When you look at the structure of a successful organization, it is rare to find silos of any sort. The reason being that when you shift the emphasis from individual performance optimization to a team-based structure focused on optimizing delivery, you get faster output. Why?
When an individual is focused on their own task lists, priorities slip for other projects that get held up. This ultimately creates a bottleneck of work. What is the natural thing you may do when you are waiting for someone else to do the next step of a project or be told to do so from a superior? You start something else. Because you are working on some new project, a new bottleneck is formed when your resources are needed. You are not available any longer and someone is now waiting on you. They start a new project while they wait and so on and so forth.
The Culture Shift
We are members of a culture of multi-tasking – we must always be busy. This is not always good. In the modern culture, resources are dedicated and at the ready to move projects along, even if they are underutilized. So now you have resources that are not moving on to new projects and are ready when their resources are needed.
Now going back to the silo vs. team approach, we start to see less specialization and more focus on distributing knowledge. So now you have a team that can be the next in line instead of one person. It’s now about cross-functional teams vs. superstars.
The focus also needs to change. Our culture wants us to get the Employee of the Month award and achieve personal objectives but what if we focused less on how much we could get out of top performers and more on how much output we could deliver to our customers?
This would mean another huge cultural shift and this time it’s about the management team. Management must be agile and allow for teams to make decisions quickly without having to cut through yards of red tape to get something across the finish line. It’s more about holding your team accountable vs. tracking and monitoring their every move.
The report concludes by stating: “While process and automation are essential enablers of these better results, organization culture, structure, and management approach are the true enablers of better business results.”
Continuous Delivery can be a tremendous game changer for your organization but the organization needs to be modernized in such a way that it will be a successful game changer.
Marketing Funnel Manager
Follow her on Twitter
At the Jenkins User Conference/Europe, held in Berlin on June 25, Timo Stollenwerk of Plone Foundation presented how the Plone community uses Jenkins to build, test and deliver Python-based software projects. Timo went through some of the CI rules and talked about the main tools you should take a look at for implementing Python CI.
For open source projects implementing CI, the most important thing besides version control and automated builds is the agreement of the team. In small development teams, that is an easy task most of the time, but not in big teams or in open source projects where you need to follow some rules.
When implementing CI, it is always a good practice to build per commit and then notify the responsible team as to the outcome. This makes the integration process easier and avoids "Integration Hell." The Jenkins dashboard and the Email-ext plugin could help accomplish this. Also, the Role-based Access Control Plugin could be useful to set-up roles for your organization, so your developers can access the Jenkins dashboard while being sure that nobody can change their job configuration.
Java developers usually use Gradle, Maven or Ant as automated build tools, but in Python there are different tools you should consider, like Buildout, PIP, Tox and Shining Panda. Regarding testing and acceptance testing, I have listed below some of the tools that Timo mentioned.
Due to Python's nature static analysis has become somewhat essential. If you plan to implement this in your organization, I recommend reading this article, which compares different tools for Python static analysis, some of them which Timo also mentions.
Regarding scalability, when you are running long builds you could start facing some issues. A good practice here is not to run any build in your master and to let your slaves do the job.
If you have several jobs involved in launching a daemon process, you should ensure that each job uses unique TCP port numbers. If you don't do this, two jobs running on the same machine may use the same port and end up interfering with one another. In this case, the Port Allocator Plugin can help you out.
The CloudBees Long Running Build Plugin and the NIO SSH Slaves Plugin, which will be released this year, could also be helpful if you want to restart a build (in the case that Jenkins crashes) without starting from scratch or if you want to increase the number of executors attached to your Jenkins master while maintaining the same performance.
In the release process, Timo explains that the Jenkins Pipeline plugin could be combined with some specific Python tools like zest.releaser or devpi.
Get Timo's slides and (when videos are posted) watch the video of his JUC Europe session.
Félix Belzunce is based in Europe and helps our European users become more successful in leveraging the services CloudBees provides. Read more about him on his Meet the Bees blog post and follow him on Twitter.
Continuous Delivery is becoming a main initiative across all vertical industries in commercial markets/private markets. The ability for IT teams to deliver quality software on a hourly/daily/weekly basis is the new standard.
The public sector has the same needs to accelerate application delivery for important governmental initiatives. To make access to the CloudBees Continuous Delivery Platform easier for the public sector, CloudBees and DLT Solutions have formally joined hands in order to help provide Jenkins Enterprise by CloudBees and Jenkins Operations Center by CloudBees to federal, state and local governmental entities.
With Jenkins Enterprise by CloudBees now offered by DLT Solutions, public sector agencies have access to our 23 proprietary plugins (along with 900+ OSS plugins) and will receive professional support for their Jenkins continuous integration/continuous delivery implementation.
Some of our most popular plugins can be utilized to:
- Eliminate downtime by automatically spinning up a secondary master when the primary master fails with the High Availability plugin
- Push security features and rights onto downstream groups, teams and users with Role-based Access Control
- Auto-scale slave machines when you have builds starved for resources by “renting” unused VMware vCenter virtual machines with the VMware vCenter Auto-Scaling plugin
For departments using larger installations of Jenkins, CloudBees and DLT Solutions propose Jenkins Operations Center by CloudBees to:
- Access any Jenkins master in the enterprise. Easily manage and navigate between masters (optionally with SSO)
- Add masters to scale Jenkins horizontally, instead of adding executors to a single master. Ensure no single point of failure
- Push security configurations to downstream masters, ensuring compliance
- Use the Update Center plugin to automatically ensure approved plugin versions are used across all masters
The CloudBees offerings, combined with DLT Solutions’ 20+ years of public sector “know-how”, makes it easier to support and optimize Jenkins in the civilian, federal and SLED branches of government.
For more information about the newly established CloudBees and DLT Solutions partnership read the news release.
We are proud to partner with our friends at DLT Solutions to bring continuous delivery to governmental organizations.
Business Development Manager
I am happy to announce the release of a new version of Jenkins Operations Center by CloudBees - version 1.1. The pie´ce de´ resistance is the monitoring feature, which lets administrators monitor multiple Jenkins that are connected to Jockey. In addition to SSH slaves, Jockey supports windows (JNLP) slaves, an often requested feature.The on-boarding experience for Jenkins into Jockey has been made easier. Finally, we released a new type of higher throughput slaves (called NIO SSH slaves) (in Jenkins Enterprise by CloudBees) as a result of our focus on scalability improvements.
Let me quickly introduce you to the monitoring and alerting feature (released in Jenkins Enterprise by CloudBees) which is available on Jockey. The monitoring plugin on an individual master provides a standard dashboard that includes mechanism to see if a master is overloaded by providing insight in to memory, system load, file descriptors and web response times. The plugin also gives insight into build queue metrics like the build queue length, build duration, build scheduling rate and executors available for builds. Administrators can set alerts via emails for thresholds exceeding pre-determined values. On Jockey, the monitoring plugin consolidates information across all client masters in a cluster. Thus, administrators can quickly determine the masters that need attention.
If you haven't tried Jockey, now is the time to download Jockey and Jenkins Enterprise by CloudBees and give it a spin[7 & 8].
[a] Jenkins should be upgraded to Jenkins Enterprise by CloudBeesAdditional information Monitoring plugin JNLP slaves on Jenkins Operations Center by CloudBees NIO SSH slaves Release Notes Jenkins Operations Center by CloudBees documentation and tutorial Jenkins Enterprise by CloudBees documentation Jenkins Enterprise by CloudBees download Jenkins Operations Center by CloudBees download
- Harpreet Singh
Senior Director, product management
Harpreet has 16 years of experience in the software industry. Prior to CloudBees, he was at Oracle and Sun for 10 years in various roles, including leading marketing efforts for JavaEE 6, GlassFish 3.1 and tech lead for GlassFish 2.1. He was also product manager for Hudson, launching it within Sun's GlassFish portfolio.
Removing the friction from within any process means the cost of repeating it over and over doesn’t create “heat” and this has fantastic consequences. As an example, simply imagine if the time it would take you to travel, anywhere, was pretty much null? Where would you live? Where would you work? Would they be the same places? Probably not.
Consequently, what might have been initially considered as a simple and local technical and organizational optimization within IT, led to have a much greater impact on companies as a whole.
Technically first, removing this friction meant that there was no incentive anymore for IT to “group” software changes in “batches” that would justify the friction cost involved in shipping that new batch to production. Why would IT wait 9 months to push a new feature batch to production if, instead, for the same cost, it could instead split this new feature into hundreds of less risky changes and push them iteratively to production? Furthermore, in doing so, IT would be able to measure pretty much in realtime whether the feature they were building in steps was indeed leading to the changes they were expecting. And this had huge consequences as this was not just reducing the IT risk associated to any change – which is a great improvement in itself - this was also enabling businesses to measure and validate much sooner, whether what they had asked IT to deliver was really yielding the expected results. Yes, business started to see huge value that Continuous Delivery could have on their business.
And in doing so, businesses realized that to fully benefit from Continuous Delivery, it wasn’t simply the IT processes that had to be adapted. The entire value creating chains and feedback loops had to be rebuilt. Since IT doesn’t work in a vacuum, business had to redefine the way business requirements are identified, formalized, and funneled to IT for delivery as a constant stream rather than as big 18 months plans. Furthermore, early feedback from those initial deployments has to re-wired back to the business so it can adapt and improve its plans. Gone are the days of IT as a remote arm of the business : once Continuous Delivery gets achieved across a company, Business and IT merge into a virtuous circle and become one. This obviously has an important impact on how companies have to architect their org chart, processes, decision process, reporting structure, etc.
Where to start?In the last few years, the move towards Continuous Delivery has inexorably made it front and center on the agenda of development teams, IT Ops and CIOs. While the challenges they each have to solve are unique, they all have in common to be in discovery mode to understand what it means to them, how much is already there, how much should change and where and how they should start.
Since education is a prime concern, a few years back CloudBees has decided to initiate the Jenkins User Conferences with the Jenkins community. Those "JUC" aimed at helping software development, IT Ops and DevOps teams learn and share around their use of Jenkins. The 2014 edition of those “JUC” are just about to start with the American edition in Boston this week, a European edition in Berlin next week and the Middle-East edition in Israel in one month.
However, the feedback we have increasingly received in the last 12 months is that CEOs and CIOs are also very much interested in learning more about Continuous Delivery, how it can help them and what it means to their organization. To that end, CloudBees is proud to announce a series of “Continuous Delivery Seminars” - CD Summit - aimed at decision makers. The first edition will take place this week in New York city and is already counting … several hundred registrations! Hurry up if you are interested in attending, we have a few more seats available. The good news is that we will also be having a European edition of our ”Continuous Delivery Seminar” in Berlin next week. Those seminars will feature prominent speakers from Forrester, Fidelity, Bosh and leading vendors in that space.
Kohsuke Kawaguchi and I will be present at all of those events and hopefully will see you there.
This year is the butler's first conference tour to New England. The event will be held at the waterfront Seaport hotel.
We have a great speaker line-up this year. Attendees will be well fed, caffeinated, and the afternoon break features BEvERages. :-) This year, everyone also gets a Jenkins World Tour t-shirt!
We would like to thank our generous JUC US East sponsors. With their help, this Jenkins User Conference is sure to be the best yet.
Kohsuke Kawaguchi is Founder, Jenkins CI, and Chief Technology Officer, CloudBees. You can follow him on Twitter @KohsukeKawa
Continuous delivery is a transformational journey that begins in development and QA, and stretches all the way to IT operations and into production, where business value is delivered to end users. The CD process enables a fast flow of new features from development into production, while preserving software quality, reliability and maintainability. It impacts the software delivery process and technology, of course - but also has great impact on the organizational culture. Let there be no doubt, continuous delivery is larger than anyone thought and is proving to be one of the most innovative and transformational trends in technology.
Starting June 19th in New York City, CloudBees, along with our expert partners, will be kicking off a series of CD Summits around the world to help educate IT executives and technologists on the business significance and technology impact of continuous delivery. The Summits are unique in that they are designed to address both the higher level ‘business value’ questions of executives and the technical ‘how to’ needs of technologists.
We start off the morning of each summit with a keynote presentation discussing the business value that can be realized from following continuous delivery practices. The keynote speakers are experts like Kurt Bittner from Forrester Research and Dr. Jan Hagen from the European School of Management and Technology. Following the keynote, we will have presentations covering the people, process and technology impacts of continuous delivery from firms leading the CD charge like Eliassen Group, CloudBees and codecentric. We’ll show you real world examples of CD in action from enterprises that are actually transforming their software delivery practices like Fidelity Investments and Bosch.
After lunch, we kick off the afternoon session with a technology keynote from Jenkins founder Koshuke Kowaguchi, who will discuss the role of Jenkins CI in continuous delivery practices. Afterward, our partners - including XebiaLabs, SOASTA, MidVision and Puppet Labs - will all discuss how to automate the software delivery pipeline.
Register now! Join us in New York City on June 19 or in Berlin on June 24 for an event that is not to be missed. Check here for future CD Summit dates in cities such as London, Paris and Chicago.
P.S. As an added CD Summit feature, every attendee will receive a complimentary copy of The Phoenix Project.
Written by Gene Kim, Kevin Behr and George Spafford, The Phoenix Project is a must read for anyone in IT development or operations that wants to learn how CD can impact the value CD delivers to the business in a profound way. Armed with all of the information you will gain from the CD Summit, you can write your own (successful) final chapter!
See you there!
André Pino is vice president of marketing at CloudBees.
The newly released plugins are:
- Monitoring pluginBased off the OSS metrics plugin (contributed by CloudBees) provides monitoring dashboard views for a number of Jenkins-specific metrics. In addition, administrators can use these metrics to setup alerts to proactively manage Jenkins instance.
1.0 Default and Custom Dashboard Creation
2.0 Default Monitoring Dashboard
3.0 Custom alerts in action
- NIO SSH PluginThe NIO SSH slaves plugin based on Java Non Blocking I/O provides much better throughput than SSH slaves available with Open Source Jenkins. This plugin uses fewer threads per slave as compared to SSH slaves and improves Jenkins master responsiveness. In addition, where CPU resources aren’t available, this plugin slows the build down to maintain responsiveness, as compared to SSH slaves where the connection is lost resulting in a build failure.
- In our internal benchmarks, we have seen that a Jenkins master with NIO SSH slaves can handle anywhere between 6x-to-10x number of concurrent builds as compared to the standard SSH slaves.
- Long Running Build plugin solves the problem where a build is aborted if the Jenkins master goes down. This is especially problematic when builds span hours if not days. This plugin offers a “long-running” project type that survives master failures. The configuration is almost the same as for a standard free-style project, with one difference: the part of your build that you want to run apart from Jenkins should be configured as a (Unix) shell or (Windows) batch step. Of course this script could in turn run Maven, Make, or other tools. The Long Running build plugin is still in beta will be GA in middle of June.
- Harpreet Singh
Senior Director, product management
Harpreet has 16 years of experience in the software industry. Prior to CloudBees, he was at Oracle and Sun for 10 years in various roles, including leading the marketing efforts for Java EE 6 and GlassFish 3.1. He was also product manager for Hudson, launching it within Sun's GlassFish Portfolio.
Below are some of the questions we received to webinar:
Q: If you use a VPN to access source code on premise from CloudBees DEV@cloud, would source code still be accessible by CloudBees employees?
A: See the details on our wiki. CloudBees support engineers do have access to the Jenkins build to provide support, but that access is restricted. Some plugins might pull and cache source on the master, which you should also be aware of. You can also use on-premise executors from the cloud if needed, to mix the hosted builds with something you want to remain isolated on-prem. Finally, some customers use their own VPC as an IPSec-based bridge to our OpenVPN-based connection, providing further control over access.
Q: What is puppet and chef? Are they scripting languages or tools?
A: They are IT automation tools. Check out the details on http://puppetlabs.com and http://www.getchef.com
Q: Artifacts are stored in a repository. Is it a network share or some sort of repository? What was its name?
Response: The repositories we referenced in slides were Nexus (from Sonatype) and Artifactory (from JFrog).
Q: Why would one choose Jenkins over Bamboo as the main ingredient of a CD solution?
Response: Bamboo is a very capable tool, but people choose Jenkins over it for many reasons. As one of the most active community-driven open source projects, Jenkins enjoys a momentum that is hard to beat. Jenkins is designed to be extensible via its plugin architecture. If you (and we) can't achieve what you want with a plugin, then something must be broken in Jenkins core! What this means is that if you need to connect Jenkins to some system you have in-house, then there is likely to be a solution in the +900 plugins already -- or you can build one yourself. This is also a reason Jenkins is popular not just with developers, but with Ops people. Bamboo is often used along with other Atlassian products, but Jenkins has great connectivity to JIRA, Bitbucket, Stash and Hipchat. CloudBees is committed to working closely with the Jenkins community to continually improve the open source offering, but we also provide Jenkins Enterprise by CloudBees and Jenkins Operations Center to add value and commercial support.
Q: While deploying Jenkins, how can you manage the script file to run after the build is prepared? I tried to do it but it runs just before the code from git is taken...
Response: We are not sure exactly what you are referring to. However, you can configure a "post build step" in a variety of ways within Jenkins to execute a script after a build. If you want to commit to master only when a build is successful, you can use the Validated Merge plugin that is part of Jenkins Enterprise. If neither of these suggestions is addressing your question, you can submit the question with some more specifics to StackOverflow using the Jenkins tag, where CloudBees and community members are very active.
Q: For an enterprise with virtual stack -- I know the Docker plugin exists now in Jenkins -- any case studies or mature examples on that being used for env provisioning as well as automated deployment promoting change from DEV through Prod incl env prop changes?
Response: Well, as Duncan mentioned, Netflix is always a great example, and Viridity's case study with its usage of microservices is quite consistent with Netflix's style. But not everyone can be Netflix! Here's a very nice Velocity conference presentation from Mandi Walls (@lnxchk) of Chef/OpsCode that will give you some specific examples of how to automate deployment using Jenkins in operations. This InfoQ article by Kohsuke and Andrew Phillips of Xebia also provides some specifics about constructing a CD pipeline with Jenkins.
Q: What's the best source for learning Jenkins and all these processes in detail?
Response: Unfortunately, I don't think there is really a great cookbook our there -- yet. Jez Humble and Dave Farley's book is certainly the reference on Continuous Delivery. To get up to speed on Jenkins, there is John Smart's book and some more recent books. The Jenkins User Conferences are great places to hear real-world experience and to rub elbows with others in the very open and supportive community. For online reading, I mentioned one of my favorite bloggers Jeff Sussna. Other online forums that you might find useful (aside from the CloudBees developer blog) are ContinuousDelivery.com and DevOpsGuys. DZone's recently published Guide to Continuous Delivery might also be of interest. As I mentioned in answer to a separate question, there is a very nice Velocity conference presentation from Mandi Walls (@lnxchk) of Chef/OpsCode that will give you some specific examples of how to automate deployment using Jenkins in operations. This InfoQ article by Kohsuke Kawaguchi (CloudBees CTO and Jenkins founder) and Andrew Phillips of XebiaLabs also provides some specifics about constructing a CD pipeline with Jenkins.
Q: Continuous delivery too can deploy automatically on what all flavors of operating systems like Windows, Linux, and iOS? Are there any technology constraints?
Response: Certainly deployment to all flavors of Linux is common, along with Windows. But people use deployment tools to all kinds of systems, from mainframes to web apps to embedded systems. Deployment to iOS and Android is an interesting case. CloudBees supports iOS/XCode builds as part of our hosted service. But what does "deployment automation" mean when your app is gated by an Apple or Google-controlled approval process? Ironically, it means you need to be even more thorough in keeping your software in a release-ready state, and very confident as you roll out updates! Waiting days to get a critical fix to your customers can be a business killer. CloudBees partners with some companies with best-of-breed mobile testing solutions, both in terms of actual "device cloud" hosting as well as test automation.
Q: What are the best practices to automate the UI-centric testing?
Response: We mentioned Selenium from Sauce Labs during the webinar, and it is something we use internally at CloudBees. In the mobile space, emulators are useful but only get you so far. SOASTA has a terrific tool called TouchTest that lets you record and replay complex automated tests on touch-based devices. Robotium is one we run across on Android.
Q: How does Jenkins differ from Go (CD tool by Thoughtworks)?
Response: Go was conceived of as a continuous delivery tool, whereas Jenkins started with continuous integration and has evolved to address continuous delivery as driven by real-world users and community. The open source community has a lot to do with the differences, and perhaps this is why Thoughtworks has recently open sourced Go. Jenkins is the hub of continuous delivery because it connects to everything and is extensible, whereas as a proprietary product prior to being open sourced, Go depended more on a single company's resources to reach the long tail of surrounding systems. Jenkins also shines in its ability to just fit in to existing toolchains and processes. This allows Jenkins to be a tool that helps incremental adoption of CI/CD processes without being overly opinionated and imposing changes and processes on teams that they don't feel they need or benefit from.
Q: Any plan to organize on how to achieve CD in CloudBees?
Response: We offer Jenkins training and partner with experts who can help make you successful in achieving continuous delivery. As Kurt Bittner pointed out, a lot of the challenge in achieving CD is around cultural and organizational issues, not toolchain choice. But, your toolchain choices can be key to helping make the changes.
-- Steven G. Harris
Steven Harris is senior vice president of products at CloudBees. Follow Steve on Twitter.