Development and deployment workflow


Here, at Zitec, we deal with a variety of medium to large projects developed “agile” style. While “agile” is good for the customers, since they get things delivered faster, it also induces a high level of complexity when it comes to code deployment on the production/live machines or environment. The key point is to have the code in sync when multiple developers are working on the same code base, to deploy it simultaneously to all the machines on production environment, while maintaining *databases structure in sync (I mean to push structural changes to live database).

SVN GUISince we are using Subversion for the source control, we have developed a lightweight GUI (internally named SVN GUI) for the Subversion Linux based client. This small app is deployed on every development environment, including production, with the only purpose to facilitate the code release. This way the developer does not need to SSH on the production machine to do a release, he or she only needs to login to SVN GUI and choose the right release tag.


All projects are “routed” by default to our standard development infrastructure, which contains 3 distinct environments:

1) Development(DEV)

Given the fact that all new features and/or bugs are developed on separate branches, DEV is the place where they are actually tested by the developer itself and by the tester(s).

The tester is able to change a specific (development/bug fixing) branch from the SVN GUI branch selector.

SVN GUI branches selector

Since this is the first place where the code gets deployed, it is the less stable in the workflow.

The database data on DEV is usually a minimized replica of the data from the production and it is not used for performance and/or load testing. At this point only the functional part of the feature/bug is being checked.

2) Staging (STG)

This is the point where a branch is merged to trunk and is getting tested. As opposed to DEV, here we have a real data set copied from the PROD. At this point the customer is able, in fact is being asked, to view the changes and/or fixes that were developed for the current release before going on the PROD machine.

Only the code available on trunk can be tested on staging and SVN GUI is configured in such a way to allow us only update operations and no branch or tag switch.

Once the code, in fact the application, is declared stable, a tag is created which marks a version number in application life-cycle.

3) Production (PROD)

Finally, the PROD environment is the place where the code needs to be and where the end users are able to see the changes we did in one complete development cycle.

SVN GUI tags

The release consists only in a switch command that brings the code to the latest tag that was created above. This way we minimize the downtime and if something goes wrong, we can quickly revert to the previous stable tag.

*more about database synchronization and versioning in a separate post

Leave a Reply

Notify of
Inline Feedbacks
View all comments