It also looks like using ansible + git. However, also gitflow is just a clever use of git branches, but having a standard way of doing things using simple existing tools (git + ssh here) defined by someone who has studied the problem is very valuable to other people who has similar issues, but didn't study the case yet.
I appreciate the work that has gone into this code, but if you want to deploy using source control then you should really be looking into continuous integration and deployment.
I think the simple answer to this one is that it's a universal deployment tool. Like it or not, anyone who uses git can use it.
If I'm working on a Python project, I could possibly create a Fabric file to help automate the deployment. Anyone working on the same project would have to install Fabric, and figure out any quirks it has.
The same then applies to every other language. They tend to recreate deployment tools in their own language to solve the exact same problem. Capistrano for Ruby, etc. Everyone has to learn the deployment process for each different project.
Using git as a deployment tool means that the only person who has to worry about the deployment process is the one who creates the server side commit hook/push scripts. All the complexity is taken away, they just have to say "push to git@example.org" and all the magic behind it is taken care of.
It's universal between all projects. If I'm running a PaaS, all I have to tell my users is to put files in a specific place, add a config file, push to our servers. Without this, users of every language might need specific deployment tools, or be forced to use a generic one which might not suit their needs.
These two things typically go hand in hand. I personally use git to version my deployments. So, I'll check something into git, and then have it do a deployment via a git post commit hook. This is very handy, in that I have a history of what was deployed along with the changes. I can also easy revert changes and they get pushed out. So, we are distilling a deployment (which typically has many steps) into a 'git push' workflow.
Does it still have the `.git` folder? If so, I'll stick to writing regular build scripts, as nice as this seems. I also want to push a snapshot of a build artifact (sort of, it's PHP after all) - not sending a few folders, sending commands to the remote server to execute, etc.
Anyone have a better way of achieving what I want that doesn't require my hacked together `build.php --deploy` script?
My largest system builds and deploys with Fabric. We deal with multiple load-balancers with unique content, and it works perfectly. I use it for a master control Python script that watches/adds/etc our servers and our data.
Whilst I agree with your objectives and would love a tool that does this. I have not done so myself because of security problems with having .git in the website folder. I'll continue to use git's hooks to copy the files as I push them to the server.
Right now, your source is potentially downloadable via the web, if a developer accidentally places a password in the code and then later reverts the change, its still in the history for someone to find. Plus they get the ability to rip off your work because you've made it public. Or perhaps just scan it for flaws to exploit.
I know what your going to say, that you can mitigate these problems with a simple configuration change. However is everybody that you give the code to going to do that on every server they deploy?
What nextw33k said! It's not an issue for me: I _know_ the gotchas when dealing with this stuff (that's why I asked!), but the people I hire in the future might not.
I only know about it because I've been burned by it in the past!
I had a feeling that was the case :) I will use this for smaller personal things for sure, but I think I've got to handle my startup slightly differently; I've got a lot of security things I have to be wary of!
Thanks so much for this tool btw, I really like the look of it!
It's a bit much at first, but once you realize that it's basically just a build file with some handy functionality baked in, it's very useful. Here's an example of a deploy script for deploying a git repo to a single machine:
set :application, "Project Name"
set :repository, "git@github.com:project/project.git"
set :use_sudo, false
set :user, "deploy_user"
set :shared_children, ["list", "of", "directories/to", "symlink/rather/than/copy"]
set :copy_exclude, [".git/*"]
set :scm, :git
set :branch, "master"
set :deploy_via, :remote_cache
set :keep_releases, 5
set :deploy_to, "/path/to/deploy/to"
server "1.2.3.4", :app, :web, :db
Then you just run `cap deploy` and you're deploying. `cap rollback` instantly rolls back to the previous revision of your code. That deploy script keeps 5 releases and manages a symlink that points to the current release. The git repo is kept checked out, and then is updated and copied to a release directory, so you have multiple separate snapshots of your application on hand.
It's also extremely extensible; we use it to do asset pre-builds, send deployment notices to Hipchat and NewRelic, flush caches, restart background workers, and the like.
As a sysadmin, seeing this kind of stuff gives me The Rage(tm). Don't fight the distro - your distro of choice (Debian, RedHat, BSD, -buntu, whatever) already HAS ways of deploying your software. It even plays nice with interdependencies between different packages, allows custom scripts at different stages of deployment, etc. They're not perfect, but they ARE standard. Learn them, use them, love them, and if there's anything particularily egregious about some aspect of them, they're open source so you can submit patches. Literally every job I've ever had as a sysadmin has started with "...so the developers rolled their own software distribution tool and we're learning the hard way that we've blown a sizable hole in our collective foot with it". Working with developers to apply a suitable dose of RPM or DEB magic (99% of the time, these systems are Linux-based and speak one of those two packages) solves the problem, and everyone agrees that it's a better solution.
Don't fight the distro, people. They've hit all of your problems harder, sooner, and with more edge-cases than you can care to imagine.
20 comments
[ 3.2 ms ] story [ 53.6 ms ] threadI appreciate the work that has gone into this code, but if you want to deploy using source control then you should really be looking into continuous integration and deployment.
If I'm working on a Python project, I could possibly create a Fabric file to help automate the deployment. Anyone working on the same project would have to install Fabric, and figure out any quirks it has.
The same then applies to every other language. They tend to recreate deployment tools in their own language to solve the exact same problem. Capistrano for Ruby, etc. Everyone has to learn the deployment process for each different project.
Using git as a deployment tool means that the only person who has to worry about the deployment process is the one who creates the server side commit hook/push scripts. All the complexity is taken away, they just have to say "push to git@example.org" and all the magic behind it is taken care of.
It's universal between all projects. If I'm running a PaaS, all I have to tell my users is to put files in a specific place, add a config file, push to our servers. Without this, users of every language might need specific deployment tools, or be forced to use a generic one which might not suit their needs.
Git has hooks for kicking off processes, its extensible, deployment scripts don't alter the core of git. What's the problem with evolving something?
Anyone have a better way of achieving what I want that doesn't require my hacked together `build.php --deploy` script?
Right now, your source is potentially downloadable via the web, if a developer accidentally places a password in the code and then later reverts the change, its still in the history for someone to find. Plus they get the ability to rip off your work because you've made it public. Or perhaps just scan it for flaws to exploit.
I know what your going to say, that you can mitigate these problems with a simple configuration change. However is everybody that you give the code to going to do that on every server they deploy?
I only know about it because I've been burned by it in the past!
Thanks so much for this tool btw, I really like the look of it!
It's a bit much at first, but once you realize that it's basically just a build file with some handy functionality baked in, it's very useful. Here's an example of a deploy script for deploying a git repo to a single machine:
Then you just run `cap deploy` and you're deploying. `cap rollback` instantly rolls back to the previous revision of your code. That deploy script keeps 5 releases and manages a symlink that points to the current release. The git repo is kept checked out, and then is updated and copied to a release directory, so you have multiple separate snapshots of your application on hand.It's also extremely extensible; we use it to do asset pre-builds, send deployment notices to Hipchat and NewRelic, flush caches, restart background workers, and the like.
Don't fight the distro, people. They've hit all of your problems harder, sooner, and with more edge-cases than you can care to imagine.