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:
   

From its inception, CloudBees has been about development in the cloud, and Jenkins is at the center of that story. The CloudBees story expanded from there to include deployment and runtime, and easy access to a rich partner ecosystem. As we've added more flexibility and extensibility into our hosted runtime stacks, we've continued to make it even simpler to create and manage the entire continuous delivery process on CloudBees using ClickStarts.

ClickStarts Create Running Apps with Source, Builds, Continuous Deployment and Other Services
When you have these end-to-end capabilities in your hands, already hosted and ready to go, what has become obvious to CloudBees and customers like Choose Digital, is that the sweet spot of the CloudBees PaaS is continuous delivery in the cloud. What's perhaps less obvious is that the growth of mobile and everything-as-a-service is making continuous delivery a necessity, not an option. Mobile drives continuous delivery adoption because of user expectations of frequent updates and because the app store model puts you in an uncomfortable position very quickly - and one you can't extract yourself from quickly - if you ship something that isn't working well. Behind almost every mobile app are hosted services, connecting to your existing systems and to third-party service providers. To be competitive and to take advantage of the mechanics and economics of delivering as-a-service, you want to roll out functionality quickly, experiment cheaply and gather real-time metrics about how your service is being consumed. Continuous delivery -- keeping your software in a release-ready state at all times, and rolling out new releases as often as makes sense for you -- is the way to solve these problems.

Continuous Cloud Delivery Behind the Scenes at CloudBees
So is it just "doing it in the cloud" that makes Continuous Cloud Delivery different from what you should learn from the must-have book, Continuous Delivery? To be sure, using cloud infrastructure gives you a boost. But what you get from CloudBees and our platform delivered as a service, is a lot more than just infrastructure and application hosting. In addition to having CloudBees monitoring and maintaining everything that supports your application, you get on-demand, scale-out access to as many build/test resources as you need, and you only pay for them when you use them. Your developers can instantly deploy to a staging area, test continuously against your real app at scale, connect to other services and tear things down when they're no longer needed. Management and developers can see what's going on at all times and share the results of their work without hiding machines under desks or figuring out how to optimize use of precious shared resources. Push to production when you want to, with confidence that what you're pushing works as expected, and, if needed, can be rolled back.

Check out our white paper for more details. Or better yet, sign up for an account and use one of our many ClickStarts to see for yourself just how easy it is to get up and running with Continuous Cloud Delivery using the technology stack of your choice.


-- Steven G. HarrisSenior VP of ProductsCloudBees, Inc.www.cloudbees.com







Follow CloudBees:
   

Our friends at XebiaLabs, who make the excellent Deployit application release automation solution, just finished a handy survey to learn more about how teams are releasing software in 2013 and see where the hiccups in the pipeline lurk. They talked to folks in financial services, healthcare, insurance, tech, and other industries to find out about current release management processes, release process pain points, and key focus areas for 2013.

We found the results most insightful - here's a snapshot:



Check out the full graphic here (no, you don't need to register, it just didn't fit nicely on our blog).

Automating the continuous delivery pipeline is clearly a step companies know will improve their time to market and software quality, and it's a key initiative for 2013. Fortunately we have tools for that...

 

-- Lisa Wells
CloudBees Partner Marketing Bee

    Follow CloudBees:

   

In a previous blog post in this series about continuous integration for mobile apps with Jenkins, I showed examples of how to run Android builds using remote slaves, in the same way that you might run iOS builds (see this blog for more details on how to set that up).  That's all very well and may be what you need to do in some circumstances, such as when you want to run tests using an actual, tethered device.  However, when developing for Android that's probably not what you would want to do most of the time: you just want your changes to be built and tested automatically against the Android SDK's emulator, only doing actual physical device testing at key milestones.  For these regular automatic build jobs, Jenkins as a service running on the CloudBees PaaS is the perfect tool since we can allocate build executors on-demand, without any software set-up or hardware required.
Another feature of Android development is the number of possible device configurations that a mobile app might need to support.  This contrasts with the iOS world, where there are only a certain number of combinations you need to worry about: sure, you have different iOS versions and several devices (iPad, iPhone, iPod Touch) which could have different memory specs, for example, but with Android there are so many more combinations of underlying system image and device capability to worry about.  Again, Jenkins is a perfect match for this challenge: with its multi-configuration "matrixed" build jobs, Jenkins can kick off any number of similar build/test cycles, all modeled on a single "template" but each running against a distinct set of device characteristics and emulator specs.  You can see an example of a multi-configuration Android build online here and here's the matrix of builds it defines:

