Tired of needless, unproductive meetings? Take a new approach that leverages the power of design thinking
Setting a DevOps mindset for 2016
What does DevOps need to overcome for a successful 2016?
The move to marry development and operations continues to gain momentum. In 2016, DevOps will hit the mainstream as a strategy employed by 25 percent of Global 2000 organizations, according to Gartner. For all of its collaborative benefits, and the potential savings in terms of time and money, there are still some challenges ahead. Affecting real, long-lasting, and stable change requires the right balance of technology and data, with people and process.
There’s no quick fix solution, but if DevOps is to conquer the enterprise, these questions should enter the mindset for the New Year.
Are your DevOps tools accessible?
There’s a real need for accessible automation tools that enable easy management of deployments throughout the product life cycle. Many of the existing developer and operations tools are focused on managing one set of users such as development or operations. If rapid deployment is the goal, then operations needs the ability to manage production.
An interface that enables operations to pick and choose, and then automate the deployment, should allow for greater rapidity and break this bottleneck. DevOps automation tools should not be left out in the cold for those with less programming skills. Infrastructure as code and overreliance on writing scripts is slowing things down.
Do you have true scalability?
For enterprises, the ability to handle a large scale, automated deployment into a huge production data center is essential. DevOps tools that offer an array of tempting features for development and testing often overlook this important requirement. Scalability for deployments cannot be an afterthought.
Your automated deployment process has to work now, and in the future when you add another hundred servers or adopt a new cloud service. The challenge of deploying across an increasingly complex hybrid cloud is growing, and will continue to do so as companies make quick decisions in the pursuit of innovation.
Can you replicate the production environment?
If you really want to mitigate the risk of release and build a stable continuous deployment (CD) pipeline, then you have to be able to clone your dev, test, integration and production environments. A separate sandbox that mirrors every aspect of your production environment is ideal for developing and testing. Think about every detail, including your hybrid cloud infrastructure, data migration and integrity, and even your network security.
It’s possible to dramatically decrease the risk of every deployment. You can reduce the chance of outages or defects creeping into production. But you must develop and test in an environment that really encompasses all of the nuances of your production environment.
Do you have automation all the way to production?
Automating the individual steps in the DevOps process is one thing, automating the whole show is quite another. For the full range of benefits to be realized, automation has to work end-to-end, from development into production. You need more than a series of bridges between departments. Processes, applications, and even infrastructure should be stirred into the pot.
The best individual tools may fall short on integration. If you can’t find the right ingredient to bind everything together, then you may need to reconsider your choices. It may be worth compromising in some areas to achieve a comprehensive system that works well together and allows you to automate the full DevOps process.
Don’t forget the inevitable manual steps
For most companies, the reality is that manual steps in the software delivery process are not going away. While software delivery can never be 100 percent on auto-pilot, a company should find ways to work in manual steps into the entire CD process and still achieve the same goals of accelerated delivery with fewer snags or errors and greater control.
Your CD tooling should also be able manage these unavoidable non-technical steps so that you don’t end up with two different disjointed processes, where one automates certain things, but then the real process is still reliant on e-mail and spreadsheets.
Is there a real commitment to collaboration?
The greatest technology tools and the latest streamlined processes are not going to get you anywhere without the right mindset. DevOps is a philosophy, and it won’t work in the long term unless there’s a real commitment to its ideals. If everyone works together, it’s easier and faster to tackle problems. It’s simply more efficient, but this much-prized collaboration that can bring such tangible benefits will not happen by itself.
If you’re serious about DevOps, then you have to facilitate regular discussion. You have to break down the barriers between development and operations. You have to ensure that the operations team can talk directly to a developer when they need to, and vice versa. You have to work on building a shared vision where their objectives align and their incentives require them to collaborate in order to succeed.
If you can answer each of these questions positively, then you have a solid base for DevOps to thrive.