What is DevOps?
If you ask ten people, you will get ten different answers. Two weeks ago, I was at the ALM forum in Seattle and one of the three tracks was devoted to DevOps. I attended as many sessions as I could and I couldn’t find two presenters with the same definition for DevOps. However, they all believed in one thing: Development and Operations should work hand-in-hand and should be run by the same people.
Operations and Automation
Some believed that operations should be replaced by automation. Some companies like Netflix are using Amazon Web Services (AWS) for their operations and believe that most companies will eventually outsource operations to those companies who are able do it at a bigger scale like Amazon.
How can you merge Development with Operations?
You need Continuous Delivery (CD)
In order to have CD, you need for almost everything to be automated. Anything from:
- Testing
- Integration
- Deployment
- Configuration and
- Monitoring
must be automated.
That’s how Amazon can have 23,000 highly reliable deploys every single day. It means Amazon deploys new software to its servers (not all servers) every 4 seconds. Obviously these are not all big changes, but they are reliable and they let Amazon test the product even before its completion.
Compare this to typical enterprise deployments that take, on average, 9 months to deploy. There is a good chance that business needs have changed by the time the enterprise develops and deploys any given IT project.
Removing Barriers
DevOps is about removing the wall between Development and Operations in the software life cycle.
This is essentially the same impact that Agile had by changing Requirements and Development interactions. Agile promoted an iterative approach by adjusting requirements while products are being developed.
DevOps is essentially asking operations to be a part of the Agile development cycle. DevOps promotes continuous delivery and ownership of operations by developers.
This means developers are responsible for test, deployment and monitoring of the software that they implement.
How is DevOps related to requirements?
In Agile, requirements are constantly adjusted not only from changes coming from the business and stakeholders, but also based on the feedback the BAs get from the development team reflecting new learning as the application is created.
In DevOps, requirements are not only shaped by development feedback but also by operations monitoring. This means requirements affect development, development affects operations and operations affect requirements.
Usually, the software is deployed in a transition phase and at that time requirements changes must be deferred until the next release of the product. Business Analysts and operation teams are in two different worlds and don’t interact with each other.
However, in DevOps, BAs get real-time feedback from monitoring tools, not operation engineers. All monitoring data is traced back to requirements.
For example, a software capability that was defined in Sprint 1 and developed in Sprint 5 is tested, deployed and monitored in production during Sprint 6. This way, BAs have time to adjust requirements before the end of the release. It’s evident that through this process cost is going to be lower while quality rises. In short, DevOps is all about reducing cost while increasing quality.
Feedback is essential for continuous improvement. At Blueprint, we believe that operation-monitoring metrics should be automatically traced back to requirements. This way, Business Analysts can continuously monitor how their requirements turned out in production and have enough time to change them at a lower cost.
To learn more about how Blueprint can align with DevOps, contact Blueprint today.
