How To Become a DevOps Engineer In Six Months or Less

NOTE : La dernière mise à jour de cette série date de décembre 2022.

Partie 1

Public cible

Êtes-vous un développeur qui cherche à réorienter sa carrière vers un modèle plus DevOps ?

Vous êtes une personne ayant reçu une formation classique en Ops et vous aimeriez avoir une idée de ce qu'est le DevOps ?

Ou bien vous n'êtes ni l'un ni l'autre, et après avoir passé un certain temps à travailler avec la technologie, vous êtes maintenant simplement à la recherche d'un changement de carrière et vous ne savez pas par où commencer ?

Si c'est le cas, lisez la suite, car nous allons voir comment devenir un ingénieur DevOps de niveau intermédiaire en six mois !

Enfin, si vous faites du DevOps depuis des années, vous trouverez peut-être ceci utile pour valider où nous en sommes et où nous allons.

Qu'est-ce que c'est ?

Tout d'abord, qu'est-ce que DevOps ?

Vous pouvez chercher les définitions sur Google et vous frayer un chemin parmi tous ces mots à la mode, mais sachez que la plupart d'entre eux sont des salades de mots trop longues et embarrassantes qui s'insèrent dans des phrases interminables (vous voyez ce que j'ai fait ici). (Vous voyez ce que j'ai fait ici ?)

Je vais donc vous épargner les clics et vous résumer la situation :

DevOps est un moyen de fournir des logiciels avec une douleur et une responsabilité partagées.

C'est tout.

D'accord, mais qu'est-ce que cela signifie ?

Cela signifie que traditionnellement, les développeurs (les personnes qui créent les logiciels) avaient des motivations très différentes de celles des opérationnels (les personnes qui gèrent les logiciels).

Par exemple, en tant que développeur, je veux créer autant de nouvelles fonctionnalités que possible. Après tout, c'est mon travail et c'est ce que les clients exigent !

Cependant, si je suis une personne chargée des opérations, je veux le moins de nouvelles fonctionnalités possible, car chaque nouvelle fonctionnalité est un changement et le changement est risqué.

C'est à la suite de ce désalignement des incitations que le DevOps a vu le jour.

DevOps tente de fusionner le développement et les opérations (DevOps, vous voyez ?) en un seul groupe. L'idée est qu'un seul groupe partagera désormais à la fois la douleur et la responsabilité (et probablement les récompenses) de la création, du déploiement et de la génération de revenus à partir de logiciels orientés vers le client.

Les puristes vous diront qu'il n'existe pas d'"ingénieur DevOps". "DevOps est une culture, pas un rôle", vous diront-ils.

Oui, oui. Ils ont techniquement raison (la pire sorte de raison !), mais comme cela arrive souvent, le terme a évolué au-delà de sa signification originale.

Aujourd'hui, un ingénieur DevOps est en quelque sorte un "ingénieur système 2.0".

En d'autres termes, quelqu'un qui comprend le cycle de vie du développement logiciel et qui apporte des outils et des processus d'ingénierie logicielle pour résoudre les défis opérationnels classiques.

DevOps signifie en fin de compte construire des pipelines numériques qui amènent le code de l'ordinateur portable d'un développeur jusqu'à des prod géniaux générateurs de revenus !

C'est de cela qu'il s'agit !

Notez également qu'en tant que choix de carrière, l'ensemble de l'espace DevOps est très bien rémunéré, la quasi-totalité des entreprises "faisant du DevOps" ou prétendant le faire.

Quelles que soient les entreprises, les opportunités d'emploi DevOps sont nombreuses et offrent des emplois intéressants et intéressants pour les années à venir.

REMARQUE : Méfiez-vous des entreprises qui recrutent une "équipe DevOps" ou un "département DevOps". À proprement parler, de telles choses ne devraient pas exister car, en fin de compte, DevOps est une question de culture et de manière de livrer des logiciels, et non une nouvelle équipe ou un nouveau département à doter en personnel.

Avis de non-responsabilité

Mettons le verre de Kool-Aid de côté pour un moment et considérons ce qui suit.

Avez-vous entendu le vieil adage selon lequel "il n'y a pas d'ingénieurs DevOps juniors" ?

Si ce n'est pas le cas, sachez que c'est un trope populaire sur Reddit et StackOverflow. Mais qu'est-ce que cela signifie ?

En termes simples, cela signifie qu'il faut de nombreuses années d'expérience, combinées à une solide compréhension des outils, pour finalement devenir un praticien DevOps senior vraiment efficace. Et malheureusement, il n'y a pas de raccourci pour l'expérience.

Il ne s'agit donc pas d'une tentative de tricher avec le système - je ne pense pas qu'il soit réellement possible de prétendre être un ingénieur DevOps senior avec quelques mois d'expérience. Une solide compréhension des outils et des méthodologies qui évoluent rapidement prend des années à maîtriser et il n'y a pas d'échappatoire à cela.

Cependant ! Il existe un menu d'outils et de concepts à peu près accepté (à la mode, si vous voulez) que la plupart des entreprises utilisent et c'est ce dont parle cet article !

Encore une fois, les outils sont différents des compétences, donc pendant que vous apprenez les outils, assurez-vous de ne pas négliger vos compétences (entretiens, réseautage, communication écrite, dépannage, etc.)

Plus important encore, ne perdez pas de vue ce que nous recherchons : construire un pipeline numérique entièrement automatisé qui prend des idées et les transforme en morceaux de code générateurs de revenus.

C'est la seule et plus importante leçon à tirer de tout cet article !

Assez parlé, par où commencer ?

Voici votre feuille de route.

Maîtrisez les points suivants et vous pourrez en toute sécurité et en toute honnêteté vous qualifier d'ingénieur DevOps ! Ou ingénieur cloud si vous détestez le titre "DevOps".

La carte ci-dessous représente mon idée (et probablement celle de la majorité des personnes travaillant dans ce domaine) de ce qu'un ingénieur DevOps compétent devrait savoir. Cela dit, il ne s'agit que d'une opinion et il y aura certainement des voix discordantes. Ce n'est pas grave ! Nous ne recherchons pas la perfection ici, mais une base solide sur laquelle construire.

REMARQUE : vous êtes censés parcourir ce document en commençant par le fond, couche par couche. Commencez (et continuez !) par les fondations. Apprenez d'abord les technologies en bleu (Linux|Python|AWS), puis si le temps le permet ou si le marché du travail l'exige, attaquez-vous aux technologies en violet (Golang|Google Cloud).

Encore une fois, il faut s'attaquer à la première couche de chaque pilier. Ensuite, si le temps le permet, attaquez-vous à la deuxième couche pour approfondir votre expertise.

Honnêtement, la couche fondamentale ci-dessus est quelque chose que l'on ne peut jamais cesser d'apprendre. Linux est complexe et il faut des années pour le maîtriser. Python nécessite une pratique continue pour rester à jour. AWS évolue si rapidement que les choses que vous connaissez aujourd'hui ne représenteront qu'une fraction du portefeuille global dans un an.

Mais une fois que vous avez raisonnablement compris la couche de base, passez à l'ensemble des compétences du monde réel. Vous remarquerez qu'il y a 6 colonnes bleues au total, une par mois.

REMARQUE : ce qui manque notablement dans le pipeline ci-dessus, c'est le test. C'est intentionnel - écrire des tests unitaires, d'intégration et d'acceptation n'est pas facile et relève traditionnellement des épaules des développeurs. L'omission de la phase "Test" est intentionnelle, puisque l'objectif de cette feuille de route est l'acquisition rapide de nouvelles compétences et de nouveaux outils. Le manque d'expertise en matière de tests est considéré par l'auteur comme un obstacle insignifiant à un emploi DevOps adéquat. Cela dit, nous couvrirons les tests basés sur les conteneurs dans la section PACKAGE.

N'oubliez pas non plus que notre objectif n'est pas d'apprendre tout un tas d'informations techniques sans rapport avec le sujet. Nous cherchons à acquérir une solide compréhension des outils qui, pris ensemble, racontent une histoire unique et cohérente.

