Continuous integration has gone mainstream. It has helped development teams move quicker, and has disrupted build management and put additional pressures on deployment groups. In this presentation, we look at how CI achieved such a disruptive, positive impact, how it is turning into Continuous Delivery, and where DevOps fits into the picture (And how DevOps will be just as disruptive).

1. From Continuous Integration to DevOps

2. Maciej Zawadzki Cofounder and CEO of Urbancode Original author of AnthillPro. Architect of Urbancode’sDevOps Platform. Blog: http://urbancode.com/blogs/devil-in-the-details Twitter: @devl_in_details

3. Eric Minick Lead Consultant Worked as a dev, tester, and release guy Dozens of enterprise rollouts Blog: http://urbancode.com/blogs/ Twitter: @EricMinick

4. Agenda Continuous Integration Continuous Delivery DevOps The Future Resources

5. CI: it’s about Quality Determination CI is based on the observation that the longer development streams diverge, the more painful the eventual integration will be. Taking the converse of the above statement, the more frequently developers integrate their changes, the more painless those integrations will be. But, why does it not suffice for developers to simply check-in or commit their changes frequently to practice CI? Implied condition -- that each integration will not decrease the code quality. This is the key to understanding CI; the rest is implementation details.

6. CI: it’s about Quality Determination Integrating frequently is less painful than infrequently. But, If we commit frequently blindly, we have a broken code base Implied condition: each integration will not decrease the code quality. This is the key to CI The rest is implementation details. http://www.urbancode.com/blogs/anthillpro-blog/2011/09/07/continuous_integration_why_you_dont_really_get_it.html

7. CI: the Implemention How do we determine code quality? We test it How do we test code? We build it and run tests against it CI requires fast feedback, so what tests do we run? Unit tests This is how we get from CI to CI servers and software builds

8. CI: the Disruption of Build Management Paradigm change: similar to structure of scientific revolutions – Thomas Kuhn Before CI, build engineers would: Manually perform the build After the paradigm change, build engineers would: Design the build process for projects. The actual build execution is handled by a tool.

9. CI: the Bumps CI Builds Purpose: determine quality of latest changes Audience: development team Source: Build is traceable to latest changes and “latest” source Artifacts: Throw away builds, tests are important Build Management Builds Purpose: produce artifacts for 3rd parties Audience: 3rd parties outside development Source: Build is traceable to source Artifacts: Important builds, artifacts are important and primary

10. CI: the Innovation of Automation Invention: proven to work in the laboratory Innovation: it can be replicated reliably on a meaningful scale at practical costs. For an idea to move from invention to innovation requires an ensemble of critical components. Peter M. Senge, The Fifth Discipline CI brings together “critical” factors: Automation Self-service Transparency/Visibility

11. CI: Summary CI requires the determination of code quality CI disrupted Build Management CI represents the Innovation of Automation

12. Agenda Continuous Integration Continuous Delivery DevOps The Future Resources

13. Continuous Delivery: What is it? Continuation of the Quality Determination that CI started. Functional tests require deployment. Progression through environments on a march to production, with “the build” subjected to more exhaustive tests in each environment.

14. Continuous Delivery: The Drivers Quality Determination: CI left unfinished business on the table. Further tests require deployments. Agile: keeping up with the pace. Innovation of Automation: self-service and visibility have a powerful attraction

15. Continuous Delivery: the Details Deploying multi-tiered applications is not trivial. Application model Component (tier) model Mapping of components to servers in each Env. Multiple Tiers Database changes Middleware code changes Middleware config changes Flat file changes Multi-environment deployments Handle different environment topologies Handle different environment configurations

16. Continuous Delivery & Mountain Bikes How many people own a mountain bike? How many people ever took it down a mountain? The guys that deploy to production 50 times a day drive their mountain bike down the mountain. The rest of us benefit from the technology as we have a comfortable ride on the park trails with our kids.

17. Continuous Delivery: Theory & Reality The reality is that: Dev and Ops are in different silos Dev and Ops use different tools Dev produces change, Ops seeks to control change 50 page Word doc is the standard hand-off between Dev and Ops

18. Continuous Delivery: Summary CD follows through on what CI started, the quality determination CD is enabling technology for deployments CD reality is that most organizations use it in lower environments only

19. Agenda Continuous Integration Continuous Delivery DevOps The Future Resources

20. DevOps: the Drivers The Cloud (IaaS): Has all the “critical” factors for Innovation Self-service is a radical shift in the SLA Hand-off document leads to errors Agile leads to faster pace

21. DevOps: the Disruption Cloud offers an alternative to Enterprise IT Enterprise IT will need to match the SLA Private cloud under Enterprise IT control is a way to remain competitive Adopting cloud automation is a paradigm shift for Enterprise IT Once the paradigm shifts, the flood gates open for deployment automation

22. DevOps: the Implementation, Convergence IaaS on a private cloud Environment provisioning as a service. Application teams may request environments for their applications. Environments come pre-configured with DB and middleware. Application Deployment (CD) to provisioned environments.

23. DevOps: the Bumps Ahead Dev Ops Very High Tempo Can rebuild database / app from scratch No need for Rollbacks Audit is nice to have Security, traceability, separation of duties. New Environments are common Slower Tempo Incremental updates to Database and App Rollbacks are huge Audit Critical Security, traceability, separation of duties. New environments are rare

24. The Summary CI represents Innovation of Automation CI got us started down the road towards PROD CD continued the work that CI started CD provided enabling technology for application deployments DevOps will disrupt Ops the same way CI disrupted Build Management DevOps opens the door for the convergence with Dev practices such as CD

25. Agenda Continuous Integration Continuous Delivery DevOps The Future Resources

26. Where are we headed? Private clouds (or public/private) Platform as a service Servers with middleware, properly configured, managed, and available self-service. Application deployment onto the platform Release Management Tracks builds through the (PaaS) environments from CI to Production. Same deployment process for all environments

27. Where are the tools headed? Pre-2006: Just CI tools 2006-2010: CI becomes Continuous Delivery First end-to-end tool is AnthillPro in 2006. Now: DevOps CI is commodity. Integrated CD tools focus on point solutions deployment and pipeline management. Expanding integrations with private cloud

28. Agenda Continuous Integration Continuous Delivery DevOps The Future Resources

29. More on CI, CD, and DevOps Webinars and more: http://urbancode.com/resources Death to Manual Deployments! Build & Deployment Automation for the Lean Economy Enterprise DevOps: Scaling Build, Deploy, Test, Release You should follow us: Urbancode.com/blogs/ Twitter.com/UrbanCodeSoft Facebook.com/UrbanCodeSoft

30. Yes, UrbanCode sells Agile / DevOps tools AnthillPro is now the DevOps Platform DevOps Platform Automated build, test and deployment. Includes UrbanDeploy. UrbanDeploy Deployment and release management

31. Questions? Or ask us later: eric@urbancode.commbz@urbancode.com