Kohsuke and I finally got Continuous Information out the door. Volume 4 of the CloudBees Newsletter for Jenkins features an article from Kohsuke, the latest Jenkins improvements, some handy recent blogs, details on upcoming Jenkins events, loads of Jenkins resources and various other useful info for Jenkins users.
Check out the headlines...

• 730+ Plugins, 61k+ Active Installations
• Giving Back to the Community: Kohsuke's Insights
• Registration Open for JUC Bay Area and JUC Israel, and the Jenkins User Event in Copenhagen
• What’s New in Jenkins?
• Upcoming Jenkins Enterprise by CloudBees Release
• Featured Blogs
• ... and more

 Read the whole newsletter, then check out previous issues and sign up to receive it directly.
PS - Got something for the next newsletter? Please drop us an email.



-- Lisa Wells
CloudBees Partner Marketing Bee & Managing Editor, Continuous Information

 

Follow CloudBees:
   

If you read our news today, you know it’s indeed rocking here at CloudBees! Over the last few months, much has happened in our growth and market momentum. Let's take a closer look at CloudBees' business, on several fronts.
First, we have further extended our Partner Ecosystem. We added key Technology Partners to provide more choice for developers and further augment - in an integrated way - the feature set and add-on services available from within the CloudBees Platform.
On the Services Partner side, the family is growing fast. The program that we launched late last year provides our customers with experts skilled not only in development but also with the CloudBees PaaS. Services Partners are available locally in more and more places around the globe. They are doing wonderful things on our platform and delivering amazing applications in a fraction of the time and at a lower cost, compared to the traditional on-premise development and deployment model. To support these valuable Service Partners we now have Cindy Vranken, our first partner manager, on board. She spends her time ensuring our partners are successful and happy. And we are already looking at further expanding her team.
From a platform user perspective, we have introduced the Developer Success Team. This team’s objective is to ensure that every user that comes to the CloudBees platform has a positive experience. The Developer Success Team helps and guides the developers on our platform to maximise their productivity and effective use of the platform. For those of you that are new to CloudBees, I’m pretty sure you have had a conversation with Félix Belzunce Arcos, our first Developer Success Team member.
Finally given the strong adoption and demand for the CloudBees platform in Europe, we have expanded our product offering and our team. Users can now run their applications on Amazon Web Services EU West in both multi-tenanted and dedicated configurations, enabling them to comply with European regulations and reduce application latency. We also opened the European office in Brussels with a team on the ground to be closer to our users and partners.
Watch this space, as the team is growing and a lot more activity is on the way!

Michel Goossens
Vice President of Worldwide Sales
CloudBees
www.cloudbees.com

At a time of explosive demand for the CloudBees Platform, Michel Goossens is driving growth for CloudBees, globally. Prior to CloudBees, Michel was at e-commerce platform provider Magento, where he was vice president and general manager of EMEA. Prior to Magento, he served as vice president for JBoss EMEA. Goossens holds a Degree in Computer Science from EPHEC in Brussels, Belgium.



Follow CloudBees:
   

A big thank you to everyone who attended our webinar, Building and Running Your Applications in the Cloud: A Tutorial for Getting Started with PaaS. It was great to have so many of you join us for the session and thanks also for all of your questions.  If you missed the webinar or would like to see it again, here's the WebEx recording.  You can find recordings of all of our other webinars (past, present and future) on the Webinar recordings page - please check them out to learn more about PaaS, all things cloud, Jenkins CI and Continuous Deployment.

There were some great questions during the webinar Q&A and I wanted to give you more detailed answers than we had time for on the webinar:

Q: I have created the database. How do I insert data into it?
A: There are a lot of possible answers to this question, but here are a couple to consider:

1. Many application development frameworks (Spring is a good example - see this documentation) have built-in ways to initialize a data source.  Take a look at our ClickStarts as there are some examples of this: for example, the JBoss JPA/Hibernate one has an import.sql script.
2. You can always run a database initialization script as part of your deployment: if you are running a Jenkins build job using DEV@cloud, then the easiest way to do this is simply to invoke your SQL script using the built-in "Execute shell" action.  You should use the Build Secret Plugin to protect your database administrator password.

Q: Please publish a step-by-step tutorial on using CloudBees.
A: Here are some resources that may be helpful:

1. I've done a few short videos that go through the complete setup of your CloudBees project (including integration with GitHub and Eclipse): you can find these on our Getting Started with CloudBees Resource Center.
2. Sign up or login to your CloudBees account and check the box to "Take the Tour." This will guide you through the various features of the CloudBees Platform.
3. There are quite a number of videos available on the CloudBeesTV YouTube channel.

Q: Is an app-cell an 1/8th of an EC2 Compute Unit?A: Yes, correct.  There's a more detailed explanation of app-cells in our pricing FAQ and there's more about EC2 Compute Units and the reasons why Amazon introduced this model in the Amazon AWS FAQ.

Q: Does CloudBees support ec2-userdata?  I use this to configure which environment my EC2 instance is (demo, uat, prod) and JDBC URL, etc. Perhaps this is done better in a PaaS?A: No, we don't provide access to the ec2-userdata for the underlying Amazon EC2 instances your app is running on: this is very tightly tied to the AWS infrastructure and we aim to abstract all that away for you. As you suggest, there is a much easier way to do this using PaaS: take a look at this article about Configuration Parameters and how to use these to customize settings for different environments.

Q: Do you have a Hadoop setup to run MapReduce jobs for an App that needs a computed data/result?A: We don't ourselves offer a Hadoop service: one option would be to consider using Amazon's Elastic MapReduce service and call to it using the Amazon APIs from your apps running on CloudBees - it's really easy to "mix-and-match" PaaS and IaaS in this way: you can use the bees config:xxx commands from the CloudBees SDK to pass the AWS credentials for the IAM user into your application and then call the services exactly as shown in the AWS Java SDK.

Q: We have a web application that needs to write/read media files at runtime. Which model (dedicated/shared) do you recommend?A: The main issue to consider is whether your application only needs temporary access to the files or whether you are looking for longer-term storage.  By their nature, PaaS applications do not usually have persistent file storage associated with them: the PaaS runtime can (and does) relocate those apps to deal with problems in the underlying infrastructure, or to scale the application to respond to increases in demand and in that event, the application is liable to be re-started in a completely different virtual environment with no access to the original underlying file system.  Even with dedicated servers, this is still the case: the main reason for using that model is for a more deterministic performance/response time, since you know in advance exactly what hardware infrastructure will be available to your applications and so can scale accordingly.


Q: Are you working on a NetBeans plugin?
A: It's something we really want to develop (particularly the former NetBeans engineer on our team!), but I'm afraid we just haven't been able to spare the resources yet. There is a community-contributed NetBeans plugin on GitHub, but I haven't actually used it myself. If you have time to take a look at it, please do let me have any feedback so that we can incorporate that into the requirements.

Q: Any plans to allow customers to choose Amazon hosting in Australia?
A: Nothing planned right now, but if this is important to you then please do let me know, so that we can get it on the engineering radar as this is certainly something we could support fairly easily: we already have a multi-region capability built into our PaaS and we provide customers their choice of Amazon US and EU regions.


Q: Is there any comparison with CloudBees & non-cloud pricing for a web application?
A: Yes, please take a look at our Total Cost of Ownership white paper.


Q: Do you plan to go to market with the Drupal ClickStack?
A: We are just in the process of finishing up work on the initial Drupal ClickStack and as soon as that is completed, then we definitely plan to make this available as a supported runtime on the platform.  The combination of ClickStacks, ClickStarts and continuous delivery will, we think, make a compelling case for developing and testing Drupal-based applications on CloudBees. The beauty of ClickStacks is that they allow us to plug in different runtime containers very easily and (surprising as it might seem at first glance) the underlying model is very similar, as these diagrams illustrate:





Mark Prichard, Senior Director of Product ManagementCloudBeeswww.cloudbees.com

Mark Prichard is Java PaaS Evangelist for CloudBees. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was Product Manager for the WebLogic Platform. A graduate of St John's College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA.  Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.



Follow CloudBees:

   

As of the end of February 2013, Jenkins had more than 57,000 active installations (a conservative number) - up more than 60% in the last year - and more than 600 plugins. Our Fall 2012 Jenkins survey showed that 83% consider it a mission-critical tool. 


2013 Palo Alto Jenkins User Conference

Wednesday, October 23, 2013Palo Alto Jewish Community Center
The Jenkins User Conference (JUC) provides the perfect venue for everyone – Jenkins experts and newbies alike – to learn more about the Jenkins continuous integration server, share knowledge, network, and build an even stronger open source community.

JUC Palo Alto 2013 features a keynote by Jenkins founder and most significant contributor Kohsuke Kawaguchi and two full tracks of presentations by Jenkins experts from the community (hopefully including you!). Light breakfast, lunch, snack and Jenkins conference freebie (usually an envy-inspiring t-shirt, but maybe we’ll surprise you this year) are included for everyone.


What You Need to Know

• Register and join the fun! Early-bird tickets are only $54 through August 2.
• Call for Papers ends June 9 – if you have exceptional Jenkins knowledge to share, please submit an abstract to present (scroll to the bottom for the form).
• Sponsorship – please drop a note 'juc-oc-ext AT cloudbees DOT com' if you would like show your awesomeness and support the Jenkins community... or even host a Jenkins event yourself.

To get a feel for the conference, check out the video & slides from 2012 JUC San Francisco and the video highlights and slides from the inaugural JUC in October 2011.

Finally, a special shout-out to the many sponsors who have already flocked to support JUC:


         





 

             






We expect the conference to sell out, so secure your spot now!

Can’t make it to California for Palo Alto JUC? Check out JUC Israel on June 6 and the Jenkins User Event in Copenhagen on September 9th.



Follow CloudBees:
   

U.S. District Judge William AlsupYou could hear a collective sigh of relief from the software developer world when Judge William Alsup issued his ruling in the Oracle-Google lawsuit. Oracle lost on pretty much every point, but the thing that must have stuck most firmly in Oracle's throat was this:

"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different…"
TL;DR... APIs are not copyrightable. Sign the White House petition in support of open APIs.
Now the legal appeal of the decision is underway. Microsoft and IBM (via the Business Software Alliance), amongst others, have filed friend-of-the-court briefs in support of Oracle. The ruling has a lot of entrenched corporate heavyweights up in arms – and you can bet that the common denominator is about defending the aging Empire from the startup Foundation.
This lineup of friend-of-the-court briefs is alarming. Why? Their collective argument is that Judge Alsup's ruling is bad for business. It may in fact be bad for the old guard's business that is increasingly threatened by changes driven by open source and cloud-based services. But make no mistake: if Judge Alsup's ruling is overturned on appeal, it's not going to be in your interest as a software professional.
Oracle lost in their attempt to protect their position using patents. If they succeed in claiming you need their permission to use the Java APIs that they pushed as a community standard, software developers and innovation will be the losers.
CloudBees sits on the Java Community Process Executive Committee. We are working with others inside the JCP to advance the current rules to be more in sync with the fork-friendly open source and cloud world. We believe that Oracle’s quest for a legal stranglehold on the Java API, which itself has been advanced through the Java Community Process, has nothing to do with compatibility and everything to do with cashing in on Java at the expense of the community.
With the IT industry shifting from packaged software to a cloud-based service model, this debate becomes even more important. As companies increasingly invest in SaaS, PaaS and IaaS solutions, their entire operations will depend on 3rd party APIs. Formal standards are only just emerging and adding FUD over the legal standing of API usage is going to place a drag on the industry.
The debate is this: will our economy thrive and be more competitive because companies can easily switch from one service provider to the other, by leveraging identical APIs; or, will we allow vendors to inhibit competition through API lock-in? And should this happen only because a handful of legacy software vendors want to protect their franchise a few more years? This decision will impact us for decades to come.
Developers: your long-term livelihood, the richness of technology choices, and the competitiveness of our industry are at stake.

If you agree with us, please register your vote on the White House petition, started by Kohsuke Kawaguchi.

Sacha Labourey, CEO
Steven G. Harris, SVP of Products
CloudBees, Inc.



You can also learn more on the APIs are not Copyrightable Facebook page.


Follow CloudBees:
   

An Experience Report on Building a Mobile Automated Test Lab with SOASTA TouchTest


This is a guest blog by Wil Pannell, an enterprise software engineer evolving as an agile practitioner. Wil blogs about his experience using SOASTA and CloudBees for the testing of a mobile application on multiple mobile platforms. Wil's firm, Media Agility, provides consulting to global clients seeking the latest approaches to mobile software development and deployment.

wil.pannell

Prelude

I came to develop a PhoneGap application on IOS and Android tablets.  Agile/lean engineering practice led to test-first development, but when I began to build out continuous integration, I found the offerings for mobile automated functional testing and deployment lacked maturity.

I discovered SOASTA when I attended a webinar on mobile functional testing that culminated with a photo of a mobile lab, to which a continuous integration process was deploying and running an automated suite of functional tests to a variety of IOS and Android targets:
I required no further inspiration.  Such an outcome would provide my organization with a high degree of code coverage for our mobile offerings and protection against defect regression -- to build the product right -- and establish an infrastructure to deploy feature changes continuously -- to build the right product.  The doors to lean mobile platform development are now wide open for us.

SOASTA and CloudBees
The webinar was hosted by SOASTA in partnership with CloudBees, a cloud-based provider of Platform-as-a-Service for developing web-based and mobile applications.  We followed the practices recommended by SOASTA and CloudBees closely, and built out our Jenkins deployment pipeline  comprised of the following jobs:

1. build the javascript assets for deployment to the IOS PhoneGap project;
2. build and deploy the IOS app capable of running SOASTA functional tests to devices tethered to the mobile lab;
3. kick off SOASTA functional tests;
4. build and deploy the production-ready IOS app to our enterprise Appaloosa store and notify QA that a new release is ready for a spot check.

We also built out an analogous pipeline to deploy and test our Android PhoneGap project designed to run concurrently with the IOS pipeline.
Features of Our Mobile Lab
(1) We run over 350 automated unit- and integration-tests and achieve greater than 80% code coverage:


(2) Using SOASTA command-line tooling and the Jenkins XCode plugin, we build a mobile-functional-test-ready IOS target and deploy it to the devices tethered to the mobile lab:

(3) Again, we use SOASTA command-line tooling to run a pre-recorded mobile functional test on a SOASTA-hosted instance of their TouchTest environment.



(4) Finally, provided each job succeeds, we build and deploy a production-ready release to our Appaloosa private enterprise store:

(5) There is a step that I purged, which uploaded to a QA site for approval.  This meant that the build would not pass until QA exercised their exploratory test phase.  I did not feel right about the way in which this step would prevent continuous deployment.  But I felt that it was right to purge this step after discussing the topic with Joshua Kerievsky.  He asked me a simple question:  can the automated test do exactly what QA would do?  Because of the accurate recording I experienced with SOASTA TouchTest, my answer was:  yes.

Quick Starts and Support
There exists a ton of practice on both SOASTA and CloudBees for getting a mobile lab up and running.  SOASTA's quick starts and knowledge base are comprehensive, and I found the forums and personalized sales support via email extra-ordinarily responsive.
The same is true of CloudBees.  Their partnerdemo site and blog provided concrete configuration and practice for many of the scenarios we required.  And Mark Prichard of CloudBees himself generously devoted a considerable amount of his time to walk thru the fine points of my Jenkins configuration.


Summary
The other offerings I discovered that support mobile functional testing had obvious shortcomings in one-way-or-another.  SOASTA is the only one, to my knowledge, that can support development at enterprise scale.

My favorite feature is to be able to deploy from the command line to IOS hardware targets in a continuous deployment scenario without manual intervention.

At the time of posting this, I learned that SOASTA has shipped my most-anticipated forthcoming feature:  the one that wakes up the sleeping device tethered to the mobile lab when the automated build deploys.

Our experience with SOASTA tooling for automated mobile functional testing was quite satisfying.


Follow CloudBees:
   

This is a guest blog, written by Gary Kennedy, Founder and COO, Clarus Financial Technology, London. Clarus provides services such as technology due diligence, enterprise risk architecture, central counterparty clearing, financial engineering and software development.
In football, the home team supporters energise their players by showing appreciation of good plays and creating an intimidating and distracting atmosphere for the opposing team. This advantage can be so great that is likened to having an extra player in the team, referred to as the ‘twelfth player‘ in the team.In many traditional software companies, the development and release infrastructure is handled internally, either by a small dedicated team, or on a part-time basis by some of the experienced developers. A modern approach is to consider a Platform-as-a-Service (PaaS) to host and manage the development infrastructure, freeing resources to concentrate efforts on one’s core strength, the product. At Clarus we have used CloudBees from day one to provide source control management, continuous build management (via Jenkins), hosting databases and deploying web applications. Our experience has been very positive and over time it really feels like there is an extra member in our team completely dedicated to our infrastructure.The decision to break from our previous experiences of internally managed infrastructure was not an easy one, we had instinctive fears around Security, Reliability and Flexibility. Without doubt the fremium model helped us get comfortable with using CloudBees, a new company we had not heard of before.SECURITYSecurity was the easiest hurdle to overcome, we absolutely needed to have the infrastructure accessible from outside our physical office. CloudBees had some significant customers who were already comfortable with their security protocols, moreover we reasoned that CloudBees could do as good a job as we could.RELIABILITYReliability has been very impressive, whilst no service can be 100%, we have only experienced one day when CloudBees was down (a period of 3 hours). At that time we were using a free account and I could see from their support on twitter that other paying customers were down for a much shorter period of time. When we have had some technical support questions, the responses have been very quick and of high quality (even during the initial free period). Generally reliability has been significantly better than our experiences with internally managed infrastructure.FLEXIBILITYWhilst there is less freedom than internally managed infrastructure, there is certainly enough functionality to be very effective and we have not found this to be a problem at all. It certainly encourages us to follow standard processes, and we find it to be an excellent example of keeping a service simple yet effective. Furthermore, CloudBees services have grown since we first looked at it, for example one can now easily deploy releases onto amazon web services or google app engine.FREMIUM HURDLESCloudBees uses a fremium model. There are two main hurdles which force conversion from free to premium,

1. the number of minutes of build time
2. number of users

We hit both hurdles in the same month which I suspect is not an accident. I can imagine CloudBees are at such a scale that they can fairly accurately predict when a startup will convert.



Follow CloudBees: