devopsy.kinsta.cloud

Category: Doin’ DevOps

Evolution Not Revolution – DevOps in the Wild
Ever heard these questions:
- What is DevOps?
- How do I hire a DevOps Engineer?
- Should we have a Director of DevOps?
- Am I doing DevOps?
- Why is DevOps failing in my organization?
More and more frequently, I run into engineers, managers and business leaders describing failures in their organization due to “DevOps.”

Oddly, digging a little deeper, I find that most of these cases are simply failure by substitution. The Operations team was failing, so they rebranded it DevOps. Alas, buzzword compliance was unable to change the trajectory of the team and the buzzword was blamed.

DevOps today is–still–an ill-defined set of practices closely associated with automation and operations. If you accept this as fact, then DevOps can neither fail or succeed. If we want to measure the success of the DevOps movement in an organization, then we need a definition that leads to accountability.

A Definition for DevOps

The DevOps movement, unlike Agile, lacks a manifesto. To fill that gap, I assert that DevOps is a philosophy and that its base definition is:

DevOps is the way in which a technology organization embeds itself in a business to the benefit of that business.

The business in question need not be a technology company such at Docker or IBM. Indeed, all companies today are technology companies whether they like it or not. (1)

In this and future articles I will write about philosophy, models and implementation. In short, a philosophy is what I reason from to create models of behavior. Models inform the actions taken in an implementation. Implementation without philosophy leads to failure. Jingoistic adherence to philosophy without accounting for new technology leads to failure. Balance must be acheived.

As an example of this sort of failure, take a lesson from project management. Many shops adopt Jira because it can do anything. Since the tool can do anything, that means their workflow is capable of anything! Problem solved, QED. We all know tools are not process. When we look at our own track records of instituting change. too often the change stemmed from tool choice, not critical thinking about what was to be accomplished.

Tools should reflect the philosophy they are implemented to support. Without that philosophy tools will fail. The more complex the problem or tool, the more spectacular the failure. In this example, Jira did not fail, leadership failed. Specifically the thought leaders entrusted with workflow management.

Are you Doing IT DevOps Style

DevOps is about evolution. If you are doing IT DevOps style, then you are asking questions like:
- What should we change next?
- How do we create a sandbox to measure the impact of the change?
- How do we create demand for the change once vetted?
- Who do we need to be patient zero?
- What cultural paradigms are we shifting and how do we ease this for teams?
While automate-all-the-things is often associated with the term DevOps, automation without cultural shift will result in broader failure, rather than success. Like any technology problem, at its core DevOps models account for their impact on people because businesses are composed primarily of people.

Future Articles

Over the course of the next few months. I will relate my experiences at several companies. Articles will describe:
- What we changed.
- Why we changed what we did.
- What cultural issues we faced.
- What technologies we used and why.
I hope you will join me to learn how the practice of DevOps as a philosophy can lead to millions of dollars on the bottom line, happy bosses, fluffy bunnies and rainbows. If your lucky, you might even become a unicorn, though my own horn has yet to sprout.

The first case study will describe a failing company with three months capital. An amazing team. Some amazing mistakes and, ultimately, some amazing success. Technology decisions driven by the needs of a sales team. Automation driven by a business model. A successful acquisition.

References

(1) The Phoenix Project – Gene Kim, Kevin Behr, George Spafford
(2) Good to Great – Jim Collins

About the Author/Boyd E Hemphill

Boyd E Hemphill is Director of Evangelism at StackEngine (link). , an enterprise grade, Docker operations management software company. DevOps raconteur and organizer of community events in Austin, find him on Twitter or LinkedIn.
February 4, 2015
The Business Value in Software Quality

Software is taking over the world. You would be hard pressed today to find a company without dedicated software development efforts. But even in traditional business models, this is not confined to line-of-business applications. Organizations now have public, contractor and field team applications—as well as end users. And they must consider the results-focused future of software development and the need for faster, higher quality application releases. This is the business value of software quality.

(more…)

January 29, 2015
Metrics for DevOps

Your organization is now committed to DevOps methodology. You’ve integrated development, operations, and QA, and you have moved drastically away from waterfall and into a fire hose of application development. How do you find out how well it works? How do you know if it’s working at all? Many net new DevOps organizations are surprised to find that it was easier to start then they thought, but hard to keep alive. This can be because of menacing habits, or just because the team is too far into the weeds. In a word, you need metrics

(more…)

