Implementing build only once + deploy from artefact repo

[Eric Gagnon]

Hello,

I'm evaluating Pipelines while having limited experience of CI-CD. Late to the party, I know...

The organisation I work for is not ready for continuous deployment (we also have to improve our quality process before going there as a dev team too).

So I need a manual trigger for QA and PROD.  I would have liked this part of the process to be relatively simple to offer it as self-service to QA member for whom Bitbucket could be an important learning challenge.

I naively thought that I could implement continuous delivery for dev (build, test, e2e, publish to nexus, deploy to dev) and manual trigger deploy (using a simple mix  of tags / branch / commit?) to fetch back the binary (build only once + time efficiency) and only do the deploy part.

I don't understand how this could be done with Bitbucket Pipelines.

The manual triggers seems to hidden quite far away in the ui and are binded to branch and commit only?

I thought I could use something like Rundeck but also looks like there is no official bitbucket api to do so. I have seen this thread that seem to be discussing about this : https://community.atlassian.com/t5/Bitbucket-questions/Trigger-Custom-Pipeline-from-API-OR-create-a-deployment/qaq-p/769230. 

Any hint on how I should / could implement this within the limits of Pipelines?

I'll maybe give a look to Bamboo server to see if it would be easier / possible to implement such scenario.

Great product so far.

[Eric Gagnon · Accepted solution]

Hello, I was able to figure out a few things by myself.

Download section can effectively be used as a simple repository for the builds (instead of Nexus).

I had to manage a private server deployment, which made things more difficult, but was able to  build a simple proof of concept using Slack.

My Bitbucket Pipeline send a message to our project slack, a App Bot receive the message and complete the deployment (get the file from the download repository, I was able to get the list using a npm library for Bitbucket, I only have to complete the download (I currently get a aws error).

I will change the message format to have something like @Demo-bot deploie build-x-y-z en dev (have the build identifier or version and target environnement).

The default Slack pipe is not working for me (it's also quite heavy to spin a docker just for a curl call?), the slack RTM api is only reacting to message, not attachment, took me a bit of time to figure it out but it is working nicely.

So for self-service (on deploy, not the build), our QA will be able to use the slack channel to trigger the deploy using the same message used by the Bitbucket cloud-slack-private server bridge.

Still have to pass the approval of security team because of the slack bridge (I also have another related issue for the Sonar-scanner result that I can't send to Sonar-Qube that is behind the Firewall) but I had fun building the proof of concept and learning Pipelines along the way.

Great product, cheers!

[Eric Gagnon]

Hello, I was able to figure out a few things by myself.

Download section can effectively be used as a simple repository for the builds (instead of Nexus).

I had to manage a private server deployment, which made things more difficult, but was able to  build a simple proof of concept using Slack.

My Bitbucket Pipeline send a message to our project slack, a App Bot receive the message and complete the deployment (get the file from the download repository, I was able to get the list using a npm library for Bitbucket, I only have to complete the download (I currently get a aws error).

I will change the message format to have something like @Demo-bot deploie build-x-y-z en dev (have the build identifier or version and target environnement).

The default Slack pipe is not working for me (it's also quite heavy to spin a docker just for a curl call?), the slack RTM api is only reacting to message, not attachment, took me a bit of time to figure it out but it is working nicely.

So for self-service (on deploy, not the build), our QA will be able to use the slack channel to trigger the deploy using the same message used by the Bitbucket cloud-slack-private server bridge.

Still have to pass the approval of security team because of the slack bridge (I also have another related issue for the Sonar-scanner result that I can't send to Sonar-Qube that is behind the Firewall) but I had fun building the proof of concept and learning Pipelines along the way.

Great product, cheers!