1. ALM Deployment Pipeline Implementation

2. Create a Repeatable, Reliable Process for Releasing Software. Automate Almost Everything Keep Everything in Version Control If It Hurts, Do It More Frequently, and Bring the Pain Forward Build Quality In Done Means Released Everybody Is Responsible for the Delivery Process Continuous Improvement Source: Martin Fowler Principles of Software Delivery

3. Why ? : Quality affect software costs

4. Teams integrate their work multiple times per day. Each integration is verified by an automated build Significantly reduces integration problems Develop cohesive software more rapidly Source: Martin Fowler Continuous Integration

5. Five Principles of Continuous Integration Environments based on stability Maintain a code repository Commit frequently and build every commit Make the build self-testing Store every build

6. Roadmap

7. Stability & Branching

8. Stability monitor - Sonar Jenkins builds the code SONAR runs after each build SONAR alert thresholds can 'break' the build Automate quality improvements

9. Code Quality Static code analysis Looks for common java bugs (Findbugs, PMD).NET - FXCop Check for code compliance (Checkstyle) Unit test analysis Measure coverage (Cobertura) Look for hotspots, areas of low testing and high complexity (SONAR)

10. Commit frequently and build every commit Performance, performance & performance 1.Build should be quick : Common problems.NET different solutions reference by dll (150 projects – 30 solutions) Build -Solution Creator mvn -T 1C clean install # 1 thread per cpu core” Java parallel build - “ mvn -T 1C clean install # 1 thread per cpu core” 20-50% speed improvement Build only what you need BeforeAfter Compilation Time8:00[mm:ss]4:00[mm:ss]

11. CI Daily vs. Nightly TestsDailyNightly Unit testFullFull System testsAcceptanceFull Rest testFullFull IntegrationXFull Auto Start 24 X 7 DB upgradeAcceptanceFull UI - SeleniumAcceptanceFull API performanceXFull LoadXFull InstallationXFull SecurityXFull

12. HP ALM CI Diagram

13. HP ALM on Jenkins

14. HP ALM on Jenkins coverage DB Engine OSWEB

15. Test Performance

16. Make the build self-testing

18. Pretested commits - Why Our CI was frequently red and that creates work. During a two-week period we measured that more than 80% of the builds resulted in failure. CI was red More than half of the failures followed a previous failure. That means that by a low estimation 30% of the commits were made while the CI was red.

19. Pretested commits - Analysis So lets just establish that everyone always runs the tests before publishing their work, right? - Tried it, doesn’t work. Well not? - Because it’s always tempting not to. Why? - Because it’s difficult to be sure whether it’s your bug or someone else’s. Why? - Because other developers commit untested code. Oops! Vicious circle. But that’s not the only reason, what’s more? - It takes time to run the tests and it blocks the development environment. Nasty. Any more? - It takes discipline to run all the tests before every “publication” of my code and discipline is a limited resource. Someone will run out of it and then it will get a lot more tempting for the others to skip it. Oops! vicious circle again.discipline is a limited resource

20. Pretested commits - how 1.He starts by checking out a new feature branch 2.he commits some modifications locally (since we’re using git) 3.he does some more work and commits again refs/heads/merge-requests/ / 4.then he pushes his branch to the team repository refs/heads/merge-requests/ / 5.Jenkins takes the branch merges it with the stable branch 6.if the code doesn’t merge cleanly nothing is done to the stable branch and the committer is notified by mail. 7.if any tests fail, then again nothing is done to the stable branch and the committer is notified by mail. 8.if the build succeeds, the stable branch is updated* with this latest stable version. (* : in git branches are like post-its that you can move around, so “updating the stable branch” just means “move to post-it named stable to the just tested commit”)

21. Bug hunt CheckIn 1CheckIn 2 …… CheckIn N Jenkins Break Jenkins

22. DevOps organization structure DevOps CI Build Management Automation Provisioning, Deployment, Integration Architect Total : 15 persons ~ 10% of whole Project resources

23. The book story CI Artifact Repository Source