Is DevOps restricted to companies with SaaS products?

Question

The practices describing DevOps, such as continuous delivery, automation, etc. are relevant to products that provide continuous service, such as SaaS products.

For example, a software development company that mostly does projects for other clients might never be maintained these after the project is over. And client projects are not shared with other clients, because irrelevant.

Does DevOps even apply to companies who develop multiple projects that are one-offs? What DevOps practices apply in this case, if at all?

Answer 1

Absolutely not!

DevOps is all about breaking down the traditional silos (departments) in order to be more efficient.

Better communication between teams, improved visibility and reliable and automated process are ways to achieve a better product.

I used to work for a big media company where we would support an internal tool and develop public-facing websites.

The benefits of DevOps in our case were the following:

• Through continuous building, we let know the development team earlier rather than later if there are integration or build problems with their code. They can fix issues while their mind is still on the piece of code they just committed.
• Through continuous testing and delivery (into QA), we enabled the QA team to find problems earlier and report them earlier. This reduced the time it took to find and correct bugs as well as reduce the complexity of these investigation.
• With out log collection & aggregation tools, we gave to the developers access to something they wouldn't usually look at (they were very keen on the debuggers :) - understanding how logs are seen and used by other teams improved the overall quality of logs
• We often shared information and created documentation to share knowledge between teams, trying to break down walls. By understanding the Ops' needs, we create a few guides for what should always be kept in mind when bootstrapping an application (where/how to manage properties, etc.). By understanding the Dev's reality (code more features, faster, gogogogo!) we were able to have the ops create servers and clusters that were better suited to the dev's needs.
• The overall quality of deployments was greatly improved too. Deployments were handled by our team, so we had perfect visibility on both Ops and Dev. This eliminated many issues related to the "code hand-off" where the dev would hand over a package and one-page document to the ops saying "Install this!".

Overall, I would say that regardless if you are updating your production environment once per day or once per month and regardless of how many customers you have or your business model, every enterprise can use better communication, better tools, better visibility, faster feedback, etc.

Answer 2

My team and I are responsible for developing "one-offs", products that once finished are given to the client for upkeep or in some cases managed by us for a fee.

We still need to maintain a solid development pipeline to handle the constant feedback from our clients in order to ensure that we ship them something reliable and proven to run.

While the client doesn't care about DevOps (in most cases), it is still helpful for us. With DevOps, we can rapidly push new builds, so clients can see feedback in minutes not hours, and we are also able to catch any errors/bugs with our testing via Jenkins/Travis.

To ensure our deployment strategies are the same across projects, we focus on containerizing our applications. Using Docker, we are able to easily hand off the application to our clients.

The cost saved by DevOps is hard to determine. We do have extra costs in the form of software we choose to use for the pipeline (Travis, Jenkins, Puppet, what have you), but we also save time and money by fixing bugs/ giving the clients feedback quickly. Our quick response time keeps our customers happy, in turn, keeping our wallets happy.

Answer 3

The activities on the development and implementation of software previously did not require deep integration between the departments. But for today it is necessary to closely cooperate all departments (Development, IT Operations, Quality Assurance, etc.).

For developers, change is what they get paid for. Business always needs changes to match the modern world. This understanding pushes developers to produce the maximum possible number of changes. IT professionals have a different understanding, in which change is harm. Each of them thinks that it works correctly, benefiting the business. Indeed, if we consider them separately, they are both right.

All employees must understand that they are part of a single process. DevOps cultivates thinking, which makes it possible to realize that the personal decisions and actions of everyone should be directed towards the realization of a single goal. And success should be measured relative to the entire development-to-delivery cycle, and not from the success of individual roles. As a result of close cooperation between developers and maintenance specialists, a new generation of engineers is formed, which take the best achievements of both disciplines and combine them for the benefit of the user. This is manifested in the appearance of cross-functional teams with experience in development, configuration management, database management, testing and infrastructure management.

So the methodology is useful not only in SaaS.

Answer 4

I've worked for companies producing software as shrink-wrap products, as fully installed and supported deployments and as embedded code in devices. In all of those companies, DevOps provides essential support for development:

• Automated, reproducible builds of software, with known, controlled configurations of compilers, libraries and other build tools.
• Automated, repeatable system tests for regression testing and for new functionality tests.
• Other automated and regular actions (for example, continuously updated sample screen shots available in all supported languages, for translators to verify and for technical authors to incorporate into user manuals).

In all cases, these are things that individual developers could do as one-offs, but that would not be good use of developer time, nor have the same assurance of configuration control that the automated builds have.

Answer 5

Not at all. While there are already great examples on this thread, I'd like to share an anecdote of my own. In 2001 I inherited a software project with a release that involved the creation of a CD. The documentation for the release process included 40(!) steps documented by a previous engineer, that included some ridiculous hand-written instructions like "open this config file and change the name of the .jar file on line 41 to include the version number of the new release".

We aggressively automated every step of that build process, replacing hand written instructions like that with things like 'patch' scripted with bash. We even had to open tickets with our third party install-tool vendor to make their project files patchable.

Once that process was automated, we bought a 'CD Jukebox'. Every night after the tests would pass, the build machine would automatically create a new install CD. Our testers could come in the next morning, grab a disk, and make sure everything was installable.

We certainly have tighter feedback loops when we can deploy software as a service, but the core principals of automation, feedback, cycle time, small releases, etc. all apply.