On a plane, back to the UK, so republishing Selling Automation to Ops
Tag: DevOps
-
Modeling and Design Are More Important in DevOps
I’ve run across a few customers that are adopting DevOps processes for the database. This makes sense as I deal with Redgate Customers, many of whom are doing this. As they adopt a Compliant Database DevOps process, it seems often that there is a push for database developers to react to feature requests quickly, at the same rate that the application developers do, and push out new code regularly to support changes. This new code often includes schema changes to support new features and functions, which often means table changes because the data elements need to be stored somewhere. This, of course, means the data model changes.
In many cases, trying to release a new feature today or tomorrow, or even next week, means making quick decisions. As an example, if we capture lots of cost and price information in an application and are enhancing this to add currency values, we’ll be adding fields to any table that stores financial data. How we do this could vary. It’s easy to add a currency lookup field to all tables, and that might be what many application developers want to do. If they’re using an ORM, they might just add this as a property to their object definition, which generate a series of ALTER TABLE statements to add the related fields. Certainly, a database developer could just generate those same scripts.
Whether this is the best choice, or if some more normalized structures are needed, is unclear. That’s dependent on the problem domain, and if date stamps are needed to capture currency differentials at times, or even if we need additional FKs to ensure there is referential integrity, many junior developers and DBAs might not think about the implications to the data model. As time passes, this could mean additional technical debt to deal with, limiting future enhancements. This could also mean fundamental flaws in how financial data is calculated, potentially opening impacting revenue if the data model doesn’t support accurate calculations.
Moving to DevOps doesn’t necessarily mean moving fast. It can, but it’s really about making focused, small changes at the rate that matters for your business. It also means that your data model and design of data store structures becomes more important than ever. While we can make decisions quickly, this takes experience and understanding of the business impacts, as well as the potential downfalls from different types of structures. DevOps asks us to give feedback about potential problems up and down the software development pipeline, which should include a data architect of data modeler. Someone with experience here can help to consider future implications and even provide some flexible designs that can adapt in situations where we have incomplete knowledge.
Since we build our software on the data, we need to ensure we are properly capture the data in a way doesn’t create too much technical debt. There are many, many stories of organizations that struggle to grow their applications over time, often because of very poor data models. Many of these issues could have been avoided by consulting with senior developers, DBAs, and data architects/modelers for an hour before making a fundamental change. Even if this means keeping a consultant on retainer. The investment in reviewing and understanding the data model can pay off tremendously in the future, especially as the cost of data processing is often one of the larger costs of running an application. Whether this is an RDBMS like SQL Server or an alternative structure like CosmosDB. A little investment in modeling early can prevent the need to over-provision resources later.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
The Single Pane of Glass
One of the things that I’ve seen talked about quite in the DevOps movement is a single pane of glass. That phrase seems to be in use to describe a way of quickly understanding the state of your environment. It could be the view of the software versions deployed in environments throughout the development process or the status and capabilities of your infrastructure. In either case, it’s a holistic view of your portion of the organization.
I don’t think this is much different from the idea of a global dashboard that might be produced for business people. I’ve seen no shortage of those during my career. Certainly lots of business intelligence projects have been based on the idea of a single view of data that provides insight and assists decision making. Those ideas have been adopted by plenty of organizations that are moving to a DevOps process for software development.
I’m wondering if any of you have a dashboard for your particular job? This could be in infrastructure as a DBA, where you have a single view of your database servers, maybe status and alerts? Perhaps you just a monitoring system like SQL Monitor to keep track of important data related to all the instances under your responsibility. Perhaps you have custom information important for your organization such as the flow of data in ETL processes, numbers of transactions, or some other measures to measure health or performance.
Maybe you’re a developer that wants to know the status of all builds for the various projects under active development. As teams look to produce more reliable software, they often want to know the where their changes are deployed, if the code passes all tests, and even which work items are in which states. Azure Boards or DLM Dashboard are examples of how teams keep track of their responsibilities.
There are any number of ways that organizations can keep an eye on the state of their systems, but I do think that any high performing group will have some way of measuring their work. After all, if you don’t know the state of your system, how can you determine if you’re getting better or worse.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
Start the DevOps Journey
More and more, I find that getting someone’s mindset to change is the major impediment to changing to a DevOps process. Once a person starts to believe in DevOps and accept a new way of working, they can rapidly start to improve the efficiency of their work. Moving on to change the mindset of a team (or teams) is even harder, but this is arguably the most important part of changing your software development process.
I don’t have a great way of changing everyone’s mindset, but if you want to start, I have a thought for you that might add a little work, but will help you understand how to make changes in the way you work and experiment with a better way to deploy database changes.
The tools are the easy part, and I want to help you get comfortable because the harder part is then trusting your process and helping others to learn how to trust a DevOps flow as well. To get you to start that journey, you need to learn one skill: how to execute your changes from the command line.
That’s it. Think about how you will manually execute your tasks now, and then ensure there are command line execution processes for these. This could be a call to SQLCMD with a filename as a parameter or it could be a DACPAC deployment with sqlpackage.exe. If you are a Redgate customer, we have PoSh cmdlets for deploying changes with SQL Change Automation or command line SQL Compare calls.
A command line interface (CLI) is really the key for the DevOps toolset to succeed. That’s only a small part of the process, since you need cultural change, you need to still model your database well and write good code, and you still need to learn how to improve your code over time. Adding a DevOps process allows you to spend time on code quality, testing, and skill improvement, instead of assembling changes and files for that next deployment.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and Libsyn.
