This year, the West Coast Jenkins User Conference will be in Palo Alto rather than San Francisco. If you’re nearby – or even if you’re not – join Kohsuke and other fellow developers for a solid day of Jenkins.

• The Date: Wednesday, October 23, 2013
• The Venue: Palo Alto Jewish Community Center
• Details
• Register

The Call for Papers is open until June 9 (scroll to bottom of page for form). JUC will be much better with your involvement, so please submit your abstracts and share your Jenkins knowledge with the community.

A very special thanks to our JUC Palo Alto sponsors, who will make sure you are fed, caffeinated, clothed (in this year’s collectible Jenkins tshirt), and generally well cared for at the conference: CloudBees, JFrog, XebiaLabs, appvance, ZeroTurnaround, LMIT Software, Black Diamond Software, New Relic, Liferay, AppDynamics, and SOASTA.

Two other differences this year – the conference is not timed to coincide with JavaOne, and it falls on a Wednesday rather than a Sunday. We thought we’d try these changes and are interested to know if they work better for everyone.

The agenda won’t be populated until after the Call for Papers closes and talks are selected. But you can check out previous JUC agendas, slides, and video:

• 2012 JUC San Francisco
• Inaugural JUC San Francisco - 2011

If JUC Palo Alto is not convenient for you, there’s also a JUC coming up in Herzelia, Israel on June 6 and a Jenkins event planned for Copenhagen, Denmark on September 6.

Hope you can join us at JUC!

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:
   

The current webcomic on xkcd.com titled “Is It Worth The Time” has a fantastic table listing how long you can work on making a routine task more efficient before you’re spending more time than you will save, based on a 5-year payback plan.

As a company spending most of our time and effort focusing on the general problem of accelerated software development and delivery, this is obviously great data and icing on the cake that can be used to justify the value of our solutions and offerings.

How much time and effort are you spending today optimizing and accelerating your software builds, tests and release processes?

It's been a while we had a hackathon in Germany. Let's get together, get some coding done, and get to know fellow Jenkins developers! The date is June 15th Saturday.

TNG Technology Consulting, where Stefan Wolf (dependency graph viewer plugin, etc) works, will be hosting us (thanks!)

We'll try to arrange some themes or agenda, based on who's coming and how many of us will be there. For example,

• If there are many people who have never done a plugin development, we can do a plugin development tutorial.
• If we see a concentration of devs in a specific area of Jenkins (say mobile), we can try some focused development in a specific area.
• If you have things you need from the core to do what you want, this is the chance to get that implemented on the spot!
• If you want to see a certain development happen in Jenkins but don't know how, please make a pitch to us in the form of presentations (short or long) would be welcome

Finally, assuming there's interest, we'll head out somewhere for a dinner afterward.

If you are interested in coming, please RSVP at meetup.com so that we can prepare accordingly.

It's been a while we had a hackathon in Germany. Let's get together, get some coding done, and get to know fellow Jenkins developers! The date is June 15th Saturday.

TNG Technology Consulting, where Stefan Wolf (dependency graph viewer plugin, etc) works, will be hosting us (thanks!)

We'll try to arrange some themes or agenda, based on who's coming and how many of us will be there. For example,

• If there are many people who have never done a plugin development, we can do a plugin development tutorial.
• If we see a concentration of devs in a specific area of Jenkins (say mobile), we can try some focused development in a specific area.
• If you have things you need from the core to do what you want, this is the chance to get that implemented on the spot!
• If you want to see a certain development happen in Jenkins but don't know how, please make a pitch to us in the form of presentations (short or long) would be welcome

Finally, assuming there's interest, we'll head out somewhere for a dinner afterward.

If you are interested in coming, please RSVP at meetup.com so that we can prepare accordingly.

You can see your Jenkins build history and re-deploy the older APKs from your Mobile Phone !

This is particularly useful when you want to have multiple of version of your Mobile App to your QA or Beta Testers (just like you !) without having to redeploy or notify anyone: you can go back and forth in a time-machine as many times you want !

Jenkins acts like a APK binary repository with full access to:

