Este artículo también está disponible en:
Distinguimos tres tipos de cambios: bugs, características y cambios de infraestructura o mantenimiento del sistema. La etapa inicial es diferente para cada cambio, pero todos comparten el mismo proceso de desarrollo, prueba y despliegue.

Los clientes informaron de los errores
Siempre que se informa de un error en nuestro servicio de atención al cliente, ese error se informa en nuestro servicio interno. Desde el servicio de atención al cliente interno el error es validado por el equipo de control de calidad. Los errores válidos son entonces escalados a nuestro equipo de devsupport1 que se encarga de los errores. A partir de ese momento, siguen el mismo proceso de desarrollo que las nuevas características.

Características
Las características de la hoja de ruta que se seleccionan para el desarrollo se escriben en los criterios de aceptación por el gerente de producto. Antes de que la característica se implemente, la característica es discutida y refinada por todos los equipos involucrados.

Infraestructura y/o mantenimiento del sistema
Hay varias razones que causan un cambio en nuestra infraestructura/sistema.

Hay actualizaciones de seguridad para el software de terceros del que depende nuestro producto.
Hay nuevas versiones de software de terceros de las que depende nuestro producto.
Se necesitan cambios en la infraestructura/sistema para mejorar nuestro producto o procesos de trabajo.

Estos cambios que se seleccionan para el desarrollo se discuten y luego son implementados por nuestro equipo de desarrollo, de la misma manera que se hacen las características. Dada nuestra política de desarrollo seguro, damos prioridad a las actualizaciones de seguridad.

Proceso de desarrollo
El proceso tiene las siguientes etapas:

Discusión: Los criterios de aceptación están escritos/mejorados para el cambio deseado. Esto asegura que todos los que están trabajando en la característica o cambio saben cuál es el resultado final deseado. Nuestro objetivo es hacer muchas pequeñas mejoras sobre los grandes cambios.
Desarrollo: al menos dos desarrolladores trabajan en el código. Usamos desarrollo basado en pruebas. Probamos nuestro código con pruebas automatizadas de unidad, integración, funcionalidad y aceptación. Se requiere que todas las pruebas nuevas y existentes pasen antes de pasar al paso de revisión del código.
Revisión de código: todos los cambios son revisados por al menos otro desarrollador que no trabajó en el código. Aquí verificamos si el código está a la altura de los estándares. Usamos el OWASP top102 para comprobar las vulnerabilidades. El cambio no puede pasar a la siguiente etapa hasta que todos los comentarios se resuelvan y todos los cambios en el código hayan sido revisados de nuevo.
Control de calidad: Los cambios son probados por el equipo de control de calidad. Si los cambios no cumplen con los criterios de aceptación, los estándares de accesibilidad o tienen otros problemas, todo el proceso vuelve a la etapa de desarrollo.
Fusión: Todos los cambios se fusionan en la versión de desarrollo de nuestro producto.
Lanzamiento: Lanzamos una nueva versión de nuestro software diariamente:
Ponemos la última versión de desarrollo en nuestro entorno de prueba.
Ejecutamos la prueba de aceptación en toda la aplicación.
Si todo pasa, desplegamos todos los cambios en la producción.

Notas
El equipo de apoyo al desarrollo es un equipo de desarrolladores que ayuda con el apoyo de nuestro producto. La mayoría de nuestros errores son resueltos por este equipo.
El top10 de OWASP es una lista de las vulnerabilidades más comunes. La lista se puede encontrar en el sitio web de OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project||
¿Este artículo te resultó útil?
Cancelar
¡Gracias!