January 9, 2014

Source Control Revisited

In a previous post, I wrote about how we are doing our source control at work. Still on svn, we are now trying to keep the database and associated documents of a project in one repo as well. This meant that we had to rethink the structure and the workflow of projects a bit.

The new structure is as follows:

  • Docs
  • Source
    • Dev
    • Prelive
    • Live
  • Sql
    • Dev
    • Prelive
    • Live
  • Publish

We have removed the previous folder names as it was causing some confusion with where what is.  We moved the future release to Dev, quick release to Prelive and last but not least, we moved trunk to Live. It kinda makes sense, thinking about it like this. There are 3 new folders in the repo, the “Docs” folder, this contains all the documentation, specification documents, designs and mockups, and the “Sql” folder, for all the database scripts associated with the project, and the “Publish” folder, which I will discuss later in the article.

Managing Sql…

As with the “Source” folder, the “Dev” folder in the “Sql” folder is for the development boxes, and “Prelive” for the prelive environments and the “Live” for the live “production” servers. This is so that the database administrators can double check our stored procedures and naming conventions when we design our databases for a particular application. All they have to do is check out the “Sql” folder and check the scripts. It also makes it easier for them (database admins) to apply all the required scripts to the correct server environment, be it prelive or live.

Publishing to an environment

With the “Publish” folder we have created a folder that will contain the files necessary for a specific environment. This makes the life of IT a bit easier as there is only 1 folder that needs to be checked out to every server, the responsibility of the correct files for the correct environment lies with the developer. We can also minify js, css and do other optimizations depending if it is needed or not, meaning that even though the source is not minified in the “Source” folder, it can be in the “Publish” folder.

One bad thing is having to re-do all the source repos, which in turn gives us chance again to check the current repos for the correct code.

Implementing processes to improve control over our source is always going to be a time consuming process, but that’s life.

Leave a Reply

Your email address will not be published. Required fields are marked *