Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Continuous delivery -- running on the blade edge

News Is DevOps a yet another "for profit" technocult? Bosos or Empty Suits (Aggressive Incompetent Managers) Cargo cult programming Continuous delivery -- running on the blade edge Agile -- Fake Solution to an Important Problem Infrastructure as Code
Managing Managers Expectations Authoritarians Bureaucracy as a Political Coalition Dictionary of corporate bullshit Preventing Vendors From Playing The Blame Game Unix Configuration Management Tools Unix System Monitoring
Conway Law Brooks law Real Insights into Architecture Come Only From Actual Programming Micromanagers Bully Managers Narcissistic Managers Surviving a Bad Performance Review
The Good Soldier Svejk Parkinson Law The Peter Principle Pollyanna creep Sysadmin Horror Stories Humor Etc

Wikipedia defines this term as (Continuous delivery - Wikipedia)

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

The idea of continuous delivery comes as a generalization of the idea of nightly builds that are common practice in  many software companies.  The new twist is higher level of automaton of acceptance testing using battery of tests that are applied to each build. The idea pioneered by Perl many decades ago. Ideally developers approve or initiate the deployment, and all testing is dome by some robotic machinery. If successful the release goes into production.  The positive idea here  is the level of automation of acceptance testing for most applications can be dramatically increased. Often using existing, off the shelf testing tools and packages that do not cost all that much in companion with the cost of human labor.  So this is variation of the theme "robots eat people".

Highly sophisticated and highly automated acceptance  testing is performed  for compliers and interpreters for a long time.  Probably decades, if we are talking about, for example Perl interpreter.  Here how enthusiasts of this approach try to sell it ( The quickie guide to continuous delivery in DevOps )

To start with, the terms apply to different parts of the same production arc, each of which are automated to different degrees:

With continuous deployment, "a developer's job typically ends at reviewing a pull request from a teammate and merging it to the master branch," explains Marko Anastasov in a blog post .

But when the result of such "robotically tested builds" are pushed into production,  huge unanticipated problems might arise, when you can't define algorithmically all most typical scenarios.  Murphy law guarantees that. In other words automated testing can't fully replace trained testers and pilot users and weeks of month of their experience with  the new release.

It still makes sense for a very small teams, and very specific software domains. Actually it favors "a single isolated developer" (lone wolf) approach. But at the same time it gives developer too much freedom which they naturally tend to abuse.  Too much  rope to hang themselves. The risks of malfunction of newly baked code are high, no matter how much automated testing was performed, unless the change is trivial (and even in this case there might be problems, Year 2000 scare is one example here).

Continues delivery often is practiced by developers of small Web sites or utilities (when the current release is always the current build from, for example, gitube).  And even for those small scale projects, the users sometimes are badly burned.  In other words this approach does not scale up outside of small applications such as utilities, web site scripts,  and few other specific software domains. Especially, if the user interaction with application is complex. Simple, primitive Web interfaces like used by Netflix are more amendable to this approach. If you go up in complexity things became much less rosy. 

In a way, this is return on a new level of pipe dream of verification enthusiasts: that there is a magic bullet that allow you to produce bug free software using some formal or semi-formal methods. This time automated testing is the magic bullet. But as a general statement this is clearly an attempt to sell a snake oil and people who are doing it are clearly charlatans.  There is no magic bullet.

Yeah, maybe there's something useful in continues delivery in small software projects with  very few users,  which are run highly disciplined and talented developers, but  as you go up in complexity and size of the  user population, risks became way too high to try it.  Nothing alienates customers more then being a guinea  pigs for developers.

 Nothing alienates customers more then being a guinea  pigs for developers.

Another great suspicion comes from the fact that the  articles advocating continued delivery typically are devoid of any substance.  One of the most difficult problem is creating the  new release is how to avoid  "software featurism" and not to lose a part of conceptual integrity of the product.  continues delivery removes some barriers for developers. And  those developers who were added to the project at the late stage do not understand the underling philosophy and underling compromises by their enthusiasm can destroy perfectly viable product. 

Another waning sign for "continues delivery" hoopla is that most articles that cover this topic are just buzzword soup with a dash of spicy new technologies names like DevOps thrown in. Five years ago they would have said practically the same words, but  just talked about another fashionable technology instead. This type of content is called techno scam and  people who produce it techno scamsters.   That doesn't mean that continues delivery is complete sham, but as project size of complexity grows it became one very soon indeed.

