Πώς να γίνει ένας μηχανικός DevOps σε έξι μήνες ή λιγότερο, Μέρος 3: Έκδοση

Γρήγορη ανασκόπηση

Ας ανακαλύψουμε γρήγορα πού είμαστε.

Με λίγα λόγια, αυτή η σειρά μηνυμάτων λέει μια ιστορία.

Και αυτή η ιστορία μαθαίνει πώς να πάρει μια ιδέα και να την μετατρέψει σε χρήματα, το συντομότερο δυνατό - την ουσία του σύγχρονου κινήματος DevOps.

Συγκεκριμένα, στο Μέρος 1 μιλήσαμε για την κουλτούρα και τους στόχους του DevOps.

Στο Μέρος 2, συζητήσαμε για το πώς θα θέσουμε τα θεμέλια για μελλοντικές εφαρμογές κώδικα με το Terraform. Φυσικά, Terraform είναι κώδικας επίσης!

Συνεπώς, σε αυτή τη θέση, θα συζητήσουμε πώς να κρατήσετε όλα αυτά τα κομμάτια του κώδικα από το να πηγαίνουν εντελώς άσχημα σε όλη τη χώρα. Spoiler, είναι όλα σχετικά με git!

Μπόνους: Θα μιλήσουμε επίσης για το πώς να χρησιμοποιήσετε αυτή την επιχείρηση git για να χτίσετε και να προωθήσετε το προσωπικό σας εμπορικό σήμα.

Για παραπομπή, είμαστε εδώ στο ταξίδι μας:

Ταξίδι DevOps

Γιατί να ασχοληθούμε;

Όταν μιλάμε για "Έκδοση" τι εννοούμε;

Φανταστείτε ότι εργάζεστε σε κάποιο λογισμικό. Κάνετε αλλαγές σε αυτό συνεχώς, προσθέτοντας ή αφαιρώντας τα χαρακτηριστικά ανάλογα με τις ανάγκες. Συχνά, η τελευταία αλλαγή θα είναι μια "σπάσιμο" αλλαγή. Με άλλα λόγια, ό, τι κι αν κάνατε τελευταία, έσπασε ό, τι είχατε πριν.

Και τώρα τι?

Καλά. Εάν είστε πραγματικά Old School, πιθανότατα έχετε την τάση να ονομάσετε το πρώτο σας αρχείο ως εξής:

awesome_code.pl

Στη συνέχεια, αρχίζετε να κάνετε αλλαγές και πρέπει να διατηρήσετε όσα λειτουργούν, σε περίπτωση που πρέπει να επιστρέψετε σε αυτό.

Έτσι, μετονομάστε το αρχείο σας σε αυτό:

awesome_code.12.25.2018.pl

Και αυτό λειτουργεί καλά. Μέχρι μία ημέρα κάνετε περισσότερες από μία αλλαγές την ημέρα, έτσι ώστε να καταλήξετε σε αυτό:

awesome_code.GOOD.12.25.2018.pl

Και ούτω καθεξής.

Φυσικά, σε ένα επαγγελματικό περιβάλλον, έχετε πολλαπλές ομάδες που συνεργάζονται με τον ίδιο κώδικα, που σπάει ακόμα περισσότερο αυτό το μοντέλο.

Περιττό να πω ότι αυτό το τρελό τρένο εκτροχιάζει γρήγορα.

Έλεγχος πηγαίου κώδικα

Εισαγωγή ελέγχου πηγαίου κώδικα: ένας τρόπος για να διατηρήσετε τα αρχεία σας σε κεντρική θέση, όπου πολλές ομάδες μπορούν να συνεργαστούν σε ένα κοινό κωδικό.

Τώρα, αυτή η ιδέα δεν είναι νέα. Η πρώτη αναφορά σε ένα τέτοιο πράγμα που κατάφερα να βρω χρονολογείται από το 1972! Έτσι, η ιδέα ότι πρέπει να συγκεντρώσουμε τον κώδικα μας σε ένα μέρος είναι σίγουρα παλιά.

