I am using Bamboo 5.6.2 version.
I have a requirement to create a release every time a build is successful as part of Continuous Integration Pipeline. Output of build pipeline is a link to docker image from an external docker registry.
Reason being: Administrator has configured build expiry where old build results may be deleted including artifacts.
Intent: Creating a release will ensure that build result/artifact stays and thereby allowing us to deploy it at a later stage by referring to artifact.
I found similar question here: https://answers.atlassian.com/questions/33136376/how-can-i-automatically-create-a-deployment-release-but-dont-execute-deployment-yet but yet to be answered.
Create Deployment environment with echo script task and add trigger to that environment to deploy on successful build. Not sure such trigger exists in 5.6, working with 5.14.4
Related
We are currently using bamboo to build and test our software. Now our build plans are just a bunch of task: execute this bat, execute that bat etc. Created with the Bamboo UI.
It happens that over months/years the build plan needs adjustments:
Parallelize jobs
Add extra jobs
Change some tasks
But this will break when we try to build an older version of the software. Some scripts (called from bamboo task) are not-existing in older versions.
At my previous employer we used Jenkins pipelines where the content of the build and test was just a file present in the sources repo.
Now with bamboo it appears you can use Bamboo Specs. From I read you create specs file and when you run this, it which will create build plan. But I don't see a relation to cater for changing build plans over time (changing steps).
For example the Bamboo Specs of develop are used to build all Plan Branches (e.g. Pull Requests). So if you want to change the build in a PullRequest, you first need to merge this into develop, the Bamboo Spec of develop updates the Build Plan. Not possible to test this before merging.
Question: How can you make scripted buildplans in Bamboo, where every branch of develop can a have possible other way of building?
We have it now setup as:
Buildplan 'Product A': plan branches: develop, release_x, release, y
Buildplan 'Product A PullRequest': plan branches: feature/*
Edit: supported in 7.0: https://confluence.atlassian.com/bamboo/enhanced-plan-branch-configuration-996709304.html
Old answer:
I found Atlassian documentation: https://jira.atlassian.com/browse/BAM-19620. They call it 'divergent plan branches'. No support, there is a feature request.
As of 15-4-2019:
Atlassian Update – [11 April 2019] Hi everyone,
Thank you for your votes and thoughts on this issue.
We fully understand that many of you are dependent on this
functionality.
After careful consideration, we've decided to prioritise [this
feature] on Bamboo roadmap. We hope to start development after our
current projects are completed.
Expect to hear an update on our progress within the next 6 months.
To learn more on how your suggestions are reviewed, see our updated
workflow for server feature suggestions.
Kind regards,
Bamboo Team
Question: How can you make scripted build plans in Bamboo?
To make scripted build plans in Bamboo, you have to use bamboo specs. Since you are already familiar with Jenkins, bamboo specs work exactly like Jenkinsfile by automating your pipeline. The benefit of using this is that it lives in your source code and the changes you make to this file in your source code automatically changes your plan(pipeline) when bamboo build is triggered.
This is how I script build plans in bamboo:
I add my bamboo.yml file under the root of my repo. But currently, I use git subtree and my bamboo specs live in there. But you don't have to do this. The below link provides you with a simple approach.
Link my repo to bamboo
Tell bamboo to scan for bamboo specs in the repo
Make commit and push
https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html
If I have to make changes to the plan in the future, I edit the bamboo specs file then commit and push.
I had the same problem and unfortunately had to go through an unpleasant choice
Backporting the build script
This is not necessarily feasible everywhere, but I managed to make it work somehow for my project.
The idea is: treat the build script as a C#/Java interface, or better as a contract.
As soon as your branches do not provide significant changes in building the software, e.g. your desktop app becomes a web app, or you switch from Ant to Gradle, you can handle this.
Assuming my application is always a web application to be released as a jar on JFrog Artifactory, I have identified the following steps that are common to all maintained versions:
Use javac to build the jar of all modules
Use gulp to build the Javascript resources
Run JUnit from the repository
Baptize 💒 the artifacts with a version number obtained with a tricky algorithm
Push the artifacts to JFrog Artifactory
So the idea is that I had taken my Ant build script and mostly rewrote it in order to do the same tasks on different versions of the application. I started doing the changes from an older version, not maintained anymore, as an excercise. In fact, my official Git branches look like release/x.y.z where semver is x.y.z.k and newer bugfix-builds are built from the head of any x.y.z release.
So I took release/3.10.0 branch and rewrote Ant. I am currently testing with a manually created Bamboo plan
Stage: Compile
ant clean ivy-retrieve compile jar #builds the jar in a job
ant gulp-install gulp-prod zip #creates javascript resources
Stage: Test
ant run-junit
Manual Stage: Release
ant baptize ivy-release #tags the artifact using ${bamboo.jira.version} and pushes to JFrog Artifactory
What I am going to do with Yaml
Since the build script is the same, but specific tasks (e.g. Java compiler version) may change in different versions, I can create a very single Yaml script that rules them versions all.
I will then merge release/3.10.0 => release/3.10.1 => release/3.10.2 ... release/3.11.2 by merging the conflicts
Personal experience
Tonight I am struggling in making the JUnit tests work as I also chose to backport my testing framework to the older version of the project. I accept that a few tests will fail because older and non-maintained versions contain bugs. For me this is a way to prove that the system works.
Indeed, diverging branches are a great idea, but I am forced to use Bamboo 6 in my office
We're currently using TeamCity Enterprise 9.0 for our continuous deployment process; so please imagine the following scenario, you deploy your latest code to the dev branch, but one of the nugget packages was removed from the source and the build fails, QA team comes in at night and finds the build is broken and the environment is down for testing.
So I was wondering if there is a way to configure TeamCity to automatically run the last successful build in case the current code version fails, like configure it to make it aware that the current branch is broken and thus go back to a previous stable state.
Thanks,
The recommended approach is to have a separate build configuration for Deployment task. In this case you will be able to configure artifact dependency with option get artifacts from "Latest successful build".
Also see how to set up deployment with TeamCity.
I am testing out automatic deployment of build artifacts from Bamboo to Artifactory. I installed the Artifactory plugin in Bamboo, and then set up a test build plan. I added an "Artifactory Generic Deploy Task" since I'm not using Maven, Ivy, or Gradle.
My repository layout is:
group / product / version / filename.extension
It was pretty easy to specify where the artifact should go in the "Edit Published Artifacts" field in Bamboo:
myartifact=>com.example/someproduct/${bamboo.buildNumber}
This is fine for snapshot builds, but what if I want to make a release with a specific version number? What do I put in place of ${bamboo.buildNumber}? Or do I need to take an entirely different approach?
It's normally preferred to promote a satisfactory snapshot build to a released status than to run an independent release build.
Although Artifactory's release promotion support was not implemented for Bamboo's generic build type, starting with version 2.6.0 you can actually implement your own build promotion strategy within Artifactory as a custom User Plugin and invoke the procedure via a REST-API command.
So the procedure becomes pretty simple:
Write a release promotion strategy.
Add a Bamboo build step that executes the promotion via REST.
Build your snapshots until you're satisfied with the state.
Execute release step.
We also keep an example of a release promotion strategy plugin in github.
I'm just getting to grips with TeamCity and MSDeploy and have deployment to a dev environment triggered by SVN commit working nicely. The question I have is in terms of releasing to a test environment; I want to do this on demand and based on a specific revision number. What's the best way to configure a TeamCity build based on a user-defined revision?
You can use Run Custom Build Dialog in the TeamCity, and customize there Changes to include parameter, where you need to specify actually SVN revision to build.
Take a look on Pin functionality in TeamCity. You can pin a certain build and then deploy latest pinned build.
So you have a 'Create development build' task in TeamCity which deploys to dev environment and exposes artefacts. You can create another task in TeamCity that will use artefacts from latest pinned build in 'Create development build' task and deploy to your testing environment.
You can create yet another task that deploys to production latest pinned 'test' build. Rollback can be achieved by simply unpinning last pinned build.
You also have a history of deployed build.
Note: This question has been originally posted by Lahiru Gunathilake as an answer to another question. I'm moving it here as a separated question for the sake of clarity.
When we are doing a release we just build in our local machine and do the QA and then we host it in to repository. If we run mvn deploy does it create new artifacts, this cause having different artifact in the repository and in binary distribution because we are creating the binary distribution from our local repository. But if someone get the source code and do the build they'll get a different one. But if mvn deploy doesn't build but only deploy it's fine.
As explained in Build Lifecycle Basics:
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.
To do all those, you only need to call the last build phase to be executed, in this case, deploy:
mvn deploy
That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase.
So, the answer is yes, mvn deploy will execute install and build the project artifacts. But if you don't change anything, this will produce exactly the same artifact.