Skip to content

CloudBees' Blog - Continuous Integration in the Cloud
Syndicate content
Updated: 9 hours 28 min ago

A Tale of Four Bugs

Mon, 06/26/2017 - 19:33

This post is a post about a recent chain of interconnected bugs and mistakes that we found. I feel there is learning in this tale of many interconnected bugs/mistakes…even if I cannot quite place my finger on what exactly that learning is.

So our story all beings with the great UI refactoring that is JENKINS-43507…

Ideally, any change should be small. Code review works best when the changes are small…but we also have to balance that with ensuring that the changes are complete, so while the refactoring started off as a series of small changes there reached a point of The Great Switcheroo™ where it was necessary to swap everything over with new tests to cover the switch over.

Ideally a lot of the preparation code could have been merged in small change requests one at a time, but it can be hard to test code until it can be used, and adding a change request that consists of new code that isn’t used (yet) and cannot be tested (yet) can make things hard to review… anyway that is my excuse for a collection of changes requests that clock in at nearly 40k LoC.

If we take the GitHub Branch Source PR as an example of the code: github-branch-source-plugin#141

GitHub reports this as:

GitHub diffstats for github-branch-source-plugin#141

This is the part of the story wherein I provide some excuses as to why the PR is not really that big, if you are not interested in excuses you can safely skip it!

Scary…well let’s take a look at that in more detail:

# number of lines of code in new files
$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;') ; \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l
# number of lines of code in deleted files
$ for removed in $(git diff master --name-status | sed -n -e 's/^D.//gp;') ; \
do git diff master -- "$removed" | sed -n -e '/^--- a/d;/^-/p' ; done | wc -l
# number of lines of code removed from existing files
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;') ; \
do git diff master -- "$modified" | sed -n -e '/^--- a/d;/^-/p' ; done | wc -l
# number of lines of code added to existing files
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;') ; \
do git diff master -- "$modified" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l

Still looking like a lot of code… but we can dig further

# number of lines of test code in new files
$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/test') ; \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l
# number of lines of test code in deleted files
$ for removed in $(git diff master --name-status | sed -n -e 's/^D.//gp;' | grep 'src/test') ; \
do git diff master -- "$removed" | sed -n -e '/^--- a/d;/^-/p' ; done | wc -l
# number of lines of test code removed from existing files
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/test') ; do \
git diff master -- "$modified" | sed -n -e '/^--- a/d;/^-/p' ; done | wc -l
# number of lines of test code added to existing files
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/test') ; \
do git diff master -- "$modified" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l

So of the (cli count) 14082 lines “added”, 8405 of those lines were test code and test data…

$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/test/java'); \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p'  ; done | wc -l
$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/test/resources"); \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p'  ; done | wc -l

OK, at least half of the new code is actually new tests. We can do a similar analysis on the production code new files:

$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/main/java'); \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l
$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/main/resources'); \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p' ; done | wc -l

I tend to add a lot of comments and Javadoc to production code… so what is left if we strip that out (and blank lines):

$ for created in $(git diff master --name-status | sed -n -e 's/^A.//gp;' | grep 'src/main/java'); \
do git diff master -- "$created" | sed -n -e '/^+++ a/d;/^+/p' ; done | sed -e 's/^+//' | \
sed -e '/^ *\*/d;/^ *\/\*/d;/^ *$/d;/^ *\/\//d' | wc -l

So more than half of the new production code that I wrote is actually comments…

What about the files that I changed:

# including comments (added lines)
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/main/java'); \
do git diff master -- "$modified" | sed -n -e '/^+++ a/d;/^+/p'  ; done | sed -e 's/^+//' | wc -l
# including comments (removed lines)
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/main/java'); \
do git diff master -- "$modified" | sed -n -e '/^--- a/d;/^-/p'  ; done | sed -e 's/^-//' | wc -l

# excluding comments (added lines)
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/main/java'); \
do git diff master -- "$modified" | sed -n -e '/^+++ a/d;/^+/p'  ; done | sed -e 's/^+//' | \
sed -e '/^ *\*/d;/^ *\/\*/d;/^ *$/d;/^ *\/\//d' | wc -l
# excluding comments (removed lines)
$ for modified in $(git diff master --name-status | sed -n -e 's/^M.//gp;' | grep 'src/main/java'); \
do git diff master -- "$modified" | sed -n -e '/^--- a/d;/^-/p'  ; done | sed -e 's/^-//' | \
sed -e '/^ *\*/d;/^ *\/\*/d;/^ *$/d;/^ *\/\//d' | wc -l

