• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » Don’t do DevOps!
  • Don’t do DevOps!

    • By Yael Keemink
    • DevOps 4 years ago
    • DevOps 0 comments
    • DevOps DevOps
    Don’t do DevOps!

    DevOps is a term that you currently hear a lot. I will explain to you how you can implement DevOps. Spoiler alert, do not do it! Do not implement DevOps, but use parts from DevOps that you can use in your environment.

    Oh by the way, if you are reading this and think ‘What the hell is DevOps?’. Then read my article What is DevOps?

    Resistance to change

    Not everyone will be excited at first when you drop the bomb. When you say, ‘Hey let’s work DevOps from now on’ you most likely will face a lot of resistance from within the organization.

    Resistance from the management team

    The most difficult part of implementing DevOps is convincing your manager that your team must become a DevOps team. The fact that it is a radical change with unknown profit is a rather big risk for them. They will have to adjust the current company structure and maybe even the culture. This costs money and it will be difficult to convince the management of the benefit of a DevOps team.

    Resistance from operations

    Those who are currently responsible for operational activities in your organization may not like the plan. They will fear that their jobs will eventually disappear. The reason is, they are afraid that their tasks will be taken over by the development team.

    Resistance from your own team

    Resistance can even come from your own team. There may be people in your team who are afraid of change. These people will therefore not like to work in a completely different way. They get extra tasks and responsibilities that increase the chances that if something goes wrong they will be the ones to blame.

    Do not talk about DevOps

    To avoid the resistance you should not talk about DevOps. Prefer to talk about the parts within DevOps. Use the principles that are most effective for your situation. Then search for more parts that you could use. This way you do not even have to say the word DevOps. It does not matter how you call it, as long as it is an improvement for the current process. DevOps should not be a goal, but a means to reach the goal and in most cases that goal will be to improve the process.

    Talk to the other team

    Visit the operations team and try to find out what kind of problems they are encountering. Also try to understand why they do certain things the way they do them. When you understand how operations work, you can take that into account during your own work. This will increase mutual understanding and will improve cooperation a lot. People like it when you show interest in their work.

    An important aspect of a DevOps engineer is that he is technically strong, but also understands the operations side well. As a result, you know what impact your choices have during development on the production environment.

    Automate small things

    Another easy thing to do is automating your own work. Take a look at the work you do. Are there any repetitive tasks? They can probably be automated. By automating these tasks you will have more time to deliver value for the customer.

    Switch to trunk based development

    Chances are that you are still working with long-lived feature branches at the moment. If so, it may be useful to switch to trunk based development. In my previous article I explained what trunk-based development is about. Now I will provide you some tools with which you can try to work trunk based.

    Trunk based on dev

    With trunk based development you have very short lived branches that are merged directly into master with a pull request. However, that does not mean that you immediately have to implement it that way. Perhaps you are in an environment where you do not have any rights on the master branch, or you must code in a dev branch first or you have another reason why you can not or do not want to push to master.

    Even then you can still start with trunk based development. To start, create a branch per backlog item. When your backlog item is finished, merge it into your dev branch and create a new branch again. This will reduce the chances of merge conflicts and you will spend less time resolving these conflicts. However, not everything will have to be released, because you can cherry pick the desired features. This way you have the benefits of short lived branches but you do not have unfinished features in production.

    Feature toggles

    The next step is to use feature toggles. Make sure you create a feature toggle for the feature you start with. Then try to convince the person responsible for releasing the application to include a single feature that is not yet included in the release. You have placed this feature behind a feature flag that prevents the user from seeing it. Use a feature that is not too big to reassure the responsible person. When this is successful, he will hopefully see that there is little danger of releasing a feature with a feature flag and your team can work quietly towards real trunk-based development.

    So…

    As I said at the beginning, it is not the intention that you implement DevOps, but that you take parts that can be useful for your situation. Do not try to replace everything at once, but do this step by step. Also keep the goal in mind, stay critical on what you want to change. Does the change really add something valuable to your goal or do you do it because you want to work DevOps? When you do that, it does not matter if you call it DevOps, agile or scrum. These methods should help you deliver more value for the customer and are not a purpose themselves.

    Share this

Yael Keemink

DevOps engineer.

View profile

Related blogs

  • Argo CD

    Argo CD Roel van den Berg - 1 year ago

  • Add Azure Active Directory authentication to an App Ser…

    Add Azure Active Directory authentication to an App Ser… Michaël Hompus - 2 years ago

  • Manage Azure AD applications from an Azure DevOps Pipel…

    Manage Azure AD applications from an Azure DevOps Pipel… Michaël Hompus - 2 years ago

Data Discovery Channel

  • Explainable AI - Break open the blackbox

  • Toekomstvaste microservice data architecturen

  • Modern Data Platform

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}