2. Tech days 2011
1. Get it 2. Configure it
3. Build it 4. Run it
5. Deploy it
3.
4. “There should be two tasks for a human being to
perform to deploy software into a development,
test, or production environment: to pick the
version and environment and to press the
“deploy” button.”
[Continuous Delivery]
5. What we aim for?
• Build application binaries – ant, make… √
• Configuration (tools ??) X
• Database (tools ??) X
• Delivery (tools ??) X
6. Why?
• NHibernate: 63K LoC
• Bailiffs: 157K LoC
• R#: 500K LoC
• BAM: 1M LoC
• Russian CB: 1.3M LoC
• .NET4: 2M LoC
7. VCS almighty
• DB scripts … all configurations … deployment
scripts … application source code
EVERYTHING!
8. Antipattern #1
• Manual Configuration Management of
Production Environments
– Hours to enable new team member
– Hours to install any new environment
– Hours to get WHY it doesn’t work on my PC ?!
9. Infrastructure as code
• “Infrastructure as code is an approach whereby infrastructure
configuration is scripted or described by files
that are stored in version control, and
changes are pushed out to the datacenter in
a controlled manner. This parallels the discipline of
source control and build promotion used in software
development, hence ‘as code’” [http://www.thoughtworks.com/articles/technology-
radar-january-2011]
12. Antipattern #2
• Deploying Software Manually
– Diffing Test DB with some “prod-like” DB
– Long installation instructions
– Long delivery cycles
– Broken productions
– Evenings / Weekends in office fixing
13. Deliver often
• MVP hype [Agile-*, Lean-*] -> feedback
• Incremental DB patches (*-Migrations libs)
• Automatic package build –best documentation
• Enterprise software on any unplugged laptop
• Feature toggles (use feature branches not version branches)
“If it hurst …”
14. So again
1. Get it 2. Configure it
3. Build it 4. Run it
5. Deploy it
15. Not there yet
• Automatic setup of web applications (and services
like Mystic) – mitigated by F5 execution
• Visible dashboards
• 100% host environment control (Puppet -
http://projects.puppetlabs.com/projects/puppet)
16. • “Repeatability and reliability derive from two
principles: automate almost everything, and
keep everything you need to build, deploy,
test, and release your application in version
control.“
[Continuous Delivery]
Notes de l'éditeur
- A working software application can be usefully decomposed into four components: executable code, configuration, host environment, and data.
- In many software projects, release is a manually intensive process.
Create a Repeatable, Reliable Process for Releasing SoftwareAs releases become less fraught, it is easier to consider things like the agile ideal of a release at the end of each iteration. Even if that isn’t appropriate for a particular project, it means that we get our weekends back.These days, many companies are putting out multiple releases in a day. This is possible even with large projects with complex codebasesOur highest priority is to satisfy the customer through early and continuous delivery of valuable softwareWhen deployments aren’t fully automated, errors will occur every time they are performed.
