choosing automation for devops & continuous delivery in the enterprise
TRANSCRIPT
Choosing Automation for DevOps & Continuous Delivery in the Enterprise
Andrew Phillips, VP Products
2 Copyright 2014.
About Me
▪VP Products for XebiaLabs
▪Lots of enterprise software development on high-performance systems
▪Been on both sides of the “Dev…Ops” fence
▪Active open source contributor and committer
▪Regular meetup, conference etc. presenter
3 Copyright 2014.
About XebiaLabs
▪We build software to support Continuous Delivery at scale
▪We know how to implement CD “in the real world”
4 Copyright 2014.
Our Products
▪Visualize, orchestrate and manage your end-to-end Continuous Delivery pipeline.
▪Manage, execute and optimize complex test scripts across your test tools.
▪Automate your application deployments for standardized, efficient releases.
TRY OUR PRODUCTS:
www.xebialabs.com/products
5 Copyright 2014.
Delivering Measurable Success
A proven solution, delivering benefits to the world’s top companies:
Reduced deployment times from12 weeks to 2 days
Deploying 90% Faster
Reduced environment idle time by 65%
Improved Dev, Ops Collaboration
“With XL Deploy we have a better collaboration between Dev and Ops, an acceleration of our application releases and a significant reduction in deployment and configuration errors.”
Alexandre VictoorLead Architect, Sociéte Generale, Corporate & Investment Banking
Many of the world’s largest banks and financial institutions trust XebiaLabs’ proven, secure solutions to deliver rapid time to value.
6 Copyright 2014.
Agenda
▪Continuous Delivery, DevOps & Tooling
▪A DevOps Tooling Provider Model for the Enterprise
▪Tooling Categories, Classes & Maturity
▪Product Evaluation Criteria for Enterprise Use
▪DevOps, CD & The Business
7 Copyright 2014.
Continuous Delivery, DevOps & Tooling
▪It’s been said many times: “Continuous Delivery & DevOps >> Tooling”
▪In practice, the majority of CD & DevOps initiatives are automation initiatives− Often, localized activity driven by individual teams or Tech Heroes
▪Automation address many of the immediate pain points felt by teams− “We spend ages waiting for a test environment to become available, and further time trying to undo all
the changes made be the previous team”
− “Many of the problems in our code only show up in pre-production, because the developers can’t put together a local environment that’s sufficiently production-like”
− “Changes committed by developers keep conflicting with work made by other team members, breaking our code”
− “Our test results are largely useless because the test data is not representative of production”
− “There are all these cool tools out there that I want to play with”
− …
8 Copyright 2014.
Continuous Delivery, DevOps & Tooling
▪It’s been said many times: “Continuous Delivery & DevOps >> Tooling”
▪In practice, the majority of CD & DevOps initiatives are automation initiatives− Often, localized activity driven by individual teams or Tech Heroes
▪Automation address many of the immediate pain points felt by teams− “We spend ages waiting for a test environment to become available, and further time trying to undo all
the changes made be the previous team”
− “Many of the problems in our code only show up in pre-production, because the developers can’t put together a local environment that’s sufficiently production-like”
− “Changes committed by developers keep conflicting with work made by other team members, breaking our code”
− “Our test results are largely useless because the test data is not representative of production”
− “There are all these cool tools out there that I want to play with”
− …
9 Copyright 2014.
Continuous Delivery, DevOps & Tooling
▪This is a very confusing and fast-moving space:
10 Copyright 2014.
Continuous Delivery, DevOps & Tooling
▪You most likely already have pretty much every possible tool running somewhere
▪Every team will be pushing to either keep their solution− Or to make their solution the “standard”
▪“Let 100 DevOps toolsets bloom”?
11 Copyright 2014.
Continuous Delivery, DevOps & Tooling
▪“Let 100 DevOps toolsets bloom”
▪Becomes infeasible as DevOps adoption scales up
▪Lack of expertise: “not enough Tech Heroes to go around”
▪Hidden maintenance overhead− “We need to spend some time in this sprint to fix our CI server”
▪Difficult to implement cross-cutting concerns− Security
− Audit/compliance
− Integrations
− Data access
− …
12 Copyright 2014.
A DevOps Tooling Provider Model for the Enterprise
“Shared services, with exceptions”
▪Choose one or two standard tools in each DevOps tool category− Consider also cloud-hosted services if these meet security etc. requirements
▪Create a dedicated team to provide these tools “as a service” to teams− Usually part of the Operations/platform team, although often initially staffed with Tech Heroes from
dev/release engineering
▪Additional responsibility: provide guidance and onboarding support to teams not familiar with DevOps tools
▪In the initial standardization phase, provide migration assistance to teams that are happy to move to a standard tool
13 Copyright 2014.
▪No “One Toolset to Rule Them All”: allow teams to run alternative toolsets
▪Top-down enforcement of a mandated standard will generate resistance− Especially if the standard toolset genuinely fails to meet the needs of a particular project
▪“Rights and responsibilities:” teams should
▪…run their alternative systems themselves
▪…fund them from the team/project budget
▪…develop and maintain any required integrations
▪…comply with necessary cross-cutting requirements (e.g. audit trails, test reports etc.)
A DevOps Tooling Provider Model for the Enterprise
14 Copyright 2014.
▪“Open DevOps Tools Lab”
▪Give all teams the opportunity to research new technology, if desired− Not just the tooling team itself!
▪Improves morale and innovation - stay up to speed with tech developments
▪Avoid “For this project, let’s run everything on <new technology of the week here> to see how it works”
▪Provide a clear path for updating the standard toolset− Need to demonstrate benefit over existing tools for multiple teams
A DevOps Tooling Provider Model for the Enterprise
15 Copyright 2014.
Tooling Categories, Classes & Maturity
Classes:
▪“Process”
▪“Component”
16 Copyright 2014.
Tooling Categories, Classes & Maturity
Categories
▪Issue tracking (Process)
▪SCM (Component)
▪Continuous Integration (Process)
▪Artifact repository (Component)
▪Cloud management (Component)
▪Environment provisioning (Component)
▪Application release automation (Component)
▪Test data & test result management (Component)
▪Release coordination/CDM (Process)
▪System-level monitoring (Component)
▪User-level monitoring (Process)
▪Team collaboration (Process)
17 Copyright 2014.
Tooling Categories, Classes & Maturity
Maturity▪Commodity
− Continuous Integration− Cloud management− System-level monitoring
▪Established− Issue tracking− SCM− Artifact repository− Environment provisioning
▪Growth− Application release automation− Test data & test result management− Release coordination/CDM− User-level monitoring− Team collaboration
18 Copyright 2014.
Product Evaluation Criteria for Enterprise Use
1. Broad applicability of your standard tools you choose: scaling out DevOps means being able to support your mainframe wrapper as well as your “new build” apps− “DevOps in the Dark Corners”
2. Especially for Growth tools, favor products that have been around for a while, unless there are exceptionally clear business reasons. − Lots of bleeding edge tools in this area will not survive, and will require extensive hand-holding
− Very new tools are what the teams should be researching and, if desired, requesting exceptions for
3. For Established or Commodity tools: no need for lengthy bake-offs. Choose the 1 or 2 most popular tools in use by your teams; validate enterprise scalability through expert sources and/or testing
19 Copyright 2014.
Product Evaluation Criteria for Enterprise Use
4. For Component tools, look for APIs, strong integrations and an open extension model− Component tools will become increasingly “invisible” but need to be tightly integrated with each other
5. For Process tools, look for user-friendly interfaces that are not just “suitable for Tech Heroes”, and visualization capabilities− The closer to the process level, the more non-technical users the tool will have as DevOps scales
out
6. For Process tools, look for integrations with “adjacent” IT and business processes: portfolio management, service management, change management
7. All tools need to be automatically installable and configurable− Based on a versionable configuration
20 Copyright 2014.
Product Evaluation Criteria for Enterprise Use
8. All tools need to support the ability to version any created artifact− Whether binary deliverable or process definition
9. All tools need to support the ability to “partition” the tool’s domain model according to teams, departments etc.− “Multi-tenant lite”
10.All tools need to support the ability to apply security settings to these partitions
11. All tools need to provide published reporting APIs or other supported means of data access− No matter how good the reporting capability of the tools, you will need to get data out to answer
questions relating to multiple tools, e.g. providing audit information
21 Copyright 2014.
DevOps, CD & The Business
“Making DevOps compatible with the rest of the organization”
▪Team-level DevOps & CD initiatives can become “black holes”: great stuff going on inside, no information coming out
▪As DevOps adoption scales, the tooling and process starts to touch “traditional” IT & business processes
− Portfolio management
− Service management
− …
▪Moving from “dev to prod” to “concept to cash”: need the ability to follow business-relevant IDs through the toolchain
− “Track and trace”
▪Link features to user-level monitoring
22 Copyright 2014.
Next Steps
▪Download the guide:go.xebialabs.com/IT-Managers-Guide-to-CD.html
▪Learn more about XebiaLabs:xebialabs.com/products/xebialabs.com/solutions/continuous-delivery/
▪Stay informed:
blog.xebialabs.com
@XebiaLabs
youtube.com/xebialabs
23 Copyright 2014.
Next Steps
Questions?
Thank You!