¿Cómo gestiona el ciclo de vida de su proyecto?

Question

¿Cómo gestionas el ciclo de vida de tu proyecto?

Por ejemplo: ¿Empiezas con una plantilla? ¿Utiliza versiones como SVN como la fuente autorizada? ¿Archiva los proyectos, si es así cuándo y cómo? Cuando se reanima un proyecto (se reanuda el trabajo), ¿cómo se maneja? ¿Utiliza scripts automatizados para hacer cosas como crear sitios IIS, bases de datos, archivar, iniciar, etc.?

De particular interés es la gestión de muchos proyectos en diferentes puntos de desarrollo.

Answer 1

Desarrollo: No comenzamos con una plantilla, porque el mundo cambia lo suficientemente rápido como para hacer que el mantenimiento de la plantilla sea un trabajo de tiempo completo. Animamos a todos a usar el mismo IDE (Eclipse), para que puedan ayudarse unos a otros con sus entornos.

Gestión de proyectos: Estamos utilizando GForge para gestionar nuestros proyectos. Sourceforge es un poco mejor, pero GForge es mucho más barato y tiene un modelo de tarifa de licencia diferente. GForge incorpora CVS, SVN, almacenamiento de documentos, seguimiento de problemas e integra todo muy bien. Esto hace que sea fácil ver dónde está el proyecto. Problemas abiertos y problemas cerrados con cambios de código conectados, todo está integrado.

de versiones: pesar de que tratamos de SVN, que cambió de nuevo a CVS porque se ajusta a nuestras necesidades mejor y funciona bien.

Copias de seguridad: Nuestro servidor GForge, que aloja todos nuestros proyectos y código fuente, se ejecuta en un servidor VMWare EX. Las copias de seguridad se realizan a diario en el nivel de VM y hacemos instantáneas de VM si creemos que necesitamos puntos de restauración más frecuentes por algún motivo.

Proyectos de reanimación: Esto es muy común en nuestro negocio. Cada proyecto tiene todas sus bibliotecas y requisitos de compilación en CVS. El proyecto siempre tiene un manual de desarrollo actualizado que describe todos los pasos para ejecutar un entorno de desarrollo, y tiene un capítulo con todas las cosas que no son predeterminadas, para prestarle atención. Intentamos crear software en un entorno predeterminado como sea posible para que los desarrolladores no tengan que perder días ajustando sus configuraciones.

Casi todos los proyectos están diseñados con Maven, lo que también hace la vida más fácil para nuestros desarrolladores. Ususally la reactivación de un proyectos sólo tarda unos pocos pasos:

• Descargar Eclipse
• Conectar a CVS a través de SSH (extssh está integrado en Eclipse)
• Salida del proyecto (por defecto "Hora de salida" opción)
• Ejecute "Maven Eclipse" y actualice Eclipse
• Ejecute pruebas de unidad en Eclipse para ver si todo está funcionando.

Builds: Todos nuestros proyectos se basan en un servidor de compilación independiente. Todas las mañanas, el servidor de compilación realiza una compilación completa y etiqueta CVS si todas las pruebas de unidad tienen éxito. Durante el día, se realizan construcciones por hora y cuando hay fallas, el equipo recibe automáticamente un correo electrónico. Usualmente usamos un servidor de compilación por proyecto, y es un servidor luntbuid simple (Linux, Tomcat, Luntbuild).

Tanto el servidor de construcción como algunas veces las máquinas de desarrollo son máquinas virtuales. Esto hace que revivir un proyecto sea realmente fácil. Obtenga la VM del servidor de archivos, iníciela y estará listo.

El servidor de compilación crea sitios diarios que muestran estadísticas de cobertura de prueba de unidad, mediciones de complejidad, actividad de CVS y actividad de desarrollador (quién cambió qué y cuándo).

