So DevOps has hit your organization, you’re hearing the term passed around every other week. What does this mean for you organization, team, and job? Isn’t DevOps just automation? Could your role, or entire team be eliminated, with some tools doing your job? You may be surprised to find that, while DevOps does include automation, DevOps doesn’t work without teams. DevOps is a potent mix of tools, processes, I.T. practices, and most importantly, teams. Without teams, DevOps doesn’t really exist. The right implementation of DevOps improves the quality of the major (and minor) IT roles. This means it’s easy to know when a DevOps implementation isn’t working. Will you have to work differently in your role to get the most out of DevOps imlpementation? Probably. Will you definitely lose your job because of a DevOps adoption at your organization? Probably not. This article breaks down how DevOps affects the general roles in most IT organizations; from developers to operations engineers to QA, and management.
As a developer, your primary job is to build professional grade software. What makes you professional is working within the context of a team. What you produce must fit with what other developers produce. It must also be testable and tested by other teams. It must also be packaged and run on environments managed by others teams. DevOps affects the context of your work. Starting with the workflow you use to introduce changes (version control), to how you notify testing teams when new changes need to be validated, to how you deploy your changes to higher environments. Through a combination of DevOps practices (CI, CD, Gitflow) and tools (build server, release management, artifact management, version control) you’ll be able focus on your specialization, and spend more time in the flow, producing meaningful work.
- Access to infrastructure quicker
- More control over infrastructure
- Immediate feedback to the quality of new changes
- Seamless interactions with QA and Operations through notification tools and build servers
As an operations engineer, you’re used to receiving 2 main types of requests; create new infrastructure and maintain existing infrastructure. Developers and QA request resources and you have to make it happen. Their packages and dependencies must work on your servers or your job is to keep the resources up. You may feel like you’re the last one to receive information, and first to respond to issues. Your goal is to stabilize the system, but the dev team keep introducing breaking and disruptive changes. Enter DevOps. It’s not a cure-all, but it does transform you to become cross-functional; allowing you to imbibe some of the practice developers use, such as scripting, source control and versioning. You can design blueprints of infrastructure to be used and create them on the fly. You can leverage disposable environments for those quick requests from devs and QA. You can also automate tedious and repeatable tasks, to focus on the entire system and higher quality work.
- Perform operations tasks with code
- Employ some developer practices like version control, scripts
- Automate repeatable functions
- Think big picture, engineer system for resilience and handle multiple scenarios
Instead of waiting for Developers to notify you of their changes so you can run your tests, DevOps tools takes care of that for you. Instead of waiting on Operations to create a test environment to test new features, you can spin up environments to on demand. DevOps allows you to work on writing automated test suites instead of working on repeatable tasks like manually running tests cases. You can choreograph your test executions to commence after a successful build. You can also automate notifications back to dev teams on the status of new changes.
- Plug validation seamlessly into Continuous Integration
- Write automated test scripts instead of running tests
- Think big picture and write test suites
- Automate test execution instead of waiting to get notified
- Automated notifications
As a manager, If you’ve just managed to adopt the Agile methodology, introducing another new practice may not be of interest to you given all the competing priorities. Many managers have promptly dismissed DevOps as the new fad in the industry while simultaneously bemoaning delayed projects, rolled back deployments and the sunk cost of fixing defects. The side effect of implementing DevOps practices and tools are data that can be translated to metrics. Metrics will helps leaders and management make informed decisions such as how to allocate resources, what initiatives and tasks to focus on, and when/if to course correct on actions. You’ll also have access to the real-time status of value delivery. You can also foster an environment of continuous learning as your team observes you adjust and react to the metrics your DevOps implementation is producing.
- Metrics to view velocity, compliance, quality, and value delivered
- Information radiators to know the status of delivery in real time
- Respond to changes as they occur
- Measurable Visibility into the Quality and Quantity of work produced by team members
- Alignment of activities with business goals
Hopefully DevOps no longer raises eyebrows when mentioned at your next All-Hands meeting. It’s aim is to bring improvements across board. It allows your organization stay competitive. Your role and tasks may be refined, you may have to learn some new tools and practices, but you’ll be more valuable in your role when you adopt DevOps.
The DevOps Handbook, Gene Kim et al.