Plan de integración continua

¿Alguna vez te has preguntado por qué tú no tenías la reacción del “Me importa” en Facebook pero tus otros amigos sí? Bien, aquí tienes por qué, el plan de integración continua comienza a hacer el despliegue en producción paso por paso.
.
Aquí es donde vemos lo que comenté en la clase anterior, el uso de git, GitHub y sus branches, que de nuevo, esto está bien explicado en esta clase:
.
https://platzi.com/clases/1557-git-github/19955-flujo-de-trabajo-profesional-haciendo-merge-de-ram/
.
Algo que me parece curioso son los tags, si los conocía, pero se me hacía más lógico tener un branch exclusivo para producción, y que ese branch sea master.

Les recomiendo mucho revisar gitflow, que es la manera en que trabajamos en la empresa que me encuentro. Me parece útil y creo que tiene las ramas necesarias para tener orden en el repositorio, a continuación relaciono una imagen del flujo:

Como aporte en los deployments por lo general se utilizan estrategias de deployments como canary, blue/green, rolling deployment para realizar todo lo que el se referia de liberas la version a X cantidad de Usuario o Zonas, etc. Les dejo un enlace donde pueden leer mas y tener una idea mas completa de las estrategias de deployment.

Veo que existen algunos comentarios que hacen referencia a la convención que maneja Angular para commit message, esta cool y lo utilizo muy seguido, pero mi decisión para el formato de escritura depende desde el tipo de proyecto, tamaño, y cantidad de integrantes, a partir de ello tomó como referencia Conventional Commits (en esta convención de igual manera hacen referencia al formato que maneja Angular)y voy modificando el formato.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Al final lo que importa es que un commit message sea claro para las personas del equipo, ya que con un buen mensaje podemos tener una visibilidad de que paso en el commit antes de entrar analizar en el código, ya que algunos objetivos principal de los commit messages son: poder saber qué cambios vienen cuando alguien realiza un PR para un code review o si estamos buscando un error a través del tiempo de evolución del del proyecto, podemos saber a través de un mensaje claro donde se pudo haber agregado ese error.

Nunca, Nunca poner mensaje como

• Hecho

• No entiendo cómo funciona

• Ya arregle esto

• Se agregó botón

• Se cambio color

• Sálvame Diosito

• Etc.

Por si desean colaborar en proyectos grandes, les comparto las reglas de Angular para contribuir:

La rama Master en Github ahora es Main

Hola!

Les comparto el enlace del curso de Git y GitHub que explica los cambios recientes que se han incorporado en algunas palabras; por ejemplo, ya no se dice master, sino más bien main: https://platzi.com/clases/1557-git-github/35869-cambios-en-github-de-master-a-main/

Responder

Habia muchas expectativas por este curso en parlicular, pero hasta el momento me parece como la receta que te da algun amigo por telefono y después con los ingredientes en mano, no sabes como preparar el plato, espero mejore mas adelante.
Para la gestión del Repository vale la pena leer. Que cosa es GitFlow.

Si quieren entrar en detalles acerca de Git, pueden ver el curso de Git y Github: https://platzi.com/clases/git-github/

Muy interesante esta forma de usar los tags, este curso se pone cada vez mejor, hasta puede ser la base en un futuro de otros cursos de backend en platzi, haciendo implementaciones en django,laravel, java etc.

muy interesante esta clase…