Mapping out your DevOps implementation?

Mapping out your DevOps implementation?

A week ago on Tuesday I participated in an online panel on the subject of Mapping Your DevOps Journey, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery, and DevOps.

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes. In this blog post, I will share some of my contributions and thoughts from the panel.

People: culture and roles

When doing a transition of any sort, it's important to distinguish the responsibilities and goals of different parties. The fundamental question to ask in a DevOps transition is what is the role of the development organization? I believe the answer is delivering the software. Pursuing that goal should be the first and foremost goal for the transition, and thus, in order to allow the development organization to develop the software, we need to separate the development from the DevOps organization or team.

I believe there's an on-going transition in many organizations where the role of the traditional IT is transforming from serving the end users, to providing the end users platforms and tools that they can then use to serve themselves. This is also what we have helped organizations to achieve in the banking and in the public sector in Finland. In both of these cases, Deveo provides the tooling that helps to remove a lot of manual work from the IT department and shifts the work towards thinking proactively. It's no longer a question of "what's the most urgent fire to extinguish", but instead "what are the needs tomorrow that the development organization has."

I believe the role of the IT organization is to think one step ahead, asking "what are the tools that the developers are going to need tomorrow?", testing those tools out, and providing them even before the developers ask for them. In a lot of big companies, there is a huge problem of the Shadow IT which raises from the fact that the IT does not support the needs of the development organization fast enough. That happens because traditional IT organizations are buried with manual and repetitive work. It's good to see that the roles and responsibilities are shifting to be more practical in that sense.

Technology: infrastructure and tooling

We have over 10 years of experience from a development organization consisting of thousands of developers. In general, I would start off any DevOps transition with the very basic tools; version control systems, delegated access management, issue tracking, documentation, and the very basics of Continuous Integration. These tools should be provided to the development organization in such a way that they can be taken into use when the need arises. Providing the aforementioned tools in the form of a self-service platform that the development teams can utilize allows them to take the next steps more quickly, as they don't have to reinvent the wheel or build snowflake solutions.

It's important to adapt the tools one step at a time. There are myriads of tools for achieving various things. If you bring the whole stack of tools, e.g. 100 tools at a time and start enforcing that everyone needs to use all of them, it will probably do more harm than good. Start with small steps and provide the steps at one chunk at a time but still in a self-service manner so that everybody can start using the tools when they feel.

Process: the value stream

From the process and value stream point of view, I would basically ask these 4 different questions:

  • What is it that we want to achieve?
  • Who can help us to achieve this?
  • How can they help? and
  • What are the tangible actions that need to happen?

These four questions are the base for Impact Mapping. When we base the process on these questions, we can be sure that we move in the right direction. The most important question before starting any transition is to build a common understanding of what we want to achieve.

Communication plays an extensive role in the DevOps transition. With communication, we come back to the tools. One of the things that help companies to build an extra layer of communication between the dev and the ops are so called team chat tools, such as Slack. These tools bridge a lot of communication gaps between the Dev and Ops because people can hang out in the same channels. The other trend in addition to bridging the communication gaps with the team chat tools is that they can be used to do ChatOps, e.g. starting builds automatically, getting reports and notifications from various tools and interacting with the whole tool stack from the chat window.

Last but most definitely not least, I would emphasize the effectiveness of automation. If you can document the process, you can probably automate it.


You can watch the recording of the panel below. If you liked what you read, do share this post around.

Seamless software development.

Code management and collaboration platform with Git, Subversion, and Mercurial.

Sign up for free
comments powered by Disqus