Cette histoire est celle de l'automatisation des processus de bout en bout - un pipeline numérique qui déplace des bits à la manière d'une chaîne de montage.

En outre, vous ne voulez pas apprendre un tas d'outils et vous arrêter là. Les outils évoluent rapidement, les concepts beaucoup moins. C'est pourquoi il faut utiliser les outils comme des substituts d'apprentissage pour les concepts de plus haut niveau.

D'accord, creusons un peu plus !

Connaissances fondamentales

Sous la ligne supérieure intitulée "Foundation", vous verrez les compétences que tout ingénieur DevOps doit maîtriser.

Ici, vous verrez trois piliers dominants de l'industrie : le système d'exploitation, le langage de programmation, le cloud public. Il ne s'agit pas de choses que vous pouvez apprendre très rapidement, les cocher sur la liste et passer à autre chose. Il s'agit de compétences que vous devez acquérir et maintenir à jour en permanence, afin de rester pertinent et à jour par rapport à ce qui se passe.

Passons-les en revue une par une.

Linux : là où tout tourne. Peut-on être un excellent praticien DevOps et rester entièrement dans l'écosystème Microsoft ? Bien sûr que oui ! Aucune loi n'impose l'utilisation de Linux pour tout.

Cependant ! Sachez que si toutes les choses DevOps-y peuvent certainement être faites avec Windows, c'est beaucoup plus douloureux et les opportunités d'emploi sont beaucoup moins nombreuses. Pour l'instant, vous pouvez supposer sans risque que l'on ne peut pas devenir un véritable professionnel du DevOps sans connaître Linux. C'est donc Linux qu'il faut apprendre et continuer à apprendre.

Honnêtement, la meilleure façon de le faire est d'installer Linux (Fedora ou Ubuntu) à la maison et de l'utiliser autant que possible. Vous casserez des choses, vous vous retrouverez bloqué et vous devrez tout réparer et, ce faisant, vous apprendrez Linux !

Par exemple, en Amérique du Nord, les variantes Red Hat sont plus répandues. Il est donc logique de commencer par Fedora ou CentOS. Si vous vous demandez si vous devriez prendre l'édition KDE ou Gnome, prenez KDE. C'est ce qu'utilise Linus Torvalds :)

Python : le langage de base dominant de nos jours. Facile à prendre en main, largement utilisé. Bonus : Python est très répandu dans le domaine de l'intelligence artificielle et de l'apprentissage automatique, donc si vous souhaitez vous orienter vers un autre domaine en vogue, vous serez prêt !

Amazon Web Services : Une fois de plus, il est impossible de devenir un professionnel DevOps chevronné sans une solide compréhension du fonctionnement d'un cloud public. Et si la connaissance d'un nuage est ce que vous recherchez, Amazon Web Services est l'acteur dominant dans cet espace, offrant l'ensemble le plus riche d'outils avec lesquels travailler.

Est-il possible de commencer par Google Cloud ou Azure ? Absolument ! Mais comme nous recherchons le meilleur rapport qualité-prix, AWS est l'option la plus sûre, du moins en 2018.

Vous obtenez un niveau gratuit pour jouer avec lorsque vous vous inscrivez pour un compte chez AWS, c'est donc un bon point de départ.

Maintenant, lorsque vous vous connectez à la console AWS, vous êtes accueilli par un menu de choix simple et facile à comprendre.

C'était un sarcasme. La bonne nouvelle, c'est que vous n'avez pas besoin de connaître toutes les techniques d'Amazon.

Commencez par les éléments suivants : VPC, EC2, IAM, S3, CloudWatch, ELB (sous l'égide d'EC2) et les groupes de sécurité. Ces éléments sont suffisants pour vous permettre de démarrer, et toute entreprise moderne utilisant l'informatique dématérialisée se servira largement de ces outils.

Le site web de formation d'AWS est un bon point de départ.

Je vous recommande de consacrer 20 à 30 minutes par jour à la pratique de Python, de Linux et d'AWS.

