ALM Deployment Pipeline Implementation Continuous Delivery isnt just

ALM Deployment Pipeline Implementation Continuous Delivery isn’t just a development methodology, it’s critical to doing business UT & Coverage Build Code Analysis` FXCop/FB Customer Project Upgrade System Acceptance Tests

Principles of Software Delivery • 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

Why ? : Quality affect software costs

Continuous Integration • 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

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

Roadmap

Stability & Branching

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

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)

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 Before Compilation Time • • After 8: 00[mm: ss] 4: 00[mm: ss] Java parallel build - “mvn -T 1 C clean install # 1 thread per cpu core” 20 -50% speed improvement Build only what you need

CI Daily vs. Nightly Tests Unit test System tests Rest test Integration Daily Nightly Full Acceptance Full X Full Auto Start 24 X 7 DB upgrade Acceptance Full UI - Selenium Acceptance Full API performance X Full Load X Full Installation X Full Security X Full

HP ALM CI Diagram

HP ALM on Jenkins

HP ALM on Jenkins coverage DB Engine OS WEB

Test Performance

Make the build self-testing

Make the build self-testing

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. 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

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.

Pretested commits - how 1. 2. 3. 4. 5. 6. 7. 8. He starts by checking out a new feature branch he commits some modifications locally (since we’re using git) he does some more work and commits again then he pushes his branch to the team repository refs/heads/merge-requests/<myname>/<branch-name> Jenkins takes the branch merges it with the stable branch if the code doesn’t merge cleanly nothing is done to the stable branch and the committer is notified by mail. if any tests fail, then again nothing is done to the stable branch and the committer is notified by mail. 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”)

Bug hunt Jenkins Check. In 2 … Break Check. In 1 … Check. In N

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

The book story CI Source Artifact Repository