Deploying software is hard. Even since I've worked in this industry, over 25 years now, I've seen the challenges faced by IT professionals when they try to update software. I used to think most of the issues were poorly built installation programs, but over time I've come to see that users pose just as much of a challenge as the technology. While it can be frustrating to debug hard coded paths, missing files or registry keys, and other issues with software upgrades, the demands and expectations of users can be just as bad.  In fact, the challenges of getting users to accept downtime and disruption from software may even be more stressful to IT professionals.

That's from the application perspective, which is the easy part. Get new bits installed to run, and if they have issues, copy the old ones back. Certainly that's not easy, and I know that the large software vendors that install platforms, like Windows, MacOS, iOS, Android, and more spend a lot of time trying to prevent users from being interrupted. Despite the hassles with software, the database continues to be a more challenging platform when it comes to upgrades.

One of the main challenges with a database upgade is data. Our users want it, we can't throw it away and start over, and the effort to preserve data means that upgrades are resource intensive and often slow. Some of these changes are due to the inherent design of a database system. If I change a large amount of data, that takes a physical amount of time, which can slow down, or prevent access to, a table. If I want to provide a forward and backward compatible system, I may end up with triggers and copies of data that are maintained in multiple places. This could make an deployment quicker, but at the expense of more resources needed for my workload every day.

There are also the compatibiliy issues with software. It does seem that many developers don't spend too much time thinking about the database, or they use a framework that becomes tightly coupled to a particular design. It becomes difficult to adapt to schema changes, and more importantly, it seems to be difficult to refactor the software later to remove links to the schema that we may want to drop. If multiple applications are involved, the entire process becomes exponentially more complex.

When I read about finding ways to smooth deployments, such as this piece, I realize the scope and breadth of skill that a DBA or developer needs to smoothly upgrade a database when we deploy new changes. I think the level of detail needed is part of the reason many of us approach database deployments with some trepidation, but I also think we tend to not always consider the various items mentioned in the artilcle for every deployment. We're human and we view some deployments as small and easy, and others are needing more care. However the truth is all deployments need careful planning.

I've been writing and speaking about this a bit, and Redgate has been working on building new tools to help everyone better engineer a deployment process for their SQL Servers. However it's a complex task and while we've made a lot of progress, there's more work to be done. I am looking forward to seeing where we go and how the process evolves for DBAs across the next decade.