January 26, 2015
There is No ‘I’ in Team: Transitioning Engineering Teams into a DevOps Model

As the pace of development and business continues to scale, teams need an agile and collaborative work environment to succeed. Moving to a DevOps model is a critical part of setting your engineering teams up to succeed, but making the transition can be challenging for many companies.

What’s the deal? – Why you need a DevOps model

DevOps is a movement in the software world that focuses on collaboration between developers and operations, customer empathy and infrastructure automation. In traditional models, developers write code and then hand it to operations teams to deploy and and run in a production environment. This often leads to a lack of ownership between the two teams (“It worked on my local box!”) as well as a slower pace of development. In a DevOps model, by contrast, the two teams work closely with each other, and toward common, customer-facing goals – developers take ownership of their code even while it’s in production, and operations teams build tooling and processes that help developers write, test and ship code faster and more easily.

By breaking through traditional developer-operations walls, development happens faster and with more customer empathy, ultimately resulting in a better customer experience and a happier team. Rather than seeing the other team as a gate or obstacle, if done right, developers and operations see each other as teammates working to deliver value to the customer and business.

Unfortunately, introducing DevOps culture and practices to your company isn’t easy. Big changes to long-entrenched silos can generate resistance, and business leaders are often scared of the costs that come with change. To combat these concerns and hesitations, we’ve highlighted a few tips for transitioning to a DevOps model.

Start with Collaboration – what’s working and what’s not?

At the heart of DevOps is improved collaboration between your Operations and Development teams. You’re probably not starting from a vacuum, though – look at and talk about the best examples of how your operations and software development teams are collaborating today. Are there particular dev/ops groups that are already working tightly together, championing great communication or doing joint planning? Focusing on what is already working and how to make it work better, rather than what’s broken, keeps things positive and more likely to succeed.

You could set up a group brainstorming session to discuss, or have one-on-one conversations with individual team members, depending on the format that you think will help people open up more easily. This article highlights opportunities for collaboration across the application delivery lifecycle, and could provide a useful framework for asking questions and identifying opportunities.

In addition to the state of collaboration, you’ll also want to look for process successes and breakdowns in how you deploy and maintain applications, services and infrastructure. Identify the biggest opportunities for improvement – do your builds and test take hours? Are your 20 development teams all competing for the same three staging environments? Being able to quantify the impact of these pain points can help defend the transition to business stakeholders who may not have as much on-the-ground context about your teams’ pain points.

It’s also important to build an understanding of the different perspectives operations and development teams may have. If your organization has traditionally been very siloed, thinking about other teams’ goals when planning and prioritizing may be a new mindset. Sharing each team’s objectives and what success looks like for them can help build this understanding and empathy. Focus on transparency (a framework like OKRs can help) to avoid conflict from mismatched assumptions about priorities.

Create a plan

Once you’ve identified opportunities to improve the collaboration and workflow between developers and operations, it’s time to create a specific plan. Pick key opportunities and identify the first few steps to make a difference. Courtney Nash recommends starting with a group of people who are receptive to the vision and picking a small product or service as a test-bed. When implementing big changes, it helps to start small and scale from there after proving success.

Engineers are not always known for their people skills, but transitioning to DevOps is as much about people as it is about process and tools. Throughout this whole process, you’ll want to be investing key stakeholders in your team and company in the transition. Change management sounds awfully corporate, but at it’s heart, it’s about making sure you build support for your projects and goals by collecting input from key stakeholders: gathering their feedback and goals, sharing and re-shaping your plan based on their input, and communicating your progress with them. It’s always easier to work in silos with people that already agree with you, but for lasting change, you’ll need to invest in building support across teams and throughout your organization.

Finally, pick realistic timelines and objectives. It’s important to note that some effects of the change may take longer to realize as people ramp up on new tools and ways of working. Don’t discount or neglect the amount of time required for training, and try not to be fazed if the first project you pick doesn’t turn out to be a good one. As Courtney Nash mentions, Nordstrom.com realized their first project was not ultimately the right one to start with. Importantly, they didn’t give up, instead choosing a different, better-suited application.

Measure and reflect

While it’s rare for timelines in complex systems to happen exactly as planned, it’s important to timebox your work so that you can measure and reflect on how it went.

After the specific milestone you’ve chosen, bring stakeholders together and run a retrospective. There are a lot of great resources out there to help with good retrospectives, but regardless of approach, make sure you make an intentional space to look critically at your results, celebrate success, and think about how you’d like to change or iterate the process for the future.

When reflecting on progress, it’s important to be candid and honest while assuming the best intentions of your teammates. You are guaranteed to make mistakes – that’s inevitable with any new process – but remember (and help others remember) that you’re all working toward the same purpose and share a common set of values and goals.

Don’t give up

Adopting DevOps is a big change for an organization, and there will be bumps along the road. At the end of the day, though, the rewards of tighter collaboration among teams and a more empathy-driven engineering culture can be really powerful, and will show in product quality, velocity and team morale.

January 21, 2015
15 must have Jenkins plugins to increase productivity
Jenkins is a vastly used continuous integration tool for the IT industry which is built and used around plugins. It’s core is the Jenkins tool and there are 100’s of plugins available to enhance its power and usability.

Let’s take a look at a few of the best plugins to increase the productivity.
1. Global Build Stats Plugin–It’s essential to know your current capacity, usage and capability to prepare for capacity planning or system requirements, because the very first question is “what is your current capacity?”
You need to know how many builds are happening on a daily and weekly basis. How much time is taken by various builds, what is the waiting period. This plugin give you enough data to answer the question. This plugin can provide you data as graph which can be further consumed.
1. Job GeneratorPlugin–In big or growing organizations, its a bit difficult to maintain the jobs for a project when developers are working on various branches and releases. You want to give access to developers to create their own job and at the same time you don’t want developers to create arbitrary jobs which may not fall under company standards. This plugin gives you flexibility to define templates and developers can create new jobs with the help of job generator template. Configuration access can be disabled via roll-based authorization plugin.
2. Disable-failed-job –In rapid development environments failing jobs due to various unnecessary reasons are a pain, It’s difficult to keep track of such jobs and disable/delete them. This plugin can solve the problem by defining the upper number of consecutive failed builds and then disable automatically.
3. Embeddable-build-status –This plugin can give you a link which can be pasted anywhere (example github project) to expose the status of the build and users can get the current state of the job while looking at project.
4. Exclusion –This plugin enables you to handle conflicts between jobs. You can assign a resource (or lock) in multiple jobs, when build is executed, it will acquire the lock and other builds (if fired) will wait until lock is released.
5. GitHub/GitLab Pull Request Builder-This is one of the best plugins I found to provide support to automate code review up to a certain extent in github/gitlab. This plugin does amazing job once defined for the project. For any new pull request this plugin does fox merge and runs the build on the code as well as gathers the necessary static analysis (if configured) or build results and comment back the status to pull request. This helps reviewers get an idea of the health of the code which is going to be merged. You can even define automatic merge if build passes.
6. Hudson Extended Read Permission Plugin- During initial days of Jenkins setting configuration access was not available to any developer to make sure they do not change anything but developers used to ask to view configurations to know how job has been setup, they may want to see the build steps. Extended read plugin can provide option to developer to view the configuration without giving them write access.
7. Post+build+task –There may be a need for performing some actions on the basis of the results of a build, for example if build passed you may want to upload artifact(ex debian) to some repo (apt) or perform some packaging part or similar. In case of failure you may want to roll back something (like release) . This plugin helps you to define the pass/fail criteria and let’s you decide what to do after that.
8. JDK Parameter Plugin–This plugin is useful for an organization where many projects are using different versions of java. This plugin let’s you choose the java version during run time of the build.
9. Job Configuration History Plugin-Ah! This is one of my favorite plugins. This plugin lets you keep track of config changes in each build including who did it. You can easily revert back to any previous config if you want.
10. Multiple SCMs plugin–Default SCM section provides only one source control tool/URL option, what if you want to check out from more than 2 repos from multiple source control tools (like svn and git). This plugin will come in handy in such scenarios. This plugin will facilitate users to add any number of SCM URLs to checkout the code.
11. Parameterized Trigger plugin– Another one of my favorite plugins. This plugin allows you to have user input as a variable and use on run time. This is the most used plugin in dynamic environments where you have lots of options and user-defined values to be used in the build which may keep changing.
12. Pre SCM BuildStep Plugin- Just like post build task plugin, you may have requirements to perform some action even before checkout happens for the job, for example you may want to perform merging of the branch before the build and then checkout. This plugin can come in handy in various conditions and gives you flexibility when running the job.
13. SCM Sync Configuration Plugin-backup, this is the most important task of any administrator. Without regular backup, the whole system cannot be reliable; this plugin provides you features to backup live Jenkins configs to any source control tool. It will keep committing the config files (including Jenkins and jobs) to SCM repository as soon as there is any change.
14. Configuration Slicing Plugin – This plugin comes in very handy when you want to make bulk changes in multiple jobs. This plugins allows you to change values of various fields like email, timer, shell script, configurations etc at one go.
These are my favorites, but like I wrote, there are 100’s of plugins for Jenkins available. What are some of your favorites?
January 15, 2015
7 Tips for testing the usability of mobile apps
Of the one million mobile apps, only half are used more than 5 times

