Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous wut?

Continuous wut?

Small talk on continuous integration

A8d8ca813a744866b9f85ea1cefb5813?s=128

Sergey Arkhipov

January 14, 2013
Tweet

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
  10. None
  11. — This is Microsoft daily build flow

  12. — So why agile matters and what is the problem?

  13. None
  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!..
  26. None
  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
  31. None
  32. None
  33. None
  34. None
  35. None
  36. — What are you going to do if machinery stopped?

  37. None
  38. None
  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?