lassedesignen - Fotolia
You need a systematic approach to DevOps. Enterprises must craft a step-by-step transition to DevOps, not throw out everything old and bring in everything new at once.
Most companies have experienced software developers and system administrators who understand the software development lifecycle and IT operations. They still need help to determine how to get an initiative going.
The seven key steps to starting DevOps range from careful and methodical planning through tool selection, automation, pilot projects and continuous learning opportunities.
1. Create a DevOps transformation roadmap
To adopt DevOps, create a roadmap. The plan needs to map out how to start with DevOps, in a step-by-step format. A roadmap enables an organization to choreograph its actions upfront.
Publish the roadmap and accompanying documentation in a central location where stakeholders and team members can access the content at their convenience. For example, use Microsoft PowerPoint or Google Slides to document the roadmap and post those slides on the company's collaboration platform. Include enough detail so the roadmap is easy to understand -- even without a presenter. Resist the temptation to email the slides around to ensure the roadmap isn't lost among the latest emails from HR.
Stakeholders can see the roadmap and ask questions about its role in their project delivery process. IT teams can see the next steps in the transformation as they make changes. Everyone has a chance to ask questions and provide feedback on the roadmap. There are no secrets, which helps quell rumors.
A DevOps transformation roadmap isn't a one-and-done project. Be prepared to update and iterate on the roadmap as your organization advances on its DevOps journey.
2. Select a DevOps toolchain
Critical to starting DevOps is to choose a toolchain, but it's just one step. DevOps can't be bought, regardless of what the friendly automation software or repository management salesperson says. Tool selection is essential to account for developers' requirements, as well as integrations and technology stacks.
DevOps toolchain selection and composition also includes a licensing and security exercise. For cloud-based toolchains, organizations must create a model of their spending distribution -- and amounts -- across all their tool vendors and cloud services provider. A DevOps toolchain can become a vector for man-in-the-middle and similar attacks. Involve the security team during the due diligence and implementation phases of the new toolchain.
IT organizations should take a pilot project approach when selecting a DevOps toolchain, wherein internal teams work with tool vendors -- and potentially even a professional services firm -- to implement the right mix of tools that meets their delivery requirements through training, and then a manageable first project.
3. Implement tools and strategies for cultural transformation
There's a certain amount of comfort with the status quo for some developer personality types. DevOps disrupts some organizational and political power structures as developers gain power in the delivery process. To meet these challenges, put tools and strategies in place that foster cultural transformation across the parts of the business that will experience the most changes.
To implement tools for DevOps culture, follow these steps:
- Open the new DevOps toolchain to the development, operations and security teams.
- Provide DevOps training for development and operations teams to teach them the requisite skills to use the new toolchain.
- Capture and define a collaboration strategy between developers, operations, QA and security teams for workflows.
- Train stakeholders and business units on DevOps concepts so staff outside the IT department learn new ways to interact with development and any new expectations product development places on them.
- Create internal process documentation that captures DevOps processes and publish it to a central repository, such as a wiki, for easy updates.
4. Automate processes
The prospect of automation can be scary in some corporate environments. To dispel this fear, consider a transparent and phased approach to DevOps automation.
Set automation goals by priority. Automating every process at once isn't realistic or feasible -- for any organization. For example, when getting started with automated testing, focus on software testing first, then automate security testing. While automated testing can't replace the expertise of a human tester, a phased approach enables organizations to demonstrate how automation can augment the staff's capabilities.
This approach also enables IT admins to work directly with the teams who will feel the changes from the automation of their tasks. Use this opportunity to explain the business reasoning and help them adapt their job duties to automation.
5. Focus on data and analytics
Modern DevOps tools enable IT teams to tap into actionable data from across their toolchain. Harnessing that data is integral to DevOps success because it alters how IT teams communicate with stakeholders and across departments.
Set up dashboard reporting for stakeholders so project leads don't have to generate management reports manually. Introduce stakeholders to the dashboards and how to send the DevOps team feedback on the data they receive. A "dashboard first, ask questions second" mentality can require some minor cultural adjustments, especially in management.
6. Run a pilot project
A DevOps pilot project enables teams and stakeholders to take their new tools and processes out for a spin on a small project. A typical school of thought is to pick an internal project without a customer attached, to lower the risk if something goes wrong: A willing -- and paying -- customer for the project raises the stakes for the team -- and the project. On the other hand, with a cooperative client as part of the project, DevOps teams can receive feedback from outside their organization.
7. Prepare for continuous learning and improvement
There is no traditional last step to the process of starting DevOps. Just as software follows a continuous integration/continuous delivery process, so do DevOps processes and tools. Over time, teams are going to learn lessons about how to do something better. Those lessons need to find their way back into the organization's strategy. New staff members will bring new perspectives and experiences from previous employers and projects. Inevitably, teams will want to fold some of their learnings and expertise into the DevOps framework as well.