Jenkins Blogs

Syndicate content
Pipes Output
Updated: 9 min 3 sec ago

New Wiki URL Requirement for Plugins

Mon, 2015-06-22 06:03

Let's say you're browsing the 'Available' tab in the Jenkins plugin manager for interesting-looking plugins. How do you learn more about them, preferably without installing them on your production instance? You click the plugin's name, which usually links to the plugin's wiki page, of course!

Unfortunately, it's possible for plugins to be published without a wiki page, or any other documentation aside from what's provided in the plugin itself. This is really unfortunate, as users rely on wiki pages and similar documentation to learn more about a plugin before installing or upgrading it, like its features, limitations, or recent changes. Additionally, plugin wiki pages have a special section at the top that provides an automatically generated technical overview of the plugin, such as dependencies to other plugins, the minimum compatible Jenkins version, a list of developers, and links to the source code repository and issue tracker component. Everyone learning about or using a plugin benefits from a plugin wiki page and luckily, almost all plugins have one!

To ensure that every plugin has at least a basic wiki page with some documentation, we decided to only publish plugins in the Jenkins update center that have and link to a wiki page. To keep the impact to a minimum, we're implementing this plan in several stages.

The first stage went live on June 1: All existing plugins that don't have a (valid) wiki link got a wiki link assigned by the update center (a so-called 'override'), either to an existing wiki page if there was one, or a generic "This plugin has no documentation" wiki page otherwise. This ensures that no currently existing plugins get dropped from the update center at this point. Of course, new plugins that don't provide a wiki URL and don't have an override URL will not show up at all.

The second stage will be enabled later this year: We're planning to remove all the overrides mentioned above. At this point, plugins may get removed from the update center if they still don't specify a wiki URL. Of course this isn't our goal, and we'll try to work with plugin authors to prevent this from happening.

So what can you do? Check the current overrides list to see whether the plugins you care about are affected, and if so, see the landing page in the wiki to learn what you can do. If you have any questions about this process not covered by the wiki, ask us on the Jenkins developers mailing list.

JUC Speaker Blog Series: Martin Hobson, JUC U.S. East

Tue, 2015-06-16 15:19

I’ve been using Jenkins for some time now as the build server for the various projects that are assigned to our four-person software development team, but recently I had exposure to how things were done in a much larger team, and I came away with a better understanding of the kinds of demands that are placed on a build pipeline in these environments. It was quite an education – while the CI pipelines that I administer in our small team might require a handful of virtual machines in our corporate cloud, the pipeline in this team supported over one hundred developers and required several hundred VM instances at any given time.

When operating at this scale, efficiency does become important, as the Amazon cloud charges add up and become significant at this level. Using some relatively simple techniques, I was able to gain insight into what actually happened in the more complex build jobs and learned just how these VM instances were utilized. These build jobs configured over a dozen virtual machines each, and understanding the startup and execution flows was critical to making changes and improving efficiencies. I will be discussing how to instrument and analyze these complex builds in my Lightning Talk: "Visualizing VM Provisioning with Jenkins and Google Charts” and hope to see you all there!

This post is by Martin Hobson, Senior Software Developer at Agilex Technologies. If you have your ticket to JUC U.S. East, you can attend his lightning talk "Visualizing VM Provisioning with Jenkins and Google Charts" on Day 1.

JUC IS HERE! JUC U.S. East will begin with registration at 7AM, Thursday June 18. The two day conference is sure to be a blast! If you have not registered, you can still get a ticket! Check out the agenda for JUC U.S. East here and find the link to register.



Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Stephan Hochdörfer, JUC Europe

Mon, 2015-06-15 10:50

I am very much looking forward to the Jenkins User Conference in London where I will present our insights on how to use Jenkins in a PHP related environment. Moving to Jenkins about 5 years ago bitExpert gained a lot of experience in running and managing a distributed Jenkins infrastructure. bitExpert builds custom applications for our clients which means that we have to deal with different project infrastructures, e.g. different PHP versions. We heavily rely on the build nodes concept of Jenkins which I will briefly outline in the session. Besides that I will give some in-depth insights on how we use Jenkins on a daily basis for the "traditional" CI related tasks (e.g. linting code, checking code style, running tests) as well as how Jenkins is used to power our integration tests. Last but not least I will cover how Jenkins acts as a kind of backbone for our Satis server which allows us to host the metadata of our company's private Composer packages. Throughout the talk I will point out which Jenkins plugins we use in the different contexts to give you a good starting point if you are new in the Jenkins ecosystem.

