Friday, October 22, 2010

Hudson as a Service release, 2010-10-22

While we've been overwhelmed with the enthusiasm and uptake of our Dev@cloud Hudson as a Service, we are never satisfied with "good enough." This week's release is just another step in the journey to make the best continuous integration service on the planet.

One of the areas we've improved is cost control. We've heard from several customers that they're concerned about what happens to their bill when a build gets stuck. This could happen for a variety of reasons, such as the SCM repository being down, or developers introducing an infinite loop in a test. To address this, we've added the following:

  • A build-timeout plugin which lets you specify elastic timeouts, i.e., timeouts as percentages of good builds. This elasticity allows you stricter timeouts that will still accomodate natural growth in build times as you add tests or modules. This can be set on the build configuration page.
  • A global, absolute timeout for all jobs. This setting ensures that however jobs are configured, builds will never last longer than you think they should. While we default this to four hours, you can set it as strict as you like on the global configuration page (Manage Hudson -> Configure System).
We've also reduced the number of steps you must take to setup a build, by providing defaults for several fields with the values tuned for running in the cloud. Furthermore, we've rolled out several more plugins requested by customers and plan to add many more.

We are also proud to announce that we are upgrading our build machines from Centos 5.5 to Fedora 13. As a part of this, we will be introducing a more modern kernel (2.6.34 from 2.6.21), as well as minor upgrades to Python (2.6.4), and PHP (5.3.3). The existing Java, Ant and Maven installations are unmodified. The details our in our knowledge base article.

We don't expect this to be a big change for most of you, but wanted to make you aware of it in case you did see some differences in your builds. This upgrade will give us more flexibility in some improvements we have planned.

Remember, you can sign up for free right now and only pay one cent per build minute during our beta period. Give it a try and tell us what you think!

Ryan Campbell, Developer/HaaS
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Friday, October 8, 2010

CloudBees is Hiring: Product Management & Marketing position

CloudBees is hiring for a Product Management & Marketing position, you will find the detailed description in this document.

For you to be a fit, you are probably a rising star, much brighter than me, with high energy, extroverted and with a great personality. You are also a self-starter, you don’t need to be micro-managed, you are very comfortable with blogging and social media (your online activity will impress us). Oh, and obviously, you are familiar with the Java infrastructure world and you are convinced that the cloud is a massive paradigm shift.

If you didn’t run away, why don’t you send me an e-mail?

This is going to be a fun ride – don’t miss it!

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Meet the CloudBees Team at Devoxx - Nov 16 to 18

Come at Devoxx - Antwerp (Belgium) - and meet with the CloudBees team.

From Nov 16 to 18, you will have the opportunity to see Hudson as a Service in action, CloudBees' PaaS roadmap and get precise answers to your questions.

Devoxx is the most important Java conference in Europe with more than 3,000 developers expected in 2010 (over-booked).

CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter

Monday, October 4, 2010

Are You Ready to Put your Source Code “in the Cloud?"

One question that comes up frequently when I introduce CloudBees is whether companies are actually OK to host their code “in the cloud” (or at least build/test it over there). 

Up to now, companies I’ve met split in three main categories (non-scientific poll).

1) No way: some companies just do not want to put their code somewhere else than on-premise. When companies have a strong opinion about it, it usually means they have already thought about it and cannot for a variety of reasons (legal, contractual, etc.) While this seems like the most logical bucket, interestingly enough - based on the interactions I’ve had - this is not the largest one.

2) Yes, we can: a decent number of companies already leverage the cloud for development related work and already made that transition. Consequently, their code, in some way, shape or form already travels “on the cloud”. To them, this is very natural and the move to something like CloudBees is very appealing. And do not think this category only applies to start-up and one-man-companies; I’ve actually met with large organizations for which IP is king and which are willing to move their code to the cloud as long as they have the insurance that some well-defined security rules are enforced. 

3) Let me think about it: the last bucket is very interesting. It concerns people who actually never really thought about it. Their first reaction is “probably not” but then, they mentally list what assets they already have in the cloud and realize … they already have quite a few. For instance, most of them leverage salesforce.com - and so, why would putting your entire pipeline, list of customers and prospects, information about your existing revenue be less sensitive than putting your code online? (especially for a public company!) Why would it be less sensitive to put all of your e-mail communications (Google Apps for example)? And pretty quickly, developers realize the decision is not that obvious, that they already put a good chunk of their key assets in the cloud (and some of the most critical and sensitive ones for that matter…) and their company seems to just be fine with it. 

This is why I think the cloud will accelerate thanks to DEVELOPERS and grow BOTTOM-UP. Much like with Open Source, developers will use the cloud because it helps them solve a pain point, because it is easier, more elegant and because their relationship with IT remains a love/hate one. I remember the good old days at JBoss when CIOs would tell us they weren’t using JBoss AS (and couldn’t use it) because it was Open Source and because they have policies restricting the kind of IP they can consume and very restrictive “approved vendors lists”, etc. and then have a bunch of architects at the back of the room raise their hands and start listing all of the projects that were deployed on JBoss in production. There was such an obscurantism wall between the top of the hierarchy and the trenches. 

It is very hard to fight the obvious, especially with developers. Consequently, I find it much more constructive to EMBRACE new technologies, define what’s OK for you and avoid any religious stance or over-simplification. Developers are smart dudes, anytime you fail to justify why they cannot do something they think would bring increased value and productivity, you can be sure it will happen anyway, one day, in an non-controlled fashion.

Onward,
Sacha

Sacha Labourey, CEO
CloudBees
www.cloudbees.com
 
Follow CloudBees:
Facebook Twitter