Εκσυγχρονισμός legacy εφαρμογής: από πού να ξεκινήσετε

Ονομάστε τον επιχειρησιακό λόγο πριν αγγίξετε τον κώδικα

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

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

Αξιολογήστε τον κώδικα και την παραγωγή πριν αποφασίσετε οτιδήποτε

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

• Εκδόσεις περιβάλλοντος εκτέλεσης, framework και βιβλιοθηκών, και ποιες από αυτές δεν λαμβάνουν πλέον διορθώσεις ασφαλείας
• Ποια μέρη αλλάζουν συχνότερα και ποια χαλάνε συχνότερα, από το ιστορικό εκδόσεων και το αρχείο περιστατικών
• Κάλυψη από τεστ στις διαδρομές στις οποίες βασίζεται η επιχείρηση
• Πώς γίνεται το build, η ρύθμιση και το deploy της εφαρμογής, και ποιος μπορεί να τα κάνει
• Το μοντέλο δεδομένων, το μέγεθός του και ποια άλλα συστήματα διαβάζουν ή γράφουν στην ίδια βάση δεδομένων
• Οι άνθρωποι που γνωρίζουν το σύστημα, και τι γνωρίζουν μόνο αυτοί

Σταθεροποιήστε πρώτα την παραγωγή, ώστε η δουλειά να έχει σταθερή βάση

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

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

Φτιάξτε ένα δίχτυ ασφαλείας από τεστ γύρω από τη συμπεριφορά στην οποία βασίζεστε

Ο legacy κώδικας συνήθως έχει λίγα τεστ, και η τεκμηριωμένη συμπεριφορά του σπάνια ταιριάζει με την πραγματική. Πριν αλλάξετε τη δομή, γράψτε τεστ χαρακτηρισμού (characterization tests): τεστ που καταγράφουν τι κάνει σήμερα το σύστημα, μαζί με τις παράξενες οριακές περιπτώσεις του, ώστε κάθε αλλαγή συμπεριφοράς να εμφανίζεται ως αποτυχημένο τεστ.

Ξεκινήστε από τα άκρα, με τεστ που καλούν την εφαρμογή μέσω του API ή της διεπαφής χρήστη και ελέγχουν τα αποτελέσματα, γιατί αντέχουν στις εσωτερικές αλλαγές. Για υπολογισμούς και αναφορές, περάστε πραγματικές εισόδους από τον παλιό και τον νέο κώδικα και συγκρίνετε τις εξόδους. Προσθέστε πιο λεπτομερή τεστ σε κάθε μέρος καθώς το αναδιαρθρώνετε. Το άρθρο μας για την αναβάθμιση μιας κρίσιμης εφαρμογής Java 8 δείχνει το ίδιο δίχτυ ασφαλείας εφαρμοσμένο σε αναβάθμιση περιβάλλοντος εκτέλεσης.

Αντικαταστήστε το σύστημα κομμάτι κομμάτι αντί να το ξαναγράψετε

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

Η συνηθισμένη εναλλακτική είναι το μοτίβο strangler fig. Βάλτε ένα επίπεδο δρομολόγησης, όπως ένα reverse proxy ή ένα API gateway, μπροστά από την παλαιά εφαρμογή. Φτιάξτε μία δυνατότητα τη φορά στον νέο κώδικα και δρομολογήστε την κίνηση αυτής της δυνατότητας προς αυτόν μόλις αποδειχθεί ότι λειτουργεί. Το παλιό σύστημα μικραίνει μέχρι να μπορεί να απενεργοποιηθεί, και η επιχείρηση κερδίζει αξία σε κάθε βήμα.

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

Αντιμετωπίστε τα δεδομένα ως ξεχωριστή μετάβαση

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

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

Βάλτε τη δουλειά σε σειρά ανάλογα με ρίσκο και αξία, και δείξτε πρόοδο νωρίς

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

Κρατήστε το σχέδιο σύντομο και αναθεωρήστε το μετά από κάθε βήμα, γιατί όσα μαθαίνετε θα αλλάξουν τη σειρά. Οι μηχανικοί μας έχουν δουλέψει έτσι σε κρίσιμα συστήματα. Μέσω της Sopra Steria, ηγήθηκαν της μετάβασης από Java 8 σε 16 μιας κρίσιμης εφαρμογής ενδοημερήσιας διαπραγμάτευσης φυσικού αερίου, και ως μέρος της ομάδας του προγράμματος cloud της Crédit Agricole αξιολογήσαμε κάθε εφαρμογή που μεταφέραμε για να αποφασίσουμε αν θα την αναβαθμίσουμε ή θα την ανακατασκευάσουμε. Αν θέλετε αξιολόγηση του δικού σας συστήματος ή μια ομάδα που θα υλοποιήσει το σχέδιο, η SDK Enterprises κάνει και τα δύο υπό μία σύμβαση.

Συχνές ερωτήσεις