Continuous Delivery, the ObjectStyle Way: Interview with DevOps Aficionado Evgeni Vintik

In continuous delivery, development is a journey, not a destination. The developer’s work is never done. And, if it is done, this spells the death of a project.
Evgeni Vintik

OS: As far as I know, you were the one who introduced continuous integration into your team’s routine here at ObjectStyle. What inspired you to do that?

EV: Prior to ObjectStyle, I worked for a company where continuous integration was the norm. We were using TeamCity to cooperate and were rolling out product updates each week.

When I joined ObjectStyle about two years ago, my team were releasing software updates irregularly, and the amount of time it took to test things before each release, was way too much.

The reason it was taking so long, was that unit tests were scarce and there was poor code coverage. Moreover, out of the few unit tests that existed, many were outdated; this made those tests pretty useless.

So, I wanted my team to know there was a better way to write code. I was positive that, once they tried continuous integration, they would never look back. That was how I became a kind of a trailblazer for the cause at ObjectStyle.

OS: How long has it been since you started the “revolution”?

EV: It’s been about a year and a half.

OS: What were the challenges of introducing the new approach?

EV: One of the main challenges was breaking the old mindset. When a developer is used to a particular style of work, it’s difficult to make him/her adapt a new model. Naturally, people don’t want to get out of their comfort zones.

But, luckily, continuous integration brings fruit pretty quickly, which gives you the incentive to carry on. The greater your test coverage, the easier it becomes to compose new code for a program.

Another challenge was to stick to the newly adopted code quality standard. According to the new standard, code had to pass all existing tests with no exception to be incorporated into the release.

It’s important to have zero tolerance to failed tests, because, on one occasion, you let a couple of minor issues slide. Then on another occasion, you decide “Heck, maybe a dozen minor issues is not a big deal..”. This tends to snowball pretty quickly, and, before you know it, you’re not doing continuous delivery any longer, because you start accumulating technical debt, which takes you in the opposite direction.

It’s important to have zero tolerance to failed tests, because, on one occasion, you let a couple of minor issues slide. Then on another occasion, you decide “Heck, maybe a dozen minor issues is not a big deal..”. This tends to snowball pretty quickly, and, before you know it, you’re not doing continuous delivery any longer…

OS: How did you cope with the challenges?

EV: First, I had to talk to the programmers and convince them to write more unit tests in order to increase test coverage. We introduced a system where, if the test coverage in an individual branch was smaller than the average test coverage in the master branch, the code was not passing the test.

Usually, this means that the developer has written too much code without writing sufficient unit tests for the code. Modern continuous delivery tools are pretty accurate at determining how much testing is required, and we rely on them for that matter.

We also struggled to create a workflow where we would do end-to-end testing on a regular basis. While automated E2E tests already existed in some form, they were run inconsistently; and some of them were outdated.

These tests take a huge amount of time to write and keep up to date. But we had to start somewhere. Clearly, the main purpose was to cover the core functionality without going too crazy and trying to cover every tiny feature in the application.

But this is the area where you see the biggest return on investment, so to say. The longer you’ve been writing end-to-end tests, the less time is needed to maintain them or build up on them.

So, to sum this up, the strategy is as follows: unit tests should have maximum coverage, while end-to-end tests need to cover the crucial features/parts of the product.

OS: Did you start using any new tools for continuous delivery?

EV: At first, we decided to go with Atlassian’s Bamboo, the cloud–based platform. But, unfortunately, Atlassian stopped supporting it in 2017.

Then we switched to JetBrain’s TeamCity. If you’re not familiar with it, TC is a great fit for Java in particular and is designed with continuous integration in mind. Besides, there is a robust free version available.

There are tons of other tools, of course. I would recommend anyone looking for language- and platform-agnostic instruments to try BitBucket’s Pipelines. You don’t even need to set up a server to run it.

In addition, there are quite a few great CI services available that integrate with GitHub. If you have a public repository, this is a good option.

OS: Besides the fact that continuous integration is a trend now, what are the key benefits?

EV: The longer you do CI and the more software has been written using CI-driven requirements, the easier it becomes to introduce changes or to release new features for the project.

Eventually, you should arrive at a point where you no longer have to worry about reverse compatibility or time-consuming tests. There are fewer surprises, and getting feedback on the compliance of your code becomes a routine.

Then the developer enjoys greater peace of mind and can finally focus on programming, adjusting their code as they go – instead of ping-ponging tickets back and forth between dev and QA.

Then the developer enjoys greater peace of mind and can finally focus on programming, adjusting their code as they go – instead of ping-ponging tickets back and forth between dev and QA.

In the old times, you had to wait and develop film before you could see how the photo came out. Nowadays, you can see the pictures you take momentarily, because people have digital cameras and there is no need to wait. Coding while getting immediate feedback from automatic tests is very much like that.

OS: How does continuous integration relate to Agile, DevOps, TDD and continuous delivery? I realize these terms are NOT interchangeable, but oftentimes they’re thrown around as part of the same bundle of concepts.

EV: Speaking of the first two (Agile and DevOps), continuous integration is a much more concrete process that can apply to any software development company, regardless of its size.

Agile is more of a philosophy/methodology. Some companies do Agile without even realizing it. You don’t have to use fancy terms like Scrum, Sprint or Kanban to be doing Agile.

And while the latter is a great methodology, continuous integration is what makes Agile possible. Without continuous integration, it is difficult to release working software as frequently as the methodology requires you to.

DevOps is an even more esoteric concept. But I believe it is something quite real in big organizations that build mass-market products. The implementation may vary, but a big company often has a dedicated person or even a department responsible for releases, version control, and maintaining and customizing software/hardware used in deployment. Imagine releasing the new version of a program that distributed among hundreds of servers. And a big organization may be doing it several times a day! Then you definitely need DevOps.

Continuous delivery is the result of continuous integration. This is something you arrive at after you’ve been investing your sweat and blood and tears into continuous integration for some time. That’s the benefit you reap.

OS: If you were to describe continuous delivery in a few words, what would that be?

EV: In continuous delivery, development is a journey, not a destination. The developer’s work is never done. And, if it is done, this spells the death of a project.