So what this means is that the 13-14k LoC PR is about 3k of new production code (I would argue it is about 1k lines moved and 2k lines added)…which is a lot…but not as bad as the diffstat initially said…and we got about twice that amount of new tests.

So yeah, the pull request should not be that big, but we reached the point where small refactorings could not continue while being reviewed in context.

This is the end of the excuses.

First off, in this refactoring of the GitHub Branch Source I made a simple mistake:

Mistake 1

In all the changes in the PR, I was refactoring old methods such that they called through to the corresponding new methods (to retain binary API compatibility).

Pop-Quiz: Can you spot the mistake in maintaining binary API compatibility in this code?

New code with mistake

For comparison, here is what the old code looked like:

Old code

The mistake is that the effective behavior of the code is changed. I had maintained binary compatibility. I had deliberately not maintained source compatibility (so that when you update the dependency you are forced to switch to the new method) but I was missing behavioral compatibility.

The fix is to add these four lines:

Fixed code

So, I hear you ask, with 6k LoC of new tests, how come you didn’t catch that one?

Mistake 2

The existing tests all called the now deprecated setBuildOriginBranch(boolean), setBuildOriginBranchWithPR(boolean), etc methods in order to configure the branch and pull request discovery settings to those required for the test. Those methods were changed. Previously they were simple setters that just wrote to the backing boolean field. One of the points of this PR is to refactor away from 6 boolean fields with 64 combinations and replace them with more easily tested traits, so the setters will add, update the traits as necessary:

Legacy setter adds traits when missing

So because the tests were setting up the instance to test explicitly, they were not going to catch any issues with the legacy constructor’s default behavior settings, though they did catch some issues with my migration logic.

I used code coverage to verify that I had tests for all of the new methods containing logic…so of course I had added tests like:

Test of legacy setter

Which were checking the branch point in the constructor…so when self-reviewing the code I looked at the 100% code coverage for the method and said Woot! (This was Mistake 2)

Can't have low coverage... if you don't have the code for the missing tests

I had not got any tests that verified the behavioral contract of the legacy constructor.

Mistake 3

Now these plugins have a semi-close coupling with BlueOcean, so one of our critical acceptance criteria includes verification against BlueOcean.

Acceptance criteria

The first step in all that was to bump the dependency versions in BlueOcean to run the acceptance tests…

Now you may remember that I said that I had explicitly broken source compatibility for the legacy methods, this was in order to catch cases where people are assuming that the old getters / setters are exclusively the entirety of the configuration. If you are copying or re-creating a GitHubSCMNavigator instance via code and you use the legacy methods, the new instance will be invalid, your code needs to upgrade to the new traits based API to function correctly.

So when I bumped the dependencies in BlueOcean without changing the code, my expectation was that the build would blow up because of the source incompatibility and it would then be compiler assisted replacement of the legacy methods… oh but little did I count on this little subtle behavioural change between ASM4 and ASM5…

ASM5 needed a signature change so we can enforce @Restricted

Back in early May, Jesse spotted and fixed this issue with the ASM upgrade… 

Without blaming anyone, the mistake here is that the BlueOcean code had not picked up the fix, so there were no compiler errors. The code compiled correctly.

This turns out to be fortuitous…

Mistake 4

BlueOcean’s create flow for GitHub needs to reconfigure the GitHubSCMNavigator to add each repository that is “created” into the regex of named repositories to discover.

Now, in hindsight, there is a lot wrong with that… but the mistake was to recreate a new instance of the GitHubSCMNavigator each time, rather than reconfigure the instance.

In fact the original code even had a setter for the regex field:

Old code had setPattern(...)

So to some extent there was no need to replace the existing instance with every change:

Replacing the instance always (last line)

But, in principle there should be nothing wrong with replacing it each time…and in any case the new repository may require the credentialsId to be updated and the pre-JENKINS-43507 code used a final field and did not provide a setter…

The mistake here was not to replicate the rest of the configuration. In effect, every time you created a pipeline on GitHub using the BlueOcean creation flow, you blew away any configuration that had been applied via the classic UI: JENKINS-45058…the code should really have looked like this:

