Sustainability in Construction: Building a Greener Tomorrow
There’s a couple of core areas that differentiate DevOps from traditional product software development. In this blog our first question is how DevOps is different from traditional software development approaches the changes in what is being done now to how it is approached previously.
The starting point would be to focus on the flow of value within the project and not necessarily conforming to a project plan. By approaching the project in this way you will instead be focusing on the value this delivers to your customers. The more traditional process is to follow a project plan. A document that is structured with completed deadlines e.g. over a six month period. During the six months, the layout is a perfect plan whereby you hit every single milestone along the way. One can argue that at the end of those six months you have a potential software delivery failure on your hands. This is because if you delivered exactly what was planned over the six months and have not learnt anything in those six months about your customer, about your technology, about the platform you are building on – one can argue you are not delivering the maximum amount of value to your customers. In other words, DevOps adopts a continual learning and adjustment process that is included into the plan.
Organisations that initially adopt DevOps method of – Flow of Value, can sometimes take time to adjust It is a completely different way of working and can take some time to get used to. However, the benefits suggest that the company can learn more about their customers and at a quicker rate, allowing that knowledge to be poured back into the build, producing a better service or product.
This is often different between organisations, although in the last 12 to 15 years, development teams see the importance of sharing code within the organisation. This culture is very important and systematic to the DevOps, as it supports innovation within the project development cycle.
The rapid iteration with feedback loops is another area that strongly distinguishes the DevOps process to a traditional software development methodology. The rapid iteration with feedback loops means the customer feedback is seamlessly coming back into the development process, again and again and again. It becomes a fluid cycle of receiving feedback, making alterations, getting more feedback and as you can guess… making more changes! This rapid iteration and feedback loops allow for constant learning and improved product use, subsequently a better user experience and increase growth and revenue.
A lot of this sounds like Agile. But what is the difference between DevOps and Agile? They are very related except Agile tends to be focused on quick delivery with feedback loops for the development team. In DevOps the process looks at the entire delivery team, to include IT operations. So, the process is not just about learning what the customer likes and how the customer behaves.
Another aspect that tends to differentiate the DevOps world from a traditional software development is automation, especially code delivery and infrastructure. When we talk about automation, we are not just talking about building a script that one can sit down and run from a command line that will do the deployment. This is of course very important, but it is not the only piece of automation that is focused on. In a DevOps world the ability to automate as much as possible, to receive feedback loops as rapidly as possible. A tight feedback loop allows the delivery of small units of value very rapidly and can be achieved through automation.
Should everything be automated in a DevOps world? Probably not. There is still a need for exploratory testing and having sharp testers play a game of wits against the software and the infrastructure to try to break things which is so important. But for the most part regression suite, unit tests and infrastructure deployments should be automated.
Infrastructure in the DevOps world is no longer a stagnant fixed server that is just used to compile apps and data. With DevOps there is a more fluid use case for infrastructure using a method of bleeding traffic into new servers, which gives real time feedback for the project. This optimises information to different servers and through doing so, able to assess if the software is working in that ecosystem. The advent of the cloud has caused this type of flexible infrastructure to really come to the fore.
Those are several core areas that distinguish traditional software development from DevOps. Both software development and DevOps have their own applications and their own merits, but essentially it is down to the organisation to identify the most appropriate fit. If you want to move to DevOps the adoption needs to stand on the existing culture and bring change from within. DevOps is a continuous development cycle.