Knowledge exchange is paramount for every software development team, no matter how big or small. Commonly used knowledge exchange methods include pair programming, team code reviews, hackathons, and so-called brown bag lunches. For me, either the scope of these methods seemed too limited, or the atmosphere too forced, so I could never actually get them off the ground. However, a recent and completely spontaneous experience in COMPLEVO turned into what I can honestly call a knowledge exchange success story.
It all started with a migration issue: we’d been playing with the thought of fully migrating from TeamCity to GitLab because we’d already been using GitLab for source code management, and developers felt more comfortable having everything “in one place”. There was another argument in favor of the migration: using TeamCity for running tests as an “external pipeline” increases the complexity of the setup and makes automated deployment more challenging. However, the lack of embedded reporting tools in automated tests in GitLab was one of the major showstoppers.
When it comes to automated testing, TeamCity provides a rich suite of reporting features that have proved to be priceless during debugging and bug fixing. These features include:
Since we used xUnit, which is seamlessly integrated into TeamCity, we were able to get all the features listed above out of the box. Which of these features did GitLab offer? None. Zero. Nada. At best, xUnit itself could provide an XML test protocol for a pipeline which contained the necessary source information but was still hardly useful. A year ago, a feature request from the GitLab community was submitted. The feature has not been implemented yet; it continues to exist only as a feature request, which shows it’s not a high priority for GitLab developers. If you have 1500 automated test cases, including 300 fairly complex integration test cases, you inevitably need some reporting that goes beyond: “Oops, something went wrong. What exactly? Well, here is a console output!”
It seemed that we were stuck. The migration task had been in the backlog for 5 months. We still used GitLab for source code management, and TeamCity as an external pipeline for test runs and reporting. And then, one day, it all changed. And the change started with an off-hand question in the team kitchen from a colleague working on a different project:
“Hey, how’s it going?”
I must confess, I’m one of those people who, on being asked this question, actually starts elaborating on how it is going. So, I explained that we recently implemented Elastic Search for logging and played around with Kibana dashboards; both of these tools are free and relatively intuitive once you get a grasp on them. To this, my colleague replied:
“Huh, you know, we actually used ELK stack for test reporting in my previous company”.
And I instantly realized that ELK stack was exactly what we needed- a free, flexible, and extensible suite that might become the much-needed replacement for TeamCity reporting. While the technical side of this story will be described in another article, I’d like to emphasize here the spontaneity of this knowledge exchange, which proved to be priceless and from which we can learn a lot.
What made our conversation so fruitful? Firstly, it took place in the native language of both parties, which in this case was Russian. Time and again I have noticed that people are more relaxed and more likely to share their thoughts and worries when communicating in their native language. A developer may say “yeah, it’s fine” during a planning session in English, and then let off steam talking to a Russian colleague in Russian. (Recent research tend to agree, see here).
Secondly, both of us were free to talk about whatever we wanted, and it just so happened that I had this problem on my mind. On previous occasions we had talked about rents, vacations, weather and whatnot, so this technical chatter was utterly unforced (by the way, that’s why I tend to think that a formally organized brown bag lunch is not quite the best idea). It has often been noted that a simple break is immensely helpful in finding a solution to a problem you’re working on, since your brain keeps on thinking in the background. It is also well-known how valuable the fresh perspective of an outsider may be, and luckily for me, my situation combined both.
Thirdly, it was this colleague’s wide range of previous experience and knowledge combining thousands of hours of work, reading blogs, and trying (and failing!) all sorts of possible solutions that introduced me to this new option which we are currently adopting. Nowadays, it is almost expected that everyone in IT plays around with new frameworks in their free time, reads at least 10 technical blogs, and has an active side project and five long-abandoned ones still available on GitHub. Realistically, not everyone can live up to this expectation, and even if they can, it is no longer humanly possible to embrace all possible aspects of modern IT that are relevant to your day-to-day job. Impromptu conversations can therefore allow developers to learn about options that they were previously unaware of.
The short kitchen conversation described in this blog became a good reason to schedule an hour-long knowledge exchange seminar between the testing teams working on the respective projects. Our company has recently undergone a growth spurt, and my colleague’s team was operating under tight deadlines. Their testing team had to catch up and cover already existing code, so they never found the time to tell other teams about the technology stack they were using, and the solutions they found in the process. If we had planned a full-on knowledge exchange session between our two teams, encompassing everything worth mentioning from the technology standpoint, it would probably have required at least half a day and the coordination of 15 schedules. However, finding just an hour to hear about the team’s testing tools and practices was easy. And what’s more, what we found most relevant for our project was not this knowledge exchange session as such, but the discussions that preceded it and the discussions that followed it.
What can we learn from this story?