🏴󠁧󠁢󠁷󠁬󠁳󠁿 👨🏼‍🌾 🧖🏽 Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 3. Versions 🔓 🕺 🤹🏼

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 1. Introduction
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 2. Configuration

Rafraîchissez la mémoire

Dans la première partie, nous avons parlé de la culture et des objectifs de DevOps, dans la seconde - comment jeter les bases de futurs déploiements de code à l'aide de Terraform, qui est lui-même du code. Dans la troisième partie, nous verrons comment sauvegarder toutes ces parties du code d'un désordre complet. Spoiler: Tout tourne autour de Git!

Bonus: nous parlerons également de la façon d'utiliser ce même Git pour créer et promouvoir votre propre marque personnelle. L'image montre où nous en sommes maintenant.

Pourquoi s'embêter avec ça?

Qu'entend-on par versionnage? Imaginez que vous travaillez sur une sorte de logiciel et que vous y apportez constamment des modifications, en ajoutant ou supprimant des fonctions selon vos besoins. Souvent, le dernier changement sera un changement fondamental, brisant tout ce qui a été créé plus tôt. Si vous êtes un représentant d'une ancienne école, vous nommerez probablement votre premier fichier awesome_code.p1.

Ensuite, vous commencez à apporter des modifications et vous devez enregistrer ce qui fonctionne, au cas où vous devriez y revenir. Par conséquent, vous renommez votre fichier en ceci: awesome_code.12.25.2018.p1.

Tout fonctionne bien jusqu'à ce que, le même jour, vous apportiez quelques modifications et que vous deviez nommer le nouveau fichier awesome_code.GOOD.12.25.2018.p1. Et continuez votre bon travail.

Très probablement, dans un environnement professionnel, vous avez plusieurs équipes collaborant dans la même base de code, ce qui viole davantage ce modèle. Inutile de dire que ce train fou déraille rapidement.

Système de contrôle de version de contrôle de code source

Utilisez le système de contrôle de version SCC - c'est un moyen de stocker vos fichiers dans un endroit centralisé où plusieurs équipes peuvent travailler ensemble sur une base de code commune. Cette idée n'est pas nouvelle. La première mention du système SCC que j'ai réussi à trouver remonte à 1972. Ainsi, l'idée que nous devrions centraliser notre code en un seul endroit est définitivement dépassée.

Cependant, l'idée que tous les artefacts produits devraient être versionnés est relativement nouvelle. Cela signifie que tout ce qui concerne votre environnement de production doit être stocké dans le système de contrôle de version, sous réserve de suivi, de vérification et d'enregistrement de l'historique des modifications.

De plus, l'application de la loi «tous les artefacts prod doivent être versionnés» vous fait vraiment aborder les problèmes par le principe de «l'automatisation d'abord».

Par exemple, lorsque vous décidez de simplement cliquer sur un problème complexe dans votre environnement de développement AWS, vous pouvez faire une pause et penser: «est-ce un clic sur un artefact versionné»? Bien sûr, la réponse sera «non».

Bien qu'il soit normal de réaliser des prototypes rapides via l'interface utilisateur pour voir si quelque chose fonctionne ou non, votre travail sera de courte durée. Par conséquent, lorsque vous effectuez un travail prometteur et long, assurez-vous de le faire dans Terraform ou dans un autre outil d'infrastructure en tant que code. N'oubliez pas que vous devez gérer les artefacts versionnés et les stocker à l'aide du référentiel Git.

Dépôt Git

Avant Git, l'utilisation de SCCS tels que SVN était maladroite, peu conviviale et généralement une expérience plutôt douloureuse. La différence avec Git est qu'il fournit un contrôle de version distribué. Autrement dit, vous ne bloquez pas les autres utilisateurs du référentiel de code source centralisé pendant que vous travaillez sur vos modifications, mais vous travaillez avec une copie complète de la base de code. Une fois votre travail terminé, cette copie sera intégrée au référentiel maître.

Gardez à l'esprit que ce qui précède est une simplification grossière de la façon dont cela fonctionne. Une telle description suffit aux fins de cet article, cependant, une connaissance détaillée de Git est une expérience laborieuse mais enrichissante.

Pour l'instant, rappelez-vous simplement que Git ne fonctionne pas comme SVN. Il s'agit d'un système de gestion de code source distribué (version) dans lequel plusieurs équipes de développement peuvent travailler en toute sécurité et de manière fiable sur une base de code commune.

Pourquoi avez-vous besoin de savoir cela?

J'affirme fermement que sans savoir comment fonctionne Git, vous ne deviendrez jamais un ingénieur DevOps (Cloud) professionnel. Comment l'étudier? Notez qu'un résultat de recherche Google pour «Git Tutorial» fournit généralement des liens vers des didacticiels extrêmement gonflés et déroutants. Néanmoins, certains manuels vraiment sensés se retrouvent parmi eux.

