Alles nur CI-Theater?

Continuous Integration (CI) ist mittlerweile ein etabliertes Prinzip. Die meisten Teams haben heute einen Server wie Jenkins für CI. Ohne Continuous Integration gibt es keine Continuous Delivery. Oft genug wird CI allerdings halbherzig durchgeführt und das Team wiegt sich in trügerischer Sicherheit – sie spielen CI-Theater. Wie kann ich CI-Theater erkennen und welche Maßnahmen helfen mir bei echter CI? Der Talk gibt hierauf Antworten.

Transcript

1. Konstantin Diener | konstantin.diener@cosee.biz … die größten Stolpersteine für Continuous Integration Alles nur CI-Theater?
2. Konstantin Diener CTO und Gründer von cosee
3. Wertvolle So ft ware, die Geld verdient!
4. Wir vermieten cross- funktionale Teams für die Produktentwicklung.
5. Was ist eigentlich Continuous Integration?
6. „Continuous Integration is a so ft ware development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive so ft ware more rapidly. … “ https://martinfowler.com/articles/continuousIntegration.html
7. 11 Praktiken
8. Maintain a Single Source Repository
9. Automate the Build
10. Make Your Build Self- Testing
11. Everyone Commits To the Mainline Every Day
12. Every Commit Should Build the Mainline on an Integration Machine
13. Fix Broken Builds Immediately
14. Keep the Build Fast
15. Test in a Clone of the Production Environment
16. Make it Easy for Anyone to Get the Latest Executable
17. Everyone can see what's happening
18. Automate Deployment
19. CI-Theater
20. „CI theatre” describes the illusion of practising continuous integration (CI) while not really practising it. Suzie Prince, https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html
21. Es ist die Übertragung von Cargo Cult auf Continuous Integration.
22. Top 3⃣
23. 3 Platz 3
24. Make Your Build Self- Testing
26. „If you've skipped unit tests because you plan to refactor the code soon, you might not understand refactoring (or unit tests).“ @DocOnDev
27. mvn install -DskipTests
28. --no-verify
29. 2 Platz 2
30. Fix Broken Builds Immediately
31. A phrase I remember Kent Beck using was "nobody has a higher priority task than fixing the build". This doesn't mean that everyone on the team has to stop what they are doing in order to fix the build, usually it only needs a couple of people to get things working again. It does mean a conscious prioritization of a build fix as an urgent, high priority task. Martin Fowler
32. 1 Platz 1
33. Everyone Commits To the Mainline Every Day
34. Jez Humble, David Farley Continuous Delivery
35. „… it has been our experience that poor version control practices are one of the most common barriers to fast, low-risk releases.“ Continuous Delivery
36. Continuous Delivery • Develop on Mainline • Branch for Release • Branch by Feature • Branch by Team
37. Continuous Delivery • Develop on Mainline • Branch for Release • Branch by Feature
39. „It is worth emphasizing that branching by feature is really the antithesis of continuous integration, … Continuous Delivery
40. Branching is not the problem, merging is the problem. Jez Humble
41. Jeder von uns kennt vermutlich die Merge Hell.
43. Auf Feature Branches zu arbeiten, bezeichnen die Autoren als Continuous Isolation.
44. DON’T DO FEATURE BRANCHES!
45. Was denn sonst? 🤔
46. Continuous Delivery • Develop on Mainline • Branch for Release • Branch by Feature
47. Auf der Mainline zu entwickeln, wird auch als Trunk Based Development bezeichnet.
48. Dadurch bekommen wir early integration statt late integration.
50. • Ensuring that all code is continuously integrated • Ensuring developers pick up each others’ changes immediately • Avoiding „merge hell“ and „integration hell“ at the end of the project
51. Aber wir bauen von der Mainline unsere Releases! Wie soll das gehen? 😱
52. Continuous Delivery • Develop on Mainline • Branch for Release • Branch by Feature
53. „It is worth emphasizing that branching by feature is really the antithesis of continuous integration, … Continuous Delivery
55. Ok, aber zum Release sind nicht alle Features fertig! 🏗
56. Deswegen gilt: „Keep your application releasable!“
58. • Hide new functionality until it is finished. • Make all changes incrementally as a series of small changes, each of which is releasable. • Use branch by abstraction to make large-scale changes to the codebase. • Use components to decouple parts of your application that change at di ff erent rates.
59. • Dark Releases • Feature Toggles • Build Time Switches
60. • Hide new functionality until it is finished. • Make all changes incrementally as a series of small changes, each of which is releasable. • Use branch by abstraction to make large-scale changes to the codebase. • Use components to decouple parts of your application that change at di ff erent rates.
61. • Hide new functionality until it is finished. • Make all changes incrementally as a series of small changes, each of which is releasable. • Use branch by abstraction to make large-scale changes to the codebase. • Use components to decouple parts of your application that change at di ff erent rates.
65. • Hide new functionality until it is finished. • Make all changes incrementally as a series of small changes, each of which is releasable. • Use branch by abstraction to make large-scale changes to the codebase. • Use components to decouple parts of your application that change at di ff erent rates.
67. konstantin.diener@cosee.biz Konstantin Diener