Kendra Little

10 March 2020

How Database DevOps can support remote working in the age of Coronavirus

As cases of COVID-19 spread worldwide and concerns mount, organizations everywhere are responding with efforts to maintain the flow of business while keeping employees and their families safe. Development and IT teams everywhere are either validating that their team may effectively work from home or have already moved to a full-time working-from-home policy.

Teams who have already implemented Database DevOps have an advantage over teams who work in a more legacy fashion in terms of adapting to a fully remote team working situation. This is because Database DevOps integrates tooling, process, and communication practices which flow smoothly whether team members are sitting physically together, or whether they work in distributed locations.

One example of this is the Pull Request workflow

Many teams who have adopted Git choose to implement it across their DevOps practices, whether they are working with database or application code.

Figure 1: A diagram of two feature branches in a Pull Request workflow

When this workflow is applied in Database DevOps, team members who need to make a change to a database work in a dedicated development database and utilize a feature branch in Git. This combination produces an isolated working environment which beautifully supports remote work: each team member makes modifications in a private, but share-able, environment with no worry of overwriting changes or accidentally picking up changes from a legacy shared-database environment.

Any time a team member wants to make sure they are up to date with recent changes, they may merge changes from trunk into their feature branch. And when a team member would like feedback on their changes or is ready for a code review, they can push their feature branch to the central repository and create a Pull Request.

Pull Requests guide the flow of communication seamlessly in both remote and in-person formats. Automated policies ensure that required reviewers are involved and that required checks are met. Automation in Database DevOps may also be configured to quickly clone a production-like copy of the database and deploy the code from the feature branch to that environment for quality real-world review by team members, no matter where they are around the world.

This type of adaptive workflow is impossible with the legacy way of working with the database

In the legacy way of working, version control is not in place and changes are reviewed only in shared environments or using file shares with custom scripts. Teams working in this older format will suffer from a sudden drop in face-to-face contact, as it becomes difficult to understand what is going on. These teams will become more reliant upon emails and are much more likely to need to slow down their work significantly in order to avoid errors.

If your team hasn’t yet implemented Database DevOps, don’t panic!

The first steps to take are to evaluate your team’s situation and identify if your team’s workflow can be safely achieved with remote workers.

If it can’t and you’re forced to slow down your team’s work, take a step back and consider your options:

1. This slower period could be an opportunity to optimize how you provision or provide development databases.
2. This could be the push you need to take the first steps to getting your database code into source control.
3. Now might be the time to make some automation changes to improve the flow of work and better fit with remote workers.