Efficiency and origination are the keys to happy customers more than ever. Are you frustrated with how long it takes to get new software delivered? Do you struggle through disappointment and unmet expectations while longing for more predictable and dependable delivery schedules? Are you scratching your head as you watch smaller, more nimble companies emerge overnight with compelling new digital solutions that seem to roll out continuously at the push of a button?
Continuous delivery is a way of flowing new software features to clients at breakneck speed, while ensuring product quality, usability, and performance. It’s a method of operating that Dropbox, Netflix, and even Amazon are using to great competitive advantage. Continuous delivery is achieved by bringing together development and operations in ways that create the early alignment and continuous cohesion necessary for coherent output that exceeds customer’s expectation. We will demystify the nuts and bolts of a well-integrated DevOps infrastructure that enable continuous delivery.
The idea of DevOps has been around the IT world for some time; some might even say it is ‘dead.’ We don’t believe it is. We do believe that many business leaders don’t understand the challenges that come with setting up infrastructure, processes, and systems to support continuous and rapid deployment, along with the cultural shifts required to make it all work seamlessly. An Army General was heard saying “Culture eats strategy for breakfast every day!” We agree. The best planned DevOps Strategy will never achieve its potential if culture is not addressed at the same time.
This series of blog posts will explore how culture interacts with, and enables, the processes, tools, and infrastructure put in place to achieve a truly functional DevOps program to exceed your customer’s product and delivery expectations.
So what is DevOps?
If you think about the development life-cycle, it usually begins with identifying the customer’s needs and wants, next is making sure requirements are accurate, and then building solutions to meet those needs. Typically, development is highly focused on bringing value to customers and solving those problems with new tools and enhanced features.
Then the process gets to a place where it needs to be executed, so it moves from development to validation, and then to live deployment. This deployment and execution phase is usually led by an operations team who also manages the infrastructure for the newly deployed software.
Some would say that a “traditional” view of development is “done” once the new code is built and the baton has been passed to the operations teams for deployment. This leaves the operations teams focused on keeping the software and tools up, running, and usable.
Operations teams are usually responsible for supporting the new software and fixing it when something breaks or goes wrong. They are the ones that have to make it work, so they are concerned with maintaining uptime and keeping systems stable. Thus, they are usually more averse to risks.
The paradox is that the operations team is also responsible for deploying changes and new features to customers. You can see the challenge emerging here. The Operations teams have the difficult task of making sure releases are smooth and do not interrupt customers or the business. So the real challenge becomes how to make these two, almost conflicting views, happen simultaneously.
Some believe that focusing on the tools will bring about this collaboration. While tooling is important, and we will cover that topic as well, our next post focuses on the people and cultural aspects of DevOps.