So werden Sie in maximal sechs Monaten DevOps-Ingenieur, Teil 3: Version

„Nahaufnahme einer beleuchteten Laptoptastatur“ von Markus Petritz bei Unsplash

Kurzzusammenfassung

Lassen Sie uns kurz rekapitulieren, wo wir sind.

Kurz gesagt, diese Postserie erzählt eine Geschichte.

Und diese Geschichte lernt, wie man eine Idee so schnell wie möglich in Geld verwandelt - die Essenz der modernen DevOps-Bewegung.

Konkret haben wir in Teil 1 über die DevOps-Kultur und -Ziele gesprochen.

In Teil 2 haben wir darüber gesprochen, wie der Grundstein für zukünftige Code-Bereitstellungen mit Terraform gelegt werden kann. Natürlich ist Terraform auch Code!

Folglich werden wir in diesem Beitrag diskutieren, wie all diese Codeteile nicht komplett durcheinandergebracht werden können. Spoiler, es geht nur um Schwachsinn!

Bonus: Wir werden auch darüber sprechen, wie Sie mit diesem Git-Geschäft Ihre eigene Marke aufbauen und fördern können.

Als Referenz sind wir hier auf unserer Reise:

DevOps-Reise

Warum die Mühe?

Wenn wir von „Versionierung“ sprechen, was meinen wir dann?

Stellen Sie sich vor, Sie arbeiten an einer Software. Sie nehmen ständig Änderungen daran vor und fügen nach Bedarf Funktionen hinzu oder entfernen sie. Häufig ist die letzte Änderung eine "brechende" Änderung. Mit anderen Worten, was auch immer Sie zuletzt getan haben, hat alles kaputt gemacht, was Sie zuvor gearbeitet haben.

Was jetzt?

Gut. Wenn Sie wirklich Old School sind, hatten Sie wahrscheinlich die Tendenz, Ihre erste Datei folgendermaßen zu benennen:

awesome_code.pl

Dann nehmen Sie Änderungen vor und müssen beibehalten, was funktioniert, falls Sie zurückkehren müssen.

Also benennen Sie Ihre Datei folgendermaßen um:

awesome_code.12.25.2018.pl

Und das funktioniert gut. Bis zu einem Tag nehmen Sie mehr als eine Änderung pro Tag vor.

awesome_code.GOOD.12.25.2018.pl

Und so weiter.

Natürlich arbeiten in einer professionellen Umgebung mehrere Teams auf derselben Codebasis zusammen, was dieses Modell noch weiter verschlechtert.

Natürlich entgleist dieser verrückte Zug schnell.

Quellcodeverwaltung

Enter Source Code Control: Eine Möglichkeit, Ihre Dateien an einem zentralen Ort zu speichern, an dem mehrere Teams auf einer gemeinsamen Codebasis zusammenarbeiten können.

Nun ist diese Idee nicht neu. Die früheste Erwähnung von etwas, das ich finden konnte, stammt aus dem Jahr 1972! Die Idee, dass wir unseren Code an einem Ort zentralisieren sollten, ist definitiv alt.

Relativ neu ist jedoch die Idee, dass alle Produktionsartefakte versioniert werden müssen.

Was bedeutet das?

Dies bedeutet, dass alles, was Ihre Produktionsumgebung berührt, in der Versionskontrolle gespeichert werden muss, vorbehaltlich der Verfolgung, Überprüfung und des Änderungsverlaufs.

Darüber hinaus zwingt die Durchsetzung des Gesetzes „Alle Produkte müssen versioniert werden“ Sie wirklich dazu, Probleme mit der Einstellung „Automatisierung zuerst“ anzugehen.

Wenn Sie sich zum Beispiel dazu entschließen, sich durch ein komplexes Problem in Ihrer Dev AWS-Umgebung zu klicken, können Sie innehalten und überlegen: "Klicken Sie auf ein versioniertes Artefakt?"

