Talk:Continuous delivery/Archive 1

Archive 1

Subject of podcast

Continuous delivery was the subject of podcast Herding Code, episode 143 (MP3, 28 MB, 41 min 23 sec, published 2012-05-11). --Mortense (talk) 12:52, 12 May 2012 (UTC)

anon addition

How Wix implemented Continuous Delivery."The Road to Continuous Delivery - Wix Story".. If someone gets a chance to review if this is a WP:RS and glean any worthwhile material for the article. Walter Görlitz (talk) 07:11, 11 January 2014 (UTC)

Delivery vs Deployment

There's an ongoing confusion, or argument if you so will, to whether the art of continuously installing/uninstalling and making the software ready for installing is called C Delivery or C Deployment. There are two sides to this coin: one side argues that you can't deliver without having deployed it at some point to verify the deliverable's quality; the other side argues that if the software isn't running, then it's only delivered but not deployed.

Puppet Labs talks in terms of "Delivery happens first, then Deployment". So does the book listed in the references section.

Another example is this: A software delivery company (Provider) that sells software over the counter to various clients/customers (Consumer) may provide software packages that can be installed automatically, as is done with most Linux distributions. You select the package to install and it gets installed without further manual steps. Upgrades typically happens automatically too (though this typically can be turned off in whole or in part (only allow security upgrades to be automatically installed)). To the point: The provider thus can't Deploy the software so that it reaches its actual users, the provider can only Deliver software (which before being published/distributed/released most probably have been deployed internally). To able to do Continuous Deployment, this means that software must be offered as a service to the end users, ie that software and service is hosted by the Providing party. — Preceding unsigned comment added by Fredrik wendt (talk • contribs) 12:53, 20 September 2014 (UTC)

Remove Poka Yoke reference

"Continuous delivery treats the commonplace notion of a deployment pipeline[1] as a lean Poka-Yoke" - this sentence doesn't make sense? Even if you look up what they mean, poka-yoke is Japanese for 'mistake proofing'. So it's a 'lean mistake proofing'!? — Preceding unsigned comment added by 207.114.222.38 (talk) 17:19, 24 October 2014 (UTC)

I just now added citation for Poka-Yoke Michaelmalak (talk) 00:31, 25 October 2014 (UTC)

Confusion with Continuous Deployment

This page helpfully cautions the reader not to confuse Continuous Delivery with Continuous Deployment, and explains briefly how they are different.

When the reader then looks up Continuous Deployment in Wikipedia, she is redirected... back here, to Continuous Delivery. Fail.

208.86.145.68 (talk) 23:37, 19 January 2016 (UTC)

So stop whining and you fix it. Andy Dingley (talk) 00:42, 20 January 2016 (UTC)

I checked and could not find the circular link. Walter Görlitz (talk) 15:26, 20 January 2016 (UTC)

@Walter: if you click this: https://en.wikipedia.org/wiki/Continuous_deployment or this: Continuous deployment ... you end up back at Continuous Delivery. @Andy: flagging the problem lets someone else take a crack at solving it before I can get around to it. If nobody does, I guess I'll need to create a Continuous Deployment page. 208.86.145.68 (talk) 21:01, 20 January 2016 (UTC)

I recognize that. But it's not linked in the article. You could change that redirect to point to the Relationship to Continuous Deployment section. You could also change the wording of the first sentence there to remove that phrase. I am not going to do that as I'm hoping that that you will take a few steps toward being an editor. I suspect that Andy Dingley has a similar idea. Walter Görlitz (talk) 05:38, 21 January 2016 (UTC)

Quality Impact of Continuous Delivery

I feel that the topic above has not been given enough exposure. The first listed benefit is: "Accelerated Time to Market" and, indeed, this seems to be the primary focus. This is a desirable objective but is subject to constraints. Specifically, it is a demonstrable fact that additional test time will remove additional error. This known fact is diametrically opposed to "Accelerated Time to Market". This facet is not explored at all. The only counter-argument presented is "Tests needing a human oracle: Not all quality attributes can be verified with automation. These attributes require humans in the loop, slowing down the delivery pipeline." which appears to say that if we could only figure out how to automate that part of the problem, it could be solved. Instead, experience reveals that each error has a probability of being discovered (based up the rarity of the containing path and upon error complexity -- how many conditions have to be true to stimulate the error to show itself). To the extent that this is true, the discovery of error is a strictly time based problem which may explain why we observe the time behavior of testing indicated above.

There is another facet that is not even mentioned. It should lie in the obstacles section. This is the observation that learning takes time. Deployment means that the people doing the deployment and the people doing the consuming of the software require time to figure out how to install and use the software. This time requirement provides a natural "governor" on the ability of any organization to absorb new technology. Indeed, it is entirely possible to "flood" people with so much "stuff" that it is impossible for a human being to understand it all. This, too, receives short shrift in this article and needs more exploration.

My concern is that this article is biased towards benefits and minimizes obstacles thus providing a biased view of the subject. This needs to be balanced so readers are not led astray. — Preceding unsigned comment added by Maurermxm (talk • contribs) 17:30, 5 October 2017 (UTC)

My concern is that none of what you wrote is from a reliable source. See WP:RS. Walter Görlitz (talk) 17:35, 5 October 2017 (UTC)

Lacks a disadvantages section.

Mainly, that continuous delivery, in actual practical reality, always results in permanent instability.
Because no release is tested properly and allowed to mature anymore. Because that would take “too much time”, and succeeding releases would already be ready before the maturing would be done. So no release is ever stable.
Like this, the article reads like it is written by a disciple of the Cult Of (Riding) The Dead Horse. Aka people who started doing things like this, and now have to believe it even more feverishly, to compensate for how much evidence they have for its failing.
— 78.34.99.107 (talk) 23:47, 27 October 2017 (UTC)

I don't agree with *all your criticisms* here.

• Testing: automating the testing of staged systems feeds in nicely with CD; you can make those test results the automated blocker. Even so, those tests will check out base functionality; perf & load handling harder to track
• Software is generally a world of permanent instability anyway.

Critique-wise: I'd add "expectation of ability to deploy changes in minutes leads to unrealistic expectations of delivery, pressure to ship quick fixes and the risk of releasing immature code". Been there. — Preceding unsigned comment added by SteveLoughran (talk • contribs) 19:53, 11 March 2018 (UTC)

Remove CDE reference

The first sentence says that Continuous Delivery is abbreviated as either “CD” or “CDE.” While the former is common in literature, the latter does not seem to be common.

My recommendation: either qualify the reference to the abbreviation “CDE” – or remove it completely

Ernstdehaan (talk) 13:56, 24 March 2020 (UTC)

Ernstdehaan, Thank you for the recommendation. You can do it. Wikipedia:Be_bold and Wikipedia:BOLD, revert, discuss cycle I'll come around later and do it in case you do not want to. Removal it okay with me as CD is common and I have not encountered CDE in the wild. —¿philoserf? (talk) 17:25, 24 March 2020 (UTC)

I took care of this today and added the {{abbr}} wrapper template too. —¿philoserf? (talk) 16:55, 25 March 2020 (UTC)

{{abbr}} is incorrectly used here. Walter Görlitz (talk) 11:39, 27 March 2020 (UTC)

@Walter Görlitz:, This conversation is the why of the change you reverted. I missed the change in the main section. My mistake was to only update the lead. If you, or another editor doesn't object I will correct the article by removing both. —¿philoserf? (talk) 16:21, 27 March 2020 (UTC)

Already done. Walter Görlitz (talk) 16:43, 27 March 2020 (UTC)