Here are some general guidelines for structuring your Stages in Bamboo:
Fail Fast
The number one goal should be to structure your Stages in order of speed. The earlier you can find problems, the better it is. Move functional tests that take a long time to run into later Stages, or break them up and paraellise them to shorten the overall test duration.
Stage 1: Compile – Depending on your technology, you will have to compile your application first. If the compilation doesn't work, we are done and don't even need to kick of other Jobs.
Stage2 : Unit Tests – When something is broken, you want to find out as soon as possible. Your unit tests are the first line of defence. Ideally you have a lot of them. They run fast and catch a lot of problems within a few minutes.
Stage 3: Functional Tests – Functional Tests allow you to test the application with all it's dependencies, which is great. Unfortunately tests also take a longer to run.
Stage 4: Deployment – The deployment comes last. You might have some QA-Deployment Stage before the actual production deployment to perform some smoke tests or manual QA.
Don't Waste Resources
The great thing about failing fast is that we can detect potential problems early and don't need to execute the rest of the build. If we take the above example, when a test fails in the Unit Test Stage, we won't even bother running the more expensive functional tests... we already know that they are likely to break and are better of fixing the unit tests first.
Test the Artifact You Want to Deploy
Again, depending on your language, you are likely to generate an artifact of your application. You want to make sure that you only have to build this artifact once and test the same artifact in other stages before it gets deployed. You can either pass it via Bamboo's artifact sharing feature to subsequent Stages or use an external artifact management tool. That's completely up to you and depends on what existing tools you already use.
Jobs vs. Tasks
You can have multiple Jobs within a single Stage. The great thing about Jobs is that within a Stage they can be executed in parallel. Which means that you can run a bunch of Tests in parellel or deploy to different servers in parellel. Since Jobs run in parellel it's likely that they are being executed on separate agents and potentially completely separate physical machines. Hence you don't want any dependecies between Jobs like relying on the fact that they all access the same working directory.
Tasks within a Job on the other hand are always executed in serial on the same agent. Hence you could create a Task that assumes a certain state created by a previews Task. For example you might have a Task that modifies some property files before the tests are being executed with the next Task.
I hope this helped a little. Expect more blog posts and documentation on Stages and Continuous Delivery over the next couple of month.
Last but but not least, the following blog post is a rather simple example on how one could structure their Bamboo Stages:
http://blogs.atlassian.com/2012/01/continuous-delivery-with-bamboo-stages/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.