3 Reasons Application Developers Should Care About Database Deployments
In many organizations, database deployments are managed by a team external to the application development team. Since the database and application must be released as a unit, this two-path approach to deployments is difficult to manage. Unfortunately, most developers view this as a problem cloaked by Douglas Adam’s “Somebody Else’s Problem” invisibility field. However, application deployments are very much EVERYBODY’S problem.
1. You are not done until the application is in production
Just like you don’t win a basketball game by completing a single quarter, you are not done with your development efforts until the application is in production and benefiting the customer. If that application is not in the hands of the customers, they are seeing no benefit from your development efforts. Thus, there really was no point in your making those code changes in the first place. Moreover, application development requires feedback from the customer to improve. That feedback is impossible to receive until the customer has the application to use.
By relying on a slow, manual, error-prone process to update the database, your database deployments are slowed, no matter how much you automate the application (compiled bits) deployment. You must automate the entire Application (upper case “A”), not just the application (lower case “a”).
2. “Out of band” changes and Interrupts are preventing you from performing better
Developers are impatient. After all, we get very angry when the computer is being lazy and not anticipating our needs. That’s a good thing as it forces us to make the computer anticipate those needs “or at least pretend to” as Larry Wall tells us.
As Development moves forward to the next sprint, requiring them to move back to a previous sprint to fix a problem in the database update is excruciatingly painful. We not only slow the progress of the current sprint, in addition we have to mentally switch tasks to go back and resolve the database deployment issue found by a Production DBA. Of course, this difficulty could have been avoided had we known sooner that our database change was not sufficient. After all, we have this our code in the form of unit tests. Until we have the same for database code, we are going to have to deal with “out of band” changes and interrupts. Ugh.
3. You are going to have to look for a new job
Companies that adopt DevOps have a higher market capitalization growth rate (total stock outstanding X stock price) than their competitors. DevOps adopters also out perform the S&P 500. Both are what your C-Suite is attempting to do on their own. But, with DevOps, we’ve shown that high performing IT organizations allow for more agility in attacking new markets or expanding rapidly in existing markets.
If your company does not adopt DevOps, you will be looking for a new job because your company will eventually fail. (“Hi, Sears!”) Though development may look at database deployments as somebody else’s problem or a mere annoyance, the truth is that it directly affects a developer’s paycheck as jobs are now at risk due to competitive threats from another company that is more agile from an IT perspective.
There is a solution and you have already put it in place for your application deployments. You may have automated deployments using Jenkins or some Application Release Automation. To complete the task, you must have your database changes follow the same path as your application changes. That means using the same source code repository for both, providing lights out deployment single click deployments for all environments, and demanding immediate feedback to proposed database changes just like you have for your code.
“The future is already here — it’s just not very evenly distributed.” Because you have already applied these patterns to your application code, it’s time to bring the database deployment into the future the same way.