version control - tiempo - ¿Cómo gestionas el ciclo de vida de tu proyecto?
importancia de la gestion del tiempo en proyectos (4)
Dependería 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, reabriría ese directorio y, para cualquier componente no común, crearía 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 respaldo, archive el trabajo en cualquier punto donde haya alcanzado un hito, con la excepción del código, del cual realizo 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.
¿Cómo gestionas el ciclo de vida de tu proyecto?
Por ejemplo: ¿comienzas 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.
creo carpetas que contienen las etapas del proyecto como "proceso de inicialización del software" en donde colocamos documentos como la propuesta de negocio, usamos otro para requisitos, otro para la construcción, lanzamientos, uno para reuniones, minutos, etc.
Los mantenemos en un repositorio de subversión, pero realmente depende de la metodología que se utilice, también depende de cómo se maneja la administración de la 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.
En cuanto al 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 todos los documentos que pertenecen a un lanzamiento, desde las hojas de planificación y recursos hasta las especificaciones, teselas, manuales de usuario y técnicos para el software que creamos, etc., los almacenamos en un sitio del portal 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 usamos 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.
En cuanto a los scripts , utilizamos varios para realizar pruebas nocturnas de construcción plus (normalmente hacemos eso para la última versión y la actual), pero también para implementar la solución de software completa (incluida la creación de sitios IIS, actualización de modelos de datos de bases de datos, ... ) en los servidores de prueba. Estas son secuencias de comandos nant que usan muchas variables para rutas, números de versión, etc. por lo que es muy fácil copiarlas y modificarlas para una nueva versión.
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.
Versiones: aunque probamos SVN, volvimos a cambiar a CVS porque se ajusta mejor a nuestras necesidades y funciona bien.
Copias de seguridad: nuestro servidor GForge, que alberga 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 reactivació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 se crean utilizando Maven, lo que también hace la vida más fácil para nuestros desarrolladores. Usualmente revivir un proyecto solo requiere unos pocos pasos:
- Descargar eclipse
- Conéctese a CVS a través de SSH (extssh está integrado en Eclipse)
- Vea el proyecto (opción predeterminada "Pagar")
- Ejecute "Maven Eclipse" y actualice Eclipse
- Ejecute pruebas de unidad en Eclipse para ver si todo está funcionando.
Compilaciones: todos nuestros proyectos están construidos en un servidor de compilación separado. 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 máquina virtual 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 secuencias de comandos de base de datos de autoconstrucción integradas. Apunte el archivo de configuración a la base de datos, inicie el software y descubra qué debe 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.
Ya sea que tenga 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 puedes usar un tenedor de código abierto de GForge). No está en las herramientas, es cómo las usas.