DLM S1 – The manual stage
At Redgate Software, we’ve been trying to build tools that help developers work with software better. One of our areas of focus in the last few years has been streamlining database development and deployment. To help customers migrate to a smoother workflow and a better engineered software development pipeline, we’ve built our own maturity model around Database Lifecycle Management (DLM).
In this post, we’ll look at S1, the first stage of that model, which we call the Manual stage.
S1 – The Beginning
The maturity level at which many organizations work is the S1 stage, or completely manual level. This doesn’t imply they can’t build great software, but rather they do so in an ad hoc fashion. The processes are highly dependent on the knowledge of individuals, as well as sufficient time to craft the tools and scripts needed to build and deploy their database schemas.
In other words, chaos.
Chaos certainly can work, and has been the way many groups manage their technology systems. If you have methodical, smart, talented workers, they can easily keep track of their code. They deploy what’s needed. They test their code appropriately for the environment. They get work done and software deployed, with relatively few bugs or issues reported by clients.
That’s not how most of us work. As we hire more developers, we have different styles of working. We track and store scripts in different folders. We name files in our own unique way. We test some code, but not other code. We may deploy code with custom, bespoke scripts and processes tailored to a specific environment, or even a specific release. We could depend on a particular worker’s ability to complete a task, which often means that other workers have difficulty, or even cause downtime, when they deploy changes.
Utilities or software tools may be in use at this stage. For example, SQL Compare might be used to generate deployment scripts based on comparisons between a development and production database. However, the use of these tools is in an ad hoc fashion, with their configuration and execution untracked and dependent upon the user’s knowledge of how the tool works, as well as which settings may be appropriate for the particular application.
This stage is characterized by no version control other than a manual one, so nothing is enforced or tracked with tools. If developers don’t manage their scripts and code correctly, or check them into a VCS each time they make a change, work can be lost or misplaced. We are human and we make mistakes. Our Manual maturity level means that we accept and work around those mistakes.
Certainly in an organization we may have some applications or systems that are better engineered, with tighter process controls, responding. Those applications may rank higher on our maturity model. However, we all probably have some systems at the manual, S1 stage.
That’s fine. We just hope that you yearn to mature those systems over time, reducing the dependency on individuals.
The next stage beyond Manual is our S2, or Automated Version Control, stage. You can read more about that, and the other stages in Redgate’s Database Lifecycle Management maturity model, by dipping into my other posts:
An Overview of Database Lifecycle Management
Stage 1 – The Manual Stage
Stage 2 – Automated Version Control
Stage 3 – Continuous Integration