Very recently a discussion came up regarding the usage of different buildspec.yaml files, one for branch builds and the other for deployment builds and I was wondering, since after some research I wasn't able to find the best practices on this topic from AWS, what is the approach I should follow when it comes to this topic.

To give some context, each time a branch is created and code is pushed to it that triggers a branch build to run on AWS that will trigger an entire Maven cycle of running tests, plugins, building the code, etc... and some additional steps that are specified in the buildspec. On the other hand, when merging a branch into master or when pushing something to master directly, the process that was just mentioned for branch will also happen with the addition of deploying the code to production as well.

With all of this in mind, I wanted to ask the community if having all the instructions for both the production and branch execution in the same buildspec file is the best practice or if having different buildspecs would be the correct approach.

Additionally, one dev ops person I know said that it depends on the use case so both are correct depending on the particular use case but I wanted to confirm this with some documentation or second opinion as well.

Thank you everyone in advance and sorry if this question is not appropriate or badly formulated.

  • Once the branch is merged into master, does it go through the full build, with the addition of being deployed to production? Mar 15, 2022 at 13:20
  • Yes it goes through the full build (So, compiles, runs all the tests, unit and integration ones, checks for vulnerabilities, etc...) and in the end, it goes to the deployment phase.
    – Pmsmm
    Mar 15, 2022 at 14:51

1 Answer 1


Anything merged into master is releasable, pending the steps in your build pipeline. The build pipeline feeding from master ultimately ends up being deployed, but not all changes in every branch are deployable. This alone warrants different builds (hence different buildspec.yaml files).

Separate buildspec files for other branches can be desirable in cases where you practice trunk-based development, because this allows you to enable feature toggles or conditionally run tests for new application features. Presumably a "branch build" has a few deviations in steps compared to your production build. This could include limiting deployments to pre-production environments.

There might be many similarities between your production and "branch builds", but I wouldn't worry about the duplicate effort. Once branches are merged into master, they go through the full build cycle anyhow. You can certainly use the buildspec.yaml file from master as a starting point when creating a new branch build. That way you can introduce customizations for your branch builds that are not desirable for a production build.

There is no single rule to apply here. Copy and paste as needed. The production build is the gatekeeper to production for any changes merged into master. If a commit merged into another branch is not releasable, don't be afraid to create a new buildspec.yaml file in order to customize that build pipeline to suit your development needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.