Originally published on DZone. Interview conducted by Alesia Krush with Evgeny Vintik, Team Lead at ObjectStyle.
Background: Why CI Was Needed
Evgeny Vintik came to ObjectStyle having already worked in an environment where Continuous Integration (CI) was standard practice. His previous employer used TeamCity to coordinate work and shipped product updates every week. When he joined ObjectStyle, things looked quite different: releases were irregular, pre-release testing consumed enormous amounts of time, unit tests were sparse and many of those that existed were outdated and effectively useless.
Recognising the gap, Vintik set out to introduce CI as a core part of his team’s daily development routine — a process that took roughly a year and a half to take root.
The Challenges of Changing the Mindset
Introducing CI is as much a cultural challenge as a technical one. Vintik identifies two main obstacles his team faced:
- Breaking established habits. Developers accustomed to a particular workflow are naturally reluctant to leave their comfort zone. The good news, Vintik notes, is that CI delivers visible results relatively quickly, which helps build momentum.
- Maintaining zero tolerance for failing tests. Once a code-quality standard is agreed upon — specifically, that code must pass all existing tests before it can be merged — it is critical to enforce it without exceptions. Letting a few minor failures slide can snowball rapidly. Each concession makes the next one easier to justify, and before long the team is accumulating technical debt instead of practising Continuous Delivery.
Practical Strategies for Making CI Stick
Enforcing Test Coverage at the Branch Level
To encourage developers to write more unit tests, the team introduced a rule: if test coverage in a feature branch fell below the average coverage in the master branch, the build would fail. This acts as an automatic gate, preventing developers from merging code that does not carry its own weight in tests.
End-to-End Testing: Start Small, Focus on Core Functionality
End-to-end (E2E) tests already existed in some form when Vintik’s team started, but they were run inconsistently and many were outdated. Writing and maintaining E2E tests is time-intensive, so the team adopted a focused strategy: cover the core functionality thoroughly rather than trying to test every minor feature. Vintik observes that E2E tests deliver the greatest return on investment over time — the longer you invest in them, the cheaper they become to maintain and extend.
The overall testing strategy the team settled on can be summarised as:
- Unit tests: maximum coverage across the codebase.
- End-to-end tests: focused coverage of critical features and user journeys.
Tools the Team Evaluated and Adopted
Choosing the right CI tooling was an iterative process for ObjectStyle:
- Atlassian Bamboo (cloud): The team’s first choice. According to Vintik, Atlassian discontinued support for the cloud-hosted version of Bamboo in 2017, which forced a switch.
- JetBrains TeamCity: The team migrated to TeamCity and found it a strong fit, particularly for Java projects. It is built with CI in mind and offers a robust free tier for smaller teams.
- Bitbucket Pipelines: Vintik recommends this for teams looking for a language- and platform-agnostic option. It requires no dedicated server infrastructure, reducing operational overhead.
- GitHub-integrated CI services: For projects hosted in public GitHub repositories, several CI services integrate directly with the platform and are worth evaluating.
The Real Benefits of Continuous Integration
Beyond the industry trend, Vintik articulates concrete, compounding benefits his team experienced:
- Introducing changes becomes cheaper over time. The more code that has been written under CI discipline, the easier it is to add new features or refactor existing ones without fear of regressions.
- Fewer surprises. Automated tests catch compliance issues immediately, turning what used to be late-stage QA discoveries into routine, low-stakes feedback loops.
- Developers can focus on programming. Instead of manually passing tickets back and forth between development and QA, engineers receive fast, automated feedback and can adjust code on the spot.
Vintik offers a memorable analogy: developing software with immediate automated feedback is like using a digital camera instead of film — you no longer have to wait to see whether the shot came out.
How CI Relates to Agile, DevOps, TDD, and Continuous Delivery
These terms are frequently bundled together. Vintik draws useful distinctions:
- Agile is a philosophy or methodology. Teams can practise Agile principles without adopting any specific framework (Scrum, Kanban, etc.). CI is what makes frequent Agile releases technically feasible — without it, shipping working software at the pace Agile demands is very difficult.
- DevOps is a broader organisational concept, most tangible in large companies shipping mass-market products. At scale — think hundreds of servers receiving multiple deployments per day — a dedicated team or function responsible for releases, version control, and deployment infrastructure becomes essential.
- Continuous Delivery is the outcome of sustained investment in CI. Once a team has built up solid test coverage and reliable pipelines, they arrive at a state where releasing software becomes routine rather than an event. It is the reward for the hard work put into CI over time.
- TDD (Test-Driven Development) is a coding practice that complements CI by ensuring tests are written before or alongside code rather than as an afterthought, supporting the high coverage levels that CI requires.
Continuous Delivery in a Sentence
Asked to distil Continuous Delivery into a few words, Vintik puts it this way:
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.
— Evgeny Vintik, Team Lead, ObjectStyle
Key Takeaways
- Cultural resistance is the first barrier to CI adoption — early, visible wins help overcome it.
- Zero tolerance for failed tests is not optional; every exception erodes the standard.
- Enforce coverage at the branch level to prevent regression without manual policing.
- E2E tests are expensive to write but deliver compounding returns; prioritise core functionality.
- Tool choice matters less than discipline — TeamCity, Bitbucket Pipelines, and GitHub-integrated services are all viable starting points.
- Continuous Delivery is not a tool or a framework; it is the measurable outcome of sustained CI practice.