-1

Like many IT departments, we have numerous Developer teams, and DevOp teams.

Recently, our .NET Development Team just completed an application based on .NET 3.1 that took around a year to complete.

We were excited to coordinate with the DevOps team in question in order to deploy said application to the UAT environment.

Unfortunately, as we were making progress with deploying said application, the DevOps team Management Stopped us because they said that .NET 3.1 is No longer supported by Microsoft. Therefore, they said that inspectors/auditors would Raise serious concerns about having Unsupported technologies deployed to production environment.

The politics behind said incident seemed to sort of suggest that the DevOps team put the blame on our .NET Development Team for failing to know that the .NET 3.1 is No longer supported by Microsoft.

As a member of the .NET Development team, I just felt like we took too much of the blame.

What kind of management techniques/processes/procedure could have been put in place in order to prevent said setback incident?

1
  • This question is probably going to be removed, but while we're discussing it, I might point out that this has nothing to do with the DevOps process itself, but is squarely on the product owner. Dev teams build the spec they're given, and the spec was terrible if they started with .Net 3.1 and it took a year to complete. Mar 17 at 12:55

2 Answers 2

1

Part of the problem is that you do not have a DevOps mindset. You don't have "DevOps teams" - there's no such thing. DevOps is a set of values and principles that build upon Agile Software Development. A key principle of Agile Software Development is that "business people and developers must work together daily throughout the project". DevOps expands this to tear down silos that existed between development teams and operations teams and to move operational considerations earlier in the system development life cycle, which is sometimes referred to as "shift left".

I can tell that you don't have a DevOps mindset because you didn't find an operational concern until before deployment to a UAT environment. If the use of outdated and unsupported tools and technologies is a risk, I would expect that to be moved earlier in the process, even into requirements. You would have specific requirements around deploying only supported dependencies, and perhaps have accepted deviations in place if there are technical reasons why it is not possible. Part of the DevOps culture is a culture change to move toward automation, so I would expect static analysis and dependency analysis tools to be in place and warn if there are third-party dependencies that contain known vulnerabilities or are end-of-life to allow the teams to take appropriate action.

So if you really want to prevent this type of problem, I would recommend actually looking at the DevOps values and principles. Get your operations specialists involved in your system requirements and find ways to build quality into your product, likely through automation.

2
  • Thx. There is little bit of the political blame game going on between the Operations & Dev teams. Could you please post some online resources' urls relating to "static analysis and dependency analysis tools to be in place and warn if there are third-party dependencies that contain known vulnerabilities or are end-of-life to allow the teams to take appropriate action"?
    – crazyTech
    Mar 16 at 19:24
  • 1
    @crazyTech I don't feel like finding or recommending tools is appropriate. That's enough information for you to start searching. You could also try "composition analysis". But this question isn't about tools, but mindset and culture shifts. Tools need to support that culture shift and providing specific references here would, in my opinion, detract from the importance of that cultural shift. People and interactions before processes and tools. Mar 16 at 20:36
1

There are some DevOps capabilities that would really help your situation.

First a foremost, the original idea behind DevOps is that developers and operations collaborate the whole time. If you have a development team working in isolation of the operations team, it's definitely not DevOps even if they have been named "DevOps".

Let's get into some capabilities. I'm going to hand pick some specific techniques and practices that I think would really help future work in your organization.

Culture: Westrum organizational culture

Quite a lot of your original question involves blame. DevOps really needs a generative culture. That means a blameless culture with high psychological safety. You need to build trust, maximize learning, and aim to have people who are satisfied they can do good work.

This is one of the top-predictors of successful outcomes.

You may not be in a position to re-wire the organizational brain, but you can definitely make an impact with how you respond to your situation. Rather than looking for someone to blame, work out how you can collaborate with those other teams to get better results next time. A bit of empathy and relationship building will go a long way.

Lean product development: Work in small batches

If there is one universal lesson that came out of phased software delivery, Agile, Lean, and DevOps... it's work in small batches.

Imagine you had created a minimal .NET application in the first week. It just has one API endpoint that returns "hello world". If you delivered that version of the application you might have found out about the .NET version issue a year earlier.

Imagine the difference in finding out a year ago, rather than when you are about to go live. The situation wouldn't have blown up as the pressure to get things live is adding pressure.

Working in small batches would also mean having a deployment pipeline that you and the operations team had confidence in as you would have been deployment every week for a year.

Technical capabilities: Continuous Delivery

This is really a number of capabilities all bundled together - but they are highly inter-related. Frequent integration of code into the main branch and an automated deployment pipeline that make your code "always ready to deploy" are a great way to remove the stress from software delivery.

In your case, building the deployment pipeline would have meant collaborating with the ops team earlier and finding out what kind of governance, risk, and compliance needs they might have.

A good build process and automated deployments will boost your levels of joy. It will also enhance confidence in your team if you can make this area pain free.

Capabilities everywhere!

You can explore more capabilities on the DORA research site. There's a lot of research and analysis that give us confidence in the relationships in the model.

.NET Note

Upgrading the .NET version shouldn't be too tricky. I've updated .NET Core MVC sites to .NET 6 and it none of the code needed to change. I tend to update regularly, so I'm now using .NET 7, but you may want to stick with .NET 6 as the even numbers have 3 years of support. The odd numbers have only short term support.

I hope you can get your API updated and get it launched. Now is the time to introduce some kind of continuous improvement process to make things better going forward. Once the dust settles and the crisis is over, people will be less willing to change the status quo.

Good luck!

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.