Going to DevOps

Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp

I have had many positive returns from the articles quoted below:

Changing Behavior for DevOps Culture

So I decided to write another article about the challenges of introducing DevOps in the configuration of a traditional company.

It’s certainly something that I myself as a consultant / specialist struggled for quite some time, both to understand and to convey people. It is not possible to convey years of experience in moving a large company, from any segment, to a DevOps way of thinking, but I hope to give the three main pillars of how I tackled it earlier.

IMPORTANT, none of this mentions technology and tools: DevOps is primarily a cultural idea and therefore affects people above anything else.

1) Bring subject matter experts

If you are moving to DevOps in your company, join different people from different areas and then hoping that they (under the effect of magic) cooperate and agree magically at all is a bit unrealistic. It is virtually impossible without competent leadership.

If you are dealing with teams that have a lot of company time, mixing third parties and employees, where in the vast majority of companies is a reality, then fragmentation of areas is likely to be a significant challenge.

Aligning incentives makes things a lot easier. Oops, but what does that mean? Calm down, I’m not just talking about financial incentives, I will not go into this, but think of incentives / bonuses as something to be won. Be it the company’s traditional bonus, a photo with the director, a spreading of your work, anything.

Continuing, if both your developers, requirements analysts, and infrastructure are encouraged with a bonus (it may even be a cool lunch for the family), depending on how much they change the mindset they target as a goal in up to a year, is a simple way to get them to agree on whether they should automate projects, for example. This is a bit simplistic, but I hope you understand what I mean.

This may well come at the cost of something else. The first thing that comes to mind in the last example is quality.

Let’s put everything clearly, okay? We get paid for it. For ideas, suggestions, intellect. No one hired us because we’re cool. Okay, it seems a bit rough, so let’s go another way.

Think clearly, we are in a moment of revolution, changes, so first of all, you need to bring together the people with the highest technical capacity possible in each area and ultimately empower someone to make decisions when it can not be achieved through consensus. The more areas, consultancies, you join, the greater the chance they will not make a decision.

You may have heard about this idea of ??DevOps with some specialist friend, where the most capable professionals can do everything blindfolded. Lie! People who have maturity and synchronized knowledge are rare. And even if they do, they do not “loose” everything evenly, they let loose gradually. After all, we are in a moment of change. In any corporate environment, caution should be exercised. Many of these people try to influence through education and persuasion, and point people in the right direction. They help teams achieve the right decisions themselves, rather than a top-down approach to the “do as I say” model.

So what’s my point? If you are trying to move toward DevOps, then hiring highly skilled professionals requires care. For this person must have power of persuasion, someone who has done it before. Someone with a very mature sense of what DevOps is, and preferably someone who did most of the work he / she is trying to influence.

Also, hiring someone who has an instinct for integration is trying to get people to their way of thinking. And finally, someone who is not afraid to put their team on the line and make a decision. In startups or in areas beginning the concept of DevOps is very common indecisions.


2) Structure of teams

The traditional definition of DevOps is to divide teams between Development and Operations so that they accomplish shared goals. However, I am a strong supporter that DevOps is not just Dev and Ops. It is about all the functions that come together to achieve meaningful change.

Developers, requirements analysts, project managers, entrepreneurs and technicians must have shared objectives and incentives. Whenever possible, they should be seated around the same table. The team must rise and fall collectively (there is no “us and them”). The team should manage the change from crib to grave (requirements, compilation, testing, deployment, support).

To that end, DevOps has so much to do with “people” rather than with new tools and processes.

With that in mind, you are potentially talking about quite radical changes in a large number of people of various abilities, experience and personality types. I think it really depends on how your organization is structured, the skills of your team and many other factors. For many, this, however, means fundamental changes.

We begin by aligning change functions (developers, testers, etc.) to individual business units (rather than shared group services).

This fundamental change was sponsored at the back of some early and small wins by implementing things like Continuous Integration and labeling it “DevOps”. Okay, so it’s not DevOps, but if using that term starts gaining visibility and movement within your organization, then I do not think this is bad. I always believed that we needed a flag for the modernization of the department. If this track reads “DevOps,” then so be it.

When any team or company starts using “DevOps”, we will have many questions like:

  1. Why are you telling me how to do my job?
  2. You are using the wrong tools
  3. I do not see the benefit
  4. I know more about this than you do.
  5. What you’re trying to do is easy.
  6. We do not have the right people.
  7. This is a modinha idea
  8. There are regulatory reasons for this not to work
  9. The team of infra solves
  10. This is stressful when you are trying to do what is right and move on.

I do not think we’ve helped each other to get started. There are always people trying to pull off and change the technologies and processes of other teams. It is not enough to take the other team to the water and help them implement something in themselves. One must go hand in hand.

3) Create a team to help others

I mentioned that DevOps is a cultural idea and not a work title. Definitely not. Unimaginable in principle. So how do I run a “DevOps” team? Surely, this is a collective of “analysts operating requirements developers?”!

I believe we should have a “Platform Services” team, supporting the idea of ??the change platform. The change platform consists of tools such as Chef, Jenkins, Puppet, uDeploy, Teamcity, TFS and a few others.

Someone finally needs to “own” the tools making sure they are maintained, creating best practices, and laying out a roadmap for the future. Not just code deploy tools, but inventory, monitoring, and so on.

This team goes beyond that and helps the different change functions to adapt to the change platform and are evangelists for things like DevOps and Continuous Delivery.

With DevOps worried about destroying the paradigms, it is contradictory to have a team that chokes on knowledge and skills. To this end, Platform Services is the paradigm shredder, helping others to choose the tools and processes and implement them.

For example, we do not do deployments, but we sell the benefits to other teams and help you adopt the tools and processes.

I think this is a good template and helps spread the success of DevOps around the IT function.

Comentários do Facebook

Conteúdos relacionados