28

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?

Improve this question

5 Answers 5

Reset to default
32

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.

Improve this answer
3
  • 1
    Indeed, DevOps can be applied to virtually any sw development organisation, even to large embeeded products with just a handful of public releases per year - by using continuous delivery inside their development pipeline they can still reap some DevOps benefits: better quality, cost reduction, release predictability, etc.
    – Dan Cornilescu
    Mar 1, 2017 at 4:59
  • The answer does remind a SaaS, doesn't really explain well how a non-SaaS product or service can benefit from these practices.
    – Evgeny Zislis
    Mar 1, 2017 at 5:18
  • The products I was working on weren't SaaS (quite the opposite). But the rationale stays the same, it doesn't matter much if you are SaaS or not, DevOps try to improve the product in non-traditional ways. I could know nothing of our pricing model or offering, it would not make that much of a difference.
    – Alexandre
    Mar 1, 2017 at 5:23
13

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.

Improve this answer
5
  • Can you provide some reasons and benefits of why this is important? Do clients actually care about your pipeline, or just the finished project at the promised date and the price they need to pay? Could you cut costs by not doing all these "devops-y" things? Could you get more hours into a project byt not doing these things and get more money for the projects (since it is longer)?
    – Evgeny Zislis
    Mar 1, 2017 at 4:01
  • 1
    @Evgeny DevOps helps finished the project on time and on budget for reasons explained in my answer. By cutting on DevOps, you would also cut on the benefits I explained. Building and testing often help staying in budget and on time. Finding a bug later cost more money and takes more time to fix, it has been proved over and over. The client doesn't care about the pipeline, but the longer you wait for his feedback, the more costly and time-consuming the rewrite will be.
    – Alexandre
    Mar 1, 2017 at 5:47
  • Isn't it just Agile Software Dev?
    – Evgeny Zislis
    Mar 1, 2017 at 5:55
  • @Evgeny I have updated my answer to clarify. We do use Agile, but that doesn't mean we can't have a DevOps mentality..
    – Turtle
    Mar 1, 2017 at 14:51
  • 1
    @Evgeny you could probably save some by not upkeeping your unit tests and acceptance tests, but this builds up Technical Debt which is a DevOps anti-pattern. You might get away with it for a few weeks or months, but you'll soon end up (probably) with a difficult to maintain mess which is impossible to test.
    – Steve Button
    Mar 1, 2017 at 17:25
3

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.

Improve this answer
1
  • Automation is not devops. Same comments as David Bock's answer below finally (sorry, my comment was lost at time I downvoted, just noticed it)
    – Tensibai
    Mar 7, 2017 at 15:59
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.

Improve this answer
0

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.

Improve this answer
5
  • This is automation related, but not related to a devops organization in any way, I see no reference about plury discipline team anywhere, just ops automating things they inherit
    – Tensibai
    Mar 2, 2017 at 19:23
  • This was 2001... long before DevOps was a thing. This was not just automation, I believe this streamlined the management of the project in exactly the same way that eventually became labelled the 'Culture' of DevOps. As such, it is an example of DevOps attitude outside of a SaaS organization.
    – David Bock
    Mar 3, 2017 at 15:37
  • DevOps is not about automation, nor project management. It's about breaking silo based organization at root. I'm sorry I don't feel this answer really relate to the Question (this doesn't mean its uninteresting, but just not at the right place IMO, and I don't see where it could be in place actually, may come later)
    – Tensibai
    Mar 3, 2017 at 15:45
  • I'm gonna try one more time to clarify - by having the CD cut so consistently and quickly, we could get feedback from QA much more quickly than we could have before. This reduced a silo. It didn't eliminate it, as it took another year or two before we disabled the fiefdoms around centralized budgets for activities, but it certainly was a critical step in makig that happen. We also knew much sooner when the release process was broken. I credit many little things like this as my personal path to DevOps.
    – David Bock
    Mar 8, 2017 at 19:32
  • This last comment bring more sense to this answer under this question, you should edit to include it , I still feel this doesn't fit this format, but it seems my position is wrong when I observe the overall evolution in this private beta, so... that's up to you. I can't remove my downvote without an edit for information
    – Tensibai
    Mar 8, 2017 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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