The document discusses continuous integration and incremental development. It defines continuous integration as a pipeline with jobs that can run in parallel and produce artifacts that other jobs depend on. Incremental development involves implementing features in a way that maintains the integrity of the existing system and enables easy deployment. It is driven by requirements and tests, uses source control management, and aims for the system to be releasable at any time. Continuous integration helps achieve many of the goals of incremental development through automated testing, monitoring, and deployment pipelines.

1. Continuous Integration for citizens

2. There are lot of areas where we can use CI/CD pipelines.

3. There are lot of areas where we can use CI/CD pipelines. • Since CI/CD instruments are very general. • We can even use CI as a general purpose job server. • As to materialize views. Real example from ironSource.

4. I’ll focus on integration of changes during incremental development.

5. So, what is incremental development is all about?

6. There is bunch of questions. I will split them into a five

7. What is incremental development is all about? • The TDD question.

8. What am I going to do? The TDD question:

9. I should be driven by requirement.

10. TDD?

11. No. It’s not just TDD.

12. Its RDD Requirement driven development.

13. Or feature driven development. I don’t care.

14. But how can I proof that I know what to do?

15. I should write a program that can do it in a constructive way.

16. Yeah, It’s from math!

17. I don’t care how obvious your proof is unless you can construct an object you assert about.

18. No finite program, no proof.

19. In case of software engineering it means that programs should be not just finite but also finish in a reasonable time.

20. What is incremental development is all about? • The TDD question. • Integrity.

21. I should implement things in context of my system.

22. Which is drives us to even more essential...

23. Regression My increment should not harm other system’s properties.

24. How to be sure that I am in the context?

25. There should be a program for this.

26. There are programs for this • Static code checking. • Code style checking • Code complexity • Types • Previous sate of the system described by tests

27. What is incremental development is all about? • The TDD question. • Integrity. • Deployment.

28. I should know how to deploy my system.

29. I should know how to deploy my system • Green/Blue releases • Migrations

30. Migrations can be useful for Green/Blue releases. Since it you store history of your system increment in migrations.

31. I should know how to deploy my system • Green/Blue releases • Migrations • Integration and E2E testing

32. Which bring us back to TDD.

33. What is incremental development is all about? • The TDD question. • Integrity. • Deployment. • Isolation

34. Isolation • I don’t want to district other developers • I don’t want other features to interfere with mine in uncontrolled way

35. There is a program for this!

36. There is a program for this! • Git

37. There is a program for this! • Git • or Mercurial

38. And two models • Feature branch model • Gitflow model

39. Who know the difference?

40. Gitflow is for Git.

41. Your stable branch is not your release branch.

42. What is incremental development is all about? • The TDD question • Integrity • Deployment • Isolation • Release readiness

43. We should be able to release at any time.

44. Or: we WILL release after each change.

45. The last mean that we probably will be forced to add feature switches into our programs.

46. But this is not obviously a bad news.

47. Intermediate solution: • CD for staging • Manual releases for production

48. There are lots of programs for this.

49. There are lots of programs for this • Jenkins/Hudson • Travis CI • Codeship • TeamCity • Bamboo

50. There are will be AWS for this.

51. There are will be AWS for this: • CodeDeploy • CodeCommit • OpsWorks

52. How does CI works?

53. It’s a pipeline with triggers

54. It’s a pipeline with triggers: • Some jobs are sequential an some can be run in parallel • Jobs produce artifacts and they depends on artifacts produced by other jobs • Jobs produce artifacts and they depends on artifacts produced by other jobs • The wrapping pipeline called «plan»

55. Triggers

56. In Bamboo jobs grouped into stages • If jobs doesn’t depends on each other they can run in parallel • It depends on number of free capable agents • Jobs itself are synchronized sequences of tasks performed on a context. E.g build dir

57. Triggers • VCS events • Build events • Schedule

58. Branches

59. (No header) • Branches are parametrized versions of the main build plan • They are bounded to VCS branches • Bamboo takes care of automatically creation and collecting branches • Or you can make eternal branches. Like master.

60. Continuous Integration Workflow (an RTM case)

61. Continuous Integration Workflow • Gitflow • When development is done we make a pull request • Bamboo checkouts branche’s HEAD and merges `dev` branch into it

62. Yeah, it merges `dev` into feature branch

63. Continuous Integration Workflow • Gitflow • When development is done we make a pull request • Bamboo checkouts branche’s HEAD and merges `dev` branch into it • It extracts deploy script as an artifact • It loads dependencies

64. Continuous Integration Workflow • ... • It loads dependencies • It tests • It packs • And it reports

65. Bamboo can do back merges for successful builds.

66. Continuous Integration Workflow • ... • Push merge result into feature branch if build is successful • Notify VCS about build status • Task is moved to code review

67. Good news: people can run programs in their heads

68. So, why code review? • It’s a way to share responsibility • There are no more sticky tasks • It’s amazingly fun

69. Code review doesn’t takes time

70. Actually it creates time

71. It’s like putting glass of water into glass of sugar

72. Because people doesn’t work continuously: they need to switch context

73. They love to chat and we let them chat

74. Continuous Integration Workflow • ... • If there is enough approves and build is successful then assignee moves task into QA • The build is deployed to QA • We can run e2e at this time

75. Missing part: integration tests as a part of deploy

76. Bamboo doesn’t support this yet

77. Continuous Integration Workflow • ... • We can run e2e at this time • QA engineer performs manual feature testing • And accepts pull request

78. CI is also a pipeline of decisions

79. Where is Team Lead among all of this?

80. The hard truth

81. We don’t need them. No more!

82. We can build a team of citizens

83. A good citizen doesn’t need a boss

84. He need a goal or the goal

85. Continuous integration, TDD and social engineering are parts of one picture

86. At least they can be assembled this way for great good

87. Implementing of CI

88. Case study 1: TDD

89. How to estimate your personal efforts for starting TDD?

90. It’s psychologically impossible since TDD is a mind shift

91. There are no introspection that can help you to estimate your mental efforts after changing the way of thinking

92. But. You can just start to do it

93. And you can estimate this from experience

94. People who write tests much more satisfied by their work and by money they earn

95. TDD is an OOP of 21th century

96. Case study 2: risks

97. CI/CD risks • You will rely on your CI infrastructure • Any problems with CI is a blocker

98. But this is much better to catch bugs on production

99. Or find that you almost impossible to do clean release

100. CI/CD risks • You will rely on your CI infrastructure • Any problems with CI is a blocker • There no efficient way to explicitly force people to write tests. They should accept this first • If CI is too slow it become useless

101. Beyond this keynote • Performance • TDD and functional programming • Metrics • Mutation testing

102. The End