CI/CD: έννοιες και pipeline

9 λεπτά

Πίνακας περιεχομένων


1 — Τι είναι το CI/CD;

Το CI/CD είναι η τεχνική ραχοκοκαλιά του DevOps. Είναι το σύνολο των πρακτικών που αυτοματοποιούν τη διαδρομή μεταξύ «του κώδικα που έγραψε ένας προγραμματιστής» και «της εφαρμογής που τρέχει στην παραγωγή».

ΑρκτικόλεξοΌνομαΜε μία πρόταση
CIΣυνεχής ολοκλήρωση (Continuous Integration)Συγχωνεύουμε και δοκιμάζουμε τον κώδικα συχνά και αυτόματα.
CDΣυνεχής παράδοση (Continuous Delivery)Ο δοκιμασμένος κώδικας είναι πάντα έτοιμος να αναπτυχθεί (χειροκίνητη θέση σε παραγωγή).
CDΣυνεχής ανάπτυξη (Continuous Deployment)Ο δοκιμασμένος κώδικας πηγαίνει αυτόματα στην παραγωγή.

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

🔧 Μικρή άσκηση — Συνδέστε κάθε αρκτικόλεξο με τον ορισμό του: (1) CI, (2) Continuous Delivery, (3) Continuous Deployment.

✅ Δείτε μια λύση

(1) CI = συγχώνευση + build + συχνές αυτόματες δοκιμές. (2) Continuous Delivery = πάντα έτοιμο για ανάπτυξη, χειροκίνητο κουμπί για την παραγωγή. (3) Continuous Deployment = θέση σε παραγωγή αυτόματα μετά από επιτυχημένες δοκιμές.

↑ Επιστροφή στην αρχή


2 — CI — Συνεχής ολοκλήρωση

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

Γιατί «συνεχής»;

Χωρίς CIΜε CI
Συγχωνεύουμε τα πάντα στο τέλος του μήνα → μεγάλοι επώδυνοι συγκρούσειςΣυγχωνεύουμε πολλές φορές την ημέρα → μικρές εύκολες συγκρούσεις
Τα σφάλματα εντοπίζονται αργάΤα σφάλματα εντοπίζονται σε λεπτά
«Δούλευε στον υπολογιστή μου»Αναπαραγώγιμο build στον διακομιστή

Αναλογία: να τακτοποιείτε την κουζίνα σας στην πορεία (CI) αντί να περιμένετε να λερωθούν τα πάντα (ενσωμάτωση «big bang»). Η μικρή συχνή προσπάθεια αποφεύγει τη σπάνια καταστροφή.

🔧 Μικρή άσκηση — Ένας προγραμματιστής κρατά τον κώδικά του 3 εβδομάδες χωρίς να τον συγχωνεύσει, και έπειτα επιχειρεί ένα μεγάλο merge. Ποια αρχή συνεχούς ολοκλήρωσης δεν τήρησε, και ποια συνέπεια είναι πιθανή;

✅ Δείτε μια λύση

Δεν συγχώνευσε συχνά. Πιθανή συνέπεια: μια μαζική σύγκρουση συγχώνευσης, δύσκολη στην επίλυση, και σφάλματα που εντοπίζονται πολύ αργά. Η CI συνιστά μικρές συχνές συγχωνεύσεις.

↑ Επιστροφή στην αρχή


3 — CD — Συνεχής παράδοση έναντι συνεχούς ανάπτυξης

Τα δύο «CD» μοιάζουν αλλά διαφέρουν σε ένα μόνο σημείο: ποιος πατάει το κουμπί της θέσης σε παραγωγή.

Continuous DeliveryContinuous Deployment
Θέση σε παραγωγήΧειροκίνητη (ένας άνθρωπος κάνει κλικ)Αυτόματη
ΈλεγχοςΤελική ανθρώπινη απόφασηΚαμία παρέμβαση
Ιδανικό γιαΡυθμιζόμενους τομείς, προγραμματισμένες εκδόσειςΏριμες ομάδες, υψηλό ποσοστό δοκιμών

Continuous Delivery = το αυτοκίνητο είναι σταθμευμένο μπροστά στην πόρτα, έτοιμο, με τα κλειδιά στη μίζα· εσείς αποφασίζετε πότε θα ξεκινήσετε. Continuous Deployment = το αυτόνομο αυτοκίνητο ξεκινά μόνο του μόλις είναι έτοιμο.

🔧 Μικρή άσκηση — Μια τράπεζα θέλει κάθε θέση σε παραγωγή να εγκρίνεται από έναν υπεύθυνο. Ποιο «CD» να επιλέξετε;

✅ Δείτε μια λύση

Continuous Delivery: ο αγωγός καθιστά την έκδοση έτοιμη αυτόματα, αλλά η θέση σε παραγωγή παραμένει ανθρώπινη απόφαση (επικύρωση του υπευθύνου).

↑ Επιστροφή στην αρχή


4 — Ο αγωγός CI/CD βήμα προς βήμα

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

StageΡόλοςΠαράδειγμα εργαλείου
CheckoutΑνάκτηση του κώδικα από το GitGit
BuildΜεταγλώττιση / συναρμολόγησηMaven, npm, javac
TestΑυτόματος έλεγχοςJUnit, pytest
PackageΠαραγωγή ενός παραδοτέου τεχνουργήματος.jar, εικόνα Docker
StagingΑνάπτυξη στην προπαραγωγήδιακομιστής δοκιμών
DeployΘέση σε παραγωγήδιακομιστής / νέφος

Η αρχή του «fail fast»: τοποθετούμε τα γρήγορα και φθηνά βήματα (μεταγλώττιση, δοκιμές μονάδας) πρώτα. Δεν έχει νόημα να αναπτύξουμε αν ο κώδικας δεν μεταγλωττίζεται καν.

🔧 Μικρή άσκηση — Με ποια σειρά να τοποθετήσετε αυτά τα stages: Deploy, Build, Test, Checkout;

✅ Δείτε μια λύση

CheckoutBuildTestDeploy. Ανακτούμε τον κώδικα, τον μεταγλωττίζουμε, τον δοκιμάζουμε και αναπτύσσουμε μόνο αν όλα είναι πράσινα.

↑ Επιστροφή στην αρχή


5 — Ένα συγκεκριμένο παράδειγμα από άκρη σε άκρη

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

Ανάπτυξη βήμα προς βήμα:

  1. Η Λέα διορθώνει ένα σφάλμα και κάνει git push.
  2. Ένα webhook ειδοποιεί τον διακομιστή CI/CD ότι υπάρχει νέος κώδικας.
  3. Ο αγωγός μεταγλωττίζει, εκτελεί τις 124 δοκιμές (όλες πράσινες) και έπειτα συσκευάζει την έκδοση v1.4.1.
  4. Η έκδοση αναπτύσσεται αυτόματα.
  5. Έξι λεπτά μετά το push, η διόρθωση είναι σε γραμμή — χωρίς χειροκίνητη παρέμβαση.

Συγκρίνετε: πριν από το CI/CD, η ίδια διόρθωση θα απαιτούσε μια προγραμματισμένη θέση σε παραγωγή, ένα βράδυ, χειροκίνητα, με το άγχος του «ας ελπίσουμε ότι θα δουλέψει». Εδώ, είναι μια ρουτίνα 6 λεπτών.

🔧 Μικρή άσκηση — Στο βήμα 3, 2 δοκιμές στις 124 αποτυγχάνουν. Τι κάνει ο αγωγός, και φεύγει η έκδοση στην παραγωγή;

✅ Δείτε μια λύση

