There is no Magic to transforming Waterfall-chaotic application development and deployment; into an ‘Agile’-integrated and error-free flow.
DevSecOps is another buzzword or ‘Magic DevSecOps’. Clients may ask for a ‘push-button’ delivery. ‘We should be able to push a button and this website will spring to life; use REST APIs to integrate with 3rd party systems automatically, make coffee, walk my dog and clean my car…..’
Much of the hype around Magic DevOps is nonsense. There is always human intervention in real life, including with code-build, deploying and testing. There is no magic.
Below: General tips and tricks when considering DevSecOps on AWS:
- Understand very clearly, where you are in reality with an automated DevSecOps pipeline using CI-CD techniques (current estate vs a target future estate)
- Make sure your products and processes need a DevSecOps, CI-CD pipeline process (in some cases static applications do not need the complexity of CI-CD), there is nothing wrong with using VMs and a CI tool like Jenkins depending on the use case, not everything should be reduced to buzzwords ‘containers’, ‘microservices’, ‘must always use K8s and Docker’ etc.
- Don’t use buzzwords like ‘continuous next’. Be concrete in describing the workflow and process flow from start to finish and map these to actors (SMEs), tools, monitoring and reporting
- Create realistic budgets and a precise target model based on those budgets (don’t guess what the pipeline and tooling will look like)
- Articulate the target CI-CD pipeline, including tools, processes, testing, security (tools and checks), principles, the budget, the timeframe (years), in a High Level (eventually End to End) design document, signed off by stakeholders
- As part of the above, tooling should include native services to test unit and system code, including security issues, or open-source tools such as Sonar, or those provided by the AWS marketplace
- Organise your code branch, trunk and repo strategy properly in the context of the DevSecOps flows (along with code-integration-UAT testing and security tools)
- Make sure testing and security are built into the design (automated test cases, security testing), along with operational runbooks and identify how Operations will interact with Development on the Agile team, and in deployments and beyond
- Monitoring, reporting (feeding into Operations) must be well thought out
- Environmental management (dev-test-prod are the same), tagging, resource tracking and the use of standard patterns are enforced (sometimes an ITSM integration with the AWS platform is the best way to control costs, decommissioning, patterns, sign-offs)
- Understand your skills, resources, knowledge and gaps in the above and make a training, change management plan (and budget) to remediate the gaps as part of the HLD-E2E
- Do not believe that you can become ‘world-class’ in DevSecOps in 6 months, or even 6 years (one team at a time), live in reality and plan for a long-term investment and it is a team-game, so the better skilled and more experience our team, better the results. Don’t expect miracles
- Ensure there is C Suite support and a long-term investment view for the CI-CD process
- Develop KPIs and Metrics with the current baseline (eg. Error rates, time to build and deploy, access and uptime SLAs)
- Implement a proper Agile-Scrum process
- Standards in processes, tooling, patterns and environmental management, must be enforced with an exception or change request process implemented and are usually approved and enforced by an Architecture Review and Governance Board and/or COE
- Going live in production is a business decision, not a technical decision or process and should be authorised with a formal checklist and approval