Εquilibrium

Μετάβαση σε VS 2005: Περιπέτεια!

Χτες ήταν η ημέρα που είχαμε καθορίσει για να μετατρέψουμε το solution μας στο νέο visual studio. Είχαν προηγηθεί δοκιμαστικά conversion από τις αρχές Νοεμβρίου και αφού είχαμε ξεπεράσει τα σημαντικότερα προβλήματα ήμασταν πλέον έτοιμοι για τη μετατροπή.

Έγιναν τα σχετικά backup, εγκαταστάθηκε το νέο VSS στον server (στους clients είχε εγκατασταθεί εδώ και μέρες και το δουλεύαμε μαζί με το παλιό studio, είναι μια χαρά) και έγινε analyze και fix της βάσης.

Η διαφορά με τα δοκιμαστικά conversion που είχα κάνει ήταν ότι στις δοκιμές χρησιμοποιούσα disconnected αρχεία από το vss, ενώ τώρα έκανα branch όλο το solution, read only το παλιό branch για ασφάλεια, και έπαιζα connected. Η μετατροπή έγινε project - project, ξεκινώντας από τα χαμηλότερα ιεραρχικά και ανεβαίνοντας προς τα πάνω. Μετά από κάθε project που έμπαινε μέσα, πήγαινα στα properties και και το ρύθμιζα έτσι ώστε να μην εμφανίζει καθόλου warnings και να μην κάνει include xml coments στα builds, γιατί είχα υποψιαστεί ότι αυτά καθυστερούν πολύ το studio. Προβλήματα δεν βγήκαν πολλά αφού ότι λάθος χτύπαγε είχα φροντίσει από τις δοκιμές να το διορθώσω από το παλιό studio.

Η μετατροπή κράτησε περίπου 8 ώρες, για ένα solution με 40 projects και πάνω κάτω 1.200.000 γραμμές κώδικα. Τα προβλήματα που παρουσιάστηκαν ήταν τα εξής:

• Ξενικώντας από νέο καθαρό solution, τα projects προστίθοντας με add existing project από το source safe. Για άγνωστο λόγο, στο πρώτο add που έκανα όλα δούλευαν κανονικά και το conversion ξεκίναγε, στο δεύτερο add όμως το studio κόλλαγε την ώρα που πήγαινε να κατεβάσει το project από το vss. Έτσι μετά από κάθε project addition έκλεινα το studio και το ξαναάνοιγα. Δεν είναι τόσο σημαντικό πρόβλημα, το νέο studio ανοιγοκλείνει αρκετά γρηγορότερα από το παλιό, αλλά όσο να ναι προσθέτει στο συνολικό χρόνο και σπάει νεύρα.
• Μόλις τέλειωσα με όλα τα conversions, ανακάλυψα το εξής: Το VS 2005 είχε αφήσει έξω από τα projects μου όλα τα resource αρχεία (resx) για φόρμες, controls, components, τα πάντα. Αναγκάστηκα να κάνω get latest από το vss, show all files σε κάθε ένα project και έκανα include όλα τα resx ένα προς ένα με το χέρι. Το πρόβλημα παρουσιάστηκε και σε ένα δεύτερο solution που έκανε αργότερα convert ένας συνάδελφος (ο Ισίδωρος) με παρόμοια διαδικασία, ενώ δεν είχε παρουσιαστεί στις δοκιμές, άρα υποθέτω ότι φταίει το integration με το VSS.
• Web projects. Δεν είναι ουσιαστικά πρόβλημα, απλά να αναφέρω ότι οι αλλαγές που έχουν κάνει στα web projects, τουλάχιστον κατά την άποψή μου, είναι σημαντικότατες, τόσο στο integration με το vss όσο και στην διαχείρισή τους από το ίδιο το studio. Εμείς έχουμε κάποια web projects που περιέχουν web services και δεν είχε πολύ μεγάλο μπλέξιμο (αν και έχω ακόμα 1-2 άλυτα θεματάκια), but αν στο solution σας έχετε web projects, φροντίστε απαραιτήτως να κάνετε δοκιμαστικά convertions και να δουλέψετε για λίγο με αυτά μέσα από το νεό studio (vss connected) ώστε να δείτε όλα τα θέματα.

Η μετατροπή έγινε σε ένα καινούργιο μηχάνημα με 1.5 GB μνήμη. Μόλις ολοκληρώθηκε και διορθώθηκαν όλα τα μικροπροβλήματα, ξεκίνησα τα builds και rebuilds. Παρόλο που είχα κλείσει comments και warnings, η ταχύτητα δεν με εντυπωσίασε. Για πλήρες rebuild στο μηχάνημα που δούλευα ήθελε κοντά στα 10 λεπτά το οποίο το θεωρούσα οριακά ανεκτό.