Pre-JENKINS-43507 fix for JENKINS-45058

So how did we discover all four of these mistakes?

Well my PR #1186 that bumped the plugin versions had test failures:

OMG! Failing tests, it is the end of days

The fact that the compilation succeeded rather than fail as expected (because of the @Restricted) annotation exposed Mistake 3

Then Mistake 4 actually exposed Mistake 1… if BlueOcean was preserving the configuration on creation these tests may not have failed…certainly a manual verification of the test scenario might have resulted in the test failure being chalked up as a bad test, but because the configuration was continually being reset to the constructor default, the manual verification forced Mistake 1 to the surface:

Manual verification escalates attention

So Mistake 1 would have been caught if we didn’t have Mistake 2…

Once you catch a mistake in production code, you typically add tests so part of fixing Mistake 1 was to also fix Mistake 2

If it were not for Mistake 3, running the BlueOcean tests with the updated plugin versions would have required code changes that would probably have bypassed Mistake 4 and we would have missed Mistake 1 in making those code changes…

Without Mistake 4 we might not have found Mistake 1…

Without Mistake 1 we might not have found Mistake 4…

Four interrelated mistakes and without anyone of them we might not have found any of the others.

As I said at the beginning, I feel there is learning in this tail of many interconnected bugs/mistakes…even if I cannot quite place my finger on what exactly that learning is.

Hopefully you have enjoyed reading this analysis!


Blog Categories: Developer Zone
Categories: Companies

CloudBees Awarded "Best in Show - DevOps" in the 2017 SD Times 100

Thu, 06/22/2017 - 19:56

When you win an award, one time, it is an unexpected delight. When you win it a second time, you think “wow.” Third time lucky, you count your blessings. But the fourth, fifth and sixth times? You feel really honored, especially when it’s an award from a publication the likes of SD Times. Yes, CloudBees has been awarded status as an SD Times 100 winner - for the sixth year in a row. We are truly humbled.

We think the award and our longevity with it is a true testament to the ongoing innovation CloudBees strives for and that our employees deliver on every day, whether in engineering, sales, technical support, marketing or administration. We have an amazing customer base - many of them at the leading edge of DevOps and continuous delivery, returning real business value to their companies every day. All of them using our enterprise Jenkins offerings to power their business.

The SD Times 100 list is a collaboration by the editors of SD Times to honor companies that have demonstrated innovation, advancing the state of software development. The categories for 2017 included:

  • ALM and Development Tools
  • APIs, Libraries and Frameworks
  • Big Data and Business Intelligence
  • Database and Database Management
  • DevOps*
  • Influencers
  • IT Ops
  • Security & Performance
  • Testing
  • The Cloud
  • User Experience

* CloudBees was included in the category of DevOps

We are honored to be recognized beside our fellow industry influencers, disruptors and unicorns. This industry only ever speeds up. We are along for the ride - and building the engine for it. Stay tuned for much more to come from CloudBees. You can count on it.

Andre Pino
Vice President of Marketing


Blog Categories: Company News
Categories: Companies

Now on DevOps Radio: Three's Company - Special Jenkins World Edition

Wed, 06/21/2017 - 03:48

The countdown to Jenkins World 2017 is officially on! Host Andre Pino sits down with not one, not two, but three Jenkins World keynote speakers in Episode 20 of DevOps Radio. Kohsuke Kawaguchi, Jenkins founder and CTO at CloudBees; Jez Humble, co-author of Continuous Delivery, Lean Enterprise, and The DevOps Handbook; and CloudBees’ own CEO, Sacha Labourey, talk about recent developments in the industry and share a sneak peak at what attendees will hear August 28th - 31st at Jenkins World 2017.

Kohsuke starts the conversation by discussing what’s been going on in the Jenkins community over the last year. He touches on key projects, such as Blue Ocean and the Declarative Pipeline. Both new offerings make it easy for users of all skill levels to automate software pipelines. Kohsuke also talks about the community responses to these recent developments. At Jenkins World, he says the community can expect to hear how the ongoing evolution of Jenkins has led to new and better methods of software delivery.

Jez talks about his active role in the DevOps community and the recent advances he’s seen as DevOps starts to become more mainstream. He says that while everyone wants a piece of DevOps, the picture for implementation is still patchy. With the research Jez has done in relation to DevOps and continuous delivery, he’s seen the science on what works and what doesn’t in IT environments. In his first time speaking in front of the Jenkins community, he plans to talk about the huge impact continuous integration and continuous delivery have had on IT performance and how teams can measure this.