REMARQUE : cela s'ajoutera à toutes les autres choses que vous devrez apprendre. Au total, j'estime qu'une heure par jour, cinq fois par semaine, est suffisante pour vous donner une solide compréhension de ce qui se passe dans l'espace DevOps en 6 mois ou moins.

De même, il y a 6 piliers principaux au total, chacun correspondant à un mois d'apprentissage.

C'est tout pour la couche fondamentale !

Dans les articles suivants, nous explorerons le niveau de complexité suivant : comment passer des idées à la production de manière entièrement automatisée !

How To Become a DevOps Engineer In Six Months or Less

Introduction

MediumIgor Kantor

Partie 2

Récapitulation rapide

Dans la section précédente, j'ai expliqué que le travail de DevOps / Cloud Engineering consiste à construire des pipelines numériques entièrement automatisés qui font passer le code de la machine d'un développeur à la production.

Maintenant, pour faire ce travail efficacement, il faut une solide compréhension des principes fondamentaux, décrits ici :

ainsi qu'une bonne compréhension des outils et des compétences (voir le graphique suivant) qui s'appuient sur ces principes fondamentaux.

Petit rappel : votre objectif est d'apprendre d'abord les choses en bleu, de gauche à droite, puis les choses en violet, de gauche à droite. Il y a au total 6 piliers d'apprentissage, un par mois.

Bon, revenons à notre sujet. Dans cet article, nous allons aborder la première étape de notre pipeline numérique : La mise à disposition.

Vue d'ensemble

Que se passe-t-il lors de l'étape Provision ?

Étant donné que le code que nous créons a besoin de machines pour s'exécuter, l'étape de configuration permet de construire l'infrastructure qui exécute notre code.

Dans le passé, l'approvisionnement de l'infrastructure était une épreuve longue, laborieuse et sujette aux erreurs.

Aujourd'hui, grâce à notre formidable nuage, tout le provisionnement peut se faire en un clic. Ou, du moins, de nombreux clics.

Cependant, il s'avère que cliquer sur des boutons pour accomplir ces tâches est une mauvaise idée.

Pourquoi ?

Parce que cliquer sur un bouton est

