6 Tips for Effective Remote DevOps Teams



DevOps principles were geared toward collaboration from the start, but since the current COVID pandemic is forcing teams to work remotely, those principles are being battle- tested.

While most organizations have been gradually transitioning to modern DevOps practices, many were caught off guard by the pandemic and are now having to rethink their approach to IT, the cloud, and collaboration. In this post, we will discuss how DevOps teams can weather the transition to remote work.

Key Considerations for Remote DevOps Teams

2nd Watch survey of enterprise IT companies found that IT and technology teams are primarily concerned with three major areas: security, culture, and collaboration. According to the survey, 75% of respondents said that they are prioritizing cloud security, while 60% are prioritizing cloud-native culture change (or DevOps), and 51% are prioritizing conferencing/collaboration, which, as the survey said, “likely reflects the growing need to support remote workers.”

If these top priorities were addressed, DevOps teams would be better equipped to handle life in a remote world. Let’s look at how we can address these areas at every step of the development pipeline.

1. Build

In the same survey cited above, 63% of respondents said that their biggest challenge was “providing remote workers access to corporate systems” due to security concerns around access and authentication. This challenge can be overcome by using modern Zero Trust Network Access solutions, and choosing the right one for your organization is essential.

DevOps teams need access to collaborative development tools, and Git-centric development can help solve that problem. Git repositories allow developers to work asynchronously on code and have it automatically merged and versioned. Think about ways to make your team more Git-centric during this phase.

While code is hosted in the cloud, it is modified on a local machine. Here again, rather than using local software, you could provision cloud-based IDEs that are easy to maintain and upgrade. They will bring consistency and unify development processes across the team.

In addition, QA and IT should be involved as early as possible. Developers should consult with them about the reliability and practicality of new features and design decisions.

2. Test

Testing should start from the minute that code is written, following the shift-left model. Developers should be able to conduct dry run tests and get immediate feedback on the quality of their code, which they can do using tools like Flux and Jenkins X.

Further, test automation is key for building reliable and high-quality applications, and most organizations have plenty of room for improvement in this area. In fact, according to the 2019 state of testing report, “only 25 percent of respondents claimed they have more than 50 percent of their functional tests automated.”

Test automation enables you to run tests in parallel, thereby speeding up the testing process. It also reduces human error by making tests repeatable and can be closely aligned with the build process using tools like Jenkins.

3. Ship

When code is ready to be deployed, you have to decide which changes to deploy. An anti-pattern here is to allow bureaucracy to slip in and slow down the pace of deployments.

For example, Camille Fournier tweeted that some organizations enforce bureaucracy by requiring that “all deployments should be paused” and only the changes that are “approved by very senior management can go through.” Charles Betz, a Forrester Principal Analyst, noted that this “is an understandable reaction. But it again represents a fallback to an older paradigm you may regret…Siloed teams perform even worse when everything is remote.”

A fail-fast mentality is central to DevOps. As soon as your team becomes dominated by the fear of failure, it will set off a domino effect that makes remote work even more challenging. It’s crucial to learn how to fail and to limit the impact of failures.

4. Run

Amazon popularized the principle of “you build it, you run it.” This requires developers to be involved in the running and management of applications in production. The only way this can work is if teams are cross-functional. Small cross-functional teams should own and run the particular microservice that they build.

5. Monitor

Moving DevOps tools and processes from local desktops and servers to the cloud means that you will need cloud-native monitoring tools. There are lots to choose from (including open- source, vendor-specific, and specialized monitoring tools), and they should be fully integrated to enable an end-to-end view of all parts of the system as well as all activity.

6. Respond

With DevOps teams working remotely there are higher chances of failures happening in production due to communication gaps that creep in. Considering this, a timely response is essential to staying resilient despite failures.

DevOps teams need to have an incident response plan in place that includes instant alerts. They also need training and updated documentation that reflects the challenges and changes that come with remote work.

With the lack of stand-up meetings, coordinating an emergency response can be more difficult. In fact, 47% of organizations in the aforementioned survey said that “conferencing/collaboration systems haven’t worked as expected.” The last thing that any DevOps team wants to deal with is unreliable video conferencing tools or team members who don’t know that discussions are happening on a particular Slack channel.

Sorting out collaboration tools and processes should be a top priority of any incident response plan. These decisions should be clearly documented and communicated to the entire DevOps teams, and especially to the on-call engineer.

Although working remotely is a challenge for most DevOps teams, it’s just what they need to push them further down the path of modernization. Remote work is here to stay, even when the pandemic ends. To stay in the game, you should invest in creating a fully virtual DevOps team – and you should start today.

Twain began his career at Google, where, among other things, he was involved in technical support for the AdWords team. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications. Twain is a regular contributor at Fixate IO.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Skip to toolbar