GDG - Git Flow

Descargar como pptx, pdf o txt
Descargar como pptx, pdf o txt
Está en la página 1de 36

Sumate!

meetup.com/GDG-CORDOBA-AR

#GDGCordobaArgentina

@GDGCordobaArg
Sociedad
Androide
fix(TechTalk): GDG-
005 - Improve bad
experiences
Martín Pastore
Full Stack Developer @ Tarmac.IO
3+ años de experiencia en JavaScript.
Tecnicatura Superior en Programación - UTN
Qué es Git Flow?
Algunos conceptos...

GitFlow es un workflow y conjunto de GitFlow se basa en un conjunto de


extensiones para Git introducidos por ramas que utilizaremos según el tipo de
Vincent Driessen con las que tarea que estemos llevando a cabo en
conseguiremos gestionar de manera nuestro proyecto y podemos
eficiente las ramas en nuestros clasificarlas en ramas principales y
repositorios Git. ramas de soporte.

https://github.com/nvie/gitflow
Ramas Principales
● Master: es la rama principal de nuestro
repositorio y la que se crea por default
cuando iniciamos un proyecto en Git. En
esta rama solo estará el código de la última
versión de nuestro desarrollo que esté
preparado para desplegar en producción.

● Develop: esta rama es la encargada de


contener el último estado de nuestro
código en desarrollo con las últimas
funcionalidades finalizadas para la próxima
release.

$ git flow init


Feature Branch

Estas ramas las crearemos con origen en la rama develop y sirven para cuando
queremos desarrollar nuevas funcionalidades para nuestro proyecto. Cuando hayamos
finalizado el trabajo que estemos desarrollando integraremos esta rama con sus
respectivos cambios de vuelta a la rama develop.

$ git flow feature start <your feature>

$ git flow feature publish <your feature>

$ git flow feature finish <your feature>


Hot Fix Branch

Estas ramas serán utilizadas para solucionar errores inesperados que puedan surgir en
producción y necesitemos corregirlos cuanto antes para desplegar una nueva versión
con la solución. Crearemos estas ramas desde master y una vez corregido el bug
tendremos que integrar nuestros cambios tanto en master para desplegar una nueva
versión, como en develop para incorporar la solución al código que esté en fase
desarrollo avanzado para futuras versiones.

$ git flow hotfix start <your hot fix>

$ git flow hotfix publish <your hot fix>

$ git flow hotfix finish <your hot fix>


Release Branch

Son ramas que también crearemos desde la rama develop y las utilizaremos para
preparar y hacer los últimos ajustes a nuestro código antes de integrar a master para
tener una versión lista para desplegar en producción. Además de integrar los cambios
de esta rama a master también los debemos integrar en develop para que las futuras
versiones de nuestro código en desarrollo estén al día con los cambios realizados en la
rama release.

$ git flow release start 0.1.0

$ git flow release publish 0.1.0

$ git flow release finish 0.1.0


Instalar Git Flow
Mac OS
$ brew install git-flow

Linux
$ apt-get install git-flow

Windows
$ wget -q -O - --no-check-certificate
https://github.com/nvie/gitflow/raw/develop/contr
ib/gitflow-installer.sh | bash
CI/CD
(Continuous integration / Continuous delivery)
Qué es CI/CD?

La "CI" en CI/CD siempre se refiere a la La "CD" en CI/CD se refiere a la


integración continua, que es un proceso distribución continua o a la
de automatización para los implementación continua, que son
desarrolladores. Si la CI tiene éxito, los conceptos relacionados y que a veces se
cambios del código nuevo en una usan indistintamente. Ambos conceptos
aplicación se diseñan, se prueban y se se refieren a la automatización de las
combinan periódicamente en un etapas posteriores de la canalización,
repositorio compartido. Esto soluciona el pero a veces se usan por separado para
problema de que se desarrollen explicar la cantidad de automatización
demasiadas divisiones de una aplicación que se está realizando.
al mismo tiempo, porque podrían entrar
en conflicto entre sí.
Porqué CI/CD en una charla de Git Flow?
Algunas
experiencias...
Master/Develop/Sprint
Posibles problemas...
Inconsistencias en el código
Branches desactualizados
Revertir código es un proceso tedioso por la cantidad de branches
Querer controlar todo termina en no controlar nada
Master
Posibles problemas...
Pérdida de tiempo y mucho carry over
Dependencia en otros equipos
Cambios no testeados en
staging
Proceso de deploy MANUAL
Master/Develo
p
De todas maneras...
Proceso

● Todos deben CONOCERLO

● Todos deben RESPETARLO

● Release plans

● CI/CD bien desarrollada/implementada

● Buena comunicación y canales definidos


Conclusiones
Q&A
Muchas gracias por
su tiempo

También podría gustarte