This post is by Stephan Hochdoerfer, Head of Technology at bitExpert AG. If you have your ticket to JUC Europe, you can attend his talk "Jenkins for PHP Projects" on Day 2.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.



Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Damien Coraboeuf, JUC Europe

Tue, 2015-06-09 13:54

Scaling and maintenance of thousands of Jenkins jobs

How to avoid creating of a jungle of jobs when dealing with thousands of them?

In our organisation, we have one framework, which is used to develop products. Those products are themselves used to develop end user projects. Maintenance and support are needed at each level of delivery and we use branches for this. This creates hundreds of combinations.

Now, for each product or project version (or branch), we have a delivery pipeline. We start by compiling, testing, packaging, publishing. Then we deploy the application on the different supported platforms and go through different levels of validation, until we’re ready for delivery. Aside from a few details and configuration elements, most of the pipelines are identical from one branch to the other, from one project to the other.

So, one framework, some products, several projects, maintenance branches, complex pipelines… We end up having many many jobs to create, duplicate and maintain. Before even going into this direction, we saw this as a blocking issue - there was no way we could maintain manually thousands of jobs on a day to day basis.

The solution we were looking for should have the following characteristics:

  • Self service - our goal being to delegate the job and branch administration in Jenkins to the projects, in order to reduce the support time
  • Security - we didn’t want to open Jenkins to the projects at configuration level - not acceptable in our context
  • Simplicity - the solution should be simple enough to be manageable by people not knowledgeable about the core technologies of Jenkins
  • Extensibility - the solution must be flexible enough to allow extensions when needed

When we thought about using the Job DSL plug-in, delegating the creation of the pipeline to the project teams was OK from a self service point of view, but was not secure and definitely not simple for people not knowing Jenkins.

In the end, we opted for a solution where:

    The Jenkins team develops, maintains and versions several pipeline libraries
  • A project team would edit a simple property file listing the characteristics of the current branch, like which type of platform is supported, which version of the pipeline library to use, etc.
  • Upon commit of this shopping list, the complete branch pipeline is regenerated using the given version of the pipeline library
  • The pipeline library code reads the “shopping list” property file and runs a Job DSL script to generate the branch pipeline according to those parameters

By default, the pipeline library generates a classic pipeline, suitable for most needs. It is also possible to define and use extensions, like having additional jobs in the pipelines.

In case of new features or defects, we develop or branch a new version of the pipeline library and projects or branches can use it by changing the version of their shopping list file.

A project gets injected into the system by having only a project seed being generated. From it, the authorised members can generate the branch seed and any branch pipeline at any time. Those seed jobs and the pipelines themselves can also be driven directly from the SCM using our plugin.

The project teams are now autonomous and can pilot their pipelines without requesting any support. They act in a secure and isolated way, and cannot compromise the shared environment. The “shopping list” file is simple and well documented. The system is not rigid and allows for extensions.

This platform has been developed initially for a very specific framework and a set of projects which depend on it, but has been extended since to be able to support other stacks. It is structured in two different parts:

  • The seed platform itself - generation of branch structures in Jenkins and trigger end points for being piloted from the SCM
  • The pipeline libraries, referenced from the shopping list files

We still allow some small tools and applications to define directly their pipeline by providing a Job DSL script.

Using the same principle, we can also pilot other tools in the ecosystem - like Artifactory or Ontrack.

I'll talk about this seed platform on June 24th, in the Jenkins User Conference in London.

This post is by Damien Coraboeuf, Continuous Delivery Expert at Clear2Pay. If you have your ticket to JUC Europe, you can attend his talk "Scaling of Jenkins Pipeline Creation and Maintenance" on Day 2.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Will Soula, JUC U.S. East

Mon, 2015-06-08 12:30

Chat Ops and Jenkins

I am very excited to be attending the Jenkins User Conference on the East Coast this year. This will be my third presentation at a JUC and fourth time to attend, but my first on the East Coast. I have learned about a lot of cool stuff in the past, which is why I started presenting, to tell people about the cool stuff we are doing at Drilling Info. One of the cooler things we have implemented in the last year is Chat Ops and our bot Sparky. It started as something neat to play with ("Oooo lots of kittens") but quickly turned into something more serious.

