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
Related
I'm evaluating Bamboo to replace our Jenkins setup and have a couple questions. I have a .NET solution that generates two artifacts: a packaged website and an MSI. I have three environments I deploy to: test, stage, production. Our Jenkins server in turn has three jobs--one for each environment. Each job builds the solution, copies in configuration files for the environment it will be deployed to and then deploys the artifacts. Reading the documentation and other stuff (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), I'm getting mixed signals about how deployment should work with Bamboo. It seems to me like deployment plans expect artifacts to exist and then deploy them. But, build plans include deployment steps as well. How is all of this supposed to interact together?
The reason I'm confused is because I have environment specific configuration files that get packaged during a build. Any direction on how this should work?
I posted the question to the Atlassian board as well and got an answer I think I like the best:
Jason Monsorno · 762 karma · Aug 30 '13 at 04:38 PM
Deployment projects in Bamboo seem to be dependant on the existance of
an artifact, the catch is you don't necessary need to use that
artifact so you could use an empty artifact and do completely
independent steps. Deployment projects are still fairly new to Bamboo
and your structure may favor the "normal" workflow so each environment
would be a separate manual stage.
The Deployment project do have a separate workflow and versioning. To
use Deployment projects in your scenario, I'd suggest making the
artifact the entire checkout then each Deployment environment can
build a copy of the artifact. The space-saving/less-time-efficient
option would be to just save the current revision in a file as the
artifact and use that to check it out and build in each Deployment
environment.
I looking for ways to improve build time for my maven build.
I was following this suggestion (Speed up maven) to rename the target folder to a different name and then proceed with the install goal and thus avoid the time it takes to clean.
However this leaves me with a folder that still needs to be cleaned at some stage. I was hoping that I could automate the removal of this renamed folder as a second process that runs in parallel with the install phase.
I haven't been able to find any information on whether it is possible or not.
Cheers for the help,
Ferg
I'm not aware of an out-of-the-box feature that would do that. Also the antrun plugin seems not to have an option to fork the process and run in parallel.
maybe ant itself can do that within the build script?
Maven 3 supports parallel builds: https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html - that might help to speed things up (but depends on the plugins you are using).
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.
We have a code base composed of many projects. Currently each time we add a project on SVN we must reconfigure CruiseControl to start build and test on such project.
I'm looking for a tool (better if open source) able to scan the SVN repository and find new projects by itself.
A project can be "a SVN folder containing trunk, tags, branches subfolders".
Even better if the tool supports multistaged continous integration and build on demand.
Thanks
In general, projects tend to be just different enough to require the build system to be set-up manually. However, you could probably use something like Jenkins with some bash scripts to achieve what you're looking for; eg. if your SVN server has an HTML index of all the projects, you could set up a bash script to poll that page for changes then tell Jenkins to add a new project from a template.
This is my second question on Bamboo (My First One). My understanding after reading suggested info, I need a build tool, like nAnt or MSbuild to write a script that gets the source code and builds it (I am working on a .net 3.5 with silverlight project). After, when deploying, I need to write scripts to move my files to the diff servers. Please tell me whether I am going in the right direction or not. Can I use ant, maven, bash scripts to do the same with a .net project?
Yes, that is true:
Bamboo is the central management server which coordinates all work
Bamboo itself has interfaces and plugins for lots of types of work
Bamboo basically needs to first get your source from a source repository (lots of plugins here for a variety of systems)
Then it needs to do the build - that can be done by using MSBuild to build your Visual Studio solution, or it could be a batch file to call your XYZ compiler and linker to create your app - whatever it is you have and use
Once your solution or project is built, you have "artifacts" (build results, e.g. executable app, config files, etc.) lying around
with those results, you can do additional things:
zip them up into a ZIP file and copy them somewhere
run a install builder on them and create an MSI
install them on a test server to make sure everything installs just fine
The sky's the limit! :-)
But in general: Bamboo is just the "orchestrator" - the coordinator. The actual work is done by either direct Bamboo plugins (of which there are plenty), or then you can call external command-line apps by means of a unix script or Windows batch file.
Marc