Die Antwort lautet natürlich "nein". Obwohl es in Ordnung ist, schnelle Prototypen über die Benutzeroberfläche zu erstellen, um festzustellen, ob etwas funktioniert oder nicht, müssen diese Bemühungen wirklich nur von kurzer Dauer sein. Stellen Sie auf längere Sicht sicher, dass Sie alles in Terraform oder einem anderen Infrastruktur-as-Code-Tool erledigen.

OK, wenn alles ein versioniertes Artefakt ist, wie speichern und verwalten wir diese Dinge genau?

Die Antwort ist git.

Git

Bis GIT kam, war die Verwendung von Quellcode-Kontrollsystemen wie SVN oder anderen klobig, nicht benutzerfreundlich und im Allgemeinen eine ziemlich schmerzhafte Erfahrung.

Was git anders macht, ist, dass es sich um eine verteilte Quellcodeverwaltung handelt.

Mit anderen Worten, Sie sperren andere Personen nicht aus einem zentralen Quellcode-Repository aus, während Sie an Ihren Änderungen arbeiten. Stattdessen arbeiten Sie an einer vollständigen Kopie der Codebasis. Diese Kopie wird dann in das Master-Repository eingefügt.

Denken Sie daran, obiges ist eine grobe Vereinfachung der Funktionsweise von Git. Für die Zwecke dieses Artikels ist es jedoch ausreichend, auch wenn die Kenntnis der inneren Funktionsweise von git sowohl wertvoll ist als auch einige Zeit in Anspruch nimmt, um sie zu beherrschen.

https://xkcd.com/1597/

Denken Sie vorerst daran, dass Git nicht wie SVN von früher ist. Es ist ein verteiltes Quellcode-Kontrollsystem, bei dem mehrere Teams sicher und sicher an einer gemeinsamen Codebasis arbeiten können.

Warum die Mühe?

Insbesondere würde ich stark argumentieren, dass Sie kein professioneller DevOps (Cloud) Ingenieur werden können, ohne zu wissen, wie git funktioniert. So einfach ist das.

OK, wie lernt man git genau?

Ich muss sagen, Googeln für ein "Git-Tutorial" hat den zweifelhaften Unterschied, dass es extrem umfassende und äußerst verwirrende Tutorials gibt.

Es gibt jedoch einige, die wirklich sehr, sehr gut sind.

Eine solche Reihe von Tutorials, mit denen ich jeden zum Lesen, Lernen und Üben auffordern möchte, sind Atlassians Git-Tutorials.

Tatsächlich sind sie alle ziemlich gut, aber in einem bestimmten Bereich werden sie von professionellen Software-Ingenieuren auf der ganzen Welt verwendet: Git Workflows.

Ein weiteres wirklich gutes Tutorial ist Learn Git Branching.

In Atlassian-Tutorials wird nur gelesen und gelernt (wenn Sie es mögen), während Learn Git Branching ein interaktives Tutorial ist (wenn Sie es mögen).

Egal, Sie werden in diesem Geschäft nicht weit kommen, wenn Sie nicht verstehen, wie git funktioniert!

Ich kann das nicht genug betonen. Immer wieder sinken 99% der angehenden DevOps-Ingenieure aufgrund mangelnden Verständnisses für die Funktionsweise der Verzweigung von Git-Features oder mangelnder Erklärung von Gitflow.

Dies ist ein wichtiger Punkt. Sie können zu einem Vorstellungsgespräch kommen und wissen nicht, was Terraform oder das neueste trendige Infrastruktur-als-Code-Tool ist, und das ist in Ordnung - man kann es im Job lernen.

Wenn Sie jedoch git und seine Funktionsweise nicht kennen, ist dies ein Signal dafür, dass Ihnen die Grundlagen moderner Best Practices für das Software-Engineering fehlen (DevOps oder nicht). Dies signalisiert den angestellten Managern, dass Ihre Lernkurve sehr steil sein wird. Das wollen Sie nicht signalisieren!

Umgekehrt sagt Ihre Fähigkeit, sicher über bewährte Vorgehensweisen für Git zu sprechen, den Einstellungsmanagern, dass Sie zuerst eine Einstellung für Software-Engineering haben - genau die Art von Image, das Sie projizieren möchten.

