I'm very excited to announce one of the projects that I've been spending a lot of time on lately — BuildHive! It started as my Christmas/New Year break hack project, but since then it has grown into a real project inside CloudBees.

BuildHive is a free service that lets you set up Jenkins-based continuous integration build/test jobs for your GitHub repositories with just a few mouse clicks. It is freely available for anyone to use.

The top page shows recent builds that have happened on BuildHive. If you keep the page open for a while, you'll see new cards appear from the left for new builds in semi-real time:




Let's click the big red "Add your Git repositories" button to set up CI jobs for your repositories. It'll first ask you to approve GitHub OAuth integration, so you need to click "Allow" to let us see your repositories and install hooks:



Once logged in, you'll see the screen to select repositories from GitHub. It will show all your personal repositories as well as repositories from any organizations that you belong to. If you have too many repositories, use the filter text box to narrow down the candidates.

All you have to do to set up a CI job is to click "Enable". We'll sniff your repository to guess the initial build configuration. The auto sniffing of the repository contents is extensible, but the initial set is geared toward Java projects (like Ant, Maven, Gradle), but also covers some Ruby projects as well.
In any case, auto-sniffing can only do so much. You can tweak the setting via the configuration screen (for example, to update where the notification e-mails are sent):



When you enable a repository, we auto-install necessary hooks for you, so that it'll build your project every time someone pushes to your repository. In addition to that, we'll speculatively build incoming pull requests to your repository (by building the result of the merge between the incoming commit and the current tip of the branch for which the pull request is sent), and report the status as a comment to the pull request:



So you can use that as one of the inputs to determine if you are going to merge a pull request or not.
Behind the scene, many of the features in BuildHive rely on our value-add plugins for Jenkins Enterprise by CloudBees, which are available for customers to use on their own Jenkins instances. For example, we use the Templates plugin to model various project types and for auto-sniffing. We use the Validated Merge plugin to speculatively build pull requests. So, while it isn't as easy as it could be, our customers can set up a similar environment in their own Jenkins instance, or they can re-use those pieces to create similar but different workflows.

And needless to say, there are many other open-source plugins at play, too — it really shows off the power of extensibility in Jenkins.

--Kohsuke Kawaguchi
Founder, Jenkins
CloudBees, Inc.
www.cloudbees.com


Follow CloudBees:

   

Last month at STAREAST 2012 Manoj Narayanan of Cognizant Technology Solutions gave a talk entitled ‘Testing in the DevOps World of Continuous Delivery’. He addressed many questions including the relationship between agile development and DevOps and how exactly an organization can make the switch. In her article, attendant Melanie Webb outlines the points targeted by Narayanan and offers useful insight into how moving to DevOps can speed deployment and improve ROI.

Agile development and DevOps

Agile development offers one path to continuous delivery as it brings developers and testers together and focuses on iterative development. Yet, according to Narayanan, “the ‘last mile problem’ still exists.” The wall separating deployment from the development and testing side encourages a long time between testing and deployment, and furthermore, testers do not necessarily have a systems administration skill set.

DevOps offers a potential solution to this integration challenge, bringing together development, testing and operations all on the same team, a team capable of playing all the different roles.

“Like Agile, this approach aims at getting features deployment ready at a high frequency. But where Agile primarily focuses on the functional and non-functional readiness of the application, DevOps takes it one step further and ensures the Operational and Business readiness as well,” Narayanan writes in his blog.

Narayanan noted several websites that are currently employing the DevOps model, sites like Facebook, Etsy, Orbitz, Groupon and Flickr. He explained that the frontrunners have tended to be Web 2.0 firms with strong reliance on eCommerce where fast changes and improved response time are paramount. He mentioned that Netflix is involved in this space as well, actually going with a NoOps approach.

When it comes to testing, the change to the DevOps environment must be gradual, and the talent involved will need to acquire new skills and adapt to new responsibilities. Testers need to gain knowledge in development languages— which fortunately is a bit easier with user-friendly tools like Python and Cucumber – and they also need to learn deployment processes and tools. Developers and systems administrators, on the other hand, must learn about test processes, design techniques and related tools.

Making the change to DevOps

Shifting to DevOps also makes continuous integration mandatory, according to Narayanan. He explained that in test-driven development we expect to fail first, but those errors inform the next cycle of development and testing. He emphasized that teams must have strong discipline around the single source code repository. The build process can be automated, resulting in a fast build. In order for all of these elements to work effectively, he highlighted the need for transparency; everyone on the team needs to know what is happening.

The process is also affected by the heavy reliance on innovative automation, which is embedded early in the lifecycle. “’Smart testing’ is dissolving the boundaries of traditional system and integration testing,” said Narayanan. Teams can now “leverage an optimal mix of automation across the lifecycle,” which includes automated unit testing, automated service layer testing and automated regression testing. Continuous integration is further facilitated by release management automation.

What do you think? Can DevOps be adapted without continuous integration?

Click here to read the full article by Melanie Webb

While application release automation is appealing, implementing the processes across you’re environments can be a daunting prospect. That’s why it is crucial to choose a solution that can easily integrate with your existing Build, CI, and ITSM platforms.

In our latest whitepaper ‘The Value of Nolio Application Release Automation in a Microsoft Environment’, deployment expert Phil Cherry discusses how Nolio ASAP can seamlessly integrate into an existing Microsoft based environment to deploy applications across the application delivery chain.

Microsoft has developed a number of effective solutions for application lifecycle management that are excellent for their original intended purposes. They do not, however, answer all of the requirements for true end-to-end deployments of complex, multi-tier applications. For this reason you may want to consider adopting a 3rd party application release automation solution such as Nolio ASAP, which can easily adapt to your ecosystem while enabling a completely automated deployment.

If you’re still not convinced that an outsider can help ease the deployment headache, here is a list of all the Microsoft programs that can directly communicate with Nolio ASAP:

1. TFS – Visual Studio Team Foundation
2. TFS Deployer
3. MSBuild
4. IIS WebDeploy
5. SCCM – System Center Configuration Manager
6. System Center Orchestrator
7. System Center App Controller
8. System Center Operations Manager
9. PowerShell
10. .Net
11. BizTalk
12. SQL Server

In addition, ASAP supports all of the major Windows Server versions, Windows 7, Vista and XP. Not convinced yet? Send me (Nili) an e-mail at nili@noliosoft.com and I’ll arrange for you to have a live demo.

“Nolio takes automation to the next level beyond code, server and systems management. Our end-to-end automation solution compliments the Microsoft solution set and many Nolio customers are using it with a combination of technologies. In complex Microsoft only environments, or in environments where it is one of multiple technologies used, Nolio provides consistency, standardization and ease of use to address the complexities of application service automation.” –Phil Cherry

Click here to download the whitepaper

Click here to learn more about our Microsoft Integrations

Click here to learn more about the our Solution

New Integrated Offering Streamlines Release Operations Across the Application Lifecycle

NEW ORLEANS, LA–(Marketwire – May 15, 2012) – Nolio — the leading provider of application release automation — today announced a new integration with ServiceNow, a leading provider of cloud-based services to automate enterprise IT operations. The integrated offering helps ServiceNow customers achieve continuous application deployment and reduce application release windows from hours or days down to minutes. Nolio and ServiceNow are working together to mitigate change risk and to minimize application service downtime.

ServiceNow helps transform enterprise IT by automating and standardizing business processes and consolidating IT across the global enterprise. The ServiceNow configuration management database (CMDB) helps IT departments implement enterprise change management by tracking configuration item relationships, automatically defining IT services and automating IT processes.

Nolio ASAP reduces time-to-market and makes enterprise operations agile and ready for the cloud. Nolio ASAP provides release operations for all application resources (e.g. servers, configurations, data) as a unified system, providing greater flexibility, control, and visibility from an application perspective.

A leading global institutional asset management firm, with more than $500 billion in client assets under management, is already using the integration of ServiceNow and Nolio ASAP to automate application releases and optimize IT operations. The integration between ServiceNow software development lifecycle functionality and Nolio enables this customer’s IT team to cut release time down to minutes and execute the release process from within the ServiceNow platform, enabling the customer to become more agile, integrate across their IT organization, and achieve cost efficiencies.

IT operations staff can use the ServiceNow console integrated with Nolio ASAP to implement continuous and automated application deployment, enforce time windows for process execution, and tie development processes to configuration items in the CMDB. When the change management process begins, ServiceNow cloud services provide the necessary information to Nolio ASAP, which automatically executes the change, configuration and release operations. Nolio ASAP provides status information to the ServiceNow CMDB in real-time so the IT user has extensive, up-to-date visibility into the application release process.

Benefits of the integrated offering include:

• Advanced analytics, reports and dashboards showing how well services are performing, how they are being used and how much time and money is spent supporting them
• Tight automation of configuration management, change management and release operations
• Full application lifecycle support including development, test/QA, staging and production
• Support for continuous application deployment practices to meet the agility requirements of cloud services
• Application-centric orchestration of cloud infrastructure provisioning
• Support for physical, virtual and cloud environments — together in a single system of record

“Extending ServiceNow software development lifecycle functionality through Nolio ASAP provides a strong and unique solution to the market,” said Rob Luddy, ServiceNow VP of Business Development. “We will continue to execute on our commitment to transform IT by automating and standardizing business processes and consolidating IT across the global enterprise. By partnering with Nolio, we now have an end-to-end release operations platform to provide to our growing enterprise customer base.”

“We are excited to be working with ServiceNow to help our customers achieve the full benefits of a continuous application release operations platform for applications in the cloud,” said Doron Gerstel, CEO of Nolio. “By building upon the IT service automation offered by ServiceNow, application owners can use the Nolio ASAP release operations platform to manage the build and release of applications across all application phases, and achieve continuous releases with Zero Touch Deployment™. Our application-centric approach is beneficial to application owners who want continuous release cycles that are simple to manage, cloud-ready, and enable high levels of performance.”

On Wednesday, May 23rd at 11am EDT there will be a free webinar in which the integrated solution will be demonstrated. To register for this online event visit:http://go.noliosoft.com/ServiceNow-webinar.html.

Nolio will be presenting the integrated solution at the ServiceNow Knowledge12 Global IT Conference in New Orleans from May 15-17.

Useful Links

• ServiceNow Knowledge12 conference
• Nolio
• Follow Nolio on Twitter
• Nolio’s Blog

About Nolio
Nolio is the Zero Touch Deployment™ company. The Nolio ASAP™ release operations platform reduces time-to-market and makes enterprise operations cloud ready. Customers use Nolio ASAP to reduce deployment time from days to minutes and eliminate downtime. Many of the world’s leading enterprises rely on Nolio to automate application deployment, maintenance, remediation and recovery across the application lifecycle on physical, virtual and cloud infrastructures. For more information visit www.noliosoft.com.

Service Now with Zero Touch Deployment

How to Integrate Service Now with Nolio – Video

Today marks the start of the Knowledge12 ServiceNow Global User Conference and we are excited to reveal the latest collaboration between Nolio and ServiceNow. Our new and improved integration has enabled leading global firms to achieve the dream – Zero Touch Deployment™!

Nolio ASAP enables the full integration of Zero Touch Deployment™ within the change management system of ServiceNow. All the platform’s process rules and data are automatically integrated with Nolio ASAP affording ServiceNow users to enjoy fully automated deployments without having to change any aspects of their current application management system. This offers the best of both worlds; rapid and accurate deployments with complete auditability, visibility and control.

Adopters of these processes are benefiting from accelerated IT transformation by streamlining their release operations across the application lifecycle. Some of the results they are enjoying include:

1. Reduced Time-to-Market
2. Greater Flexibility and Agility
3. Visibility and Auditability
4. Advanced Analytics and Reporting
5. Support for Physical, Virtual and Cloud Environments
6. Full IT Governance and Compliance

“Extending ServiceNow software development life cycle functionality through Nolio ASAP provides a strong and unique solution to the market. We will continue to execute on our commitment to transform IT by automating and standardizing business processes and consolidating IT across the global enterprise. By partnering with Nolio, we now have an end-to-end release operations platform to provide to our fast-growing enterprise customer base.” – Rob Luddy, ServiceNow VP of Business Development.

Don’t forget to stop by booth 138 for the opportunity to learn more about Nolio’s new and improved integration with ServiceNow. See you in New Orleans at Knowledge12!

Want to learn more? Join us on Wednesday, May 23rd at 11am EST/4pm GMT for our live webinar ‘ReleaseNow with ServiceNow Part II’ with Nolio’s Product Director Ron Gidron

Click here to read the full Press Release

Click here to register for our live webinar

Last week, HP made an impressive splash, launching not only the official public beta of their IaaS solution - HP Cloud Services, but announcing 40 partners that will run on HP Cloud Services, and CloudBees was one of these key partners.
HP positioned its Cloud Services offering as follows:"Designed with OpenStack technology, the open-sourced-based architecture ensures no vendor lock-in, improves developer productivity, features a full stack of easy-to-use tools for faster time to code, provides access to a rich partner ecosystem, and is backed by personalized customer support."
Here is a round up of the some of the more insightful coverage.
The Register:Good discussion of the HP offering and the fact that HP hasn't really embraced Microsoft as much as they had intended back in 2010. Instead, HP made the move to OpenStack, after only joining OpenStack less than one year ago.Lessons for HP Box Jockeys on the Amazon Warpath
PCWorld:In this article, reporter Joab Jackson called out seven of the 40 partners HP announced, identifying them as part of the "impressive roster" of partners HP announced. CloudBees was one of the seven.HP Expands Cloud Services Beta
GigaOM:Analyst Barb Darrow called out CloudBees in her summary of nine of the 40 HP partners included in the HP announcements.HP puts OpenStack cloud into public beta
TechTarget - SearchSOA:This article focuses on the importance to HP of a pervasive ecosystem for its platform, and identified CloudBees in a very short list of vendors who represent, "some major forces in various cloud arenas."HP details its cloud computing strategy at OpenStack
Unrelated to the HP news, CloudBees was also called out in a SearchCloudComputing article focused solely on CloudBees and a CloudBees customer (this article can be accessed only if you are registered with TechTarget). This is a great article that highlights how ARTstor leveraged the CloudBees PaaS to improve its business and how it went about selecting CloudBees as their PaaS solution. Michelle Boisvert’s article, “Is PaaS just another four-letter word in cloud computing?” argues that the noise around PaaS is righteously warranted. She introduces ARTstor as a company under pressure to quickly take advantage of the cloud’s benefits. Overall, a great piece for CloudBees that communicates a customer’s perspective on why CloudBees is the front runner in the PaaS market!
Happy Reading!
Onward,Sacha
CEO
CloudBees
www.cloudbees.com



Follow CloudBees:

    

We are proud to announce that a new major release of JenkinsMobi is now available for download from iTunes AppStore.

New version 3.0.3 solves many of the problems notified through crash reports by the users and most notably:

- iOS 5.1 multi-tasking
- HomeViewController is now fixed and more stable
- IndexOutOfBound when reloading views
- Significantly improved user list load time

Moreover one major issue was found on cookie management while logging out from a Jenkins instance (see JenkinsMobi Support Forum) and now is completely resolved.

