How best to handle Git Deployment For multiple web servers
Our current deployment process is to run an in house script that checks out the most recent svn revision into a newly created directory to create a working copy on the server. It then runs any sql commands that need to occur and changes a symlink from the curent working copy to the newly checked out working copy.
This is a simple way of handling updates and allows us to easily roll back the code base to the old one by changing the symlink if there is an issue.
Is it possible to fetch just a single specified branch from a git server into a newly created directory or do I need to clone the entire contents of the repository?
Or is there is a better method of handling the code base with git?
3 Solutions collect form web for “How best to handle Git Deployment For multiple web servers”
Each commit in the git is identified by “sha1” id. This id represents exact snapshot of files. So, instead of creating multiple working copies and symlinking them, you could just do
git checkout of a particular commit. To rollback you just do checkout of the last known good commit id. Since checkout works very fast (in comparison to the SVN) and doesn’t rely on a network repo (so it never fails), I recommend you to forget the symlinking nightmare.
To make more human friendly IDs you could utilize tags (essentially a human readable alias of a commit id).
Git is a distributed repository. You need to clone the entire repository when doing a git clone, you cannot just just clone a branch nor a sha id. However, git is compressed quite well and you should not have problems with your strategy because of git.
We do this at my work and have been using this methodology for over 5 years now – it does not slow us down, we have a Continuous Delivery system that allows us to deploy to production many times in a day, and our deploys are about 3 minutes long – depending on database migrations.
Sorry that the answer is – you must clone the entire repository.
We have the following scheme:
- We use gitolite for access control to our networked repository, and have our build server use a special SSH key that only has read access to the repository.
- We have a full clone on our build machine, and periodically do a fetch from our build scripts.
- We use tag names to mark things that are to be built. We use 2012-09-01[a-z] as the pattern for these names, as they sort nicely. E.g. 2012-09-01 is followed by 2012-09-01a if you need more than one build per day…could also use a full timestamp.
- When the automated shell script sees the tags to change (last tag is the latest), is does a checkout/rebuild.
Symlinks are not needed, as checkout in git is super fast. You can also use
git -xfd clean
to make sure your source tree is sparkling clean in case your script leaves cruft around.
Your development team then need only make a tag and push it to get an updated build:
git tag 2012-09-01 git push
and of course tags can use nested names, so you can do things like:
git tag test/2012-09-01 git tag release/2012-09-01 ...
to categorize the thing you are doing: testing fixes, working up to a release, etc.