Μετά τα πρώτα builds άρχισα να δοκιμάζω την εφαρμογή για να δω πως συμπεριφέρεται. Γενικότερα είχα την αίσθηση ότι κάποιες μεγάλες βαριές φόρμες ανοίγουν πολύ πιο γρήγορα με το 2.0. Συνάντησα όμως το εξής περίεργο: Έχουμε φόρμες στις οποίες κάνουμε handling το closing event για να ελέγξουμε μήπως χρειάζονται αποθήκευση τα δεδομένα. Μέσα στον κώδικα για το handling των events, είδα σε περιπτώσεις που δεν χρειαζόταν αποθήκευση να καλείται ξανά το me.close. Αυτό το βρήκα στον κώδικα όλων των developers, και στον δικό μου. Ενώ είναι λογικό και αναμενόμενο ότι θα έπρεπε η εφαρμογή να πέσει σε loop και να πάρουμε overflow exception, με το 1.1 αυτό δεν είχε γίνει ποτέ. Το me.close δεν δημιουργούσε ποτέ πρόβλημα και οι φόρμες έκλειναν κανονικά. Με το 2.0 όμως παίρνεις όντως overflow. Όταν είναι ο debugger από πίσω σε σταματάει στη γραμμή που παίρνει το overflow και μπορείς να καταλάβεις τι έγινε, αλλά χωρίς τον debuger, αν παρατήρησα καλά, η εφαρμογή σκάει και εξαφανίζεται χωρίς error, και χωρίς να πιαστεί από τα try-catch που υπάρχουν. Είναι ένα θέμα που θέλει προσοχή.

Για να έχουμε το κεφάλι μας ύσηχο, δοκιμάσαμε το solution στο μηχάνημα του Ισίδωρου, το οποίο είναι ένα τυπικό μηχάνημα για τους developers μέσα στην εταιρία με 1 Gb μνήμη. Οι ταχύτητες που παίρναμε ήταν άκρως απογοητευτικές. Το get latest από το vss έκανε απίστευτα μεγάλους χρόνους και το rebuild χρειαζόταν πάνω από 15 λεπτά. Το studio αρπάζει όλη τη μνήμη του μηχανήματος και πιάνει και άλλο τόσο από το VM. Οι χρόνοι ήταν τόσο άσχημοι που άρχισα να πιστεύω ότι Δευτέρα πρωί θα τα πετάγαμε όλα και θα γυρνούσαμε στο παλιό studio.

Τελικώς μετά από πολύ συζήτηση, ψάξιμο και δοκιμές με τον Ισίδωρο, κάναμε τα εξής:

• Σπάσαμε το solution στα 3. Ένα solution με projects κοινά για τον client και τον server (η εφαρμογή είναι τύπου smart client) δηλαδή projects για error handling, compression, τύπους δεδομένων, utilities κλπ, πράγματα που γενικά δεν αλλάζουν πολύ συχνά. Ένα solution με τα projects του server (κλασσικό data access layer, κάποιο business logic, web services, και ένα solution με τα projects του client. Μπορεί ο χωρισμός αυτός σε κάποιους να φαίνεται αυτονόητος, είχαμε μεγάλους δισταγμούς όμως γιατί υπάρχουν καθημερινές αλλαγές και στον server και στον client και ο τρόπος που δουλεύουμε μέχρι τώρα δεν ευνοεί πολύ ένα τέτοιο χωρισμό. Το αποτέλεσμα είναι τρία solutions ικανοποιητικού μεγέθους, που χωράνε άνετα στο μηχάνημα και μπορείς να τα δουλέψεις με ικανοποιητικό response.
• Φτιάξαμε ένα batch αρχείο το οποίο με command line arguments κάνει τα εξής:
  1. Διαγράφει το executable της εφαρμογής (ώστε αν κάτι σκάσει στη μέση να το πάρεις χαμπάρι όποσδήποτε
  2. Κάνει get από το source safe. Το get γίνεται για όλα τα projects, παρακάμπτοντας τα αρχεία που είναι checked out (προφανώς δουλεύονται την ίδια στιγμή στο studio).
  3. Κάνει build και τα τρία solutions (με τη σωστή σειρά).
  4. Εκτελεί το executable της εφαρμογής.

Η όλη διαδικασία και το get και το πλήρες build διαρκεί μόλις 35 δευτερόλεπτα. Οπότε με αυτόν τον τρόπο ξεπερνάμε το μπλέξιμο του να ανοιγοκλείνεις τα solutions στο studio για να πάρεις get και να κάνεις build αυτά που έχει αλλάξει ο διπλανός σου.

Anyway, η παραπάνω λύση θα δοκιμαστεί και στην πράξη και θα συμπληρώσω εδώ τις όποιες εξελίξεις. Το resume είναι ότι το νέο studio ναι μεν έχει πολλά καλούδια τα οποία θέλουμε σαν τρελοί, δεν τα δίνει όμως τσάμπα. Η μετάβαση είναι μια διαδικασία δύσκολη για μεγάλα solutions και πρέπει να σχεδιαστεί και να υλοποιηθεί πάρα πολύ προσεκτικά.