search

ESCL / salt-config

0 stars 0 forks source link

Reconsider use of CD for pjtracker #1

Closed kako-nawao closed 8 years ago

kako-nawao commented 8 years ago

Do we really want to implement Continuous Delivery for pjtracker project? Isn't that a little risky?

It might make more sense to do Continuous Integration to a development branch and then make weekly releases (ie, merge to master) of the application after running a manual test (say, on weekends). If we keep a changelog of the modifications it would be easy to run the tests to assert the correct functionality of new features.

omelendrez commented 8 years ago

Yes, Continuous Delivery is risky. Very risky. Continuous Integration should be the approach. And yes, releases can be made weekly.

kako-nawao commented 8 years ago

Agreed, there's also another problem with CD concerning client expectations: they assume you can fix one bug (and redeploy) in a matter of minutes. Which isn't necessarily wrong, but kind of shifts development to a firefighting exercise.

kako-nawao commented 8 years ago

Done, now we have two pipelines: one for develop (new integration branch) that deploys demo and one for master that deploys prod.

We keep the same trigger setup, so merging develop into master will trigger a prod deployment. We would do this after testing the demo environment.