If you study any random cross-section of successful mobile apps and games you’ll find that they have one common factor. All of them are accessible. They have user interfaces that people can navigate intuitively without instruction. This is partly about building on expectations and established norms with Android, iOS, or whatever platform you are developing on. But there’s no substitute for thorough usability testing.

According to Localytics, 20% of apps are used once and never opened again. Only 50% of apps are used more than five times. The window for app developers to impress and hook the user slams shut quickly and it stays shut. First impressions are vital if you want to boost retention rates and stand out in a crowd of over a million apps.

It can be difficult and expensive to extract actionable data from usability tests. Here are a few practical tips for successful usability testing:
1. Create a mock up – Starting with user-centric design is a smart move that will pay dividends down the line. You can save yourself a lot of time and money by discovering weaknesses and potential problems before the development really begins. There’s no reason you can’t mock up your user interface with simple screenshots and then frame it in an actual size smartphone surround. You can even do this with card and paper if need be. That way you can find out how potential users expect to interact with your app and identify the tasks that are most important to them. It’s a lot easier and cheaper to change your design on paper than it is to rewrite code.
1. Examine how people interact – This applies to every usability test you conduct, whether it’s a paper mockup, a prototype, or the functional app on a smartphone. If you’re doing it in person then provide minimal guidance, ideally none at all, so you can uncover genuine failure points. Make sure to take plenty of notes. It’s not enough to just record what’s happening onscreen, you need to observe what people are doing with their hands, and see their facial expressions and body language. Are they trying the wrong gestures? Are they getting frustrated? Is it working the way they expect? Close observation will deliver the best insights.
1. Test in the real world – If you can conduct tests in real world conditions in public then you might uncover some pertinent details about the usability of your app that you would miss in a controlled environment. This means conducting tests in real environments, whether it’s a busy shopping mall or a person’s home. It can be a good idea to avoid giving any instruction, that way you can see just how intuitive the design really is. There are services that offer video footage and audio narration of testers from around the world in different demographics using your app in real world conditions. Without the official framing of a test situation you have relaxed users and this can deliver different insights. Sometimes it might be more indicative of real world conditions to have someone test in their own home.
1. Keep it short and simple – The longer a test is, or the more complicated it gets, the less likely it is your users will stay focused and interested. If they have to think too much about the parameters of the test and what you’re asking them to do then they’re less representative of an end user. This is particularly important when you’re asking members of the public to test in return for a small reward or for free.
1. Vary platforms and devices – Try to let people use their own devices wherever possible. That way the device won’t be a distraction and you’ll get data about different devices. The more variations you can cover, the more useful data you can gather. If you’re releasing on more than one platform then make sure you cover each one. You’ll need to cater for differences in expectations about standard platform navigation.
1. Ask the right questions – Observation should be your primary source of data during usability tests, but you may want to ask some questions after each session. Be careful about what you ask and focus on getting actionable data. Asking if the app made them happy on a scale of one to ten isn’t going to tell you anything useful in a practical sense. You should also ask for elaboration, and where possible, have people show you what they mean using the app or prototype, rather than tell you, to avoid misconstruing any answers.
1. Assess and act – You need to aggregate the data you collect and create a plan to assess it. Make sure you draw meaningful conclusions that are backed up by a weight of data. Don’t let personal bias cloud this process. You should be acting on the things that will resonate with the most end users. Just because one vociferous tester shouts louder than the others doesn’t make their feedback more important. Take your time, get further feedback on specific areas if it’s needed, and create a plan of action that you’re confident will result in concrete improvements, then test them again to confirm.
There’s a lot of work involved in usability testing, but there’s no better way to improve the accessibility of your app and create a favorable first impression with the end user.

About the Author