Finally, Sacha discusses what he’s seen in the Jenkins and DevOps market recently. He says it’s now understood that enterprises need to move to DevOps, but the question that remains is how to deploy at scale and make an enterprise-wide commitment. In order to adopt DevOps effectively, Sacha thinks you need the energy and willingness to share and learn. Sacha hints that Jenkins World attendees can expect to hear about new features and services from CloudBees, in addition to how people are accelerating DevOps adoption in their organizations.

Make sure you don’t miss the code Andre offers during the podcast for a special 20% discount off Jenkins World registration – including workshops and training, as well as the conference sessions!

Another thing you won’t want to miss? New episodes of DevOps Radio! Subscribe to DevOps Radio via iTunes or RSS feed and let us know what you think by tweeting @CloudBees and using #DevOpsRadio.

Categories: Companies

Win a Free Pass to Jenkins World 2017!

Wed, 06/14/2017 - 17:54

How would YOU like to attend Jenkins World 2017 for free*?

Jenkins World 2017 will be THE event of the year for all things DevOps, continuous delivery and Jenkins. Jenkins World is the largest gathering of Jenkins® users in the world, including Jenkins experts, continuous delivery thought leaders and companies offering complementary technologies for Jenkins. With keynotes from Kohsuke Kawaguchi, Sacha Labourey and Jez Humble - with 60+ sessions - with all of the learning and networking about the technologies you care about - this is not an event to be missed.

Four (4) lucky winners from all over the world will get the chance to attend Jenkins World 2017 in San Francisco, CA! Simply enter your information for one entry, and then unlock additional ways to enter the contest. The more entries you have, the more chances you have to win! There will be one (1) winner from each of the following regions:

  • North America
  • South America
  • Europe, Middle East, Africa
  • Asia Pacific

This contest closes on JUNE 30, 2017 so enter now!

Learn, network, explore and shape the future of Jenkins - for free! Good luck - We will see YOU at Jenkins World.

Win a Free Pass to Jenkins World 2017!

*Pass does not include add-on training/workshops or travel expenses. Blog Categories: Jenkins
Categories: Companies

Jenkins World 2017: International Program

Tue, 06/13/2017 - 15:31

Jenkins World is the largest gathering of Jenkins® users in the world, including Jenkins experts, continuous delivery thought leaders and companies offering complementary technologies for Jenkins. So, to ensure our International crowd doesn’t get left behind we have composed a dedicated program for all attendees traveling to Jenkins World from outside the United States. The program gives access to everything that a full conference registration includes (keynotes, breakout sessions, expo access and meals) along with these additional events:

  • Tuesday, August 29 (Morning) - Optional: Training and Certification All Day
    • Get access to pre-conference training at Jenkins World 2017 (additional charge) and take advantage of a FREE certification exam (no charge) with your registration for the conference.
  • Tuesday, August 29 (Evening) - Jenkins World Kickoff 7:30pm PDT
    • The Jenkins World kickoff event for International Program attendees at the Autodesk Gallery
 will be hosted by Kohsuke Kawaguchi. Join us for a night of dinner, drinks, a DJ and networking with other international attendees, Jenkins contributors and CloudBees management. RSVP by August 15 here to secure your spot!
  • Thursday, August 31 - International Program Private Lunch 12:30pm-1:30pm PDT
    • Join us for an International Program private lunch hosted by Kohsuke Kawaguchi. This lunch will be conducted as a Birds of a Feather lunch with CloudBees and Jenkins community leaders from across the world.

The only criteria for this dedicated program is to be from outside of the US.

To register simply visit the International Program website.

We look forward to seeing you there!

Blog Categories: Jenkins
Categories: Companies

Now on DevOps Radio: Perficient’s Ronda Kiser-Oakes on Hitting a Homerun with DevOps

Tue, 06/06/2017 - 16:45

Episode 19 of DevOps Radio features Ronda Kiser-Oakes, director of the North America DevOps practice at Perficient, a digital transformation consulting firm serving leading companies. Besides being an avid sports fan, Ronda is passionate about the business of IT and how DevOps is changing the way businesses innovate. Unlike her beloved Cubs, Ronda says companies don’t have to wait 108 years to see DevOps success.

