I have seen many people coming up with different definitions of what 'DevOps' is. So in this case I invite you to define your take on what 'DevOps' mean so that others can give answers from the right angle.

I'll assume that DevOps means testing, integration and automation before release.

Assuming that your managers are old-school, but technically oriented people (they have been developers themselves at some point), convincing them means clear demonstration of benefits of switching to a continuous integration system.

It is safe to assume that technically oriented people are more easily convinced by something that 'works'. This is important, because you will need to convince people that the yield on returns from the amount of energy & frustration put into some additional complexity brought by continuous integration is rightfully justified.

How do you do the above? You take an essential algorithm/portion/routine from the project and start converting it to tested + integrated sum of lower order functions. Next you need to nail a bug/challenge that your old-school colleagues could not tackle.

Surviving in the competition has many many parameters, which I think one should carefully consider:

If your team has additional funding and man power:

• fork the project and allocate a group of developers that slowly builds a 'DevOps' version of the entire project.

If your team has limited-additional resources:

• partition the project into smaller parts where 1/2 developers start to convert those smaller parts into a 'DevOps' version

If your team has no extra resources and under pressure by live and ongoing project:

• You are treading on thin ice here. Implement additional features the 'old fashion'. Try to generate more revenue before you upgrade so that you have reserves in case things don't go well. Do not forget:

'You don't switch the horse while crossing the stream'

Hi PavanKumar Belagatti Anyways every one wants things should be automated or moving smoothly without any disturbance. And some how DevOps helps to deliver both the facility. Only challenge is you might have to put some effort to present a strong POC (Proof of concept) where you can justify that if DevOps is there we can save time or we can automate the process, or we can share quality build. So if you are able to justify your POC i'm sure any manager will be happy to see that he is able save lot of time. But of-course for POC either you have put additional effort for few days or you have to ask them to provide you a cutshort dedicated time. And best way of POC will be take some existing module where you feel you can do some automation so it will be broadcast as a real time example. Again i'll say DevOps is a process and philosophy so while doing POC mark both of stuffs.

I'm not sure how you can sell them on DevOps in particular, but there's an entire category of 'best practices' where the cost for prevention is way smaller than the cost of even a single mistake. I think DevOps is one of those things. Don't look at it in terms of saving time or money, but rather insurance against much more expensive liabilities. Part of DevOps is "risk reduction" as well, and things like 'liability', 'reducing risk' speak to executives and business owners because they understand their own numbers, even if they don't understand how you'll be reducing that risk.

I'd focus on Return On Time Investment (ROTI) and making it as little effort as possible for them.

Rather than convincing them of the benefits, you need to address their concerns. The classic "if this then this" quote. => "If I address your concerns, until you are happy, then will you allow me to implement this?" Then if they still have concerns then go to other managers.

You don't even have to call it devops, dumb it down and say what you want to do to one system and see if that works, if one works, then move on to the next and before you know it you'll be a devops culture without actually knowing it. :)

Could also have a read through the internet to see if other people also have concerns about devops and how they were handled.

Hope this helps.