Custom Deployment Steps

[nirpeled]

Hey,

I recently started using Pipelines and so far so good but I can't seem to understand how to add more than the standard test/staging/production deployment steps - we have more machines I'd like to setup and couldn't find a way to do this.

A good and perhaps better option will be a dropdown allowing the user to choose what environment to deploy to but for now, I'll settle for setting it and triggering it manually.

Any ideas?

Thanks :)

Nir

[mwatson]

Hi Nir,

At the moment, Bitbucket Pipelines only supports test, staging and production as environment names (https://confluence.atlassian.com/bitbucket/bitbucket-deployments-940695276.html).

However there is a highly voted ticket we are looking at implementing soon to support other environments - I suggest you vote/watch and get updated as to when the feature becomes available - https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible

In the meantime, you can deploy to whatever environments you want, but you only have the three to do actual tracking on - use them for your most important environments and for the rest don't use the `environment` keyword.

Hope this helps,

Matt Watson (Bitbucket Pipelines Development Manager)

[nirpeled]

Thanks Matt for your quick response.

I'm actually trying to set up a few deployment steps since I have 2 test environments, 2 staging environments and 4 production environments - and I'd like to be able to deploy to any of those without any dependencies - can I do that?

Thanks :)

[mwatson]

Hi Nir,

This sounds like a more complicated scenario, where you want to independently deploy to multiple environments (as well as flexible environments) - would you say that what is described in this ticket is similar to what you want? https://bitbucket.org/site/master/issues/16650/manual-trigger-for-steps-running-in

If so, perhaps comment and vote on that ticket so we can capture all the feedback in the one place.

A workaround for this would rely on building an artifact in one build that is tagged with the commit hash it was built off, then using https://confluence.atlassian.com/bitbucket/run-pipelines-manually-861242583.html manual pipelines that you trigger off the same commit to deploy the artifact (identified by the commit hash, which is the common shared information across the pipelines) to an environment specific to that manual pipeline. Alternatively, the main pipeline stores the artifact ID against the commit hash in an external database of some sort, so whoever needs it can retrieve it. Not ideal, I know.

Hope this Helps,

Matt Watson (Bitbucket Pipelines Development Manager)