**Please note that this blog is posted on behalf of the author, Fernando Gonçalves, Head of DevSecOps, Congruity360.
In the last few years, the DevSecOps area has been growing significantly. Its related tools/technologies and the surrounding culture have become more mature and specific than ever. This journey also brought new challenges as well as their corresponding solutions.
No environment is equal to another and usually, a one-size-fits-all approach is not always implementable, but we can suggest high-level goals that can help you frame your specific design for your specific cases.
Define everything as code! From your infrastructure (or the parts you manage) up until your automation processes (pipelines, for instance). It will increase the portability of your infrastructure and your processes, but even better it provides repeatability (especially to the last), and that is crucial.
Well-defined processes are repeatable and will eventually become reliable. And reliability is a mandatory primary goal for the sanity of your development environments. Having a replica of your production environment back to your development one is a major asset. It reduces drastically bugs stemming from inconsistency in the environment’s setup. And for that to happen your processes have to be repeatable and consequently well-defined, preferably as code.
Another (among many) worth mentioning major benefit is automation. With everything defined as code you'll be able to backup the definition of your infrastructure, version it, move it throughout regions in your preferred cloud provider, etc. The same thing for your pipelines.
Don't leave a stone unturned until you make yourself useless. It might seem bold, but automating all the work needed to move from your codebase up until the deployment of your application in production (Continuously) should be your goal.
Nothing left to manual/human processing should be allowed in the long run. That breaks repeatability, risks introducing errors, hence compromising reliability and later promoting inconsistency across environments (and processes)
This amounts to increased costs (to the quality of the final product, etc) as you will more frequently need to require to call someone to fix the increasing issues, etc.z
Automated tests are a paramount part of these processes.
It will help you decrease the feedback loop, consequently increasing the quality of your product and reducing costs by minimizing the number of fires you'll be called to put down. And in that regard, you'll make many friends among the ops support teams.
SECURITY BY DEFAULT
Security is a mandatory stoppage in your deployment process. From code analysis, 3rd-party software security assessment to automated pen-testing and chaos engineering, etc, you'll have to plan "space" in your processes (pipelines mostly) to accommodate its inclusion.
In the beginning, if you’re bootstrapping the DevSecOps approach in your company, you might find that security is not a priority. But while planning your pipelines, always mind that as they mature you'll have to accommodate all the logic required for your security checks.
Prepare for that inclusion from the very beginning.
CHANGING MENTALITIES / YOUR C-LEVEL PARTICIPATION
Depending on the maturity of the teams you'll deal with, and their exposure to the DevSecOps culture, you might find yourself spending more time struggling against mentality changes rather than doing actual work. Albeit undesirable, these are natural reactions from the teams you'll interact with.
Having your company's C-level understanding the DevSecOps culture is paramount for them to back up your journey. Buy them a couple of beers while presenting your DevSecOps roadmap!