Git – How to Maintain Different Variations for Deployment Using Git

deploymentgitversion control

Although there are many similar questions here regarding using GIT for maintaining different versions, none seem to answer my specific case.

I'm OK with how to use GIT to do my development, using different branches to do hot fixes, versioning etc.

However, I am making a commercial application that needs to track various modules and configurations for DIFFERENT clients. And I do NOT wish the client to have access to a module or code they haven't paid for. Yet I would like to use GIT to deploy on their server, or to be able to deploy directly on the client server using ssh/rsync, or even on my server in a unique directory, then zip up the source files using a standard process.

Let me give you an example:

Client A:

Deploy basic application
Deploy Module A (e.g. forum) only
Deploy Client A specific theme with Client A specific logo

Client B:

Deploy basic application
Deploy Module A (e.g. forum)
Deploy Module B (e.g. faq system)
Deploy Client B specific theme with Client B specific logo

Development Server:

Contains basic application
Contains Module A (e.g. forum)
Contains Module B (e.g. faq system)
Contains Client A and Client B themes with all logos
Contains Development Notes which must NOT be visible to client
Contains build files used with Phing – these must NOT be available to clients

It's very important to understand that GIT on the development server contains proprietary data for Client A and Client B. Therefore Client A must never see my development notes, my Phing build files, Module B (faq system) or code/data/images for Client B.

I do not need to keep variations of a module or the basic application for individual clients. Everything is standard across the system, and it's only the deployment configuration/variation for each client which is unique.

I am happy to use GIT Submodules to keep some parts separate, if that helps.

Note that all my code is in PHP and I am happy to deploy solutions using PHP, Perl, Python or scripting, but I don't want to use Java on the destination server. Ideally I would like to avoid Ruby solutions, if possible. I have access to SSH on the client server and can use rsync over SSH as well, but I need to be able to execute a script on the client server to clean caches etc after an update.

My development machine is Windows – yes, unfortunate, but true. If I cannot achieve what I need on Windows then I will run CentOS/Fedora in VMWare.

This is not a multi-server deployment requiring simultaneous updating across a server farm, although it would be nice to be able push out updates of the application to all the various clients on a schedule or using a single command/procedure rather than having to do it manually for each one. I would also need to be able to push client specific updates to individual clients as and when required (for instance HTML or logo updates).

So, can I use GIT for deployment, or at least track the various configurations using branches? Or is it simply going to be too messy?

Can I hide Client B from Client A, including in commit history, in a particular branch, to make sure someone proficient with GIT at the client's organization cannot retrieve code they mustn't see (and this is a contractual requirement of the project)? If so, how do I do this in GIT?

If not, how can I best manage a build process that allows me to deploy client specific configurations? Note that initially I will be managing around 20 different clients, and this might grow to 100 or more different configurations as each one will include their own HTML and logos, and a variation based on a potentially unique selection of 15-20 modules.

I am happy to maintain a hundred different XML configuration files if that's what it takes. I am aware of Capistrano, but from reading about it, it doesn't seem that suitable for my specific case. If you feel otherwise, please do feel free to state so.

Best Answer

This is not a Git-specific answer, but it should work regardless of the VCS system you use.

I would start with several different repositories

One for each client, containing the client-specific files and a configuration file stating which options the client has purchased
One or more repositories with the development code

Then I would use a make_release script (written in your favourite scripting language) that does the following:

Given the name of the client, checkout that client's repository to a temporary location
Based on the purchased options, checkout or copy (from an existing checkout) the application and modules to the same location
Remove all files/directories that are not relevant for the client (especially those that contain data meant for the VCS system)
Package the release in a convenient format (e.g. zip or tar.gz)

Then deployment should be as simple as copying the release to the client's server, unpacking it and running whatever scripts that are needed to finish the installation/upgrade.

Related Solutions

Web Development – How Safe is Using Git for Deployment on Production Server?

That depends on your exact way of doing it. Right now it seems to me you have a git repo in your httpdocs that you deploy to, basically using HEAD as your actual website - that is NOT the correct way. I'm not sure how you are able to push to this configuration at all?

What you want to do is use a bare repo somewhere outside the httpdocs-folder, and checkout the files to httpdocs after pushing. While this sounds complicated, its pretty easy to do, here is a step-by-step tutorial: http://caiustheory.com/automatically-deploying-website-from-remote-git-repository

If your webserver needs access to some files, such as a wordpress installation, you need to add chmod and chgrp commands to the post-receive hook, otherwise your files belong to the wrong user (the one you used to push the commit, not the webserver).

Simply make a new script to change ownership that you call from the post_receive hook via sudo scriptname.sh (name it change_own.sh or whatever) :

chown -R wwwrun /path/to/httpdocs
chgrp -R www /path/to/httpdocs

and allow the script to be run without password via visudo by adding gituser ALL=(ALL) NOPASSWD: /path/to/change_owner.sh at the end.

Assumptions made: wwwrun - webserver user; www - webserver group; gituser - user to push commits

Addendum: A friend used this method and complained about how he had to update Wordpress over and over again. The obvious reason is that if the Webapplication updates itself, und thus replaces its code, these changes will not be transferred back into the repository, because the hook only works one way. Thus after each commit, the hook overrode all changes the Wordpress-Installation made through updates. The imho quickest workaround is to run the updates on the developer machine, then commit to deploy.

C# – Manage ClickOnce releases for different parties

What you want is possible, but not quite in the way you mention.

A published ClickOnce package is controlled by two manifest files - the application manifest called [product name].application housed in the root folder of the published deployment, and the version manifest called [application name].exe.manifest, which of course resides in the codebase folders for the specific versions.

To to cut a long story short, you can publish as many versions as you like - in fact that is the easy bit - but you will then need a copy of the application manifest for each 'party' that you have. You can then update them independently by updating their application manifest, once you have done that any client machine will auto update - this is part of the functionality of ClickOnce (the installed ClickOnce application checks the application manifest for updates every time you run it (or at the period you specify as part of the publish)).

All you need to do is control which application manifest any particular party originally installs from, you can do this simply by checking their credentials then redirecting them to the appropriate application manifest (which will then launch the install prompt). You don't need to be messing round with Mage to achieve this - you can accomplish this using the publish functionality built into Visual Studio - you can publish to a neutral location then copy the generated neutral application manifest over top of the appropriate party specific application manifests.

Note that party specific application manifests are necessary because ClickOnce is an installation framework, it knows nothing about authentication and authorisation, so you have to take care of that bit. Technically you could house the application manifest files all in the same folder if you name them individually - but this does require a knowledge of Mage and isn't a simple task. Additionally you could automate some of this with Release Management and one or two custom tasks.

Best Answer

Related Solutions

Web Development – How Safe is Using Git for Deployment on Production Server?

C# – Manage ClickOnce releases for different parties

Related Topic