charla git

Git en el mundo real

Angel Roldán @senechaux · David Pordomingo @rizomeEs C/Campomanes 6, 5ºizq; 28013 Madrid Spain

Ángel Roldán David Pordomingo@senechaux @rizomeEs

¿ Quiénes sómos ?


y venimos de...

¿Qué hacemos en Acilia?


¿ y qué os vamos a contar?Nuestra evolución

Cómo hacemos que se cumplan las normas

Cómo nos complicamos la vida, y cómo nos la solucionamos


Evolución. Prehistoria (3 años, 3 personas)

Entorno de validación similar al de producción

Ramas: todo el trabajo se realiza sobre <master>


Evolución. El equipo crece (2’5 años, 4 personas)

Entorno de validación con rama fija: preprodEntorno de pruebas independiente con rama variable

Ramas: sólo si se prevé un desarrollo largo- para todo lo demás: <master>


Evolución. La cantidad de issues crece (1 año, 6-8 personas)Entorno de validación con rama fija: preprodEntorno de pruebas independiente con rama variable

Ramas: se recomienda una por cada issueCommits: sin reglas; pueden desarrollarse fixes o tareas pequeñas sobre master.- nombres: sin política (wip, wip2, definitivo, ahorasi)


Evolución. Commits everywhere… (6 meses, 8 personas)Entorno de validación con rama fija: preprodEntorno de pruebas independiente con rama variable

Ramas: una para cada issue- nombres: prefijo ISSUE-XXXCommits: siempre en rama dedicada a la tarea- nombres: sin política


Evolución. Control del desarrollador (2 meses, 8-10 personas)Entorno de validación con rama fija: preprodEntorno de pruebas independiente con rama variable

Ramas: una para cada issue- nombres: prefijo ISSUE-XXXCommits: siempre en rama dedicada a la tarea- nombres: sin política

Fork por cada personaPull-request a través de GitHub- aprobación automática por el desarrollador


Evolución. Poniendo el foco en la calidad (1 mes, 8-10 personas)Entorno de validación con rama fija: preprodEntorno de pruebas independiente con rama variable

Ramas: una para cada issue- nombres: prefijos ISSUE-XXX, FEATURE/, CLEANUP/, COSMETICS/, FIX/, HOTFIX/, HOTFIX/ISSUE-XXXCommits: siempre en rama dedicada a la tarea- nombres: precedido por el nombre de la rama

Fork por cada personaPull-request a través de GitHub- code-review dependiente de la criticidadAngel Roldán @senechaux · David Pordomingo @rizomeEs C/Campomanes 6, 5ºizq; 28013 Madrid Spain

Evolución. Poniendoselo fácil al desarrollador (10 personas)Múltiples entornos de validación, uno por cada rama a validarEntorno de pruebas independiente con rama variable

Ramas: una para cada issueCommits: siempre en rama dedicada a la tareaCumplimiento de estándares asegurado mediante hooks

Fork por cada personaPull-request a través de GitHub- lanzados desde la consola- ¿gitflow?


Evolución. Estadios pasados.3 👥

3 años4 👥

2,5 años6-8 👥1 año

8 👥6 meses

8-10 👥2 meses

8-10 👥1 mes

entornos prodpre

prodpre

prod = prestaging

prod = prestaging

prod = prestaging

prod = prestaging

ramas master sólo para desarrollos

recomend. por issue

obligatorio por issue



commits rama propia rama propia rama propia

naming ISSUE-XXX ISSUE-XXX prefijos

forks personales personales

PR auto aprobados

code review


la cosa avanza, vamos por el ecuadorNuestra evolución

Cómo hacemos que se cumplan las normasCómo nos complicamos la vida, y cómo nos la solucionamos


Cumpliendo normas. ¿Qué normas?Compromiso con la calidad.

Compromiso con la agilidad.

Elección de estándard.

Haciendo que se cumplan las normas

Recomendación: rebase antes de PR y squashing

Git-Hooks


Cumpliendo normas. Nombres de commits bonicos<prepare-commit-msg> Tomando el nombre de la rama

<commit-msg> Validando que el mensaje del commit sigue las normas


Cumpliendo normas. Code standards<pre-commit> Asegurando que el código cumple con nuestros estándares


Cumpliendo normas. Cada commit en su sitio<pre-commit> Asegurando que no se sale ningún commit de su issue

<pre-push> Asegurando que nadie intenta pushear sobre ramas públicas


cinco minutos y estos dos se retiranNuestra evolución

Cómo hacemos que se cumplan las normas

Cómo nos complicamos la vida, y cómo nos la solucionamos


CMS, git y BDD. Editores vs desarrolladoresDesincronización entre los templates de la BDD -que manipulan los editores-, y los mismos templates que editamos desde nuestro IDE.


CMS, git y BDD. Mandando mails desde el CMSPrimer acercamiento: mandar un email cuando se edita un template desde el CMS


CMS, git y BDD. Commiteando desde el CMSSegundo acercamiento: comiteando desde el CMS


CMS, git y BDD. Pull-request desde el CMS ¿orly?Segunda vuelta: actualizando la BDD con los datos del repositorio.


bibliografía

http://git-scm.com/book/en/v2(para rellenar: en castellano) http://librosweb.es/libro/pro_git

https://github.com/brigade/overcommity evidentemente:

http://stackoverflow.com/questions/tagged/git


bibliografía


charla git

Software