You Must Be This High to Ride the Continuous Bandwagon

There’s a lot of hype when it comes to continuous deployment (CD). The fact is that in large organizations, adopting CD takes changes to process, responsibilities, and culture (both technical and management). The right skills really help, but more often the determining factor to success is having the right attitude and vision across the whole team.

continuous-delivery-vs-continuous-deployment-b371cf5be55b1c52635058af7b70188cd2b608bfb92ca5487a3e41694e9ccf6b (1)
(image via Yassal Sundman)

At a carnival, you may have seen a sign that says “you must be this tall to ride”, an indication that the attraction is designed in such a way that it is dangerous to ride for those who don’t meet the specification. Similarly, continuous deployment sets the bar of requirement high, and some teams or products aren’t set up to immediately fit into this new methodology.

Mobile Continuous Delivery Requires Micro-climates

Mobile apps go through a validation process in an app store or marketplace before being generally available to customers, so product feedback loops take a hit in delay to market response to the app update. Mobile apps typically rely on back-end infrastructure which may require synchronous roll out of both front-end app and server-side components such as APIs and database schema. This is not trivial and for apps with thousands to millions of users.

Because of this delay, there’s huge emphasis on getting mobile app changes right before submitting them for review. Internal and beta testing platforms like TestFlight for iOS and HockeyApp for Android become vital to a successful app roll out and update strategy. For organizations that are used to 3 month release cycles and who control their whole stack, being prepared to release perfection every week requires a completely different mentality, often a completely different team too.

This is what I call product ‘micro-climates’, an ecosystem of people, processes, tools, and work that evolves independent of the larger organization. Mobile and API teams are perfect examples. A product needs to go at it’s own pace, accelerate and improve based on its own target audience. Only when organizations align product teams to business goals does this really take hold and become effective.

Prove Your Success, Aim for a Shared Vision

I’ve never seen a Fortune 500 organically evolve to CD without buy-in from a C-level or at least VP. A single group can implement it, but will ultimately run into cultural challenges outside their group (like IT and infrastructure) unless they have the support of someone who controls both groups.

If you’re trying to move in that direction but are hitting barriers outside your team, you’ve may have bitten off too much for now, and need buy-in from above (i.e. an executive sponsor). For that, you need:

  • Proof that what you’re doing is actually improving your velocity
    ‘DevOps’ is a buzzword, but metrics that show how doing kanban/scrum with both teams in the room every day actually matters. If you aren’t already capturing these metrics, I’d suggest you start. The point is to have quantifiable, objective measures that undeniably show success.
  • How your success maps to your executive sponsor’s goals
    An executive often balances potential opportunities with opportunity costs. If you’re changing process, what’s the risk to your actual project? How can this be replicated to other teams? What’s at risk if you don’t do this? Why are other competitors doing it this way too? What strategic objectives does this change enable (i.e. faster releases == competitive advantage)? Take a few moments to think about what your sponsor is measured on, and map your goals to theirs.
  • A clear plan and schedule, not just a bunch of activity
    Adding one or two process improvements is one thing, that’s actually our responsibility anyway, but to move to a model like continuous delivery/deployment you need a plan that includes objectives, strategy, and then tactics. For instance:

    • Objective: meet demand for new features, obtain competitive advantage in market
    • Strategy: streamline the delivery process to achieve 1-2 week release cycles
    • Tactics:
      • Continuous integration of code, multiple commits per developer per day
      • Minimum 80% automated test coverage
      • Test coverage over 5 key platforms and 3 geographic markets
      • Automated security reviews before each release (i.e. like this)
      • Tractability of code changes to production user impact metrics

If you’ve been bitten by the CD bug, it’s more than just an itch to scratch. It takes some concerted effort, particularly in large organizations, but don’t let that hinder you. Get your own team on board, find your velocity metrics, link your proposal to executive goals, get that sponsor, and commit to an implementation plan. Others have done it, and so can you.

Dear Sauron, I will not be returning to Mordor

[originally written 4/22/2015]

Just to be clear, I’m not talking about J.R. Tolkien.

I have been to the Mountain. I have felt the Ashes on my brow. I have seen what a skilled Practitioner with a broken soul does to people around her. There’s a difference between assertive and asshole. There’s skilled and there’s skewed.

I can’t imagine what it’s like to be an immigrant. I mean, I’ve talked to my Russian grandmother (rest her soul) about Baba, her mother. I remember pictures of her and only understand very little about what it’s like to be an stranger to everyone around me. I have friends who went through this, but have never been one myself, except for the past 14 months of life.

