Can I pre-configure a branch-way?

[Michael Hohlfeld]

Hello community, 

I'm not sure how to describe it.

So I will tell you what I have, what I do and what I think I need.

I have

1. in my repo 4 branches DEV / TEST / STAGE / PROD
2. For each branch a bitbucket-pipeline which runs automatic after a push or merge

I code and do manually

1. Push my code to DEV branch (bitbucket-pipeline run automatic to deploy to DEV server)
2. I create a pull request and merge from DEV to TEST (bitbucket-pipeline run than automatic to deploy to TEST server)
3. I create a pull request and merge from TEST to STAGE (bitbucket-pipeline run than automatic to deploy to STAGE server)
4. I create a pull request and merge from STAGE to PROD (bitbucket-pipeline run than automatic to deploy to PROD server)

My pain(s)

1. Big pain: It's a pain to select always (in the Pull Request page) the correct source and destination branch.
2. Small pain: Because every server environment contain a longer list of bitbucket-pipeline-steps I have to wait for every branch-pipeline longer ... DEV pipeline 1min, TEST pipeline 1:30min, STAGE pipeline 2:30min, PROD pipeline 5min

I think i need

1. Is there a way to configure my repo for a pre-selected branch way? DEV > TEST > STAGE > PROD 

What else I can optimize in my personal workflow?

Thx for feedback, Michael

[Erez Maadani]

Hey @Michael Hohlfeld ,

Per my understanding / gut feeling, for the higher envs (Prod & Stage), you are using PR+merge mainly for triggering a deployment, and not because you have "real" code changes.

One way to optimize your workflow is to pass the artifacts from Dev & Test pipelines to your Stage & Prod pipelines. This will reduce pipeline times because you will not have to clone and re-build your code, and it will also improve quality because there will be no bugs accidentally entering at Stage & Prod pipelines. 

In your case, I would also recommend splitting your pipeline into two pipelines: one for CI and one for CD. This will allow you to define different triggers and different behaviors which can also improve your workflow.

Hope that helps

[Michael Hohlfeld]

Hey @Erez Maadani 

Yes, correct: "you are using PR+merge mainly for triggering a deployment, and not because you have "real" code changes."

Sound's good > I have to check how to do this: "pass the artifacts from Dev & Test pipelines to your Stage & Prod pipelines"

Here I'm not sure to understand you correctly: "splitting your pipeline into two pipelines: one for CI and one for CD"

Currently I'm not deep inside CI/CD, but I'm learning every day.. Is this something what you mean? I use "steps" inside the "branches"

[Erez Maadani]

Hey @Michael Hohlfeld 

Your attached pipeline shows that your deploy & build are coupled because the deploy step is depended on the caches from the build step.

My recommendation was for you to be able to run your deployment (CD) pipeline/step without the running your build (CI) pipeline/step first.

To do that, you might want to use a third party to upload your artifacts to.

And then there are few options to implement what you want. One simple option would be:

1. Every commit to dev branch, run the build steps. One of the build steps will upload your artifacts to a third party.
2. Have env files, one for each env: test, stage, & prod. Every commit to Test, Stage & Prod branches, pull just the specific env file, parse it and deploy the relevant artifact version to the relevant env.

The solution above is pretty naive but can be implemented using a single bitbucket pipeline file. 

The important point here is to logically separate the CI from the CD. Each pipeline has different triggers, different requirements and different steps.