Hello,
I have a software product using Gitlab CI designed in the following way:
- There are 2 projects: Front End (FE) and Back End (BE)
- Each of the projects is configured to trigger - upon merge to ‘master’ - a CI task (defined in .gitlab-ci.yml file)
- Changes are deployed automatically to the integration cloud environment
- Once QA is finished, someone in the team has to run a manual task of deploying the changes to the production environment.
Now the business requirements had changed due to a new version being developed:
- We need to freeze and maintain the old version (1.0) in its production environment.
- We expect low maintenance, but we should be able to control what we update.
- We need to develop the new version (2.0) right now, and it must has a separate integration and production environment.
- For some time, 2.0 and 1.0 will have to live in parallel.
In terms of the source control management, I don’t see a justification to split the 2.0 into separate Git projects. My thought is to move the 1.0 maintenance into a separate branch (to be used for this purpose only), and keep working with merging branches to the ‘master’ for the 2.0 code.
However, will it work right with the CI?
Can I configure Gitlab to trigger a deployment of ‘master’ code on any merge / commit to ‘master’ - based on .gitlab-ci.yml from ‘master’, while trigger another CI process every time there is a commit to ‘v1_0_maintain’ branch - based on .gitlab-ci.yml from that branch? Is this configuration documented?
Is it in line with the best practices, or rather violates them and I need to do something differently?
Thanks for help.