• sujet à l'erreur (les humains font des erreurs),
• n'est pas versionné (les clics ne peuvent pas être stockés dans git),
• non reproductible (plus de machines = plus de clics),
• et non testable (aucune idée si mes clics vont réellement fonctionner ou s'ils vont tout gâcher).

Par exemple, pensez à tout le travail nécessaire pour provisionner votre environnement de développement... puis l'environnement int... puis QA... puis staging... puis prod aux USA... puis prod dans l'UE... Cela devient très fastidieux, très ennuyeux, très rapidement.

C'est pourquoi une nouvelle méthode est nécessaire. Cette nouvelle méthode est l'infrastructure en tant que code et c'est ce dont il est question dans cette phase de provision.

En tant que meilleure pratique, l'infrastructure en tant que code impose que tout le travail nécessaire à l'approvisionnement en ressources informatiques soit effectué uniquement par le biais du code.

REMARQUE : par "ressources informatiques", j'entends tout ce qui est nécessaire pour faire fonctionner correctement une application en prod : calcul, stockage, réseau, bases de données, etc. D'où le nom d'"infrastructure en tant que code".

De plus, cela signifie qu'au lieu de cliquer pour déployer notre infrastructure, nous allons plutôt

• rédiger l'état de l'infrastructure souhaité dans Terraform,
• le stocker dans notre système de contrôle du code source,
• passer par un processus formel de demande d'extraction pour solliciter un retour d'information,
• le tester,
• exécuter pour provisionner toutes les ressources nécessaires.

Pourquoi ceci et pas cela ?

La question qui se pose est la suivante : "Pourquoi Terraform ? Pourquoi pas Chef ou Puppet ou Ansible ou CFEngine ou Salt ou CloudFormation ou ${whatever} ?"

Bonne question ! Des barils d'encre virtuelle ont été déversés pour débattre de cette question.

En résumé, je pense que vous devriez apprendre Terraform pour les raisons suivantes

• Il est très à la mode, donc les opportunités d'emploi sont nombreuses
• Il est un peu plus facile à apprendre que d'autres
• Il est multiplateforme

Maintenant, pouvez-vous choisir l'un des autres et réussir quand même ? Absolument !

NOTE SECONDAIRE : cet espace évolue rapidement et est assez déroutant. J'aimerais prendre quelques minutes pour parler de l'histoire récente et de la façon dont je vois les choses évoluer.

Traditionnellement, des outils comme Terraform et CloudFormation ont été utilisés pour provisionner l'infrastructure, tandis que des outils comme Ansible sont utilisés pour la configurer.

On peut considérer Terraform comme un outil permettant de créer des fondations, Ansible comme un outil permettant de poser la maison sur le toit, puis l'application est déployée comme on le souhaite (cela peut être aussi Ansible, par exemple).

En d'autres termes, vous créez vos VM avec Terraform et utilisez ensuite Ansible pour configurer les serveurs, ainsi que pour déployer potentiellement vos applications.

Traditionnellement ( !), c'est ainsi que ces choses fonctionnent ensemble.

Cependant, Ansible peut faire beaucoup (sinon tout) de ce que Terraform peut faire. L'inverse est également vrai.

Que cela ne vous dérange pas. Sachez simplement que Terraform est l'un des acteurs les plus dominants dans le domaine de l'infrastructure en tant que code, et je vous recommande donc vivement de commencer par là.

En fait, l'expertise Terraform+AWS est l'un des ensembles de compétences les plus recherchés en ce moment !

Cependant, si vous décidez d'abandonner Ansible au profit de Terraform, vous devez tout de même savoir comment configurer un grand nombre de serveurs de manière programmatique, n'est-ce pas ?

Ce n'est pas forcément le cas !

Déploiements immuables

En fait, je prédis que les outils de gestion de configuration comme Ansible vont perdre de leur importance, tandis que les outils de provisionnement d'infrastructure comme Terraform ou CloudFormation vont gagner en importance.

Pourquoi ?

À cause de ce qu'on appelle les "déploiements immuables".

En termes simples, les déploiements immuables font référence à la pratique consistant à ne jamais modifier l'infrastructure déployée. En d'autres termes, votre unité de déploiement est une VM ou un conteneur Docker, et non un morceau de code.

Ainsi, vous ne déployez pas de code sur un ensemble de machines virtuelles statiques, vous déployez des VM entières, avec le code déjà intégré.

Vous ne changez pas la configuration des machines virtuelles, vous déployez de nouvelles machines virtuelles avec la configuration souhaitée en place.

Vous ne corrigez pas les machines de production, vous déployez de nouvelles machines, déjà corrigées.

Vous n'exécutez pas un ensemble de VM dans dev et un autre ensemble de VM dans prod, ils sont tous les mêmes.

En fait, vous pouvez en toute sécurité désactiver tout accès SSH à toutes les machines de prod parce qu'il n'y a rien à y faire - pas de paramètres à changer, pas de journaux à consulter (plus de détails sur les journaux plus tard).

Vous voyez où je veux en venir.

Lorsqu'il est utilisé correctement, ce modèle est très puissant et je le recommande vivement !

NOTE : Les déploiements immuables exigent que la configuration soit séparée de votre code. Veuillez lire le manifeste 12 Factor App qui détaille cela (et d'autres idées géniales !) de manière très détaillée. Il s'agit d'une lecture incontournable pour les praticiens DevOps.

Le découplage du code et de la configuration est très important - vous ne voulez pas redéployer toute la pile d'applications chaque fois que vous changez les mots de passe de votre base de données. Au lieu de cela, assurez-vous que les applications le tirent d'un magasin de configuration externe (SSM/Consul/etc.).

De plus, vous pouvez facilement voir comment, étant donné la montée des déploiements immuables, des outils comme Ansible commencent à jouer un rôle moins important.

En effet, vous n'avez besoin de configurer qu'un seul serveur et de le déployer un grand nombre de fois dans le cadre de votre groupe de mise à l'échelle automatique.

Ou, si vous utilisez des conteneurs, vous voulez absolument des déploiements immuables presque par définition. Vous ne voulez pas que votre conteneur de développement soit différent de votre conteneur d'assurance qualité et que celui-ci soit différent de votre conteneur de production.

Vous voulez exactement le même conteneur dans tous vos environnements. Cela évite les dérives de configuration et simplifie les retours en arrière en cas de problème.

Les conteneurs mis à part, pour les personnes qui débutent, le provisionnement de l'infrastructure AWS à l'aide de Terraform est un modèle DevOps classique et quelque chose que vous devez vraiment maîtriser.

Mais attendez... et si j'ai besoin de consulter les journaux pour résoudre un problème ? Eh bien, vous ne vous connecterez plus aux machines pour consulter les journaux, mais vous consulterez l'infrastructure de journalisation centralisée pour tous vos journaux.

Encore une fois, vous pouvez désactiver complètement l'accès à distance et vous sentir plus en sécurité que la plupart des gens !

En résumé, notre parcours "DevOps" entièrement automatisé commence par le provisionnement des ressources informatiques nécessaires à l'exécution de notre code - étape de provisionnement. Et la meilleure façon d'y parvenir est de procéder à des déploiements immuables.

Enfin, si vous êtes curieux de savoir par où commencer exactement, le combo Terraform+AWS est un bon point de départ !

C'est tout pour l'étape "Provision".

How To Become a DevOps Engineer In Six Months or Less, Part 2: Configure

Month 1

MediumIgor Kantor

Partie 3

Récapitulation rapide

Récapitulons rapidement où nous en sommes.

En bref, cette série de billets raconte une histoire.

Et cette histoire consiste à apprendre comment prendre une idée et la transformer en argent, aussi rapidement que possible - l'essence même du mouvement DevOps moderne.

Ou, plus précisément, comment construire un pipeline de création de valeur numérique entièrement automatisé.

Dans Intro, nous avons parlé de la culture et des objectifs DevOps.

Dans la première partie, nous avons expliqué comment poser les bases des futurs déploiements de code avec Terraform. Bien sûr, Terraform, c'est aussi du code !

Par conséquent, dans ce billet, nous allons discuter de la façon d'empêcher tous ces morceaux de code de se détraquer complètement. En gros, il s'agit de git !

Bonus : nous parlerons aussi de la façon d'utiliser cette affaire de git pour construire et promouvoir votre propre marque personnelle.

Pour référence, nous sommes dans la partie Version de notre voyage :

Pourquoi s'en préoccuper ?

Lorsque nous parlons de "version", que voulons-nous dire ?

Imaginez que vous travaillez sur un logiciel. Vous y apportez constamment des modifications, en ajoutant ou en supprimant des fonctionnalités selon les besoins. Souvent, la dernière modification est une "rupture". En d'autres termes, ce que vous avez fait en dernier a cassé ce qui fonctionnait avant.

Et maintenant, que se passe-t-il ?

Et bien... Si vous êtes vraiment de la vieille école, vous avez probablement eu tendance à nommer votre premier fichier comme ceci.

awesome_code.pl

Vous commencez alors à apporter des modifications et vous devez conserver ce qui fonctionne, au cas où vous devriez y revenir.

Vous renommez donc votre fichier comme suit :

awesome_code.12.25.2022.pl

Et cela fonctionne bien. Jusqu'au jour où vous effectuez plus d'une modification par jour, ce qui donne ce résultat :

awesome_code.GOOD.12.25.2022.pl

Et ainsi de suite.

Bien entendu, dans un environnement professionnel, plusieurs équipes collaborent sur la même base de code, ce qui brise encore plus ce modèle.

Inutile de dire que ce train fou déraille rapidement.

Contrôle du code source

Voici le contrôle du code source : un moyen de conserver vos fichiers dans un endroit centralisé, où plusieurs équipes peuvent travailler ensemble sur une base de code commune.

L'idée n'est pas nouvelle. La première mention d'une telle chose que j'ai pu trouver remonte à 1972 ! L'idée de centraliser notre code en un seul endroit est donc tout à fait ancienne.

Ce qui est relativement nouveau, en revanche, c'est l'idée que tous les artefacts de production doivent être versionnés.

Qu'est-ce que cela signifie ?

Cela signifie que tout ce qui touche à votre environnement de production doit être stocké dans un système de contrôle des versions, soumis au suivi, à la révision et à l'historique des modifications.

De plus, l'application de la loi "tous les artefacts de production doivent être versionnés" vous oblige vraiment à aborder les problèmes avec l'état d'esprit "automatisation d'abord".

Par exemple, lorsque vous décidez de cliquer pour résoudre un problème complexe dans votre environnement Dev AWS, vous pouvez faire une pause et vous demander si tous ces clics constituent un artefact versionné.

Bien sûr, la réponse est "non". Ainsi, bien qu'il soit acceptable de réaliser des prototypes rapides via l'interface utilisateur pour voir si quelque chose fonctionne ou non, ces efforts doivent vraiment être de courte durée. À plus long terme, assurez-vous de tout faire avec Terraform ou un autre outil d'infrastructure en tant que code.

OK, donc si tout est un artefact versionné, comment stocker et gérer ces choses, exactement ?

La réponse est git.

Git

Jusqu'à l'arrivée de git, l'utilisation de systèmes de contrôle de code source comme SVN ou d'autres systèmes était compliquée, peu conviviale et en général une expérience assez pénible.

Ce que git fait différemment, c'est qu'il adopte la notion de contrôle distribué du code source.

En d'autres termes, vous n'excluez pas les autres personnes d'un dépôt de code source centralisé pendant que vous travaillez sur vos modifications. Au contraire, vous travaillez sur une copie complète de la base de code. Cette copie est ensuite fusionnée dans le dépôt principal.

Gardez à l'esprit que ce qui précède est une simplification excessive du fonctionnement de git. Mais c'est suffisant pour les besoins de cet article, même si connaître le fonctionnement interne de git est à la fois précieux et prend un certain temps à maîtriser.

Pour l'instant, il suffit de se rappeler que git n'est pas comme le SVN d'autrefois. Il s'agit d'un système de contrôle de code source distribué, où plusieurs équipes peuvent travailler sur une base de code partagée en toute sécurité.

Pourquoi s'en préoccuper ?

Plus précisément, je dirais que vous ne pouvez pas devenir un ingénieur DevOps (Cloud) professionnel sans savoir comment fonctionne git. C'est aussi simple que cela.

D'accord, mais comment apprend-on git, exactement ?

Je dois dire que la recherche sur Google d'un "tutoriel git" a la particularité douteuse d'aboutir à des tutoriels extrêmement complets et extrêmement confus.

Cependant, il y en a quelques-uns qui sont vraiment, vraiment bons.

L'une de ces séries de tutoriels que je conseille vivement à tout le monde de lire, d'apprendre et de pratiquer est celle des tutoriels Git d'Atlassian.

En fait, ils sont tous très bons, mais une section en particulier est utilisée par les ingénieurs logiciels professionnels du monde entier : Git Workflows.

Un autre très bon tutoriel est Learn Git Branching.

Les tutoriels Atlassian se contentent de lire et d'apprendre (si c'est votre truc) tandis que Learn Git Branching est un tutoriel interactif (si c'est votre truc).

Quoi qu'il en soit, vous n'irez pas loin dans ce domaine si vous ne comprenez pas comment fonctionne Git !

Je n'insisterai jamais assez sur ce point. Encore et encore, le manque de compréhension du fonctionnement du branchement des fonctionnalités de git ou l'incapacité à expliquer GitLab Flow est ce qui fait couler 99% des candidatures des aspirants ingénieurs DevOps.

Il s'agit là d'un point essentiel. Vous pouvez vous présenter à un entretien sans connaître Terraform ou le dernier outil d'infrastructure en tant que code à la mode, et ce n'est pas grave - on peut l'apprendre sur le tas.

Mais ne pas connaître git et son fonctionnement est le signe que vous ne maîtrisez pas les fondamentaux des meilleures pratiques de l'ingénierie logicielle moderne, DevOps ou non. Cela signale aux responsables de l'embauche que votre courbe d'apprentissage sera très raide. Vous ne voulez pas signaler cela !

À l'inverse, votre capacité à parler avec assurance des meilleures pratiques de git indique aux responsables du recrutement que vous venez d'abord avec un état d'esprit d'ingénieur logiciel - exactement le genre d'image que vous voulez projeter.

Pour résumer : vous n'avez pas besoin de devenir le plus grand expert mondial de git pour décrocher ce poste génial de DevOps, mais vous devez vivre et respirer git pendant un certain temps pour être capable de parler en toute confiance de ce qui se passe.

• Au minimum, vous devez savoir comment
• Créer un repo (Fork)
• Créer des branches
• Fusionner les changements en amont et en aval
• Créer des demandes d'extraction (Pull Requests)
• Approuver les demandes de retrait

Et maintenant ?

Une fois que vous avez terminé les tutoriels d'introduction à Git, ouvrez un compte GitHub.

NOTE : GitLab est également OK, mais au moment de la rédaction de cet article, GitHub est le dépôt git open source le plus répandu, donc vous voulez être là où tout le monde est.

Une fois que vous avez votre compte GitHub, commencez à y contribuer avec votre code ! Quoi que vous appreniez qui vous oblige à écrire du code, assurez-vous de le publier régulièrement sur GitHub.

Cela permet non seulement d'inculquer une bonne discipline en matière de contrôle du code source, mais aussi de construire votre propre marque personnelle.

NOTE : lorsque vous apprenez à utiliser git+GitHub, portez une attention particulière aux Pull Requests (ou PRs, si vous voulez être cool).

La marque

En parlant de cool, une marque est un moyen de montrer au monde entier ce dont vous êtes capable.

L'un des moyens (actuellement, l'un des meilleurs moyens !) est d'établir une solide présence sur GitHub comme indicateur de votre marque. De nos jours, presque tous les employeurs vous demanderont de toute façon d'en avoir un.

Par conséquent, vous devriez vous efforcer d'avoir un compte GitHub soigné, soigneusement entretenu - quelque chose que vous pouvez mettre sur votre CV et dont vous pouvez être fier.

Dans les sections suivantes, nous verrons comment construire un site web simple mais sympa sur GitHub en utilisant le framework Hugo. Pour l'instant, il suffit de mettre votre code sur GitHub.

Plus tard, lorsque vous serez plus expérimenté, vous pourrez envisager d'avoir deux comptes GitHub. Un pour vos affaires personnelles que vous utilisez pour stocker le code pratique que vous écrivez et un autre compte pour stocker le code que vous voulez montrer aux autres.

En résumé :

• Apprenez git
• Contribuez à tout ce que vous avez appris sur GitHub
• Tirez parti des points 1 et 2 pour présenter toutes les choses que vous avez apprises jusqu'à présent.
• Profitez-en !

Dernières réflexions

Enfin, gardez à l'esprit les derniers développements dans ce domaine, tels que GitOps.GitOps porte toutes les idées dont nous avons discuté jusqu'à présent à de nouveaux niveaux - où tout est fait via git, pull requests, et les pipelines de déploiement.

Notez que GitOps et les approches similaires s'adressent à l'aspect commercial des choses. Plus précisément, nous n'utilisons pas des outils complexes comme git parce qu'ils sont cool.

Nous utilisons plutôt git pour favoriser l'agilité de l'entreprise, accélérer l'innovation et livrer des fonctionnalités plus rapidement - ce sont des choses qui permettent à notre entreprise de gagner plus d'argent au final !C'est tout pour l'instant !

How To Become a DevOps Engineer In Six Months or Less, Part 3: Version

Month 2

MediumIgor Kantor