I have the following CI setup going on via gitlab.com and my remote servers (dev/staging/production). Basically works like this:
-
Developers pull the dev branch (gitlab.com) to their local dev environment (laptop, desktop, etc.) and work on code.
-
Once they’re happy with their work, commits are pushed back to dev branch (gitlab.com) where .gitlab-ci.yml then auto-deploys the changes to the development server (remote server).
-
The work is then reviewed on the remote development server and if OK, on gitlab.com the dev branch is merged into the staging branch.
-
This then triggers another pipeline (via .gitlab-ci.yml) which deploys the staging branch (gitlab.com) to the remote staging server.
-
The database and files are then pulled from the production server onto the staging server and the work is then reviewed (with current content/files from the production server).
-
Once the updates on the staging server (remote) are approved, the staging branch (gitlab.com) is then merged into the production branch.
-
This trigger the final pipeline which deploys the code to the production server.
We’ve been using this workflow for a couple years now and no complaints. The only issue I have is, on rare occasions, we need to do a hotfix on the production server. Now, this is where I run into a small problem. When the hotfix on the production server is pushed back to the production branch (gitlab.com) this triggers the pipeline to auto-deploy back to the production server. Nothing really happens—the pipeline ends with a “Already up-to-date.” GIT response.
This isn’t a big deal. Just a waste of pipeline minutes, really. But, I’m wondering if there’s any way, via the .gitlab-ci.yml to check to see where the commits came from and not deploy changes to the same place those commits came from (in this case, commits come from the production server and then auto-deployed back to the production server)?
Thanks,
Kristin.