Embed Size (px)
DESCRIPTION
You've heard about Continuous Integration and Continuous Deilvery but how do you get code from your machine to production in a rapid, repeatable manner? Let a build pipeline do the work for you! Sam Brown will walk through the how, the when and the why of the various aspects of a Contiuous Delivery build pipeline and how you can get started tomorrow implementing changes to realize build automation. This talk will start with an example pipeline and go into depth with each section detailing the pros and cons of different steps and why you should include them in your build process.
Citation preview
DC CONTINUOUS INTEGRATION, DELIVERY,
& DEPLOYMENT USER GROUP
Thanks to Mike McGarr and Excella Consulting for hosting!!
Introduction
Sam Brown 11+ Years as a Java developer with commercial and
federal clients Practicing continuous integration/continuous delivery
for ~6 years DevOps Evangelist at Excella (www.excella.com) Certified Scrum Master Puppet Certified Professional
Enterprise Macro ViewBasic components of an automated enterprise Continuous integration Dependency management Automated build tools
to build... Shared API libraries Custom web applications Products
What the heck is a pipeline?
So how did ‘pipelines’ get applied to software? Let’s try a few changes to this statement...
“The purpose of a build pipeline is to transport code from a developers machine to an environment quickly and effectively with minimal upkeep or attention required once
built” – me
“The purpose of a pipeline is to transport some resource from point A to point B quickly and effectively with minimal upkeep or attention required once built” – me
What’s missing?
Build pipelines require measurements and verification of the code to ensure: Adherence to standards Quality proven through testing A product that meets user’s needs
The purpose is not just transport, but to ensure that our product is high-quality, prepared for the environment it will reach, and satisfies the end-user.
Build Pipeline - Defined“An automated manifestation of the process required to get your team’s application code to the end-user, typically implemented via continuous integration server, with emphasis on eliminating defects” – me (again)
Not all pipelines are built the same …in fact, NONE ARE! Build pipelines will vary as much as
applications Different teams have different needs Simplicity is key
One Size Fits All!
Our example pipeline
Code Pipeline
Repeatable, automated, process to ensure that application code is tested, analyzed, and packaged for deployment.
Version Control
System of record Just do it! Take advantage of commit hooks Build from trunk and reduce server-side
branches Tag often Don’t check in broken code!
Compile/Unit TestPurpose: Integrate, build and unit test code for quick feedback Best Practices
Runs in under 10 minutes (rapid feedback) Unit tests do not require external resources Run on EVERY developer check-in Fixing broken builds is the top priority! Gamification to drive adoption 80% test coverage or BETTER
Challenges LOTS of builds False sense of security Writing tests is hard
Integration TestPurpose: Test component and/or external resource integration Best Practices
Test connectivity with external resources Test frameworks load correctly Test application components work together Test configuration Fewer integration tests than unit tests
Challenges External resources may not be available in all environments
○ Mock locally Can be time consuming
○ Use local resources ○ Separate short/long running tests
Static Code Analysis
Purpose: Use automated tools to inspect code Best Practices
Check syntax Find security vulnerabilities Record test coverageDiscover complexity Optional: Fail based on a metricOptional: View technical debt
ChallengesNot all code analysis tools are freeLearning/installing new tools
Label & Package
Purpose: Label code and package as deployable
Best PracticesLabeling allows you to go back in timePackaging code for deploymentReduce complexity by combining stepsNO configuration in package -> Package once,
deploy multiple Challenges
Labeling can be resource intensiveMany packaging options
Publish to Repository
Purpose: Make artifacts available for deployment or available to other teams Best Practices
Publish a versioned artifactMake repository available Reduce complexity by combining steps
ChallengesRequires initial complex setup Security requirements around exposing artifacts
○ Use a tool with security built-in like Nexus
Our example pipeline
Infrastructure Pipeline
Repeatable, automated, process to ensure that our target environment is properly constructed for our application(s).
Analyze & Compile
Purpose: Check syntax and compile prior to application Puppet Lint – Static format checker for
Puppet manifests No-op Test Run – Ensure that manifest
compiles Challenges
Puppet-lint requires a ruby-based environmentNo-op test needs production-like VMLong feedback loop
Apply & TestPurpose: Test infrastructure in a prod-like environment Puppet Apply –Puppet application against VM that
mimics DEV/TEST/PROD Infrastructure Tests – Test your environment! Example tests:
Users and groups created Packages installed Services running Firewall configured
Challenges Long feedback loop Yet another language (cucumber/rspec/other) VM must be up to date with DEV/TEST/PROD
Example Infrastructure Tests
Feature: Services
Scenario Outline: Service should be running and bind to port When I run `lsof -i :<port>` Then the output should match /<service>.*<user>/
Examples: | service | user | port | | master | root | 25 | | apache2 | www-data | 80 | | dovecot | root | 110 | | mysqld | mysql | 3306 |
require 'spec_helper'
describe 'logrotate::rule' do let(:title) { 'nginx' }
it { should include_class('logrotate::rule') }
it do should contain_file('/etc/logrotate.d/nginx').with({ 'ensure' => 'present', 'owner' => 'root', 'group' => 'root', 'mode' => '0444', }) endend
cucumber-puppet rspec-puppet
http://rspec-puppet.com/
http://projects.puppetlabs.com/projects/cucumber-puppet/wiki
Our example pipeline
Acceptance Test Pipeline
Repeatable, automated, process to ensure that our application is properly installed in the target environment and that the application
meets acceptance criteria.
Apply & TestPurpose: Test acceptance criteria in a prod-like environment Puppet Apply – Apply Puppet manifests including
deploying application Run Acceptance Tests – “End-to-end” testing
End-user perspective Meets user-defined acceptance criteria Possible tools: Cucumber, Selenium, Geb, Sikuli
Challenges Maintain a production-like VM Acceptance tests brittle
○ Test at the right level Acceptance tests long running
○ Run nightly
Label & Deploy
Purpose: Label application and infrastructure code, deploy to DEV environment Label Release Candidate – Known “accepted”
versions will be deployed together Deploy to DEV – Automated deployment
Infrastructure AND application Challenges
DEV updating, not deployed from scratch○ Create tests for ALL possible scenarios
Security ○ Work with security early and often!
Our example pipeline
The Last Mile
Simplified process to support streamlined deployments to TEST and PRODUCTION
Pull & Test
Purpose: Enable the test team to pull the latest code Pull-based deployment Manual Testing/Approval Challenges
Enabling test team is a paradigm shiftProducing changes too fast
○ Create good release notes○ Not every build needs manual testing
Pull & Release
Purpose: Enable operations team to pull the latest code into production “Push-button” deployment to production
Requires testing approval Challenges
Audit/security check before deployment○ Discuss with operations○ Automate as much as possible and prudent
Paradigm shift for operations, TOO EASY!○ Engage the operations team as early and often
Rollback/Roll forward strategy ○ Easier with RPM’s, I prefer roll forward
Benefits of the Pipeline Remove human error Repeatability tests and improves the
process Visibility from code to deployment Baked-in quality Metrics, metrics, metrics Rapid and constant feedback Releases are non-events
Quick Aside: VersioningWhy do we store old/obsolete versions? Rollback Auditing History? Any other reason?
My view: Store only the latest build and current production release Bugs fixed in latest version (Almost) impossible to reproduce environments Version control has history
Exception: Other teams dependent on a previous version Store major/minor revisions
Reasoning: In a continuous delivery environment, delivering frequently allows you to keep moving forward with new features AND bug fixes!
Don’t wait, start tomorrow! Put EVERYTHING in version control Start simple, up your unit test coverage. Analyze your code in order to focus Install CI and start with two build steps Start and maintain a wiki And lastly…
Connect…
@SamuelBrownIV
http://github.com/samueltbrown
http://www.linkedin.com/pub/samuel-brown/3/715/352