Mush Honda is QA Director at KMS Technology, a provider of IT services across the software development lifecycle with offices in Atlanta and Vietnam. He was previously a tester at Ernst & Young, Nexidia, Colibrium Partners and Connecture. KMS services include application management, testing, support, professional services and staff augmentation.
January 8, 2015
DevOps answers to high availability

Everyone want’s their application SLA to be 99.99999%. However with some applications it is not a desire, it is mandatory. The Consequences of failure in mission critical applications are drastic. And with commercial applications damaging, it is reputation, and internal support costs.

(more…)

January 7, 2015
DevOps – what does “good” look like?
I’ve blogged a lot about my definition of DevOps and what it means to me.

I’ve always thought it much larger than “Dev” and “Ops” and that there isn’t really an end state – it’s an ever changing idea that will adapt to meet the needs of the business.

That said, I’m asked quite often what “good” looks like? How do you know you are on the right path?

For me DevOps is a primarily a cultural idea. If the culture is right then the technology and people will follow. I talk to a lot of people who see this word “DevOps” and reach out straight to technology. DevOps isn’t another word for automating Cloud servers…

In order to an effective “DevOps” organisation I think you need 4 main pillars:
1. Culture – does the culture of your company promote collaboration, self improvement etc?
2. Process – you need to have processes that support different silo’s working together to achieve a fast pace of change
3. People – if you don’t have the right people then it doesn’t matter how great your technology is. People and culture are very linked but I’ve tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
4. Technology – what are the building blocks you need to be a mature DevOps enterprise?
The following is very much my view of what “utopia” looks like. The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve. For example, you absolutely don’t need to use public Cloud to achieve DevOps. However, I do think it’s a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.

This is where I want my company to get to…

Culture
- Measure everything, always
- Individuals have empathy for the rest of the team (i.e. they don’t pass the buck)
- Shared goals and incentives
- Don’t reward the fire fighter, reward the fire preventer
- Reward innovation and challenging the status quo
- Don’t punish people when they try something new but fail
- There is no IT and “business”. IT as much “the business” as the sales people.
- Seeking to break down silo’s
- “It’s not my job” doesn’t exist
- “Its my server/code/network/database” doesn’t exist
- Individuals are empowered to make decisions
- Top-up management rather than top-down
People
- Restlessnes (relentlessly looking to improve themselves, others, processes etc)
- Good technical ability across a broad skill set (understand as much of other people’s jobs as possible)
- Everyone can code and use version control
- Everyone understands the test triangle
- Dev-test pairing
- Organised in small product focused teams rather than technology silo’s (align teams to the business not the technology)
- Common incentive schemes
- Favour automation and repeatability above anything else
- CIO/CTO are DevOps biggest guardians & SME’s and seek to destroy anything that affects that culture
- Natural face-to-face influencers rather than endless emailers
- Natural sharers of information
- Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)
Process
- Agile
- Continuous Integration
- Continuous Delivery
- Lean
- Fail-early, fail often
- Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
- All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
- Knowledge sharing and “just enough” documentation is part of the process
- Measuring success and failure is part of the process
- Retrospectives are part of the process
Technology
- TDD/BDD everything (including Puppet etc)
- Everything is in version control (code, automated tests, server config etc)
- Release automation tooling
- Convergent desired state tooling
- Cloud (private or public but the ability to spin servers up on demand)
- The same trending, monitoring & alerting solutions available through nonprod & prod
- Application Performance Management
- Service Virtualisation
- Continuous Integration
- Continuous Unit tests
- Continuous Service level tests
- Continuous GUI tests
- Performance testing
If you can get half way to delivering all of that then I think you should be in a very good place indeed.

It’s a long hard journey if you are a traditional Enterprise. Nothing worth achieving was ever easy though!

I’m outta here for what proved a fantastically successful 2014 (personally and work). 2015 is a massive year too for me but good luck in whatever you have planned ahead.

Happy New Year to you all!

J
xx
January 6, 2015
DevOps Resolutions For The New Year

As we welcome in the New Year, it’s natural for us to set both personal and professional goals. While many are adding the obligatory eat healthier, spend more time with family, and exercise more to their personal list, some of our client are adding DevOps resolutions to their professional goals.

During a recent customer roundtable discussion, we asked our clients what are their DevOps goals / resolutions for the New Year. Here are a few that stood out from the crowd.

“Focus on fewer problem areas (bottlenecks)”
-Ben S., VP, Major European Auto Manufacturer

