top of page

Workflow de déploiement : le point de vue d’Abdenour, DevSecOps chez La Javaness

Nous avons au sein de notre écosystème La Javaness de multiples projets à gérer. Nous allons dans un premier temps identifier notre problématique de déploiement, puis face à cela itérer sur notre modèle de déploiement mis en place.


14/03/2022

La problématique que nous vivons au jour le jour est la suivante : chaque protagoniste a des attentes bien précises. Les développeurs ont besoin d’un environnement de développement prêt à l’emploi rapidement. De même, une mise en place d’une intégration comprenant les items suivants:

- Test d’intégration et de non-régression

- Construction applicatifs

- Livraison d’artefacts


Le souci rencontré par le développeur tient à au développement uniquement de la production de son artefact .


Concernant l’Ops, ce dernier doit déployer en prenant en compte les paramètres suivants :

- Le déploiement doit être associé au bon artefact.

- Le déploiement doit s’effectuer de manière continue ou bien à la demande


En règle générale, un projet applicatif se déploie sur trois environnements avec un degré de criticité et de contrainte allant crescendo. L’environnement de développement dispose d’un cycle de vie court et évolue constamment. Il permet aux développeurs de tester les fonctionnalités en continue et reste en constante évolution. L’environnement de staging permet de déployer les microservices dit “stable”.


Par ailleurs la production comme définit contient les microservices qui sont utilisés par les utilisateurs et clients en temps réel.

 

Maintenant que les problématiques ont été établies, il s’agit d’identifier quelles sont les différentes étapes de notre cycle de vie. Nous identifions les phases suivantes :


1. Création des infrastructures

2. Modèles de livraisons des artefacts comprenant les tests et la qualité.

3. Déploiements des artefacts

4. Mise à jour automatisée ou pas


Nous mettons à disposition les infrastructures avec l’aide de Terraform qui présente les avantages suivants :

- Infrastructure as code déclarative et itérative - Idempotence - La facilité de décommissionnement - Mise en place de politique de dry run, et de load test sans pour autant maintenir une infrastructure UP en continu.


Dès lors que la plateforme infrastructure est UP, nous utilisons Gitlab et Gitlab Runner pour configurer les pipelines qui vont se décliner en deux parties. En prenant pour Exemple un projet Backend au sein de La Javaness pour décrire ce processus.

La CI (Continuous Integration) comprend les étapes suivantes :



Sur ce pipeline, nous nous assurons que le livrable est testé et ne contient pas de vulnérabilité. Par ailleurs on attribue une version à cet artefact qui nous sera utile pour l’historisation et le rollback. La deuxième partie de la CI concerne la livraison de l’artefact dans un dépôt donné.



Cette étape est la dernière étape de la CI qui consiste à livrer l’artefact. Ainsi, cette stratégie nous permet de livrer un artefact agnostique et déployable partout.




Vous souhaitez en savoir plus sur notre entreprise, nos actualités, et d'autres sujets ?

Abonnez-vous à notre newsletter pour ne rien manquer !



14 views0 comments
bottom of page