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.
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'd like to find the best way to manage releases using Maven 2, Bamboo 3.1 and JIRA 4.3. I've tried many things but I keep hitting dead ends due to bugs or missing functionality.
My end goal is to have versions come from JIRA, have Bamboo take those versions and build artefacts from them using Maven then deploy those artefacts to a repository (Nexus in our case).
Here are the approaches I have tried:
1) Use a place holder in all poms for project versions:
Parent pom
<project ...>
<groupId>group</groupId>
<artifactId>parent</artifactId>
<version>${ci.version}</version>
...
<modules>...</modules>
</project>
Child pom
<project ...>
<parent>
<groupId>group</groupId>
<artifactId>parent</artifactId>
<version>${ci.version}</version>
</parent>
<artifactId>child</artifactId>
...
</project>
This builds if you start the build from the project root pom and specify -Dci.version=<my-version> on the command line. Combine this with the Bamboo Release Management Plugin and I can build and deploy versions of my modules and release as needed.
The problem with this approach is that Maven does not replace place holder variables in poms when deploying or installing which means the poms in the repository have the ${ci.version} marker when I'd really like them to have the concrete version. Because of the place holder it means nobody can use the modules I deploy. See MNG-2971.
2) Use concrete SNAPSHOT versions in the pom and configure bamboo to execute the Maven Release Plugin using the Bamboo Release Management Plugin.
Unfortunately the Maven Release Plugin needs the version to increment to, the bamboo plugin allow you to get the name of the current version to build but not the next one. Without this information using the Maven Release Plugin would increment the version to something that is not managed by JIRA. To make this option work I'd either need the next version available to me or be able to run a plan after the Bamboo Release Management Plugin has done it's thing (this second fix would also add extra mess to the commit logs as you'd get one commit for the auto increment and one for the proper increment).
2.b) Same as 2) but you have to specify the next version in Bamboo before any release build through the plan configuration interface, setting the value manually to the next JIRA version the plan should be working on. This fixes the problem with 2) but adds extra manual steps.
3) Do things manually, probably using the Maven Release Plugin. Completely ignore all release functionality in Bamboo and manually manage released on the command line by calling the Maven Release Plugin goal to change the version as and when needed. JIRA versions will also need to be released manually when this happens. We also need to configure a bamboo build to run and test the tag that the release plugin creates for the non-SNAPSHOT version.
This option has so much process involved something is bound to go wrong.
I can't be the only person trying to get automated releases using these technologies, can anyone help.
Thanks
matt,
You have to specify in your goal -Dci.version={bamboo.custom.brmp.name}
I stumbled upon your question when I was looking for exact the same information, but then for JIRA 4.4 and Bamboo 3.3, where the release management plugin has been replaced / upgraded with the JIRA Bamboo plugin ...
Hope this helps,
Francis
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.
This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.
Environment
ClearCase - Version 7.0.1.2 of ClearCase.
Maven - All of them, from the Maven website.
Hudson - Version 1.307 downloaded straight from the Hudson website
Questions
Does Maven run from a VOB?
I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.
To prevent there being extraneous files, I used the -rnname flag in clearfsimport.
This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.
Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.
A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!
In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.
Does Hudson work with ClearCase?
I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.
I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.
In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.
This saves extra administration on both the part of me (the admin) and my users.
What Internal Repository Manager did you use?
I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.
I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.
But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)
That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
I am not using this SCM, but there is a Maven2 plugin called SCM that handles Clearcase.
I had a team building with Maven 2 and using Clearcase as the version control system. We used Archiva as the repository for built artifacts so the development team did not need to use the SCM plugin.
However, the continuous integration server was Continuum and that was relying on the SCM information in the POM. We had problems with the Clearcase SCM grabbing snapshot views using out branching strategy. One of my developers had to tweak the Clearcase SCM code to get it to work with our branches. We both moved on before we got round to contributing his fix.