We would like to keep you up to date with the latest news from Digitalisation World by sending you push notifications.
Digital Newsletter
Each week our editor Phil Alsop rounds up the most popular articles, videos and expert opinions. We compile this into a Digital Newsletter and send it straight to your inbox every week.
Digital Magazines
We'll let you know each time a new edition of Digitalisation World is released so that you're always kept up-to-date with the latest and greatest news and press releases.
Video Magazines
The Digitalisation World Video magazine contains the latest Zoom interviews with experts in the industry.
A similar attitude is beginning to grow within the DevOps space. While the DevOps community is thriving, the internet is often scattered with pieces that cry “This is NOT DevOps” or “You don’t get it, DevOps is not about this!” While these arguments are often well-intentioned and follow a precise mental model, the reality is that it only serves to create further confusion at a time when companies must develop their confidence to drive digital transformation.
Breaking it down in simple terms is critical to removing this confusion.
DevOps is about breaking the silos in IT and the business. Visualise old style vertical teams and departments: engineering, QA, and IT Ops, for example. Each department has its own policy and well-defined “interfaces” that define how and when development teams push new code to QA environments and production. Visualise horizontal slices of these teams: Team A is focused on the success of product A and define one way of working. Some companies will merge some roles, others will keep distinct roles, yet nonetheless: they are living DevOps when their cross-functional teams feel their “first home” is their product team, not their department. Picking the right tool that fits the company’s DNA and reinforces its right DevOps motion is the right one. People should not be told what “is” or “is not” DevOps - what matters is the behavioural changes being driven.
Continuous integration / continuous delivery (CI/CD) is another area of discussion. Where does “true” CD start and CI end? The reality is that it doesn’t really matter. Being “continuous” is about iterating fast, and as fast iteration creates heat, businesses need to remove that friction, which leads to automation.
Unfortunately, automation is not an overnight change. It is often the case that projects are hard to automate due to cross-departmental hand-off friction wired in its system – as such, automation is achieved in steps.
It is easier to automate to the “left” of the process, which is referred to as continuous integration (CI), as most development tools are created to be automated. The right of the process, continuous delivery (CD), means businesses are always in a “release-ready stage,” allowing organisations to push to production as they please. However, it is important to note that frequent releases may not add anything to a business – other times, it is simply impossible because of the domain.
Regardless, what remains is that organisations can automate as much as they please, up to the point of the final remaining pieces. They may even go the extra mile and reach continuous deployment, where various pieces are put “in production” (on a server, device, or app store) with every validated commit. Continuous deployment will require a system to deal with that “last mile” to reach the target location, measure its impact and rollback if things go wrong. There is no right or wrong - it is a journey.
In conclusion, organisations should not let those mostly argumentative discussions damage their confidence in what they are trying to build. If teams focus on continuous improvement through collaboration, fast iteration and automation, they are going in the right direction, whatever they wish to call it.
