12

When explaining DevOps to somebody, it happens that a question comes up like:

How does Release Management using the Agile methodology differ from Waterfall?

So what kind of criteria can you use to explain these differences to such audience?

11

IMO DevOps is culture, much like Agile (without choosing an agile methodology.) Therefore you don't "do" DevOps.

You "do" a release methodology called Continuous Delivery as part of a DevOps Culture. (full disclosure, I don't think I've ever referred to CD as a release methodology before, but in my jetlagged state I think it works)

If you'll buy that, then here's the definition of Continuous Delivery from one of the people who wrote the book by the same title, Jez Humble.

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.

We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.

So then, you can work in an Agile methodology, having software you can demonstrate to the business, making sure you're doing proper automated testing, reacting well the change and all of the things that make it better than waterfall. All too often that doesn't mean you could actually deploy it to production.

You end up with something like this: agile without cd

So the software will (probably) be better when you're done then if you didn't have some sort of iterative approach, but you don't really know because real users haven't ever seen it.

What you really want is something that looks more like this:

enter image description here

Every iteration, something gets deployed to production. So, the software is deployed. If you decide to create downloads, open up the web server, or however you get software into the hands of users it's released.

What the heck!? I asked about DevOps! Nobody asked about Continuous Delivery!!

So what does DevOps have to do with this?

It's very, very hard (approaching impossible) to truly have your software in a state where you could deploy it whenever you want unless that team is working in a DevOps culture. A culture where System Admins, DBA, SREs, Security People, Devs, QAs, etc., etc., are all part of a single team and not siloed part of an organization with handoffs.

Note:

About part of a comment posted to this answer, which was like so:

About your "... software in a state where you could deploy it whenever you want ...": that reminds me about "automatic pilot" software (in a plane) ... My favorite question about that: "Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?".

I love that question (in bold, in the above quote)! The idea of "is it really ready?" is something I rant about all the time - blog. IMO it's vital that you're confident in security, performance and other too often "secondary" tests in order to practice CD. The features are done when they're done, but hackers are always there.

  • Thank you for your interesting viewpoints/answers (and shiny images ...). I must admit I never heard about the term Release Methodology, though Release Management is what I'm pretty familiar with (for over 2 decades ...). About your "... software in a state where you could deploy it whenever you want ..." (combined with the "jetlagged"): that reminds me about "automatic pilot" software (in a plane) ... My favorite question about that: "Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?". – Pierre.Vriens Mar 4 '17 at 17:27
  • 1
    I love that question! The idea of "is it really ready?" is something I rant about all the time - blog. IMO it's vital that you're confident in security, performance and other too often "secondary" tests in order to practice CD. The features are done when they're done, but hackers are always there. – Ken Mugrage Mar 4 '17 at 17:40
  • 1
    I was referring to - "Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?" – Ken Mugrage Mar 4 '17 at 17:45
  • And please edit away, I'm a n00b here :) – Ken Mugrage Mar 4 '17 at 17:46
  • Please review my suggested edit, to integrate your interesting comment also. If you don't like it, just perform a rollback to the prior version (link is within "revisions"), and/or further improve/extend it as you like. Guess what, it seems that "inflight" some of my "permissions" got changed ... looks like I have too much rep already here to still need "approvals" for such suggested edits ... lucky us this is just some SE-software (not a suggested update to some route of a flight without prior approval from air traffic control ...). Oeps 2 (correction): it got approved at light speed ... – Pierre.Vriens Mar 4 '17 at 17:57
2

Not sure if there aren't any others, but these are the criteria I use:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

And if you really want to experience the difference yourself as a user of some software, then think of using some software (like a Linux distribution), where you have a choice between using either of those releases:

  • a "Rolling" release (==> Agile).

  • a "Long Term Support" release (==> Waterfall).

  • 1
    The Linux example might not be very inspirational :) Personally I dislike the rolling releases because of: 1. the quality level and 2. the rather distracting changes (I prefer to focus on my work, not on the linux I'm using for my work). So I use the long(est) term ones (often way past their EOL) and only focus on a major update once every 2-3 years. Unless this is just increasing adversion to change due to aging? :) – Dan Cornilescu Mar 5 '17 at 7:39
  • @DanCornilescu I used this Linux example because I think it is an extreme example of "a" release mgnt aspect (ie the frequency of releases) for both methodologied. Though "personally" I fully agree with your disliking of rolling releases, for the very same reasons you mentioned. – Pierre.Vriens Mar 5 '17 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.