4

I'm trying to learn more about the DevOps trend and what DevOps actually is, and how it could apply to my situation (recently fuelled by the Stack Overflow survey results starting by mentioning DevOps). All my research so far points to things like under DevOps, developers assume responsibility for deployment and automate it.

I believe I understand the principles and their benefits in scenarios where the software is a running service (such as an information system or website) managed by the company developing it. However, none of the descriptions I've read so far (on Wikipedia or top Google hits) mention DevOps being limited to situations like this, so I assume it's supposed to be applicable universally.

I cannot understand how the principles would apply in a situation where a team/company develops offline desktop software which is bought, downloaded, and installed by its customers. The only involvement of the developing company is to host the installation packages on its website.

In this case, would the "deployment & operations" part of DevOps be limited to packaging the installer and copying it to the download area, or is there something I'm missing?

None of the articles about DevOps which I've read so far touched on this model of software development. Is this something where the DevOps principle is applicable, and if so, how?

Angew is no longer proud of SO
  • 372
  • 2
  • 12
  • In the SAFE course I followed they use a system called 'Release on Demand' next to Continuous Deployment. At every time, you must be able to create a release. But you don't have to. – Carra Mar 13 '18 at 16:27

2 Answers2

6

Lets start by separating out a few terms:

DevOps

A movement to bring Development and Operations together to help break down the barriers between departments and share skills and knowledge. Closely linked are:

Continuous Delivery

The continuous delivery of value. This is often managed as part of something like a scrum framework to constantly add business value into the product rather than creating huge monolithic releases. In its simplest terms this comes down to things like "Develop in Master" approaches and Continuous Integration.

Continuous Deployment

Continuous Deployment is the next logical step from Continuous Delivery. If code is automatically build, deployed to test environments, AND automatically tested through automated tests then why can't it be continuously integrated into a live environment to get REAL feedback from users and using this knowledge quicker?

So is DevOps limited to packaging the installer and copying it to the download area?

One of the key goals of these principals is trying to minimise the cycle time between you writing the code and that code being executed by your customers. There are many reasons why this is good including:

  • Faster deployment of fixes
  • Faster feedback on the quality of releases
  • Smaller incremental (and perhaps more importantly less detrimental) changes

If I was you I'd look at the time it takes for the various steps involved in deploying to your customers. How long does it take to get from your Dev box to build? To deploy to to Integration? To deploy to QA? To publish to the download area? Or to push to a customer's devices?

Get real numeric values for these, don't guess them!

I'd suggest that the longest lag you'll face is the amount of time it takes customers to download and install a new version once you've deployed it to your download area. That's going to be what's be the biggest wait you'll face when you're wanting a customer to update...

The logical conclusion?

TLDR

I would suggest that the biggest improvement you can make to your deployment process would be to automate it by providing an automatic update mechanism so customers don't have to do anything to update.

However, development is not about guess work! Find out what slows down this pipeline and use REAL data to make these conclusions for yourself!

Liath
  • 3,406
  • 1
  • 21
  • 33
  • 1
    +1, if not familiar then have a look at concepts like Lean and Value Stream Mapping in order to understand how to investigate the parts of your pipeline and analyse data. – f1dave Mar 14 '18 at 11:44
2

With packaged installable software the "Operations" part of DevOps still has two important jobs beyond the packaging of releases:

  1. Delivering updates to the users
  2. Getting useful feedback about user problems

For 1. there is nowadays no excuse for your software not being capable of updating itself automatically. Which requires a server infrastructure to deliver those updates.

For 2. your job is even more complex and tricky than with software running on servers you control, but you also have enormous potential for improvement over how things used to be done. Instead of putting the entire burden for useful bug reports on end users (which means you will get basically none), you can integrate a bug reporting facility into the software that will send you whatever useful context information you might need (though this can get very tricky in regard to privacy legislation!).

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176