You can do this already in Bitbucket Pipelines and your preferred PaaS provider -- just set up a manual step on your branch pipeline to deploy it. We built Deployments to help teams track changes in their _shared_ environments, which is where most of the value for tracking is.
Who would want to see a history of deployments for a branch-specific environment? What information would they be looking for?
In the early release, it's not possible: the 3 default environments are at the moment just for the repository, not per branch. You can deploy from multiple branches to the same environment though. Can you elaborate on why this would be helpful for you?
I was asking because we build a product that is deployed at customer site, so deployments would not be useful for that. But, we do deploy our own product to test environments for manual testing. (We also have automatic testing, but thats per commit and removed after testing... so not relevant here.)
We have the following branches (simplified):
master
release-4.2.x
release-5.0.x
release-5.1.x
Now, I was thinking to use the deployments feature to track the deployment of the test environment of each branch. So our testers can see the status of their test environment.
Branch-specific test environments would allow regression testing to happen _before_ changes get merged (I've used Travis to do this). I would love to have this kind of test isolation in our CI environment.
My main pain point with deployment is with servers that are not directly accessible from the Internet. For example, an EC2 instance that sits in a private section of an AWS VPC. Accessing the server is done through a Bastion server/Jumpbox. AWS CodeDeploy is the only solution I've found in this environment and it sucks. Can the new system ssh proxy through a Bastion server?
At the moment, direct access to your Amazon resources requires an access key configured via secure variables in Pipelines. We'd consider adding support for IAM roles/key rotation if a lot of people would find it useful.
I'm currently using the "custom" section with a plugin I developed to deploy to environments. In the default build it pushes the build to Elastic Beanstalk and then deploys to test. The custom builds merely promote the build for other environments.
I can't wait to use this. Is there planned support for FTP/SFTP? I only saw deployment plans for container-like services. Right now I have a pipeline script wrote using lftp but I'd prefer first-party support for SFTP deployments.
I'd like to see a mechanism to coordinate deployment dependencies - if the front-end and back-end(s) are stored in separate repos it may be necessary for the back-end to be upgraded before deploying the new front-end.
this is birru you're shared new future in bit-bucket (bit-bucket deployments) but it not visible in bit-bucket account
i am searched is there any add-on future there no add-on
there is no future in bit
how can i go to use deployments future in bitbucket
One idea I've seen broadly recommended if you don't want to run your whole tech stack & all environments (Test & Prod environment servers/DBs) in the cloud, i.e. as a DockerHub container or something, is to instead use WebHooks or CURL requests to call localized Jenkins CI within your private/local network to then kick off final builds/deployments to real environments that way, after the initial build succeeds and possibly even a throwaway environment gets spun up and tests pass in the Cloud.
That can be done using either the built-in Jenkins API https://wiki.jenkins.io/display/JENKINS/Remote+access+API or "Trigger Builds Remotely" Build Trigger option (which basically uses the same mechanism with your own Job-specific token/key). Nice feature is that BitBucket Pipelines supports "environment variables" to enable securely storing Jenkins API keys or tokens that let you securely tunnel through corporate FW rules and the like:
https://confluence.atlassian.com/bitbucket/environment-varia...
I'm pleasently surprised that bitbucket-pipelines has actually worked this well. So well that we have turned off our Jenkins server.
Nice work, atlassian!