As you can see, I've chosen three axes for the matrix build (screen density, locale and architecture) but for a real build system, I could and would add other axes and many more combinations.  The beauty of being able to run all these in the cloud is that I don't have to worry about resources for these builds: Jenkins will automatically allocate executors from the pool of available resources on-demand.  Here's how you would go about setting this up: first, create a new Jenkins job and choose the "Build multi-configuration project" option; then define the axes like this in the Configuration Matrix section:


These axes (density, locale and target-abi) map to the properties (${density}, ${locale}, ${target-abi}) used in the Android Emulator configuration, like so:

You'll find more information on the Jenkins Android Emulator Plug-in page, which also has a nice example of how you can remove elements from the Matrix of builds (for example, where a particular screen density is nonsensical for certain device configurations) using a "Combination Filter" in Jenkins.  Another interesting use for Combination Filters is to have Jenkins automatically select a subset of build configurations from the matrix: during development, you might want only a "sample" subset of device configurations to be tested, as a sanity check, with the full matrix used for formal build milestones.  An example of that would be a combination filter like this: index%2==0; this would select half the build configurations to run (Jenkins will choose the set to ensure that all the axes get as much coverage as possible, within the constraints you set).

When running Android builds (single or multi-configuration) using Jenkins in the cloud, the Android SDK will automatically be mounted: you specify the appropriate Android target in your build properties as in the example below.  The Android project is updated from SCM (and the project workspace refreshed), then we run the android project update command to set the target for the build and update the local.properties file to point to the Android SDK used by the Jenkins executor(s).  Here's what the build configuration looks like, with the relevant output from the Jenkins console:


Running multi-configuration build/test jobs makes continuous integration for Android development a practical reality, without the need to configure test environments and schedule runs manually.  Every time you make changes to the code, you know that those changes will be tested across the huge range of devices, locales, settings and environments that you will need to support.  


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:

   

Identifying @risk users in lifecycle marketing

CloudBees is the leader in the Continuous Integration (Jenkins) and Continuous Cloud Delivery (DEV@cloud) world. It was inevitable that we would start examining our lifecycle marketing practice through the continuous-improvement lens.

A while ago, we started grappling with the issue of understanding how developers used our Platform as a Service (PaaS) and how we could identify at-risk users. This blog describes the mechanism underway to solve this issue in an initiative called Continuous Engagement (what else :-)?) .

Side note:
Cloud application providers can micro-segment users based on actual usage of software. Examples of micro-segmentation are: users who deployed a database, users who deployed a database greater than 5GB in size and so on. Such segmentation is feasible, as cloud providers run applications in-house and have visibility into every nook and cranny of the system. Running software in the cloud is a tremendous advantage over the previous generation of packaged software where, even though the software could be instrumented, in-house adopters would be wary of sending any data outside the firewall.

We started by instrumenting our PaaS to emit interesting events that are logged into a third-party Software as a Service (SaaS) provider called Totango (Totango helps analyze the usage of software).

Since we are in the application lifecycle business, the events of interest are things like:

• Login into our web console
• Deploy an application
• Jenkins job started
• Database deployed

... you get the idea.

We can then start doing interesting things with this data.

We divided our funnel into 3 segments, each with multiple points in the adoption lifecycle. It is perhaps better to show this visually than to talk about it. The accompanied image shows a simplified view of our funnel.

