Hacker News Reader

Comment by ithkuil | Hacker News Reader

Honestly curious: has it ever been a practical problem to you or somebody you know?

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.

Which approach do you prefer to solve this problem?

I use fabric, I can type

>> 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.

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.

Reply on news.ycombinator.com