For many years application performance and security were an afterthought. Developer focused on implementation of new features. Tester executed functional tests and compared actual with expected results. Operational teams deployed the new release on production and once the user community started to use the new product massive performance problems appeared. This scenario is quite typical because almost every week there is a new story about not reliable websites or services in the news. The impact of such a performance disaster is tremendous. The reputation of companies suffers, customers stop to use their services, and expensive rework is required to fix those flaws.
Forward-thinking organizations have introduced new terms such as shift left, but what does this mean and how is it related to performance and security? According to the defect cost theory, the point in time when you detect issues drives fixes efforts. This is true for functional defects and even more for performance or security flaws because those often lead to design rework or code changes. It’s clear that large design or code changes require some development time and introduce additional risks.
Businesses try to avoid last minute changes and massive rework. One successful strategy to keep the risk of last-minute changes low is to identify those problem spots early in the development lifecycle. With this practice, key metrics are validated immediately after the new build has been created. Specified thresholds help to decide whether to push the new build back to development or proceed with deployment on testing stages.
Critical steps of such an unbreakable development pipeline which follow the shift left idea are:
1. Automated build
2. Automated deployment of the new build on the staging environment
3. Automated functional, security and performance test
4. Automated update of quality gate
5. Automated deployment to system integration stage if quality gate passed
6. Automated production user and transaction volume testing
We’ve realized that early performance and application security validation plays a significant role, but there is still a missing piece in our puzzle. Performance and application security engineering is all about testing against given requirements. My next post will shine a light in this specification of string requirements for performance and security tests.
Keep doing the good things!