4 ms·

I like that this article doesn't focus too much on the technical aspects of auto-deploys and CI. I've been in a lot of places where the concepts were lumped tog

I like that this article doesn't focus too much on the technical aspects of auto-deploys and CI. I've been in a lot of places where the concepts were lumped together, and while we could have easily delivered software continuously, we falsely believed we needed every last thing to be perfectly automated before we did. It's important that your deployment process is repeatable and simple (i.e. typing one or two commands into a terminal), but if a human is still kicking it off that's still a net positive over big timed releases.

vsupalov 9y ago
Good point. But that's not limited to automation. As with data engineering, or software development, you're likely to overdo it and build something which does not agree with reality if you "try to build the whole thing" at once. Building the smallest possible deployment pipeline (a skeleton pipeline, as it's called in the continuous delivery book (from 2010 but still the best thing on the topic out there) [1]). You start covering the most essential needs just so they become useful and usable. Then you go ahead and iterate from there, building something which suits your team, company & product. Learning and adapting in the process. [1] https://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 https://www.amazon.de/Continuous-Delivery-Deployment-Automat...
perlgeek 9y ago
We have automated our deployments using https://gocd.org/ https://gocd.org/ (which mostly runs Ansible scripts that do the actual deployment), and we use manual approval steps to trigger production deployments. This is a very nice escape hatch for when you want to do manual steps (like manual testing) before a deployment, but you can still rely on the fact that deployment to prod will use the same playbook as deploying to staging did.
jbattle 9y ago
I agree that reaching perfect automation isn't critical - but one thing that is critical is to ensure that local uncommitted changes do not get deployed. I've been burned a couple of times where changes from a developer's machine ended up in production
- rhizome 9y ago
  How does that happen? The only way I can think of is when using a "copy local" type deployment rather than a repository checkout, which is a pretty basic bug in this kind of process that should be eliminated by the time "automation" is a priority.

vsupalov 9y ago

Good point. But that's not limited to automation. As with data engineering, or software development, you're likely to overdo it and build something which does not agree with reality if you "try to build the whole thing" at once. Building the smallest possible deployment pipeline (a skeleton pipeline, as it's called in the continuous delivery book (from 2010 but still the best thing on the topic out there) [1]). You start covering the most essential needs just so they become useful and usable. Then you go ahead and iterate from there, building something which suits your team, company & product. Learning and adapting in the process. [1] https://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 https://www.amazon.de/Continuous-Delivery-Deployment-Automat...

perlgeek 9y ago

We have automated our deployments using https://gocd.org/ https://gocd.org/ (which mostly runs Ansible scripts that do the actual deployment), and we use manual approval steps to trigger production deployments. This is a very nice escape hatch for when you want to do manual steps (like manual testing) before a deployment, but you can still rely on the fact that deployment to prod will use the same playbook as deploying to staging did.

jbattle 9y ago

I agree that reaching perfect automation isn't critical - but one thing that is critical is to ensure that local uncommitted changes do not get deployed. I've been burned a couple of times where changes from a developer's machine ended up in production

rhizome 9y ago
How does that happen? The only way I can think of is when using a "copy local" type deployment rather than a repository checkout, which is a pretty basic bug in this kind of process that should be eliminated by the time "automation" is a priority.