I'm currently interning as a DevSecOps engineer, and I'm working on a microservice application that requires three different environments: development, staging, and production. My idea is for developers to create feature branches and make merge requests to a development branch first. From there, we would merge into staging and finally into the main branch for production. Additionally, we'll have a separate repository for deployment manifests which will manage deployments to the respective environments.
My main questions are: is this approach viable? How should the .gitlab-ci.yml file be structured for the backend microservices developed in various branches? Specifically, will we have Docker images pushed for development, staging, and production? What about the feature branches and merge requests? Also, regarding the manifests repo, should it contain separate branches for each environment?
1 Answer
I'd recommend avoiding a branch-per-environment strategy. Instead, let developers merge their feature branches into the main branch whenever they’re ready. This way, you can build versioned artifacts that can be promoted between environments through your CI/CD pipeline. Trust me, managing separate branches for each environment can quickly become a maintenance nightmare! Also, consider keeping the deployment manifests in the same repository as the components and versioning them together. This makes deployments much easier since everything is matched properly.
Definitely! I've been in situations with env branches, and they can be a real hassle. Trunk-based development or Gitflow are way better alternatives. Trust me—it makes for a much cleaner workflow!