DEV Community

loading...

Discussion on: Frequent delivery - how?

Collapse
quii profile image
Chris James • Edited

The key to delivering software as quickly as possibly is to have as little process as possible but place value on things that actually give you confidence.

Ask your engineers, if we deployed every commit to live; what would it take for you to not be scared?

  • Tests. No manual testing allowed if you're practising continuous delivery
  • Monitoring, so you know if something has gone wrong
  • Green/blue deployments
  • Pair programming
  • Breaking down stories into small tasks. If you're shipping small things frequently then the risk is low.

Scrum, kanban, etc are all distractions honestly.

Collapse
bertilmuth profile image
Bertil Muth Author

Do you currently work that way? How are business priorities reflected in your way of working?

Collapse
quii profile image
Chris James • Edited

Yes I do, it's very nice and teams I have worked on have always been less stressed, more productive and happier compared to teams that release weekly/monthly

Re the business

It's important to distinguish between business requirements and technical activities.

Files moving from one server to the other (i.e deploying) is not a business concern. Just like how creating functions is not a business concern.

Depending on the business it is better to ship features when they're ready even in an MVP state. But if the business wants/needs control, use feature flags.

edit-

Due to the fast feedback, iterative nature of continuous delivery business requirements are generally more based on actual real feedback rather than guesses. In addition because we can ship things easier they are more open to trying different ideas. So CD is not only a technical win but a business one too. It changes the way the business works for the better.