All of our source code, including the code for front-end web development , database objects, and Infrastructure as Code files, resides in Git version control.
Whenever the code is committed to version control, the build is run. Here, the codebase is compiled, unit tests are run, and an artifact is created. This artifact is used by the release to deploy the software to an environment.
Sports Store is an MVC application. We are using Git, a decentralized version control system.
The above screenshot shows an example of the website codebase. We will use this example to fix a bug in the system.
It is challenging to store database objects in version control. Our goal is to treat the database as regular code. Stored procedures and views make this quite simple , although schemas are harder because existing data is involved.
We have two broad approaches we can take. The state-based approach is where we code the database schema as we wish it to be and store it in version control. The database tooling is used to generate a script that detects the differences between the new schema and the target database.
The migration-based approach keeps track of the changes made to the database as a set of metadata. The metadata is applied against the target database.
There are tradeoffs for each of these approaches. Sports Store uses the state-based method as implemented by SQL Server Data Tools (SSDT).
All changes to our target database are done via scripts, and there are pre- and postdeployment placeholders available to us. The predeployment placeholder is used for the data manipulation necessary because of schema changes. The postdeployment placeholder is used for reference data and to clean up deployment.
The above screenshot depicts the development experience for the product table. A “visual” editor as well as SQL “Create Table” code can be seen.
When an SSDT project is “compiled,” the complete schema is validated, and a DacPac is created. This DacPac is the artifact created by the build process, and it is then deployed to the target environment.
Next, we will discuss branches and code reviews.
For details on the topics covered in this article, please visit the links below. You may also download the source code for the DevOps Roadmap Lab on Git Hub. Contact me to set up a free meeting where we can dive deeply into the lab material and discuss your individual needs .