The top end of our funnel are the "onboarders," essentially users who signed up with us in the last 4 weeks and are using the platform free (CloudBees has a free tier). Moving down the funnel, we have the "established" sub-segment, free users make it here if they have a met a threshold of usage on the platform. Now this is where Totango shines as we can use the actual usage of services on the platform to move people from onboarders->established and down the established funnel. The paying list is a list of users.

In traditional inbound marketing, you would walk these people down the onboarders funnel through marketing campaigns on services like Marketo (in fact, we still have a few campaigns like those, but I suspect they will bite the dust compared to the "continuous engagement" juggernaut). However, with those models you cannot move people up and down the funnel based on actual usage. Here, you can be an established-yellow this month and back to established-green next month. The last bit is that at each of the checkpoint locations within a particular funnel (say "established-lost"), we can send them personalized emails that are based on the actual usage or have a customer success manager reach out to the users.

I will blog about specific use-cases over the next few months, as we continuously improve our continuous engagement process (for example: how do you set up weekly usage reports in a cloud-based environment) and build on this image (we are actually farther along than what I have shown here).

PS: I am giving a short use case presentation at the Totango Summit this week about this use case.

- Harpreet Singh, 
Senior Director of Product Development, CloudBees
www.cloudbees.com 

Harpreet has 14 years of experience in the software industry. Prior to CloudBees, he was at Oracle and Sun for 10 years in various roles, including leading the marketing efforts for Java EE 6 and GlassFish 3.1. He was also product manager for Hudson, launching it within Sun's GlassFish Portfolio.



Follow CloudBees:

   

This morning, we announced support for deployment from DEV@cloud Jenkins build jobs to Cloud Foundry's PaaS: I've done a short video that shows how easy it is to set this up (we've done ClickStarts with a couple of well-known Spring/Grails projects) and I've also written a guest blog on the Cloud Foundry site that goes through how it all works.  I'm really happy to see this integration - our vision for DEV@cloud is all about a complete, fully cloud-based continuous delivery platform, regardless of where you choose to run the applications that you build.

Rather than cover the same ground as the Cloud Foundry blog, I wanted to drill down a little into what's going on and how you can use this in your own projects: I've included a couple of examples, based on the ClickStarts, on our partnerdemo account that you can use as a reference.


First, let's take a look at how we secure access from your CloudBees DEV@cloud account to the Cloud Foundry deployment services.  CloudBees and Cloud Foundry both support the industry-standard OAuth 2.0 protocol, allowing you to establish a trust relationship between your accounts without the need for either party to store account details like passwords from the other service.  To do this, just go to https://cloudfoundry.cloudbees.com, which will redirect you to the standard Cloud Foundry log in page.  Log in with your Cloud Foundry credentials and authorize your CloudBees account to deploy to your Cloud Foundry account:


You'll be asked to confirm that authorization on the CloudBees side as well and you'll get an email confirmation: if you happen to have multiple accounts associated with your CloudBees login email address (I'm guessing most people don't, but just in case you do), then you can choose which accounts you want to link to your Cloud Foundry account.  The other thing to bear in mind is that it's quite normal for an OAuth token to expire - in fact it's a good thing and you should expect to be asked to re-authorize your account periodically.  I believe that Cloud Foundry's current policy is to ask you to renew authorization every 30 days, but of course that might change.  Anyway, CloudBees will send you an email to let you know if any of your builds are unable to deploy to Cloud Foundry because the auth token has expired, so you'll be able to take action.  Just go to cloudfoundry.cloudbees.com and re-authorize for that account.
For deployment to Cloud Foundry, choose "Deploy applications" from the Post-build Actions drop-down menu in the usual way, and when you go to select a Host Service you'll see "Cloud Foundry" as an option with "CloudBees RUN@cloud service".  In fact, if you've already enabled deployment to Google App Engine, you'll see that as an option as well.  The whole mechanism for adding deployment targets is completely generic: if you're curious, take a look at the installed Jenkins plugins for your account and you'll see how it works.  There's a Cloud Foundry Deploy Engine Plugin that manages the actual deployment, plus OAuth Credentials and Token Provider plugins.  There's also a Cloud Foundry ClickStarts plugin, which provides a convenient launcher for the Spring and Grails ClickStarts - you'll see that in your top-level Jenkins menu.
Modulo the OAuth mechanisms, which we clearly don't need for our own services, the way we deploy to RUN@cloud works in exactly the same way: there's a CloudBees Deployer Plugin that implements those same interfaces to make RUN@cloud a Host Service, just as we do for Cloud Foundry and Google App Engine.  That might seem surprising, but we're very serious about making the cloud an open space for continuous delivery, however you decide to deploy your apps.
The details of how to configure the Cloud Foundry deployment are shown below.  This is taken from the Grails PetClinic application (the source is on GitHub), which is one of the two ClickStarts that we provide to get you started:

There a couple of points to notice here.  We follow the Cloud Foundry convention and omit the scheme when specifying the Deployment URL; however, don't forget that this needs to be unique.  There are plenty of ways to do that, but for the ClickStarts I decided to add -${account} to the application name, so that the actual deployment URL would be e.g. http://petclinic-grails-partnerdemo.cloudfoundry.com. 
Note also that this application uses a MySQL service on Cloud Foundry and we can simply specify this as part of the deployment.  When I took the screenshot, the job had already run, so that's why you see the message that the service exists and will be bound to the application as-is: if you create a job from scratch, you'll see an equivalent message that the service doesn't exist and will be created for you.  You don't need a globally-unique name for services, by the way, so no need for the -${account} trick.  The Spring example uses postgres and redis services in exactly the same way.  There is full documentation on how to use the plugin to deploy from DEV@cloud to Cloud Foundry on the Cloud Foundry GitHub site.
That's pretty much it.  We've pre-configured things on DEV@cloud to use a pre-installed 2.2.0 version of Grails, to make the build go faster.  If you're setting up your own Grails jobs, don't forget that you need to configure the Grails installation(s) as part of the Jenkins global settings (Manage Jenkins -> Configure System -> Grails).  If you're interested in how we built the ClickStarts, you can find them on GitHub (cloudfoundry-grails and cloudfoundry-spring).

• Try CloudBees DEV@cloud on Cloud Foundry - it's all free: https://cloudfoundry.cloudbees.com
• Read the Cloud Foundry blog tutorial

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:

   

A guest post by Krishnan Badrinarayanan, one of our good friends at ZeroTurnaround

Why bother? Happy users and $$$ … DuhIf you are a SaaS vendor, provider of online apps, or an online retailer, offering 24/7 uptime is essential to the success of your business. Any downtime means lost revenue or unhappy customers. At the same time, your customers expect only the best from you. Your predicament: how do you release all those awesome improvements without calling for maintenance windows so that you can push updates frequently?

Ideally, you’d like to release updates frequently, without impacting user experience. Fail to do so and you risk driving users to competitors or other alternatives. Great products give you a competitive edge and most importantly, lead to loyal customers.

How do Dev, QA and Ops teams rise to the challenge?Development and QA teams create, build and test products and features rapidly as users demand more, with productivity tools from CloudBees at their disposal. Operations teams then follow through to deliver updates to users as quickly as possible without interrupting service or compromising stability. This usually means calling for a maintenance window at 3AM on a Sunday. And this still doesn’t ensure that no user is interrupted! Plus, if something were to go wrong, the folks that can help fix it are usually sound asleep at home during these midnight deployments.

Enter Continuous Delivery (Continuous Integration + Release Automation)
How do you continuously deliver cool features to your users, proactively, seamlessly and reliably? And during business hours without impacting user experience? Answer: The right kind of AUTOMATION.

With the right tools, you can implement a single application deployment pipeline - from developer to user - with all the checks to ensure that no bugs find their way to users. Your team should be able to develop, safely test and deploy updates seamlessly and as frequently as required, without impacting user experience. This is more or less the Continuous Delivery that we aspire for.

Tooling for Continuous Delivery with Jenkins and LiveRebelAn excellent set of tools is - Jenkins Enterprise by CloudBees and ZeroTurnaround’s LiveRebel, for release automation and management - will help build an application deployment pipeline. Once implemented, the diagram below shows how code updates go from developers, through QA and staging, into production, and in front of your users. We will go over each stage one by one.


 

1. Develop: Developers, based on user needs and feedback, quickly develop features using their favorite IDE and commit them to source control.
2. Integrate: The code changes are then integrated using Jenkins Enterprise by CloudBees. If the integration fails, Jenkins immediately sends feedback to the developers who then proceed to fix it. Once the build is generated by Jenkins, it is passed over to LiveRebel via a readily available plugin.
3. Deploy: ZeroTurnaround’s LiveRebel deploys the build with database and configuration changes across environments of your choice - whether it is hosted by CloudBees, in the cloud, or in your datacenter. In the example above, LiveRebel deploys to the testing and staging environments where UAT and staging tests are run, and then to production, with zero downtime and without disrupting user experience.

The benefit: Reduced risk, more user feedback, happy customers!Practicing Continuous Delivery enables software teams to automatically release features, however small, regularly. Users get to try them right away and provide feedback immediately via social media, forums, email or other channels you can listen into. You are also exposed to a lot less risk since you avoid making massive updates that could run successfully in testing but fail in production (dang!). With LiveRebel, if a deployment were to fail in production, it will automatically rollback to the previous state without impacting users.

Setting Up Your OwnYou will need to first install both Jenkins Enterprise by CloudBees and LiveRebel. As you proceed to do so, you will receive information on how you can configure them individually.

•     Jenkins Enterprise by CloudBees; free for 30 days
•     LiveRebel; free for all time when you deploy on up to 2 managed servers

Then take a few minutes to install and configure the LiveRebel plugin for Jenkins and follow these instructions.

You are now tooled up and ready to practice Continuous Delivery!By integrating LiveRebel with Jenkins Enterprise by Cloudbees, you have now created a application deployment pipeline right from development, through QA and Ops, directly to your users. You and your team can now confidently practice Continuous Delivery and provide your users new features with 24/7 uptime. Plus, you and your colleagues will get to sleep soundly on deployment Sunday!



Krishnan Badrinarayanan is the product marketing manager for LiveRebel, ZeroTurnaround's application release automation and management tool that helps software teams take products to users faster. A Java geek turned product marketer, Krishnan is well versed with issues that plague IT teams and is passionate about applying technology to solve their challenges. Prior to ZeroTurnaround, Krishnan held various positions within large, mid-sized and start-up companies.

Follow CloudBees:   

Recently been quite a few people on holidays, some burning from the heat, others freezing (the joys of a global company). But here are some recent random technical postings from the CloudBees development team:
1. AngularJS clickstart released - AngularJS being the hottest new JS thing at the moment (this ClickStart sets up a build/test and app using Angular for you)
http://developer-blog.cloudbees.com/2013/01/angularjs-html-for-apps-try-it-now-as.html
2. Michael talks about a nasty lesson he learned about dependencies while at University: http://developer-blog.cloudbees.com/2013/01/the-most-insidious-bug-ever-why.html
3. Stephen rips out some mean shell scripting and R to make graphs of contributions to popular open source projects: http://developer-blog.cloudbees.com/2013/01/does-community-matter-oh-and-git-is.html
4. Stephen writes (rants?!) about the art and craft of API design:http://developer-blog.cloudbees.com/2013/01/api-design-is-craft-and-you-don-have-it.html

-- Michael NealeElite Developer and ArchitectCloudBeeswww.cloudbees.com
Michael is an open source polyglot developer. For his sins he spent time at JBoss, working on the Drools project, and then Red Hat, where he continually caused trouble on various projects. His interest in the cloud is natural, as he is attracted to disruptive technologies. Michael lives and works in the Blue Mountains, just outside Sydney, Australia. Follow Michael's daily struggle on Twitter or on his blog.
Follow CloudBees: