SQL Code Deployment Best Practices

Problem
I am the only SQL Server DBA at my organization and I feel like I am constantly pushing out code. I have Developers send me emails, I get help desk tickets, I have to go out to file shares and VSS to check for code that needs to get pushed out. I have been at a point where I am not able to get my other work done which is becoming frustrating. The other issue that I have is that I am unable to track the changes over time. With 4 different places that I need to check for code, this has become a nightmare that I have to get in control and soon. How should I go about doing this?

Solution
With the numerous code deployments on a daily or weekly basis there is not doubt that you are having an issue getting other work done. Deploying code can become a full time job if you let it become one. You are probably also facing a significant amount of fire fighting because you do not have a process in place and everything is ad-hoc.

Although there is no single answer to resolve this issue, in this tip we will outline options that can be leveraged to help you resolve your code deployment issues. These options include:

• Schedule - First and foremost, you have to setup a schedule for the following items:
  • Code submittals
  • Code reviews
  • Code deployments
• Managerial Support - The next big area that you need to tackle is managerial support. Take some time to record the amount of time you spend on a daily or weekly basis deploying code and how you plan to change the amount of time for code deployments and the initiatives you can address with your fee time. The key here is to think about benefits from your perspective and how you can benefit the organization. Another key area is how your change is going to impact the remainder of the organization. Most likely you will be brining order to chaos, so keep that in mind and be prepared for push back.
• Communication - Have your management communicate the deployment plan to the development teams. You will probably get some push back when moving from an entirely ad-hoc schedule to a formalized schedule, but you need to stick to your schedule or negotiate a reasonable plan that works for the entire team. In a nutshell you do not want to stop progress, but do not want to constantly be facing chaos and firefighting.
• Technology - To streamline the process consider a third party tool to package and deploy the code. Some of these tools may be
• Just say "no" to the drive by requests - If your team has been accustomed to being able to send a request and have you as the DBA fulfill it, then any change to that process is going to cause some friction. Be aware that at times code does need to get pushed out if it is an emergency. Those needs should be identified, but you should have sign-off from management above the Development and DBA managers for this type of approval. If not, every request will become an emergency and the process you are trying to put in place will not get off the ground.
• Coding Needs - Most likely if you do not have a standardized code deployment process now then items like comments, deployment code, rollback code, etc are non-existent. Moving forward this is something you should need in order to have a smooth code deployment perspective.
  • Check out this coding comments example.
  • Depending on what is being deployed should dictate the deployment scripts or steps. If you can code it then it can be retained for historical purposes and reviewed if an issue arises in the future.
  • Rollback scripts should be the reciprocal of the code or data being deployed. Having these scripts could be the difference between having an extended downtime or just a blimp on the radar screen. Typically these scripts never see any action, but when they are needed, they are a life saver.
• Sign-Off - Depending on the formality in your organization dictates the level of formality with sign-off. At some organizations a verbal sign-off is all that is needed, in other organizations it is exchanging emails until you reach agreement and in the third category of organizations a formal written sign-off is necessary. See what makes sense and do not make this process so rigid that no one wants to participate.
• Process - When you build a schedule, obtain managerial support then communicate the schedule and follow it - what you are really doing is putting a process in place. Do not be afraid of it or resist it, just be aware that it is something you are trying to put into place to better manage your time and stop some of the chaos in your SQL Server environment.

Example Code Deployment Scenario

Below outlines a sample deployment schedule that could be considered a viable option in your SQL Server environment:

• Code Submission - Every week on Monday @ 12:00 PM all code and rollback scripts need to be submitted to the DBA
• Code Review - Monday afternoon the DBA reviews the code then tests it in a test environment and executes a best practices checklist on the submitted code
• Team Meeting - Tuesday @ 9:00 AM questionable code is discussed and determined if it is included in the deployment
  • If the DBA does not have any questions then this meeting can be cancelled, but the DBA should email the team to let them know the needs
• Deployment - Every Wednesday @ 6:00 AM have jobs that push out the code
• Review - Every Wednesday @ 6:00 AM the DBA reviews the output and verifies the code
• Rollback - Every Wednesday @ 6:00 AM the DBA determines if the code needs to be rolled back or not
• Report - Every Wednesday @ 6:00 AM the DBA reports the status of the code deployment
• History - Every Wednesday @ 6:00 AM the DBA records the changes that were successfully pushed out