DevOps is the hot new thing. DevOps promises better cooperation between developers and operations, test environments on demand, and seamless deployments through multiple environments. But many doubt the practicality of DevOps. What practices are prescribed? Where are the certifications? Is this thing real?
The good news is that we know large organizations that have been bridging the developer/operations gap for years - longer than "DevOps" has been a term.
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Getting Started with DevOps
1. Getting Started with DevOps
Eric Minick
Consultant & Technical Evangelist
eric@urbancode.com
1
2. Why DevOps?
• Cool new Applications are delayed because
they don’t run in our production
environments
• Outages due to Dev / Ops communication
problems
• Releases fail due to environmental differences
2
3. DevOps Is NOT
• Giving the developers the root password
• A job title
(ok, it is, but that doesn’t make sense)
• Asking Developers to be sys-admins or sys-
admins to be developers
• A formalized process like ITIL or Scrum. Nor is
it incompatible with those processes
3
4. DevOpsis a philosophy
• Agile & Lean applied to the whole software
delivery chain, not just developers
– BizDevQaSecReleaseOps
• Driven by efficiency and consistency
– Building applications
– Building environments
– Configuring applications and environments
• Optimizing software delivery end-to-end
4
5. DevOps needs People, Process and Tools
• People
– Changes in behavior
– Potential for new roles
• Process
– Tweak SDLC processes for more responsiveness
– Regular refinement
• Tools
– Chain of complementary tools
– Supporting people and process
5
7. Agenda: Process, People, Tools
• Process
• People
• Tools
•Build •Deploy to
•Deploy to
Test Envs
Dev •Unit test
•Dev QA •Functional
and Perf
Ops Staging
•Deploy to
Deployment Production
test
7
8. Start updating Process: The Goal
• Goal: Unify the software delivery process
across the SDLC
– Reduce duplication of effort
– Improve consistency
– Embrace change
– Remove known sources of error
8
9. Start Updating Process: Form a Team
• Establish a team that improves process
• Members:
– Stakeholders across the SDLC
• Devs, QA, Release, Ops, Security…
– More hands-on people than managers
9
10. Start Updating Process: Form a Team
• The team should meet:
– Regularly (perhaps inline with Dev’s Sprints)
– For post-mortem’s of outages and good releases
• Refining the Process
– Start from current process
– Respond with real change to real failures
• “We should be more careful” doesn’t count
10
11. Start Updating Process: Ex. Refinements
• Because errors creep into the official builds…
– Unify the CI and official builds and test nightly
• Because a new app wasn’t compatible with
the live environment…
– Involve sys-admins in early design phases
– Setup test envs that more closely match Live
• Deployments failed due to manual error
– Increase automation in deployment
11
13. People: Living DevOps
• Break down the Dev / Ops wall
– Different roles are ok
• Involve members of “the other side” in your
decisions.
• When in doubt, get a mediator
13
14. People: As Developers…
• Inform Ops early of new applications and other
changes coming down the pipeline
• Include health and status monitoring in the app
• Consider involving Ops in early architecture
meetings. They’ll ask:
– So… how are you going to back that up?
– What security protocols are we using?
– Will it run in the cluster?
14
15. People: As Operations…
• Share network diagrams with interested
developers.
• Support Dev and QA with “cheap” and
disposable test environments
• Collaborate with QA to implement smoke
testing for all environments
15
16. People: Facilitators
• Consider Dev / Ops facilitators
• Especially helpful if:
– Cultural momentum seems insurmountable
– Dev and Ops groups are geographically distant
– Each party is attempting to use “DevOps” to
bludgeon the other into submission
16
17. People: Facilitators – Release Management
• Release Management
– May already own the end-to-end process
• “System” knowledge is distributed and
Release Managers are often already the hub
– Distributed development
– Offshore development
– Outsource development
– Outsourced IT operations
17
18. People: Facilitators – Env. Management
• Environment Management
– Emerging group. Owns what goes into
environments and their configuration changes.
• Well positioned to maintain environment
consistency and integrity.
18
19. People: Facilitators – Delivery Architect
• Chairs SDLC process group
• Strong technical skills
– Understands writing, running, tuning and
monitoring complex apps
• Strong people skills
– Has to bring many people together
– Needs to be great at asking questions
19
20. Agenda: Process, People, Tools
• Process
• People
• Tools
“Man is a tool-using animal. Without tools he is
nothing, with tools he is all” – Thomas Carlyle
20
21. Start updating Tools:
• Tools should support people and process
across the SDLC
– There is no single “DevOps” tool
– Build a coherent tools chain
– Tools should be reusable across silos
21
22. Start updating Tools: Types of Tools
• “How do we get our software from source
code to a deployable package?”
– Motivated by the need for an
authoritative, traceable deployable
• Build Systems:
– Perform CI for developer feedback and official
builds for release.
– CI build is the Official build
– Store build output in an artifact repository
22
23. Start updating Tools: Types of Tools ctd.
• “How do we get a deployable package on to
an environment?”
– Motivated by high deployment effort and/or high
deployment risk
• Application Release Automation / Deployment
– Replace manual steps and cobbled scripts
– Consistent deployment process across
environments
– Consider release management aspects like
approvals to match raw automation
23
24. Start updating Tools: Types of Tools ctd.
• “How do we create environments?”
– Motivated by dev / prod environment variances
– Need for frequent new test environments
• Virtualization and Environment Provisioning
– Public / Private “clouds”
– Installing and configuring middleware
24
25. Start updating Tools: Types of Tools ctd
• “How do we know it works?”
• Automated tests suites speed testing as
changes are brought to production quickly
• Smoke tests can be incorporated in automated
deployments to detect failures
25
26. Start updating Tools: Forming a Tool Chain
• Integrations
– Direct integrations are the easiest links
• APIs
– An API of some sort allows you to
create an integration with current
(and future) tools
• Conventions
– Short of an integration, common conventions provide
an interface for adjacent tools
26
27. Summary
• The Dev / Ops gap is a sign of a broken system
– The business wants change and stability
– As a team, we can deliver it
• Examine processes and look for improvements
often
• Expect to implement new tools, but do them
to support new processes not for their own
sake
27
28. Instigate change
Youshould reach out to people in other silos
28
29. References
http://urbancode.com/resources
• Enterprise CD Maturity Model
• Death to Manual Deployments!
• Build & Deployment Automation for the Lean
Economy
• ITIL Release Management and Automation
Urbancode.com/blogs/
Twitter.com/UrbanCodeSoft
Facebook.com/UrbanCodeSoft
Slideshare.net/Urbancode
29
30. Yes, we sell products for this
• uBuild
– Build automation and CI for the hard problems
• uDeploy
– Deployment and release management
• uCloud(coming soon)
– Environment provisioning for in-house PaaS
30
Reduce Duplication: For software build, don’t have Developers doing CI builds and Release Managers doing an official build that is differentConsistency: Same deployment process in all environmentsTransition, “This is all well and good, but how do we get there?”