Εκμάθηση συνεχούς παράδοσης - Δημιουργία αγωγού συνεχούς παράδοσης με χρήση της Jenkins

Συνεχής παράδοση:

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

• Τι είναι η συνεχής παράδοση;
• Τύποι δοκιμών λογισμικού
• Διαφορά μεταξύ συνεχούς ολοκλήρωσης, παράδοσης και ανάπτυξης
• Ποια είναι η ανάγκη για συνεχή παράδοση;
• Hands-on Χρήση των Jenkins και Tomcat

Ας καταλάβουμε γρήγορα πώς λειτουργεί η Συνεχής Παράδοση.

Τι είναι η συνεχής παράδοση;

Είναι μια διαδικασία όπου δημιουργείτε λογισμικό με τέτοιο τρόπο ώστε να μπορεί να κυκλοφορήσει στην παραγωγή ανά πάσα στιγμή.Εξετάστε το παρακάτω διάγραμμα:

Επιτρέψτε μου να εξηγήσω το παραπάνω διάγραμμα:

• Τα αυτοματοποιημένα σενάρια build θα εντοπίσουν αλλαγές στη διαχείριση κώδικα πηγής (SCM) όπως το Git.
• Μόλις εντοπιστεί η αλλαγή, ο πηγαίος κώδικας θα αναπτυχθεί σε έναν αποκλειστικό διακομιστή build για να βεβαιωθείτε ότι το build δεν θα αποτύχει και όλες οι τάξεις δοκιμών και οι δοκιμές ενοποίησης λειτουργούν καλά.
• Στη συνέχεια, η εφαρμογή build αναπτύσσεται στους δοκιμαστικούς διακομιστές (διακομιστές πριν την παραγωγή) για Δοκιμή αποδοχής χρήστη (UAT).
• Τέλος, η εφαρμογή αναπτύσσεται χειροκίνητα στους διακομιστές παραγωγής για κυκλοφορία.

Πριν προχωρήσω, θα είναι δίκαιο να σας εξηγήσω τους διαφορετικούς τύπους δοκιμών.

Τύποι δοκιμών λογισμικού:

Σε γενικές γραμμές υπάρχουν δύο τύποι δοκιμών:

• Δοκιμή Blackbox: Είναι μια τεχνική δοκιμών που αγνοεί τον εσωτερικό μηχανισμό του συστήματος και εστιάζει στην έξοδο που παράγεται έναντι οποιασδήποτε εισόδου και εκτέλεσης του συστήματος. Ονομάζεται επίσης λειτουργική δοκιμή. Χρησιμοποιείται βασικά για την επικύρωση του λογισμικού.
• Δοκιμή Whitebox: είναι μια τεχνική δοκιμών που λαμβάνει υπόψη τον εσωτερικό μηχανισμό ενός συστήματος. Ονομάζεται επίσης δομική δοκιμή και δοκιμή γυάλινων κουτιών. Χρησιμοποιείται βασικά για την επαλήθευση του λογισμικού.

Δοκιμή Whitebox:

Υπάρχουν δύο τύποι δοκιμών, που εμπίπτουν σε αυτήν την κατηγορία.

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

Δοκιμή Blackbox:

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

• Δοκιμή λειτουργικής / αποδοχής: Διασφαλίζει ότι λειτουργεί η καθορισμένη λειτουργικότητα που απαιτείται στις απαιτήσεις συστήματος. Γίνεται για να βεβαιωθείτε ότι το παραδοθέν προϊόν πληροί τις απαιτήσεις και λειτουργεί όπως αναμένει ο πελάτης
• Δοκιμή συστήματος: Διασφαλίζει ότι η τοποθέτηση του λογισμικού σε διαφορετικά περιβάλλοντα (π.χ. λειτουργικά συστήματα) εξακολουθεί να λειτουργεί.
• Δοκιμή στρες: Αξιολογεί πώς συμπεριφέρεται το σύστημα υπό δυσμενείς συνθήκες.
• Δοκιμές Beta: Πραγματοποιείται από τελικούς χρήστες, μια ομάδα εκτός ανάπτυξης, ή κυκλοφορεί δημόσια την πλήρη προ-έκδοση του προϊόντος που είναι γνωστή ωςβήταεκδοχή. Ο στόχος της δοκιμής beta είναι η κάλυψη απροσδόκητων σφαλμάτων.

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

