Well, it worked in Development!

"It works on my development machine." When I began as a developer at a small, private internet banking company back in 2005, I heard this a lot. In fact, it became so popular, our QA had coffee mugs made with that saying on them. Obviously, it was a point of contention between our development and QA staffs. And over time, we used that saying to encourage developers to consider all the various environments and configurations their software would be required to run against. It made us better.

Despite all the advancements in automated and unit testing frameworks, CI/CD pipelines and cloud technology one of the biggest challenges in software development is validating the code we write works in various development, staging and production environments. As much as we try to ensure our infrastructure is the same across all of our development stacks, invariably we cannot duplicate the exact delivery environment, which includes countless configurations across many different customers. Sure, we've gotten a lot better at this since I was a developer back in the dark ages, but it's still an issue and sometimes creates very painful memories for us, our partners, and our customers. What I have discovered over the years is while we should use current technologies and best practices, it takes everyone in a development cycle to prevent embarrassing situations. It takes developers creating unit tests, QA executing complete regression suites and professional services and customers/partners validating their code against recent base releases. It takes all of us to ensure quality, rock-solid experiences for our end users.

At Q2, we take quality seriously and we are meticulous about code coverage in our SDK and API. We go to lengthy measures to ensure backwards compatibility and new feature reliability. We run unit tests to ensure every line of code is executed, and each code path returns an expected output given a set of mocked data. We set high standards for test code coverage, and this is enforced in a build pipeline to make sure all tests work outside the developer’s environment When a bug is discovered, before it is fixed, an analysis is done to figure out why the bug evaded the test suite, and a new test is written to make sure the bug is fixed and does not show up again. However, it requires help from our developer community to create seamless updates for our collective end users. That's why we are making a few changes to the delivery process for our API.

Starting in May, we will announce API updates to the staging environment by sending notification emails to the Newsletter distribution and also to anyone who has opted in to receive Caliper API notifications. The announcements will contain a list of the updates we made in the latest API version and will serve as a signal for you to validate your extensions and customizations against this new release. After one month, we will move the release into production, and you will receive a subsequent notification. During the one-month certification period, please raise a support ticket for any issues you find with that API release. Our first monthly release will drop on Tuesday, May 17th and that is when you will start receiving API release notifications. Sign up to receive those here.

We are always looking to improve, and we want to ensure quality updates for everyone involved. After all, we know it works on our development machines! If that were only enough…