It has for me. Doing deploys direct from source control implies you're doing other things in production you shouldn't be. Like a `bundle install`, or `rake assets:precompile`. Those are both slow and error-prone, neither of which is what you want when you're pushing a bug-fix out.
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.
Build .debs either locally or (preferably) from CI, push them to an apt repository, apt-get install to production from puppet/ansible.
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.
Ah ok, so your primary concern is that the actual production environment should be separated from the build environment. Fair enough.
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?"
Yeah, I've got no problems with what you run locally to trigger a deploy being a `git push`. Where it pushes to is the interesting part.
> 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.
Have you ever been unable to reach GitHub during a denial of service attack? They're supposedly rare, but I've been committing during three of them in the last year. Simply, they're not dependable and if you deployment mechanism needs to be dependable then you're adding a rather weak link to the chain.
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.
What about simply putting a "deploy" script into your main source directory? Executing
./deploy
is even less work than "git push" into a special remote repository/branch.
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.
IMO the neat thing about a "git push" deployment is that you are deploying a particular commit.
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.
Dokku is awesome (as is Docker which it builds on). The guy that wrote it (Jeff Lindsay) has been working on Flynn for the past 6 months - https://flynn.io/ - think of Flynn like a 'multi host dokku'
23 comments
[ 3.5 ms ] story [ 70.0 ms ] thread>> 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.
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:
https://news.ycombinator.com/item?id=7755914
Interesting ... it says one of its main functions is the ease of reverting / backing out of an install.
>>>> 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: