Continuous Integration and Delivery

Continuous Integration and DeliveryBrandon Cornett

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle Text

Brandon CornettTalking about and DeliveryBut first let me tell youSELU Graduate - Class of 2012Envocean for 3 yearsAt Envoc, Im primarily Xamarin mobile app and ASP.NET developerSecond SQL Saturday presentation

Think about this

How long does it take for you to go from having no project at all to having a new one created, in source control, and on a staging server?Production?User management?Password management?Zero to production in 5 minutes.


1) Most people - hour or twoLast) Using combo of CI, CD, and a custom solution, this is possible- Show you at end of presentation

Source Control Just Do It

Store everything that is needed to build the entire system, but nothing that gets builtIf build products have to be committed, theres a deeper problem"Anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine." - Martin Fowler


Prereq to all1) Store needs for build, nothing product of build1a) Fast transfers, builds2) Commit products, have issues bad3) MF says

Martin Fowler - author and design pattern guru

Problems to Solve

Integration HellTracking down teammates to fix buildsBuild-breaking dependenciesDevelopers work until the day of release, and commonly run in to integration or deployment issues that dayWhen defects are introduced, they can sometimes go unnoticed if unit tests are not run by the developer before committing


1) Me and you both try to check in after a long time - last one in merging tons of files2) Story - You commit week ago, forget files, Doesnt build for me, track you down3) Doesnt build on anyone elses machine4) Happens to all of us5) Testing important here, if not - found by QA weeks later, or worse clients- How know which commit broke it?

The Solution - Continuous Integration

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. - WikipediaEvolved idea from Extreme Programming, introduced in 1997Per-commit reportingBuilt every time in production-like environment


1) one thing - solves Integration Hell - committing early and often, not taking forever2) CI was used with just TDD, later introduced build server3) Report results to developers - uncommitted files, dependencies missing or not working- See exactly which commit broke the build - [Story] Would have notified you of failed build, fix right away4) Avoid last-minute deployment issues

Continuous Integration Lifecycle

http://kaizentesting.wordpress.com/2012/08/19/agile-test-automation-is-incomplete-without-continuous-integration/


Before, daily was standard, now trigger every commit

Benefits

Increased visibilityImmediate unit testingSignificantly less back-tracking to find breaking changesGenerated metrics


1) Which enables greater communication2) Easy to determine if build is compromised- If it is - email / notify Slack or HipChat3) so you can spend more time building features4) code coverage, code complexity, etc

Best Practices

Maintain a single source repositoryAutomate the buildMake your build self-testingEveryone commits to the mainline every dayEvery commit should build the mainline on an integration machineKeep the build fastTest in a clone of the production environmentEveryone can see what's happening


1) So you dont have triggers watching all over, trying to make systems communicate2) Can do so using Nuget, make, etc.3) Use unit tests - check before committing4) Failing test should cause build to fail5) Because theres only hours between commits, no Integration hell6) Always available- Reduces risk of dependency issues- Solves "Works on My Machine6) Cloning repo, building, testing should be fast7) More risk if you dont have a replica- Point is to test prod8) Selling point is increased communication

Continuous Integration Systems

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextTeamCity Demo


Notice build number

The Next Step - Continuous Delivery

Design practice used in software development to automate and improve the process of software delivery - WikipediaThe practice of releasing every good build to usersGoal is to increase quality, decrease cycle timePuts the release schedule in the hands of the business, not in the hands of ITSingle-action deployments of any version to any environment on demandExtension of continuous integration


1) Bring dev and IT teams together2) All tests pass, should be ready for QA or production depending3) By adopting both CI and CD, not only reduce risks, but move quickly to prod4) For ex, when client asks, dev can be deployed to production at a moment's notice5) Point is to minimize lead time6) Systems work together

Delivery vs Deployment

a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice - and nobody would bat an eyelid, let alone panic." - MF

http://blog.crisp.se/


Delivery - isnt deployed every time - but it can be Deployment - Tests provide a guarantee of quality Some customers like to test - consult / product Single server - cant take down prod in middle of day

Continuous Delivery Visualized

http://en.wikipedia.org/wiki/Continuous_integration

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextThe Last Mile

Manual deploymentsLack of configuration managementInfrequent, error prone deployments

http://ptgmedia.pearsoncmg.com/images/art_humble_continuousdelivery/elementLinks/humble_fig01.jpg


Publish to prod env issues Looks to solve this problem

Benefits

Feature-based releasesCan measure performance directlyRepeatable deployment processConstant availabilityState of development


1) rather than a weekly whatever happens to be ready release2) because releases are small, can tell which one did it. Monitor with Zabbix, NewRelic, etc.3) and frees the IT team of busywork4) Always have a current build for testing, demo, or release purposes5) Anyone can see what the development progress is

Best Practices

Release to pre-production staging servers for additional QARolling deployments help down-timeBuild binaries only once - not per environmentUse precisely the same mechanism to deploy to every environmentIf anything fails, stop the buildIntegrate into HipChat, Slack, etc.Done means releasedVersion everything


1) by clients, customers2) Explain clustering3) just apply web config transforms or the like4) to ensure consistency5) dont push broken code6) to keep devs in the loop on whats going on7) Dont commit and think youre done, it should make it all the way to prod through the build system8) to keep track of everything - what features are in what environment

Continuous Delivery Systems

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextOctopus Deploy Demo

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextExpanding With a Warmup

Use solution templates with basic functionalityAllow for one-click set-up of a new, baseline solutionAlleviates tediousness involved in project setup


- Use Entity Framework Code First1) Pull latest from source control2) Modify to be specific to client3) Push to source control4) Create continuous integration server project5) Create continuous deployment server project6) Trigger build and deploy to development environment

*Give credit to chuck norris*

Zero to Prod in Five Minutes

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextSo How Do I Convince My Boss?

envoc.io/ZeroToProdVideo

http://info.chromeriver.com/blog/bid/276672/5-Ways-to-Convince-Your-Boss-to-Automate-Expenses

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextImpressive Stats

GitHub had over 41,679 builds and 12,602 deployments from Jan-Aug 2012StackOverflow deploys 5 times per dayIMVU - 6 deployments an hour, 15k test cases, 9 mins to run over 40 machinesEtsy deploys 50 times per day, 14k test cases, 1.5 billion page views / month

http://www.zap2it.com/

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextThe Books

http://martinfowler.com/

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextWebsite: bcornett.comEmail: [email protected]: @brandonmc2005

This presentation: envoc.io/CIandDQuestions?

Body Level OneBody Level TwoBody Level ThreeBody Level FourBody Level FiveTitle TextReferences

http://en.wikipedia.org/wiki/Continuous_integrationhttp://en.wikipedia.org/wiki/Continuous_deliveryhttp://martinfowler.com/delivery.htmlhttp://www.thoughtworks.com/continuous-integrationhttp://www.extremeprogramming.org/rules/integrateoften.html


Documents

Continuous Integration and Delivery