But the message of people who beat the drum and match with this banner is that all you need is to switch. And everything is better. Yeah, right ;-)

When they are talking about  higher customer satisfaction this is another scam. Of cause, if you set the level of customer satisfaction low enough (for example, if you settle for the level at which customers do not beat the developers as high customer satisfaction  ;-)  you are fine. But in reality most such companies have abysmal customer satisfaction ratings because continuous delivery is equal to constant change  and customers do not like it.  Constant change might be not so bad for developers, they used to live in this world, and typically they are not afraid of braking compatibility if it bring substantial benefits. But constantly changing product is "Alice in wonderland" reenacted on a new technological level. It is  a nightmare for the poor customers of such product.

Any professional software developer will test a new software release thoroughly before letting it get anywhere close to an production environment, especially where their business is at stake. So the fact the most efforts of professional software developers are shifted from pure development  to testing is not  an aberration. This is  a requirements for achieving high quality, because this activity that allow developers to feel the total complexity of the product and how the part designed by him/her actually interacts with other parts.  Complexity slows everything down. That's why productivity of professional developers is so low, costs  are so high and project schedule overruns are typical. 

and that's why software typically has rather rare releases and even more rare versions upgrades.  They are milestone for fully tested product releases that achieved some level of conceptual integrity (with most reckless contributions and ideas discarded), and that should not cause major problem downstream, when deployed.  the only activity when something more or less resembling continues delivery paradigm  can be found for large software project is security patching.  And believe me just a dose of programs few thousand lines each is enough to lose understanding of what is what for even talented developers.  At this point they are simply afraid to touch the code.  There are exceptions to this rule, and some developers do not slow as much with the increasing complexity of the codebase, but they are rare.

Depending on complexity,  the scope of the changes, the level of bureaucracy and qualification of the workforce the process of creating viable new release of a software product can take anywhere from a week or two to several months, or even a year. New versions (major releases of a software product that  add/remove important features) for mature product usually take more then a year. This time is less for new products, but is rarely less then six month.  You can look at Linux kernel release history to see the tendency here.

Timing also depends on the severity bugs found and fixed in previous release, and whether any alterations to the internals, or interface, or working practices have to be introduced.

So to have developers lob a new "release" over the wall at frequent intervals is not useful, it isn't clever, and does not save any money, or speed up the development. It just create a mess, a real nightmare for everybody involved. Except political hacks who usually push for it -- when things became hot people often discover that those slick guys who can do wonderful presentations already jumped to greener pastures (often still on mission to destroy another company, or product ;-) and  there is nobody to fire for the mess created.

In essence, continues delivery offloads the most difficult arts of testing to the users, floods the change control process and helpdesk with "issues" that should be ironed out before the  release, and thus dramatically increases  the level of stress.  If releases are way too frequent and ticket processing is slow you encounter a paradoxical situation when the problem reported for the release, that is no longer deployed. In this case, and if major customers are forced to report the same bugs for several consequent releases, you can be sure that they will jump the ship very soon. You might even get the angry letter with the threat to do so :-)

Any professional software development  team can't rely only of automatic testing for a new release of more or less complex product (it does not matter, whether this is in-house or commercial product). Users need to be involved, or at least professional testers who imitate users. Letting it get anywhere close to an environment where their business is at stake is suicidal.  Just imagine if continues delivery is applied to production of pacemaker software.  

There is a claim that  continues delivery helps developers to concentrated of development instead of the bureaucratic maze connected with testing, deployment and support. To a certain extent this is true, but the price can be way to high. You can fight the situation when  developers are more focused upon deployment/testing then actual development with other means.  for example by hiring additional testers. One to one  ration of developers and testers might be more optimal then many think.

Without strict version control and scheduled dates of release the developers just push too many things out  and production support is responsible for addressing the resulting mess. It is not only horrible stupid practice, but it created disconnect and alienation between developers and other personnel down the food chain. So it is one thing when in very small problem a small group of developers is responsible for everything. They can practice "continues delivery" within the certain bounds and level of discipline. But  if testing and production are separate organization units forget about it: the level of disconnect between developers and other departments will create consistent outages. So the only slight chance to succeed is to adopt the mantra developers should "Eat your own dog food", and support the crap they push. This is a very expensive proposition, even for small projects.  Actually for anything larger that a non-profit website. 

The crux of the problem is that we (in these discussions and the analysts) describe *all* types of software development are the same. They are not. there is a difference between developing a small desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video. I would be terrified if  'continuous delivery' is adopted for a software in the microcontroller of a health care device.

another way to view continuous delivery  is as an attempt to automate the decision-making process that decide when a new release is deployed. In this case supposedly you deploy some sophisticated automated testing process that automatically (or with a click of a button) determine whether all test criteria are met.  If this particular release passed all the tests it can be deployed. This is probably possible for development of compilers and scripting language interpreters like Perl interpreter (that is know for vast library of test cases),  but  generally this is a pipe dream, because with the change of software typically acceptance criteria typically also slightly change.

In any case continues delivery is not a good thing for those poor customers who were chosen to be involuntary beta testers as well as for the rest of the customers who have to deal with software that is constantly changing.  Roll back in case "continues delivery" produced a batched result often is not enough. It is too little too late. Note that a customer with a choice is likely to just go somewhere else rather than use your software.  Like one Slashdot read  wrote "All I know is that, as a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me and I wish it would die the horrible death it deserves already."
 


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Aug 29, 2017] Victory! The smell of skunkworks in your office in the morning

While it's easy to start up a few, flashy new DevOps teams, releasing to production each week and flaunting the ball-and-chain of enterprise governance, scaling that change to your organisation will always be challenging, if not crushingly impossible. When it comes to scaling the skunk-works, I'm reminded of a conversation …

[Aug 29, 2017] The quickie guide to continuous delivery in DevOps

This is pretty idiotic: "But wait -- Isn't speed the key to all software development? These days, companies routinely require their developers to update or add features once per day, week, or month. This was unheard of back in the day, even in the era of agile software development ."
And now example buss words infused nonsense: ""DevOps is a concept, an idea, a life philosophy," says Gottfried Sehringer, chief marketing officer at XebiaLabs , a software delivery automation company. "It's not really a process or a toolset, or a technology." And another one: ..." "In an ideal world, you would push a button to release every few seconds," Sehringer says. But this is not an ideal world, and so people plug up the process along the way."... "
I want to see sizable software product with the release every few seconds. Even for a small and rapidly evolving web site scripts should be released no more frequently then daily.
Notable quotes:
"... Even if you're a deity of software bug-squashing, how can you -- or any developer or operations specialist -- deliver high-quality, "don't break anything" code when you have to build and release that fast? Everyone has their own magic bullet. "Agile -- " cries one crowd. " Continuous build -- " yells another. " Continuous integration -- " cheers a third. ..."
"... Automation has obvious returns on investment. "You can make sure it's good in pre-production and push it immediately to production without breaking anything, and then just repeat, repeat, repeat, over and over again," says Sehringer. ..."
"... In other words, you move delivery through all the steps in a structured, repeatable, automated way to reduce risk and increase the speed of releases and updates. ..."
Aug 29, 2017 | insights.hpe.com
The quickie guide to continuous delivery in DevOps

In today's world, you have to develop and deliver almost in the same breath. Here's a quick guide to help you figure out which continuous delivery concepts will help you breathe easy, and which are only hot air. Developers are always under pressure to produce more and release software faster, which encourages the adoption of new concepts and tools. But confusing buzzwords obfuscate real technology and business benefits, particularly when a vendor has something to sell. That makes it hard to determine what works best -- for real, not just as a marketing phrase -- in the continuous flow of build and deliver processes. This article gives you the basics of continuous delivery to help you sort it all out.

To start with, the terms apply to different parts of the same production arc, each of which are automated to different degrees:

With continuous deployment, "a developer's job typically ends at reviewing a pull request from a teammate and merging it to the master branch," explains Marko Anastasov in a blog post . "A continuous integration/continuous deployment service takes over from there by running all tests and deploying the code to production, while keeping the team informed about [the] outcome of every important event."

However, knowing the terms and their definitions isn't enough to help you determine when and where it is best to use each. Because, of course, every shop is different.

It would be great if the market clearly distinguished between concepts and tools and their uses, as they do with terms like DevOps. Oh, wait.

"DevOps is a concept, an idea, a life philosophy," says Gottfried Sehringer, chief marketing officer at XebiaLabs , a software delivery automation company. "It's not really a process or a toolset, or a technology."

But, alas, industry terms are rarely spelled out that succinctly. Nor are they followed with hints and tips on how and when to use them. Hence this guide, which aims to help you learn when to use what.

Choose your accelerator according to your need for speed

But wait -- Isn't speed the key to all software development? These days, companies routinely require their developers to update or add features once per day, week, or month. This was unheard of back in the day, even in the era of agile software development .

That's not the end of it; some businesses push for software updates to be faster still. "If you work for Amazon, it might be every few seconds," says Sehringer.

Even if you're a deity of software bug-squashing, how can you -- or any developer or operations specialist -- deliver high-quality, "don't break anything" code when you have to build and release that fast? Everyone has their own magic bullet. "Agile -- " cries one crowd. " Continuous build -- " yells another. " Continuous integration -- " cheers a third.

Let's just cut to the chase on all that, shall we?

"Just think of continuous as 'automated,'" says Nate Berent-Spillson, senior delivery director at Nexient , a software services provider. "Automation is driving down cost and the time to develop and deploy."

Well, frack, why don't people just say automation?

Add to the idea of automation the concepts of continuous build, continuous delivery, continuous everything, which are central to DevOps, and we find ourselves talking in circles. So, let's get right to sorting all that out.

... ... ...

Rinse. Repeat, repeat, repeat, repeat (the point of automation in DevOps)

Automation has obvious returns on investment. "You can make sure it's good in pre-production and push it immediately to production without breaking anything, and then just repeat, repeat, repeat, over and over again," says Sehringer.

In other words, you move delivery through all the steps in a structured, repeatable, automated way to reduce risk and increase the speed of releases and updates.

In an ideal world, you would push a button to release every few seconds," Sehringer says. But this is not an ideal world, and so people plug up the process along the way.

A company may need approval for an application change from its legal department. "Some companies are heavily regulated and may need additional gates to ensure compliance," notes Sehringer. "It's important to understand where these bottlenecks are." The ARA software should improve efficiencies and ensure the application is released or updated on schedule.

"Developers are more familiar with continuous integration," he says. "Application release automation is more recent and thus less understood."

... ... ...

Pam Baker has written hundreds of articles published in leading technology, business and finance publications including InformationWeek, Institutional Investor magazine, CIO.com, NetworkWorld, ComputerWorld, IT World, Linux World, and more. She has also authored several analytical studies on technology, eight books -- the latest of which is Data Divination: Big Data Strategies -- and an award-winning documentary on paper-making. She is a member of the National Press Club, Society of Professional Journalists and the Internet Press Guild.

[Aug 28, 2017] Could AI Transform Continuous Delivery Development

Notable quotes:
"... It's basically a bullshit bingo post where someone repeats a buzzword without any knowledge of the material behind it ..."
"... continuous delivery == constant change ..."
"... This might be good for developers, but it's a nightmare for the poor, bloody, customers. ..."
"... However, I come at it from the other side, the developers just push new development out and production support is responsible for addressing the mess, it is horrible, there is too much disconnect between developers and their resulting output creating consistent outages. The most successful teams follow the mantra "Eat your own dog food" , developers who support the crap they push ..."
"... But do you know who likes Continuous Delivery? Not the users. The users hate stuff changing for the sake of change, but trying to convince management seems an impossible task. ..."
"... some of us terrified what 'continious delivery' means in the context of software in the microcontroller of a health care device, ..."
"... It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Developer decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'. ..."
"... It's amazing how common this attitude has become. It's aggressively anti-customer, and a big part of the reason for the acceleration of the decline of software quality over the past several years. ..."
"... All I know is that, as a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me and I wish it would die the horrible death it deserves already. ..."
Aug 28, 2017 | developers.slashdot.org

Anonymous Coward writes:

Re: Score: , Insightful)

Yeah, this is an incredibly low quality article. It doesn't specify what it means by what AI should do, doesn't specify which type of AI, doesn't specify why AI should be used, etc. Junk article.

It's basically a bullshit bingo post where someone repeats a buzzword without any knowledge of the material behind it.

xbytor ( 215790 ) , Sunday August 27, 2017 @04:00PM ( #55093989 ) Homepage
buzzwords Score: , Funny)

> a new paradigm shift.

I stopped reading after this.

cyber-vandal ( 148830 ) writes:
Re: buzzwords

Not enough leveraging core competencies through blue sky thinking and synergistic best of breed cloud machine learning for you?

sycodon ( 149926 ) , Sunday August 27, 2017 @04:10PM ( #55094039 )
Same Old Thing Score: , Insightful)

Holy Fuck.

Continuous integration Prototyping Incremental development Rapid application development Agile development Waterfall development Spiral development

Now, introducing, "Continuous Delivery"...or something.

Here is the actual model, a model that will exist for the next 1,000 years.

1. Someone (or something) gathers requirement. 2. They get it wrong. 3. They develop the wrong thing that doesn't even work they way they thought it should 4. The project leader is canned 5. The software is implemented by an outside vendor, with all the flaws. 6. The software operates finally after 5 years of modifications to both the software and the workflows (to match the flaws in the software). 7. As soon as it's all running properly and everyone is trained, a new project is launched to redo it, "the right way". 8. Goto 1

AmazingRuss ( 555076 ) writes:
Re:

If everyone is stupid, no one is.

ColdWetDog ( 752185 ) writes:
Re:

No no. We got rid of line numbers a long time ago.

Graydyn Young ( 2835695 ) writes:
Re:

+1 Depressing

Tablizer ( 95088 ) writes:
AI meets Hunger Games

It's a genetic algorithm where YOU are the population being flushed out each cycle.

TheStickBoy ( 246518 ) writes:
Re:
Here is the actual model, a model that will exist for the next 1,000 years.

1. Someone (or something) gathers requirement. 2. They get it wrong. 3. They develop the wrong thing that doesn't even work they way they thought it should 4. The project leader is canned 5. The software is implemented by an outside vendor, with all the flaws. 6. The software operates finally after 5 years of modifications to both the software and the workflows (to match the flaws in the software). 7. As soon as it's all running properly and everyone is trained, a new project is launched to redo it, "the right way". 8. Goto 1

You just accurately described a 6 year project within our organization....and it made me cry Does this model have a name? an urban dictionary name? if not it needs one.

alvinrod ( 889928 ) , Sunday August 27, 2017 @04:15PM ( #55094063 )
Re:buzzwords Score: , Insightful)

Yeah, maybe there's something useful in TFA, but I'm not really inclined to go looking based on what was in the summary. At no point, did the person being quoted actually say anything of substance.

It's just buzzword soup with a dash of new technologies thrown in.

Five years ago they would have said practically the same words, but just talked about utilizing the cloud instead of AI.

I'm also a little skeptical of any study published by a company looking to sell you what the study has just claimed to be great. That doesn't mean its a complete sham, but how hard did they look for other explanations why some companies are more successful than others?

phantomfive ( 622387 ) writes:
Re:

At first I was skeptical, but I read some online reviews of it, and it looks pretty good [slashdot.org]. All you need is some AI and everything is better.

Anonymous Coward writes:
I smell Bullshit Bingo...

that's all, folks...

93 Escort Wagon ( 326346 ) writes:
Meeting goals

I notice the targets are all set from the company's point of view... including customer satisfaction. However it's quite easy to meet any goal, as long as you set it low enough.

Companies like Comcast or Qwest objectively have abysmal customer satisfaction ratings; but they likely meet their internal goal for that metric. I notice, in their public communications, they always use phrasing along the lines of "giving you an even better customer service experience" - again, the trick is to set the target low and

petes_PoV ( 912422 ) , Sunday August 27, 2017 @05:56PM ( #55094339 )
continuous delivery == constant change ( Score: , Insightful)

This might be good for developers, but it's a nightmare for the poor, bloody, customers.

Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake.

This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any ) bugs are found and whether any alterations to working practices have to be introduced.

So to have developers lob a new "release" over the wall at frequent intervals is not useful, it isn't clever, nor does it save (the users) any money or speed up their acceptance. It just costs more in integration testing, floods the change control process with "issues" and means that when you report (again, developers: not if ) problems, it is virtually impossible to describe exactly which release you are referring to and even more impossible for whoever fixes the bugs to produce the same version to fix and then incorporate those fixes into whatever happens to be the latest version - that hour. Even more so when dozens of major corporate customers are ALL reporting bugs with each new version they test.

SethJohnson ( 112166 ) writes:
Re:

Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake. This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any) bugs are found and whether any alterations to working practices have to be introduced.

I wanted to chime in with a tangible anecdote to support your

Herkum01 ( 592704 ) writes:
Re:

