By: Terri Hurley | Updated: 2024-06-10 | Comments | Related: More > Database Administration
Problem
Shifting production responsibilities between DBAs and Developers can sometimes cause stress between the two groups. This article has tips on how to make that transition easier for both groups.
Solution
In this article, we will demonstrate how to effectively communicate with Developers and others to discuss implementing production changes as a team effort.
It is mostly true when someone says only DBAs can implement production changes. But I'd like to say that it's also a team effort. After all, Developers write and test the SQL code since they understand the data. The final step is to push that code into production, where DBAs come into the scene.
So, without that code, there is nothing for DBAs to do. Hence, teamwork.
I've worked at large companies where there is a hard line between what Developers and DBAs are allowed to do or not do. But I've also worked for a few smaller companies where that line was not as clear.
If your organization is somewhere in between, you are possibly at the start of something great where you can have a positive influence. For me, it's a great feeling to be part of something that will help your company meet industry standards.
With all that said, the key to success is communicating with the Developers and the other important groups within IT. Getting management's input and full support is a first step to a successful transition. You need to define the exact changes expected and how the DBAs and Developers are to communicate.
Most importantly, you need to realize that this "separation of duties" process is more about teamwork than "separating" work between teams. Think about it: When Developers begin work on a new task that includes the DBAs, you should be more involved in meetings, reviewing SQL code for performance tuning, code approval, asking questions about data updates, etc. As a team, you will communicate more frequently and effectively.
The following is a suggested guideline in preparation to cut over to 'shared' responsibilities.
Communication with Key Personnel
IT Managers
Begin by meeting with IT managers to discuss the transition process and verify support before, during, and after the transition. This is the most important task to start. If you encounter any pushback from anyone during this process, they can be directed to talk to management. Not everyone may be happy with the changes coming down the line.
You also need to clarify the Developer's role after transitioning. Some larger companies prohibit changes made by Developers of any kind in a production environment. Some others allow Developers to make some data changes but not schema changes. It's not a one-size-fits-all answer, but the changes need to fit the company's size and requirements. This could be determined by how many Developers or DBAs are employed. For example, a company with one DBA needs to allow the right to make data changes to several Developers. However, a large DBA team could handle all changes intended for production.
Project Managers
When talking to Project Managers, let them know what you need from them regarding new projects. For example, I prefer to use a spreadsheet to document the entire change implementation. This records the order of steps to be taken, who will take care of that line item, how long it's estimated to take, and, most importantly, the expected roll back plan (i.e., restore, SQL scripts) in case of an emergency.
I have also requested that our team be included in kick-off meetings requiring SQL databases. We may not attend every meeting, but we will have advanced knowledge of a new project that is in the works and will be able to raise questions or concerns early in the process.
Change Management
I personally prefer that Developers attach a SQL script to the change ticket. This gives us an opportunity to save the file and search the document for keywords such as SELECT, HINTS, etc., quickly review the code, and approve or deny a request.
Developers
As for coding standards, I recently had a meeting with Developers to review coding best practices. I provided a document that outlined what types of changes are encouraged and ones considered showstoppers. I encourage you to create and share this type of information with your Developers.
If they don't know what improves performance, then their code will never evolve. Once they know how to improve performance, future tickets with SQL code will become more efficient. Remember, it's easier to fix the code before it moves into production than to work on performance issues after installing bad code.
Lastly, I have also asked that DBAs be included in meetings when Developers discuss new technologies that will use SQL databases in order for the entire team to be part of the decision-making process.
Preparation and communication are key to a successful transition.
Next Steps
- Check out this MSSQLTips webinar: DBA Code Reviews Done Dirt Cheap. This is an excellent webinar that goes over specific best coding practices you can share with developers.
- Once separation of duties is in place, review existing SQL Server permissions. Developers and users should utilize the principle of least privilege.
About the author
Terri Hurley is a Sr. SQL DBA with over 20 years of extensive database administration experience.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
Article Last Updated: 2024-06-10
