Feature Branch Deployment vs Branch-Protected Deployment

Question

How to have both security and flexibility when it comes to deployment?

1. Having the capability to deploy to any feature branch is good for QAs, since they can test the app even before it's code reviewed.

   • Some scenario: Dev cannot access a certain feature due to geo blocking, and only QA has access to it within the team.
   • Faster turnaround time for fixing edge case scenarios.
   • Not secure since anyone who has access to the repo can just submit a commit to access secret information (keystores, distribution certs, API keys, ...)

2. Branch-protected deployment is secure but not flexible enough.

   • Typically, there would be code reviewers before you can deploy your commits so it's a bit secure.
   • If code review takes a long time (always happens in our case), productivity can slow down for multiple teams.

3. Feature branch deployment with restricted access to deployment environment.

   • But how?
   • Some idea I have found is to use pre_build_script wherein you can add some condition before runners can execute. Eg, store checksum of .gitlab-ci.yml to prevent from further editing, unless it has been reviewed. But this doesn't prevent other file from accessing the environment variables, eg, In Android, there is build.gradle which you can access any env vars.

It is preferably to have #3 solution but we're not sure how can this be achieve securely.

My issue is specific for mobile deployments (iOS & Android) if it helps.

Answer 1

The 1st point seems to be the most viable option to have both security and flexibility when it comes to deployment. The only concern here, which is pretty serious is security as anyone can get access to secret information.

Well, it's a pity people still store their secrets this way in repos where access control is a challenge. Ideally, secrets need to be dynamically injected into a pipeline and stored in a vault. If you can do that, the 1st option is the best way out. There are many articles out there on how dynamic secrets are managed like this for instance: https://ozone.one/blog/basics-of-dynamic-kubernetes-secrets-management-ozone/

Good luck!