In my previous post, I’ve highlighted some reasons why quality of service is falling short in DevOps. It’s time to close this gap and consider the how’s in your DevOps chain.
Start with requirements and specify the what’s and the how’s. Enrich your documentation with as many qualies of service requirements as possible. Ask your business teams always about performance and security expectations of new features, and describe those non-functional characteristics in your stories. This practice gives your QA folks input for their test cases and makes it easier to decide whether the new build fulfills the agreed requirements or not.
Design the solution for reliability, availability, testability, and maintainability. Keep scalability in mind, think about how a tester can automate tests and how customers use this new application. Consider uptime and maintenance expectations in your architectural decisions. Right design decisions make the job for your developers easier.
Implement building blocks and keep design considerations in mind because the sooner your teams identify hotspots the more comfortable they are to eliminate. Validate your architecture, check the communication pattern, set functional and non-functional unit test in place and check if your new feature fulfills specified requirements. Educate your developers on secure coding practices and schedule secure code scans according to proofed security standards such as OWASP top 10 to identify and eliminate security issues at the root.
Build new solutions continuously, deploy the build on an integration environment and start the regression. Functional tests are essential, but they are worth nothing when it comes to quality of service. Set exact load tests in place which simulate current and future growth patterns. Combine resilience tests with your load test executions to check how safe your transactions fail. Break the build for any violation and block deployments if one of those tests identified issues. Set the quality gate to passed if all tests are within agreed thresholds.
Continuously monitoring how the new system behaves in production when real customers use it helps to address hotspots early. Different data sets, not expected navigation steps, other behavior of interfaces or invalid input can cause serious problems. The sooner you identify such problem spots, the more time your developers need to fix such problems within the next release.
Follow this advice, and the chances are high that your next deployment is in line with both, customers functional and quality of service needs.
Keep doing the good things!