Zusammenfassend: Sie müssen nicht der weltweit führende Git-Experte sein, um diese großartige DevOps-Rolle zu erlangen, aber Sie müssen eine Weile leben und atmen, um sicher darüber sprechen zu können, was los ist.

Zumindest sollten Sie sich gut auskennen

  1. Gabeln Sie ein Repo
  2. Erstellen Sie Zweige
  3. Änderungen aus dem Upstream und dem Backstream zusammenführen
  4. Pull-Anfragen erstellen

Was jetzt?

Sobald Sie die einführenden Git-Tutorials durchlaufen haben, können Sie sich einen GitHub-Account erstellen.

HINWEIS: GitLab ist auch in Ordnung, aber zum Zeitpunkt des Schreibens ist GitHub das am weitesten verbreitete Open-Source-Git-Repository. Sie möchten also dort sein, wo sich alle anderen befinden.

Sobald du dein GitHub-Konto hast, kannst du deinen Code dazu beitragen! Was auch immer Sie lernen, dass Sie Code schreiben müssen, stellen Sie sicher, dass Sie ihn regelmäßig an GitHub übergeben.

Dies fördert nicht nur eine gute Disziplin bei der Quellcode-Kontrolle, sondern hilft Ihnen auch dabei, Ihre eigene Marke aufzubauen.

HINWEIS: Wenn Sie lernen, wie man git + GitHub verwendet, achten Sie besonders auf Pull Requests (oder PRs, wenn Sie cool sein möchten).

Pull Request von Vidar Nordli-Mathisen

Marke

Apropos cool - eine Marke ist eine Möglichkeit, der Welt zu zeigen, wozu Sie in der Lage sind.

Eine Möglichkeit (derzeit eine der besseren!) Besteht darin, eine solide GitHub-Präsenz als Proxy für Ihre Marke aufzubauen. Fast alle Arbeitgeber werden heutzutage sowieso nach einem fragen.

Deshalb sollten Sie sich bemühen, einen ordentlichen, sorgfältig kuratierten GitHub-Account zu haben - etwas, auf das Sie Ihren Lebenslauf aufsetzen und auf das Sie stolz sein können.

In späteren Abschnitten erfahren Sie, wie Sie mit dem Hugo-Framework eine einfache, aber cool aussehende Website auf GitHub erstellen. Im Moment reicht es aus, nur Ihren Code in GitHub einzufügen.

Wenn Sie später mehr Erfahrung haben, sollten Sie zwei GitHub-Konten in Betracht ziehen. Eine für Ihre persönlichen Sachen, die Sie zum Speichern des von Ihnen geschriebenen Übungscodes verwenden, und eine für ein anderes Konto zum Speichern des Codes, den Sie anderen zeigen möchten.

Zusammenfassen:

  • Lerne git
  • Tragen Sie alles, was Sie gelernt haben, zu GitHub bei
  • Nutzen Sie # 1 und # 2 als Schaufenster all der Dinge, die Sie bisher gelernt haben
  • Profitieren!

Abschließende Gedanken

Denken Sie zum Schluss bitte an die neuesten Entwicklungen in diesem Bereich, z. B. GitOps.

GitOps bringt alle bisher diskutierten Ideen auf eine neue Ebene - wo alles über Git, Pull Requests und Deployment Pipelines erledigt wird.

Beachten Sie, dass GitOps und ähnliche Ansätze die geschäftliche Seite der Dinge ansprechen. Insbesondere, dass wir nicht nach komplexen Dingen wie Git suchen, weil sie cool sind.

Stattdessen verwenden wir git, um geschäftliche Flexibilität zu ermöglichen, Innovationen zu beschleunigen und Funktionen schneller bereitzustellen - dies sind Dinge, mit denen unser Unternehmen am Ende mehr Geld verdienen kann!

Das ist alles für jetzt!

Und wenn Sie bereit sind, weiterzumachen, ist Teil 4 hier.