Ο αγωγός σταματά στο stage Test, ειδοποιεί τη Λέα και δεν αναπτύσσει. Η παραγωγή παραμένει στην προηγούμενη σταθερή έκδοση. Αυτή είναι η αρχή «fail fast» που προστατεύει την παραγωγή.

↑ Επιστροφή στην αρχή


6 — Τα πλεονεκτήματα της αυτοματοποίησης
ΠλεονέκτημαΤι αλλάζει συγκεκριμένα
Λιγότερα ανθρώπινα λάθηΟι επαναλαμβανόμενες εργασίες είναι σε σενάρια: όχι άλλο ξεχασμένο βήμα
Γρήγορη ανατροφοδότησηΞέρετε σε λεπτά αν μια αλλαγή σπάει κάτι
Συχνές αναπτύξειςΜπορείτε να παραδίδετε πολλές φορές την ημέρα με εμπιστοσύνη
ΑναπαραγωγιμότηταΚάθε build είναι πανομοιότυπο — τέλος στο «δουλεύει στον υπολογιστή μου»
ΙχνηλασιμότηταΚάθε αλλαγή καταγράφεται: ποιος, τι, πότε

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

🔧 Μικρή άσκηση — Αναφέρετε δύο λόγους για τους οποίους το να αναπτύσσετε 10 φορές την ημέρα μικρές αλλαγές είναι λιγότερο επικίνδυνο από μία μόνο μεγάλη ανάπτυξη τον μήνα.

✅ Δείτε μια λύση
  1. Κάθε ανάπτυξη περιέχει λίγο κώδικα → ένα σφάλμα είναι εύκολο να εντοπιστεί. 2) Η επαναφορά είναι απλή (λίγες αλλαγές προς ακύρωση). Η μεγάλη μηνιαία ανάπτυξη συγκεντρώνει αντίθετα πολλούς κινδύνους με τη μία.

↑ Επιστροφή στην αρχή


7 — Κουίζ — Έννοιες CI/CD

Question 1 : Τι σημαίνει «CI»;

a) Code Inspection

b) Continuous Integration

c) Container Initialization

d) Central Infrastructure

💡 Δείτε τη λύση

Απάντηση: b)Continuous Integration: συχνή αυτόματη συγχώνευση και επικύρωση του κώδικα.


Question 2 : Ποια είναι η διαφορά μεταξύ Continuous Delivery και Continuous Deployment;

a) Καμία, είναι συνώνυμα

b) Στο Delivery η θέση σε παραγωγή είναι χειροκίνητη· στο Deployment είναι αυτόματη

c) Το Deployment δεν κάνει δοκιμές

d) Το Delivery αναπτύσσει αυτόματα

💡 Δείτε τη λύση

Απάντηση: b) — Και τα δύο προετοιμάζουν μια έτοιμη έκδοση· μόνο η θέση σε παραγωγή διαφέρει (χειροκίνητη έναντι αυτόματης).


Question 3 : Τι συμβαίνει αν το stage Test αποτύχει σε έναν αγωγό;

a) Ο αγωγός συνεχίζει ούτως ή άλλως έως την παραγωγή

b) Ο αγωγός σταματά και η ομάδα ειδοποιείται

c) Ο κώδικας διαγράφεται από το αποθετήριο

d) Ο αγωγός ξαναρχίζει στο άπειρο

💡 Δείτε τη λύση

Απάντηση: b) — Αρχή «fail fast»: μια αποτυχία σταματά τον αγωγό και ενεργοποιεί ειδοποίηση· τίποτα δεν φεύγει στην παραγωγή.


Question 4 : Τι είναι ένα τεχνούργημα σε έναν αγωγό;

a) Ένα σφάλμα που εισήχθη κατά λάθος

b) Το συσκευασμένο αποτέλεσμα ενός build (π.χ. ένα .jar, μια εικόνα)

c) Ένα μήνυμα στις καταγραφές

d) Ένας χρήστης του συστήματος

💡 Δείτε τη λύση