Αυτό που είναι σχετικά νέο, όμως, είναι η ιδέα ότι όλα τα τεχνουργήματα της παραγωγής πρέπει να εκδοθούν.

Τι σημαίνει αυτό?

Αυτό σημαίνει ότι όλα όσα αγγίζουν το περιβάλλον παραγωγής σας πρέπει να αποθηκεύονται σε έλεγχο έκδοσης, με την επιφύλαξη της παρακολούθησης, της αναθεώρησης και του ιστορικού των αλλαγών.

Επιπλέον, η επιβολή του νόμου "όλα τα εργαλεία τέχνης πρέπει να εκδοθεί" νόμος σας αναγκάζει πραγματικά να προσεγγίσετε τα προβλήματα με τη "αυτοματοποίηση πρώτη" νοοτροπία.

Για παράδειγμα, όταν αποφασίσετε να κάνετε κλικ στο δρόμο σας μέσα από ένα περίπλοκο πρόβλημα στο περιβάλλον του Dev AWS, μπορείτε να κάνετε μια παύση και να σκεφτείτε: "Είναι όλα αυτά κάνοντας κλικ σε ένα εκδομένο τεχνούργημα;"

Φυσικά, η απάντηση είναι "όχι". Έτσι, ενώ είναι εντάξει να κάνουμε γρήγορα πρωτότυπα μέσω UI για να δούμε αν κάτι λειτουργεί ή όχι, αυτές οι προσπάθειες πρέπει πραγματικά να είναι βραχύβια. Μακροπρόθεσμα, βεβαιωθείτε ότι έχετε κάνει τα πάντα στο Terraform ή σε άλλο εργαλείο υποδομής-ως-κώδικα.

Εντάξει, έτσι αν όλα είναι ένα εκδομένο τεχνούργημα, πώς αποθηκεύουμε και διαχειριζόμαστε αυτά τα πράγματα, ακριβώς;

Η απάντηση είναι git.

Git

Μέχρι να έρθουν μαζί, η χρήση συστημάτων ελέγχου πηγαίου κώδικα, όπως το SVN ή άλλοι, ήταν ανελαστικός, δεν ήταν φιλικός προς το χρήστη και ήταν γενικά μια πολύ οδυνηρή εμπειρία.

Τι git κάνει διαφορετικά είναι ότι αγκαλιάζει την έννοια ενός κατανεμημένου ελέγχου πηγαίου κώδικα.

Με άλλα λόγια, δεν κλειδώνετε άλλους ανθρώπους από ένα κεντρικό αποθετήριο πηγαίου κώδικα, ενώ εργάζεστε στις αλλαγές σας. Αντ 'αυτού, εργάζεστε σε ένα πλήρες αντίγραφο του codebase. Και αυτό το αντίγραφο έπειτα συγχωνεύεται στο κύριο αποθετήριο.

Λάβετε υπόψη σας, τα παραπάνω είναι μια ακατανόητη υπεραπλούστευση του πώς λειτουργεί το git. Αλλά αρκεί για τους σκοπούς αυτού του άρθρου, αν και η γνώση της εσωτερικής λειτουργίας του git είναι και τόσο πολύτιμη και παίρνει λίγο χρόνο για να κυριαρχήσει.

https://xkcd.com/1597/

Προς το παρόν, απλά θυμηθείτε ότι το git δεν είναι σαν το SVN των παλαιών. Πρόκειται για ένα κατανεμημένο σύστημα ελέγχου πηγαίου κώδικα, όπου πολλές ομάδες μπορούν να δουλέψουν σε ένα κοινό κωδικό με ασφάλεια και ασφάλεια.

Γιατί να ασχοληθούμε;

Συγκεκριμένα, θα υποστήριζα σθεναρά ότι δεν μπορείτε να γίνετε επαγγελματίας μηχανικός DevOps (Cloud) χωρίς να ξέρετε πώς λειτουργεί το git. Είναι τόσο απλό.

Εντάξει, πώς να μάθει κάποιος git, ακριβώς;

