ALM Deployment Pipeline Implementation Continuous Delivery isnt just
- Slides: 23
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
- Notch glaucoma
- Isnt the love of jesus something wonderful
- Life is not fair quotes
- There aren't some cakes
- Isnt he beautiful
- Big data continuous integration
- Intune deployment project plan
- Scalar pipeline
- Difference between linear and non linear pipeline
- Competitive intelligence law firm
- Alm nedir
- Hp application lifecycle management
- Linguagem tecnica
- Banka hesap planı
- Wordle genres
- O que significa alm
- Alm
- Aras altium connector
- Alm policy credit union
- Jerome lebuchoux
- Imvu continuous deployment
- Does juliet wake up just before romeo dies or just after?
- Present continuous past continuous
- Past simple future simple