We're in the process of pulling together and trialling a proof of concept for a new approach, after finding nothing that suited.
The showstopper for us is typically the granularity associated with import/export and content staging. We use a mechanism similar to that found in version control systems such as SVN in that we have a central development DB (think dev branch) and a trunk DB that completed work is content staged to (think trunk).
This almost works really well.
Each time we are ready to release new work, we clear the content staging tasks in the trunk DB and content stage completed work from the dev DB to the trunk DB. This in turn creates new content staging tasks which essentially record the work related to the release.
After backing the trunk DB up, we are then able to content stage all tasks to a staging DB for testing. When testing completes, we restore the trunk DB so that the staging tasks sent to staging DB are restored, and we then content stage to our production DB.
Apart from the work involved (which is significant) the granularity of content staging tasks introduces issues for us.
For example, if we have developer A alter a query for a given document type, and developer B alter a transformation for the same document type, and at release we have developer A's work ready to go, but not developer B's we are a little bit screwed. Content staging presents only a document type ready to go, and not the individual pieces within it. If I stage the document type developer B's unfinished work goes along for the ride. If I do not, then developer A's work never gets there.
I bring this approach up though only for discussion, and to give others a strating point.
What we are actually looking at now is something similar to what is on offer for Drupal, or the mechanism used within TFS.
Basically we execute a script that generates individual code files for each DB asset (eg. document type query, transformation, page template). Each code file contains the SQL required to insert the asset, or to update it if it is found to be out of date.
Our initial load into source control involves simply running the script, generating the files, and committing these to source control. From this point on things work in the same way as the regular source control mechanisms developers are used to.
Developer A finishes a piece of work, pulls the latest from the source code repository, executes the script locally to overwrite locally, and uses the tools provided with the source control used to decide upon which files to commit.
For example, developer A changes a transformation and a query but is only ready to commit the transformation. Developer B changes another transformation. Developer A pulls the latest from the source code repository, executes the script locally to overwrite local files, attempts to commit changes to source control. and is prompted for all 3 changes. Developer A then chooses to commit only the transformation change that is ready for release.
That's it. The change is now under version control, allowing for rollback, auditing, difference chacking etc.
When a release is due, the release manager pulls the latest from the source control repository and executes the script against a staging DB. Upon successful testing of the changes against the staging DB, the same scripts are executed against the production DB.
I'd love to hear thoughts and comments on this approach, and this post is meant to be nothing more than a catalyst for discussion.
While I will post updates on progress, I'm hoping that other will also become involved.
Trackback URL:
http://www.kenticodeveloper.com/trackback/c154ab8c-a342-4ec2-91f6-10ee671551bd/Discussion---Kentico-Version-Control-for-Teams.aspx
Comments
Blog post currently doesn't have any comments.