¿Qué estándares impone su equipo para una implementación de código de versión principal?

Question

Tengo curiosidad sobre qué tipo de estándares se aseguran otros equipos antes de que el código se envíe (o implemente) a la puerta en lanzamientos importantes.

No estoy buscando respuestas específicas para cada una, pero aquí hay una idea de lo que estoy tratando de tener una idea.

• Para las aplicaciones basadas en servidor, ¿se asegura de que la supervisión esté en su lugar? Hasta qué punto ... solo que responde al ping, que puede afectar a todas sus dependencias en un momento dado, que la lógica que la aplicación realmente sirve es sólida (por ejemplo, un servicio que calcula 2 + 2 en realidad devuelve "4 ")
• ¿Necesita scripts de construcción automatizados antes de lanzar el código? Es decir, ¿cualquier desarrollador puede caminar sobre una nueva caja, quitar algo del control de la fuente y comenzar a desarrollar? Dadas cosas como un sistema operativo e IDE, por supuesto.
• ¿Qué hay de las secuencias de comandos de implementación automatizada para las aplicaciones basadas en servidor?
• ¿Qué nivel de documentación requiere para que un proyecto se "complete"?
• ¿Está seguro de que tiene un plan de copia de seguridad completo para todos los componentes principales del sistema, si está basado en el servidor?
• ¿Hace cumplir los estándares de calidad del código? Piensa en StyleCop para .NET o evaluaciones ciclotómicas de complejidad.
• ¿Pruebas unitarias? Pruebas de integración? ¿Pruebas de carga de rendimiento?
• ¿Tiene estándares sobre cómo se maneja el registro de errores de su aplicación? ¿Qué tal la notificación de error?

Una vez más, no estamos buscando una lista de resultados línea por línea de respuestas a todo lo anterior, necesariamente. En resumen, ¿Qué elementos no codificados deben tener un lanzamiento de código antes de que se considere oficialmente "hecho" para su equipo?

Answer 1

El mínimo:

1. pruebas unitarias funcionan
2. pruebas de integración trabajan
3. despliegan en el escenario de prueba bien
4. corta comprobación manual en el escenario de prueba

Mejor:

1. pruebas unitarias funcionan
2. checkstyle ok
3. pruebas de integración trabajan
4. métricas como jmeter y cobertura de la prueba pasó
5. desplegar en el escenario de prueba bien
6. algunas pruebas manuales en el escenario de prueba

finalmente implementar en la etapa de producción

Todas las pruebas de unidad e integración funcionan automáticamente, lo mejor es en un servidor de integración continua como CruiseControl hecho por ant o maven. Al desarrollar servicios web, la prueba con soapui funciona bien.

Si se utiliza una base de datos, se realiza una actualización automática (con liquibase por ejemplo) antes de la implementación. Cuando se utilizan servicios externos, se necesitan pruebas de configuración adicionales para garantizar que las URL estén correctas (solicitud principal desde la aplicación, conexión a la base de datos, wsdl get, ...). Al desarrollar webpps, un HTML validation en algunas páginas será útil. Una verificación manual del diseño (use browsershots por ejemplo) sería útil.

(Todos los enlaces de ejemplo para el desarrollo de Java)

Y por último (pero no menos importante): son todas las pruebas de aceptación sigue pasando? ¿Es el producto lo que el dueño quiere? ¡Haga una revisión en vivo con él en el sistema de prueba antes de ir más allá!

Answer 2

Principalmente hago desarrollo web, por lo que mis artículos pueden ser diferentes a los suyos. Justo al lado de la parte superior de mi cabeza ...

• Asegúrese de que todos los servicios web están hasta a la fecha de
• Asegurar que todas las bases de datos scripts/cambios/migraciones ya están desplegados en el servidor de producción
• Min todos js y archivos css.
• Asegúrese de que todas las unidades/integración de las pruebas de Selenium funcionales// están pasando (Nuestro objetivo es que el 95% + cobertura de la prueba, mientras que estamos desarrollando, por lo que estos suelen ser bastante precisa en la determinación de un problema)

Hay más , Sé que hay, pero no puedo pensar en ninguno ahora.

Answer 3

1. ¿No hay errores visibles? ok
2. prueba de unidad de trabajo? ok (algunos lo ignoraron) ha funcionado bien
3. setup ya sure. ok
4. ¿registro de error? por supuesto ! :-) necesitamos esto ! para arreglar los errores!
5. todo en cruisecontrol.net nice.

Answer 4

Todos y cada uno de los proyectos son diferentes, sin embargo, como regla general, aquí están las cosas centrales que trato de hacer antes de dejar que el código salga al aire libre.

En ningún orden en particular:

1) Una identificación de la versión en el lugar donde se puede encontrar por un usuario más tarde, esto debe ser única para esta versión. (muy típicamente un "número de versión" asociado en el archivo distribuible, las bibliotecas y el ejecutable, o el usuario visible desde un diálogo "aproximadamente." Podría ser un número en un registro conocido o desplazamiento en el firmware)

2) Una instantánea del código exacto utilizado para producir el lanzamiento.(Una etiqueta o una rama de la liberación en el sistema SCM es bueno para esto)

3) Todas las herramientas necesarias para recrear la fuente debe señalarse y archivado (fuente de la etapa 2 se hace de uso limitado sin este)

4) Un archivo de la versión real (una copia del instalador exacto publicado, quien sabe en 7 años que sus herramientas pueden no ser capaces de construirlo, pero ahora al menos usted tiene el código fuente y un instalable a su lado para fines de investigación).

5) Un conjunto de cambios documentados entre esta versión y la anterior aka Notas de versión (me gusta usar el estilo de agregar a la lista para que todos los cambios de publicación estén disponibles en un solo lugar para un usuario).

6) Ciclo de prueba de lanzamiento del candidato completo. Utilizando la carga y la prueba creadas distribuibles usando el plan de prueba completo/revisado para asegurarse de que la funcionalidad central esté operativa, todas las funciones nuevas están presentes y funcionan según lo previsto.

7) El seguimiento de defectos muestra que todos los artículos pendientes se marcan como a) fijos b) no es un defecto c) diferido.

Puede rociar en muchos otros pasos dependiendo del dominio o el estilo de desarrollo, pero yo diría que la mayoría del software "debe ser" realizando los pasos anteriores cada lanzamiento. YMMV.

Diviértete asaltando el castillo.

Answer 5

• Codestyle
• pruebas automatizadas (automatizados) (partícipes & Integrationtests)
• pruebas manuales (incluyendo las etapas de ensayo y beta)
• Whitebox herramienta de prueba de penetración de la herramienta de pruebas de penetración
• Blackbox (automatizado) (automatizado)
• Monitorización de excepción/registro manual en etapas de prueba/beta antes del despliegue
• capacidad para volver a la versión anterior en cualquier momento/aplicaciones internas
• revisión de código & 'ilegales' Checkins

Answer 6

para la web una cosa, además de las otras sugerencias.

Asegúrese de involucrar al equipo de operaciones/despliegue para que no entregue software que requiera más servidores de los que ya tienen (no asuma que las personas que presionan los requisitos ya lo han hecho).

Answer 7

• Revise la lista de verificación: verifique que todas las funciones nuevas, las solicitudes de cambio y las correcciones de errores planificadas para la versión hayan sido finalizadas.
• La compilación (en la máquina de compilación) se compila sin ningún tipo de advertencia ni error en el modo de lanzamiento.
• Todas las pruebas unitarias automatizadas se ejecutan sin error.
• Todos los mensajes e imágenes han sido aprobados por el equipo del producto.
• Las comprobaciones de rendimiento no son peores que la versión anterior.
• El plan de prueba completo (manual) ha sido comprobado por el equipo de prueba sin errores.
  • La aplicación se prueba en muchos escenarios posibles (diferentes sistemas operativos, motores de bases de datos, configuraciones y aplicaciones de terceros).
  • Todas las características de la aplicación se prueban: muchas veces nos pasó que un cambio en una característica rompió con otra que no se consideraba relacionada, mierda sucede, por lo que debemos minimizarla.
  • La configuración o implementación funciona en todos los escenarios demasiado
  • La configuración es capaz de actualizar las versiones anteriores

Answer 8

Hicimos un gran lanzamiento hace poco tiempo, así que esto es todavía bastante fresco en mi mente. Hacemos una aplicación de Windows con una GUI para la cual lanzamos un ejecutable binario, por lo que mi lista necesariamente será sustancialmente diferente de la de una versión solo web.

1. Los candidatos al lanzamiento van al equipo de pruebas. Necesitan al menos unos días para jugar con eso. Si encuentran algún error que consideremos bloqueadores del show, la publicación se cancela. Esto supone que tienes un equipo de prueba. Solo borramos un candidato de lanzamiento si ha transcurrido al menos una semana desde su fecha de compilación.

2. Todas las pruebas automatizadas tienen que funcionar y aprobarse. Las pruebas automáticas se consideran un complemento de los verificadores en vivo.

3. Todos los errores marcados como "bloqueadores" se deben resolver para la construcción final.

4. El material publicitario debe estar listo (en nuestro caso, una actualización de la página web y un boletín informativo por correo electrónico). Los revendedores son alertados de que un lanzamiento se realizará con varias semanas de anticipación, para que puedan preparar su material también. En su mayoría, esto no es una preocupación de los programadores, pero revisamos las afirmaciones de marketing para garantizar su precisión.

5. Las licencias deben actualizarse para reflejar la protección contra copia que estamos utilizando. Nuestras versiones beta y versiones de lanzamiento utilizan diferentes modelos de licencia, y este cambio requiere un esfuerzo de programación.

6. El instalador y el acuerdo de licencia deben actualizarse. Dado que las versiones beta tienen un instalador, esto generalmente es solo un cambio de texto, pero aún les corresponde a los programadores actualizar realmente el script de instalación.

7. Cualquier referencia a la versión beta debe eliminarse de la aplicación. Perdimos algunos de estos, vergonzosamente.

8. Los archivos de ayuda y los manuales deben actualizarse y corregidos por completo, ya que forman parte del paquete de publicación.

9. Si hubiera errores que no se pudieron solucionar a tiempo, al menos intentaríamos mitigar el daño, por ejemplo, detectar que tal error estaba ocurriendo, y abortar la operación con una disculpa mensaje de error. Esto contribuye enormemente a la estabilidad percibida del producto.

Lejos y lejos, las dificultades de un lanzamiento importante no eran problemas de programación, sino problemas administrativos o de comercialización. Muchas de estas cosas requirieron la atención de los programadores: ayudaron con los instaladores, revisaron la lista de características para asegurarse de que nada de esto era una tontería, secciones técnicas de corrección de pruebas del manual, actualización de licencias, etc.La principal diferencia técnica fue el cambio de la corrección de errores a la mitigación de errores.