Very simple git-based deployment for fabric.
Git pulling from a remote repository requires that you open your repository to the world and it means your deployment process relies on one more moving piece. Since git is distributed you can push from your local repository and rely on one fewer external resource and limit access to your private repositories to your internal network but still get lightning fast git deployments.
pip install gitric
- Uses git push instead of git pull.
- Pre-seeds your target's immutable git object store so you can stop and restart your server before and after the working copy is modified instead of waiting for network IO and the working copy to update.
- Won't let you deploy from a dirty working copy (can be overridden for testing).
- Won't let you lose history (can be overridden for rollbacks).
cd example virtualenv .env --no-site-packages source .env/bin/activate pip install -r requirements.txt fab -l Available commands: allow_dirty allow pushing even when the working copy is dirty deploy an example deploy action force_push allow pushing even when history will be lost prod an example production deployment
After creating a test-deploy user on my server:
fab prod deploy ... [yourserverhere] out: HEAD is now at b2db04e Initial commit Done. Disconnecting from yourserverhere... done.
You can't deploy when your working copy is dirty:
touch dirty_working_copy fab prod deploy ... Fatal error: Working copy is dirty. This check can be overridden by importing gitric.api.allow_dirty and adding allow_dirty to your call. Aborting.
And it (well git) won't let you deploy when you would lose history unless overridden with a force_push:
# simulate a divergent history echo "#hello" >> requirements.txt git add requirements.txt git commit --amend fab prod deploy .... Fatal error: 11485c970d21ea2003c0be3be820905220d34631 is a non-fast-forward push. The seed will abort so you don't lose information. If you are doing this intentionally import gitric.api.force_push and add it to your call.