4 ms·

My objection is automatically updating your server using deployment scripts checked out from a git repository. Git wasn't and will never be designed to be a dep

by Ixiaus 13y ago

My objection is automatically updating your server using deployment scripts checked out from a git repository. Git wasn't and will never be designed to be a deployment solution, and automatically updating a cluster of servers using a cron is bad advice. You're a smart man and I enjoy your blog, so please don't take what I'm saying personally (I used language in my original comment that was too emotional). I would only recommend this if you had a separate server that acted similarly to a continuous integration server: it listens for pushes to a repository, checks out the latest code, builds an image from the latest known stable and runs the new scripts/configuration/whatever in the image along with application tests to ensure nothing is broken. If everything passes, then the CI server should bundle it up into a .deb and serve it on its own deb repository to the production servers. The production servers (if all running the same image version) should be safe to update using a cronjob; but even then you should make sure that their "image version" is next in the hierarchy. Deployment is then using the native deployment tools to the environment that were designed for it - this way you should be able to completely reverse your upgrade too if something DOES break! Huh, that's starting to sound like image migration...

StavrosK 13y ago
> You're a smart man and I enjoy your blog, so please don't take what I'm saying personally (I used language in my original comment that was too emotional). Oh don't worry about that, I just wanted to hear your opinion. > I would only recommend this if you had a separate server that acted similarly to a continuous integration server. Yep, that's exactly the current setup. I should have included a disclaimer that said "only implement this if you're sure it won't break". > If everything passes, then the CI server should bundle it up into a .deb and serve it on its own deb repository to the production servers. This is how large-scale deployments should be done, I agree. My post (and the way I use this) is for single-server or two-server deployments for small projects, mainly in startups, where a full-blown provisioning server is overkill. It has worked very well there, but it does take some higher amount of responsibility. For larger deployments, we're doing what you mentioned: Jenkins continually runs tests, packages the repo in a .deb if they pass, and triggers the deployment through a PPA to the corresponding servers. I should update the post with rationale on which use cases this serves, I take that too much for granted sometimes. Thanks for the feedback!

by Ixiaus 13y ago

StavrosK 13y ago

> You're a smart man and I enjoy your blog, so please don't take what I'm saying personally (I used language in my original comment that was too emotional). Oh don't worry about that, I just wanted to hear your opinion. > I would only recommend this if you had a separate server that acted similarly to a continuous integration server. Yep, that's exactly the current setup. I should have included a disclaimer that said "only implement this if you're sure it won't break". > If everything passes, then the CI server should bundle it up into a .deb and serve it on its own deb repository to the production servers. This is how large-scale deployments should be done, I agree. My post (and the way I use this) is for single-server or two-server deployments for small projects, mainly in startups, where a full-blown provisioning server is overkill. It has worked very well there, but it does take some higher amount of responsibility. For larger deployments, we're doing what you mentioned: Jenkins continually runs tests, packages the repo in a .deb if they pass, and triggers the deployment through a PPA to the corresponding servers. I should update the post with rationale on which use cases this serves, I take that too much for granted sometimes. Thanks for the feedback!