Bamboo simple deployment for many small projects?

Question

So we are the small php developers group from different countries and collaborating our work with awasome atlassian products. As we are under 10 devs and don't need clients to have access (for now) we have starter license for all products. Now we trying to implement automatic deployment to our dev and then production servers - but unfortunately seems like Bamboo has a different licensing. It's alow us to have just 10 jobs. But we have up to 10 projects in development and same amount in support. We do not use any testing (for now) so all process is just trigger push to stash and run ssh command on dev, like this: "cd /path/to/project/ && git checkout dev && git pull". So by run this we have updated code on dev server and nice icon in stash to reflect it. Obviously, we can't make more than 10 projects at the time to use this, and it's even divide by half once we setup prod deployment...

I know we can have just one plan that can run ssh command on dev server for all projects one by one, but I'd like to keep that notification icon in stash and seems like it can be done only per project. Also stats will be afwul to find wich environment fail the build.

Is there any small teams that struggle with same issue? Maybe we can use it in other way to meet our needs?

Please advice, thank you.

Robert Watkins · Accepted Answer

There are three options:

1) Keep under 10 active jobs. If you're not working on a project, you can disable it, so it's no longer active. This means you need to juggle a bit, but if you've got less than 10 devs, you shouldn't be working on 10 projects simultaneously anyway (as "multi-tasking is bad, mkay?"). Enabling and disabling jobs is pretty easy.

2) The starter licenses are starters for a reason - as you outgrow them, you are expected to upgrade. The next tier in the on-demand service is $50/month, which allows unlimited jobs, or if you run locally, you can upgrade to the "1 remote agent" license for a one-off $800.

3) Use a different product, such as Jenkins.

(A fourth option, to solve the dev/support issue, would be to run in a 'continuous-deployment' mode, where the build is _always_ ready to deploy. This means you wouldn't need to have a support branch - but does require a lot of discipline to know that the code is always deploy-ready)