• Code changes
• Unit-test executions
• Console output

Join JenkinsMobi V4 Beta now and give your feedback today.

Pulse 2.5.24 has been released. This is a stable build in the 2.5 series. Changes include:

• A security fix for password hash exposure in configuration audit logs.

See the release notes for full details.

Pulse 2.5 packages are available from the downloads page.

Guest post by Yury V. Zaytsev and Abigail Morrison. To download the PDF file of the journal article mentioned below, click here!

As recently exemplified by several reports on this blog, automation tools such as continuous integration servers, that help to defuse the exploding complexity of software under the ever-increasing pressure to deliver, are steadily gaining well-deserved mindshare in the industry.

However, it is not just developers of enterprise software who need solutions to the complexity problem. Scientists are arguably even worse off: most of them are not trained as software engineers, yet, in the last decades, creating custom software has become an integral part of virtually any research activity, be it data analysis, simulation or experiments. Frequently, there is a great emphasis on numerical accuracy and reproducibility of results, which requires extensive testing. As a coup de grâce, most publicly funded research projects are running on tight budgets, excluding the possibility of hiring professional contractors to outsource required software development work.

Enter Jenkins the Butler!

Back in 2011, Yury V. Zaytsev, a doctoral candidate now working at Jülich Research Center, Germany was supported by a Google Summer of Code stipend to design a continuous integration infrastructure for NEST, a spiking neuronal network simulator for neuroscientific research released under the GPL license. An overwhelmingly positive experience with this new setup motivated him to write up a case study, which was recently published in "Frontiers in Neuroinformatics", an open access scientific journal.

"The new CI system boosts our productivity, because it helps us find and fix breakages very quickly, even when they only occur for obscure combinations of configuration options. Automated integration testing is a major breakthrough for NEST, as it ensures that developing new features does not come at the cost of reliability or accuracy" - said Markus Diesmann, director of the Institute of Neuroscience and Medicine (INM-6) at the Jülich Research Center, Germany and NEST Initiative board member.

We hope that through a peer-reviewed publication in a prominent scientific journal we will be able to reach the scientific community more efficiently, as compared to the materials targeting professional software developers. However, we likewise believe that our case study might be of interest to the readers of this blog, especially those who are still only considering implementing continuous integration.

Lastly, we would like to thank all developers and users of Jenkins whose contributions throughout the years made it the versatile and robust continuous integration server it is today!

Guest post by Yury V. Zaytsev and Abigail Morrison. To download the PDF file of the journal article mentioned below, click here!

As recently exemplified by several reports on this blog, automation tools such as continuous integration servers, that help to defuse the exploding complexity of software under the ever-increasing pressure to deliver, are steadily gaining well-deserved mindshare in the industry.

However, it is not just developers of enterprise software who need solutions to the complexity problem. Scientists are arguably even worse off: most of them are not trained as software engineers, yet, in the last decades, creating custom software has become an integral part of virtually any research activity, be it data analysis, simulation or experiments. Frequently, there is a great emphasis on numerical accuracy and reproducibility of results, which requires extensive testing. As a coup de grâce, most publicly funded research projects are running on tight budgets, excluding the possibility of hiring professional contractors to outsource required software development work.

Enter Jenkins the Butler!

Back in 2011, Yury V. Zaytsev, a doctoral candidate now working at Jülich Research Center, Germany was supported by a Google Summer of Code stipend to design a continuous integration infrastructure for NEST, a spiking neuronal network simulator for neuroscientific research released under the GPL license. An overwhelmingly positive experience with this new setup motivated him to write up a case study, which was recently published in "Frontiers in Neuroinformatics", an open access scientific journal.

"The new CI system boosts our productivity, because it helps us find and fix breakages very quickly, even when they only occur for obscure combinations of configuration options. Automated integration testing is a major breakthrough for NEST, as it ensures that developing new features does not come at the cost of reliability or accuracy" - said Markus Diesmann, director of the Institute of Neuroscience and Medicine (INM-6) at the Jülich Research Center, Germany and NEST Initiative board member.

We hope that through a peer-reviewed publication in a prominent scientific journal we will be able to reach the scientific community more efficiently, as compared to the materials targeting professional software developers. However, we likewise believe that our case study might be of interest to the readers of this blog, especially those who are still only considering implementing continuous integration.

Lastly, we would like to thank all developers and users of Jenkins whose contributions throughout the years made it the versatile and robust continuous integration server it is today!

Rundeck community member Will Sterling (from Datalogix) did a great presentation introducing Rundeck to the Colorado Linux Users and Enthusiasts meeting in Denver.

Alex Honor posted a helpful writeup on rundeck.org:

If you are new to Rundeck, watch Will Sterling give an introduction to what Rundeck can do and how he uses it to automate work at DataLogix.

Here are some notable quotes:

• “Multi-tentant command orchestration and process automation with WebGUI, CLI, and RESTful API.”
• “Target nodes with rich metadata. Never use hostnames again.”
• “Process automation via multi-step jobs…Options allow users to pick one or more values.”
• “Rundeck makes everything in the GUI available through the API.”

Besides showing off the basics, Will opened up Eclipse to step through ruby code that talks to Puppet to communicate node information to Rundeck. His code only includes nodes he can ping and have a certain class.

Will also showed off how he uses resty as nice shell based way to access the Rundeck API.

 

The post Will Sterling presentation on Rundeck at the April CLUE Meeting (Video) appeared first on dev2ops.

JenkinsMobi V4 Beta program continues with the support of Assembla SSO Login.

Assembla.com is Cloud ALM that provides Project Workspaces, featuring project management software elements such as task management, issue tracking, cardwall (Kanban), agile project management, Git/Svn  repositories and scrum meetings.

When you configure Jenkins with Assembla Auth Plugin the Jenkins Login process goes through the Assembla SSO Form-based login: this is now automatically managed by JenkinsMobi V4 Beta.

As usual, everything is plug&play: just enter your Assembla Credentials in the JenkinsMobi settings … and then play with JenkinsMobi V4 Beta !

Reblogged from GitEnterprise:

GerritForge is proud to organise the first European Gerrit Code Review Hackathon in London (UK) for three days: 7th, 8th and 9th of May 2013.
The Hackathon is a great way to have the core Gerrit developer Team working side-by-side on some new exciting new features for the OpenSource community. Some of the major improvements in Gerrit architecture and functionality came out from past Hackathons.

Read more… 23 more words

Keep calm and Gerrit Code Review Hackathon

Stuck in old legacy? Fighting a slow development process? Are complex dependencies between teams and product architecture prohibiting your ability to innovate? Struggling to adopt or scale Agile?

A few weeks back I read “A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware” by Gary Gruver, Mike Smith and Pat Fulghum.
This is a very hands-on and quick read that articulates practical solutions to many common issues and challenges in a large-scale development organization – legacy product architecture, team organization, quality issues, and efficiency of product delivery. The book introduces an interpretation and conceptual practical realization of Lean and Agile methodologies, applied in the context of large-scale embedded product development. The reported Before/After-metrics are astoundingly impressive – I’m leaving the detailed metrics out of this post for readers of the book to take away.

The whole approach at HP Firmware and their transformation is admirable and very intriguing to read about. Below are my main takeaways and what I appreciated learning about the most:

• Their vertical “thin-slicing” approach to refactoring a legacy product architecture in order to quickly understand and meet business objectives.
• Their planning and estimation management using the role of a System Engineer and common Agile planning and estimating techniques. Essentially a System Engineer at HP Firmware is an experienced engineer with enough talent and oversight to understand both internal technical engineering and external customer and market needs – an interesting role that I would say is fairly uncommon in other similar organizations.
• Their diligent and phased test automation management. Fully integrated and automated into their Continuous Delivery process, I appreciated their approach and process of constantly monitoring and optimizing what tests to run at what phase of their test automation implementation.
• “The key is not to manage by metrics but to use the metrics to understand where to have conversations about what is not getting done”. Very well said.

If you’re looking for a concrete and real case study on how to transform a large-scale development organization, I can definitely recommend getting a copy of this book. Read it through, then start discuss and work with your peers to agree, identify and understand what your goals, needs and current pain points are. From there on, it’s an ongoing process of Continuous Learning and Improvement!

Good luck!

Join our embedded webinar presented by VDC Tuesday, April 16th, at 9AM PDT/ 12PM EDT/ 4PM GMT

Register now:

http://www.electric-cloud.com/about/events-webinar-041613-electric.php

We all know that Agile enables software organizations to continuously deliver working software faster to customers (internal or external).

This helps software teams to not only deliver products faster but also in tune with the changing market needs. In practice however, organizations still struggle to get the full benefits of Agile methodology because they have not fully automated their practices (development, build, test, release).

Join us to hear Christopher Rommel, VP of M2M and Embedded Technology at VDC, address the fundamental issues and recommendations you should consider as you adopt Agile:

- Drivers for adopting Agile

- Critical organizational, process and tooling issues to consider and pitfalls to avoid

- Recommendations on how to do this right by automating your processes

I will be co-presenting with Christopher and look forward to your participation on this great topic.  This 1-hour webinar will be held on Tuesday, April 16th at 9am PDT.

Register now:

http://www.electric-cloud.com/about/events-webinar-041613-electric.php

Pulse 2.5.23 has been released. This is a stable build in the 2.5 series. Changes include:

• A bug fix for permission enforcement when pinning builds.

See the release notes for full details.

Pulse 2.5 packages are available from the downloads page.

When you configure Jenkins with OpenID SSO, the authentication phase goes through an external web-site (GitHub, Google or others) for authenticating your credentials: when authentication succeded, Jenkins gives you a Session-ID to continue using the API until the session expires.

From JenkinsMobi V4.6.1 (see how to upgrade from JenkinsMobi home screen) you can even automatically manage a 2-step SSO Authentication with your Google Account and Google Authenticator.

1. Edit your JenkinsMobi settings and put your Jenkins URL and SSO username and password.
2. Whenever your Google SSO request a 2-step authentication, you will see a pop-up asking to enter your one-time verification code
3. Tap on “Auth App” to jump directly to Google Authenticator
4. Read the verification code and tap on the “back” button of your Android phone
5. Enter the verification code and tap Verify
6. JenkinsMobi contacts Google SSO and enters again your SSO credentials and one-time verfication code

Your authenticated session will last for the time-to-live of Jenkins Session: should the session be disconnected, you would need to go through the Google SSO and 2-step verification again.

Enjoy JenkinsMobi with Google Authenticator securely over the Internet

Today, Electric Cloud is announcing the immediate availability of ElectricAccelerator 7.0. This release brings significant new innovations and performance enhancements to the market for anyone looking to optimize and accelerate their software build environment.

We have publicly launched and talked about some of the new capabilities of this release already, back in February at the Android Builders Summit – here is a blog about what was presented.

The marquee features of ElectricAccelerator 7.0 are Parse Avoidance and Dependency Optimization:

• Parse Avoidance significantly reduces makefile parse time. By caching and reusing parse results, this feature can speed up both full builds and incremental builds.
• Dependency Optimization improves performance of a build by optimally schedule the workload in the build based on the actual dependencies, efficiently removing any superfluous dependency-information.

Apart from performing the upgrade, existing ElectricAccelerator customers will be able to take advantage of this release with no necessary changes of their build environment.

Below is a table of some of the internal benchmarks we have run as part of qualifying this release. Both builds are Android-based, with stock vanilla Android Jelly Bean 4.1.1 on the left and CyanogenMod 10.0 on the right.

We were using a 48-core machine for all the benchmarks presented above, percentages in blue refers to the relative performance improvement when Dependency Optimization and Parse Avoidance are enabled.
The columns named “48 agents, Remote” shows the benchmarks when ElectricAccelerator was configured in a distributed build cloud mode, with all computational workload being federated over the network to a remote 48-core machine through the ElectricAccelerator cluster-architecture. The “48 agents, EADE” columns show the results when ElectricAccelerator Developer Edition was being used on that single multi-core machine, with no distribution capability across remote machines. As you can see, significant performance improvement of both full and incremental builds in both setups!

Today, Electric Cloud was selected as a 2013 Cool Vendor by Gartner. We strongly believe that the selection is  a testament to the value that we provide to the Dev and Ops team in today’s fast paced application release process.

Gartner has always considered automation as a key cornerstone of DevOps and Electric Cloud solutions automate and accelerate the build-test-release-deploy processes. More importantly, our solutions  provide a common set of tools that can be used by both the Development (Dev) and Operations (Ops) organizations.  Dev and Ops can use the same deployment solutions  (ElectricDeploy) which improves the reliability of deployments; Dev and Ops also share a common release management process (ElectricCommander) that increases  visibility and quality of the released application.

The net result is that our solutions helps Dev and Ops work well together and improves the efficiency of the application release process. And that is exactly the benefit that hundreds of our customers have seen with our solution.

We are very pleased with the Cool Vendor selection. Stay tuned – we will announcing many more innovative solutions targeting the DevOps market.

We’d all love to be DevOps ‘Ninjas’ – ready and equipped to overcome all the challenges thrown at us on a daily basis. However, the truth is that most of us are merely ‘white belts’, struggling to get past the incessant deployment roadblocks obscuring our path.

Help is at hand! We can help you overcome these roadblocks with four techniques and tools:  

Tip One: Know the Process

Having one single pathway to product is vital for the implementation of a successful DevOps culture

It’s important to make sure that you have approvals (manual or automated) set up between every stage of the process. Your choice of process automation technology will depend on the ability to model both automated and manual approvals. Even if you want a fully automated continuous delivery platform, it’s better to adopt technology that is able to handle both automated and manual approvals if necessary.

Tip Two: Automate Your Processes

It doesn’t matter whether you’re in development, QA or operations – I’m sure that you’ve all been in the frustrating situation where it works on your machine but errors are occurring in another environment.

So what can we do to avoid this? If development and operations work closely together, there shouldn’t be any surprises about the choice or architecture or hardware. Close collaboration should enable operations to provide environments that very closely reflect the production environments. Virtualization is key! You need to be able to spin up instances on demand in order to avoid hardware-driven bottlenecks. If you give developers environments that closely resemble production, you can test changes against properly configured environments in the early stages of the deployment process.

Tip Three: Enable Reproducible Deployments

There are many different types of deployment automation. At the very least, most people have some kind of basic script to perform deployment automation at some level. As architectures and environments increase in complexity, so do the scripts. However, the scripts don’t always work for all of the environments and the authors are often too busy to maintain them once they’ve become too complex. Writing scripts in order to handle integrations to multiple systems and deploy products isn’t usually a core competency in a company.

Luckily, there are tools on the market like Puppet and Chef which give the ability to perform many low level operations easily. However, there is still a need for deployment automation that can integrate all aspects of the software development lifecycle. Custom integrations can be complex, time-consuming and fragile but they are critical in establishing and maintaining end-to-end traceability.

Tip Four: Put all the Pieces Together

Most companies won’t throw out technologies that are already set in place. Most deployment automation tools can handle integrations when applications are being deployed but there are many ‘touch points’ in the process. These include: issue tracking, continuous integration, test automation, requirements management and application monitoring. The process management layer should be capable of exchanging information by receiving information or pulling it from another system. With the higher-level process management framework in place, you have ensured traceability

All of the tips and techniques listed above will help you get on the path to being a DevOps ‘Ninja’. They will help you remove your deployment roadblocks and eliminate your problems easily and with minimum effort.

This article, Want to be a DevOps “Ninja”?, is based on an original post in DevOps Angle.

 

 

Thanks to the first feedback of the JenkinsMobi V4 Beta, today we have certified JenkinsMobi with OpenID: you don’t have to do anything, just insert your OpenID credentials in the JenkinsMobi V4 settings and, if you have Jenkins-OpenID SSO, everything will magically works