No hablaré de ninguna verdad universal, pero así es como lo hacemos:
- GitFlow a través de SourceTree. Cualquier cosa fusionada con la rama de desarrollo desencadena un enlace web en Bitbucket que realiza una llamada a un script de implementación en nuestro servidor de desarrollo. Se lleva a cabo un montón de autorizaciones y otras cosas para verificar que la llamada se realiza desde Bitbucket y luego desencadena un simple “git pull” en la rama de desarrollo del repositorio principal.
- Después de verificar que todo está bien con la rama de desarrollo, se realiza una fusión de desarrollo a maestro que activa otro enlace web con las mismas funciones que el paso anterior, pero aquí en nuestros servidores de producción.
Esto funciona bastante bien para decir la verdad. La revisión es muy fácil, tan pronto como se empuja la sucursal, se aplica automáticamente a los servidores de producción, lo que nos permite centrarnos en llevar esa revisión por los desagües a todas las demás sucursales activas.
Tan pronto como las características estén listas para pruebas amplias, las tenemos disponibles de inmediato en nuestro entorno, y no es necesario realizar fusiones amplias de antemano.
- ¿Cómo puede ser segura una aplicación web o móvil si está escrita con frameworks controlados por Javascript (Angular, Nodejs ...)?
- ¿Cuál es la forma preferida de estructurar las aplicaciones web de Golang?
- ¿Cuál es el lenguaje de programación más adecuado para desarrollar aplicaciones web de gran escala?
- ¿Las aplicaciones web realmente pueden reemplazar las aplicaciones nativas fuera de línea / Windows para el software ERP?
- ¿Cuál es la mejor plataforma de facturación y pago para un producto de suscripción web basado en equipo?
Por supuesto, esto supone que está empleando algún control de versión, ya sea Git o Mercurial o lo que sea que haga flotar su barco. En nuestro caso, hemos tenido excelentes experiencias con Git a través de Bitbucket y diría que, en lo que respecta a la GUI para Git, SourceTree es un cliente muy fuerte que me brinda un gran control y una visión general con casi todo lo que podría ser complicado en Git simplificado en conceptos comprensibles y atajos.
También me gustaría promover la forma de trabajar de GitFlow. Entiendo que podría no satisfacer las necesidades de todos, pero en nuestro caso es extremadamente adecuado:
- Rama maestra: esta es la producción, nada debería fusionarse aquí si no se ha probado rigurosamente.
- Desarrollar sucursal: este es un terreno común para todos los desarrolladores en un proyecto más o menos. Cada función / revisión presenta una solicitud de extracción que se obtiene cuando el gerente de proyecto ha revisado el código y permanece en desarrollo hasta el próximo lanzamiento programado.
- Ramas de características: este es el patio de recreo. La comprobación de la rama de desarrollo permite a cualquier desarrollador crear de forma independiente sus características, protegidas de forma segura en su propio entorno. Cuando una característica está lista para fusionarse en el desarrollo, utilizamos solicitudes de extracción y revisión de código.
- Liberar ramas: aquí es donde los conceptos se vuelven realmente suaves para nosotros. Cuando tenemos suficientes características para hacer un lanzamiento, o el momento es correcto, bifurcamos la rama de desarrollo en un nuevo lanzamiento. Corrección de errores, pruebas, lo que sea. Aquí es donde sudamos nuestro código. Cuando “todo está hecho” fusionamos la rama de lanzamiento en master. Otro número de versión salta a su lugar, y volvemos al desarrollo de características individuales.
Como dije antes, este no es un flujo de trabajo universal, y estoy seguro de que hay muchas razones para que este flujo de trabajo no sea adecuado para entornos específicos, pero creo que es un gran flujo para desarrollar alrededor de un repositorio central.
Hay un buen artículo en profundidad en Atlassian con ilustraciones que explican también otros flujos de trabajo: Gitflow Workflow.
Para responder a su pregunta en breve: no, no creo que haya una forma absolutamente correcta de implementar aplicaciones. La mejor manera es la necesidad que se adapta perfectamente a su flujo de trabajo y que tiene sentido para su entorno. Asumir implementaciones hechas para escalas empresariales no tiene sentido para una pequeña aplicación web, del mismo modo que los enlaces web no tendrían sentido en un sentido de escala de Facebook.
¡Las herramientas adecuadas para el trabajo siempre dependen del trabajo!
