Git-deliver intends to be a simple and secure way to:
- deliver software onto servers
- know what version of your software is on which server, when and by whom it was delivered, and whether (and how) it was altered since delivery
- write and reuse delivery "recipes"
- Git for version control, data transfer and integrity assurance
- SSH for authentication and remote command execution.
- Bash for custom delivery scripting
Compared to a regular Git push/checkout, Git-deliver :
- makes the delivery atomic
- structures the delivery process in stages and handles errors while maintaining availability
- archives delivered versions and automates rollback
- logs everything
- provides an easy way of knowing what is delivered where, checking integrity and knowing when and by whom a version was delivered.
- intends to provide pre-baked delivery recipes for common development environments
I have a working prototype on Github, with more information and documentation : https://github.com/arnoo/git-deliver/
By funding this Indiegogo project, you'd be funding the transformation of my prototype into a robust and well documented piece of software.
What would it look like ?
git deliver --list-presets
Let's assume you have a Rails project. After installing git-deliver, you run
and notice that a "rails" preset is listed.
You cd to the root of your Git working copy and you type
This will create a .deliver directory (which you would add to your Git index). In this directory are "stage scripts" : they are bash scripts that will perform the Rails-specific parts (database migration, etc.) at the various standardized "stages" in a Git-deliver delivery (or rollback). You can customize these stage scripts at will. After customization, you might even want to turn them into your own preset so that you can rungit deliver --init my_preset
for your next projects.
If your project is simple enough that a delivery is just about copying files, you don't even need to use stage scripts or a preset.
Once Git-deliver is initialized, assuming each of the servers you want to deliver to contains a bare Git repo that is setup in Git as an ssh remote, you can use
to deliver your project as of <ref> (a commit sha1, branch name, or tag) to <remote>
After your first delivery, <remote> will contain all the usual for a bare Git repo, plus a 'delivered' directory, in which you will find :
- One non-bare Git repo for each delivery. These Git repos share their metadata with the main repo to avoid excessive disk space usage. A delivery commit is made automatically to preserve the state of the project on delivery after your scripts have run. For extra sagety, this commit can be signed.
- A symlink, named "current", which points to the currently delivered version. This not only gives you a constant path to point to the current version of the project, but also makes the switch to a new version "atomic".
Should anything fail, either in the standard delivery process or your custom scripts (which signal it via their exit status), Git-deliver will properly cancel the delivery, getting you back to the previous version, however advanced the delivery stage.
git deliver --status
tells you which version is delivered on which remote, when and by whom it was delivered, and whether it was altered since delivery.
git deliver --status <remote>
gives you all the versions still available on <remote>. You can rollback to one of these versions usinggit deliver --rollback <remote><version>
git deliver --gc <remote>
cleans up on <remote>, removing all but the last three deliveries.
git deliver --init-remote <remote-name> <remote-url>
can be used to automatically create the bare git repo, add the remote to your local Git as <remote-name>, and if applicable run your "init-remote" stage scripts to initialize the remote (install dependencies for instance).
Although the prototype is mostly usable, it still has rough edges, and a few bugs. It's also missing a few important features. You can see the list of open Github issues (https://github.com/arnoo/git-deliver/issues?sta...) for details.
Here's what I want to do :
- do a thorough code review and make the code cleaner and more maintainable
- reorganise the test suite, make existing tests more pertinent, and add a lot more tests
- fix as many important GitHub issues (https://github.com/arnoo/git-deliver/issues?sta...) as possible : both existing issues (known bugs and missing important features) and new issues I'm sure you'll submit
- Improve the documentation, including a basic website
- Hopefully deal with pull-requests for presets as people start using Git-deliver
All funds collected will be used towards work on the project. The more funds there are, the more features, documentation, presets, etc. I can ship.
I've been a professional software developer for 7 years, and a passionate amateur one for about 18. My personal and professional projects have been pretty varied : I've been a system and network administrator for a few months, worked as a developer on projects using C#, Java, PHP, Perl, Common-Lisp... and done quite a lot of consulting and teaching.
I've used Git extensively for more than 5 years. I successfully organised transitions from other version control systems and taught Git to a good number of people.
In my free time, I paddle my canoe, study and teach Krav-Maga, play the violin and code, mainly in Lisp.
As all passionate developers, I have too many projects and too little time. I really believe in this project, which is why I'd like to be able to spend more time on it and really bring it to fruition. I hope you'll feel the same after reading this.
I plan to continue working on the project in my free time. In addition to week-ends and mornings/evenings, I have secured one free day a week from my employer for the coming weeks. I intend to put in about a day a week total, a bit more at times.
Other ways to support the project
Another way to support the project is to hire me for consulting through my employer, Key Consulting. I can help you get started with Git, including Git-deliver. I can work remotely, or you can pay for my travel from Paris, France. Contact me at email@example.com for more information.