2 answers
1 accepted
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!
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).
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.