To preface, my organization uses Github for its code base and Azure DevOps pipelines for its CI/CD.
I am building a DevOps CI/CD system for my organization and already have the tasks, jobs, and steps outlined to build and deploy. But I am unsure which branch to keep my YAML file(s) for best practice, and for developers to have to modify as little as possible after the pipeline is up.
My first instinct is to put the YAML file into our develop
branch, as that is where most of the stable changes will be during research. The trigger will be triggered on any PR or commit to develop
.
My issue with this approach is that if a developer branches a feature or bugfix from the develop
branch, then the trigger will still be from develop
in that feature or bugfix branch, which would cause multiple pipeline runs to be triggered, once for each active feature or bugfix branch that is still up when develop
is modified.
We could ask the developers to manually change the trigger in the YAML file from develop
to something else after a branch is created , but ideally the process is as hands off as possible.
My next idea was to have a dedicated branch, named DevOps
in the repository that contains only a YAML file. This would trigger on develop
.
However, this would cause any PR on develop
to not have the 'pre-check' that would be automatically displayed if the YAML file was in develop
.
So I ask, what is standard or best practice for keeping YML files and setting triggers? And how do you structure it in your project?
If you want the pipeline can be triggered for a branch, the YAML file must be existing in that branch, and the branches filter set on the CI triggers should include current branch at least.
The YAML pipelines can be triggered for bugfix
branch in the following scenarios:
bugfix
branch and has the branches filter like as below.
trigger:
branches:
include:
- bugfix # Include bugfix branch.
. . .
OR
trigger:
branches:
include:
- '*' # Include any branch.
. . .
The YAML pipelines cannot be triggered for bugfix
branch in the following scenarios:
The YAML file is in the bugfix
branch and has the branches filter like as below.
trigger:
branches:
exclude:
- bugfix # Exclude bugfix branch.
. . .
The YAML file is not in the bugfix
branch, even if has the branches filter like as below.
trigger:
branches:
include:
- bugfix # Include bugfix branch.
. . .
OR
trigger:
branches:
include:
- '*' # Include any branch.
. . .
It is recommended to ensure the YAML file is existing in both source branch and target branch of the PR. And ensure the branches filter set on the PR triggers should include the target branch at least.