Now before each login all cookies are removed from app shared storage, more secure and reliable.

You can install or upgrade JenkinsMobi on your phone by searching “JenkinsMobi” or visiting the following URL: http://itunes.apple.com/gb/app/jenkinsmobi/id467020180?mt=8

Stay with us … new features are coming out !

LMIT and JenkinsMobi Development Team.

The first stop of Jenkins User Conference world tour this year was Paris, where there's a considerable concentration of Jenkins developers and users (sometimes those of us on the other side of the Atlantic call them "the French gang"). The event was held a day before Devoxx France, in the hope that we would attract more attendance.

I believe there are 100+ people that actually showed up, and we had a full day divided into two tracks, talking about all things Jenkins. While many were French, some of the attendees came from all over Europe. I was able to see some familiar faces, as well as those who I've only known by their names.
I tried to get in and out of both tracks to get a sense of what was going on, so that I could report out later, and here's my notes.

I kicked off the whole day with a keynote, looking back at what we've done since we became Jenkins. I've looked into various activities in the community, such as LTS, Jenkins CIA, Ruby plugin development, and UI enhancements. I updated my adoption statistics slides (we are happy to report that we crossed 40K installations in our tracking!), and reported that JFrog is now hosting our repositories that we rely on for development. I showed some of what we've been working on lately at CloudBees — such as the upcoming version of Jenkins Enterprise by CloudBees that supports high-availability, our giving away the Folder plugin for free (as in beer), and previews of some not quite public yet features, which is a treat only for those who came!

In the first slot, Gregory Boissinot went through a plugin development workshop. This was actually something I really wanted to understand, so that I get the objective view on where the pitfalls are. Even though the talk was in French, I did understand the code he was showing, and I took some notes about having some kind of skeleton code generator — for example, there's a common pattern for building an UI bound model object (for asking the user to enter data that has structures, persisting them, and so on), and having a code generator command line tool (like jenkins.rb has) could be really handy.

In another room, Nicolas and Mathieu were showing their "Build Flow" plugin, which lets you write a workflow in Groovy DSL. Choreographing a complex workflow that involves multiple jobs is a common challenge among many Jenkins users, and so this talk was well attended, and I'm really looking forward to seeing this plugin mature (there's a separate effort to integrate BPMN workflow into Jenkins, see more about that here.) One thing I learned about Groovy DSL since then is the AST transformation. I'm thinking it might allow us to convert the DSL workflow script into a continuation passing style so that you can suspend/resume workflow at arbitrary point.

The day was so packed that we didn't even waste the lunch time! While attendees were eating, we had lightening talks in the room. Olivier showed off how Apache runs Jenkins, which is quite sizable, then I pitched in for Domonik, who couldn't make it to the conference, and covered the Scriptler plugin. Vincent followed and covered the similar Groovy system console. Harpreet then closed off the lunch lightening talks by showing the templates plugin in Jenkins Enterprise by CloudBees.

In the afternoon, Arnaud, one of our French gang, showed how you can set up iOS development on Jenkins (from code change to test, to the delivery of the binaries to actual phones). Bruno then did a demo of how he uses DEV@cloud and RUN@cloud to quickly set up continuous deployment for Java webapps. For system integraters that deal with lots of projects, I think it is a great combination (for example, allowing you to hand over the entire development environment to the customer when the project is over).
While all that was going on in one room, in another room Lars Kruse showed off how the old meets the new — where you take ClearCase UCM and use it to do validated merge, in which only the changes tested by Jenkins become visible to the rest of the team. I personally don't know much about ClearCase, but it was very interesting that emerging techniques like validated merge can be applied on more traditional SCM tools. He also said his company works with clients to develop custom Jenkins plugins. I always felt that any big company adopting Jenkins need some custom glue plugins, and I regularly come across those companies, but CloudBees can only help so many. It's great to see that there are more help available now!