This is my favorite. It’s counterintuitive but makes perfect sense. With a topic like DevOps, it can feel over whelming at times. It’s for easy organizations to create a litany of things to do. Many enterprises hesitate to invest in DevOps not because they don’t know where to start, but rather they have too many choices on where to start.
So this year, listen to Ben’s advice: pick the top 2- 3 areas that can make a positive impact to your organization. That may be continuous integration, or automated testing, or automated environment configuration. Whatever the area, just focus on a few areas, rally your team, and stick with it.
If you are struggling with what to pick, use time, pain, and / or cost as your prioritization criteria. Even if you get it wrong, the impact on one part of your Software Delivery Lifecycle (SDLC) will highlight the bottlenecks in other areas.

“Spend time talking to the people in trenches”
-Jay S., Senior Director, Leading HealthCare Provider

Jay hit the nail on the head. Too often we only focus on executive messaging and alignment. While that is important, talking to the people that are actually living this day in and day out is just as important. The insights you gain from them will be invaluable as you create your DevOps strategy and will go a long way when you try to get their buy in. Also, don’t just stick to the people within your silo. Talk to business, development, and operations – to get a holistic point of view
If you are going to start a DevOps cultural revolution, you might as well get both top down and grass roots support. It’s the own way it is going to work.

“Connect with others who have been there done that”
-Ann H., VP, Major Telecommunications Company

DevOps is a paradigm shift that challenges many of our long-held beliefs. It is a mind-set change and the only way to break the old way of thinking is to learn something new. So as the New Year unfolds, consider replicating Ann’s strategy: plan to connect with others who have been there and done that.
We are at a stage in the market where many organizations have jumped in with both feet into DevOps. Some have been successful and continue to invest, and others not so much. Talk to both, you can learn a lot on what to do / not to do.

“Stick To Your Guns”
– John B., Snr. Director, Leading Technology Firm

DevOps fails in an enterprise, not because of a flawed strategy, or mis matched tools, or even a bad process, but due to death by a thousand cuts. For example, breaking the continuous integration protocols and letting bad code pass through, increasing the batch size due to scope creep, not checking in code daily, and / or using non-standard pattern for deployment. Each cut, though small in nature, undermines the entire process. If done once in a while, it might be ok. But do it too often and you will literally see your DevOps investment vaporize into thin air.

So if you were to add just one resolution to the list, I would recommend you follow John and add “sticking to their guns”. Whatever process that you and your team have decided on, stick to it. The more you stick to it, the easier and more natural it will become. Do it often enough and you will be setting the right tone for yourself, your team, and towards DevOps success.

What are your resolutions for 2015?

About the Author

Mustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.

You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

January 5, 2015
Breaking Builds II – The Butler did it
As editor-in-chief here at devopsy.kinsta.cloud and writing for several other publications I see more than my share of contests, promotions and other marketing campaigns (not to mention pitches from PR agencies), but I came across one this week that I really wanted to share with you. My friends at CloudBees, the Jenkins company are once again running their Breaking Builds promotion. In case you don’t know about it, it combines two very different characters. The Butler from Jenkins and Walter White from Breaking Bad. As Sacha Labourey, CEO of CloudBees says in his blog post on the contest morphing these two together is “probably one of the best examples of cognitive dissonance you can get.”

The marketing and engineering teams at CloudBees have come up with a series of banners with graphics of the Butler as Breaking Bad characters, especially Water White. They then have come up with captions for the images that are spoofs of lines from Breaking Bad and also have a Continuous Delivery angle to them. You can see what they have come up with here. Your mission if you accept it is to take the graphics and come up with a better caption than the CloudBees team. You then tweet the image with your caption and you’re entered.

There are prizes for several categories of captions. The categories are
- Most Original Caption for any of the 10 #BreakingBuilds images + your caption
- Most Humorous Caption for any of the 10 #BreakingBuilds images + your caption
- Most ReTweeted Twitter post* for any of the 10 #BreakingBuilds images + your caption *Dare we call this CI (Continuous Interaction)? 😉
- Most Favorited Twitter post for any of the 10 #BreakingBuilds images + your caption
- We may also create additional categories during the contest if we see an emerging theme!
The categories, prizes and full rules are also available here.

Personally my favorites of the images and captions done by CloudBees are these two:

So if you are a Jenkins and/or a Breaking Bad fan why not join in the fun. Give it a try. We will also feature some of the winning banners here on devopsy.kinsta.cloud
December 18, 2014