Διαφορές μεταξύ συνεχούς ολοκλήρωσης, παράδοσης και ανάπτυξης:

Το οπτικό περιεχόμενο φτάνει στον εγκέφαλο ενός ατόμου με πιο γρήγορο και κατανοητό τρόπο από τις πληροφορίες κειμένου. Θα ξεκινήσω λοιπόν με ένα διάγραμμα που εξηγεί με σαφήνεια τη διαφορά:

Στη συνεχή ενσωμάτωση, κάθε δέσμευση κώδικα δημιουργείται και δοκιμάζεται, αλλά δεν είναι σε κατάσταση που θα κυκλοφορήσει. Θέλω να πω ότι η εφαρμογή build δεν αναπτύσσεται αυτόματα στους δοκιμαστικούς διακομιστές προκειμένου να την επικυρώσει χρησιμοποιώντας διαφορετικούς τύπους δοκιμών Blackbox όπως - Δοκιμή αποδοχής χρήστη (UAT).

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

Η συνεχής ανάπτυξη είναι το επόμενο βήμα μετά τη συνεχή παράδοση, όπου δεν δημιουργείτε μόνο ένα αναπτυσσόμενο πακέτο, αλλά το χρησιμοποιείτε πραγματικά με αυτοματοποιημένο τρόπο.

Επιτρέψτε μου να συνοψίσω τις διαφορές χρησιμοποιώντας έναν πίνακα:

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

Μάθετε πώς να δημιουργείτε αγωγούς CI / CD χρησιμοποιώντας το Jenkins On Cloud

Αλλά το ερώτημα είναι αν η συνεχής ολοκλήρωση είναι αρκετή.

Γιατί χρειαζόμαστε συνεχή παράδοση;

Ας το καταλάβουμε με ένα παράδειγμα.

Φανταστείτε ότι υπάρχουν 80 προγραμματιστές που εργάζονται σε ένα μεγάλο έργο. Χρησιμοποιούν αγωγούς συνεχούς ολοκλήρωσης για να διευκολύνουν τις αυτοματοποιημένες κατασκευές. Γνωρίζουμε ότι το build περιλαμβάνει και δοκιμές μονάδων. Μια μέρα αποφάσισαν να αναπτύξουν την τελευταία έκδοση που είχε περάσει τις δοκιμές μονάδας σε περιβάλλον δοκιμών.

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

Ποια μπορεί να είναι η προφανής αιτία της αποτυχίας;

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

Ένας αντιληπτικός προγραμματιστής έκανε μια έξυπνη προσέγγιση:

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

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

Δήλωση προβλήματος:

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

Επιτρέψτε μου να συνοψίσω τα μαθήματα που αντλήθηκαν εξετάζοντας τα παραπάνω προβλήματα:

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

Λύση - Αγωγός συνεχούς παράδοσης (αυτοματοποιημένη δοκιμή αποδοχής):

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

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

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

Αγωγός συνεχούς παράδοσης με χρήση της Jenkins:

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

Βήματα που εμπλέκονται στο Demo:

• Ανάκτηση του κώδικα από το GitHub
• Σύνταξη του πηγαίου κώδικα
• Δοκιμή μονάδας και δημιουργία των αναφορών δοκιμής JUnit
• Συσκευασία της εφαρμογής σε αρχείο WAR και ανάπτυξη της στο διακομιστή Tomcat

Προαπαιτούμενα:

• Μηχανή CentOS 7
• Jenkins 2.121.1
• Λιμενεργάτης
• Tomcat 7

Βήμα - 1 Σύνταξη του πηγαίου κώδικα:

Ας ξεκινήσουμε δημιουργώντας πρώτα ένα έργο Freestyle στο Jenkins. Εξετάστε το παρακάτω στιγμιότυπο οθόνης:

Δώστε ένα όνομα στο έργο σας και επιλέξτε Freestyle Project:

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

Τώρα θα προσθέσουμε ένα Trigger Build. Διαλέξτε την επιλογή δημοσκόπησης SCM, βασικά, θα ρυθμίσουμε τη Jenkins για δημοσκόπηση του αποθετηρίου GitHub μετά από κάθε 5 λεπτά για αλλαγές στον κώδικα. Εξετάστε το παρακάτω στιγμιότυπο οθόνης:

Πριν προχωρήσω, επιτρέψτε μου να σας δώσω μια μικρή εισαγωγή στον Κύκλο του Maven Build.

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

Ακολουθεί η λίστα των φάσεων κατασκευής:

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

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

καθαρό πακέτο mvn

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

Θα ξεκινήσουμε λοιπόν με τη σύνταξη του πηγαίου κώδικα. Στην καρτέλα build, κάντε κλικ στην επίκληση στόχων υψηλού επιπέδου maven και πληκτρολογήστε την παρακάτω εντολή:

συντάσσω

Εξετάστε το παρακάτω στιγμιότυπο οθόνης:

Αυτό θα τραβήξει τον πηγαίο κώδικα από το αποθετήριο GitHub και θα τον μεταγλωττίσει (Maven Compile Phase).

Κάντε κλικ στο Αποθήκευση και εκτελέστε το έργο.

Τώρα, κάντε κλικ στην έξοδο της κονσόλας για να δείτε το αποτέλεσμα.

Βήμα - 2 Δοκιμή μονάδας:

Τώρα θα δημιουργήσουμε ένα ακόμη Freestyle Project για δοκιμές μονάδας.

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

Τώρα, στην καρτέλα 'Buid Trigger' κάντε κλικ στο 'build μετά την κατασκευή άλλων έργων'. Εκεί πληκτρολογήστε το όνομα του προηγούμενου έργου όπου καταρτίζουμε τον πηγαίο κώδικα και μπορείτε να ορίσετε οποιαδήποτε από τις παρακάτω επιλογές:

• Ενεργοποιήστε μόνο εάν η κατασκευή είναι σταθερή
• Ενεργοποιήστε ακόμη και αν η κατασκευή είναι ασταθής
• Ενεργοποιήστε ακόμη και αν η κατασκευή αποτύχει

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

Στην καρτέλα Build, κάντε κλικ στην επίκληση στόχων υψηλού επιπέδου maven και χρησιμοποιήστε την παρακάτω εντολή:

δοκιμή

Η Jenkins κάνει επίσης εξαιρετική δουλειά να σας βοηθήσει να εμφανίσετε τα αποτελέσματα των δοκιμών σας και τις τάσεις των αποτελεσμάτων των δοκιμών.

Το de facto πρότυπο για τις δοκιμές αναφοράς στον κόσμο της Java είναι μια μορφή XML που χρησιμοποιείται από το JUnit. Αυτή η μορφή χρησιμοποιείται επίσης από πολλά άλλα εργαλεία δοκιμών Java, όπως TestNG, Spock και Easyb. Η Jenkins κατανοεί αυτήν τη μορφή, οπότε αν το build σας παράγει αποτελέσματα δοκιμών JUnit XML, η Jenkins μπορεί να δημιουργήσει ωραίες γραφικές αναφορές δοκιμών και στατιστικά στοιχεία για τα αποτελέσματα των δοκιμών με την πάροδο του χρόνου και επίσης να σας επιτρέψει να δείτε τις λεπτομέρειες τυχόν αποτυχημένων δοκιμών. Η Jenkins παρακολουθεί επίσης το χρονικό διάστημα που χρειάζονται οι δοκιμές σας, τόσο σε παγκόσμιο επίπεδο, όσο και ανά δοκιμή - αυτό μπορεί να είναι χρήσιμο εάν πρέπει να εντοπίσετε προβλήματα απόδοσης.

Το επόμενο πράγμα που πρέπει να κάνουμε είναι να κάνουμε τη Jenkins να παρακολουθεί τις δοκιμές μονάδας μας.

Μεταβείτε στην ενότητα Ενέργειες μετά την κατασκευή και επιλέξτε το πλαίσιο ελέγχου 'Δημοσίευση αναφοράς αποτελεσμάτων δοκιμής JUnit'. Όταν ο Maven εκτελεί δοκιμές μονάδας σε ένα έργο, δημιουργεί αυτόματα τις αναφορές δοκιμών XML σε έναν κατάλογο που ονομάζεται surefire-report. Εισαγάγετε λοιπόν '** / target / surefire-reports / *. Xml' στο πεδίο 'Δοκιμή αναφοράς XML'. Οι δύο αστερίσκοι στην αρχή της διαδρομής ('**') είναι μια βέλτιστη πρακτική για να κάνετε τη διαμόρφωση λίγο πιο ισχυρή: επιτρέπουν στον Jenkins να βρει τον κατάλογο προορισμού, ανεξάρτητα από το πώς έχουμε ρυθμίσει τη Jenkins να ελέγχει τον πηγαίο κώδικα.

