Why DevOps is all about creating one team
What is DevOps and how should organizations introduce it? In this series of articles, we talk to DevOps thought leaders who are leading the way in implementing advanced software development practices like DevOps for database as well as application development. What are the challenges they’ve faced, how have they overcome them, and what lessons can other IT professionals learn from them?
A Contract Solutions Architect for a manufacturing software development company, Tonie Huizer has 20+ years’ experience working with Azure, SQL and other Microsoft technologies. A Microsoft Certified Azure Developer Associate, he has the knowledge to design, build, test, and maintain cloud applications and services on Microsoft Azure.
He constantly explores ways to work smarter and more efficiently with databases and spoke at the 2021 PASS Data Community Summit about ‘DIY database clones’ and how to use disposable databases in the DevOps process.
But where did this thought leader’s journey start and what has he learned about DevOps?
Can you tell us how you started your journey towards DevOps?
When we first started to implement DevOps, we had three teams and this caused us a problem. The Development team are .Net developers responsible for software development to meet customer needs. The Consultant team have to understand what the customer wants, communicate it and deploy the software. The two teams were working together but not always towards the same goal, creating what I call the ‘wall of confusion’.
In addition, we had the Customer IT team, who work in the IT departments at customer organizations. They would work closely with the Development team, but they weren’t part of the core team implementing DevOps.
I set out with the aim to create one team. We’re not quite there yet but we have merged the Development and Consultant teams into a single, customer-oriented team. The Customer IT team is still separate but they now work with our tools and processes which is helping. The next step is to move them into the team as well so that we have one DevOps team.
Does this popular definition of DevOps from Microsoft’s Donovan Brown resonate with you?
“DevOps is the union of people, process, and products to
enable continuous delivery of value to our end users.”
Yes, absolutely, and I think the order of ‘people, process and products’ is important when implementing DevOps. If you don’t change the people, you can give them new processes but they won’t accept them. Similarly, you can buy all kinds of software licenses, but if the process isn’t changed and the people don’t accept it, it doesn’t work.
What kind of culture does a business need to implement DevOps?
You need to have a very open culture. People need to be able to say whatever they think and be able to change something. It’s the type of culture where anyone can bring up any problem, and people in the team will help them to resolve it. This should be consistent across all teams and they need to move forward towards a DevOps approach together.
For example, if only one team in the organization is applying DevOps and the other teams aren’t, you won’t be able to make progress, so there should be a steer and buy-in from senior management that all teams should work in this way. You can’t introduce a culture or working practice in one department or team before the others; they need to progress together.
Have you found there are particular roles that are resistant to DevOps?
DevOps is about delivering software faster. If there are people resistant to change, they can often be convinced by the value to be gained from working in this way. By, for example, seeing development teams releasing new features every two weeks to meet customer needs.
One barrier might be from higher up in the organization because of the up-front costs and investment required to change the processes, like acquiring software licenses and the investment in automation. Or the time required from the teams involved, particularly in, say, a consultancy organization where this work takes them away from projects that are billable to clients.
When we first started to embrace automation and move away from doing things manually, there was a lot of research and development required. We were lucky that we were able to have that time, but if R&D time is restricted, it will significantly slow down progress. There needs to be budget and management agreement for both time investment and software licenses.
What parts of the software development lifecycle need to change when introducing DevOps?
In 2018, we had a lot of manual labor per developer. Every developer had their own computer to develop and build the software. From that computer the software would be copied into a file share and there was no automation. The time to build and release software varied per customer as everyone worked in different ways and there was no consistency of processes.
We introduced build agents so the build process wasn’t reliant on the developer or the developer’s machine. Instead, everything was built at the central build agent and then released through release agents. This transformation could only be done because we invested time in understanding how to build the build agents, how to configure them and what parts could be automated.
To get to this point, from a process perspective, we had to first align the processes from the different customers and from the different consultants. The developers didn’t understand or want to use build agents initially. Similarly, consultants debated whose process was best and which should be used as the model for automation. So, a lot of time was invested up front to align them and their processes. Of course, there were some deviations and special cases, but we worked through those by explaining the benefits of a consistent and automated process.
Some of the changes, for example using a build agent, will prove themselves over time. Initially, the response of the developers was that using the build agent took longer than on their own machines, with builds taking three minutes rather than three seconds. But over a few weeks we showed them that the build agent will work every time, every day, every minute, 24/7, whereas their machines can break down, and updates can interfere with configurations. So ultimately the value to them is an overall increase in productivity.
One of the risks of moving to automation was a drop in communication across the team. If they can add their comments into a system instead of talking to their colleagues, they will do that. We explicitly asked people to reach out to each other, not only in daily stand-ups or in the bi-weekly retrospectives but, if they had a problem, they should call someone, or send a message to the team there and then. This is important for team building, as well as for the efficiency of the business.
What were the criteria for choosing third-party tools?
We’re a Microsoft partner so investing in Microsoft products wasn’t an issue. When we understood the principle of branching databases and building different branches of the database, we knew we had to have some tools to help us. However, it took us a year and a half to convince the team leads that we needed to invest in Redgate Deploy, which standardizes and automates database deployments from version control through to deploying changes.
We were already using SQL Source Control and SQL Compare, so while we did spend some time evaluating other software options, Redgate was the clear winner for us. In fact, our requirements list was built from the knowledge we gathered from talking to the Redgate team. They helped set the vision for us so it was then a clear path to purchase the tool that could help us achieve that vision.
Has the team seen value in DevOps?
Yes, and if you ask them about moving away from automation and going back to how we used to do things, they don’t want to. They see that the pace of deploying software to the customer has improved. We deliver at least five products every two weeks, whereas previously we were inconsistent in delivery. It’s not only the time savings that are a benefit, but the quality of the deployments has also increased. It’s right every time.
What’s the next step in your DevOps journey?
Database DevOps is behind software DevOps. If I was to do this process again, I’d move them forward together. At the time, we didn’t really know the value we could get, or the value that Redgate products could bring us. We didn’t understand in 2018 what ‘building a database’ meant.
We actually work with three database environments; a development environment that’s shared, a test environment that is also shared, and the production databases themselves. The production databases aren’t built – they’re already there and they’re modified as changes are released through the development and then test environments.
If we had understood what could be achieved, done more research up front, and understood how Redgate Deploy could help us, we would have evolved both together. I would have also merged the two teams and their work processes at the same time as evolving processes. We did this in part but ignored the database development part.
The challenge is that we have 13 databases, all dependent on each other. The first step is to get the different developers, across two teams, working together to start to configure the process with not only one database, but with 13 databases that have software projects relying on one, or more, of the databases. We have a goal to dismantle at least half of these databases and this process should help us bring the Customer IT team into one DevOps team.
If you’d like to know more about how modern organizations are introducing DevOps, read other posts in this series of conversations with DevOps Thought Leaders:
- Why DevOps needs a change from a ‘me’ to a ‘we’ mindset
- Why you don’t just buy tools to make DevOps happen
To find out more about how organizations can embrace DevOps and deliver value quicker while keeping data safe, visit our DevOps solutions pages.
Read next
Blog post
Why DevOps needs a change from a ‘me’ to a ‘we’ mindset
What is DevOps and how should organizations introduce it? In this series of articles, we talk to DevOps thought leaders who are leading the way in implementing advanced software development practices like DevOps for database as well as application development. What are the challenges they’ve faced, how have they overcome them, and what lessons can
Blog post
Why you don’t just buy tools to make DevOps happen
What is DevOps and how should organizations introduce it? In this series of articles, we talk to DevOps thought leaders who are leading the way in implementing advanced software development practices like DevOps for database as well as application development. What are the challenges they’ve faced, how have they overcome them, and what lessons can
You may also like
Blog
Using the new Flyway Diff commands
Blog
The rising need for database monitoring in Financial Services
Blog
Why you don’t just buy tools to make DevOps happen
Blog