Πρέπει να πω, Googling για ένα "GIT tutorial" έχει την αμφίβολη διάκριση να έρχονται με εξαιρετικά πλήρη και εξαιρετικά σύγχυση tutorials.

Ωστόσο, υπάρχουν μερικές που είναι πραγματικά, πραγματικά καλές.

Μια τέτοια σειρά μαθημάτων που προτρέπω όλους να διαβάσουν, να μάθουν και να εξασκηθούν είναι τα Git Tutorials του Atlassian.

Στην πραγματικότητα, όλα είναι αρκετά καλά, αλλά ένα τμήμα ειδικότερα είναι αυτό που χρησιμοποιείται από επαγγελματίες μηχανικούς λογισμικού σε όλο τον κόσμο: Git Workflows.

Ένα άλλο πολύ καλό φροντιστήριο είναι το Learn Git Branching.

Τα μαθήματα Atlassian είναι απλά ανάγνωση και εκμάθηση (αν αυτό είναι το πράγμα σας) ενώ το Learn Git Branching είναι ένα διαδραστικό φροντιστήριο (αν αυτό είναι το πράγμα σας).

Ανεξάρτητα από αυτό, δεν θα πάρετε μακριά σε αυτή την επιχείρηση εάν δεν καταλαβαίνετε πώς λειτουργεί το git!

Δεν μπορώ να τονίσω αυτό αρκετά. Ξανά και ξανά, η έλλειψη κατανόησης του πώς λειτουργούν τα git διακλαδώσεων ή η αδυναμία εξήγησης του Gitflow είναι αυτό που κατακλύζει το 99% των υποψήφιων υποψηφίων μηχανικών DevOps.

Αυτό είναι ένα βασικό σημείο. Μπορείτε να έρθετε σε μια συνέντευξη και να μην γνωρίζετε το Terraform ή οτιδήποτε άλλο είναι το τελευταίο μοντέρνο εργαλείο υποδομής-ως-κώδικα και αυτό είναι εντάξει - μπορεί κανείς να το μάθει στη δουλειά.

Αλλά μη γνωρίζοντας το git και πώς λειτουργεί είναι ένα μήνυμα που σας λείπει τα βασικά στοιχεία των σύγχρονων βέλτιστων πρακτικών μηχανικής λογισμικού, DevOps ή όχι. Αυτό σηματοδοτεί την πρόσληψη διαχειριστών ότι η καμπύλη μάθησης σας θα είναι πολύ απότομη. Δεν θέλετε να το σημάνετε αυτό!

Αντίστροφα, η ικανότητά σας να μιλάτε με σιγουριά για τις βέλτιστες πρακτικές git λέει στους διαχειριστές μίσθωσης ότι έρχεστε πρώτα με μια νοοτροπία μηχανικής λογισμικού - ακριβώς το είδος της εικόνας που θέλετε να προβάλλετε.

Για να συνοψίσω: δεν χρειάζεται να γίνετε ο πρώτος εμπειρογνώμονας git στον κόσμο για να προσγειωθείτε στον φοβερό ρόλο DevOps αλλά πρέπει να ζήσετε και να αναπνεύσετε git για λίγο για να είστε σε θέση να μιλήσετε με σιγουριά για το τι συμβαίνει.

Τουλάχιστον, θα πρέπει να είστε καλά εξοικειωμένοι με το πώς να

  1. Πιέστε ένα repo
  2. Δημιουργία υποκαταστημάτων
  3. Συγχώνευση αλλαγών από την ανάντη και την πλάτη
  4. Δημιουργία αιτημάτων έλξης

Και τώρα τι?

Τώρα, μόλις φτάσετε στα εισαγωγικά μαθήματα git, αποκτήστε τον λογαριασμό σας στο GitHub.

ΣΗΜΕΙΩΣΗ: Το GitLab είναι εντάξει επίσης, αλλά κατά τη στιγμή αυτής της γραφής, το GitHub είναι το πιο διαδεδομένο αποθετήριο git ανοιχτού κώδικα, έτσι θέλετε να βρίσκεστε εκεί όπου είναι όλοι οι άλλοι.