While sitting down with host Andre Pino, Ronda shares her industry observations, saying that while many companies that have started their DevOps journey, most do not know what route to take. She notes this is a “MapQuest” scenario where companies know they have to get from point A to point B, but there are too many different routes and they want to ensure they reach milestones along the way. Ronda’s approach is to assess the situation and bring vision to tactical strategy by identifying where to start, how to get to the next point and which endpoint to get to first. Many of the processes like continuous integration, continuous delivery, continuous deployment, shift left and agile that organizations look to employ, are really the endpoint to their DevOps initiatives.

Ronda also outlines the three elements every DevOps game plan should include: people, process and technology. With the DevOps journey now spanning so much of the organization - through DevSecOps, security, QA testing and operations - and different roles within the company investing in it, it’s important to keep the people aspect in mind. At Perficient, to get all parties aligned, they outline five ways to deliver services, which Ronda shares.

Like a true champion, Ronda fields Andre’s question about DevOps politics by saying that anytime you are changing the world in IT, there’s going to be politics but it is important to understand the culture and adjust to it, to stay neutral. She then compares DevOps and sports, highlighting the competitive edge in both. Ronda says while we all want to get to the Super Bowl and the World Series - or seamlessly deliver a successful product - there’s always competitiveness and naysayers, but by continuing to work hard, we can see how we can do better to stay true to the team. Her coaching advice for the ultimate DevOps dream team is to put the customer first and everybody wins.

Want more MVP DevOps advice? Swing on over to the CloudBees website, search us on iTunes or subscribe to DevOps Radio via RSS feed. Extra game points if you Tweet @CloudBees and include #DevOpsRadio in your post!

Categories: Companies

What is Customer Success at CloudBees?

Thu, 05/18/2017 - 18:59

In an endless effort to provide the best customer experience for all subscribers, consistently and effectively, what does Customer Success imply for myself at CloudBees? The practical answer is to reduce churn, grow recurring revenue and increase product adoption. How does this become reality, though? There’s no magical “button of success” to achieve these goals and it certainly doesn’t happen overnight. From the start, I need to understand what matters most to my customers from their point of view to build a relationship with integrity and credibility. Only then can I provide trustworthy and reliable advice while working alongside the customer to meet their goals. I always want to add value in some facet with each interaction, even if it’s a quick email.

At the end of the day it’s about improving the software delivery cycle as a whole. At CloudBees we utilize a customer-centric engagement model to drive value, and in turn, we seek to establish a regular meeting cadence with customers. This allows me to create a customer journey/roadmap that includes specific goals and timelines. I want to know what is going to make you, as the customer, successful and help create a path to success that includes a sense of accountability.

Customer Success is an emerging market, but it’s permeating throughout all sectors of business. It’s becoming even more important for enterprises to adopt a customer engagement model conducive to positive, regular conversations. Implementing change into an organization is a daunting task, specifically for larger entities, but it is become more evident that an effective CS model executed 100% of the time produces positive results.

Lastly, I’ll speak briefly to the factors I believe to be most influential in qualifying customer success.

Trust. Trust is imperative to establish credibility and a positive, professional rapport. You cannot have mutual respect without trust!

Advocate for the customer. I’m not referring to advocacy in the sense that “the customer is always right.” I’m referring to advocacy in a sense of truly understanding your customer’s needs, wants and timelines to achieve their goals. Having this understanding gives CSMs the ability to advocate for the customer on a truly individual level and work together to make sure that the customer is never wrong. When there’s mutual respect and transparency, we’re in the journey to success together.

Know your product well. Do you have to become extremely technical? No. Will it benefit those of us working in customer success to become more technical and understand the product better? Yes.

Hire the right people. Teamwork really does make the dream work. 

Don’t be afraid to fail.  Fail fast. I’m not afraid to fail because I learn from my mistakes. The internal support surrounding this methodology makes it effective and enables continuous growth - personally and professionally.

Parker Ennis
Customer Success Manager
CloudBees, Inc.







Blog Categories: Jenkins
Categories: Companies

Meet the Bees: Amanda DeLuise

Thu, 05/11/2017 - 21:51

In every Meet the Bees blog post, you’ll learn more about a different CloudBees Bee. Let’s meet Amanda!​

Who are you? What is your role at CloudBees?

