Submitted by kohsuke on Fri, 2013-10-18 14:34
(This is a guest post by Alyssa Tong, the lead coordinator of Jenkins User Conference)
Our 3rd annual Jenkins User Conference in the Bay Area being held next Wednesday in Palo Alto is booked fully to the capacity and we couldn’t be more excited for this event! It’s going to be an amazing day of learning, talking to technology experts, networking with other Jenkins users, seeing cool demos and finding out how you can contribute to the Jenkins open source projects.
This event is being held at the Oshman Jewish Community Center and registration begins at 8am. There will be breakfast and plenty of coffee to get you caffeinated. Welcoming announcement will begin sharply at 9am and the keynote address follows shortly after. We’re so excited to have thirteen sponsors investing in and supporting the Jenkins community in this continuous integration space.
(This is a guest post from Gareth Bowles, a Senior Software Engineer at Netflix.)
Jenkins has been a central part of the Netflix build and deploy infrastructure for several years now, and we've been attending and speaking at JUC since it started in 2011. It's a great opportunity to meet people who are as passionate about build, test and deployment automation as we are - although as Kohsuke said last year, having all those folks in one place could be dangerous if there's an earthquake !
CloudBees and the JUC Organizing Committee have put another great program together this year. We'll be doing two talks. Justin Ryan and Curt Patrick will present "Configuration as Code: Adoption of the Job DSL Plugin at Netflix", describing how we're shifting our users from manual job configuration via the UI, to defining their jobs as Groovy code using the Job DSL plugin. Justin and Curt will describe how Netflix development teams can now create and maintain complex sets of jobs for their projects with the bare minimum of coding.
(This is a guest post from Owen B. Mehegan aka autojack)
The Jenkins User Conference - Palo Alto is coming up on October 23rd! The schedule for talks is full, but we've been looking for a way to give other members of the Jenkins community some visibility. There are many people who have contributed to the project in various ways, whether it's contributing to core, developing plugins, writing documentation or just helping new users.
(This is a guest post by Stephen Connolly)
Every developer, at some stage, will be handed a project to maintain that somebody else was responsible for. If you are lucky, the developer will not have left the organization yet and you get a brief Knowledge Transfer as the developer packs up their desk before heading on to their new job. If you are unlucky, you don't even get given the details of where the source code is hiding.
Now begins the detective work, as you try to figure out how to build and release the project, set up Jenkins jobs to build the project and run the tests…
It doesn't have to be this way, you know!
What if I told you there was a file sitting at the top level that told you exactly how to build the project and do the important things? You'd be interested, wouldn't you?
When I tell you it's the README file? “But that's all lies. Nobody keeps that up to date. Argh!!!”
But what if Jenkins reads the README file and uses it for the build definition? Now you not only have a CI system ensuring that the build definition is correct, but you have less work to do setting up the job.
What if, because the build definition is now in Source Control, you can have Jenkins create jobs for each branch with ease?