The document discusses the principles and importance of Continuous Integration (CI) and Continuous Delivery (CD) in modern software development, emphasizing the need for automation in building, testing, and deploying software. It outlines the advantages of CI/CD, such as delivering value more frequently, improving quality, and providing faster feedback, while also highlighting tools like Git, Maven, and Jenkins necessary for implementing these practices. The document also addresses the cultural shifts required in organizations to effectively adopt CI/CD methodologies.

1. TEST MANAGERS FORUM 2014
SYDNEY, AUSTRALIA
CONTINUOUS INTEGRATION
CONTINUOUS DELIVERY
1

2. 2
WHO AM I?
Gridfusion Software Solutions
Contact:
Michael Palotas
Gerbiweg 2
8853 Lachen
SWITZERLAND
Tel.: +41 79 6690708
Email: michael.palotas@gridfusion.net
Head of Productivity & Test Engineering, eBay
Founder / Principal Consultant
Gridfusion Software Solutions

3. SETTING THE STAGE
Tell me about yourself J
What are your expectations for today?
3

4. Your setup
How do you build software?
4

5. WHAT IS SO SPECIAL ABOUT AGILE?
5

6. WHY CI/CD?
6

7. WHAT IS IMPORTANT IN AGILE?
7

8. Agile
=
Release working software anytime
8

9. Traditional waterfall model / tools do not support
“build and deploy anytime”
9

10. WHAT IS CI / CD?
CI and CD
=
Automated Build?
Automated Tests?
Automated Quality?
Automated Deployment?
Automated Feedback?
10

11. WHY CI / CD
Deliver value to the business more frequently
Better Quality
Early Bugs
Bug Prevention instead of late detection
Fast & frequent feedback
11

12. WHY CI / CD
Automated frequent builds
Automated frequent tests
Automated frequent code quality metrics
(Hopefully) Fewer bugs
Fast feedback
12

13. WITHOUT CI
Slow / long release cycles
Late testing
Waterfall (WaterScrum)
Bugs
Slow feedback
Complex integration
13

14. CORE PRINCIPLES
Every build could be a release
Everything should be automated
Stable and trustworthy automated tests
Build pipelines
14

15. RELEASING IN THE OLD WORLD
15
Coding Deploy to
QA
QA Deploy to
Production
Production
Smoke
Tests
Bug
Bashes

16. CI / CD - CORE WORKFLOW
16
Compile
Unit Test
Deploy to QA
Acceptance tests
Deploy to Production
Production Smoke Tests
Code Quality

17. THE MAIN TASKS
Automated build
Automated code quality
Automated testing
Automated deployment
17

18. 18
Wakaleo.com

19. CAN YOU MEASURE AUTOMATED CODE
QUALITY? DOES THAT MAKE SENSE?
19

20. AUTOMATED CODE QUALITY?
Sonar gives you information on:
- Lines of code
- % of comments
- Duplications
- Complexity
- Rules compliance
- Unit test coverage
- Unit test success rate
- Unit test duration
- Hotspots
20

21. CAN / SHOULD YOU AUTOMATE EVERYTHING?
21

22. WHAT SHOULD YOU AUTOMATE?
22

23. WHAT ARE BARRIERS TO CI / CD?
23

24. WHAT IS CONTIUOUS INTEGRATION?
24
Continuous integration (CI) is the practice, in software engineering,
of merging all developer working copies with a shared mainline
several times a day. It was first named and proposed as part of
extreme programming (XP). Its main aim is to prevent integration
problems, referred to as "integration hell" in early descriptions of XP.
CI can be seen as an intensification of practices of periodic
integration advocated by earlier published methods of incremental
and iterative software development, such as the Booch method. CI
isn't universally accepted as an improvement over frequent
integration, so it is important to distinguish between the two as there
is disagreement about the virtues of each.

25. WHAT IS CONTINUOUS DELIVERY?
25
Continuous Delivery (CD) is a design practice used in software
development to automate and improve the process of software
delivery. Techniques such as automated testing, continuous
integration and continuous deployment allow software to be
developed to a high standard and easily packaged and
deployed to test environments, resulting in the ability to
rapidly, reliably and repeatedly push out enhancements and
bug fixes to customers at low risk and with minimal manual
overhead. The technique was one of the assumptions of
extreme programming but at an enterprise level has
developed into a discipline of its own, with job descriptions for
roles such as "buildmaster" calling for CD skills as mandatory.

26. THE MANAGEMENT / ORGANIZATIONAL ASPECT
What are the changes for developers and
testers?
What needs to be changed in the organization to
enable them to implement CI / CD?
What role has management in creating a devops
culture?
26

27. OUR TOOLS
Version Control System GIT
Build Tool MAVEN
Unit Test Framework JUNIT / TESTNG
End To End Test Framework SELENIUM
Build Server / Deployment JENKINS
27

28. Branching & Merging
Small and Fast
Distributed
Data Assurance
Staging Area
Free and Open Source
VERSION CONTROL: GIT
28
http://git-scm.com/about/

29. GIT: BRANCHING & MERGING
29
Git-scm.com

30. GIT: SMALL & FAST
30
Git-scm.com

