Workflow

Workflow is an important feature of a CI/CD pipeline. Some people advocate that only one workflow option is the correct one and that is "CI running against a shared mainline". Your branch strategy looks something like this:

This means that all changes are committed into one Master branch and every commit is a potential release candidate. The CI/CD actions are:

Branch	CI/CD actions
Master	Perform full build and Unit tests Quality checks / static code analysis Deployment and testing Production deployment

Promotion and deployment to Production can be a full automated process, but it may be convenient to insert a manual step.
The workflow is simple, but it may not be suitable for all teams. Sometimes it is not easy - or possible - to split up a feature into small changes. Frontend applications often involve small GUI changes, so a workflow that consist of only a Master branch may be sufficient, but in a lot of cases, a feature must be implemented as one change. A branch-per-feature workflow may be more suitable in these cases.
Some literature state that other workflows are considered 'CI/CD theatre' (see also https://www.thoughtworks.com/radar/techniques/ci-theatre). I find this a bit debatable. You must choose the workflow that the team feels comfortable with and that makes sense for the type of changes. If your workflow has some sort of mainline you are still be able to "run CI against a shared mainline". In our case for example, we have a Java/Maven project using the Atlassian workflow; this means the use of a branch-per-feature. The workflow is as follows:

The Master branch is the mainline. Each user story or epic results in a Feature branch. Each successfully build Feature branch is merged with the Master. A failed Feature - Epic 1 in the figure - is not merged with the Master until the build and unit tests are successful. Each Release is a branch with a commit from the Master. In CI/CD pipeline terms this means the following actions for each branch type:

Branch	CI/CD actions
Master (=snapshot)	Perform full build and Unit tests Quality checks / static code analysis Deployment and testing
Feature	Perform full build and Unit tests
Release	Perform full build and Unit tests Quality checks / static code analysis Deployment and testing Production deployment

Compared with the first workflow, the branch-per-feature workflow has one distinct difference; the commit frequency on the Main branch is less. That does not have to be an issue. The commit frequency on the Feature branch may be high instead. A merge with Master also does not mean that you easily screw up the Master branch. It is the responsibility of the developer to keep the Feature branch in sync with the Master.
The branch-per-feature workflow also does not put a heavy burden on the build- and test environments. Even the smallest change may result in a long build- and test cycle (a Fortify scan can easiliy take up 1 - 2 hours) in a one-branch workflow . Making a lot of small changes per day in a one-branch workflow results in queued jobs and queued testruns, unless your build- and test environments are scaled accordingly, which becomes costly.