The talk that followed was from Julien Carsique from Nuxeo, discussing how he manages and improves the CI environment for his organization. Now, I regret I didn't take all the notes about details, but I think this was one of the best presentations of the day for me. I remember thinking that if we had the best Jenkins administrator award for those who push things to the limit and beyond, he would be my top pick. IIRC, he had a major project with multiple Maven modules that span across different repos and all. He set up Jenkins such that any change triggers a cascade of new builds of downstream jobs, which later then fan out to cross-platform test jobs, then he made the whole thing visual so you can track exactly where time is spent and how those changes propagate. I think this was very inspirational to many other fellow Jenkins users, and I hope he will put his slides somewhere so that other people can mimic what he's done.
Back to the big room, my fellow colleagues Stephen and Harpreet did the only introductory talk in the whole day, going through check lists of production Jenkins deployments, recapping why you want CI, etc. (And I always forget that there are still many who don't know much about Jenkins!)

It was also great to see and hear Sebastian Bergmann, the guy behind Jenkins PHP, talk about Jenkins and PHP integrations. I wish we had more of those people who bridge our community to different communities and help us spread the ideas. He even kindly gave me his Jenkins/PHP book and signed it for me!

Aside from talks, food was great, especially for those of us who came from the U.S.

I've got some good inspirations about where we need to work. And I also managed to implement the search filter in the update center during the day, in response to the valid complaint from Sebastian. For virtual communities like ours, it's really good to meet people in the meeting space and put faces to names. Build automation engineers are often somewhat lonely in their respective organizations — there just aren't that many people who get excited about automating things away, and so having so many of like-minded folks in one room was by itself a great experience.

On the things to improve side, I felt that workshops was tricky to do in a limited time and in a big room. Maybe it would work out better if there's a smaller room where a smaller number of people can gather and hack away (probably some time slots designated for some specific topics), then we can collectively merge pending important pull requests, teaching how to develop plugins, or ask others to look at their plugins, etc. There also can be a valid discussion about JUC, run nicely in exchange for an admission fee, vs. JUC run cheaply but free.

In any case, I think the quality of presentations were very good, and knowing local Jenkins developers/users will help expand your horizons. As I said in the beginning, we are taking JUC around the world this year. The one in New York is already coming up next week (May 17), followed by Herzelia (Israel - July 5 (July 29), San Francisco (September 30) and Antwerp (November 13).

Please register while seats are still available (and the cost is even lower during the Early Bird registration period)!

Kohsuke Kawaguchi
Founder, Jenkins Community and
Elite Developer, CloudBees
www.jenkins-ci.org
www.cloudbees.com



Follow CloudBees:
   

All over the world we are witnessing major companies shift their business to the cloud. This comes with obvious benefits but also creates new bottlenecks. Productivity increases exponentially, pushing DevOps in to more automated release processes to keep up with the growth. I recently came across a blog by Martin Tantow that nicely explains how the application of cloud technologies actually helps to bring Dev and Ops together. Adopting DevOps and the cloud require some major changes, but the statistics don’t lie. It’s worth it!

Bridging the DevOps Divide by Leveraging Cloud Technologies

In today’s increasingly instrumented and interconnected world, business leaders are seeking ways to leverage strategies that optimize growth, improve agility, driver higher-value customer relationships and lead to increased revenue. Many see cloud as the answer. In fact, a recent IBM Institute for Business Value study found that 90 percent of organizations expect to adopt or substantially deploy a cloud model in the next three years. While cloud adoption is becoming more mainstream, organizations are also now moving beyond virtualization to higher value stages of cloud computing.

As a result, the rate at which new cloud-based applications and updates are being delivered is often faster than the IT operations team can manage – creating a divide between development and operation sides of the business. How can companies leverage cloud and increase business agility without sacrificing operation discipline, quality and governance?

Through continuous software delivery practices, companies can bridge the DevOps divide and leverage cloud technology in a strategic way that also sets themselves apart from the competition by enabling the creation of differentiated products and services quickly and efficiently — bringing products to market on time and under budget.

The numbers speak for themselves. Companies can expect to see:

1. 20% reduction in resource costs while increasing predictability of deployments through low touch and self-service applications
2. 40% more agility by streamlining operation and development collaboration with in-context communication
3. 20% increase in application service availability and performance by improving stakeholder of alignment development, test and ops
4. 5 times faster application build and deployment times and reduced errors by 93% in one client example

Cloud computing can fundamentally change the economics of business infrastructures and speed the delivery of innovative products and services – yet the DevOps divide cannot be overlooked if companies want to achieve the full potential of cloud.  As enterprises look to accelerate delivery and realize agility, many are starting their cloud implementation journey around development, test and deployment operations to ensure coordination between development and operations.

What do you think about the DevOps divide? Will moving to the cloud help bridge the gap?

Click here to read the full article

Click here to download our free whitepaper ‘Does The Cloud Simplify Application Release Deployment’

Very recently Electric Cloud celebrated its 10th birthday as a company and I thought it’d be interesting to share some notes that I found in a office-cupboard summarizing 18 prospect interviews that were being conducted by our 2 founders John Ousterhout and John Graham-Cumming prior to actually founding the company, right in the aftermaths of the dotcom bubble.

These interviews were being done with large and small companies in Silicon Valley at that time and as you can imagine, the amount of change that’s happened in all of these companies are enormous. Some are no longer around due to acquisitions and other circumstances, but below are a couple of nostalgic anecdotes I thought was worth sharing with you:
• One truly innovative multidisciplinary company, today regarded as the global role-model for all Internet companies with some 33,000+ employees, had at the time of the interview 280 employees – where 100 of them were software engineers and apparently only 3 worked in QA!
• A major disruptive company in the virtualization business later acquired by EMC had at this time 60 engineers – current number that I’m able to research is some 9000 employees overall.

The Agile Manifesto had just been published in early 2001 and in these interview-notes, I cannot find any reference to common commodity terms and terminology such as Agile methodologies, Scrum, Kanban, Continuous Integration and Continuous Delivery. Yet when reading through the notes, I was surprised to find that many of the problems, concerns and issues that I hear about today with respect to Agile enablement blockers working with Electric Cloud prospects on a daily basis in my role as the ElectricAccelerator Product Manager very much were problems, concerns and issues already 10 years ago! Below are some quotes I picked up, pretty much summarizing the entire material of notes:
• “We’ve spent millions of dollars to make builds go faster, yet we are not satisfied”
• “We’re struggling to get releases out in time, often due to slow and unreliable builds”
• “My software builds are taking longer and longer, due to the proliferation of platforms I need to support and the staggering growth in complexity.”
• “If you could speed up my build by a factor of 10x, that would be huge!”

To quickly put this in perspective compared to the software development world of 2012, today I was in a partner discussion where we discussed a prospect in the automotive industry that had 8-9 hour long nightly builds and 20m+ developer incremental builds – clearly impacting engineering productivity and prohibiting other Agile development methodologies to efficiently be put in place.

Based on these interviews, our two founders compiled a graph illustrating the key prioritized features and value propositions that Electric Cloud should be founded to implement and realize, and I think this is pretty interesting to share with you:

So with Electric Cloud’s flagship product ElectricAccelerator that were designed and built to implement the above top features – where are we today, 10 years later?
• 10x faster builds, requested as a desired feature in almost 90% of the interviews: For the vast majority of our customers, a 10x improvement of their full build times is today commonplace. In fact, in quite a few of our customer deployments we know of acceleration factors exceeding 20, or even 30 and 40x. Last week I actually heard of the most extreme acceleration factor ever with ElectricAccelerator – a 72x speedup bringing a 36h+ build down to less than 30m!
• More platforms supported: To make sure our product is as compatible as possible for the marketplace, the ElectricAccelerator product team are constantly reviewing which platforms are mostly being used in the software industry and considering additional platforms to support. At the time of this writing, ElectricAccelerator runs on all supported Windows platforms, a number of Linux distributions including RedHat, SUSE and Ubuntu, and also on Solaris for both SPARC and x86. All in all, there are 14 major supported platforms that our automated build and QA lanes are covering daily!
• Better Dependency Tracking: One of the major key differentiating technologies of ElectricAccelerator from any other software build solution out there is its ability to detect, track, visualize and react to complete and guaranteed dependency information, without any timing overhead. This is also what enables the massive parallelization and distribution of builds that in turn realizes the dramatic speed improvements.
• Scheduling and Self-service builds: This is deliberately not a feature that ElectricAccelerator was originally designed for to implement, but given all the demand that the marketplace raised for the capability to automatically manage the end-to-end build-test-deploy workflow once the software build speed problem was pretty much solved, Electric Cloud decided to implement and introduce ElectricCommander.

Given this full coverage in terms of the top prioritized features that ElectricAccelerator was originally set out to implement, what are the next area of problems to address for the product? Based on all the user data and knowledge we’ve gathered over the years about software build environments in particular but also software development best practices in general, this was a pretty easy question to answer for me as the Product Manager of ElectricAccelerator: Optimize productivity and efficiency for each individual software developer in the context of a scaled out Agile development methodology, by revolutionizing the way software developer incremental builds are being done!

If you find this above statement interesting and would like to know more details, please don’t hesitate to contact me at drosen (a) electric-cloud.com. In the meantime, stay tuned!

The first stop of Jenkins User Conference world tour this year was Paris, where there's a considerable concentraion of Jenkins developers and users (sometiems those of us on the other side of the Atlantic call them "the French gang") The event was held a day before Devoxx France, in the hope that we attract more attendance.

I believe there are 100+ people that actually showed up, and we had a full day divided in two tracks, talking all things about Jenkins. While many are French, some of the attendees come from all over the Europe. I was able to see some familiar faces, as well as those who I've only known by their names.

I tried to get in and out of both tracks to get the sense of what's going on, so that I can report them later, and here's my notes.

I kicked off the whole day with a keynote, looking back what we've done since we became Jenkins. I've looked into various activities in the community, such as LTS, Jenkins CIA, Ruby plugin development, and UI enhancements. I updated my adoption statistics slides (we are happy to report that we crossed 40K installations in our tracking), and reported that JFrog is now hosting our repositories that we rely on for the development. I showed some of what we've been lately working on at CloudBees — such as the upcoming version of Jenkins Enterprise by CloudBees that support high-availability, our giving away the folder plugin for free (as in beer), and previews of some not quite public yet features, which is a treat only for those who came!

In the first slot, Gregory Boissinot went through a plugin development workshop. This was actually something I really wanted to understand, so that I get the objective view on where the pitfalls are. Even though the talk was in French, I did understand the code he was showing, and I took some notes about having some kind of skeleton code generator — for example, there's a common pattern for building an UI bound model object (for asking the user to enter data that has structures, persisting them, and so on), and having a code generator command line tool (like jenkins.rb has) could be really handy.

In another room, Nicolas and Mathieu were showing their "build flow" plugin, which lets you write a workflow in Groovy DSL. Choreographing a complex workflow that involves multiple jobs is a commoon challenge among any Jenkins users, and so this talk was well attended, and I'm really looking forward to seeing this plugin mature (there's a separate effort to integrate BPMN workflow into Jenkins, see more about that here.) One thing I learned about Groovy DSL since then is the AST transformation. I'm thinking it might allow us to convert the DSL workflow script into a continuation passing style so that you can suspend/resume workflow at arbitrary point.

The day was so packed that we didn't even waste the lunch time! While attendees are eating, we had lightening talks in the room. Olivier showed off how Apache runs Jenkins, which is quite sizable, then I pitched in for Domonik, who couldn't make it to the conference, and covered the scriptler plugin. Vincent followed and covered the similar Groovy system console. Harpreet then closed off the lunch lightening talks by showing the templates plugin in Jenkins Enterprise by CloudBees.

In the afternoon, Arnaud, one of our French gangs, showed how you can set up the iOS development on Jenkins (from code change to test to the delivery of the binaries to actual phones.) Bruno then did a demo of how he uses DEV@cloud and RUN@cloud to quickly set up continuous deployment for Java webapps. For system integraters that deal with lots of projects, I think it is a great combination (for example allowing you to hand over the entire development environment to the customer when the project is over.)

While all that is going on in one room, in another room Lars Kruse showed off how the old meets the new — where you take ClearCase UCM and use it to do validated merge, in which only the changes tested by Jenkins become visible to the rest of the team. I personally don't know much about ClearCase, but it was very interesting that emerging techniques like validated merge can be applied on more traditional SCM tools. He also said his company works with clients to develop custom Jenkins plugins. I always felt that any big company adopting Jenkins need some custom glue plugins, and I regularly come across those companies, but CloudBees can only help so many. It's great to see that there are more help available now!

The talk that followed was from Julien Carsique from Nuxeo, discussing how he manages and improves the CI environment for his organization. Now, I regret I didn't take all the notes about details, but I think this was one of the best presentations of the day for me. I remember thinking that if we had the best Jenkins administrator award for those who push things to the limit and beyond, he would be my top pick. IIRC, he had a major Maven projects that span across different repos and all. He set up Jenkins such that any change triggers a cascade of new builds of downstream jobs, which later then fan out to cross-platform test jobs, then he made the whole thing visualized so you can track exactly where the time is spent and how those changes propagate. I think this was very inspirational to many other fellow Jenkins users, and I hope he will put his slides somewhere so that other people can mimic what he's done.

Back to the big room, my fellow colleagues Stephen and Harpreet did the only introductory talk in the whole day, going through check lists of production Jenkins deployments, recapping why you want CI, etc. (And I always forget that there are still many who don't know much about Jenkins!)

It was also great to see and hear Sebastian Bergmann, the guy behind Jenkins PHP, talk about Jenkins and PHP integrations. I wish we had more of those people who bridge our community to different communities and help us spread the ideas. He even kindly gave me his Jenkins/PHP book and signed it for me!

Aside from talks, food was great, especially for those of us who came from the U.S. I've got some good inspirations about where we need to work. And I also managed to implement the search filter in the update center during the day, in response to the valid complaint from Sebastian. For virtual communities like ours, it's really good to meet people in the meat space and put faces on names. Build automation engineers are often somewhat lonely in their respective organizations — there just aren't that many people who get excited about automating things away, and so having so many of like-minded folks in one room was by itself a great experience.

On the things to improve side, I felt that workshops was tricky to do in a limited time and in a big room. Maybe it would work out better if there's a smaller room where smaller number of people can gather and hack away (probably some time slots designated for some specific topics), then we can collectively merge pending important pull requests, teaching how to develop plugins, or ask others to look at their plugins, etc. There also can be a valid discussion about JUC, run nicely in exchange of admission fee, vs JUC run cheaply but free.

In any case, I think the quality of presentations were very good, and knowing local Jenkins developers/users would help expand your horizon. As I said in the beginning, we are takin JUC around the world this year. The one in New York is just in the next week, followed by Herzelia (Israel), Tokyo, San Francisco, and Antwerp. Please register while seats are still available!

The first stop of Jenkins User Conference world tour this year was Paris, where there's a considerable concentraion of Jenkins developers and users (sometiems those of us on the other side of the Atlantic call them "the French gang") The event was held a day before Devoxx France, in the hope that we attract more attendance.

I believe there are 100+ people that actually showed up, and we had a full day divided in two tracks, talking all things about Jenkins. While many are French, some of the attendees come from all over the Europe. I was able to see some familiar faces, as well as those who I've only known by their names.

I tried to get in and out of both tracks to get the sense of what's going on, so that I can report them later, and here's my notes.

I kicked off the whole day with a keynote, looking back what we've done since we became Jenkins. I've looked into various activities in the community, such as LTS, Jenkins CIA, Ruby plugin development, and UI enhancements. I updated my adoption statistics slides (we are happy to report that we crossed 40K installations in our tracking), and reported that JFrog is now hosting our repositories that we rely on for the development. I showed some of what we've been lately working on at CloudBees — such as the upcoming version of Jenkins Enterprise by CloudBees that support high-availability, our giving away the folder plugin for free (as in beer), and previews of some not quite public yet features, which is a treat only for those who came!

In the first slot, Gregory Boissinot went through a plugin development workshop. This was actually something I really wanted to understand, so that I get the objective view on where the pitfalls are. Even though the talk was in French, I did understand the code he was showing, and I took some notes about having some kind of skeleton code generator — for example, there's a common pattern for building an UI bound model object (for asking the user to enter data that has structures, persisting them, and so on), and having a code generator command line tool (like jenkins.rb has) could be really handy.

In another room, Nicolas and Mathieu were showing their "build flow" plugin, which lets you write a workflow in Groovy DSL. Choreographing a complex workflow that involves multiple jobs is a commoon challenge among any Jenkins users, and so this talk was well attended, and I'm really looking forward to seeing this plugin mature (there's a separate effort to integrate BPMN workflow into Jenkins, see more about that here.) One thing I learned about Groovy DSL since then is the AST transformation. I'm thinking it might allow us to convert the DSL workflow script into a continuation passing style so that you can suspend/resume workflow at arbitrary point.

The day was so packed that we didn't even waste the lunch time! While attendees are eating, we had lightening talks in the room. Olivier showed off how Apache runs Jenkins, which is quite sizable, then I pitched in for Domonik, who couldn't make it to the conference, and covered the scriptler plugin. Vincent followed and covered the similar Groovy system console. Harpreet then closed off the lunch lightening talks by showing the templates plugin in Jenkins Enterprise by CloudBees.

In the afternoon, Arnaud, one of our French gangs, showed how you can set up the iOS development on Jenkins (from code change to test to the delivery of the binaries to actual phones.) Bruno then did a demo of how he uses DEV@cloud and RUN@cloud to quickly set up continuous deployment for Java webapps. For system integraters that deal with lots of projects, I think it is a great combination (for example allowing you to hand over the entire development environment to the customer when the project is over.)

While all that is going on in one room, in another room Lars Kruse showed off how the old meets the new — where you take ClearCase UCM and use it to do validated merge, in which only the changes tested by Jenkins become visible to the rest of the team. I personally don't know much about ClearCase, but it was very interesting that emerging techniques like validated merge can be applied on more traditional SCM tools. He also said his company works with clients to develop custom Jenkins plugins. I always felt that any big company adopting Jenkins need some custom glue plugins, and I regularly come across those companies, but CloudBees can only help so many. It's great to see that there are more help available now!

The talk that followed was from Julien Carsique from Nuxeo, discussing how he manages and improves the CI environment for his organization. Now, I regret I didn't take all the notes about details, but I think this was one of the best presentations of the day for me. I remember thinking that if we had the best Jenkins administrator award for those who push things to the limit and beyond, he would be my top pick. IIRC, he had a major Maven projects that span across different repos and all. He set up Jenkins such that any change triggers a cascade of new builds of downstream jobs, which later then fan out to cross-platform test jobs, then he made the whole thing visualized so you can track exactly where the time is spent and how those changes propagate. I think this was very inspirational to many other fellow Jenkins users, and I hope he will put his slides somewhere so that other people can mimic what he's done.

Back to the big room, my fellow colleagues Stephen and Harpreet did the only introductory talk in the whole day, going through check lists of production Jenkins deployments, recapping why you want CI, etc. (And I always forget that there are still many who don't know much about Jenkins!)

It was also great to see and hear Sebastian Bergmann, the guy behind Jenkins PHP, talk about Jenkins and PHP integrations. I wish we had more of those people who bridge our community to different communities and help us spread the ideas. He even kindly gave me his Jenkins/PHP book and signed it for me!

Aside from talks, food was great, especially for those of us who came from the U.S. I've got some good inspirations about where we need to work. And I also managed to implement the search filter in the update center during the day, in response to the valid complaint from Sebastian. For virtual communities like ours, it's really good to meet people in the meat space and put faces on names. Build automation engineers are often somewhat lonely in their respective organizations — there just aren't that many people who get excited about automating things away, and so having so many of like-minded folks in one room was by itself a great experience.

On the things to improve side, I felt that workshops was tricky to do in a limited time and in a big room. Maybe it would work out better if there's a smaller room where smaller number of people can gather and hack away (probably some time slots designated for some specific topics), then we can collectively merge pending important pull requests, teaching how to develop plugins, or ask others to look at their plugins, etc. There also can be a valid discussion about JUC, run nicely in exchange of admission fee, vs JUC run cheaply but free.

In any case, I think the quality of presentations were very good, and knowing local Jenkins developers/users would help expand your horizon. As I said in the beginning, we are takin JUC around the world this year. The one in New York is just in the next week, followed by Herzelia (Israel), Tokyo, San Francisco, and Antwerp. Please register while seats are still available!

                    
When we announced AnyCloud in February, we discussed our ability to deploy to OpenStack-based providers. Behind the scenes, that meant we had been working closely with HP Cloud Services to take advantage of the great work they've done and which is now available to the general public. What that means for you as a CloudBees customer is that you can make use of HP as a trusted cloud infrastructure provider with a real enterprise sensibility, probably also a provider your company already has an existing relationship with. So you get all the advantages of the CloudBees PaaS (productivity, faster development, built-in continuous integration and delivery, world class service, all at aggressively low pricing) along with the backing of a tremendous company with over $120 billion in revenue that isn't trying to convince you their packaged middleware is taking you to the cloud.      

Let's take a look at some specifics about the CloudBees PaaS on HP Cloud...

OpenStack.  CloudBees was born on AWS, but with our AnyCloud offering, we've been running on vSphere and OpenStack-based infrastructure, too.  Since we have an abstraction layer in the CloudBees Platform to work across IaaS providers, I asked Michael Neale, the lead on our HP Cloud work, to comment on what he found on HP compared to others. Here are his thoughts:
"HP cloud is becoming quite full featured - yet still OpenStack-standards based.  I can use the nova CLI for instance. The Web UI seems fast, friendly and easy to use.  They have done a great job with OpenStack so far. As HP rolls out more images and features, it looks super competitive - and so far staying pretty simple to use. Having a fully featured infrastructure cloud to compete with AWS is encouraging.  It will be interesting to track the roll out of features."The Experience.  Probably the most exciting thing about CloudBees on HP Cloud Services is... that it just looks and feels like CloudBees once you've registered your HP Cloud Services resources with us.  We treat those resources like other "dedicated" resources already available on CloudBees.  So, you can deploy to HP Cloud Services and set up continuous deployment to HP from Jenkins hosted on DEV@cloud.  When you associate server resources from your HP Cloud Services account with CloudBees, we manage them on your behalf as you deploy, scale down-up-and-out, monitor and make use of CloudBees partner services, like New Relic.

Why CloudBees?  You'll find other PaaS players on HP Cloud Services, so what sets CloudBees apart? In addition to the usual differentiators, the power of AnyCloud really shines brightly with HP Cloud Services.  That means we manage the entire stack for you, and you're not installing or maintaining the PaaS itself or the underlying runtime stack.  You can use other public cloud resources, or target the HP cloud, all from a single environment or command line.  Many customers would like a combination of elastic, public cloud resources for some of their activities, like dev/test, together with your HP Cloud Services resources for other activities. In both cases, though, they want a consistent experience, with CloudBees managing the workloads and underlying infrastructure in a way that maximizes utilization and minimizes their operational burden.  Only CloudBees AnyCloud offers that kind of flexibility.

If you're an HP Cloud customer exploring CloudBees, contact us to see the CloudBees PaaS in action on HP Cloud Services.  If you're already a CloudBees customer, then you can now use not just AnyCloud, but the HP Cloud.

Learn more!

• Read about CloudBees and HP Cloud Services
• Read the press release
• Watch the video -- see a CloudBees application deployed on HP Cloud Services:

Steven G. Harris, Senior VP of Products
CloudBeeswww.cloudbees.com

Follow CloudBees:

     

This one is for the managers out there who straddle the Dev and Ops divide.

Alex Honor and Betsy Hearnsberger have seen the importance of release management dramatically change over the past decade. Through their collective experiences working inside organizations like E*TRADE, Ask.com, NASA Ames, and Zynga (as well as Alex's subsequent consulting work at DTO Solutions) they've each amassed a wealth of experience and insight into dealing with high velocity release engineering in large scale and complex organizations.

Since their professional paths have crossed multiple times, I figured I'd get Alex and Betsy together in front of a whiteboard for a chat. In these videos they talk about the common challenges they see, advice for managers addressing these issues, solution approaches that work, and criteria for tool selection.

Please note that these videos were originally shot on July 29, 2011. Due to a technical problem is was thought that these videos were lost. Lucky for us, they have been fully recovered. I'll have to get them both on camera again soon to discuss how their thinking has evolved since then. 

 

Part 1: Common problems

 

Part 2: Management's approach to the problems

 

Part 3: Solution patterns and tool selection

 

I never thought of the DevOps movement having any sort of connection to community building. Perhaps that’s why I so enjoyed reading the poignant comparisons offered by Venessa Paech in her self-titled blog. The overall message is that everyone will be more effective if they work together. I’ve only included an expert of the full blog and I highly recommend reading the whole thing, if for no other reason than to learn why no one celebrates ’Middle Aged White Man’ day.

DevOps and strategic community management alliances

I have many friends who work in ops or as developers, and as a community thinker, I’ve been fascinated by the DevOps movement for some time.

You can read more about it here, from the godfather of the movement, Patrick DeBois.

Here’s my take.

Two often warring tribes of the IT landscape, both with challenging jobs to pull off in a rapidly iterating world, are working to collaborate more constructively and understand each other a little better, to make their own daily grind less obstacle riddled, and cultivate a leaner, more united playground.

It’s an amazing piece of community building, happening on an international scale (and inspiring music videos).

It involves challenging assumptions and confronting boundaries and comfort zones, so it’s an uphill battle that has its critics. I see value –  understanding where you live in your IT ecosystem and a real empathy for your peers should lead you to better ways of working (and playing).

I’m no DevOps expert but over the years I’ve come to have enormous respect for the guys and gals that make our sure our communities are up and running.

Managing vast communities in many large enterprises and organisations, developers and sysadmins are among the folks I talk to the most on a regular basis. We’ll discuss risks and issues that will emerge within the community from the latest release of tools or features; we’ll comb through log files looking for problem IPs or users. I’ll work with them to develop new reports that tell me about critical community behaviours. And we’ll bond while having a whinge that no one seems to really understand the users of our website except us.

The truth, while it is undoubtedly strategic, community management is absolutely operational. In some respects, ops is a more natural paradigm for our work than marketing, which is designed to focus on the ideal rather than the reality.

And lets not forget that most of the earliest online community managers were system administrators – SysOps are our forefathers.

So here’s some highlights of my presentation, covering ’8 reasons #ops and #cmgmt should be strategic allies’.

Think of us as Social Ops.

Reason 1: Nobody understands what we do

Ops and community management folks struggle to articulate precisely what we do. It’s not that we can’t describe it. It’s that when we start, eyes generally respond by glazing over.

Most people, if they think of it at all, consider ops some sort of auto-magical mojo that either runs itself, or, involves aSheldon Cooper-type typing furiously while simultaneously kicking ass in an online game and bidding for geek memorabilia on eBay.

Many, when they think of community management, think of perky, relentlessly positive cheerleaders (somewhere between the casts of Bring it On and Glee) who sit around posting banalities and pretty pictures to various, largely superficial social networks encouraging people to buy more of brand x, and Be Happy!

The truth is actually less appealing, but way more interesting.

Reason 2: We both use metrics to tell important stories

If there’s one thing ops folk are known for, it’s their talent for measuring. Everything. They understand that numbers reveal secrets and a bigger picture that might otherwise be missed.

Despite our qualitative qualities, (good) community managers are also data nerds. We recognise the importance of fuzzy data, but we’re constantly striving to measure and report on numbers that tell the most relevant stories about our communities.

We understand that number of users is fundamentally meaningless, if there’s not a high ratio of replies to posts and viable sharing activity within and beyond the social system. We know that a lot of activity isn’t good in and of itself. It may point to aggressively vocal members, gaming of the system and a need for re-calibration.

We look at reported content volumes and how they inform the health of a community. And we understand just how important lurkers are.

Reason 3: We invest a lot of time running triage for others

Though we have our own priorities and strategic objectives, ops and community managers are technical and behavioural ‘fixers’.

We get stuff back online, diagnose problems and turn bad situtation around really well. So we’re the go-to guys and gals for this work. While we’re happy to help out, this can create the expectation that we’re the resident clean up crew for (avoidable) mistakes.

Here’s some examples from the community management world:

“The users hate the features we released. I know they didn’t ask for them, but make them love them!”

“We didn’t really consider what to do with this product after the first month. We’re working on other stuff now, can you make a plan for us?”

“We’ve installed a giant fly out advertisement over the top of sign in. Can you make sure that’s not an issue?”

Click here to read the full article

Using ServiceNow? Learn how you can achieve continuous application deployments with the latest ServiceNow and Nolio ASAP integration, minimizing application release windows from days and hours to just minutes!

‘ReleaseNow with ServiceNow Part II’ is a free educational webinar that will show you how full incorporation of Nolio’s Zero Touch Deployment™ process with ServiceNow can minimize time-to-production, reduce bottlenecks, eliminate manual errors and ensure IT governance and compliance.

Following the success of our first ServiceNow webinar, Nolio’s Product Director Ron Gidron will showcase the unique capabilities of this bi-directional integration including:

1. Triggering fully automated release processes from within ServiceNow
2. Ensuring full IT governance and compliance with audited application releases
3. Managed application provisioning and application incremental releases

“Managing change or deployments in ServiceNow requires a series of time-consuming manual steps. Full integration with Nolio ASAP allows users to enjoy fully automated deployments without having to change any aspect of their current application management system. Users will have rapid and accurate deployments along with complete auditability, visibility and control.” – Ron Gidron, Nolio Product Director

Following the presentation and live demo, all participants will have the opportunity to participate in a question and answer session with Ron.

The webinar will be held on May 23, 2012 at 11am EST / 4pm GMT.

Don’t forget to look for us at ServiceNow’s Knowledge12 this year in New Orleans. We’ll be at booth 138 to answer questions, give demos and unveil our latest ServiceNow and Zero Touch Deployment™ integration.

Click here to learn more about ‘ReleaseNow with ServiceNow Part II’ and register for the event

Click here to view last year’s ‘Integrating Zero Touch Deployment™ with ServiceNow for Faster & Easier Application Releases’

Click here to learn more about Nolio’s ServiceNow Solution

About Ron Gidron

Ron has over a decade of experience in enterprise application management. He is the Product Director at Nolio and an expert in release deployment automation, with an extensive background in enterprise application monitoring, performance tuning and testing. Ron has worked as a consultant for Global 500 enterprises across all industry verticals.

Conferences: XP2012 is in Neo Technology’s hometown of Malmo, Sweden [link] The BCS CMSG conference program is also out [link] VMWare sent a reminder for VMWare Forum 2012 next week  [link]...

Visit The Build Doctor for the full article.

Nolio’s partner Serena recently sat down with APMdigest to discuss the challenges and advantages of DevOps. Keep reading to see what David Hurwitz, Senior VP of Marketing, has to say.

Q&A: Serena Talks About DevOps APM: For those who may not be familiar, what is DevOps?

DH: DevOps is an IT movement to deliver better communication, interaction and productivity between Development and Operations. The aim is to bring these two traditionally divided sides of the IT house closer together, bridging the divide between Development, which tends to concentrate on how features and functionality of the software are pushed forward, and Operations with its focus on reliable performance and delivery of these applications.

APM: DevOps seems like it should have been considered a good idea years ago. What has changed recently in our industry that has made DevOps such a hot topic today?

DH: The waning tolerance for application errors and the faster pace at which software/online services must be developed and delivered are already huge drivers to the introduction of new methodologies in Development and Operations. But to enable even faster hand-overs and meet these cost reduction targets, the intersection where Development meets Operations requires a re-think in its own right.

APM: What are the main barriers today that keep development and operations from working together?

DH: A primary challenge to DevOps is the way in which the handoff between Development and Operations is managed. Even though the trend is for companies to move to development automation, few can link all of the critical stages of the application delivery process.

However, Gartner reports that as software demands become more complex, and the teams working on these applications grow in number, the individual management practices for each stage of Development and Operations are being forced to evolve into more automated and linked up processes. So the issues surrounding handoff might actually slowly resolve themselves through sheer necessity.

APM: Does DevOps usually require a corporate culture change?

DH: It requires accountability on the part of developers to see their code through to successful production. Of course, that is only a reasonable proposition when they are given the necessary visibility and are able to depend on a fast and agile deployment process.

APM: How does a company go about starting a DevOps initiative? Is this something that can be homegrown or do they need a consultant?

DH: Many companies are finding that their existing Release Management and/or Change Advisory Board functions are morphing into DevOps initiatives. Thus the initiative can be homegrown. However, it requires automation to succeed at anything other than a micro level. The automation almost certainly has to come from outside, as the required process and deployment orchestration is considerable. The good news is that off-the-shelf release management solutions are now available that solve these problems in depth.

APM: What role can development teams play in application performance? What can they do to improve app performance in the development stage?

DH: It is not just application performance that dev teams need to concern themselves with. Rather, they need to think about how to architect their apps so they can be deployed easily, can be configured while in production, and so that there is traceability back into requirements. That said, DevOps thinking and staffing should provide developers with critical insight into application performance, thus guiding developers to the creation of performance enhancing changes, which can then be quickly deployed.

APM: As part of DevOps, should the operations team be providing more guidance to the developers?

DH: Sure, there should be more collaboration between Ops and Dev. Ops can provide “last mile” feedback to Dev about how architectural and design choices affect both deployment and runtime requirements.

APM: What basic advantages can a company gain if Dev and Ops work together more effectively?

DH: Speed and agility are the main benefits of Dev and Ops working together more effectively. This matters because most systems where DevOps is employed are mission-critical online services, e.g., they are how customers spend money with the company, or get customer care, or other fundamental mission enablement.

Because these systems are externally facing, they need to be revised regularly to keep ahead of the competition and customer expectation.

An enterprise that lacks the speed and agility of DevOps is bound to lose customers to faster moving competitors.

APM: What technologies support a DevOps approach?

DH: Release management technologies most directly support DevOps. These include the ability to automate the workflow around release planning and control, to securely manage a release package’s path to production, and to automate the actual deployment process. The first of these provides the visibility and confidence to operate at an accelerated cadence. The second ensures that release packages are known and pristine. The third slashes the labor and elapsed time for deployment, yielding tremendous cost, agility and quality benefits.

APM: Do you have any predictions on how DevOps will evolve in the near future?

DH: DevOps will become mainstream in all on-line business in the next year or two, albeit not necessarily with the title of DevOps. But the need for speed and agility required in online businesses means that the traditional silos of Dev and Ops must be brought together in organizations that expect to compete in the market.

IT management vendors are starting to compete for this important domain, leading to attractive automation solutions for DevOps practitioners.

Where do you think DevOps is headed? Share your thoughts with us.

Click here to learn more about David Hurwitz and to read the full article

Are you getting the most out of your cloud-based application development lifecycle? Did you know that you can improve the entire application lifecycle - from build to deployment to running production applications in the cloud? At CloudBees, we work hard so you won't have to.  Your CloudBees account comes packed full of a wide range of tools that allow you to instantly set up a full-cycle development environment with project collaboration, Jenkins continuous integration, and multi-stage (development/test/staging/production) environments.

Take advantage of our free Application Lifecycle Management with Platform as a Service (PaaS) training as we demonstrate how you can optimize productivity within your CloudBees account to create application lifecycle proceesses to fit the needs of your team.  By the end of this one hour session, you'll be able to:

• Setup a collaborative development environment
• Create developer application sandboxes for "under development" features
• Inject application configuration and data sources
• Combine CloudBees services to create a continuous development process
• Roll out application updates using multi-stage deployments
• Manage application configuration and data sources for each deployment environment
• And much more 

Details:
Date: May 8, 2012
Time: 1PM - 2PM EDT

Attendance is limited, so register now!

Spike Washburn
VP of Engineering
CloudBeeswww.cloudbees.com

Follow CloudBees:  

Though I am always on the lookout for new insights into the DevOps/NoOps debate, I have to admit that I originally started reading this blog because of the references to Dr. Seuss and the movie ‘Groundhog Day’. What can I say, I’m a sucker for silly cultural references. Whatever the reason I began reading, this article by James Urquhart at gigaom.com is a great overview of the concepts that are driving so much discussion online.

OneOps, TwoOps, RedOps, BlueOps,
DevOps, NoOps, OldOps, NewOps.
This one relies on cooperation.
This one banks on automation.
Say! What a lot of ops there are.

- With sincere apologies to Dr. Suess

Those of you who follow me on Twitter (@jamesurquhart) may have come across frequent recent discussions about new operations methods enabled by cloud computing. The most common terms in these discussions include DevOps and it’s controversial sibling, NoOps. While I think the practices behind these terms are critical to understand as the nature of IT operations shifts to meet new demands, the terms themselves are less than helpful.

So, what I thought I’d do today is walk you through key new operations concepts being adopted by the most cloud-savvy organizations I know, but without allowing terminology to distract the discussion. If I am successful, you’ll be able to look past the label and see the incredible value these new models bring to businesses and institutions of all sizes.

If I am unsuccessful …well, maybe we’ll keep having these conversations for another year—kind of like Groundhog Day.

How is cloud changing IT operations?

Understanding how cloud computing drives fundamental changes to the way IT works, rather than just becoming another way of expressing what has come before, doesn’t rest with its causes, but with its effects:

1. In the past, I’ve gone into some depth about how cloud computing takes IT from server-centric to application-centric operations.

2. I’ve also pointed out that the very nature of “who owns what” in the cloud reorganized operations activities along application, services and infrastructure lines.

3. Furthermore, I’ve also discussed how the highly interdependent, multi-owner nature of the cloud brings forward the science of complex adaptive systems.

In conjunction with these three, one other concept is critical to understand. What matters most to any business is the application of IT to business problems, and the ongoing support of those applications as long as they remain applicable to the business. The rest of IT exists in support of that.

What people not working closely with cloud computing fail to realize is that the application-centric nature of cloud operations shifts the very nature of operations away from infrastructure (as it has been since the mainframe) to, well, applications. (While I usuallyhate electric utility analogies for cloud computing, this is indeed similar to the shift of power generation from private generation to public utilities.)

If you are focusing on running applications in an environment you may or may not control, you focus on how to keep code running, data available, configuration viable and policy enforced. And, since the only thing you control is the code, data, configuration and policy, you have to start focusing on how to build performance and survivability into the application itself.

This was the first lesson learned by the Web 2.0 companies that embraced Amazon’s EC2 and similar services early on. To make an application run well at high scale in someone else’s data center, you have to make the application responsible for its own operational integrity. So, the practice of integrating development tools and people with operations tools and people was born (and became the first form of DevOps—embedding operations skills into development teams).

When skills just aren’t scalable enough

That sounds like a heck of a solution, right? Build applications that utilize the services they run on, and add some custom automation developed by people who understand server, network and storage performance, and how to keep IT running.

Except … there’s one little problem.

In any organization with more than a few applications to deploy and operate, the problem of scaling operations resources (people and tools) to meet that demand becomes a question of not only cost, but coordination across teams. At a small scale, that’s not a big deal. However as application teams grow in number, the problem of coordinating operations activities becomes increasingly difficult.

In an ironic twist, some early adopters of this model report utilization and contention issues when operations staff are embedded in development teams. The operations staff are faced with a dilemma: either selfishly protect the needs of their own projects, or work with other operations staff on other projects to find common ground—potentially impacting their own projects’ approaches or schedules.

The solution for some of the most bleeding-edge of these companies is interesting. Rather than force bureaucracy into the mix, they took a different tack: turn operations into a service—with an API. A platform service, or PaaS, to be exact.

In the PaaS model, developers utilize a service that embeds most of the operations automation for a class of applications right into the platform. You work with code and data, and configuration and most policy is handled for you (though you might provide metadata to influence both). The development team steps back from defining the specific operations logic for their applications, and instead trusts it to the platform service.

Because the developer does little day-to-day operations in the traditional sense, this approach is sometimes called NoOps. I personally despise that term.

It should also be noted that these platforms are essentially coding frameworks provided as a service, which can limit the class of applications to which they apply. So, it is unlikely that a single platform solution will meet the needs of an entire business.

Nonetheless, I think this is the (long-term) future of IT operations: relying on platform services to manage most of the day-to-day performance and survivability challenges a custom application faces. For those companies that are big enough, there may be a team that uses more of a merged DevOps team approach to deliver a platform service of their own. But the vast majority of companies will slowly move away from running infrastructure toward building and constantly tweaking applications.

The road will be far from easy

I say that knowing full well that many of you are reading this thinking “there is no way my organization is moving to a model like that anytime soon.” And I completely agree. Legacy applications weren’t built for this model, and most organizations aren’t set up to handle these tasks, either. The “traditional” siloed operations model will survive for a while at most companies.

But for how long is, in my opinion, uncertain. Take a look at Netflix, a poster child for pushing cloud operations boundaries. They believe very much in the platform services model.

The truth is, if you haven’t already started automating operations for your applications built for the cloud, you are not taking full advantage of the model. Start, at least, with that. However, consider that, as platform services (both public and private) mature, it may make more sense to build your next generation of applications on one.

Just don’t fool yourself. Regardless of which model you adopt, your company will always be doing some sort of operations. Don’t let the terminology fool you when it comes to that.

How do you think cloud is changing IT operations? Share your thoughts!

Click here to read the full article by James Urquhart