Je suis également seul dev dans ma structure, j'utilise git flow. Il me permet de jongler avec les différentes features / bugfix...
Pour le déploiement, j'utilise des tags sur la branche master pour la PROD, et la branche "develop" brute pour la pré-prod (STAGING). La préprop peut casser, mes utilisateurs sont au courant :)
Le processus de déploiement est "à la demande": j'ai un rôle ansible qui fait le taff quand j'en ai besoin, avec un script maison deploy.sh qui n'est qu'un lanceur pour le rôle ansible.
Du coup, j'utilise pour mettre en prod :
git flow release start <version>
Bump version numbers vers > (y compris les vars ansible pour la prod !)
git commit (dans la branche release/)
git flow release finish
./deploy.sh << Vers la pré-prod
./deploy.sh -m PROD << Vers la prod
L'avantage de cette approche, c'est que je peux à tous moments pousser vers la staging (branche develop), mais que je ne peux pas pousser "par accident" dans la PROD.
Le process est à la fois contraignant mais pas trop, et avec le rôle ansible, je n'oublie rien.
Je déploie environ 20 projets différents avec cette méthode, et j'en suis très satisfait.
Ah, et j'ai un script python pour faire les montées de version:
Ce script ne fait que mettre à jour les numéros de version dans différents points du projet (main, docs, ansible vars pour récupérer le bon tag quand je déploie), il ne fait rien avec GIT.
Pour info, je fais quasi exclusivement du Django / python...
# git flow + releases
Posté par François GUÉRIN (Mastodon) . En réponse au message branches GIT. Évalué à 1.
Salut?
Je suis également seul dev dans ma structure, j'utilise
git flow. Il me permet de jongler avec les différentes features / bugfix...Pour le déploiement, j'utilise des tags sur la branche master pour la PROD, et la branche "develop" brute pour la pré-prod (STAGING). La préprop peut casser, mes utilisateurs sont au courant :)
Le processus de déploiement est "à la demande": j'ai un rôle ansible qui fait le taff quand j'en ai besoin, avec un script maison
deploy.shqui n'est qu'un lanceur pour le rôle ansible.Du coup, j'utilise pour mettre en prod :
git flow release start <version>git commit(dans la branche release/)git flow release finish./deploy.sh<< Vers la pré-prod./deploy.sh -m PROD<< Vers la prodL'avantage de cette approche, c'est que je peux à tous moments pousser vers la staging (branche develop), mais que je ne peux pas pousser "par accident" dans la PROD.
Le process est à la fois contraignant mais pas trop, et avec le rôle ansible, je n'oublie rien.
Je déploie environ 20 projets différents avec cette méthode, et j'en suis très satisfait.
Ah, et j'ai un script python pour faire les montées de version:
https://pypi.org/project/bump-release/
Ce script ne fait que mettre à jour les numéros de version dans différents points du projet (main, docs, ansible vars pour récupérer le bon tag quand je déploie), il ne fait rien avec GIT.
Pour info, je fais quasi exclusivement du Django / python...