I’m Amanda DeLuise and I’m a Customer Success Manager here at CloudBees. I’m primarily responsible for managing our customer’s success! And less literally, CSMs are communication experts and project managers. We coordinate CloudBees resources to ensure our customers are meeting their business and technical goals. Whether it’s escalating a support ticket, contacting the Account Executive about purchasing extra entitlements, or setting up a customer with a Professional Services engagement, our goal is to maximize the value of the customer’s subscription.

In addition to my CSM duties, I’ve also taken to planning and running Jenkins Area Meetups (JAMs) around the Triangle (Raleigh, Durham, Chapel Hill).

When I’m not at work, I keep pretty busy. I work with a few local social justice organizations on the evenings and on weekends, and recently joined a comedy writing workshop. I’m sure my coworkers can attest to my hilarity (just kidding, I’m pretty quiet and I’m sure most people have never heard me speak aloud). I also have two cats (Lemon and Basil), so taking pictures of them takes up a decent chunk of my free time.

What does a typical day look like for you? What are CloudBees customers like?

A typical day starts with coffee. We have a lot of coffee connoisseurs in the Raleigh office, so someone is always grinding fresh beans and brewing something delicious. It’s honestly the best office coffee I’ve ever had.

When decently caffeinated, I go through my emails. I have meticulously filtered and color coded labels so it’s easy for me to determine what needs my immediate attention each morning. I start with direct emails from customers, move onto tickets that need my feedback, check to see if I have any meeting invites for the day. If it’s a relatively slow call day, I reach out to customers to see if we can get something on the calendar for a check-in call. It’s important to stay on top of the goals my customers have for each quarter, how close they are to achieving them, and how we can help them.

Lastly, I’m most likely always creating or updating a spreadsheet at some point in the day. Staying organized is super important when you’re handling 30+ unique accounts. I want to make sure I always know what my customers are doing, what they’re thinking about doing, and what features or plugins are important to them.

Do you have any advice for someone starting a career in the CI/CD/DevOps/Jenkins space?

Be patient! There are literally thousands of ways to use Jenkins, and learning about CI/CD was a bit like drinking out of a fire hose when I first started. But a little patience and a lot of Knowledgebase articles go a long way. And when you do make a mistake (which will be inevitable), look for the lessons in it.

Similarly, ask a lot of questions. Not only are people willing to help, but I’ve found they love talking about projects they’re working on or tips and tricks. It’s much easier to digest all of the information when you add a human element to it. Jenkins is more than just code running on a server somewhere out in the ocean, Jenkins is a community.

What has been the best thing you have worked on since joining CloudBees?

It’s been awesome getting to work with the marketing team organizing the JAMs. As you may have guessed from my mention of meticulously filtered labels and spreadsheets, I love organizing. I’m also a people person, so it’s been wonderful meeting local Jenkins users and customers face-to-face instead of over the phone or through email.

What is your favorite form of social media and why?

Vine (RIP)! I could watch Vine compilations for hours. It’s a mark of comedic genius to be able to make people laugh in a 6 second video.

Favorite TV show character - why is this character your favorite?

It’s a tie between Olivia Benson from Law and Order: Special Victims Unit, Annalise Keating from How to Get Away with Murder, and Linda Belcher from Bob’s Burgers. I have a thing for well-written, multi-dimensional women characters! 


Blog Categories: Jenkins
Categories: Companies

Now on DevOps Radio: Patrick Debois, CTO of Small Town Heroes and the Father of DevOps

Tue, 05/09/2017 - 02:24

The latest episode of DevOps Radio features the father of DevOps, Patrick Debois. Patrick shares with host Andre Pino how his vision for the unification of IT teams through the DevOps Days events has seen exponential growth and impact, cementing his legacy worldwide as the founder of this cultural IT phenomenon.

As an early DevOps expert, thought leader and advocate, Patrick takes us through his experience leading up to the conception of DevOps Days in 2009 and subsequent coining of the term DevOps. After working with agile development processes, Patrick realized the people working with IT infrastructure wanted to be just as fast. He decided the two teams - development and operations - should work together, thus playing matchmaker to IT’s perfect couple.

