Is automatic deployment crucial to agile development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Clo开发者_高级运维sed 5 years ago.

Improve this question

I ask because my team previously was trying to "do" scrum. We had 2-week sprints, but no releases to go with those sprints! There were several other reasons for this, but one big one was that deployments took too long and were too complicated to do that frequently.

---

You sort of answered your own question: if deployments take too long, they can't be done frequently and you can't have short iterations, you can't ship the code at anytime, you can't demo progresses at the end of an iteration, etc. So, in your context, not having an automatic deployments was a major impediment that should have been identified and removed very early (through inspection and adaptation).

Back to the question now. Is automatic deployment a crucial practice? Well, as hinted, I'd say it depends on the context: a project with a simple and straightforward manual deployment process can probably live with it. Is automatic deployment a good practice? I think so: an automated process is typically faster, less error prone and humans obviously don't add much value at doing something that can be automated (see also Three Strikes And You Automate).

---

I'd say yes, it's an essential practice. If deployments are too complicated and taking too long you've got a bigger problem. I think you should sort that out. You have to do them sometime. Doing the work to make it possible to build at will can only help your project.

Being able to claim the "agile" label isn't important; having an automated, hands-off, repeatable build is the point.

---

Crucial, no, you can get away without it but, as you've found out, everything that you have to do manually will slow down your cycle time.

You should be aiming to automate as much as possible, build, deployment, regression testing and so forth, so that you're not unnecessarily delayed.

The idea of a sprint without a release is an ... interesting ... one. I can't say I've ever seen that tried before :-)

---

You have to distinguish clearly two things: a shippable product increment and an actual shipment. First is what your team should produce every sprint, second is what may happen with it if it makes business sense.

In other words: what the team produces each and every sprint must be a piece of completely working code, a new increment of whatever it is that you develop. It should be fully built and tested - which is why automatic testing and building environment is a must if you are to do this. However, whether it should be deployed every sprint to production servers and whether this should be automatic is a completely different thing which has nothing to do with the development process itself.

If it is a requirement that you deploy to live production server every sprint (by all means a very good thing to do) then it would probably make sense to automatize it, but whether this process is fully automatic or no shouldn't impede your team's ability to produce fully working code every sprint.