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.
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.
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.
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.
Comments
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.
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.
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.
Which approach do you prefer to solve this problem?
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.
I use fabric, I can type
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.