Posts categorized “jenkins”
You can use the MyCloud Control Panel and the Orchestration service to create a new Rackspace server and install Jenkins in one step.
Welcome to part 2 of Jenkins Post-build Plugin development tutorial. This post talks in detail about the plugin project entities and their interactions with each other. To brush up on the previous post, please visit Jenkins Post-build Plugin Part 1.
This is the first part of a two-part tutorial series to develop a Jenkins plugin (specifically, Jenkins post-build plugin). Jenkins is a very popular continuous-integration tool and with the small amount of (scattered) information present out there, it is really hard for a beginner to dive in this amazing area of extending it - Plugins!
One of our highest priorities at Mist.io is to never break production. Our users depend on it to manage and monitor their servers and we depend on them. At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day.
As we describe our release frequencies with "times per day" instead of "times per year", clunky performance testing solutions that require interaction or supervising no longer fit in the deployment pipeline. In Email & Apps, our latest and greatest code commits are hammered to their limits to enforce strict standards of performance.
The basic idea starts with Jenkins pulling the latest performance testing scripts from GitHub and submitting them to machines running Flood, a Node.js tool written in-house. These jobs can do anything Node.js can do; a typical use-case is sending requests to an HTTP endpoint. When the results come back, Jenkins can decide whether to fail the build, produce graphs, or whatever your desired behavior may be.
As discussed previously, this blog is hosted entirely in Cloud Files. It is powered by Octopress, which means it is static - perfect for hosting in an object store. Our "architecture" looks like this:
Previously, deploying the blog was a one-and-done job. A single Jenkins job that upon a push to GitHub, would install our Ruby gems, install the theme, generate the site, and push the site to Cloud Files. This worked well, for a while. Then Murphy got involved.
This is part 2 of a series of using continuous integration with the Rackspace Cloud, specifically with Git and Jenkins. This is not the way Rackspace does continuous integration, but you can use this to get started. Stay tuned for future posts on using Jenkins for continuous integration.
In my last post, I described the principles of continuous integration and how to install Jenkins on a Rackspace Cloud Server. In this post, we will walk through securing your Jenkins installation as well as setting up a git repository with Jenkins.
This is part 1 of a series of using continuous integration with the Rackspace Cloud, specifically with Git and Jenkins. This is not the way Rackspace does continuous integration, but you can use this to get started. Stay tuned for future posts on using Jenkins for _continuous integration. _
Continuous integration when used in software development is the practice of frequently integrating one's new or changed code with the existing code repository. Historically, developers would check out a code base and make changes. When submitting those changes back to the repository, the developer would have to integrate their work with code other developers had already changed. The longer the developer's personal repository had been checked out, the more difficult the integration process became. With the fast pace of web development, developers need to be able to commit and integrate changes quickly and automatically. Continuous integration helps with that.
Our cloud is open. We believe our company should be too. One of our Core Values at Rackspace is full disclosure and transparency, and we want to build a community for our developers that is open, transparent and helps them build amazing applications on the open cloud.