DevOps or ‘DevOops’: Three Tips for Successful DevOps | eWEEK

Throughout my career as an IT consultant, working with various platforms and technologies, I came across a host of terms that were suggested to me to explain how your company approaches modern software development. Terms such as Agile, DevOps, SAFe, among others.

They all come with a passionate group of advocates ready to fight for the term in the face of any skepticism. Personally, I am neither for nor against any of these terms. If something works for an organization, great. In trying to achieve the same success, many companies fall into the trap of an over-the-top solution as a new template or mold that everyone must fit into if they are to be successful.

The important thing for businesses to keep in mind is that DevOps is not a one-size-fits-all solution. The impression I get is that if a trendsetter like Google, Facebook or Microsoft decides to do something, then everyone should do it.

Add to this the added pressure of taking yourself too seriously, getting a little draconian, and it’s like a new lure thrown into the fishing pond for people like me who are generally full of cynicism after so many IT projects behind. them.

Why “DevOops?”

When I ask companies where they are in their maturity around DevOps, the answer I usually get is “we’re on a path to that.” The same can be said for companies when it comes to ongoing performance testing, which generally means that the company is doing something, but they haven’t figured it out yet.

This brings me to why I have now considered most of the current DevOps initiatives as “DevOps”, that is, a misguided attempt at DevOps. Most business leaders and companies are constantly looking for the latest developments, trends, or buzzwords to accelerate innovation, save time and money, and take on competitors. In recent years, DevOps has been one of the biggest buzzwords for companies around the world.

Ultimately, one of the most important factors in companies implementing an Agile or DevOps model is FOMO (fear of missing out). As such, companies try to adopt DevOps practices for the sake of being relevant.

This ends up causing more problems in the software development process compared to its older traditional approach. This is not to say that your traditional model is the way of the future for your company. You need to make sure you are ready for this type of model.

Imitation is the sincerest form of flattery … or is it?

When companies imitate their competitors, they try to keep up with their competitors and remain relevant. Many times they do this without sitting down to determine the best way to implement a DevOps model. for them – or if they even need DevOps practices in the first place. If your main goal is to add speed just for speed, that’s a recipe for disaster (or in this case, product development problems).

When it comes to performance testing, choosing speed over performance doesn’t solve the problem. Companies often ask me how to put each API test or end-to-end performance test in a CI pipeline to collect time metrics, and they want to do it as quickly as possible.

However, when you do this, the consequences are generally that the metrics are invalid, do not help to resolve performance issues, and become a “checkbox activity.” Why are these metrics invalid? Because the collected metrics do not provide real value to the audience (i.e. developers), leading to being overlooked or deemed irrelevant.

Meanwhile, the performance problems that companies were already experiencing continue to be detected after it is too late. Usually there is a production outage or customer experience issue on a support ticket to deal with. Automation did not solve the problem. The speed at which the tests were run through the IC tubing did not solve the problem. Headaches still exist.

But wait, there is a light!

In my experience, three things tell me that a company has successfully implemented a DevOps model / strategy;

  1. Service virtualization (or equivalent) has been implemented: This allows them to test with unfinished functions and services and not have to wait to test until development is complete. If they have no way of working on test automation for functions that work while others have not been created, they will lag behind in automation and tests will always be behind schedule.
  2. They have decoupled the production version from the users who have access to the new features: Which means they are quietly publishing code to allow end users to log in at a pace of their choosing, such as pilot groups. If they release something that messes everything up, they can quickly revert to the previous version via feature flags.
  3. Repetitive task automation: They are constantly figuring out how to reduce work environment effort by automating repetitive tasks while ensuring manual reviews are in place, even if there are exceptions to the standard pass / fail criteria. Not everything is always so simple: it happens or it doesn’t. A good DevOps organization knows the trade-off between reducing effort and speeding the pointless pipeline.

Ultimately, the solution to what ails a company’s performance testing initiatives will come down to the kind of result they expect to get from the test results. If you are looking to implement robust performance test results that enable your business to make confident business decisions, look no further than the end user experience.

Future DevOps

Right now, DevOps adoption is still in the “advertising cycle” stage or the area that Gartner calls “Peak of inflated expectations. “As a result, there are many efforts that are not completely serious about their pursuit of DevOps and are rejecting the core things that make DevOps work because they are difficult to do.

Over the next five years, we will see the DevOps hype subside as companies will “train” their employees and set new hire expectations for the skill sets required for site reliability engineers. At that point, companies will figure out how to get the right value out of it, and some will learn that they can get better value without it.

About the Author:

Scott Moore, Director of Customer Engineering, Tricentis

Leave a Comment