Docker et l'usine logicielle

Introduction

Nous vivons une période passionnante en informatique. En effet, durant les dernières années, nous avons constaté un changement de paradigme du développement (l’industrie a globalement adopté le développement en mode Agile plutôt qu’en mode Waterfall, connu aussi sous le nom de cycle en V) et une évolution radicale des outils et langages. De nouveaux patterns et de nouvelles méthodes de travail ont émergé à la suite de ces nouveautés, et Docker est, entre autres, une réponse à tous ces changements.

Mais, par-dessus beaucoup de choses, c’est un nouveau mode de travail collaboratif qui a vu le jour : le mode DevOps. DevOps est une contraction des termes "développeurs" et "opérationnels" (ou opérations). Cela signifie que cette façon de travailler a pour but de rapprocher les développeurs des opérationnels. Jusqu’à présent, nous avons utilisé Docker pour tester nos développements, mais vous avez dû constater que de petites subtilités à respecter en vue d’une mise en production ont plusieurs fois été mentionnées. Étant donné que nous, développeurs, sommes maintenant beaucoup plus proches des opérationnels, notamment pour traiter leurs retours plus rapidement, nous devons également nous mettre à leur écoute et les assister du mieux que nous pouvons, afin que toute l’équipe gagne en efficacité.

Figure 1 :Figure DevOps (source : Wikipédia)

La forme choisie pour illustrer les principes DevOps, comme on le constate ci-dessus, est assez explicite. Le signe de l’infini permet de mettre en évidence qu’il s’agit d’un cycle qui s’enchaîne et se répète continuellement. Le développeur a la responsabilité de participer à la planification du travail, de créer le code associé pour répondre aux besoins fonctionnels, d’effectuer les vérifications nécessaires (tests automatisés) et de livrer une version empaquetée. Les opérationnels, eux, vont effectuer le déploiement de cette version, la configurer selon le point de vue de l’infrastructure et suivre...

Pipeline DevOps

L’intégration continue se déroule en plusieurs phases distinctes :

Il est assez facile de constater qu’il y a beaucoup de choses à faire. Certaines étapes de cette liste sont bien entendu facultatives, et il est également possible d’inclure des étapes personnalisées, mais il faut garder à l’esprit qu’une bonne intégration continue couvre le maximum de choses pour assurer un haut niveau de qualité, car c’est là son but. De la même façon, il est assez facile de se rendre compte qu’il y a deux groupes logiques d’actions dans cette liste : les actions de création/construction et les actions de vérification/publication.

À la suite de la publication des artefacts de compilation, il sera possible d’enchaîner sur un déploiement continu qui déploiera ces artefacts sur une infrastructure d’exploitation.

Dans le cadre d’un workflow de développement, il faudra réaliser ces opérations et publier sur notre poste local pour pouvoir tester. Docker et Git nous permettent de réaliser la totalité de ces opérations, voyons tout d’abord comment construire un pipeline manuel sur un poste de développeur.

Outils pour le développement

Généralement, un pipeline DevOps va proposer une collection d’outils supplémentaires qu’on ne retrouve pas aisément sur un poste local de développeur. Par exemple, on y trouvera des outils d’analyse de code, comme Sonar, ou, comme on l’a utilisé précédemment, un dépôt privé pour mettre à disposition nos images. Bien qu’il soit possible d’installer ces éléments sur le système, ils peuvent être configurés différemment d’un poste à l’autre et vont, dans tous les cas, altérer le système du développeur en y ajoutant certaines choses.

Finalement, il va exister des tests automatisés qui auront besoin d’éléments d’environnement, comme par exemple une base de données ou un message broker, afin de simuler un environnement de préproduction.

Docker va nous permettre de monter ce type d’outils rapidement et facilement en local, afin d’améliorer le flux de travail.