Continuous wut?

Small talk on continuous integration

Transcript

1. Continuous wut? Pretty humble talk by Sergey Arkhipov. Seriously.
2. @9seconds
3. — Hi there. I write code.
4. package com.hello.world; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } }
5. — And this is how we build product
6. package com.hello.world; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } }
7. package com.hello.world; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } } Magic
8. package com.hello.world; public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } } Magic Product
9. — Before agile became mainstream nobody actually cared about quality of magic
11. — This is Microsoft daily build flow
12. — So why agile matters and what is the problem?
14. — Agile renamed team leaders to scrum masters, gave billions to sticky notes manufacturers and responsibility for developers.
15. — Agile renamed team leaders to scrum masters, gave billions to sticky notes manufacturers and responsibility for developers.
16. Agile fundamentals ― Team responsibility ― Iterative development ― Plan driven management ― Requirements emerge through feedback
17. Agile fundamentals ― Team responsibility ― Iterative development ― Plan driven management ― Requirements emerge through feedback
18. Software should always be Software should always be buildable
19. Software should always be Software should always be tested
20. Software should always be Software should always be deployable
21. Software should always be Software should always be ready
22. /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o(.text+0x18): In function `_start':: undefined reference to `main' collect2: ld returned 1 exit status — Red build again!
23. /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o(.text+0x18): In function `_start':: undefined reference to `main' collect2: ld returned 1 exit status — I have nothing to test!
24. /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o(.text+0x18): In function `_start':: undefined reference to `main' collect2: ld returned 1 exit status — We have nothing to deliver to customer!..
25. /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o(.text+0x18): In function `_start':: undefined reference to `main' collect2: ld returned 1 exit status — We are losing money!..
27. — Let's go CI!
28. Continuous Integration Continuous Integration is a software 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 software more rapidly. — Martin Fowler
29. Continuous Integration Continuous Integration is a software 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 software more rapidly. — Martin Fowler
30. Continuous Integration Practices ― Maintain a Single Source Repository ― Automate the Build ― Make Your Build Self-Testing ― Everyone Commits To the Mainline Every Day ― Every Commit Should Build the Mainline on an Integration Machine ― Keep the Build Fast ― Test in a Clone of the Production Environment ― Make it Easy for Anyone to Get the Latest Executable ― Everyone can see what's happening ― Automate Deployment
36. — What are you going to do if machinery stopped?
39. — Please stop this marketing bullshit! What is the main idea to use CI? responsibility for developers.
40. The real reasons why CI ― We don't trust you
41. The real reasons why CI ― We don't trust you ― We care about overall quality of product
42. The real reasons why CI ― We don't trust you ― We care about overall quality of product ― We hate big merges
43. The real reasons why CI ― We don't trust you ― We care about overall quality of product ― We hate big merges ― We hate duches prefer escalating not solving problems
44. The real reasons why CI ― We don't trust you ― We care about overall quality of product ― We hate big merges ― We hate duches prefer escalating not solving problems ― We got paid
45. Got questions?