I ignore homeless people every day when I go into the city. I disregard their need every time I don’t give them the change from my pocket. One time, I saw a Vietnam veteran with a cardboard sign asking for new glasses. The next day after hitting an ATM, I looked for him in on the way back in. I never found him. I should have overcome my ego problems and just eaten the $4 ATM fee right then and there, gone back, and walked with him to the nearest LensCrafters. Do you know how sad it feels to have hundreds of dollars of cash in your pocket for someone who you’ll never see again? You won’t if you can’t.

Remorse, empathy, kindness…these are character traits of someone I’m proud to be. Domination, cynicism, rudeness…they are transparent to people who care. After all this time, I still do; but broken is broken, and as much of an engineer as I am, some things can’t be fixed. Some things aren’t worth the effort.

Additional Reading:

Why responsive web developers must learn Selenium

Developers need fluency in technologies that the team uses for UI testing. Similarly, testing has become more a programmer’s job than a point-n-click task. As the world’s most widely-adopted web UI testing framework, Selenium is a must-know technology for responsive web development teams in order to maintain the pace of continuous delivery.

Mostly Working, Somewhat Broken ‘Builds’

I use the term ‘build’ loosely here when it comes to web apps, since it’s often more like packaging (particularly with Docker containers), but the idea is the same. You have code in a repo, that gets sucked in by your CI system, built/packaged), tested/validated, then deployed somewhere (temp stack or whatnot).

If the build succeeds but tests fail, you need to quickly assess if it’s the test’s fault or the new build. The only way to do that quickly is to maintain proficiency in technologies and practices used to validate the build.

Code in production is where money is made; broken code doesn’t make any money, it just makes people move on. Everyone is responsible for the result.

We have a QA person. That’s their job.

Not so fast. In continuous delivery teams, developers don’t have the luxury of leaving it to someone else. When build verification tests (BVT) fail, a developer needs to track down the source of the problem which typically means parsing the test failure logs, referring to the code and the context/data used for the test, then making some adjustment and re-running the tests.

Though your test engineer can fix the test, you still have to wait for a developer to fix problems in code. Why not make them the same person?

Of course I’m not suggesting that every developer write ALL their own UI/UX tests, there’s a division of labor and skills match decision here which each team needs to make for themselves. I also thing in larger teams it’s important to have separation of concern between those who create and those who validate.

Code in production is where money is made; broken code doesn’t make any money, it just makes people move on. Everyone is responsible for the result.

How can web developers find time for UI testing?

The answer is simple: do less. That’s right, prioritize work. Include a simple test or two in your estimation for a feature. Put another way, do more of the right things.

You may get push-back for this. Explain that you’re purposely improving your ability to turn things around faster and become more transparent about how long something really takes. Product owners and QA will get it.

Now that you have a sliver of breathing room, learn how to write a basic Selenium script over what you just created. Now you have a deliverable that can be included in CI, act as the basis for additional validation like load testing and production monitoring, and you look very good doing it.

You can do it!

Obviously, you can go to the main site, but a quick way for those with Node already installed is through WebDriver:

[full tutorial here]

For those who have never worked with Selenium before, start with this tutorial. Then go through the above.

Even if you aren’t a Node.js fan, it’s an easy to grasp the concepts. If you want to go the Java or C# route, there are plenty of tutorials on that too.

More reading:


What Can You Do Without an Office?

Meme == fun! Make one yourself! Tag #SummerOfSelenium

I rarely go to the beach. When I do, I like to do what I like to do: surprise, tech stuff. We all relax in different ways, no judgement here. We also all need to work flexibly, so I’m also busy with a new co-working space for my locals.

In back and forth with a colleague of mine, we started to talk about strange places where we find ourselves writing Selenium scripts. All sorts of weird things have been happening in mobile this summer, Pokemon Go (which I call pokenomics) for example, and Eran was busy creating a cross-platform test script for his upcoming webinar that tests their download and installation process.

At work, we’re doing this #SummerOfSelenium thing, and I thought that it would be cool to start a meme competition themed around summer-time automated testing from strange places. Fun times, or at least a distraction from the 7th circle of XPath hell that we’re still regularly subjected to via test frameworks.

If you want to build your own meme, use the following links…

940x450_phone-computer-on-beach a.baa-With-computer-on-the-beach businessman-surfboard-9452686

Reply to my tweet with your image and I’ll figure out a way to get our marketing team to send you some schwag. ;D

Mine was:


Then Eran responded with:


We think we’re funny at least.

Side-note: co-working spaces are really important. As higher-paid urban jobs overtake local employment in technical careers, we need to respond to the demand for work-life balance and encourage businesses to do the same. Co-working spaces create economic stickiness and foster creativity through social engagement. My thoughts + a local survey are here, in case you want to learn more. A research area of mine and one I’ll be speaking on in the next year.