31. GIT: THE REST
Distributed
Data Assurance
Staging Area
Free & Open Source
31

32. GIT
Distributed / local
Download: http://git-scm.com/
Initialize directory: git init
Status: git status
Add files and directories to git: git add file1 dir2
Commit: git commit –am “commit message”
32

33. SHARE YOUR CODE - GITHUB
Create repository on Github: https://github.com
Create remote: git remote add origin https://…
Push code to Github: git push origin master
Tag your code: git tag –a v0.1 –m “initial version”
Push tag to Github: git push origin v0.1
33

34. GITHUB
34

35. CONNECT GIT AND GITHUB
35
Silverpeas.org

36. MAVEN
36
Apache Maven is a software project
management and comprehension tool. Based
on the concept of a project object model (POM),
Maven can manage a project's build, reporting
and documentation from a central piece of
information.
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html

37. POM.XML
The pom.xml file is the core of a project's
configuration in Maven. It is a single
configuration file that contains the majority of
information required to build a project in just
the way you want.
37

38. POM.XML
38

39. MAVEN TARGETS
validate: validate the project is correct and all necessary information is available
compile: compile the source code of the project
test: test the compiled source code using a suitable unit testing framework. These tests should not
require the code be packaged or deployed
package: take the compiled code and package it in its distributable format, such as a JAR.
integration-test: process and deploy the package if necessary into an environment where integration
tests can be run
verify: run any checks to verify the package is valid and meets quality criteria
install: install the package into the local repository, for use as a dependency in other projects locally
deploy: done in an integration or release environment, copies the final package to the remote repository
for sharing with other developers and projects.
clean: cleans up artifacts created by prior builds
39

40. EXAMPLES
mvn clean
mvn compile
mvn test
40

41. CONTINUOUS INTEGRATION - JENKINS
Download at http://jenkins-ci.org/
41

42. RECAP
WHAT DO WE EXPECT
THE CI SYSTEM TO DO?
42

43. 43

44. A JENKINS JOB
44

45. WHAT JENKINS DOES
Jenkins checks out the workspace from Github
Builds and runs tests locally according to POM
Runs maven targets according to POM
description
45

46. A SIMPLE BUILD JOB
46

47. A SIMPLE BUILD JOB
1. Add / change some code
2. Push to Github repository
3. Let Jenkins pick up the change
4. Perform mvn clean compile targets
5. Perform mvn test target (unit tests only)
47

48. TEST AUTOMATION
Unit Tests
E2E
Tests
Manual Tests
Integration Tests

49. WHAT IS SELENIUM?
Selenium automates browsers
that’s it
…

50. E2E / UAT AUTOMATION WITH SELENIUM
50
CLIENT SERVER
JSON Wire Protocol
BROWSER

51. SELENIUM
JSON WIRE
PROTOCOL
Client
Java
C#
Ruby
Python
Server Driver
Driver
Driver

52. CLIENT
Is seen as „Selenium“ by the users
Generates HTTP requests which are received by the server
Is called by the test framework or the CI server
Supported languages: Java, C#, Python, Ruby, Perl, PHP,
JS

53. SERVER
Receives HTTP requests
Start and teardown of browser
Translates requests into browser specific commands
Communicates back to the client

54. SELENIUM GRID
Sequential Execution
Test 1 Test 2
Test
…
Test
4500
Execution Time
Test 3
Parallel Execution
Test Test Test
Execution Time
Test
Test Test TestTest
Test Test TestTest
ParallelExecution
ParallelExecution

55. SELENIUM GRID

56. TEST INFRASTRUCTURE
AUT
DB
API
Browsers
Mobiles
CLIENT

57. 57

58. A SIMPLE SELENIUM TEST
58

59. 59

60. LET’S BUILD A BUILD / DEPLOYMENT PIPELINE
60

61. THE MASTER JOB
61
Unit Test
Deploy to QA
Acceptance tests
Deploy to Production
Production Smoke Tests
Code Coverage

62. THE APPLICATION
62

63. 63

64. CONNECT CODE WITH GITHUB
64

65. UNIT TESTS
65

66. RUN UNIT TESTS LOCALLY
Run from eclipse
Run from maven
66

67. 67

68. UNIT TEST COVERAGE - COBERTURA
68

69. 69

70. SONAR: CODE ANALYSIS / CODE QUALITY
70

71. 71

72. WE ARE READY FOR THE NEXT STEP
ADD CI JENKINS
SET UP JENKINS JOBS
- Master Job
- Run unit tests
- Deploy to QA
- Run E2E tests
- Deploy to PROD
- Run PROD smoke tests
72

73. MASTER JOB
73

74. JOB: UNIT TESTS (1)
74

75. JOB: UNIT TEST (2)
75

76. JOB: DEPLOY TO QA
76

77. JOB: INTEGRATION TESTS
77

78. JOB: DEPLOY TO PRODUCTION
78

79. JOB: PRODUCTION SMOKE TESTS
79

80. JOB: SONAR
80

81. JOB: COBERTURA
81

82. PIPELINE: HAPPY PATH
82

83. PIPELINE: UNHAPPY PATH
83

84. THANK YOU!
84