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
PS - Got something for the next newsletter? Please drop us an email.
-- Lisa Wells
CloudBees Partner Marketing Bee & Managing Editor, Continuous Information
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!
Vice President of Worldwide Sales
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.
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:
- 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.
- 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:
- 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.
- 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.
- 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.
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.
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
You can also learn more on the APIs are not Copyrightable Facebook page.
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.
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:
- build and deploy the IOS app capable of running SOASTA functional tests to devices tethered to the mobile lab;
- kick off SOASTA functional tests;
- 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.
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.
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.