Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Software

Time To Move on from DevOps and Continuous Delivery, Says Google Advocate (zdnet.com) 116

Posted by msmash from the perspective dept.
A reader shares a report: Continuous improvement and continuous delivery (CI/CD) and DevOps may be on many peoples' minds these days, but there's nothing particularly new about the concept -- software shops should have put these concepts into action years ago. Instead, technology leaders should be now worrying about the futures of their businesses. That's the view of Kelsey Hightower, staff developer advocate at Google Cloud Platform, who says too many IT leaders are debating how to manage IT operations and workflows, when their businesses are being hit with unprecedented disruption. "CI/CD is a done deal -- like 10 years ago it was a done deal," he said in a recent podcast with CTO Advisor's Keith Townsend. "There is nothing to figure out in that domain. A lot of people talk about DevOps, and there may be some culture changes, in number of people who can do it or are allowed to do it. For me, that is the table stakes. CI/CD, DevOps; we have to say, listen, figure it out, or go work with another team outside this company to figure it out."
This discussion has been archived. No new comments can be posted.

Time To Move on from DevOps and Continuous Delivery, Says Google Advocate More

Time To Move on from DevOps and Continuous Delivery, Says Google Advocate

Comments Filter:

  • heads were removed from anuses (Score:5, Insightful)

    by Anonymous Coward on Friday October 27, 2017 @03:50PM (#55446969)

    So somewhere along the way people figured out again that quality of software is more important than the speed in which new features are pushed out the door.

    I guess the cranio-rectal inversion over devops crap is finally coming to an end.

    Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.

    • Re: (Score:3, Funny)

      by omnichad ( 1198475 )

      Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.

      Nah - caching/boost server on premises. So you can have a thin cloud server to go with your thin clients.

    • >> next will be when everyone moves their stuff to an "internal" cloud

      You giggle but this is actually a theme in corporate America. Typically it's the legacy VMware team that rebrands itself as the internal cloud, but I've also seen an attempt or two to build out a new virtualized stack on top of Xen or the like. It's even kind of real for teams that virtualize at the container level.

      I'm just happy to not have to pay for this stuff myself. It seems most companies are currently losing their shirt on
    • Nope, turns out this person is arguing for software quality. They think CI/CD is settled in the sense that it isn't going away, stop trying to change it, move on to other things like the latest buzz words. I believe CI/CD is what has made software shit these days. Companies start by promising x number of features, and rush it out the door after x-y>0 features are partially done, then CI/CD with users as their beta testers. You no longer have a finished version and solid piece of software, and no way to stick with a particular version, which is especially true on the walled garden of iOS. Gone are the days of a solid product coming out that stands on its own for years without the need for anything but occasional security updates.
      • You can say "we practice continuous deployment" without saying "to production servers." CI/CD is about your development branch never getting so shitty that the average engineer can't do meaningful work on it. Or, the other thing that used to happen: make a bunch of components and then try to stitch them together at the end; act surprised when nothing works.

        • I work in automotive embedded and I can't wait to get our CI server up and running. I think a lot of people forget what the 'good ole days' were like.

          We'll have people working on their own branches and then on Friday merges we have the whole thing fall apart. Meaning people don't have binaries to test until at least Saturday. Then the whole process starts over. ClearCase being a cluster doesn't help.

          • Re: (Score:3)

            by Junta ( 36770 )

            Of course with CI, you can still have this phenomon. This is about midnset and developer strategy, You can still have developers sitting on their private branches and at the last minute end of conflicting with each other. Of course a sane process says they get to sit that week out, but in all likelihodd, one of those has some change that simply "can't wait" even a week, so the whole train gets held up despite the sane thing of punting that developer work for a week,,

            • Absolutely. But the "CI" part helps to automate it. Our builds are in the ~50 minute range. Individual developers build on their own machines. There's no 'safe' build machine. At least with a CI setup they get immediate "You broke it dumbass" feedback.

              • Re: (Score:3)

                by Junta ( 36770 )

                I guess I've been blessed in that I've never worked in a team that wasn't naturally continuously building and testing their changes. I couldn't imagine being more than a few minutes of being able to see the result of my work. So for me, CI comes into novel play only when merge requests happen that start exposing subtle conflicts between privately worked branches of work.

                I suppose I could imagine someone spending a long time without even building and testing, but on the other hand I can't imagine that will

        • Re: (Score:3)

          by Junta ( 36770 )

          CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks.

          Also, while CI isn't in and of itself a bad thing, it does encourage a lot of organizations to skimp on vluable QA, made overconfident by misleading phrases like '100% test coverage' and deciding that means they automated the need for QA.

          Also, by the same mistaken thought, they don't need maintenance branches anymore because the first release was necessarily bug free because those unit tests passed, so no need to think about

          • Comment removed based on user account deletion

            • 100% test coverage is easy, with unit tests. Which are close to meaningless.
              Interesting is 100% code coverage with acceptance tests/ui driven tests/integration tests.

              • Re: (Score:2)

                by AuMatar ( 183847 )

                Still meaningless.

                if(A) {
                  foo()
                }
                if(B) {
                  bar()
                }

                You can have 100% without testing the combo of foo and bar. WHich could break everything. Code coverage numbers just give a false sense of security.

                • Depends what you conclude from them :)
                  100% coverage is certainly better than 50%.

                  Coverage is important for future refactorings, less for the quality of your actual tests. I'm not a big fan of code reviews, but tests I always review or insist that they get reviewed.
                  For Java there are byte code moephing tools that that exchange all test operations by its counterpart. If your tests are 'somewhat good' all should fail after morphing.

                  • Re: (Score:2)

                    by AuMatar ( 183847 )

                    No it isn't. 100% means every line is run once. That 50% case may only run part of the code base, but it may cover a subsystem completely with all combo of options. I'll take the second over the first. Which is why code coverage numbers are worthless. We have no idea which of those two situations it is based on the numbers.

                    • I don't understand what you mean with your 100%
                      How can a line of code be run only once without covering all options that lead to running it?

                    • Re: (Score:2)

                      by AuMatar ( 183847 )

                      Because the 100% measures lines independently. It doesn't mean that combinations of branch statements/loop iterations are tested. Without which, you claim to be testing 100% but are really testing some unknown but much lower percentage of actual code paths. Just running each line once has 0 actual value, it doesn't mean the code is well tested. I would rather have a suite that actually tests some subset of the code exhaustively than a suite that runs each line once and claims that everything is perfectl

                    • You make no sense, sorry.

                      If you have 100% code coverage, you have 100% coverage of all "if's" "else's" and "loops", too.

                      Or how do you think I magically test a line in the middle of an if block without testing the line with the "if"?

                      I would rather have a suite that actually tests some subset of the code exhaustively than a suite that runs each line once and claims that everything is perfectly tested.
                      What is the point of testing the same line of code multiple times with different tests? Unless: it is an "if"

                    • Re: (Score:2)

                      by AuMatar ( 183847 )

                      You're either not trying, or you're a really bad programmer. Let's try this:

                      if(x) {
                      //enable Feature A
                      }
                      if(y) {
                      //enable Feature B
                      }

                      What if Feature A and B are incompatible. Turning on B and A at the same time breaks the entire app. The fact we can try to enable both at the same time is a bug.

                      You can have 100% code coverage without ever testing what happens if x and y are both true, by testing x=true y=false and x=false y=true. You would then test each line, and say you had 100% coverage. But you would

                    • I would say, you are super bad in explaining.

                      No, I don't get it.

                      The above code you test with
                      x,y = false, false
                      x,y = true, false
                      x,y = false, true
                      x,y = false, false

                      What is wrong with that?

                • Comment removed based on user account deletion

          • "CI isn't such a bad thing, but CD tends to mean 'to production' for a lot of folks."

            That's because it's either "to production" or it is not CD at all.

            Of course, "to production" may mean different things to different people. For a VAR/COTS mill it means, "that's what we are going to sell to our next customer", for an internal team, it will mean "deployed and tested to our production servers" but, still, "delivery" means "delivery"; if it's not delivered, then it can't be D, continuous or otherwise.

            "Also, w

            • Re: (Score:3)

              by Junta ( 36770 )

              The curse of all of this is that good teams have always naturally done things that lead to good product, and then some folks comes along to try to 'distill' out the magic of those successes into useless aphorisms and make a consultancy industry out of it. Complicated by ditching the unprofitable pieces (for example the agile manifesto among other things stressed communication rather than processes and tools, but an Agile consultant will ditch that and focus on tools and processes because they can make mone

              • "The curse of all of this is that good teams have always naturally done things that lead to good product, and then some folks comes along"

                Not "some folks", but "some folks with authority", aka "management". Of course, everybody can impact a project/service/product/whatever but, of course too, the higher the individual in the corporate ladder, the higher his impact on the results. And it's my opinion that if the average level ot IT people is lame, the higher you climb the corporate ladder the more unfit fo

      • CI means continuous integration, not improvement.
        It is automated build and automated test of a piece of software as soon as the source code repository changes.

        In other words: it is an QA measure,

        CD means that software is either promoted in form of binaries into a staging repository or deployment on test servers.

        A better way to ensure software quality we don't have right now.

        If your CI/CD does not deliver perfect quality software, then either your developers suck and write bad tests, or the integration tests

        • What the hell is integration? It is so 1990s buzzword but I do not know what it means. It sounds like an excute to only buy from Microsoft or something as it works together if I recall PHBs using integration constantly.

          QA is going away thanks to Agile development. That is why Microsoft has no QA at all whatsoever with Windows 10. With Agile/Scrum the developers and users do the QA with happy faces/sad etc.

          • QA is going away thanks to Agile development
            This is kind of an oxymoron. QA, especially automated testing is the corner store of agile methods.

            With Agile/Scrum the developers and users do the QA with happy faces/sad etc.
            What is that supposed to mean?

            • I think he means the feedback system with emoticons that some beta Microsoft products sported.

      • Nope, turns out this person is arguing for software quality. They think CI/CD is settled in the sense that it isn't going away, stop trying to change it, move on to other things like the latest buzz words. I believe CI/CD is what has made software shit these days. Companies start by promising x number of features, and rush it out the door after x-y>0 features are partially done, then CI/CD with users as their beta testers. You no longer have a finished version and solid piece of software, and no way to stick with a particular version, which is especially true on the walled garden of iOS. Gone are the days of a solid product coming out that stands on its own for years without the need for anything but occasional security updates.

        Funny I thought CIO's were about labeling IT as a cost center with a focus on saving. Or better yet being eliminated by having ther HR or finance department run IT who get bonuses by outsourcing to the cheapest country as possible and using 10 year old software and never updating as that is out of the contract with TATA.

        Call my cynical and perhaps this has changed from last decade and the last recession but that is how I remember it.

    • Just like when people moved off of timeshare mainframes to computers on premise.

      Good God, have you not been in this industry long? This kind of tick tock is literally the name of the game. Be ready in sixty years when everyone touts whatever they call cloud in 2080.

    • Comment removed based on user account deletion

    • Next will be when everyone moves their stuff to an "internal" cloud. Just like when people moved off of timeshare mainframes to computers on premise.

      Actually this already happened. A few weeks ago our salesman happily reported that a customer would be storing data in their 'private cloud'. I've seen that private cloud; it happens to be on-site at the customer premises. It looked a lot like a server rack to me...

      • "I've seen that private cloud; it happens to be on-site at the customer premises. It looked a lot like a server rack to me..."

        Do you think a public cloud looks much different than a server rack, only on other's datacenter?

        • No, but why would you call a server rack a "private cloud"? What weird, pretentious nonsense is that?

          • "No, but why would you call a server rack a "private cloud"? What weird, pretentious nonsense is that?"

            The pretentiousness, if any, is not in the "private" part, but in the "cloud" one.

            I've been in the "cloud thingie" basically from the beginning and I've seen how the term has derived from something quite significant to the vague term it quite quickly became but then, if it allows for self servicing on demand of IT resources (mainly infrastructure, but everything above can also work), then I certainly call

    • Re: (Score:2)

      by zifn4b ( 1040588 )

      So somewhere along the way people figured out again that quality of software is more important than the speed in which new features are pushed out the door.

      The company I work for seems to be in its death throes with a person leaving the company every week. They have just now started to get a clue that low software quality has a relationship to losing your customer base and escalated support issues and consequently your reputation as a software vendor. The thing that I see neglected the most in software companies is subject matter domain knowledge. If you don't know what your software needs to do, you can't communicate that to the people that build it and th

  • Uh Huh (Score:1)

    by Anonymous Coward

    I have yet to see to a CI/CD shop actually implement this in such a way that people can safely commit away.

    I'm sure life is easier when you don't actually have customers that care about state or you just shit on your customers continuously. Google wins on both counts here!

  • But the testing goat said... (Score:1)

    by Anonymous Coward

    I just started reading "Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript" [amazon.com] by Harry J.W. Percival. Now CI/CD is obsolete.

  • I've always felt that integrating and keeping up to date test automation processes as the greatest challange in the CI/CD space. As business cycles get shorter, creating and maintaining the required set of test automation processes that can give you confidence in the final production release can be an immense challange. This together with the increasing complexity of cloud based systems has made the testing challange a really hard nut to crack.

    • While I agree with you that good test automation is challenging, I would say that it is no worse than on-premise product development. Effective testing requires engineering commitment to make test automation development co-equal with product development. It is an immense challenge. BUT, having worked CI/CD for both an on-premise product and a cloud-based (AWS) product, cloud seemed easier. If for no other reason than it is much easier to manage the equipment.
  • Here is a quote from the author:

    Now your customers say, 'where's your mobile app? I want to be able to have voice assistance to talk to your particular product.'

    Is that really true? I thought apps were mostly a dead end now, and everyone is just writing for the web. Do people really want voice recognition in apps?

    • No. Companies like Google WISH people wanted voice recognition. It is another data point they can collect and track. Voice recognition is like VR: a technology that no one wants.

      • Re: (Score:2)

        by Junta ( 36770 )

        I want and use my VR. I'm very sad if it fails to take off more than it has.

        Voice recognition on the other hand.. Meh

    • Re: (Score:2)

      by JustNiz ( 692889 )

      Meh, writing for the web is soooo 10 minutes ago..

  • By Neruos (Score:1)

    by Anonymous Coward

    "With Amazon Lambda and other microservices, you just need HR to hand out IAM accounts, and a company really doesn't need an IT staff whatsoever. Just some CI/CD mechanism to get pushes in production, and that is basically it.

    Ops is dead. Who needs to rack and stack physical servers when the cloud takes care of that, and far cheaper. Who needs OS guys, app guys, net admins, and DBAs when serverless services replace all this?

    Lets be real... the future is NoOps. Pay your Amazon bill, and they take care of you

  • . . . because, sooner or later, DevOps HAD to no longer be the New Hotness. . . Of course, the question is. . . what comes next ?

    • sooner or later, DevOps HAD to no longer be the New Hotness. . . Of course, the question is. . . what comes next ?

      I think the time has come for MangeOps - A software engineering practice that aims at unifying management (Mange) and software operation (Ops)

      The goals of MangeOps span the entire business pipeline. They include:

      • Improved customer complaints frequency
      • Faster time to failure
      • Higher failure rate of new releases
      • Shortened lead time between critical breakages
      • Faster mean time to market speak recovery (in the event of a new release crashing or otherwise disabling the current system)

      MangeOps aims to minimize the pre

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close