Bamboo 2.2 - Instant scalability using the cloud

Discussions

News: Bamboo 2.2 - Instant scalability using the cloud

  1. By taking advantage of Amazon's Elastic Compute Cloud (EC2), Elastic Bamboo let's you instantly add capacity to your continuous integration environment. It's simple really.. provided with an EC2 account, Bamboo can launch remote build agents, or elastic agents, into the cloud. This is great for reducing build queues on those days leading up to a major milestone when everyone is checking in loads of changes all day long. Less queuing means quicker feedback, so you can get on with everything else you need to do. Elastic Bamboo is ideal for anything requiring additional resources on the build server, like starting off a new project or running that additional set of tests. By using the cloud, you only pay for what you use and don't need to lobby IT for new servers or try to re-purpose old ones. Bamboo also includes several other new features which make continuous integration easy. Here are just a few of the highlights: * Customisable Email Templates * Build Comment Notifications * Hanging Build Detection * Faster Artifact Transfer * Dependent Build Improvements * Remote Agent Improvements For more information, or a free 30 day evaluation, please visit, http://www.atlassian.com/software/bamboo/
  2. I can only imagine what management (and my co-workers) would say if I told them we'll allow our proprietary code to be splattered across various Amazon servers just so we can build it faster. I think they'd laugh at me. I've heard of numerous instances of these cloud apps doing stupid things with your data (see the recent Google news about them accidentally sharing private documents). For anyone in any kind of regulated or highly competitive environment, you just can't use a service like this. I always tend to look at these products mostly from my own point of view, but all of these cloud things are completely useless for, I think, a considerable chunk of "enterprise" development. You just can't let other people handle things like message queues and basic storage for you on their own servers if you at all care about controlling your own destiny and privacy of the data.
  3. If you are worried about running it on EC2 you can install Eucalyptus and run it inside your enterprise. You still get the ability to run mixed workloads on your systems - maybe Web traffic at peak hours and bamboo builds in the quiet times. Paul
  4. Hi Paul, This is a great idea.. we have not yet tried this ourselves, but it's definitely something we'll play around with in the future. Stay tuned and we'll let you know how it goes. Thanks, Ken
  5. He would probably stop laughing after he asked you to estimate the dollar cost of performing the build in your current data center environment versus the cost of performing the same build on a cloud server. He will definitely stop laughing when his boss asks the same question...
  6. He would probably stop laughing after he asked you to estimate the dollar cost of performing the build in your current data center environment versus the cost of performing the same build on a cloud server.

    He will definitely stop laughing when his boss asks the same question...
    The initial raw dollar cost of a service should never be used in isolation to make a decision.
  7. Our builds are free[ Go to top ]

    He would probably stop laughing after he asked you to estimate the dollar cost of performing the build in your current data center environment versus the cost of performing the same build on a cloud server.

    He will definitely stop laughing when his boss asks the same question...
    The cost of doing builds is nearly free for even mammoth code bases with current hardware. We reuse hardware from our certification environment to do nightly builds and automated integration tests. I think a lot of others do the same thing. The hardware is already there, space and power are paid for, so we reuse it. I'm just not seeing the point of using cloud hardware to do builds for the vast majority of "enterprise" development shops. If you're "enterprise", you've already got a load of hardware that's probably not utilized 24/7 that can be used for stuff like this (assuming, of course, you have rationale IT people who aren't control freaks). Again, I'm looking at this from the point of view of dev shops I've worked in. We have the freedom to do things like reuse certification hosts to do our builds. I understand that some shops might not have that freedom and would have to procure dedicated hosts to do their builds. In that case, data center space might start to look expensive. But I maintain that to be a small majority of development shops.
  8. I can only imagine what management (and my co-workers) would say if I told them we'll allow our proprietary code to be splattered across various Amazon servers just so we can build it faster.
    Oh please. This is my third time around this particular block. Only prior it was source code on mainframes in IBM/Hitachi/Bull/EDS/ad infinitum datacenters, and you needed deep pockets to pay for those mainframe cycles and storage. Granted, there are still kinks, but they are being addressed and I can see them being worked out in the next year or two. Everything old is new again.