Απάντηση: b) — Το τεχνούργημα είναι το παραδοτέο που παράγει το build, έτοιμο να αναπτυχθεί.


Question 5 : Γιατί το να αναπτύσσετε συχνά κάνει τις αναπτύξεις ασφαλέστερες;

a) Επειδή κάθε ανάπτυξη είναι μικρότερη και άρα πιο εύκολη στη διάγνωση και στην ακύρωση

b) Επειδή καταργούμε τις δοκιμές

c) Επειδή οι διακομιστές γίνονται πιο ισχυροί

d) Επειδή οι χρήστες δεν το αντιλαμβάνονται

💡 Δείτε τη λύση

Απάντηση: a) — Οι μικρές συχνές αλλαγές μειώνουν την επιφάνεια κινδύνου και διευκολύνουν την επαναφορά.

↑ Επιστροφή στην αρχή


8 — Πρακτική — Σχεδιασμός του πρώτου σας αγωγού

Οδηγία

Μια ομάδα αναπτύσσει μια εφαρμογή Java. Σχεδιάστε (σε χαρτί / σε ψευδο-αγωγό) τα stages ενός αγωγού CI/CD για αυτή την εφαρμογή, αναφέροντας για κάθε stage: το όνομά του, τον ρόλο του και τι πρέπει να σταματήσει τον αγωγό. Διευκρινίστε επίσης αν συνιστάτε Continuous Delivery ή Continuous Deployment, και γιατί.


Προτεινόμενη διόρθωση

ΣειράStageΡόλοςΣυνθήκη διακοπής
1CheckoutΑνάκτηση του κώδικα από το GitΜη προσβάσιμο αποθετήριο
2BuildΜεταγλώττιση με Maven (mvn package)Σφάλμα μεταγλώττισης
3TestΕκτέλεση των δοκιμών JUnitΜια δοκιμή αποτυγχάνει
4PackageΠαραγωγή του τεχνουργήματος .jar / εικόναςΑποτυχία συσκευασίας
5StagingΑνάπτυξη στην προπαραγωγήΑποτυχία εκκίνησης εφαρμογής
6DeployΘέση σε παραγωγήΑπόρριψη χειροκίνητης επικύρωσης

Συνιστώμενη επιλογή για αρχή: Continuous Delivery.

Αιτιολόγηση: όσο η κάλυψη δοκιμών δεν είναι ώριμη, διατηρούμε μια ανθρώπινη επικύρωση πριν από την παραγωγή (Delivery). Όταν η ομάδα εμπιστεύεται τις αυτοματοποιημένες δοκιμές της, μπορεί να περάσει σε Continuous Deployment (αυτόματη θέση σε παραγωγή).

Αναμενόμενο σχήμα:

↑ Επιστροφή στην αρχή


9 — Σύνοψη

Σημεία που πρέπει να θυμάστε

  1. CI/CD = αυτοματοποίηση της διαδρομής από τον κώδικα στην παραγωγή, τεχνική καρδιά του DevOps.
  2. CI: συγχώνευση και δοκιμή συχνά και αυτόματα.
  3. CD: Delivery (έτοιμο για ανάπτυξη, χειροκίνητο κουμπί) έναντι Deployment (αυτόματη θέση σε παραγωγή).
  4. Ο αγωγός συνδέει stages· μια αποτυχία σταματά τα πάντα (fail fast).
  5. Ανάπτυξη συχνά και μικρά = λιγότερος κίνδυνος, γρήγορη ανατροφοδότηση, εύκολη επαναφορά.

Η συνέχεια

Μάθημα 05 — Git: εγκατάσταση και διαμόρφωση: εγκατάσταση του Git στον σταθμό εργασίας σας πριν από τα τοπικά αποθετήρια.

↑ Επιστροφή στην αρχή


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

Μάθημα δημιουργημένο από τον Dr. Haythem REHOUMA — Ανάπτυξη και ανάπτυξη λύσεων δεδομένων