|
| Featured Contents |
| Question of the Day |
| The Voice of the DBA |
You Need a DBA Pipeline I work regularly with a number of customers on improving their database change processes. This has been the goal of Redgate's Database Change Management over the years, helping database systems work more like application software with DevOps principles. The idea is to move quicker and respond better to demands, while providing safety and governance. A database is a stateful machine, which is a challenge to evolve and maintain, but with good data modeling, testing, code analysis, and automation, your database change process can coexist with your application software. That being said, most of the solutions for managing database change focus on the database itself and everything inside it. After all, that's where the data is. I understand people wanting to solve that problem, but there are plenty of things that need to be managed for a database server (or an instance for MSSQL) outside of the database. We have security, configuration, and, in the case of SQL Server, jobs. That might be the number one request is a way to manage jobs across systems. Regardless of any tooling you might use, the important thing that you need is a way to easily manage and deploy the scripts you generate. These might be adding users or logins, perhaps rotating certificates, or something else. Clicking through SSMS or manually running things might seem like it's quick, but that's a governed way to manage tasks. You might update a Jira ticket when you're done, but do you always capture the code you ran in the ticket? The results? For many tasks, this might not seem like it matters. If we make a mistake, we correct it, and no one needs to know. However, this doesn't help you work more efficiently, nor does it help your team work closer together. If there are records of the code and results in a pipeline, then you have a trail of who, what, when, and how. The ticket should tell you why. This helps hold you accountable. It ensures you test more carefully. It gives teammates a place to go grab a script that worked and re-run it, perhaps changing the name of something in the script; this allows the reuse of work. This ensures that the work is routine. Many of us have made a career out of doing work manually, and we've gotten good at it. However, the future will require us to work in a team, one that may include an AI, and learning to build patterns of work that flow easily across humans and agents will be a skill that lets us both be productive and provide value to our employers. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
| Featured Contents |
