Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Continuous Integration, Deployment, Delivery
Transcript of Continuous Integration, Deployment, Delivery
Software IS complex
You are here
The early Days of Configuration Management
Configuration status accounting
Configuration verification & audit
CMMI, DoD, IEEE and CM: The good Parts
Elements of a good Change Control System
Rationale for the Change
Change Control - The old days
Change "Requests" (Form)
Change Control Board (Comitee)
High Level artifacts
Revision History Tables
Change Control - Reinvented
Attribution: Commit author
Rationale: Commit message
Reversibility: Versioning tool
Change made: Diff
Auditability: Versioning log
Rise, Dawn and rebirth of Branching
Everybody working in the same code line.
Spiderman would be jealous of our version tree.
Branches are evil
Git-Workflow, short-lived branches for everything.
Continuous Integration: The Elements
a Versioned source base
Test each build
Each commit should build, commits shall be frequent
Continuous Build + :
Deploy to "Production-like Environment" on each commit
Ready to be "used", tested, touched, sensed, analyzed, by relevant stakeholders.
Continuous Deployment + :
Each commit results in a new PRODUCT version, available for end users.
CI and your lifecycle of choice
And save time
What is NOT Continuous Integration
Builds that last 10hs
Builds that are always red
Build but not test
Build what doesn't change ("Clean mainline syndrome")
Continuous Integration: The inception
XP (eXtreme Programming, not Windows)
Fighting against “Integration hell”
Eventhough branches are easy now
It's the winning of "Convention over configuration" for CM.
What's an automated Build system?
Simply put: a glorified cron job.
Repository Change Detection
Build Script Execution
A file system capable of:
Recoding who did what
CVS: bad and old.
SVN: not so bad, but old
TFS, Perforce, ClearCase: old
Mercurial, Git: awesome.
Unit tests: yes.
Many tests: yes.
Fast tests: yes.
UI tests: yes.
Integration tests: yes.
Manual (intelligent) tests: no.
How frequent is frequent?
"You shall commit if, and only if, you want to share your changes with 'someone' else and your changes are ready and meaningful"
Diego - 3rd commandment of SCM.
You'd better share with me as soon as possible so I can tell you how crappy your code is.
Let's get creative and add some fun
--Marvin, the CI robot
Elements of a good Product Integration approach:
Have a integration environment
Have a integration sequence defined
Have a build BOM (bill of materials)
Build the god damn thing
Check what you have built
Package everything and publish
What does "Integration" means?
Integration of your changes to the product
Product Integration in the old days:
Word document procedures & Processes:
Bill of materials
Manual verification of integrations
Manual packaging and release of the integrated product
Product Integration - Evolved
Just install a good build management tool and fill up what it asks for.