Using “git push” to deploy Ruby applications to your own server
blog.bytemark.co.uk
blog.bytemark.co.uk
>> fab push prod deploy
to push changes to my repo service, ssh to production servers, pull down changes via git, and restart necessary services/run associated tasks like symlinking to new static content.
Aside from "deploy" I have tasks to update the virtualenv etc, this has worked well for me for a few years.
EDIT: I should explain how this actually helps solve the problem. If I'm building a package locally, I can take advantage of all sorts of cached files which I can't assume are present on the production server. I can also use tools I don't want installed in production to speed up the process. Building a local package from cached gems is pretty quick, and will get much quicker once I've got precompiled gems sorted out. I haven't got a particularly good answer to speeding up `rake assets:precompile`, but having it fail locally is better than having it fail in production.
It's an orthogonal issue w.r.t whether the end user (i.e. the developer) should initiate a deploy by using "git push". Usually this is managed by some kind of CI server than then deploys the artifact. I understand that here the TFA was actually advocating to skip this step.
However, in both cases the size of the repository (which you called the index, which btw I'm not sure is the right name; the index in git is the place where you stage changes in preparation for a commit) could be an issue. My question was more like "did you ever encounter any problems due to the size of the git repository at the build server?"
> which you called the index
Not me, I'm just "helpfully" sticking my oar in :-) I've not found index size to be a significant problem myself, but then I don't tend to find myself into situations where it can become one.
Obviously you could host/mirror git locally for more robustness, but it will be yet another system you depend on. It is for this reason that every enterprise I've worked at used a solution where a tar ball of the code to be deployed was composed, archived, and then pushed out to ensure it was available for all nodes and that old versions were available for rollbacks.
As a simple example of the above, my TeamCity server builds all commits, then pushes successful war files to S3, then contacts all the server nodes that fetch their deployment code from S3, which has 11 9's durability.
./deploy
This "deploy" script would execute RSync and whatever needed to update the destination machine, without any server-side magic behind the scenes. It could also execute "git push" so you don't have to remember to push before deployment.
The build server could annotate the build with the commit's hash, making that deployment reproducible.
If you just have a local ./deploy script, a dev might deploy changes that never make it into version control.
(Even if ./deploy forces the working copy to be clean and the index to be empty, the dev could still "git reset --hard" afterwards and the version that has been deployed is lot)
it's abused for many purposes, but its' job is managing versioned deployments which can be rolled back.
you want this as early as possible, don't shun learning a tool for a couple hours for two years because you don't think you need its' power yet, start getting to know it so you're ready when you do.
(Eg, the /home/app/foo.git repository's working directory is in /var/www/foo)
All you need is to move the .git directory, and then make a .git file with these contents in your working directory:
gitdir: /home/foo/foo.git>>>> nothing to commit (working directory clean)
>> This means we’re on the version of Dokku currently suggested for use with Ubuntu 12.04 by its author.
No, it just means your on a detached head. Instead of git status, try:
git tag --points-at HEADInteresting ... it says one of its main functions is the ease of reverting / backing out of an install.