DevOps: Standard Requirements

Crucial Requirements:

1. You can start to create different test scenarios by bringing together all of the different types of testing that you require, and keeping a tight association with the application components to which these tests belong. This mapping is critical to understand which tests touch which code and more importantly understanding: when the code changes, which tests need to be re-run?
2. Ask yourself when you're talking about DevOps, again, it's not about a product. It's about what you know and how your company is structured, how your team works together. Do your developers-- does your development team know exactly what actual production looks like. I mean exactly. Can they tell you what production looks like?
3. With this new, full-stack approach to software delivery comes new opportunity for delay. DevOps was developed as a reaction to the long lead times required for infrastructure provisioning and integration with bureaucracy-laden ITIL processes. But what are these new sources of delay in the software development lifecycle?
4. DevOps isn't really a product. It's not something you can buy. DevOps is fundamentally about culture and about the quality of your application. And by quality I mean the specific software engineering term of quality, of different quality attributes. What matters to you?
5. A competitive edge, excellent. Focus on continuous delivery. Move on to continuous deployment because that's going to provide your business value. But look at your individual business. Look at your environment and say "is that what gives us the competitive edge?"
6. Essentially, DevOps isn't a tool or a product. It's an operational approach that changes how organisations think about developing and deploying applications. But, for many organisations, this can be a bit vague. How do you introduce this sort of change?
7. To put your organization on the path to DevOps, you need a clear understanding of your current practices for development and operations. Do your development processes use agile or waterfall methodologies, or both?
8. If you're not able to roll back your changes, how much money you're going to lose in the business. How much time are you going to lose for the defect and look for what happened?
9. DevOps needs both a strong definition and a set of standard success measures, but how does one measure improved cooperation between development and operations or alignment?
10. When the engineering team is satisfied, and pushes the new features to a full automation run, including load testing, how long does it take to declare the service ready to use?