Μέρος 1: Web/Android
Σημείωση: αυτό το άρθρο είναι μια μετάφραση στα ρωσικά του αρχικού άρθρου Ωστόσο, όλες οι απεικονίσεις, οι σύνδεσμοι, τα αποσπάσματα και οι όροι διατηρούνται στην αρχική γλώσσα για να αποφευχθεί η παραμόρφωση του νοήματος όταν μεταφράζονται στα ρωσικά. Σας εύχομαι καλές σπουδές!
Επί του παρόντος, η ειδικότητα DevOps είναι μια από τις πιο περιζήτητες στον κλάδο της πληροφορικής. Αν ανοίξετε δημοφιλείς ιστότοπους αναζήτησης εργασίας και φιλτράρετε κατά μισθό, θα δείτε ότι οι εργασίες που σχετίζονται με το DevOps βρίσκονται στην κορυφή της λίστας. Ωστόσο, είναι σημαντικό να γίνει κατανοητό ότι αυτό αναφέρεται κυρίως σε θέση 'Senior', κάτι που σημαίνει ότι ο υποψήφιος έχει υψηλό επίπεδο δεξιοτήτων, γνώσης τεχνολογίας και εργαλείων. Αυτό συνοδεύεται επίσης από υψηλό βαθμό ευθύνης που σχετίζεται με την αδιάλειπτη λειτουργία της παραγωγής. Ωστόσο, αρχίσαμε να ξεχνάμε τι είναι το DevOps. Αρχικά, δεν ήταν κάποιο συγκεκριμένο πρόσωπο ή τμήμα. Αν ψάξουμε για ορισμούς αυτού του όρου, θα βρούμε πολλά όμορφα και σωστά ουσιαστικά, όπως μεθοδολογία, πρακτικές, πολιτισμική φιλοσοφία, ομάδα εννοιών κ.λπ.
Η εξειδίκευσή μου είναι μηχανικός αυτοματισμού δοκιμών (QA automation engineer), αλλά πιστεύω ότι δεν πρέπει να σχετίζεται μόνο με τη σύνταξη αυτόματων δοκιμών ή την ανάπτυξη αρχιτεκτονικής πλαισίου δοκιμών. Το 2020, η γνώση της υποδομής αυτοματισμού είναι επίσης απαραίτητη. Αυτό σας επιτρέπει να οργανώσετε μόνοι σας τη διαδικασία αυτοματισμού, από την εκτέλεση δοκιμών έως την παροχή αποτελεσμάτων σε όλους τους ενδιαφερόμενους σύμφωνα με τους στόχους σας. Ως αποτέλεσμα, οι δεξιότητες DevOps είναι απαραίτητες για να ολοκληρώσετε τη δουλειά. Και όλα αυτά είναι καλά, αλλά, δυστυχώς, υπάρχει ένα πρόβλημα (spoiler: αυτό το άρθρο επιχειρεί να απλοποιήσει αυτό το πρόβλημα). Το θέμα είναι ότι το DevOps είναι δύσκολο. Και αυτό είναι προφανές, γιατί οι εταιρείες δεν θα πληρώσουν πολλά για κάτι που είναι εύκολο να γίνει... Στον κόσμο των DevOps, υπάρχει ένας μεγάλος αριθμός εργαλείων, όρων και πρακτικών που πρέπει να κατακτηθούν. Αυτό είναι ιδιαίτερα δύσκολο στην αρχή μιας καριέρας και εξαρτάται από τη συσσωρευμένη τεχνική εμπειρία.
Πηγή:
Εδώ μάλλον θα τελειώσουμε με το εισαγωγικό μέρος και θα επικεντρωθούμε στον σκοπό αυτού του άρθρου.
Τι αφορά αυτό το άρθρο;
Σε αυτό το άρθρο, θα μοιραστώ την εμπειρία μου από την κατασκευή μιας δοκιμαστικής υποδομής αυτοματισμού. Υπάρχουν πολλές πηγές πληροφοριών στο Διαδίκτυο σχετικά με διάφορα εργαλεία και τον τρόπο χρήσης τους, αλλά θα ήθελα να τις εξετάσω καθαρά στο πλαίσιο του αυτοματισμού. Πιστεύω ότι πολλοί μηχανικοί αυτοματισμού είναι εξοικειωμένοι με την κατάσταση όταν κανείς εκτός από εσάς δεν εκτελεί τις δοκιμές που έχουν αναπτυχθεί ή δεν ενδιαφέρεται για τη συντήρησή τους. Ως αποτέλεσμα, τα τεστ γίνονται ξεπερασμένα και πρέπει να αφιερώσετε χρόνο για να τα ενημερώσετε. Και πάλι, στην αρχή μιας καριέρας, αυτό μπορεί να είναι αρκετά δύσκολο έργο: να αποφασίσετε με σύνεση ποια εργαλεία θα βοηθήσουν στην εξάλειψη ενός δεδομένου προβλήματος, πώς να τα επιλέξετε, να ρυθμίσετε και να τα διατηρήσετε. Ορισμένοι δοκιμαστές απευθύνονται σε DevOps (άνθρωποι) για βοήθεια και, ας είμαστε ειλικρινείς, αυτή η προσέγγιση λειτουργεί. Σε πολλές περιπτώσεις αυτή μπορεί να είναι η μόνη επιλογή, καθώς δεν έχουμε ορατότητα σε όλες τις εξαρτήσεις. Αλλά όπως γνωρίζουμε, οι DevOps είναι πολύ απασχολημένοι, γιατί πρέπει να σκεφτούν την υποδομή ολόκληρης της εταιρείας, την ανάπτυξη, την παρακολούθηση, τις μικροϋπηρεσίες και άλλες παρόμοιες εργασίες ανάλογα με τον οργανισμό/ομάδα. Όπως συμβαίνει συνήθως, η αυτοματοποίηση δεν αποτελεί προτεραιότητα. Σε μια τέτοια περίπτωση, πρέπει να προσπαθήσουμε να κάνουμε ό,τι είναι δυνατό από την πλευρά μας από την αρχή μέχρι το τέλος. Αυτό θα μειώσει τις εξαρτήσεις, θα επιταχύνει τη ροή εργασίας, θα βελτιώσει τις δεξιότητές μας και θα μας επιτρέψει να δούμε τη μεγαλύτερη εικόνα του τι συμβαίνει.
Το άρθρο παρουσιάζει τα πιο δημοφιλή και δημοφιλή εργαλεία και δείχνει πώς να τα χρησιμοποιήσετε για να δημιουργήσετε μια υποδομή αυτοματισμού βήμα προς βήμα. Κάθε ομάδα αντιπροσωπεύεται από εργαλεία που έχουν δοκιμαστεί μέσω προσωπικής εμπειρίας. Αλλά αυτό δεν σημαίνει ότι πρέπει να χρησιμοποιήσετε το ίδιο πράγμα. Τα ίδια τα εργαλεία δεν είναι σημαντικά, εμφανίζονται και γίνονται απαρχαιωμένα. Το μηχανολογικό μας καθήκον είναι να κατανοήσουμε τις βασικές αρχές: γιατί χρειαζόμαστε αυτήν την ομάδα εργαλείων και ποια προβλήματα εργασίας μπορούμε να λύσουμε με τη βοήθειά τους. Γι' αυτό στο τέλος κάθε ενότητας αφήνω συνδέσμους για παρόμοια εργαλεία που μπορεί να χρησιμοποιηθούν στον οργανισμό σας.
Τι δεν υπάρχει σε αυτό το άρθρο
Επαναλαμβάνω για άλλη μια φορά ότι το άρθρο δεν αφορά συγκεκριμένα εργαλεία, άρα δεν θα υπάρχουν παρεμβολές κώδικα από την τεκμηρίωση και περιγραφές συγκεκριμένων εντολών. Αλλά στο τέλος κάθε ενότητας αφήνω συνδέσμους για λεπτομερή μελέτη.
Αυτό γίνεται γιατί:
- αυτό το υλικό είναι πολύ εύκολο να βρεθεί σε διάφορες πηγές (τεκμηρίωση, βιβλία, μαθήματα βίντεο).
- αν αρχίσουμε να εμβαθύνουμε, θα πρέπει να γράψουμε 10, 20, 30 μέρη αυτού του άρθρου (ενώ τα σχέδια είναι 2-3).
- Απλώς δεν θέλω να χάσω τον χρόνο σας, καθώς μπορεί να θέλετε να χρησιμοποιήσετε άλλα εργαλεία για να πετύχετε τους ίδιους στόχους.
Πρακτική
Θα ήθελα πολύ αυτό το υλικό να είναι χρήσιμο σε κάθε αναγνώστη, και όχι απλά να διαβαστεί και να ξεχαστεί. Σε κάθε μελέτη, η πρακτική είναι ένα πολύ σημαντικό συστατικό. Για αυτό έχω προετοιμαστεί. Υπάρχει επίσης εργασία για το σπίτι που σας περιμένει για να βεβαιωθείτε ότι δεν αντιγράφετε άσκοπα τις γραμμές των εντολών που εκτελείτε.
Σχέδιο
Βήμα
Τεχνολογία
Εργαλεία
1
Τοπική εκτέλεση (προετοιμάστε δοκιμές επίδειξης ιστού / android και εκτελέστε τα τοπικά)
Node.js, Selenium, Appium
2
Συστήματα ελέγχου έκδοσης
Git
3
Εμπορευματοποίηση
Docker, πλέγμα Selenium, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Πλατφόρμες Cloud
Πλατφόρμα Google Cloud
6
Ορχήστρα
Kubernetes
7
Η υποδομή ως κωδικός (IaC)
Terraform, Ansible
Δομή κάθε τμήματος
Για να διατηρηθεί η αφήγηση σαφής, κάθε ενότητα περιγράφεται σύμφωνα με το ακόλουθο περίγραμμα:
- σύντομη περιγραφή της τεχνολογίας,
- αξία για την υποδομή αυτοματισμού,
- απεικόνιση της τρέχουσας κατάστασης της υποδομής,
- σύνδεσμοι για σπουδές,
- παρόμοια εργαλεία.
1. Εκτελέστε δοκιμές τοπικά
Σύντομη περιγραφή της τεχνολογίας
Αυτό είναι απλώς ένα προπαρασκευαστικό βήμα για να εκτελέσετε τις δοκιμές επίδειξης τοπικά και να επαληθεύσετε ότι περνούν. Στο πρακτικό μέρος, χρησιμοποιείται το Node.js, αλλά η γλώσσα προγραμματισμού και η πλατφόρμα δεν είναι επίσης σημαντικά και μπορείτε να χρησιμοποιήσετε αυτά που χρησιμοποιούνται στην εταιρεία σας.
Ωστόσο, ως εργαλεία αυτοματισμού, προτείνω να χρησιμοποιήσετε το Selenium WebDriver για πλατφόρμες web και το Appium για την πλατφόρμα Android, αντίστοιχα, καθώς στα επόμενα βήματα θα χρησιμοποιήσουμε εικόνες Docker που είναι προσαρμοσμένες για να λειτουργούν ειδικά με αυτά τα εργαλεία. Επιπλέον, όσον αφορά τις απαιτήσεις εργασίας, αυτά τα εργαλεία είναι τα πιο περιζήτητα στην αγορά.
Όπως ίσως έχετε παρατηρήσει, εξετάζουμε μόνο δοκιμές ιστού και Android. Δυστυχώς, το iOS είναι μια εντελώς διαφορετική ιστορία (ευχαριστώ την Apple). Σκοπεύω να παρουσιάσω λύσεις και πρακτικές που σχετίζονται με το IOS σε επόμενα μέρη.
Αξία για την υποδομή αυτοματισμού
Από την άποψη της υποδομής, η τοπική λειτουργία δεν παρέχει καμία αξία. Ελέγχετε μόνο ότι οι δοκιμές εκτελούνται στον τοπικό υπολογιστή σε τοπικά προγράμματα περιήγησης και προσομοιωτές. Αλλά σε κάθε περίπτωση, αυτό είναι ένα απαραίτητο σημείο εκκίνησης.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία
- οποιαδήποτε γλώσσα προγραμματισμού σας αρέσει σε συνδυασμό με δοκιμές Selenium/Appium.
- τυχόν δοκιμές?
- οποιονδήποτε δοκιμαστικό δρομέα.
2. Συστήματα ελέγχου έκδοσης (Git)
Σύντομη περιγραφή της τεχνολογίας
Δεν θα είναι μεγάλη αποκάλυψη για κανέναν αν πω ότι ο έλεγχος έκδοσης είναι ένα εξαιρετικά σημαντικό μέρος της ανάπτυξης, τόσο σε ομαδικό όσο και σε ατομικό επίπεδο. Με βάση διάφορες πηγές, είναι ασφαλές να πούμε ότι το Git είναι ο πιο δημοφιλής εκπρόσωπος. Ένα σύστημα ελέγχου έκδοσης παρέχει πολλά πλεονεκτήματα, όπως κοινή χρήση κώδικα, αποθήκευση εκδόσεων, επαναφορά σε προηγούμενους κλάδους, παρακολούθηση ιστορικού έργου και δημιουργία αντιγράφων ασφαλείας. Δεν θα συζητήσουμε κάθε σημείο λεπτομερώς, καθώς είμαι σίγουρος ότι το γνωρίζετε πολύ και το χρησιμοποιείτε στην καθημερινή σας εργασία. Αλλά αν ξαφνικά όχι, τότε συνιστώ να σταματήσετε την ανάγνωση αυτού του άρθρου και να καλύψετε αυτό το κενό το συντομότερο δυνατό.
Αξία για την υποδομή αυτοματισμού
Και εδώ μπορείτε να κάνετε μια εύλογη ερώτηση: «Γιατί μας λέει για το Git; Όλοι το γνωρίζουν αυτό και το χρησιμοποιούν τόσο για κώδικα ανάπτυξης όσο και για κώδικα αυτόματης δοκιμής.» Θα έχετε απόλυτο δίκιο, αλλά σε αυτό το άρθρο μιλάμε για υποδομή και αυτή η ενότητα λειτουργεί ως προεπισκόπηση για την ενότητα 7: «Η υποδομή ως κώδικας (IaC)». Για εμάς, αυτό σημαίνει ότι ολόκληρη η υποδομή, συμπεριλαμβανομένης της δοκιμής, περιγράφεται με τη μορφή κώδικα, ώστε να μπορούμε επίσης να εφαρμόσουμε συστήματα έκδοσης εκδόσεων σε αυτήν και να έχουμε παρόμοια οφέλη όπως για τον κώδικα ανάπτυξης και αυτοματισμού.
Θα εξετάσουμε το IaC με περισσότερες λεπτομέρειες στο Βήμα 7, αλλά ακόμα και τώρα μπορείτε να αρχίσετε να χρησιμοποιείτε το Git τοπικά δημιουργώντας ένα τοπικό αποθετήριο. Η μεγάλη εικόνα θα επεκταθεί όταν προσθέσουμε ένα απομακρυσμένο αποθετήριο στην υποδομή.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία
3. Εμπορευματοκιβώτια (Docker)
Σύντομη περιγραφή της τεχνολογίας
Για να δείξουμε πώς η μεταφορά εμπορευματοκιβωτίων έχει αλλάξει τους κανόνες του παιχνιδιού, ας πάμε πίσω στο χρόνο μερικές δεκαετίες. Τότε, οι άνθρωποι αγόραζαν και χρησιμοποιούσαν μηχανές διακομιστή για την εκτέλεση εφαρμογών. Αλλά στις περισσότερες περιπτώσεις, οι απαιτούμενοι πόροι εκκίνησης δεν ήταν γνωστοί εκ των προτέρων. Ως αποτέλεσμα, οι εταιρείες ξόδεψαν χρήματα για την αγορά ακριβών, ισχυρών διακομιστών, αλλά μέρος αυτής της χωρητικότητας δεν αξιοποιήθηκε πλήρως.
Το επόμενο στάδιο της εξέλιξης ήταν οι εικονικές μηχανές (VM), οι οποίες έλυσαν το πρόβλημα της σπατάλης χρημάτων σε αχρησιμοποίητους πόρους. Αυτή η τεχνολογία κατέστησε δυνατή την εκτέλεση εφαρμογών ανεξάρτητα η μία από την άλλη στον ίδιο διακομιστή, εκχωρώντας εντελώς απομονωμένο χώρο. Αλλά, δυστυχώς, κάθε τεχνολογία έχει τα μειονεκτήματά της. Η εκτέλεση ενός VM απαιτεί ένα πλήρες λειτουργικό σύστημα, το οποίο καταναλώνει CPU, RAM, χώρο αποθήκευσης και, ανάλογα με το λειτουργικό σύστημα, πρέπει να λαμβάνεται υπόψη το κόστος άδειας χρήσης. Αυτοί οι παράγοντες επηρεάζουν την ταχύτητα φόρτωσης και καθιστούν δύσκολη τη φορητότητα.
Και τώρα ερχόμαστε στη μεταφορά σε εμπορευματοκιβώτια. Για άλλη μια φορά, αυτή η τεχνολογία λύνει το προηγούμενο πρόβλημα, καθώς τα κοντέινερ δεν χρησιμοποιούν πλήρες λειτουργικό σύστημα, το οποίο απελευθερώνει μεγάλο όγκο πόρων και παρέχει μια γρήγορη και ευέλικτη λύση για φορητότητα.
Φυσικά, η τεχνολογία μεταφοράς εμπορευματοκιβωτίων δεν είναι κάτι καινούργιο και εισήχθη για πρώτη φορά στα τέλη της δεκαετίας του '70. Εκείνες τις μέρες, έγιναν πολλές έρευνες, εξελίξεις και προσπάθειες. Αλλά ήταν ο Docker που προσάρμοσε αυτή την τεχνολογία και την έκανε εύκολα προσβάσιμη στις μάζες. Στις μέρες μας, όταν μιλάμε για κοντέινερ, στις περισσότερες περιπτώσεις εννοούμε το Docker. Όταν μιλάμε για κοντέινερ Docker, εννοούμε κοντέινερ Linux. Μπορούμε να χρησιμοποιήσουμε συστήματα Windows και macOS για την εκτέλεση κοντέινερ, αλλά είναι σημαντικό να κατανοήσουμε ότι σε αυτήν την περίπτωση εμφανίζεται ένα πρόσθετο επίπεδο. Για παράδειγμα, το Docker σε Mac εκτελεί σιωπηλά κοντέινερ μέσα σε ένα ελαφρύ Linux VM. Θα επιστρέψουμε σε αυτό το θέμα όταν συζητήσουμε την εκτέλεση εξομοιωτών Android μέσα σε κοντέινερ, επομένως εδώ υπάρχει μια πολύ σημαντική απόχρωση που πρέπει να συζητηθεί με περισσότερες λεπτομέρειες.
Αξία για την υποδομή αυτοματισμού
Ανακαλύψαμε ότι το containerization και το Docker είναι δροσερά. Ας το δούμε αυτό στο πλαίσιο του αυτοματισμού, γιατί κάθε εργαλείο ή τεχνολογία χρειάζεται να λύσει ένα πρόβλημα. Ας περιγράψουμε τα προφανή προβλήματα της αυτοματοποίησης δοκιμών στο πλαίσιο των δοκιμών διεπαφής χρήστη:
- ένας τεράστιος αριθμός εξαρτήσεων κατά την εγκατάσταση του Selenium και ειδικά του Appium.
- προβλήματα συμβατότητας μεταξύ εκδόσεων προγραμμάτων περιήγησης, προσομοιωτών και προγραμμάτων οδήγησης.
- έλλειψη απομονωμένου χώρου για προγράμματα περιήγησης/προσομοιωτές, που είναι ιδιαίτερα κρίσιμο για παράλληλη λειτουργία.
- Είναι δύσκολο να το διαχειριστείτε και να το διατηρήσετε εάν χρειάζεται να εκτελείτε 10, 50, 100 ή ακόμα και 1000 προγράμματα περιήγησης ταυτόχρονα.
Αλλά επειδή το Selenium είναι το πιο δημοφιλές εργαλείο αυτοματισμού και το Docker είναι το πιο δημοφιλές εργαλείο μεταφοράς εμπορευματοκιβωτίων, δεν πρέπει να προκαλεί έκπληξη το γεγονός ότι κάποιος προσπάθησε να τα συνδυάσει για να δημιουργήσει ένα ισχυρό εργαλείο για την επίλυση των προαναφερθέντων προβλημάτων. Ας εξετάσουμε τέτοιες λύσεις με περισσότερες λεπτομέρειες.
Πλέγμα σεληνίου στο docker
Αυτό το εργαλείο είναι το πιο δημοφιλές στον κόσμο του Selenium για την εκτέλεση πολλών προγραμμάτων περιήγησης σε πολλά μηχανήματα και τη διαχείρισή τους από έναν κεντρικό κόμβο. Για να ξεκινήσετε, πρέπει να καταχωρίσετε τουλάχιστον 2 μέρη: Hub και Node(-ούς). Το Hub είναι ένας κεντρικός κόμβος που λαμβάνει όλα τα αιτήματα από δοκιμές και τα διανέμει στους κατάλληλους κόμβους. Για κάθε Κόμβο μπορούμε να διαμορφώσουμε μια συγκεκριμένη διαμόρφωση, για παράδειγμα, προσδιορίζοντας το επιθυμητό πρόγραμμα περιήγησης και την έκδοσή του. Ωστόσο, πρέπει ακόμα να φροντίσουμε μόνοι μας τα συμβατά προγράμματα οδήγησης και να τα εγκαταστήσουμε στους επιθυμητούς κόμβους. Για το λόγο αυτό, το πλέγμα Selenium δεν χρησιμοποιείται στην καθαρή του μορφή, εκτός από τις περιπτώσεις που πρέπει να εργαστούμε με προγράμματα περιήγησης που δεν μπορούν να εγκατασταθούν σε Linux OS. Για όλες τις άλλες περιπτώσεις, μια σημαντικά ευέλικτη και σωστή λύση θα ήταν η χρήση εικόνων Docker για την εκτέλεση του κόμβου και των κόμβων πλέγματος Selenium. Αυτή η προσέγγιση απλοποιεί σημαντικά τη διαχείριση κόμβων, καθώς μπορούμε να επιλέξουμε την εικόνα που χρειαζόμαστε με συμβατές εκδόσεις προγραμμάτων περιήγησης και προγραμμάτων οδήγησης που είναι ήδη εγκατεστημένα.
Παρά τις αρνητικές κριτικές σχετικά με τη σταθερότητα, ειδικά όταν εκτελείτε μεγάλο αριθμό κόμβων παράλληλα, το πλέγμα Selenium εξακολουθεί να είναι το πιο δημοφιλές εργαλείο για την παράλληλη εκτέλεση δοκιμών σεληνίου. Είναι σημαντικό να σημειωθεί ότι διάφορες βελτιώσεις και τροποποιήσεις αυτού του εργαλείου εμφανίζονται συνεχώς σε ανοιχτό κώδικα, που καταπολεμούν διάφορα σημεία συμφόρησης.
Selenoid για Web
Αυτό το εργαλείο είναι μια σημαντική ανακάλυψη στον κόσμο του σεληνίου, καθώς λειτουργεί αμέσως και έχει κάνει τη ζωή πολλών μηχανικών αυτοματισμού πολύ πιο εύκολη. Πρώτα απ 'όλα, δεν πρόκειται για άλλη μια τροποποίηση του πλέγματος Selenium. Αντίθετα, οι προγραμματιστές δημιούργησαν μια εντελώς νέα έκδοση του Selenium Hub στο Golang, η οποία, σε συνδυασμό με ελαφριές εικόνες Docker για διάφορα προγράμματα περιήγησης, έδωσε ώθηση στην ανάπτυξη του αυτοματισμού δοκιμών. Επιπλέον, στην περίπτωση του Selenium Grid, πρέπει να προσδιορίσουμε εκ των προτέρων όλα τα απαιτούμενα προγράμματα περιήγησης και τις εκδόσεις τους, κάτι που δεν αποτελεί πρόβλημα όταν εργάζεστε μόνο με ένα πρόγραμμα περιήγησης. Αλλά όταν πρόκειται για πολλαπλά υποστηριζόμενα προγράμματα περιήγησης, το Selenoid είναι η νούμερο ένα λύση χάρη στη λειτουργία «browser on demand». Το μόνο που απαιτείται από εμάς είναι να κατεβάσουμε εκ των προτέρων τις απαραίτητες εικόνες με προγράμματα περιήγησης και να ενημερώσουμε το αρχείο διαμόρφωσης με το οποίο αλληλεπιδρά το Selenoid. Αφού το Selenoid λάβει ένα αίτημα από τις δοκιμές, θα εκκινήσει αυτόματα το επιθυμητό κοντέινερ με το επιθυμητό πρόγραμμα περιήγησης. Όταν ολοκληρωθεί η δοκιμή, το Selenoid θα αποσύρει το κοντέινερ, ελευθερώνοντας έτσι πόρους για μελλοντικά αιτήματα. Αυτή η προσέγγιση εξαλείφει εντελώς το γνωστό πρόβλημα της «υποβάθμισης κόμβων» που συναντάμε συχνά στο πλέγμα σεληνίου.
Αλλά, δυστυχώς, το Selenoid δεν είναι ακόμα μια ασημένια σφαίρα. Έχουμε τη δυνατότητα "πρόγραμμα περιήγησης κατ' απαίτηση", αλλά η λειτουργία "πόροι κατ' απαίτηση" δεν είναι ακόμα διαθέσιμη. Για να χρησιμοποιήσουμε το Selenoid, πρέπει να το αναπτύξουμε σε φυσικό υλικό ή σε εικονική μηχανή, πράγμα που σημαίνει ότι πρέπει να γνωρίζουμε εκ των προτέρων πόσοι πόροι πρέπει να διατεθούν. Υποθέτω ότι αυτό δεν είναι πρόβλημα για μικρά έργα που εκτελούν 10, 20 ή ακόμα και 30 προγράμματα περιήγησης παράλληλα. Τι γίνεται όμως αν χρειαζόμαστε 100, 500, 1000 ή περισσότερα; Δεν έχει νόημα να διατηρείτε και να πληρώνετε τόσους πολλούς πόρους συνεχώς. Στις ενότητες 5 και 6 αυτού του άρθρου, θα συζητήσουμε λύσεις που σας επιτρέπουν να κλιμακώσετε, μειώνοντας έτσι σημαντικά το κόστος της εταιρείας.
Selenoid για Android
Μετά την επιτυχία του Selenoid ως εργαλείο αυτοματισμού ιστού, οι άνθρωποι ήθελαν κάτι παρόμοιο για το Android. Και συνέβη - το Selenoid κυκλοφόρησε με υποστήριξη Android. Από την άποψη του χρήστη υψηλού επιπέδου, η αρχή λειτουργίας είναι παρόμοια με την αυτοματοποίηση ιστού. Η μόνη διαφορά είναι ότι αντί για κοντέινερ προγράμματος περιήγησης, το Selenoid εκτελεί κοντέινερ εξομοιωτών Android. Κατά τη γνώμη μου, αυτό είναι αυτή τη στιγμή το πιο ισχυρό δωρεάν εργαλείο για την παράλληλη εκτέλεση δοκιμών Android.
Πραγματικά δεν θα ήθελα να μιλήσω για τις αρνητικές πτυχές αυτού του εργαλείου, αφού μου αρέσει πολύ. Ωστόσο, υπάρχουν τα ίδια μειονεκτήματα που ισχύουν για την αυτοματοποίηση ιστού και σχετίζονται με την κλιμάκωση. Εκτός από αυτό, πρέπει να μιλήσουμε για έναν ακόμη περιορισμό που μπορεί να εκπλήξει εάν ρυθμίζουμε το εργαλείο για πρώτη φορά. Για την εκτέλεση εικόνων Android, χρειαζόμαστε μια φυσική μηχανή ή εικονική μηχανή με υποστήριξη ένθετης εικονικοποίησης. Στον οδηγό πώς να κάνετε, δείχνω πώς να το ενεργοποιήσετε σε ένα Linux VM. Ωστόσο, εάν είστε χρήστης macOS και θέλετε να αναπτύξετε το Selenoid τοπικά, τότε αυτό δεν θα είναι δυνατό για την εκτέλεση δοκιμών Android. Αλλά μπορείτε πάντα να εκτελείτε ένα Linux VM τοπικά με ρυθμισμένη την "ενθετη εικονικοποίηση" και να αναπτύξετε το Selenoid μέσα.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Στο πλαίσιο αυτού του άρθρου, θα προσθέσουμε 2 εργαλεία για την απεικόνιση της υποδομής. Αυτά είναι το πλέγμα Selenium για δοκιμές ιστού και το Selenoid για δοκιμές Android. Στο σεμινάριο του GitHub, θα σας δείξω επίσης πώς να χρησιμοποιείτε το Selenoid για την εκτέλεση δοκιμών ιστού.
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία
- Υπάρχουν και άλλα εργαλεία μεταφοράς εμπορευματοκιβωτίων, αλλά το Docker είναι το πιο δημοφιλές. Αν θέλετε να δοκιμάσετε κάτι άλλο, να έχετε κατά νου ότι τα εργαλεία που καλύψαμε για την παράλληλη εκτέλεση των δοκιμών σεληνίου δεν θα λειτουργήσουν απροσδόκητα.
- Όπως ήδη αναφέρθηκε, υπάρχουν πολλές τροποποιήσεις του πλέγματος σεληνίου, για παράδειγμα,.
4.CI/CD
Σύντομη περιγραφή της τεχνολογίας
Η πρακτική της συνεχούς ολοκλήρωσης είναι αρκετά δημοφιλής στην ανάπτυξη και είναι εφάμιλλη με τα συστήματα ελέγχου εκδόσεων. Παρόλα αυτά, αισθάνομαι ότι υπάρχει σύγχυση στην ορολογία. Σε αυτήν την παράγραφο θα ήθελα να περιγράψω 3 τροποποιήσεις αυτής της τεχνολογίας από την άποψή μου. Στο διαδίκτυο θα βρείτε πολλά άρθρα με διαφορετικές ερμηνείες, και είναι απολύτως φυσιολογικό αν η γνώμη σας διαφέρει. Το πιο σημαντικό είναι ότι είστε στην ίδια σελίδα με τους συναδέλφους σας.
Άρα, υπάρχουν 3 όροι: CI - Continuous Integration, CD - Continuous Delivery και πάλι CD - Continuous Deployment. (Παρακάτω θα χρησιμοποιήσω αυτούς τους όρους στα αγγλικά). Κάθε τροποποίηση προσθέτει πολλά πρόσθετα βήματα στη γραμμή ανάπτυξής σας. Αλλά η λέξη συνεχής (συνεχές) είναι το πιο σημαντικό πράγμα. Σε αυτό το πλαίσιο, εννοούμε κάτι που συμβαίνει από την αρχή μέχρι το τέλος, χωρίς διακοπή ή χειρωνακτική παρέμβαση. Ας δούμε τα CI & CD και CD σε αυτό το πλαίσιο.
- Συνεχής ενσωμάτωση αυτό είναι το αρχικό βήμα της εξέλιξης. Μετά την υποβολή νέου κώδικα στον διακομιστή, αναμένουμε να λάβουμε γρήγορα σχόλια ότι οι αλλαγές μας είναι εντάξει. Συνήθως, το CI περιλαμβάνει την εκτέλεση εργαλείων ανάλυσης στατικού κώδικα και δοκιμές μονάδας/εσωτερικού API. Αυτό μας επιτρέπει να λαμβάνουμε πληροφορίες σχετικά με τον κώδικά μας μέσα σε λίγα δευτερόλεπτα/λεπτά.
- Συνεχής Παράδοση είναι ένα πιο προχωρημένο βήμα όπου εκτελούμε δοκιμές ενοποίησης/UI. Ωστόσο, σε αυτό το στάδιο δεν έχουμε αποτελέσματα τόσο γρήγορα όσο με το CI. Πρώτον, αυτοί οι τύποι δοκιμών χρειάζονται περισσότερο χρόνο για να ολοκληρωθούν. Δεύτερον, πριν από την εκκίνηση, πρέπει να αναπτύξουμε τις αλλαγές μας στο περιβάλλον δοκιμής/σταδίου. Επιπλέον, αν μιλάμε για ανάπτυξη κινητής τηλεφωνίας, τότε εμφανίζεται ένα επιπλέον βήμα για τη δημιουργία ενός build της εφαρμογής μας.
- Συνεχής ανάπτυξη προϋποθέτει ότι απελευθερώνουμε αυτόματα τις αλλαγές μας στην παραγωγή, εάν έχουν περάσει όλες οι δοκιμές αποδοχής στα προηγούμενα στάδια. Επιπλέον, μετά το στάδιο απελευθέρωσης, μπορείτε να διαμορφώσετε διάφορα στάδια, όπως την εκτέλεση δοκιμών καπνού στην παραγωγή και τη συλλογή μετρήσεων που σας ενδιαφέρουν. Η συνεχής ανάπτυξη είναι δυνατή μόνο με καλή κάλυψη με αυτοματοποιημένες δοκιμές. Εάν απαιτούνται χειρωνακτικές παρεμβάσεις, συμπεριλαμβανομένων των δοκιμών, τότε αυτό δεν ισχύει πλέον Συνεχής (συνεχής). Τότε μπορούμε να πούμε ότι ο αγωγός μας συμμορφώνεται μόνο με την πρακτική της Συνεχούς Παράδοσης.
Αξία για την υποδομή αυτοματισμού
Σε αυτήν την ενότητα, θα πρέπει να διευκρινίσω ότι όταν μιλάμε για δοκιμές διεπαφής χρήστη από άκρο σε άκρο, σημαίνει ότι πρέπει να αναπτύξουμε τις αλλαγές και τις σχετικές υπηρεσίες μας σε περιβάλλοντα δοκιμής. Συνεχής ενσωμάτωση - η διαδικασία δεν είναι εφαρμόσιμη για αυτήν την εργασία και πρέπει να φροντίσουμε για την εφαρμογή τουλάχιστον πρακτικών Συνεχούς Παράδοσης. Το Continuous Deployment έχει επίσης νόημα στο πλαίσιο των δοκιμών διεπαφής χρήστη, εάν πρόκειται να τις εκτελέσουμε στην παραγωγή.
Και πριν δούμε την απεικόνιση της αλλαγής της αρχιτεκτονικής, θέλω να πω λίγα λόγια για το GitLab CI. Σε αντίθεση με άλλα εργαλεία CI/CD, το GitLab παρέχει ένα απομακρυσμένο αποθετήριο και πολλές άλλες πρόσθετες δυνατότητες. Έτσι, το GitLab είναι περισσότερο από CI. Περιλαμβάνει διαχείριση πηγαίου κώδικα, ευέλικτη διαχείριση, αγωγούς CI/CD, εργαλεία καταγραφής και συλλογή μετρήσεων εκτός συσκευασίας. Η αρχιτεκτονική GitLab αποτελείται από το Gitlab CI/CD και το GitLab Runner. Ακολουθεί μια σύντομη περιγραφή από την επίσημη ιστοσελίδα:
Το Gitlab CI/CD είναι μια διαδικτυακή εφαρμογή με API που αποθηκεύει την κατάστασή του σε μια βάση δεδομένων, διαχειρίζεται έργα/κατασκευές και παρέχει διεπαφή χρήστη. Το GitLab Runner είναι μια εφαρμογή που επεξεργάζεται εκδόσεις. Μπορεί να αναπτυχθεί χωριστά και να λειτουργεί με το GitLab CI/CD μέσω ενός API. Για δοκιμές που εκτελούνται, χρειάζεστε και το Gitlab instance και το Runner.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία
- Και πολλοί άλλοι
5. Cloud πλατφόρμες
Σύντομη περιγραφή της τεχνολογίας
Σε αυτή την ενότητα θα μιλήσουμε για μια δημοφιλή τάση που ονομάζεται «δημόσια σύννεφα». Παρά τα τεράστια οφέλη που παρέχουν οι τεχνολογίες εικονικοποίησης και κοντέινερ που περιγράφονται παραπάνω, χρειαζόμαστε ακόμα υπολογιστικούς πόρους. Οι εταιρείες αγοράζουν ακριβούς διακομιστές ή νοικιάζουν κέντρα δεδομένων, αλλά σε αυτή την περίπτωση είναι απαραίτητο να κάνουμε υπολογισμούς (μερικές φορές μη ρεαλιστικούς) για το πόσους πόρους θα χρειαστούμε, αν θα τους χρησιμοποιήσουμε 24 ώρες το 7ωρο και για ποιους σκοπούς. Για παράδειγμα, η παραγωγή απαιτεί διακομιστή που λειτουργεί XNUMX/XNUMX, αλλά χρειαζόμαστε παρόμοιους πόρους για δοκιμές εκτός ωρών εργασίας; Εξαρτάται επίσης από τον τύπο της δοκιμής που εκτελείται. Ένα παράδειγμα θα ήταν τα τεστ φορτίου/καταπόνησης που σκοπεύουμε να εκτελέσουμε κατά τις μη εργάσιμες ώρες για να έχουμε αποτελέσματα την επόμενη μέρα. Αλλά σίγουρα η διαθεσιμότητα διακομιστή XNUMX/XNUMX δεν απαιτείται για αυτοματοποιημένες δοκιμές από άκρο σε άκρο και ειδικά για περιβάλλοντα χειροκίνητων δοκιμών. Για τέτοιες περιπτώσεις, θα ήταν καλό να αποκτήσετε όσους πόρους χρειάζονται κατόπιν ζήτησης, να τους χρησιμοποιήσετε και να σταματήσετε να πληρώνετε όταν δεν χρειάζονται πλέον. Επιπλέον, θα ήταν υπέροχο να τα λαμβάνετε αμέσως κάνοντας μερικά κλικ του ποντικιού ή εκτελώντας μερικά σενάρια. Για αυτό χρησιμοποιούνται τα δημόσια σύννεφα. Ας δούμε τον ορισμό:
«Το δημόσιο νέφος ορίζεται ως υπηρεσίες υπολογιστών που προσφέρονται από τρίτους παρόχους μέσω του δημόσιου Διαδικτύου, καθιστώντας τις διαθέσιμες σε οποιονδήποτε θέλει να τις χρησιμοποιήσει ή να τις αγοράσει. Μπορεί να είναι δωρεάν ή να πωλούνται κατ' απαίτηση, επιτρέποντας στους πελάτες να πληρώνουν μόνο ανά χρήση για τους κύκλους της CPU, την αποθήκευση ή το εύρος ζώνης που καταναλώνουν."
Υπάρχει η άποψη ότι τα δημόσια σύννεφα είναι ακριβά. Αλλά η βασική τους ιδέα είναι να μειώσουν το κόστος της εταιρείας. Όπως αναφέρθηκε προηγουμένως, τα δημόσια σύννεφα σάς επιτρέπουν να λαμβάνετε πόρους κατά παραγγελία και να πληρώνετε μόνο για το χρόνο που τους χρησιμοποιείτε. Επίσης, μερικές φορές ξεχνάμε ότι οι εργαζόμενοι λαμβάνουν μισθούς και οι ειδικοί είναι επίσης ένας ακριβός πόρος. Πρέπει να ληφθεί υπόψη ότι τα δημόσια σύννεφα κάνουν την υποστήριξη υποδομών πολύ πιο εύκολη, γεγονός που επιτρέπει στους μηχανικούς να επικεντρωθούν σε πιο σημαντικές εργασίες.
Αξία για την υποδομή αυτοματισμού
Ποιους συγκεκριμένους πόρους χρειαζόμαστε για δοκιμές διεπαφής χρήστη από άκρο σε άκρο; Βασικά πρόκειται για εικονικές μηχανές ή συμπλέγματα (θα μιλήσουμε για το Kubernetes στην επόμενη ενότητα) για την εκτέλεση προγραμμάτων περιήγησης και εξομοιωτών. Όσο περισσότερα προγράμματα περιήγησης και εξομοιωτές θέλουμε να εκτελούνται ταυτόχρονα, τόσο περισσότερη CPU και μνήμη απαιτείται και τόσο περισσότερα χρήματα πρέπει να πληρώσουμε για αυτό. Έτσι, τα δημόσια σύννεφα στο πλαίσιο του αυτοματισμού δοκιμών μάς επιτρέπουν να εκτελούμε έναν μεγάλο αριθμό (100, 200, 1000...) προγραμμάτων περιήγησης/εξομοιωτών κατά παραγγελία, να λαμβάνουμε αποτελέσματα δοκιμών το συντομότερο δυνατό και να σταματήσουμε να πληρώνουμε για τέτοιου είδους τρελά έντασης πόρων εξουσία.
Οι πιο δημοφιλείς πάροχοι cloud είναι οι υπηρεσίες Web Amazon (AWS), Microsoft Azure, Google Cloud Platform (GCP). Ο οδηγός πώς να παρέχει παραδείγματα για τον τρόπο χρήσης του GCP, αλλά γενικά δεν έχει σημασία τι χρησιμοποιείτε για εργασίες αυτοματισμού. Όλα παρέχουν περίπου την ίδια λειτουργικότητα. Συνήθως, για την επιλογή ενός παρόχου, η διοίκηση εστιάζει σε ολόκληρη την υποδομή και τις επιχειρηματικές απαιτήσεις της εταιρείας, κάτι που δεν εμπίπτει στο πεδίο εφαρμογής αυτού του άρθρου. Για τους μηχανικούς αυτοματισμού, θα είναι πιο ενδιαφέρον να συγκρίνουν τη χρήση των παρόχων cloud με τη χρήση πλατφορμών cloud ειδικά για σκοπούς δοκιμής, όπως Sauce Labs, BrowserStack, BitBar κ.λπ. Ας το κάνουμε κι εμείς λοιπόν! Κατά τη γνώμη μου, η Sauce Labs είναι η πιο διάσημη φάρμα δοκιμών cloud, γι' αυτό και τη χρησιμοποίησα για σύγκριση.
GCP vs Sauce Labs για σκοπούς αυτοματισμού:
Ας φανταστούμε ότι πρέπει να εκτελέσουμε 8 δοκιμές ιστού και 8 δοκιμές Android ταυτόχρονα. Για αυτό θα χρησιμοποιήσουμε το GCP και θα τρέξουμε 2 εικονικές μηχανές με το Selenoid. Στο πρώτο θα ανεβάσουμε 8 κοντέινερ με προγράμματα περιήγησης. Στο δεύτερο υπάρχουν 8 κοντέινερ με εξομοιωτές. Ας ρίξουμε μια ματιά στις τιμές:
Για να τρέξουμε ένα κοντέινερ με το Chrome, χρειαζόμαστε n1-πρότυπο-1 αυτοκίνητο. Στην περίπτωση του Android θα είναι n1-πρότυπο-4 για έναν εξομοιωτή. Στην πραγματικότητα, ένας πιο ευέλικτος και φθηνότερος τρόπος είναι να ορίσετε συγκεκριμένες τιμές χρήστη για CPU/Memory, αλλά αυτή τη στιγμή αυτό δεν είναι σημαντικό για σύγκριση με το Sauce Labs.
Και εδώ είναι τα τιμολόγια για τη χρήση του Sauce Labs:
Πιστεύω ότι έχετε ήδη παρατηρήσει τη διαφορά, αλλά θα παρέχω έναν πίνακα με υπολογισμούς για την εργασία μας:
Απαιτούμενοι πόροι
Μηνιαία
Ώρες λειτουργίας(8 π.μ. - 8 μ.μ.)
Ώρες λειτουργίας+ Προκαταβολικά
GCP για τον Ιστό
n1-standard-1 x 8 = n1-standard-8
$194.18
23 ημέρες * 12 ώρες * 0.38 = 104.88 $
23 ημέρες * 12 ώρες * 0.08 = 22.08 $
Sauce Labs for Web
Παράλληλες δοκιμές Virtual Cloud8
$1.559
-
-
GCP για Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 ημέρες * 12 ώρες * 1.52 = 419.52 $
23 ημέρες * 12 ώρες * 0.32 = 88.32 $
Sauce Labs για Android
Παράλληλες δοκιμές Real Device Cloud 8
$1.999
-
-
Όπως μπορείτε να δείτε, η διαφορά στο κόστος είναι τεράστια, ειδικά αν κάνετε δοκιμές μόνο κατά τη διάρκεια μιας δωδεκάωρης περιόδου εργασίας. Αλλά μπορείτε να μειώσετε ακόμη περισσότερο το κόστος εάν χρησιμοποιείτε προκαταβολικά μηχανήματα. Τι είναι αυτό?
Ένα προκαταρκτικό VM είναι ένα παράδειγμα που μπορείτε να δημιουργήσετε και να εκτελέσετε σε πολύ χαμηλότερη τιμή από τις κανονικές παρουσίες. Ωστόσο, το Compute Engine ενδέχεται να τερματίσει (προκαταλάβει) αυτές τις παρουσίες εάν απαιτεί πρόσβαση σε αυτούς τους πόρους για άλλες εργασίες. Οι προκαταρκτικές περιπτώσεις είναι η υπερβολική χωρητικότητα του Compute Engine, επομένως η διαθεσιμότητά τους ποικίλλει ανάλογα με τη χρήση.
Εάν οι εφαρμογές σας είναι ανεκτικές σε σφάλματα και μπορούν να αντέξουν πιθανές προκαταλήψεις παρουσιών, τότε οι προκαταρκτικές παρουσίες μπορούν να μειώσουν σημαντικά το κόστος του Υπολογιστή σας. Για παράδειγμα, οι εργασίες ομαδικής επεξεργασίας μπορούν να εκτελούνται σε προκαταρκτικές παρουσίες. Εάν ορισμένες από αυτές τις περιπτώσεις τερματιστούν κατά τη διάρκεια της επεξεργασίας, η εργασία επιβραδύνεται αλλά δεν σταματά εντελώς. Οι προκαταρκτικές παρουσίες ολοκληρώνουν τις εργασίες ομαδικής επεξεργασίας χωρίς να επιβάλλουν πρόσθετο φόρτο εργασίας στις υπάρχουσες παρουσίες σας και χωρίς να απαιτείται από εσάς να πληρώσετε το πλήρες τίμημα για πρόσθετες κανονικές παρουσίες.
Και ακόμα δεν έχει τελειώσει! Στην πραγματικότητα, είμαι σίγουρος ότι κανείς δεν κάνει τεστ για 12 ώρες χωρίς διάλειμμα. Και αν ναι, τότε μπορείτε να ξεκινήσετε και να σταματήσετε αυτόματα τις εικονικές μηχανές όταν δεν τις χρειάζονται. Ο πραγματικός χρόνος χρήσης μπορεί να μειωθεί σε 6 ώρες την ημέρα. Στη συνέχεια, η πληρωμή στο πλαίσιο της εργασίας μας θα μειωθεί στα 11 $ ανά μήνα για 8 προγράμματα περιήγησης. Δεν είναι υπέροχο αυτό; Αλλά με τα προκαταρκτικά μηχανήματα πρέπει να είμαστε προσεκτικοί και προετοιμασμένοι για διακοπές και αστάθεια, αν και αυτές οι καταστάσεις μπορούν να προβλεφθούν και να αντιμετωπιστούν σε λογισμικό. Αξίζει τον κόπο!
Αλλά σε καμία περίπτωση δεν λέω «ποτέ μη χρησιμοποιείτε cloud test farms». Έχουν μια σειρά από πλεονεκτήματα. Πρώτα απ 'όλα, αυτό δεν είναι απλώς μια εικονική μηχανή, αλλά μια ολοκληρωμένη λύση αυτοματισμού δοκιμής με ένα σύνολο λειτουργιών: απομακρυσμένη πρόσβαση, αρχεία καταγραφής, στιγμιότυπα οθόνης, εγγραφή βίντεο, διάφορα προγράμματα περιήγησης και φυσικές κινητές συσκευές. Σε πολλές περιπτώσεις, αυτό μπορεί να είναι μια ουσιαστική κομψή εναλλακτική. Οι πλατφόρμες δοκιμών είναι ιδιαίτερα χρήσιμες για την αυτοματοποίηση IOS, όταν τα δημόσια σύννεφα μπορούν να προσφέρουν μόνο συστήματα Linux/Windows. Θα μιλήσουμε όμως για το iOS στα επόμενα άρθρα. Συνιστώ να εξετάζετε πάντα την κατάσταση και να ξεκινάτε από τις εργασίες: σε ορισμένες περιπτώσεις είναι φθηνότερο και πιο αποτελεσματικό να χρησιμοποιείτε δημόσια σύννεφα και σε άλλες οι πλατφόρμες δοκιμών αξίζουν σίγουρα τα χρήματα που δαπανώνται.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία:
6. Ενορχήστρωση
Σύντομη περιγραφή της τεχνολογίας
Έχω καλά νέα - είμαστε σχεδόν στο τέλος του άρθρου! Προς το παρόν, η υποδομή αυτοματισμού μας αποτελείται από δοκιμές ιστού και Android, τις οποίες εκτελούμε μέσω του GitLab CI παράλληλα, χρησιμοποιώντας εργαλεία με δυνατότητα Docker: Selenium grid και Selenoid. Επιπλέον, χρησιμοποιούμε εικονικές μηχανές που δημιουργούνται μέσω GCP για να φιλοξενούν κοντέινερ με προγράμματα περιήγησης και εξομοιωτές. Για να μειώσουμε το κόστος, ξεκινάμε αυτές τις εικονικές μηχανές μόνο κατόπιν ζήτησης και τις σταματάμε όταν δεν εκτελούνται δοκιμές. Υπάρχει κάτι άλλο που μπορεί να βελτιώσει τις υποδομές μας; Η απάντηση είναι ναι! Γνωρίστε την Kubernetes (K8s)!
Αρχικά, ας δούμε πώς σχετίζονται μεταξύ τους οι λέξεις ενορχήστρωση, σύμπλεγμα και Kubernetes. Σε υψηλό επίπεδο, η ενορχήστρωση είναι το σύστημα που αναπτύσσει και διαχειρίζεται εφαρμογές. Για τον αυτοματισμό δοκιμής, τέτοιες εφαρμογές σε εμπορευματοκιβώτια είναι το πλέγμα Selenium και το Selenoid. Το Docker και το K8 αλληλοσυμπληρώνονται. Το πρώτο χρησιμοποιείται για την ανάπτυξη εφαρμογών, το δεύτερο για ενορχήστρωση. Με τη σειρά του, το K8s είναι ένα σύμπλεγμα. Η αποστολή του συμπλέγματος είναι να χρησιμοποιεί VM ως κόμβους, που σας επιτρέπει να εγκαταστήσετε διάφορες λειτουργίες, προγράμματα και υπηρεσίες σε έναν διακομιστή (cluster). Εάν κάποιος από τους κόμβους αποτύχει, άλλοι Κόμβοι θα παραλάβουν, γεγονός που διασφαλίζει την αδιάλειπτη λειτουργία της εφαρμογής μας. Επιπλέον, το K8s διαθέτει σημαντική λειτουργικότητα που σχετίζεται με την κλιμάκωση, χάρη στην οποία λαμβάνουμε αυτόματα τη βέλτιστη ποσότητα πόρων με βάση το φορτίο και ορίζουμε όρια.
Στην πραγματικότητα, η μη αυτόματη ανάπτυξη του Kubernetes από την αρχή δεν είναι καθόλου ασήμαντη εργασία. Θα αφήσω έναν σύνδεσμο για τον περίφημο οδηγό πώς να κάνετε "Kubernetes The Hard Way" και αν σας ενδιαφέρει μπορείτε να τον εξασκήσετε. Αλλά, ευτυχώς, υπάρχουν εναλλακτικές μέθοδοι και εργαλεία. Ο ευκολότερος τρόπος είναι να χρησιμοποιήσετε το Google Kubernetes Engine (GKE) στο GCP, το οποίο θα σας επιτρέψει να αποκτήσετε ένα έτοιμο σύμπλεγμα με λίγα κλικ. Συνιστώ να χρησιμοποιήσετε αυτήν την προσέγγιση για να ξεκινήσετε τη μάθηση, καθώς θα σας επιτρέψει να εστιάσετε στο να μάθετε πώς να χρησιμοποιείτε τα K8 για τις εργασίες σας αντί να μάθετε πώς τα εσωτερικά στοιχεία πρέπει να ενσωματώνονται μεταξύ τους.
Αξία για την υποδομή αυτοματισμού
Ας ρίξουμε μια ματιά σε μερικά σημαντικά χαρακτηριστικά που παρέχει το K8s:
- ανάπτυξη εφαρμογών: χρήση συμπλέγματος πολλαπλών κόμβων αντί για VM.
- δυναμική κλιμάκωση: μειώνει το κόστος των πόρων που χρησιμοποιούνται μόνο κατόπιν ζήτησης.
- αυτοθεραπεία: αυτόματη ανάκτηση λοβών (με αποτέλεσμα να αποκαθίστανται και τα δοχεία).
- διάθεση ενημερώσεων και επαναφορά αλλαγών χωρίς χρόνο διακοπής λειτουργίας: η ενημέρωση εργαλείων, προγραμμάτων περιήγησης και εξομοιωτών δεν διακόπτει την εργασία των τρεχόντων χρηστών
Αλλά το K8 δεν είναι ακόμα μια ασημένια σφαίρα. Για να κατανοήσουμε όλα τα πλεονεκτήματα και τους περιορισμούς στο πλαίσιο των εργαλείων που εξετάζουμε (πλέγμα Selenium, Selenoid), θα συζητήσουμε εν συντομία τη δομή των K8. Το σύμπλεγμα περιέχει δύο τύπους κόμβων: Κύριους κόμβους και κόμβους εργαζομένων. Οι κύριοι κόμβοι είναι υπεύθυνοι για τις αποφάσεις διαχείρισης, ανάπτυξης και προγραμματισμού. Οι κόμβοι εργαζομένων είναι εκεί όπου ξεκινούν οι εφαρμογές. Οι κόμβοι περιέχουν επίσης ένα περιβάλλον χρόνου εκτέλεσης κοντέινερ. Στην περίπτωσή μας, αυτό είναι το Docker, το οποίο είναι υπεύθυνο για λειτουργίες που σχετίζονται με κοντέινερ. Υπάρχουν όμως και εναλλακτικές λύσεις, για παράδειγμα. Είναι σημαντικό να κατανοήσουμε ότι η απολέπιση ή η αυτοθεραπεία δεν ισχύει άμεσα για τα δοχεία. Αυτό υλοποιείται με την προσθήκη/μείωση του αριθμού των λοβών, τα οποία με τη σειρά τους περιέχουν δοχεία (συνήθως ένα κοντέινερ ανά ομάδα, αλλά ανάλογα με την εργασία μπορεί να υπάρχουν περισσότερα). Η ιεραρχία υψηλού επιπέδου αποτελείται από κόμβους εργαζομένων, στο εσωτερικό των οποίων υπάρχουν λοβοί, μέσα στους οποίους ανυψώνονται δοχεία.
Η δυνατότητα κλιμάκωσης είναι βασική και μπορεί να εφαρμοστεί και στους δύο κόμβους μέσα σε μια ομάδα κόμβων συμπλέγματος και σε ομάδες εντός ενός κόμβου. Υπάρχουν 2 τύποι κλιμάκωσης που ισχύουν τόσο για τους κόμβους όσο και για τους λοβούς. Ο πρώτος τύπος είναι οριζόντιος - η κλιμάκωση πραγματοποιείται αυξάνοντας τον αριθμό των κόμβων/λοβών. Αυτός ο τύπος είναι προτιμότερος. Ο δεύτερος τύπος είναι, κατά συνέπεια, κάθετος. Η κλιμάκωση πραγματοποιείται αυξάνοντας το μέγεθος των κόμβων/λοβών και όχι τον αριθμό τους.
Τώρα ας δούμε τα εργαλεία μας στο πλαίσιο των παραπάνω όρων.
Πλέγμα σεληνίου
Όπως αναφέρθηκε προηγουμένως, το πλέγμα σεληνίου είναι ένα πολύ δημοφιλές εργαλείο και δεν αποτελεί έκπληξη το γεγονός ότι έχει τοποθετηθεί σε δοχεία. Επομένως, δεν αποτελεί έκπληξη το γεγονός ότι το πλέγμα Selenium μπορεί να αναπτυχθεί στα K8. Ένα παράδειγμα για το πώς να το κάνετε αυτό μπορείτε να βρείτε στο επίσημο αποθετήριο του K8. Ως συνήθως, επισυνάπτω συνδέσμους στο τέλος της ενότητας. Επιπλέον, ο οδηγός πώς να δείχνει πώς να το κάνετε αυτό στο Terraform. Υπάρχουν επίσης οδηγίες για τον τρόπο κλιμάκωσης του αριθμού των pods που περιέχουν κοντέινερ προγράμματος περιήγησης. Αλλά η λειτουργία αυτόματης κλιμάκωσης στο πλαίσιο των K8 δεν είναι ακόμα μια απολύτως προφανής εργασία. Όταν ξεκίνησα να σπουδάζω, δεν βρήκα καμία πρακτική καθοδήγηση ή συστάσεις. Μετά από αρκετές μελέτες και πειράματα με την υποστήριξη της ομάδας DevOps, επιλέξαμε την προσέγγιση της ανύψωσης κοντέινερ με τα απαραίτητα προγράμματα περιήγησης μέσα σε ένα pod, το οποίο βρίσκεται μέσα σε έναν κόμβο εργασίας. Αυτή η μέθοδος μας επιτρέπει να εφαρμόσουμε τη στρατηγική της οριζόντιας κλιμάκωσης των κόμβων αυξάνοντας τον αριθμό τους. Ελπίζω ότι αυτό θα αλλάξει στο μέλλον και θα βλέπουμε όλο και περισσότερες περιγραφές καλύτερων προσεγγίσεων και έτοιμων λύσεων, ειδικά μετά την κυκλοφορία του πλέγματος Selenium 4 με αλλαγμένη εσωτερική αρχιτεκτονική.
Σεληνοειδές:
Η ανάπτυξη σεληνοειδών στα K8 είναι αυτή τη στιγμή η μεγαλύτερη απογοήτευση. Δεν είναι συμβατά. Θεωρητικά, μπορούμε να σηκώσουμε ένα κοντέινερ Selenoid μέσα σε ένα pod, αλλά όταν το Selenoid ξεκινήσει να εκκινεί κοντέινερ με προγράμματα περιήγησης, θα εξακολουθούν να βρίσκονται μέσα στο ίδιο pod. Αυτό καθιστά αδύνατη την κλιμάκωση και, ως εκ τούτου, η εργασία του Selenoid μέσα σε ένα σύμπλεγμα δεν θα διαφέρει από την εργασία μέσα σε μια εικονική μηχανή. Τέλος της ιστορίας.
Σελήνη:
Γνωρίζοντας αυτό το σημείο συμφόρησης όταν εργάζεστε με το Selenoid, οι προγραμματιστές κυκλοφόρησαν ένα πιο ισχυρό εργαλείο που ονομάζεται Moon. Αυτό το εργαλείο σχεδιάστηκε αρχικά για να λειτουργεί με Kubernetes και, ως εκ τούτου, η δυνατότητα αυτόματης κλιμάκωσης μπορεί και πρέπει να χρησιμοποιηθεί. Επιπλέον, θα έλεγα ότι αυτή τη στιγμή είναι μονό ένα εργαλείο στον κόσμο του σεληνίου, το οποίο διαθέτει εγγενή υποστήριξη συμπλέγματος K8 από το κουτί (δεν είναι πλέον διαθέσιμο, δείτε το επόμενο εργαλείο ). Τα βασικά χαρακτηριστικά του Moon που παρέχουν αυτήν την υποστήριξη είναι:
Εντελώς ανιθαγενής. Το Selenoid αποθηκεύει στη μνήμη πληροφορίες σχετικά με τις τρέχουσες περιόδους λειτουργίας του προγράμματος περιήγησης. Εάν για κάποιο λόγο η διεργασία του διακοπεί — τότε όλες οι συνεδρίες που εκτελούνται χάνονται. Το Moon, αντιθέτως, δεν έχει εσωτερική κατάσταση και μπορεί να αναπαραχθεί σε κέντρα δεδομένων. Οι περίοδοι λειτουργίας του προγράμματος περιήγησης παραμένουν ζωντανές ακόμα και αν ένα ή περισσότερα αντίγραφα απορριφθούν.
Έτσι, το Moon είναι μια εξαιρετική λύση, αλλά υπάρχει ένα πρόβλημα: δεν είναι δωρεάν. Η τιμή εξαρτάται από τον αριθμό των συνεδριών. Μπορείτε να εκτελέσετε μόνο 0-4 συνεδρίες δωρεάν, κάτι που δεν είναι ιδιαίτερα χρήσιμο. Αλλά, ξεκινώντας από την πέμπτη συνεδρία, θα πρέπει να πληρώσετε 5 $ για καθεμία. Η κατάσταση μπορεί να διαφέρει από εταιρεία σε εταιρεία, αλλά στην περίπτωσή μας, η χρήση της Σελήνης είναι άσκοπη. Όπως περιέγραψα παραπάνω, μπορούμε να τρέξουμε VM με Selenium Grid κατά παραγγελία ή να αυξήσουμε τον αριθμό των κόμβων στο σύμπλεγμα. Για περίπου έναν αγωγό, εκκινούμε 500 προγράμματα περιήγησης και σταματάμε όλους τους πόρους μετά την ολοκλήρωση των δοκιμών. Εάν χρησιμοποιούσαμε το Moon, θα έπρεπε να πληρώνουμε επιπλέον 500 x 5 = 2500 $ το μήνα, ανεξάρτητα από το πόσο συχνά κάνουμε δοκιμές. Και πάλι, δεν λέω να μην χρησιμοποιήσετε το Moon. Για τις εργασίες σας, αυτή μπορεί να είναι μια απαραίτητη λύση, για παράδειγμα, εάν έχετε πολλά έργα/ομάδες στον οργανισμό σας και χρειάζεστε ένα τεράστιο κοινό σύμπλεγμα για όλους. Όπως πάντα, αφήνω έναν σύνδεσμο στο τέλος και προτείνω να κάνετε όλους τους απαραίτητους υπολογισμούς στο πλαίσιο της εργασίας σας.
Καλλιστώ: (Προσοχή! Αυτό δεν υπάρχει στο αρχικό άρθρο και περιέχεται μόνο στη ρωσική μετάφραση)
Όπως είπα, το σελήνιο είναι ένα πολύ δημοφιλές εργαλείο και ο τομέας της πληροφορικής αναπτύσσεται πολύ γρήγορα. Ενώ δούλευα για τη μετάφραση, ένα νέο πολλά υποσχόμενο εργαλείο που ονομάζεται Callisto εμφανίστηκε στο διαδίκτυο (γεια σας Κυπαρίσσι και άλλοι δολοφόνοι του σεληνίου). Λειτουργεί εγγενώς με τα K8 και σας επιτρέπει να εκτελείτε δοχεία Selenoid σε pods, κατανεμημένα στους κόμβους. Όλα λειτουργούν αμέσως, συμπεριλαμβανομένης της αυτόματης κλιμάκωσης. Φανταστικό, αλλά πρέπει να δοκιμαστεί. Έχω ήδη καταφέρει να αναπτύξω αυτό το εργαλείο και να εκτελέσω αρκετά πειράματα. Αλλά είναι πολύ νωρίς για να βγάλουμε συμπεράσματα, αφού λάβω αποτελέσματα σε μεγάλη απόσταση, ίσως θα κάνω μια ανασκόπηση σε μελλοντικά άρθρα. Προς το παρόν αφήνω μόνο συνδέσμους για ανεξάρτητη έρευνα.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση
Παρόμοια εργαλεία
7. Η υποδομή ως κώδικας (IaC)
Σύντομη περιγραφή της τεχνολογίας
Και ερχόμαστε τώρα στην τελευταία ενότητα. Συνήθως, αυτή η τεχνολογία και οι σχετικές εργασίες δεν είναι ευθύνη των μηχανικών αυτοματισμού. Και υπάρχουν λόγοι για αυτό. Πρώτον, σε πολλούς οργανισμούς, τα θέματα υποδομής βρίσκονται υπό τον έλεγχο του τμήματος DevOps και οι ομάδες ανάπτυξης δεν ενδιαφέρονται πραγματικά για το τι κάνει τον αγωγό να λειτουργεί και πώς όλα όσα συνδέονται με αυτόν πρέπει να υποστηρίζονται. Δεύτερον, ας είμαστε ειλικρινείς, η πρακτική της Υποδομής ως Κώδικα (IaC) εξακολουθεί να μην υιοθετείται σε πολλές εταιρείες. Αλλά σίγουρα έχει γίνει μια δημοφιλής τάση και είναι σημαντικό να προσπαθήσουμε να εμπλακούμε στις διαδικασίες, τις προσεγγίσεις και τα εργαλεία που σχετίζονται με αυτό. Ή τουλάχιστον μείνετε ενημερωμένοι.
Ας ξεκινήσουμε με το κίνητρο για τη χρήση αυτής της προσέγγισης. Έχουμε ήδη συζητήσει ότι για να εκτελέσουμε δοκιμές στο GitlabCI, θα χρειαστούμε τουλάχιστον τους πόρους για την εκτέλεση του Gitlab Runner. Και για να τρέξουμε κοντέινερ με προγράμματα περιήγησης/εξομοιωτές, πρέπει να κρατήσουμε ένα VM ή ένα σύμπλεγμα. Εκτός από τη δοκιμή πόρων, χρειαζόμαστε μια σημαντική ποσότητα χωρητικότητας για την υποστήριξη περιβαλλόντων ανάπτυξης, σταδιοποίησης, παραγωγής, που περιλαμβάνει επίσης βάσεις δεδομένων, αυτόματα χρονοδιαγράμματα, διαμορφώσεις δικτύου, εξισορροπητές φορτίου, δικαιώματα χρήστη κ.λπ. Το βασικό ζήτημα είναι η προσπάθεια που απαιτείται για να στηριχθεί όλο αυτό. Υπάρχουν διάφοροι τρόποι με τους οποίους μπορούμε να κάνουμε αλλαγές και να διαθέσουμε ενημερώσεις. Για παράδειγμα, στο πλαίσιο του GCP, μπορούμε να χρησιμοποιήσουμε την κονσόλα διεπαφής χρήστη στο πρόγραμμα περιήγησης και να εκτελέσουμε όλες τις ενέργειες κάνοντας κλικ σε κουμπιά. Μια εναλλακτική λύση θα ήταν η χρήση κλήσεων API για αλληλεπίδραση με οντότητες cloud ή η χρήση του βοηθητικού προγράμματος γραμμής εντολών gcloud για την εκτέλεση των επιθυμητών χειρισμών. Αλλά με έναν πραγματικά μεγάλο αριθμό διαφορετικών οντοτήτων και στοιχείων υποδομής, καθίσταται δύσκολο ή ακόμα και αδύνατο να εκτελεστούν όλες οι λειτουργίες χειροκίνητα. Επιπλέον, όλες αυτές οι χειροκίνητες ενέργειες είναι ανεξέλεγκτες. Δεν μπορούμε να τα υποβάλουμε για έλεγχο πριν από την εκτέλεση, να χρησιμοποιήσουμε ένα σύστημα ελέγχου έκδοσης και να επαναφέρουμε γρήγορα τις αλλαγές που οδήγησαν στο συμβάν. Για την επίλυση τέτοιων προβλημάτων, οι μηχανικοί δημιούργησαν και δημιούργησαν αυτόματα σενάρια bash/shell, τα οποία δεν είναι πολύ καλύτερα από τις προηγούμενες μεθόδους, καθώς δεν είναι τόσο εύκολο να διαβαστούν, να κατανοηθούν, να διατηρηθούν και να τροποποιηθούν σε διαδικαστικό στυλ.
Σε αυτό το άρθρο και τον οδηγό τρόπου χρήσης, χρησιμοποιώ 2 εργαλεία που σχετίζονται με την πρακτική IaC. Αυτά είναι τα Terraform και Ansible. Μερικοί άνθρωποι πιστεύουν ότι δεν έχει νόημα να τα χρησιμοποιούν ταυτόχρονα, καθώς η λειτουργικότητά τους είναι παρόμοια και είναι εναλλάξιμα. Αλλά το γεγονός είναι ότι αρχικά τους ανατίθενται εντελώς διαφορετικά καθήκοντα. Και το γεγονός ότι αυτά τα εργαλεία θα πρέπει να αλληλοσυμπληρώνονται επιβεβαιώθηκε σε μια κοινή παρουσίαση από προγραμματιστές που εκπροσωπούν τη HashiCorp και την RedHat. Η εννοιολογική διαφορά είναι ότι το Terraform είναι ένα εργαλείο παροχής για τη διαχείριση των ίδιων των διακομιστών. Ενώ το Ansible είναι ένα εργαλείο διαχείρισης παραμέτρων του οποίου η αποστολή είναι η εγκατάσταση, η διαμόρφωση και η διαχείριση λογισμικού σε αυτούς τους διακομιστές.
Ένα άλλο βασικό χαρακτηριστικό αυτών των εργαλείων είναι το στυλ κωδικοποίησης. Σε αντίθεση με το bash και το Ansible, το Terraform χρησιμοποιεί ένα δηλωτικό στυλ που βασίζεται σε μια περιγραφή της επιθυμητής τελικής κατάστασης που πρέπει να επιτευχθεί ως αποτέλεσμα της εκτέλεσης. Για παράδειγμα, αν πρόκειται να δημιουργήσουμε 10 VM και να εφαρμόσουμε τις αλλαγές μέσω του Terraform, τότε θα πάρουμε 10 VM. Εάν εκτελέσουμε ξανά το σενάριο, δεν θα συμβεί τίποτα αφού έχουμε ήδη 10 VM και η Terraform το γνωρίζει αυτό επειδή αποθηκεύει την τρέχουσα κατάσταση της υποδομής σε ένα αρχείο κατάστασης. Αλλά το Ansible χρησιμοποιεί μια διαδικαστική προσέγγιση και, αν του ζητήσετε να δημιουργήσει 10 VM, τότε στην πρώτη κυκλοφορία θα λάβουμε 10 VM, παρόμοια με το Terraform. Αλλά μετά την επανεκκίνηση θα έχουμε ήδη 20 VM. Αυτή είναι η σημαντική διαφορά. Στο διαδικαστικό στυλ, δεν αποθηκεύουμε την τρέχουσα κατάσταση και απλώς περιγράφουμε μια ακολουθία βημάτων που πρέπει να εκτελεστούν. Φυσικά, μπορούμε να χειριστούμε διάφορες καταστάσεις, να προσθέσουμε αρκετούς ελέγχους για την ύπαρξη πόρων και την τρέχουσα κατάσταση, αλλά δεν έχει νόημα να σπαταλάμε τον χρόνο μας και να καταβάλλουμε προσπάθεια για τον έλεγχο αυτής της λογικής. Επιπλέον, αυτό αυξάνει τον κίνδυνο να κάνετε λάθη.
Συνοψίζοντας όλα τα παραπάνω, μπορούμε να συμπεράνουμε ότι το Terraform και η δηλωτική σημείωση είναι πιο κατάλληλο εργαλείο για την παροχή διακομιστών. Αλλά είναι καλύτερο να αναθέσετε το έργο της διαχείρισης διαμόρφωσης στο Ansible. Με αυτό το θέμα, ας δούμε τις περιπτώσεις χρήσης στο πλαίσιο του αυτοματισμού.
Αξία για την υποδομή αυτοματισμού
Το μόνο σημαντικό πράγμα που πρέπει να κατανοήσουμε εδώ είναι ότι η υποδομή αυτοματισμού δοκιμής θα πρέπει να θεωρείται ως μέρος ολόκληρης της υποδομής της εταιρείας. Αυτό σημαίνει ότι όλες οι πρακτικές IaC πρέπει να εφαρμόζονται παγκοσμίως στους πόρους ολόκληρου του οργανισμού. Το ποιος είναι υπεύθυνος για αυτό εξαρτάται από τις διαδικασίες σας. Η ομάδα DevOps είναι πιο έμπειρη σε αυτά τα ζητήματα, βλέπει ολόκληρη την εικόνα του τι συμβαίνει. Ωστόσο, οι μηχανικοί QA εμπλέκονται περισσότερο στη διαδικασία του αυτοματισμού κτιρίων και στη δομή του αγωγού, γεγονός που τους επιτρέπει να βλέπουν καλύτερα όλες τις απαιτούμενες αλλαγές και ευκαιρίες για βελτίωση. Η καλύτερη επιλογή είναι να συνεργαστείτε, να ανταλλάξετε γνώσεις και ιδέες για να πετύχετε το αναμενόμενο αποτέλεσμα.
Ακολουθούν μερικά παραδείγματα χρήσης Terraform και Ansible στο πλαίσιο του αυτοματισμού δοκιμής και των εργαλείων που συζητήσαμε προηγουμένως:
1. Περιγράψτε τα απαραίτητα χαρακτηριστικά και τις παραμέτρους των VM και των συμπλεγμάτων χρησιμοποιώντας Terraform.
2. Χρησιμοποιώντας το Ansible, εγκαταστήστε τα απαραίτητα εργαλεία για τη δοκιμή: docker, Selenoid, Selenium Grid και πραγματοποιήστε λήψη των απαιτούμενων εκδόσεων προγραμμάτων περιήγησης/εξομοιωτών.
3. Χρησιμοποιώντας το Terraform, περιγράψτε τα χαρακτηριστικά του VM στο οποίο θα κυκλοφορήσει το GitLab Runner.
4. Εγκαταστήστε το GitLab Runner και τα απαραίτητα συνοδευτικά εργαλεία χρησιμοποιώντας το Ansible, ορίστε ρυθμίσεις και διαμορφώσεις.
Απεικόνιση της τρέχουσας κατάστασης των υποδομών
Σύνδεσμοι για εξερεύνηση:
Παρόμοια εργαλεία
Ας το συνοψίσουμε!
Βήμα
Τεχνολογία
Εργαλεία
Αξία για την υποδομή αυτοματισμού
1
Τοπικό τρέξιμο
Node.js, Selenium, Appium
- Τα πιο δημοφιλή εργαλεία για web και κινητά
- Υποστηρίζει πολλές γλώσσες και πλατφόρμες (συμπεριλαμβανομένου του Node.js)
2
Συστήματα ελέγχου έκδοσης
Git
- Παρόμοια οφέλη με τον κώδικα ανάπτυξης
3
Εμπορευματοποίηση
Docker, πλέγμα Selenium, Selenoid (Web, Android)
- Εκτέλεση δοκιμών παράλληλα
- Απομονωμένα περιβάλλοντα
- Απλές, ευέλικτες αναβαθμίσεις εκδόσεων
- Δυναμική διακοπή αχρησιμοποίητων πόρων
- Εύκολη εγκατάσταση
4
CI/CD
Gitlab CI
- Δοκιμάζει μέρος του αγωγού
- Γρήγορη ανατροφοδότηση
- Ορατότητα για όλη την εταιρεία/ομάδα
5
Πλατφόρμες Cloud
Πλατφόρμα Google Cloud
- Πόροι κατά παραγγελία (πληρώνουμε μόνο όταν χρειάζεται)
- Εύκολη διαχείριση και ενημέρωση
- Ορατότητα και έλεγχος όλων των πόρων
6
Ορχήστρα
Kubernetes
Στο πλαίσιο των κοντέινερ με προγράμματα περιήγησης/εξομοιωτές εντός ομάδων:
- Κλιμάκωση/αυτόματη κλιμάκωση
- Αυτοίαση
- Ενημερώσεις και επαναλήψεις χωρίς διακοπή
7
Η υποδομή ως κωδικός (IaC)
Terraform, Ansible
- Παρόμοια οφέλη με αναπτυξιακές υποδομές
- Όλα τα πλεονεκτήματα της έκδοσης κώδικα
- Εύκολο να κάνετε αλλαγές και να διατηρήσετε
- Πλήρως αυτοματοποιημένο
Διαγράμματα νοητικών χαρτών: εξέλιξη της υποδομής
βήμα 1: Τοπικό
βήμα 2: VCS
Βήμα 3: Εμπορευματοκιβώτια
βήμα 4: CI/CD
Βήμα 5: Πλατφόρμες Cloud
Βήμα 6: Ενορχήστρωση
βήμα 7: IaC
Ποιο είναι το επόμενο;
Λοιπόν, αυτό είναι το τέλος του άρθρου. Εν κατακλείδι, θα ήθελα να συνάψω κάποιες συμφωνίες μαζί σας.
Από την πλευρά σου
Όπως είπα στην αρχή, θα ήθελα το άρθρο να είναι πρακτικό και να σας βοηθήσει να εφαρμόσετε τις γνώσεις που αποκτήσατε σε πραγματική εργασία. Προσθέτω ξανά.
Αλλά ακόμα και μετά από αυτό, μην σταματήσετε, εξασκηθείτε, μελετήστε σχετικούς συνδέσμους και βιβλία, μάθετε πώς λειτουργεί στην εταιρεία σας, βρείτε μέρη που μπορούν να βελτιωθούν και λάβετε μέρος σε αυτήν. Καλή τύχη!
Από την πλευρά μου
Από τον τίτλο μπορείτε να δείτε ότι αυτό ήταν μόνο το πρώτο μέρος. Παρά το γεγονός ότι αποδείχθηκε αρκετά μεγάλο, σημαντικά θέματα εξακολουθούν να μην καλύπτονται εδώ. Στο δεύτερο μέρος, σκοπεύω να εξετάσω την υποδομή αυτοματισμού στο πλαίσιο του IOS. Λόγω των περιορισμών της Apple για την εκτέλεση προσομοιωτών iOS μόνο σε συστήματα macOS, η γκάμα των λύσεών μας έχει περιοριστεί. Για παράδειγμα, δεν μπορούμε να χρησιμοποιήσουμε το Docker για την εκτέλεση του προσομοιωτή ή τα δημόσια σύννεφα για την εκτέλεση εικονικών μηχανών. Αυτό όμως δεν σημαίνει ότι δεν υπάρχουν άλλες εναλλακτικές. Θα προσπαθήσω να σας κρατάω ενήμερους με προηγμένες λύσεις και σύγχρονα εργαλεία!
Επίσης, δεν έχω αναφέρει αρκετά μεγάλα θέματα σχετικά με την παρακολούθηση. Στο Μέρος 3, θα εξετάσω τα πιο δημοφιλή εργαλεία παρακολούθησης υποδομής και ποια δεδομένα και μετρήσεις πρέπει να ληφθούν υπόψη.
Και τελικά. Στο μέλλον, σκοπεύω να κυκλοφορήσω ένα μάθημα βίντεο για την κατασκευή υποδομών δοκιμής και δημοφιλή εργαλεία. Επί του παρόντος, υπάρχουν αρκετά μαθήματα και διαλέξεις για τα DevOps στο Διαδίκτυο, αλλά όλα τα υλικά παρουσιάζονται στο πλαίσιο της ανάπτυξης και όχι του αυτοματισμού δοκιμής. Σε αυτό το θέμα, χρειάζομαι πραγματικά σχόλια σχετικά με το εάν ένα τέτοιο μάθημα θα είναι ενδιαφέρον και πολύτιμο για την κοινότητα των δοκιμαστών και των μηχανικών αυτοματισμού. Ευχαριστώ εκ των προτέρων!
Πηγή: www.habr.com