{"id":52488,"date":"2021-10-12T15:00:37","date_gmt":"2021-10-12T14:00:37","guid":{"rendered":""},"modified":"2022-02-10T20:44:44","modified_gmt":"2022-02-10T19:44:44","slug":"a-few-more-mistakes-happening-in-the-devops-world","status":"publish","type":"post","link":"https:\/\/cm-edgetun.pages.dev\/en-gb\/industry\/blog\/technetuk\/2021\/10\/12\/a-few-more-mistakes-happening-in-the-devops-world\/","title":{"rendered":"A few more mistakes happening in the DevOps world"},"content":{"rendered":"

\"An<\/p>\n

As a follow-up from the original list<\/a>, there are so many more pitfalls and problems that you can find yourself into when approaching DevOps. The first list summarised the most common issues and misconceptions faced when a team or an organisation starts the journey, however these are common mistakes teams do when already up to speed.<\/p>\n

\u201cWe are doing DevSecOps now!\u201d<\/strong><\/em><\/p>\n

What happened to DevOps? There is no need to add a Sec label to DevOps. Implementing security practices should happen in the fabric of the organisation, not just tacking on a few tools in your CI\/CD pipelines. Adding a code scanner or a SAST toolkit will not automatically provide extra value, but rather create unexpected impediments for established teams.<\/p>\n

The right way of approaching this complex problem is by analysing how the security best practices you want to implement can be translated in the actual development process, building a common buy-in. Once a shared direction is agreed you will be able to reap benefits very quickly because the team would be prepared for the ongoing change.<\/p>\n

\u201cPull Requests are just for developers\u201d<\/strong><\/em><\/p>\n

Wrong! Simply put, Pull Requests are one of the earliest enforceable quality gates you can have. Remember, the sooner you can find a bug the cheaper it is to fix – a PR is not only a review, but also a place where only code considered \u201cready\u201d should land.<\/p>\n

\u201cThere is no planning in DevOps, everyone just keep moving\u201d<\/strong><\/em><\/p>\n

This is a big red flag in my view. If you are already part of a modern development team, you would have noticed that planning doesn\u2019t strictly apply to a practice that strives by the word \u201cautomation\u201d. However you could say that planning in DevOps is continuous, because it stems from Agile practices where you are continuously planning and re-planning work. You will never be in a position where things are unplanned.<\/p>\n

\u201cIn order to start doing DevOps at company-scale we need a centre of excellence\u201d<\/strong><\/em><\/p>\n

Why would you need a CoE if you are already practicing what you want to scale out? A CoE is a great support, but it\u2019s not strictly a prerequisite of enterprise-grade adoption. The easiest way to get this effort going would be to align and involve multiple interested teams so that they can see first-hand the value generated and delivered by DevOps.<\/p>\n

The next step is cultural adoption, and you can use a similar approach to the first one for the ongoing evolution. Remember to keep transparency and accessibility at the top of the priorities so things will never be stuck due to communication issues.<\/p>\n

 <\/p>\n

Learn more<\/h3>\n