Skip main navigation
Home / IT & Computer Science / Cloud Computing / Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline / Database as Code

Database as Code

.
View transcript
17
Don’t forget about the database. Very often, people think, application code, and say, oh, the database, well, we have separate database administration procedure for that. Not in DevOps. It’s not separate. In the old days, when we had separate database administration, we had this problem of configuration drift. People would make changes to the schema or the reference data in production, and those wouldn’t be reflected back in the development environment. In fact, the human error of modifying in production, but not capturing those changes back in development would lead to this progressive drift. That meant you had more verification steps, more elaborate manual processes. You had to increase the documentation around handling the database.
72.8
You had inconsistencies in the reference data, not just the schema. And as a result of all of these errors, real and anticipated, you had long times allowed for database updates. And people would assume a high error rate, a high failure, a high buffer needed. They’d work on weekends. The weekends would extend. And this would create, once again, a slower cadence. And people would be afraid of changes to the database. Well, in fact, the database needs to change as the application matures, and this just became another impediment to improvement. Let’s look at what happens in the DevOps world when you treat the database as code. With DevOps, the database is code. Its versioned the same way. Bugs are easily reproducible.
130.3
You have consistent configuration. You can tell if there’s drift in production. You can bring it back to development. You don’t think of the database as something special. You don’t think of it as something that is different, conceptually, than code. The increase in the deployment cadence means that you can make changes in small increments. You can change a table. You have just a few alter scripts instead of this huge rollup of schema changes that no human being can wade through. You can be consistent about reference data. You can treat the alter scripts for the database– the configuration scripts– as executable documentation because they’re small enough that people can understand them. And their schema changes can go forwards, of course, from development.
188.9
They can also go backwards from production because you have tools that will diff what’s in production to what’s happening in development. And you can see that they’re identical, or if not, what needs to be modified where. So it’s auditable. That’s the benefit of using database as code.

Infrastructure as Code (IaC) and configuration as code are not mutually exclusive processes. Instead, the two processes complement each other and can be used in tandem.

The term configuration as code is not used as widely, and in some cases, IaC is used to describe both provisioning and configuring machines. Infrastructure as Code can also be configuration as code but usually not vice versa.

If you do use the two processes separately, a simple principle to keep in mind is that Infrastructure of Code refers to creating and provisioning machines, whereas configuration as code refers to configuring components and software on the machines (such opening ports and installing software).

There are two types of approaches to Infrastructure as Code:

declarative (functional) and imperative (procedural). The declarative approach states what the final state should be. When run, the script or definition will initialise or configure the machine to have the finished state that was declared. In the imperative approach, the script states the how for the final state of the machine by executing through the steps in order to get to the finished state.

Want to keep
learning?

This content is taken from
CloudSwyft Global Systems, Inc. online course,

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

View Course

There are two configuration methods in IaC:

Push – in the push method, the controlling or master server will push the configuration to the target machines.

Pull – in the pull method, the machines configured will pull the configuration from a controlling server, such as a master server.

Some organisations may benefit from Infrastructure as Code frameworks such as Windows PowerShell Desired-State Configuration (DSC).

Want to keep learning?

This content is taken from CloudSwyft Global Systems, Inc. online course
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
View Course
See other articles from this course
This article is from the online course:

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free