We are looking for a release management solution:
For example we have a WordPress plugin that has 3 versions:
- single site
- three sites
- ten sites
Code is exactly the same for all versions only 1 line in 1 file (licensing code) should be dynamic where we are declaring the version name:
"single site" string changed to: define( 'ITEM_NAME', 'Single' );
"three sites" string changed to: define( 'ITEM_NAME', 'Three' );
The ideal solution will produce 3 product versions from 1 branch of code.
They could be deployed to the same or different servers (we would prefer the same server so it's easier for us to pick up the product).
More complicated case:
For this case we will have the option to tag/mark some parts of the code which then will be replaced or deleted depending on the release requirements.
For example Dev release has the code with parameters that are associated with Dev server and Prod release has the code with parameters that are associated with Prod server.
Here is the explanation for that case:
I check this code into the main branch
Can we accomplish that with Bitbucket (and maybe Pipelines)?
Thank you very much!
Yes! Both your use-cases should be possible using Bitbucket Pipelines!
For your first case you would want some way to take the ITEM_NAME value as an argument when you build your site. For example, you could create a bitbucket-pipelines.yml file that has the following contents:
pipelines: default: - step: script: - ./run-build "Single" - ./run-build "Three" - ./run-build "Ten"
You'll need to decide what the run-build script does, as I have no experience with WordPress. But, that's the sort of structure you would want to have for you first use-case: Having all your sites build off the same branch.
For your second use-case you can use our branch, and variable functionality. Your bitbucket-pipelines.yml file will look like:
pipelines: branches: develop: - step: script: - ./run-deployment "www.devsite.com" $DEV_SITE_OAUTH production: - step: script: - ./run-deployment "www.prodsite.com" $PROD_SITE_OAUTH
This will run the "run-deployment" script that matches the branch name. So if you push a new commit to the production branch, it will trigger the deployment to run with the prod values. See this documentation for more information on branching in the bitbucket-pipelines.yml: https://confluence.atlassian.com/display/BITBUCKET/Branch+workflows+in+Bitbucket+Pipelines
The other thing I have done in this file is define some environment variables for the OAUTH tokens, you can define those in your repository settings and set them as secured so they don't appear in the logs. More information is here: https://confluence.atlassian.com/display/BITBUCKET/Environment+variables+in+Bitbucket+Pipelines#EnvironmentvariablesinBitbucketPipelines-User-definedvariables
This is an overview of how the bitbucket-pipelines.yml file is configured: https://confluence.atlassian.com/display/BITBUCKET/Configure+bitbucket-pipelines.yml
Hope that helps, feel free to reply with more questions.
Stop: Articles and permission Article-writing permissions are given to Leaders, Marketplace Vendors, Solutions Partners, Atlassian Team members, and those who are Level 4 + above. But for any aspir...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events