Nebbia Technology

29 January 2018

1 Comment

Introducing a DevOps culture

A big part of the DevOps discussion is the concept of implementing a DevOps culture across organizations. Unfortunately, I often hear it as something that should just happen. We’ll take care of the process and tools, you go and focus on the DevOps culture.

How do we define that DevOps culture? What does it mean to have a DevOps culture? Who implements this DevOps culture?

Your organization’s culture of DevOps will often be the defining factor on whether you have a successful organizational change, or whether the changes that you implement impact pockets of your organization.

So what exactly do we mean when we say DevOps culture?

Let’s talk about the behavioral changes that we’re looking for when we talk about DevOps.

At the core of DevOps, we need increased collaboration. Sure, this is collaboration between Development and Operations, but it goes way beyond that because collaboration across teams often involves breaking down walls (physical and virtual) and changing behaviors across the organization.

So collaboration between Development and Operations might start with a conversation about shared goals and priorities, but we then want to extend it. To the way we design and implement systems, deploy software, monitor its effectiveness in production, and think about new servers or services that will be needed to support new features.

As teams start thinking about these things, they often shift towards a Production-first mindset.

What process changes foster this DevOps culture?

As your team looks to shorten the cycle time between an idea and production, think about the things that are preventing you from getting there.

Branching strategy

It could be that your branching strategy doesn’t allow your teams to work on multiple features at the same time. So decide if you’re using a version control system that aligns with what your company needs and, within that version control system, determine if your branching strategy fosters collaboration and your ability to work on and deliver multiple features.

Follow the code from each branch, through code review, build, deployment, all the way through production, and find the bottlenecks or opportunities for process improvement.

Environments

Do you have the right environments to support your development, testing, and overall delivery? This is a great opportunity for Dev and Ops to work together and define an environment strategy that will provide teams with a way to collaborate and create feedback loops.

We’re looking for repeatability and agility, so these environments should be created in an automated way. Your applications and databases would then be deployed continuously as part of your release pipeline.

Another great opportunity here is to leverage the cloud as a tool that can enable agility. Move away from thinking of your infrastructure as a fixed resource and, instead, think of it as a flexible and powerful resource.

Azure offers ARM templates, for example, which give you a way to create Infrastructure as Code. Dev and Ops can work very closely creating these automation scripts and templates, which can and should be applied across all environments. As soon as you need to add new services to support your application functionality, developers can make a changes to their Infrastructure as Code scripts and have those changes go through a code review process where Ops verifies and approves changes. We then apply those changes across various environments until they make it to production along with code and database changes.

Automation

Automating manual processes enables collaboration, frees people up to work on high-value tasks and helps you have a repeatable process. Manual processes are error-prone and if you’re trying to achieve continuous deployment, automation plays a very important part.

We don’t implement automation just to say that we have it automated, however. We automate to help teams deliver faster, enable quality practices through automated tests, and gain those very important feedback loops between team members and between the delivery team and the business.

Measurement

How do you know you’re delivering value if you can’t measure it? What does value actually mean to your organization?

If you added a button to your page, do you know how often your users are clicking on it? Once they do click on it, is your application behaving the way that you expected?

These are things that Dev and Ops teams should collaborate on to make sure developers are adding the right instrumentation, and that operations can access metrics to quickly take action based on the feedback, and provide developers with the information to continuously improve the application. This requires team members to work closely, without a wall in between them and with a shared set of priorities.

Is DevOps all about Dev and Ops? What about the rest of the organization?

DevOps transcends development and operations. A DevOps mindset and the changes and improvements that can be achieved with a DevOps transformation is something that impacts the entire organization.

Implemented correctly, it will change the way your organization develops ideas and turns them into products, the way initiatives are prioritized, and how you think about quality and alignment across the organization.

At its core, DevOps fosters collaboration across the organization, removes silos and ensures everyone is aligned with and aware of the organization’s direction and how they fit into achieving the company’s goals.

What about the DevOps team?

Often, as companies introduce DevOps, they create a DevOps team, or perhaps there’s already a DevOps team that has the role of automating deployments.

Creating a team with the purpose of ‘doing DevOps’, however, goes against what DevOps is trying to implement. You’re creating another silo and potential bottleneck with a new team that is in charge of automating, measuring, creating environments, collaborating, etc.

You’re trying to create a DevOps culture where everyone across the organization has a DevOps mindset. So your DevOps team is there to enable the organization to achieve this, spread the culture and practices, rather than being the only team that is doing DevOps.

If you need help with DevOps consulting, custom software development, Azure, or training, get in touch

Discover more about applying DevOps processes to the database on the Redgate solutions page