Three ways manual processes put your development lifecycle at risk

During my two decades in IT, I’ve seen the demand for Agile and its associated methodologies grow while at the same time, I’ve witnessed the database being left behind. We recently conducted a survey, 'Database Deployment & Development Risks', to gain insights into the risks associated with various database development practices. The survey focused on manual processes used throughout the development lifecycle. The results revealed two divergent realities. Despite participants from diverse sectors overwhelmingly recognising the risks associated with manual process for the database, many organisations continue to use processes and solutions which do not fully automate the development cycle.

Can you trust your source control?

One area where this was particularly apparent was with the source control. It’s imperative that development teams are able to trust their source control. But even when standard source control solutions are being utilised, 70 per cent of those surveyed are still interjecting manual processes. What that means is that even though many of these professionals have some type of solution, they still see a clear and present risk because:

1. When integrating changes, it’s possible for one developer to wrongly override valid changes with older revisions from other development branches, a potential concern that nearly 90 per cent of survey respondents associate with risk. Still, more than half (53 per cent) of the IT professionals surveyed integrate changes, creating the possibility that such overrides may occur. Nearly three quarters (70 per cent) reported having a database source control, but 53 per cent reported that they continue to have problems that a more adequate source control solution should resolve. In this case, there is a problem with the source control tool implemented.

2. The database may not be in sync with the version control repository. 90 per cent of the IT professionals surveyed associated the potential for these sources to be out of sync with risk. What’s more, 72 per cent of those surveyed admit that their database may not be in full sync with the version control repository.

3. Introducing changes without first verifying that each database object vs. its version control revision to ensure that it’s up-to-date is a process that nearly 90 per cent of survey participants associate with risk. Despite a widespread awareness that failing to verify accuracy between database objects and database source control before introducing changes is a risky practice, 53 per cent continue to do so. That means that the remaining 47 per cent of respondents do not trust their source control solution regarding the database code and are implementing steps to validate that it matches the database before introducing changes.

While interjecting manual steps can help to alleviate the risk associated with the possibility of overriding critical changes in the database, its time-consuming and manual interruptions to the continuous delivery cycle introduce risks of their own. When you can’t place full trust in source control, two developers working on the same database code or objects can easily override or revert critical changes introduced by the other developer when the script is updated in the database – sometimes with disastrous consequences. Database developers must seek out a path to database automation they can trust, or risk the database becoming a liability to the entire development process.

Yaniv Yehuda is the Co-Founder and CTO of DBmaestro

Image Credit: Shutterstock/Chones