Σύντομη παρουσίαση της αξίας της συνεχούς ολοκλήρωσης και της βασικής παραμετροποίησης του Jenkins

1. Continuous Integration
• Εισαγωγή – Τι σημαίνει συνεχής ολοκλήρωση;
• Γιατί χρειάζεται και πως εφαρμόζεται;
• Jenkins CI – Τι είναι; Γιατί Jenkins;
• Εγκατάσταση / Βασική Παραμετροποίηση
• Build Jobs basics
• CI Best Practices
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

2. Τι σημαίνει συνεχής ολοκλήρωση;
• Agile (και όχι μόνο) πρακτική
• Οι ενέργειες που γίνονται από τους developers σε
καθημερινά τακτά χρονικά διαστήματα ώστε οι
αλλαγές που κάνουν στο λογισμικό να
ενοποιούνται / ολοκληρώνονται με το υπόλοιπο
λογισμικό αυτοματοποιημένα και γρήγορα
• Στηρίζεται στην κουλτούρα ότι από την 1 η μέρα
ενός project, αυτό θεωρείται παραγωγικό!
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

3. Γιατί χρειάζεται;
• Όλοι οι ενδιαφερόμενοι μπορούν να γνωρίζουν
ποια ζητήματα έχουν αντιμετωπιστεί σε ποιο build
και με ποιες αλλαγές στον κώδικα.
• Όλοι οι ενδιαφερόμενοι έχουν εικόνα για την
ποιότητα και τα αποτελέσματα των ελέγχων που
υπάρχουν σε ένα σύστημα, καθώς και για πλήθος
ποιοτικών αποτελεσμάτων.
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

4. Γιατί χρειάζεται; (2)
• Πάντα υπάρχει διαθέσιμη, μία σταθερή έκδοση
για έλεγχο, προς επίδειξη σε πελάτες, χωρίς να
χρειάζεται η παρέμβαση της ομάδας ανάπτυξης,
όποτε προκύπτει ανάλογη ανάγκη.
• Αυξάνεται το αίσθημα ασφάλειας και σιγουριάς
απέναντι στο προϊόν εφόσον υπάρχει διαφάνεια
στις αυτοματοποιημένες διαδικασίες ανάπτυξης
και ελέγχου του συστήματος.
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

5. Πως εφαρμόζεται;
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

6. Πως εφαρμόζεται; -
Υποδομές(1)
• Source Control Repository (Subversion, Git κτλ.)
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

7. Πως εφαρμόζεται; -
Υποδομές(1)
• Αυτοματοποιημένη Διαδικασία Build (και όχι
μόνο)
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

8. Πως εφαρμόζεται; - Διαδικασία
• Σωστά ορισμένη διαδικασία commit
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

9. Πως εφαρμόζεται; - Διαδικασία
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

10. Πως εφαρμόζεται; - Διασκέδαση
• ‘Αμεσο Feedback με ποικίλους τρόπους
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

11. • OpenSource Continous Integration εργαλείο
γραμμένο σε Java
• Δημιουργός : Koshuke Kawaguchi
• Hudson μέχρι το Δεκέμβριο του 2010.
• Ήρθε η Oracle, τα έκανε μαντάρα, ο Koshuke
έφυγε και πήρε μαζί του το παιδί του.
•Από τότε υπάρχουν : Jenkins CI και Hudson
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

12. • Γιατί επιλέγουμε Jenkins και όχι Hudson;
• Τεράστιο community
• Εκατοντάδες open source plugins
• Για λόγους ηθικής
• Γιατί δεν επιλέγουμε κάποιο εμπορικό πακέτο;
( π.χ. Confluence Bamboo )
• Οικονομική στενότητα (προφανές)
• Καλυπτόμαστε πλήρως από τον Jenkins
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

13. • Εγκατάσταση
• Διαθέσιμη για όλα τα OS
• Πολύ απλή σε Windows / Run as Service (
http://mirrors.jenkins-ci.org/windows/latest)
• Βασική Παραμετροποίηση
• Εγκατάσταση / Ορισμός JDK
• Εγκατάσταση / Ορισμός Maven
• Εγκατάσταση / Ορισμός Ant
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

14. OTS SA, 2012 © Παπαπέτρου Πάτροκλος

15. • Τύποι Build Jobs
• Free style ( Ant Projects, PowerBuilder )
• Maven 2/3 projects
• Multi configuration
• Monitor external job
• Καταστάσεις Build Jobs
• Success
• Unstable
• Failed
• Running (Flashing με χρώμα από την κατάσταση του τελ. Build)
• Disabled
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

16. • Βασική Παραμετροποίηση Build Jobs
• Βασικά στοιχεία
• Source Code Management
• Build Triggers (Periodically, Poll SCM, μετά από άλλα
projects, όταν γίνεται Build μία Snapshot dependency κτλ. )
• Build (pre-steps, post-steps)
• Post actions
• Notifications
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

17. Best Practices(1) – Build Jobs
• Trunk Build
• Trigger μετά από κάθε commit
• Unit Tests Execution
• Ολοκληρώνεται σε λιγότερο από 5’-10’
• Nightly Build
• Εκτελείται κάθε βράδυ (αν υπάρχουν
αλλαγές)
• Unit Tests / Integration Tests Execution
• Deployments σε QA environments
• Static Analysis / Quality Measures (Sonar)
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

18. Best Practices(2) – Feedback
• Ενημέρωση όλων των εμπλεκόμενων
• Πότε;
• Όταν «χαλάει» ένα Build
• Όταν «επανέρχεται» ένα Build
• Γιατί;
• Άμεση επιδιόρθωση του «χαλασμένου»
Build + Κανείς δεν παίρνει τον «χαλασμένο»
κώδικα τοπικά
• Πράσινο φως για λήψη «διορθωμένου»
κώδικα
OTS SA, 2012 © Παπαπέτρου Πάτροκλος

19. Best Practices(2) – Feedback(2)
• Ενημέρωση όλων των εμπλεκόμενων
• Πως;
• Γραπτώς (email, sms, IM, RSS, tweets etc.)
• Ηχητικά
• Οπτικά ( Java Lamps – Feedback Panels )
OTS SA, 2012 © Παπαπέτρου Πάτροκλος