Todo nuestro software viene con scripts de base de datos de autoconstrucción incorporados. Apunte el archivo de configuración a la base de datos, inicie el software y descubra lo que tiene que hacer con la base de datos. Esto realmente es útil porque el servidor de compilación puede simplemente iniciar el software. No se requieren pasos especiales.Nuestros clientes también están contentos, nunca necesitan preocuparse por su base de datos o actualizar los scripts.

Todo el ciclo de vida del proyecto se gestiona, documenta y rastrea en GForge, con la adición de algunas hojas de cálculo externas para el seguimiento del presupuesto porque es simplemente más fácil.

Si tiene un servidor de proyecto integrado o no, creo que es realmente importante tener un sistema. Esto le permite cambiar de programador entre proyectos sin que se pierdan. Ahorra tiempo. Particularmente cuando un cliente vuelve a usted después de 2 o 3 años por modificaciones en el software anterior (sí, eso sucede).

Todo lo que utilizamos es de código abierto (incluso puede usar una horquilla de código abierto de GForge). No está en las herramientas, es cómo las usas.

Answer 2

Depende de la naturaleza del trabajo. Cuando trabajo en casa para clientes privados, comienzo abriendo una carpeta para el cliente con un montón de documentos estándar, que personalizo, como contratos, facturas, informes, requisitos, pruebas, depósito de códigos, etc. A medida que el proyecto se desarrolla, Agrego/modifico el directorio según sea necesario.

Si tuviera que volver a un proyecto, volvería a abrir ese directorio, y para cualquier componente no común, crear un nuevo directorio. Por ejemplo, si mi cliente creó una aplicación web y ahora necesitan una segunda, utilizaría los mismos directorios para facturas y contratos y crearía nuevos directorios para la base de códigos, los requisitos y las pruebas.

En términos de copia de seguridad, archive el trabajo en cualquier punto donde haya alcanzado un hito, con la excepción del código, del cual hago una copia de seguridad a diario como mínimo. Al final de cada proyecto, cuando cierro un contrato, tomo todo el directorio y lo comprime y almacena en un servidor remoto.

Answer 3

creo carpetas que contienen las etapas del proyecto como "proceso de inicialización de software" en donde colocamos documentos como la propuesta de negocio, usamos otro para requisitos de construcción, lanzamientos, uno para reuniones minutos, y así sucesivamente.

Guardamos ésos bajo un repositorio de subversión pero realmente depende de qué metodología está utilizando, también depende de cómo se maneja la gestión de configuración y cómo se organiza. y sí, usamos plantillas para la mayoría de nuestros artefactos, por lo que aseguramos de alguna manera la calidad de nuestros productos.

Answer 4

En cuanto a código fuente, lo tenemos todo en un repositorio de Subversion. Después de cada lanzamiento, hacemos una sucursal: las nuevas funciones solo se agregan a la sucursal actual (en la que se basará la próxima versión), las correcciones de errores críticos se realizan en la sucursal actual y antigua (para que podamos ofrecer revisiones para la versión) los clientes tienen actualmente).

En cuanto a los documentos pertenecientes a una liberación de las hojas - Planificación de recursos & a las especificaciones, los casos de prueba, el usuario y manuales técnicos para el software que crean etc. - les almacenamos en un sitio de portal de SharePoint. Las ventajas de este sitio Sharepoint es que los usuarios tienen acceso a través de un sitio web (por lo que no es necesario otorgar acceso de gestión a su repositorio ;-), puede controlar de forma precisa los derechos de acceso y puede activar el control de versiones. También utilizamos el etiquetado para marcar si un documento pertenece a una versión específica (por ejemplo, service pack xy) o producto, o si es generalmente válido.

Con respecto a las escrituras , utilizamos varias para realizar p. Ej. Nightly build plus unit tests (usualmente hacemos eso para la última versión y la versión actual), pero también para implementar la solución de software completa (incluida la creación de sitios IIS, la actualización del modelo de datos de base de datos, ...) en los servidores de prueba. Estos son los scripts nant que usan muchas variables para rutas, números de versión, etc. por lo que es muy fácil copiarlos y modificarlos para una nueva versión.