Αφού έχετε λογαριασμό στο GitHub, ξεκινήστε να συνεισφέρετε τον κωδικό σας σε αυτό! Ό, τι μαθαίνετε και απαιτεί να γράφετε κώδικα, βεβαιωθείτε ότι τη δεσμεύεστε στο GitHub τακτικά.

Αυτό όχι μόνο ενσταλάζει την καλή πειθαρχία ελέγχου πηγαίου κώδικα αλλά σας βοηθά να δημιουργήσετε το δικό σας προσωπικό σήμα.

ΣΗΜΕΙΩΣΗ: όταν μαθαίνετε πώς να χρησιμοποιείτε το git + GitHub, δώστε ιδιαίτερη προσοχή στα Pull Requests (ή PRs, εάν θέλετε να είστε δροσερά).

Τραβήξτε την αίτηση, από τον Vidar Nordli-Mathisen

Μάρκα

Μιλώντας για το δροσερό - μια μάρκα είναι ένας τρόπος να προβάλλετε στον ευρύτερο κόσμο αυτό που είστε σε θέση.

Ένας τρόπος (προς το παρόν, ένας από τους καλύτερους τρόπους!) Είναι να εδραιωθεί μια σταθερή παρουσία του GitHub ως υποκατάστατο για το εμπορικό σήμα σας. Σχεδόν όλοι οι εργοδότες αυτές τις μέρες θα το ζητήσουν ούτως ή άλλως.

Επομένως, θα πρέπει να προσπαθήσετε να έχετε έναν καθαρό, προσεκτικά επιμελημένο λογαριασμό GitHub - κάτι που μπορείτε να βάλετε στο βιογραφικό σας και να είστε υπερήφανοι.

Σε επόμενα τμήματα, θα μιλήσουμε για το πώς θα οικοδομήσουμε έναν απλό αλλά συναρπαστικό ιστότοπο στο GitHub χρησιμοποιώντας το πλαίσιο Hugo. Προς το παρόν, αρκεί να τοποθετήσετε τον κώδικα σας στο GitHub.

Αργότερα, καθώς αποκτάτε περισσότερη εμπειρία, μπορείτε να εξετάσετε το ενδεχόμενο να έχετε δύο λογαριασμούς GitHub. Ένα για τα προσωπικά σας στοιχεία που χρησιμοποιείτε για να αποθηκεύσετε κωδικό πρακτικής που γράφετε και έναν άλλο λογαριασμό για την αποθήκευση κωδικού που θέλετε να δείξετε σε άλλους.

Να συνοψίσουμε:

  • Μάθετε git
  • Συνεισφέρετε όλα όσα έχετε μάθει στο GitHub
  • Αναπτύξτε το μοχλό # 1 και # 2 ως μια βιτρίνα όλων των πραγμάτων που έχετε μάθει μέχρι στιγμής
  • Κέρδος!

Τελικές σκέψεις

Τέλος, λάβετε υπόψη τις τελευταίες εξελίξεις σε αυτόν τον χώρο, όπως το GitOps.

Το GitOps παίρνει όλες τις ιδέες που έχουμε συζητήσει μέχρι τώρα σε νέα επίπεδα - όπου όλα γίνονται μέσω git, pull requests και αγωγών ανάπτυξης.

Σημειώστε ότι οι GitOps και οι προσεγγίσεις μιλούν στην επιχειρηματική πλευρά των πραγμάτων. Συγκεκριμένα, ότι δεν χρησιμοποιούμε πολύπλοκα πράγματα όπως το git επειδή είναι δροσερά.

Αντ 'αυτού, χρησιμοποιούμε το git για να διευκολύνουμε την ευελιξία των επιχειρήσεων, να επιταχύνουμε την καινοτομία και να προσφέρουμε πιο γρήγορα τα χαρακτηριστικά - αυτά είναι πράγματα που επιτρέπουν στην επιχείρησή μας να κάνει περισσότερα χρήματα στο τέλος!

Αυτα για τωρα!

Και αν είστε έτοιμοι να προχωρήσετε, το Μέρος 4 είναι εδώ.