Une telle série de didacticiels que je recommande à tout le monde de lire, d'étudier et d'utiliser dans la pratique est les didacticiels Git d'Atlassian . Ils sont tous assez bons, mais une section, Git Workflows , qui décrit les flux de travail de ce référentiel, est utilisée par des programmeurs professionnels du monde entier.

Un autre très bon didacticiel explore la création de branches du référentiel Learn Git Branching. Les didacticiels Atlassian reposent sur le principe «lire et apprendre» et Learn Git Branching est un didacticiel interactif. Dans tous les cas, vous n'irez pas loin dans l'apprentissage de DevOps à moins de comprendre comment ce référentiel fonctionne.

Je note qu'un manque de compréhension du fonctionnement de la fonction Git Branching ou une incapacité à expliquer ce qu'est Gitflow, se noie lors d'un entretien de 99% des candidats à la candidature d'ingénieur de développement DevOps. C'est le point clé - vous pouvez venir pour un entretien et ne pas connaître Terraform ou tout autre outil d'infrastructure en tant que code à la mode, et c'est normal, car vous pouvez l'étudier dans le processus. Mais l'ignorance du travail de Git indique que vous n'avez pas les bases des meilleures pratiques modernes en développement logiciel, peu importe qu'il s'agisse de DevOps ou non. Cela signale aux responsables du recrutement que votre courbe d'apprentissage est trop inégale.

À l'inverse, votre capacité à parler en toute confiance des meilleures pratiques de Git indique aux responsables du recrutement que vous avez proposé l'installation pour effectuer le développement logiciel en premier, et c'est exactement l'image que vous souhaitez projeter. Conclusion: vous n'avez pas besoin de devenir le meilleur expert Git au monde pour obtenir ce travail DevOps génial, mais vous devez vivre et respirer Git pendant un certain temps pour parler en toute confiance de ce qui lui arrive. Pour ce faire, au minimum, vous devez avoir une bonne compréhension de la façon de procéder comme suit:

créer une copie du référentiel (Fork a repo);
Créer une branche Git
synchroniser le flux avec le référentiel et vice versa;
créer une demande de tirage.

Et après?

Une fois que vous avez appris les leçons d'introduction dans Git, créez-vous un compte sur GitHub. C'est le référentiel Git open source le plus courant, et vous voudrez probablement être avec le reste des abonnés de Git.

Dès que vous avez votre compte sur GitHub, commencez à y entrer votre code. Corrigez tout ce qui vous oblige à écrire du code dans le processus de travail sur GitHub. Cela inculque non seulement une bonne discipline dans la gestion des versions, mais vous aide également à créer votre propre marque.

Remarque: lorsque vous explorez l'utilisation de git + GitHub, faites particulièrement attention à Pull Request (ou PR si vous voulez être cool).

La marque

En parlant de raideur: sa propre marque est un moyen de démontrer au monde ce dont vous êtes capable. Une façon (actuellement c'est l'une des meilleures façons!) Est de lier fermement GitHub en tant que proxy pour votre marque. De nos jours, presque tous les employeurs le demanderont d'une manière ou d'une autre. Par conséquent, vous devez vous efforcer d'avoir un compte GitHub soigné et soigneusement supervisé. C'est quelque chose que vous pouvez mettre sur votre CV et dont vous pouvez être fier.

Dans les articles suivants, je vais vous montrer comment créer un site simple mais sympa sur GitHub à l'aide du générateur de site statique Hugo. Il est écrit en Go et, peut-être, est aujourd'hui le plus rapide parmi les analogues. Hugo rassemble environ 5 000 pages en 6 secondes, soit 75 fois la vitesse de Middleman. Mais pour l'instant, il vous suffit de mettre votre code sur GitHub.
Plus tard, lorsque vous acquérez de l'expérience, il vaut la peine de penser à avoir deux comptes GitHub. L'un pour stocker votre propre application écrite, votre code de travail et l'autre pour stocker le code que vous souhaitez montrer aux autres.

Donc, nous résumons ce qui précède:

apprendre git;
Publiez sur GitHub tout ce que vous apprenez
utilisez deux comptes pour stocker et démontrer tout ce que vous avez appris
pour en bénéficier!

résultats

Restez à jour avec les derniers développements dans ce domaine, tels que GitOps. GitOps prend toutes les idées que nous avons discutées jusqu'à présent à un nouveau niveau, où tout se fait à l'aide de git, de pull pulls et de pipelines de déploiement.

Veuillez noter que GitOps et les développements similaires parlent du côté commercial des choses, c'est-à-dire qu'ils n'indiquent pas que Git, car il est cool et à la mode. Vous l'utilisez pour assurer l'agilité de votre entreprise, accélérer l'innovation et fournir des fonctions plus rapides, c'est-à-dire pour finalement gagner plus d'argent!

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 4. Packaging logiciel

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 3. Versions