Timeline for Is CI/CD a myth
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11 at 9:01 | comment | added | jwenting | ctd... Or at the push of a button an admin can install it on any system that needs it more quickly than that. That's how CI/CD works in reality in many organisations. It speeds up our internal operations without bothering the customers with frequent forced updates. | |
| Nov 11 at 8:59 | comment | added | jwenting | Many customers, especially large ones, do NOT want constant updates and releases because it bogs down their own acceptance and integration testing. We release a minor release every other week to customers, and a major release twice a year. We use CI/CD to prepare those releases for customers to download and install at their leisure, and more than a few are years behind in their updates despite frequent reminders they're loosing support after 2 year! Internally every approved PR is prepared for delivery to test systems automatically, and installed on all test systems every night. | |
| Nov 11 at 5:54 | comment | added | Flater | @candied_orange: A more apt analogy would be that you're giving a driving lesson where you aren't allowed to say that turning the steering wheel makes the car turn, you're only allowed to explain that it puts an angular force onto the steering axle. The subsequent effects of that should point themselves out on their own, right? I mean, just look at how the car was built. Do I need to explain everything here? Pedantic correctness of what is the most directly adjacent effect (and shutting everything else out) is not a productive attitude to communication, especially when teaching new concepts. | |
| Nov 11 at 3:29 | comment | added | candied_orange | @flater the most effective defense against that accusation that a car doesn’t solve every promised transportation need on it own is to explain that it’s not self driving and that you have to know how to drive it yourself. By all means, teach them to drive. | |
| Nov 11 at 2:16 | comment | added | Flater | @candied_orange: "No, it gives you the ability to have frequent releases" You're arguing that we can't address indirect benefits, which is an act of cherry-picking for the sake of being able to condense your answer. The question as to why one would choose to implement CI/CD is not restricted to merely an explicit need to have more frequent releases. Claiming so effectively suggests that any company that has been making do with a slower release schedule wouldn't need to consider CI/CD, indirect benefits be damned. That's just not how communication works, nor how good practice is established | |
| Nov 11 at 2:11 | comment | added | Flater | This answer suffers a bit from oversimplification. Frequent releasing is CD, not CI/CD. Yes, it is true that by enforcing CD, it almost inevitably forces your hand to implement CI which entails a bunch of other improvements that simplify the release process, but at the same time these improvements also have benefits/justifications on their own that his not inherently tied to the release process. CI/CD refers to a larger concept than just CD. OP's concern is one of imprecise justification being given for the pro CI/CD guideline, and this answer is just repeating the same kind of imprecision. | |
| Nov 10 at 13:27 | comment | added | candied_orange | @DannyNiu The salesmen, trying to convince you that CI/CD will give you "faster xxx", "less bugs", "better code quality". No, it gives you the ability to have frequent releases and the tight feedback loops that come with that. If it gives you any more than that it's because you paid attention to the feedback. You don't get that other stuff for free. It's work. | |
| Nov 10 at 13:15 | comment | added | DannyNiu | So who's the idiots in this case? The non-technical managers? Who's the salesman? Who are they selling to? These are quite confusing and feel as if secret lingos. | |
| Nov 10 at 13:02 | comment | added | candied_orange | @DannyNiu the only metaphors I used were "golden" (see meaning 5) and "crap" (see meaning 1). But you didn't single those out. The toast thing is not a metaphor or an idiom. I meant it as is. Ask idiots, selling things they don't understand, if it will make toast and they will say yes; even when it's not a toaster. It's aggressive salesmanship. Our field is full of it. If those links help I can add them to the answer. | |
| Nov 10 at 12:35 | history | edited | candied_orange | CC BY-SA 4.0 |
added 42 characters in body
|
| Nov 10 at 12:30 | comment | added | DannyNiu | @candied_orange From my experience participating on POSIX mailing list, we don't put overly casual language or slangs into international standards. Your added paragraph has 2 which I've indicated in a previous comment. I would appreciate if you can edit them into plain English statements. Since you're asking me for specifics, I assume you've little experience participating in one, so all I can say is: write formally. I checked my dictionary a bit further, I think it's 2 instances of metaphors without lingual background. | |
| Nov 10 at 12:16 | comment | added | candied_orange | @DannyNiu what ISO IETF vocabularies? If you don't point me at it then all I can do is search. Google found Terminology Used in Internationalization in the IETF which helps with their stuff not mine. I dug up Electropedia: The World's Online Electrotechnical Vocabulary which is more general but they missed my entire field. Nothing about software or its development in here. | |
| Nov 10 at 11:49 | comment | added | candied_orange | @Steve yes Steve. | |
| Nov 10 at 9:16 | comment | added | Steve | @candied_orange, "I never want to go back to a shop that needs 6 months of testing before a release." - am I right that what you mean by this, is that with small changes constantly drip-fed to release under CI/CD, you avoid the lead time where changes are accumulated followed by the perceived need for extensive pre-release testing of all these changes together (unlike with a release of a large batch of changes, where the alternative to such thorough testing would be a sudden blitz of faults)? | |
| Nov 10 at 7:23 | comment | added | DannyNiu | Maybe "rhetoric" isn't the best word (I machine translated it into English), it's more like idioms and slangs. I think vocabularies for standards (such as ISO IETF publictions) are more suitable. | |
| Nov 10 at 6:39 | history | edited | candied_orange | CC BY-SA 4.0 |
deleted 1 character in body
|
| Nov 10 at 6:36 | comment | added | candied_orange | @DannyNiu why are those "rhetoric" any more than "fast feedback loops"? I'd love to make it better. But first I need to understand what's wrong. | |
| Nov 10 at 5:44 | comment | added | DannyNiu | Particularly: "and will tell you it can make toast if it will get you to buy", and "I never want to go back to a shop that needs 6 months of testing before a release". | |
| Nov 10 at 5:11 | comment | added | candied_orange | @DannyNiu sure, but please explain what you're calling rhetoric. As a native English speaker I think the whole answer is rhetoric. | |
| Nov 10 at 4:53 | comment | added | DannyNiu | Could you edit your added paragraph to avoid rhetorics? Non-native English speakers (such as me) find it hard to comprehend. | |
| Nov 10 at 4:44 | history | answered | candied_orange | CC BY-SA 4.0 |