What should never go into source control is transactional data accrued during the normal function of the application. Here’s a contentious issue for you versioning of data. The importance of this distinction is about to become clear but for now, let’s just work on the assumption that everything you see in the image above is happily tucked away in VCS via SQL Source Control. In theory, the “Customer” and “Order” tables would accumulate transactional data and the “Country” table would contain a static set of reference data. But there are two features the current version has which make it perfect for our purposes here unattended command line execution and syncing from a VCS source, the latter of which necessitates the Professional version.įor the purpose of this post, I’m going to run the process against a data model which looks like this: I’ve long been a user of this on the desktop as a means of automating releases and ensuring environments were absolutely identical. This is where SQL Compare comes into play. The main thing is that VCS is our source of truth and we need to ensure the target environment is changed to match this exactly. Depending on the changes, we could be dropping objects, altering permissions, changing data lengths or potentially any other conceivable database change. When it comes to publishing the above, we need a mechanism which can pull them from source control then script and execute the required changes against the target environment. Because SQL Source Control neatly files each object type away into its own folder, all we need to do is take a quick look in the Subversion repository for the project and we’ll see just what sort of stuff is going to go in there: This includes any database objects such as stored procedures, views, triggers and of course, tables. Working on the understanding that anything we want to release with this process should come from source control, the obvious database elements which need to go into VCS are pretty much everything in the schema. It’s where application life begins and it’s where TeamCity is going to turn to when it publishes both the web application and the database. Sometimes we’ll address the latter by using a shared development databases but, well, go back and read the article above for everything that’s wrong with that.īut most importantly in the context of this post, VCS is the “source of truth” for automated deployments from a continuous integration environment. Of course we also lose all the productivity advantages of not only being able to rollback when required, but being able to integrate with the work of our peers. ![]() We lose the ability to say “Here – this is the state of code over time”, as only part of the picture exists. Without the DB in source control we end up with a fragmented, partially complete picture of what an application is. As I wrote a couple of days back in The unnecessary evil of shared database development, “Database source control is no longer negotiable”.ĭatabases are an essential component of many of the applications we build and to deny them the value of VCS is just crazy talk. Get your database under source controlįirst and foremost, none of this is going to make any sense whatsoever unless you get your database under source control. Let’s take these tools – plus a few more from the Red Gate product suite – and finally make one-click database deployment a true first class citizen with its application peer. ![]() Last year I wrote about Red Gate’s SQL Source Control as a very excellent way of versioning databases and followed up later in the year about automating deployments with TeamCity. ![]() Some special tooling is in order and fortunately the planets are starting to align in such a fashion that some of my favourite products work very nicely together to serve just the purpose we’re after. ![]() You’ve got to consider the very nature of databases being that you’ve got real live data to deal with and the ramifications of screwing up a deployment are pretty severe. Of course the problem is that database objects don’t exist as simple files that can be versioned, nor can you just pick them up and place them in a target location when you want to deploy them. Continuous integration is another practice which although not as common, is still frequently present in a robust application lifecycle. Source control management, for example, is near ubiquitous for application files and there are several excellent VCS products which make versioning a breeze. Databases have long been the poor cousin of the application tier when it comes to many of the processes we take for granted in the.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |