ACM.390 Thinking about software development environments, permissions, complexity, and naming conventions
Part of my series on Automation of cybersecurity measures. AWS Organizations. I AM. Deploy a static website. THE Coded.
Free content on Cybersecurity Jobs | Register at Broadcast list
In the last article I explained why I was removing dynamic references from some of my CloudFormation templates in favor of script parameters, retrieving the parameters via scripts and passing the values as CloudFormation parameters. I’ve also outlined my wishlist for better secret protection in the CloudFormation settings.
In this article I’m going to describe something I’ve been thinking about: environments and where you store your repositories like Elastic Container Registry And AWS CodeCommit. I use them to store source control and containers.
Let’s say you have an account where you test setting up websites. You then have an account where you deploy your production websites. Do you want these two accounts to get code from the same code repository?
You can create a single repository and use a branching and merging strategy like many people do with GitHub. I find this approach complex, time-consuming and error-prone. It’s also harder to maintain permissions when a certain team only has permission to edit a particular branch. Maybe it’s just me, but I had to troubleshoot branch merging issues in GitHub and found it somewhat of a pain.
Another way to manage code
At one company I used a product called AccuRev. This product was my favorite source control system in terms of code merging at deployment time. I’m not saying I recommend it because I haven’t looked into security lately. I was just trying to look at the documentation and there is no TLS certificate or there is something wrong. I did not watch. I think it also only works on Windows.
But I liked the way it created a visual of who was modifying which files. You could rearrange the streams…