1
Today, we use git feature branches and handle deployment to both staging and production using python's fabric.
By default, GitLab's CI runs on every feature branch push, which I dislike, since you can push a feature branch that isn't ready for testing, for backup purposes. Although, it can be configured to automatically deploy only to staging, while having production deployment manually triggered. It can also run only on specific branches, like staging and master.
I was after a way to integrate deployment with task status updates, so once we updated a task status to Staging, for example, it would trigger a job to merge that task's feature branches to staging and deploy it. Once it gets tested and approved, we would update the task status to Approved, which would trigger a master merge and a push to production. To me, this would be the perfect solution.
Unfortunately, that's not how it works. It might be achievable through GitLab's web hooks and api, but i don't think it has a way to add a custom field to a task to store the related git branches and it only has an open / close status. We could use labels instead and parse the task description to extract the branch info.
What I've done in the past and worked great is use git hooks for deployment. Basically, we would add the fabric tasks functionality to the post_receive git hook, so once we push the staging or master branch, it would automatically trigger deployment. That would handle deployment's heavy lift, but I'd still like to automate branch merging, by linking it to task status.
In short, what I'd like to achieve is deployment based on task status updates.
Has anyone done that? Is it a good idea? Are there any caveats?
Any tips or ideas would be highly appeciated. Thanks!