Proceso de desarrollo de aplicaciones web: control de versiones, seguimiento de fallas, pruebas unitarias, implementación

Question

Describa el proceso que utiliza para desarrollar aplicaciones web en un nivel no muy alto, centrándose en VC, seguimiento de errores, control de calidad, pruebas unitarias, implementación y cualquier otra cosa similar (menos el lado de la planificación/comunicación del cliente).

Soy nuevo en esta área, por lo que mi ejemplo aproximado (léase: no he usado este proceso) es sin duda un abit off, por así decirlo, señale sus defectos para que pueda aprender.

Por ejemplo.

1. Crear repositorio de proyectos en el servidor local SVN.
2. Crear scripts de proceso por lotes/shell para las asignaciones de DNS.
3. Echa un vistazo al proyecto y comienza a trabajar en la copia de trabajo local.
4. Desarrolla funciones como ramas.
5. Seguimiento de errores con Mantis (el enlace se compromete con los errores a través de su integración SVN (no sé si eso existe)).
6. Documento sobre la marcha.
7. Hacer control de calidad en la rama.
8. Combínalo con el tronco cuando sea estable.
9. Pruebas unitarias?
10. Comprométete con el repositorio cuando la característica esté implementada y estable.
11. Copia de las publicaciones de las etiquetas en el repositorio. P.ej./project/tags/rel-123/
12. Use Phing para cargar en el servidor de transferencia. (Podría alguien aclarar exactamente lo que un servidor de ensayo se utiliza para la 'prueba' más allá?)
13. Uso Phing con la preparación de sitio activo para actualizar, configurar DB/desplegar, etc.

Answer 1

términos muy generales:

1. Crear repositorio SVN en
2. Comprobación copia de trabajo local para entorno de desarrollo
3. actualización/confirmar los cambios con frecuencia
4. Implementar a la etapa de SVN tr unk usando encargo desplegar la escritura
5. pruebas de control de calidad en el escenario, los informes de errores en Mantis
6. Desarrolladores corregir errores, marca como resuelto
7. volver a implementar para organizar
8. pruebas de control de calidad errores, se cierra si fija
9. QA es terminado, hacer pruebas de regresión
10. implementar para la producción de encargo usando desplegar la escritura
11. hacer un poco de baile

También creamos sucursales para futuras versiones o características. Estos finalmente se fusionan en el tronco.

Mantenemos nuestras estructuras db sincronizadas con una herramienta de comparación db personalizada que se ejecuta durante las implementaciones.

Answer 2

1. Crear/checkout versión de la cabeza ("rama principal")
2. Desarrollar código y sincronía con la rama principal -al menos- diaria
3. Después del desarrollo se lleva a cabo, escribir y ejecutar pruebas de unidad
4. Go mediante la revisión de código y enviar código/cambios a la rama principal
5. Deje constructor continua ejecutar todas las pruebas unitarias y pruebas del sistema/de integración en la rama principal
6. Cuando esté listo, cereza recoger las revisiones e integrarlos a la rama de control de calidad
7. Ejecute pruebas de integración y sistema, corrija errores reportados o repliegue según sea necesario; Esto se repite los pasos 4-7
8. Después de QA visto bueno, integrar el cambio de control de calidad para liberar rama
9. pruebas de unidad de ejecución, sistema/pruebas de integración en la rama de la liberación
10. Implementar para la producción y ejecutar pruebas de cordura.

Un servidor de transición es una copia de su entorno de producción lo más actualizada posible. En mi proyecto actual, podemos mantener cada versión independiente entre sí, por lo que nuestro "servidor de transición" es nuestro servidor de producción, al que se accede desde una URL diferente.

Notas y discreprencies:

Todas las etapas tienen alguna variación en función del tamaño de su proyecto. Cuanto más grande sea su proyecto, mejores serán los beneficios de la recolección de cerezas y la separación del medio ambiente. En proyectos más pequeños, estos simplemente pueden ser interrupciones de tiempo y, a menudo, se ignoran o se pasan por alto.

Para aclarar, hay una pila de desarrollo, una pila de QA y una pila de etapas. Dependiendo del tamaño de su proyecto, la garantía de calidad puede ser provisional, la producción puede ser en etapas o alguna combinación de las mismas. La separación de las pilas Dev y QA es la más importante.

En los pasos anteriores, asumo que tanto el código como los datos relevantes están versionados o son rastreados. Tener un lanzamiento y un proceso de compilación que tenga en cuenta los datos de control hace que el lanzamiento sea muy, muy fácil.

En un proyecto de tamaño pequeño-mediano, puede haber o no una rama de publicación; depende de la frecuencia del cambio de código. Además, dependiendo de la frecuencia del cambio de código y el tamaño de su proyecto, puede integrar la rama de QA completa en la rama de Liberación, o bien seleccionar las revisiones específicas para integrarlas en la rama de publicación.

FWIW, he encontrado que las "secuencias de comandos de migración" tienen poco valor. Siempre son un guión único con poca reutilización y hacen que el retroceso sea un dolor en el culo. Es mucho más fácil, diría mejor, tener la aplicación compatible con versiones anteriores. Después de algunas versiones (cuando una reversión es ridícula), se debe realizar una limpieza de datos, si es necesario.

Answer 3

Publicación anterior, pero interesante!

En mi empresa ahora:

1. Crear una nueva operación Github
2. Configurar Jenkins
3. Clon localmente
4. inicio una rama
5. Desarrollar y añadir pruebas (servidor, cliente y E2E)
6. Comprometerse con cada paso, y buscar + rebase para mantener la rama sincronizada
7. Cuando esté listo, empuje la rama en el servidor: un pre-commit pelusa de verificación y pruebas y bloque si no está bien
8. Crear una solicitud de extracción de la rama
9. Aquí, Jenkins ejecuta automáticamente pruebas en la rama y marcarlo como "verde" o "pruebas rotas" directamente en la solicitud de extracción
10. Tener al menos 2 colegas revisar la solicitud de extracción y corregir sus conclusiones (volver al paso 5)
11. Cuando todo verde y 2 colegas han acordado, el último fusiona la solicitud de extracción
12. Eliminar la rama en el servidor
13. Cuando esté listo, impulsar una nueva versión
14. Última versión acceder inmediatamente desplegó una plataforma de ensayo
15. QA validar las correcciones y características introducidas (de nuevo a 5 si el problema)
16. (TODO) Implementar en un pre-prod con idénticos parámetros que la la producción
17. Implementar para la producción
18. Ir disculpas a los usuarios por los errores introducidos;) e informar de ellos en el administrador de tema
19. peticiones GET y les informe en el administrador de tema
20. ciclo de reinicio en la paso 2