** / target / surefire-report / *. xml

Αποθηκεύστε ξανά και κάντε κλικ στο Build Now.

Τώρα, η αναφορά JUnit γράφεται στο / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-report / TEST-behavior.

Στον πίνακα ελέγχου Jenkinsμπορείτε επίσης να παρατηρήσετε τα αποτελέσματα των δοκιμών:

Βήμα - 3 Δημιουργία αρχείου WAR και ανάπτυξη στον διακομιστή Tomcat:

Τώρα, το επόμενο βήμα είναι να συσκευάσουμε την εφαρμογή μας σε ένα αρχείο WAR και να την αναπτύξουμε στον διακομιστή Tomcat για δοκιμή αποδοχής χρήστη.

Δημιουργήστε ένα ακόμη έργο freestyle και προσθέστε τη διεύθυνση URL αποθετηρίου πηγαίου κώδικα.

Στη συνέχεια, στην καρτέλα trigger build, επιλέξτε build όταν κατασκευάζονται άλλα έργα, εξετάστε το παρακάτω στιγμιότυπο οθόνης:

Βασικά, μετά τη δοκιμαστική εργασία, η φάση ανάπτυξης θα ξεκινήσει αυτόματα.

Στην καρτέλα build, επιλέξτε το σενάριο κελύφους. Πληκτρολογήστε την παρακάτω εντολή για να συσκευάσετε την εφαρμογή σε ένα αρχείο WAR:

πακέτο mvn

Το επόμενο βήμα είναι να αναπτύξετε αυτό το αρχείο WAR στο Tomcatυπηρέτης. Στην καρτέλα 'Ενέργειες μετά την κατασκευή' επιλέξτε ανάπτυξη πολέμου / αυτιού σε ένα κοντέινερ. Εδώ, δώστε τη διαδρομή στο αρχείο πολέμου και δώστε τη διαδρομή περιβάλλοντος. Εξετάστε το παρακάτω στιγμιότυπο οθόνης:

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

Για να προσθέσετε διαπιστευτήρια στο Jenkins, κάντε κλικ στην επιλογή διαπιστευτηρίων στον πίνακα ελέγχου Jenkins.

Κάντε κλικ στο Σύστημα και επιλέξτε καθολικά διαπιστευτήρια.

Στη συνέχεια, θα βρείτε μια επιλογή για να προσθέσετε τα διαπιστευτήρια. Κάντε κλικ σε αυτό και προσθέστε διαπιστευτήρια.

Προσθέστε τα διαπιστευτήρια Tomcat, εξετάστε το παρακάτω στιγμιότυπο οθόνης.

Κάντε κλικ στο OK.

Τώρα στο Project Configuration, προσθέστε τα διαπιστευτήρια tomcat που έχετε εισαγάγει στο προηγούμενο βήμα.

Κάντε κλικ στο Save και μετά επιλέξτε Build Now.

Μεταβείτε στη διεύθυνση URL του tomcat, με τη διαδρομή περιβάλλοντος, στην περίπτωσή μου είναι http: // localhost: 8081. Τώρα προσθέστε τη διαδρομή περιβάλλοντος στο τέλος, εξετάστε το παρακάτω Στιγμιότυπο οθόνης:

Σύνδεσμος - http: // localhost: 8081 / gof

Ελπίζω να έχετε καταλάβει την έννοια του μονοπατιού περιβάλλοντος.

Τώρα δημιουργήστε μια προβολή αγωγού, εξετάστε το παρακάτω στιγμιότυπο οθόνης:

Κάντε κλικ στο εικονίδιο συν, για να δημιουργήσετε μια νέα προβολή.

Διαμορφώστε τον αγωγό με τον τρόπο που θέλετε, εξετάστε το παρακάτω στιγμιότυπο οθόνης:

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

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

Έτσι μπορούμε να αναπτύξουμε συνεχώς την εφαρμογή μας στον δοκιμαστικό διακομιστή για δοκιμή αποδοχής χρήστη (UAT).

πώς να μάθετε pl sql

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

Για να δημιουργήσετε αγωγούς CI / CD, πρέπει να αποκτήσετε μεγάλη ποικιλία δεξιοτήτων Κατακτήστε τις απαιτούμενες δεξιότητες DevOps τώρα