I can sympathize with that few, of it appearing to have too many developers focused upon deployment/testing then actual development.

However, I come at it from the other side, the developers just push new development out and production support is responsible for addressing the mess, it is horrible, there is too much disconnect between developers and their resulting output creating consistent outages. The most successful teams follow the mantra "Eat your own dog food" , developers who support the crap they push

JohnFen ( 1641097 ) writes:
Re:
This might be good for developers

It's not even good for developers.

AmazingRuss ( 555076 ) writes:
"a new paradigm shift."

Another one?

sethstorm ( 512897 ) writes:
Let's hope not.

AI is enough of a problem, why make it worse?

bobm ( 53783 ) writes:
According to one study

One study, well then I'm sold.

But do you know who likes Continuous Delivery? Not the users. The users hate stuff changing for the sake of change, but trying to convince management seems an impossible task.

angel'o'sphere ( 80593 ) writes:
Re:

Why should users not like it? If you shop on amazon you don't know if a specific feature you notice today came there via continuous delivery or a more traditional process.

Junta ( 36770 ) writes:
Re:

The crux of the problem is that we (in these discussions and the analysts) describe *all* manner of 'software development' as the same thing. Whether it's a desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video.

Then we start talking past each other, some of us terrified what 'continious delivery' means in the context of software in the microcontroller of a health care device, others t

angel'o'sphere ( 80593 ) writes:
Re:

Well, 'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition. Continuous delievery basically only is the next logical step after continuous integration. You deploy the new functionallity automatically (or with a click of a button) when certain test criteria are met. Usually on a subset of your nodes so only a subset of your customers sees it. If you have crashes on those nodes or customer complaints you

JohnFen ( 1641097 ) writes:
Re:
You deploy the new functionallity automatically (or with a click of a button) when certain test criteria are met. Usually on a subset of your nodes so only a subset of your customers sees it. If you have crashes on those nodes or customer complaints you roll back.

Why do you consider this to be a good thing? It's certainly not for those poor customers who were chosen to be involuntary beta testers, and it's also not for the rest of the customers who have to deal with software that is constantly changing underneath them.

Junta ( 36770 ) writes:
Re:
'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition.

It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Developer decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'.

If you have crashes on those nodes or customer complaints you roll back.

Note that a customer with a choice is likely to just go somewhere else rather than use your software.

manu0601 ( 2221348 ) writes:
AI written paper

I suspect that article was actually written by an AI. That would explain why it makes so little sense to human mind.

4wdloop ( 1031398 ) writes:
IT what?

IT in my company does network, Windows, Office and Virus etc. type of work. Is this what they talk about? Anyway, it's been long outsourced to IT (as in "Indian" technology)...

Comrade Ogilvy ( 1719488 ) writes:
For some businesses maybe but...

I recently interviewed at a couple of the new fangled big data marketing startups that correlate piles of stuff to help target ads better, and they were continuously deploying up the wazoo. In fact, they had something like zero people doing traditional QA.

It was not totally insane at all. But they did have a blaze attitude about deployments -- if stuff don't work in production they just roll back, and not worry about customer input data being dropped on the floor. Heck, they did not worry much about da

JohnFen ( 1641097 ) writes:
Re:
But they did have a blaze attitude about deployments -- if stuff don't work in production they just roll back, and not worry about customer input data being dropped on the floor.

It's amazing how common this attitude has become. It's aggressively anti-customer, and a big part of the reason for the acceleration of the decline of software quality over the past several years.

Njovich ( 553857 ) writes:
No

You want your deployment system to be predictable, and as my old AI professor used to say, intelligent means hard to predict. You don't want AI for systems that just have to do the exact same thing reliably over and over again.

angel'o'sphere ( 80593 ) writes:
Summary sounds retarded

A continuous delivery pipeline has as much AI as a nematode has natural intelligence ... probably even less.

Junta ( 36770 ) writes:
In other words...

Analyst who understands neither software development nor AI proceeds to try to sound insightful about both.

JohnFen ( 1641097 ) writes:
All I know is

All I know is that, as a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me and I wish it would die the horrible death it deserves already.

jmcwork ( 564008 ) writes:
Every morning: git update; make install

As long as customers are comfortable with doing this, I do not see a problem. Now, that will require that developers keep making continuous,

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

...

Continuous delivery - Wikipedia



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: April, 23, 2019