Timeline for How can Continuous Delivery work in practice?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 7, 2016 at 15:30 | comment | added | atoth | Regarding "Database access is tested implicitly by your end-to-end scenario based functional acceptance tests." The key problem is this is implicit. People seems happy with that, but this is a very time wasting approach; instead of telling the problem "This is what I expected from the DB and got this instead", it says "Something broke in one of the 100 layers". | |
| Dec 12, 2011 at 19:15 | comment | added | Jez Humble | I like to distinguish between continuous delivery and continuous deployment. Here's the difference. Continuous delivery means you keep the system production-ready at all times and can release on demand at the push of a button. Release is a business decision. Continuous deployment is a limiting case where you release every good build (note not every check-in - some check-ins don't result in a releasable build). In both cases you can include manual validations: the key is the concept of the deployment pipeline. | |
| Dec 11, 2011 at 16:54 | vote | accept | Joshua Fox | ||
| Dec 10, 2011 at 16:24 | comment | added | Joshua Fox | Thanks for your answer. Yes, I believe in testing. My projects have had good code coverage from automated tests run with the daily build. I'm just saying that you need some sort of iteration before you release. "You still need to perform exploratory testing ... manually." I don't understand. A full CD system deploys on every checkin. How can you do that if you include manual testing? | |
| Dec 9, 2011 at 19:28 | history | answered | Jez Humble | CC BY-SA 3.0 |