Ever get asked the same questions over and over? What jobs to run to deploy your code? What is the status of the build? These question and more can all be automated so you do not have to keep answering them. Furthermore, when you do get asked you can show them, and everyone else, how to get the information by issuing the proper commands in a chat room for everyone to see. With chat rooms functioning as the 21st century water coolers, putting the information in the middle of the conversation is a powerful teaching technique. You are not sending people to some out dated documentation on how to get their code deployed, nor are you showing them the steps today only to be forgotten tomorrow. Instead you can deploy your code and they see the exact steps needed to get their code deployed.

Even more impressive is the way ChatOps can bring your company together. Recently our CTO got a hipchat account so he could interact with Sparky. This gave me the idea that if we extend Sparky to deliver information useful to the other teams (Sales, Marketing, Finance, etc) then we would be able to get these wildly disparate teams in the same chat room together and hopefully they will talk and learn from each other. Where DevOps is the bringing together of Dev and Ops, ChatOps can be the bridge across the entire organization. Come see my presentation Day 1: Track 1 at 4:00 PM to learn how ChatOps can enrich your team, how Drilling Info is using it, and what our future plans entail for ChatOps.

This post is by Will Soula, Senior Configuration Management/Build Engineer at Drilling Info. If you have your ticket to JUC U.S. East, you can attend his talk "Chat Ops and Jenkins" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Andrew Phillips, JUC U.S. East

Wed, 2015-06-03 13:21

Automated Testing with Jenkins: At JUC East with Andrew Phillips

Next stop: Washington, DC! I’m looking forward to heading to JUC East in a couple weeks, which runs June 18-19. The Jenkins User Conference is the annual get-together for Jenkins customers, users, partners, developers and community members. It promises to be an exciting two days, and as an added bonus I get to catch up with Kohsuke Kawaguchi and Gene Kim!

I will be giving a talk about a topic that I think is a bit of an elephant in the room in the Continuous Delivery space: the critical importance of optimized Automated Testing. As you start to ship code faster, you’ll need numerous automated tests across many different tools, in many different jobs in your pipeline. But getting a grip on the results of all of your automated tests — and then figuring out whether your software is good enough to go live — becomes harder and harder as you speed up the delivery of your software.

I’ll share tips on how naming conventions, partitioning of testware and mirroring the application’s structure in the test code help you best handle automated testing with Jenkins. I’ll also try to provide some insight into how to keep the setup manageable, as well as share practical experiences of managing large portfolios of automated tests. Finally, we’ll showcase some practices that help you manage all your test results and add aggregation, trend analysis and qualification capabilities to your Jenkins setup.

Join us at the event, or check the slides or recording (which we’ll post after the talk) to learn more. Looking forward to seeing you there!

This post is by Andrew Phillips, at XebiaLabs. If you have your ticket to JUC U.S. East, you can attend his talk "How to Optimize Automated Testing with Everyone's Favorite Butler" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Peter Vilim, JUC U.S. East

Tue, 2015-06-02 12:50

In this talk I will be focusing on plugin development for Jenkins. I aim to capture some of the lessons that we have learned at Delphix and that I learned while I was in graduate school. At Delphix we have been large users of Jenkins for over four years which is most of the history of our startup. We currently run thousands of jobs per day. We have been quite happy with the experience and expect these numbers to grow significantly as our business scales beyond our current 300 head count.

The core concept of Delphix is Data as a Service. Our software allows businesses to virtualize databases and data associated with their applications then provision these on demand to developers and others who need virtual copies of them. Our development for this software spans the entire stack. We have quite a few kernel developers, including the original team for the ZFS filesystem who work on developing the open source application, OpenZFS, which underpins our product. Further up the stack we have a large java application that interacts with ZFS to perform virtualization operations, provides user facing webservices, and interfaces with our internal Postgres metadata store which stores the state of our system. Finally above this we have a modern Javascript front end for user interaction. Our full software product ships as a virtual machine on a variety of hypervisors. As a result of these numerous components, end to end integration testing is very important to us. This integration testing is the primary use of Jenkins for us. Before any developer checks in code to either our operating system or application repository, it must undergo several hours of automated integration testing. We also have nightly runs which go for far longer and tests a much more extensive set of functionality. In addition, we use Jenkins for the build process of our software as well as final packaging for release. Because Jenkins serves as a hub for our development processes, having a well designed system is very important to us and saves us significant time.

Below are some of the key points I will be discussing at my talk. I hope you attend to learn more about the areas that I find very interesting.

  • I'm planning to discuss the structure of a Jenkins plugin. I'll also cover a few of the more advanced areas of plugins such as distributed builds that I see less frequently in plugins. In addition, I'll briefly cover unit testing, which is something missing in many open source plugins.
  • I'll talk about some good patterns to use in plugins as well as some areas where a plugin is not a good idea. I'm planning to pull from my own personal experience developing plugins, the experience of other people at Delphix working with Jenkins, and our experience using other open source plugins to talk about what works and what doesn't.
  • I'll give an overview of the current plugin development at Delphix. I'll cover some of the lessons that we have learned along the way. We have also started to take a "dogfooding" approach to some of our development where we use plugins internally to help our test process and open source them since our customers find features used for testing our product to often be useful in their production environments. This has an added bonus of making it easier to justify our development time spent on making these plugins, since they are also features requested by our customers.
  • I'll discuss the trade-offs between using an already developed plugin or group of plugins, writing some scripts, and building your own plugin. Being able to figure out when to do which can lead to major time savings as well as a better user experience.

I hope you attend. Even if you have no immediate plans to write your own plugins, hopefully you'll be able to learn about what makes plugins tick and how to better evaluate plugins when picking them for your own projects. Plugins were what originally got me excited about Jenkins and they allowed me to see its true potential as a build and test system. I hope to share some of that inspiration.

This post is by Peter Vilim, Member of Technical Staff at Delphix. If you have your ticket to JUC U.S. East, you can attend his talk "Providing a First Class User Experience with Jenkins Plugins" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Nobuaki Ogawa, JUC Europe

Mon, 2015-06-01 12:22

On the 23rd and 24th June, I’ll attend Jenkins User Conference 2015 Europe in London. And I’ll present a lightning talk about Continuous Delivery with Jenkins.

Here is short overview of what I’d like to talk about there.

1. Continuous Build

My starting point was to get to know JenkinsCI. Our developers used JenkinsCI to make the Continuous Build of our software. So, our developing environment was quite Jenkins friendly from the beginning.

2. Continuous Deploy

--- Virtual Machine ---

We had to have an environment where we could deploy our new build. As we are big fans of Microsoft, we decided to use Azure as our environment to make Continuous Testing.

How do we control it? We use Powershell, which can be executed with JenkinsCI.

--- Product Deployment ---

How did we achieve the Continuous Deploy? Actually, my boss, who is DirectSmile’s Yoda developed a very powerful tool called “DirectSmile Installation Service” to enable this.

So we integrated this tool within JenkinsCI, and now Jenkins can deploy DirectSmile products on any target server with just one-button-click!

3. Continuous Testing

Of course, we use JenkinsCI to make the Continuous Testing. How do we do that? We use Selenium to make and run tests. So we can cover most features and we can execute it at anytime.

We are doing it after every new version build, to obtain Continuous Delivery.

4. Continuous Sharing

I think it’s important to share all knowledge and experiences I have had with others, especially those whom have just started with Continuous Delivery.

Don’t worry, it is probably much easier than you think.

As a part of this practice, I’d like to share all my knowledge and experiences with how easy it is to achieve Continuous Delivery with Jenkins at JUC 2015.

I’m really exciting to meet and talk about this there! See you at JUC 2015 in London!

About Me

My name is Nobuaki Ogawa, from Japan, and I currently work in Berlin, Germany for the software company DirectSmile as a DevOps QA Manager.

From the very first time I used JenkinsCI, it helped me a lot. Almost all the work I did last year was mainly with Continuous Delivery with Jenkins.

From Build to Deploy, Test, and even Maintenance and Monitoring, my Jenkins takes care of everything.

It was super easy to achieve Continuous Delivery in the DirectSmile world with the help of JenkinsCI.

This post is by Nobuaki Ogawa, DevOps QA Manager at DirectSmile. If you have your ticket to JUC Europe, you can attend his talk "Jenkins Made Easy" on Day 1.

Still need your ticket to JUC? If you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: David Dang, JUC U.S. East

Wed, 2015-05-20 14:29

I’ve implemented numerous test automation projects for clients, but recently I had a unique request. Jenkins plays a critical role.

The “digital channel” is an industry buzzword for many companies these days. The digital channel represents a company’s content that is delivered by websites and mobile devices. Companies want the same website to work across any channel in multiple browsers and different operating systems. They also want that same website to work across an explosion of mobile devices. Add the new generation of smart watches showing up and testing is becoming a huge challenge for IT departments. One big issue is there is too much duplication of testing efforts.

In a perfect world, you would create a core set of test automation scripts that work across all digital channels. A client recently requested that my team and I create this perfect-world scenario, and we are doing just that. Jenkins pulls it all together by managing the execution and reporting.

Join me for my talk to learn how I’m using Jenkins, Selenium, TestNG, and Perfecto Mobile to solve the digital channel testing challenges for one client.

This post is by David Dang, VP of Automation Solutions at Zenergy Technologies. If you have your ticket to JUC U.S. East, you can attend his talk "Integrating Mobile Automation with Jenkins: A Case Study Using Perfecto Mobile with Jenkins" on Day 1.

Still need your ticket to JUC? Early bird pricing has been extended! Also, if you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.

JUC Speaker Blog Series: Andrew Bayer, JUC Europe

Mon, 2015-05-18 11:33

In the fall of 2011, the very first Jenkins User Conference was held in San Francisco. Over 250 people showed up. It was, to be completely honest, a bit shocking to me - that little project I’d gotten involved with less than three years earlier was big enough, interesting enough, important enough for 250 people to travel from around the world to spend a day talking about it? That’s an amazing feeling, and it was an amazing day. Since then, there’ve been three more JUCs in the Bay Area, three in Israel and two in Europe, with more talks on more Jenkins subjects and an ever-increasing number of attendees. This year, there are another four scheduled - three of them for two days each this time! Find out more about the first two, JUC US East and JUC Europe, below!

Not only are there enough worthy talks to merit a full day a few times a year - now there are enough to merit two days! At JUC US East 2015 outside Washington, DC on June 18 and 19, you can see talks on the Workflow plugin for Jenkins, test automation, mobile testing, plugin development, and a few talks on new and fascinating ways people are using Jenkins - even driving big data workflows! And then, just a few days later, on June 23 and 24 in London, there’s JUC Europe 2015, with talks covering things like the fantastic Job DSL plugin, reproducible build environments, Jenkins and Docker together, and my personal favorite, the 2015 edition of my Seven Habits of Highly Effective Jenkins Users talk.

Whether you’re interested in the latest innovations in continuous integration and delivery, or you’re a Jenkins plugin developer wanting to learn how to make your plugins more mature and useful, or you’re a Jenkins administrator trying to understand how to provide your users with a great platform for their builds and testing, or even if you’ve just heard about CI/CD and you want to find out more, the Jenkins User Conferences are a great opportunity to see all those things and meet with other Jenkins users and developers. I’m excited to attend my fifth JUC in London, and I hope to see you there!

This post is by Andrew Bayer, build and tools architect at Cloudera and longtime Jenkins contributor. If you have your ticket to JUC Europe, you can attend his talk "Seven Habits of Highly Effective Jenkins Users" on Day 1.

Still need your ticket to JUC? Early bird pricing ends May 15. Also, if you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Lorelei McCollum, JUC U.S. East

Thu, 2015-05-14 10:12

Have you heard Jenkins mentioned, but haven't really done much with it? Are you at JUC because you want to learn more? Has your company been pushing you to use Jenkins or to adapt a more agile build/test process using a Continuous Delivery/Continuous Integration method?

Jenkins 101 is going to give you an introduction to Jenkins and get you started in the right direction. Many sessions may be too in-depth, too specialized, or do a deep dive too fast, and while that is good for the more intermediate Jenkins user, the beginner can get lost fast and lose interest. My session will go through the basics of Jenkins, so anyone without prior knowledge can get up and running in just a short amount of time. We will cover building/configuring jobs, design of pipelines, security of your Jenkins master, fun groovy scripts and useful plugins to get you started. Whether you are a beginner or an advanced Jenkins user, you can always learn from how others are using Jenkins. Attend this session early on in your JUC lineup, so that you get the most out of the conference!

This post is by Lorelei McCollum, Software Engineer at IBM. If you have your ticket to JUC U.S. East, you can attend her talk "Jenkins 101" on Day 1.

Still need your ticket to JUC? Early bird pricing ends May 15. Also, if you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JUC Speaker Blog Series: Denis Chernilevskiy, JUC Europe

Thu, 2015-05-07 15:35

Jenkins is a great tool for automation of all kinds of processes in the software development cycle. Falling back to the year 2008 I remember myself creating my first job and the feeling of enlightenment flowing through my veins :) Then it was just one script running on just one slave (node) and it was enough for that particular task. But years have passed, software systems have become more complicated and terms like «cloud», «distributed environment», «CI/CD» are not a discovery for anyone nowadays. But how can these things be connected and used by Jenkins? The detailed answer for this question will be revealed in my presentation of "compound-cloud" plugin at JUC Europe 2015.

Before I got to Yandex, the QA's automation concept was the following:

  • The job takes 1 free slave
  • The job installs the system under test and tests themselves to this node
  • The job runs tests
  • The job cleans-up and returns the slave back to the pool

When I started working for Yandex I understood that the concept of one single slave for a job is not a solution for our tasks because of one particular reason - the system under test was not able to work on a single node… This system is a Yandex MediaAd platform and it requires at least 4 separate nodes to be run on. Better - 8 nodes. Optimal - 40 nodes :)

Thinking about the problem, we thought we would get closer to the solution by simply using a single Jenkins slave as a launchpad for tests and for some tools which will then get some more nodes from the cloud (we already had OpenStack ready) and deploy the system inside them. Thank God we haven’t implemented this solution :)

We’ve been stopped by the following reasons:

  • We are lazy and want to write as little code as possible :)
  • There’s a JClouds plugin that can work with OpenStack. Why don’t we use it? 'Cause it provisions only 1 slave per job. But it has provisioning algorithms implemented already, and we don’t want to reimplement them…
  • If we create cloud instances with a separate tool, then we have to manage them separately and can’t get profit of using Jenkins’ slave management, which is also implemented already…
  • if we do so, we also lose Jenkins’ slave features like running a script on the slave, get some reports or statistics and so on
  • We would also lose visibility: how many slaves we have, how many are busy, how many left til we get to the cloud quota limit? We could go to OpenStack panel then, but it’s totally inconvenient…

As a result of this reasoning, the idea emerged! «We should provide an ability to either attach several slaves to a job, or to allow a slave to consist of several nodes». The second way seemed to give more order in slaves management and it was stated to be a final solution for our problem. We called this concept a «compound-slave». And then we coded...

That’s how the compound-cloud plugin was born. It allows us to get such compound-slaves from any cloud plugin installed to Jenkins. Of course there’s also a possibility to form a compound slave from single slaves already attached to Jenkins, but it’s not the true way for hardcore IT guys ;)

Of course there are lots of details on how we use this concept in a real life for our purposes (and I will surely describe the main parts of them in my speech), but here’s a short list of common use-cases:

  • We configure a set of labels via the JClouds plugin. Each label represents 1 slave template, like «small_ubuntu_server» or «large_win_server».
  • We then configure a compound-slave label via compound-сloud plugin. Each label is a set of single cloud labels. As a result we have a label like «Small test env» consisting of "1x large WinServer + 3x small Ubuntu».
  • We assign roles to each single node in a compound label, to be able to distinguish them, so the job can run a script on a particular node inside a compound-slave for example.
  • We assign a label to a job, like it’s done for a JClouds label, for example.
  • When the job starts, a compound-slave provisions from the cloud using the corresponding compound label.
  • We run a deployment tool on a ROOT role node of a compound-slave. It then deploys the system under test to other nodes inside this compound-slave.
  • We run tests.
  • We don’t bother with creating/cleaning/stopping/deleting slaves. It’s done by Jenkins.
  • We get profit :)

The core feature is that we've reused all the provisioning and management mechanisms already implemented in Jenkins and cloud plugins. We just run our jobs and don’t care about the distributed infrastructure!

This post is by Denis Chernilevskiy, the head of QA/DevOps Services at Yandex. If you have your ticket to JUC Europe, you can attend his talk "Multi-Node Environment as a Jenkins Slave (Compound-Slave)" on Day 2.

Still need your ticket to JUC? Early bird pricing ends May 15. Also, if you register with a friend you can get 2 tickets for the price of 1! Register here for a JUC near you.






Thank you to our sponsors for the 2015 Jenkins User Conference World Tour:

JIRA migration this weekend

Fri, 2015-04-24 08:08

In continuing my infra upgrade work, this weekend I'll be migrating JIRA to another server.

This will make upgrade more manageable and testable. The service will be disrupted for a few hours. Check out our @jenkinsci on Twitter for up-to-the-minute status.

Once the migration is done, the next step is to upgrade them.

Jenkins User Conference - Agenda News

Wed, 2015-04-22 09:37

I have some exciting news -- The agendas have been posted for the Jenkins User Conferences (JUC) to be held at U.S. East (Alexandria, VA) and Europe (London). Take a look here to learn more about the talks, speakers and schedules.

As always, there is a great lineup of presenters ready to share their Jenkins stories: Peter Vilim will be presenting “Proving a First Class User Experience with Jenkins” at the U.S. East JUC, and Sander Kieft’s talk is called “Automating a Big Data Platform with Jenkins” at JUC Europe. Learn more about all 2015 JUC speakers and talks here. Explore the pages and see the who/what/where of all JUC 2015 locations!

You will see some familiar names and talks as well: Andrew Bayer will be presenting his very popular talk called “Seven Habits of Highly Effective Jenkins Users” at JUC Europe. Will Soula is returning this year to JUC U.S. East to “chat” about “Chat Ops and Jenkins.” Lorelei McCollum is also back with two talks at JUC U.S. East called “Jenkins 101” and “Getting Groovy with Jenkins.”

This year, you will notice a few differences in the JUC agendas. JUC is now a two-day conference in the U.S. East, Europe and U.S. West locations! Also, each session is assigned a category according to its content: Continuous Delivery, Best Practices, Operations, Plugins, Case Studies/War Stories and more. This will help you decide which talks to attend. You will also notice that several talks, especially in JUC Europe, reflect the industry’s growing interest in big data and Docker.

The agendas are still being finalized for JUC Israel and JUC U.S. West. If you are interested in speaking at either of these locations, you can still send in your talk proposals. The U.S. West deadline is May 3 and the Israel deadline is May 15.

JUC is such a great opportunity for the community to come together and network face-to-face. You can meet Kohsuke Kawaguchi, creator of the Jenkins project, Gene Kim, author of The Phoenix Project and DevOps expert, but you will also have the opportunity to meet Jenkins users, just like you, from all over the world. And this year, with the Jenkins project at well over 100K active installations, JUC as a whole will be the largest gathering of Jenkins users ever.

Early bird pricing for JUC U.S. East and Europe ends May 1, so REGISTER NOW to take advantage of the lower pricing.

JUC World Tour 2015 - Keynote Speaker News and Early Bird Tickets

Mon, 2015-04-13 09:35

The 2015 JUC World Tour dates are rapidly approaching. Since the community has grown so tremendously since last year, the JUC in each city will be the largest gathering of Jenkins users in that region.

Kohsuke will, as always, be the opening keynote speaker at each JUC. But, with the conference going from one to two days, I am happy to announce that Gene Kim will be another keynote on the second day! He is the author of The Phoenix Project and a thought leader in DevOps.

To have these two experts in one place will provide a great opportunity to talk about Jenkins as the foundation of continuous delivery and DevOps practices.

Another exciting announcement: the 2015 Jenkins World Tour will run alongside the CD Summit conferences for both days (at the U.S. East, Europe and U.S. West locations only). Attendees of either conference can attend any of the talks and presentations at both events. Learn more about what CD Summit 2014 was like to get an idea for this year's event.

Registration for all 2015 JUC locations is open. Early bird pricing ends May 1!

The Call for Papers for JUC is still open for Israel and U.S. West. Submit your own proposal or convince your favorite speaker/Jenkins user to submit one if speaking is not your thing!

Confluence migration this weekend

Mon, 2015-04-06 23:08

For the past few weeks, I've burnt a lot of midnight oil to get Confluence containerized. The goal is to make Confluence upgrade more manageable and testable. In the proces, I've not only containerized Confluence, but also containerized some other services, including mock LDAP server, to be able to test the copy of the production Confluence dataset against newer versions of Confluence before upgrading production.

The infra team is currently targeting this weekend to migrate our current Confluence instance to this new container, and use the opportunity to move the service to a bigger system. Currently JIRA and Confluence has to live within 2.5GB RAM from the same host, and it's really stretching both services. The new box has 4GB of RAM, and we are splitting JIRA and Confluence to two different servers. So there's a lot of head room.

So please expect some Wiki outage over the next weekend.

As always, our sincere thank you to Oregon State University Open Source Lab for generously hosting our servers. Please donate to them to show your support. Similarly, thank you Atlassian for generously providing the license for running Confluence.

If this goes well, JIRA will follow suit.

Good bye Java6

Mon, 2015-04-06 22:48

About two years ago, we bumped our runtime JRE requirement from Java5 to Java6. And so the time has come once again for us to finally move on to Java7. Because of all the new language features, many of us the developers really wanted to move right on to Java8, but after much discussion we settled to move to Java7 first and then to Java8.

So here is the plan:

  • Starting Jenkins 1.608, we start advertising that we will be moving on to Java7, which is why you are reading this.
  • Starting Jenkins 1.610 (2 weeks from now), we will ship so-called 51.0 class files that will only load on Java7+. This gives some more warnings to those who don't read our blog.
  • Unless we hear uproar from users, starting around 1.614 (6 weeks from now), core developers will start linking directly to new Java7 APIs. We will move on to servlet 3.0 at this time as well.
  • The current 1.596 line of LTS will remain compatible with Java6, and most likely the next LTS line will also remain compatible with Java6. So LTS users have additional 3 months before upgrading to Java7.

Java7 has more NIO improvements that allow us to do some file I/O in more portable manner. Similarly, servlet 3.0 will help us build more interactive UI.

Your Jenkins master and all the build slaves need to be running on Java7+. Similarly, those who are using the Maven2 job type must also run Maven with Java7+. However, this does not prevent you from using Jenkins to build your applications that are targeted to earlier versions of Java. According to our research, most platforms people run Jenkins on has been already shipping Java7 for quite some time now. But if you have a good reason why we shouldn't force everyone to Java7, please let us know ASAP.

To put this into context, Oracle will not release updates to Java7 past April 2015. We have always recommended users to run the latest general release according to Oracle, which is currently Java8. As I said, I suspect we will be requiring Java8 pretty soon. So if you are still running Java6, you should definitely upgrade to Java8.

Registration for JUC 2015 is Open!

Wed, 2015-03-25 12:55

It's that time of the year again: 2015 Jenkins User Conference Registration is OPEN for all cities. This year, we are making some changes to JUC — JUC will be a two-day event in three out of the four cities across the globe. You will get opportunities to network with other users and developers in the community, learn more about how other people are using Jenkins and attacking broader continuous delivery problem. As always, we love to meet & talk to you to learn what you are doing with Jenkins. To get the sense of how JUC is like, take a look at our past JUC reports like this and this.

Early Bird pricing for JUC tickets is available until May 1.

You can learn a lot more information here about the 2015 Jenkins User Conference World Tour. As always, we are tweaking JUC to make it better, based on feedback. I'll post about those in coming months. Make sure to follow or tweet at @jenkinsconf to stay up to date on JUC news or to share which JUC you will be attending!

See you there!

JUC 2015 Call for Paper Deadlines Approaching!

Tue, 2015-03-17 16:11

The deadlines to speak at a 2015 Jenkins User Conference are fast approaching. Don’t miss out on this great opportunity to share your Jenkins tips, tricks, stories, and know-how with the community! Submit your proposal by the below deadlines to have your talk considered by a panel of Jenkins experts:

Please note: The deadline to submit a speaking proposal for East Coast US (DC) and Europe (London) is SUNDAY, MARCH 22, 2015. That is only FIVE days away!

2015 JUC Cities & Call for Papers Deadlines

  • East Coast US: Deadline to Submit - March 22, 2015
  • London: Deadline to Submit - March 22, 2015
  • West Coast US (Bay Area): Deadline to Submit - May 3, 2015
  • Israel: Deadline to Submit - May 15, 2015

Not interested in speaking? Contribute to the community in another way: nominate or refer a speaker you would like to hear from at JUC! Contact alytong13@gmail.com or simply become a sponsor.