While DevOps Days are all organized and managed locally, the meetings have been extremely successful and well-attended, leading to expansion worldwide. Adding “globetrotter” to his list of accomplishments, Patrick also describes the differences in DevOps based on geographic regions. He notes some mindset differences, like how the United States has more of a startup mentality that’s resulted from the innovation in areas like Silicon Valley and, in comparison, Europeans tend to be more reserved when it comes to adopting something new, such as DevOps.

Despite regional differences, Patrick has witnessed how DevOps Days has added value to development teams globally. DevOps Days allow attendees to gather together and learn how to foster better software delivery processes through discussions about their experiences. DevOps as a whole has energized software teams by going beyond just changing their duties, to changing the way developers and IT operations think about their roles.

Predicting the future could be Patrick’s next calling as he also plays fortune teller and digs out his crystal ball to share his thoughts on where the industry is going. While he mentions that people may say DevOps is not new and shiny anymore, it is here to stay and is paving the way for more advancement in software delivery. Host Andre Pino also reminds us DevOps is not just a product you buy and implement, but an entire culture organizations must adopt.

For more of Patrick’s insights, head over to the CloudBees website, look us up on iTunes or subscribe to DevOps Radio via RSS feed. Thoughts, questions, feedback? Tweet us @CloudBees and include #DevOpsRadio in your post.

Categories: Companies

Jenkins with Support for Continuous Delivery with Peace of Mind

Wed, 05/03/2017 - 14:49

Are you searching for the fastest and easiest way to get started with using Jenkins as your continuous delivery platform? Jenkins is the #1 continuous delivery platform in the market because it connects with nearly every tool used by DevOps teams. With millions of users, a new plugin or integration is introduced every 2-3 days. This pace of innovation can help your team automate every application delivery pipeline task - that’s just downright awesome!

With more than 1,300 plugins, choosing which plugins will work for your particular need is a time consuming project in and of itself. In some cases, there are multiple integrations with similar functionality and/or dependencies with other plugins.

Without some serious research, your team may face the risk of delivery delays and outages due to instabilities caused by incompatible plugins and regressions. How can you take advantage of all the great innovations from the open source community if Jenkins is unstable after the upgrade? And who do you go to when something goes wrong? Safeguarding against these risks by identifying stable releases, suitable plugins and proven best practices takes away from doing what your team does best - delivering quality software faster.

This is why we are excited to announce - CloudBees Jenkins Team. With this continuous delivery solution, CloudBees curates an expanding set of plugins and ensures that they and the Jenkins core are enterprise-grade and play well together for trouble-free upgrades. By doing so, CloudBees minimizes business risks and eliminates downtime.This solution is backed by Jenkins technical expertise, available 24/7 through support, training and knowledge resources. This is the Jenkins you love with the support and guidance you need!

Supported Jenkins | Jenkins with Support

CloudBees Jenkins Team has three major components: a rock-solid CloudBees Jenkins distribution, CloudBees Assurance Program and 24/7 expert technical support. The monthly Jenkins distribution consists of the top open source plugins and a recent Jenkins core, verified to ensure stability, eliminating the fear of crashes. Upgrades are easy with the one-click upgrade feature, which makes upgrading… surprisingly boring for a change. You get the latest innovations in Jenkins without stability or upgradeability concerns.

CloudBees Assurance Program (CAP) is the “engine under the hood” of CloudBees Jenkins Team. This is a rigorous vetting process, staffed by 30+ engineers, conducting hundreds of hours of testing on the Jenkins core and open source plugins. Every month, this team delivers a growing list of verified integrations and a recommended configuration. The benefit is that you can avoid being overwhelmed by thousands of plugins to choose from by choosing only those that you need to work reliably with your favorite DevOps tools.

Our legendary support organization rounds out the solution by providing you with direct access to Jenkins technical experts and a wealth of resources. Get the help you need, anytime of day and in any time zone. In addition to engineer-to-engineer support, we ensure your success with a named Customer Success Manager, who can help get your team onboarded and make sure you get the most from your subscription. Support includes free self-paced Jenkins training, which can help drive adoption of CD within your organization. And you can always get your questions answered through CloudBees Network, an online portal to engage with users, find best practices and documentation.

We invite you to get started with a free 14-day trial license for CloudBees Jenkins Team. Get the best of both worlds, all the innovation of Jenkins and stable, reliable releases that let you tap into the vast Jenkins ecosystem. Finally…continuous delivery with peace of mind.



Blog Categories: Company NewsJenkins
Categories: Companies