From The Pipeline v32.0

This entry is part 32 of 33 in the series From the Pipeline

The following will be a regular feature where we share articles, podcasts, and webinars of interest from the web.


In a look into the game industry, a software engineer at Riot shared details on how they build, test, and deploy “Legends of Runeterra”, an online card game. The team switched from Perforce to Git with a hierarchical branch-based workflow. This is because the team was breaking the main branch build too often with trunk-based development. They also create new test environments as needed for each branch so developers will have isolated sandboxes to test. Riot also use HTTP servers on debug builds of their game for direct control of the game for functional automated testing. Another cool feature Riot has developed is a custom GUI tool for the game so non-technical contributors can more easily use Git.

X-ray Vision and Exploratory Testing

“Imagine you have X-ray vision. Instead of seeing through walls, you can see the inner structure of programs, the bugs lying inside, and how to expose them. Anyone could execute the steps you gave them to reproduce the bugs. The difficulty in testing, then, is not in executing steps; it is figuring out what steps to take. How do you find those hidden bugs? We need to be the X-ray vision.”

Tips for engineering managers learning to lead remotely

GitLab team members share how they managed the shift from in-person, co-located work to working and managing teams remotely at GitLab to help others make the transition to remote work more easily. Clear communication is key — especially when looking for a quick answers as opposed to a formal meeting. There is a bias towards over-communication when working remotely. Another challenge is to build connected and engaged teams. To help, teams should proactively work to build interpersonal connections with activities such as coffee chats, sharing of non-work hobbies, and team building activities.

Building CI/CD Pipeline with Jenkins, Kubernetes & GitHub: Part 2

This article is the second in a series on implementing a CI/CD pipeline that will cover multibranch pipelines and GitHub Organization pipelines. Give this article a read if you’re interested in learning how to build from the ground up, starting with credential management, configuring pipelines, and using Kubernetes. The article also links to other training materials on fundamentals of Kubernetes and deploying with Kubernetes.

Test Flakiness – One of the main challenges of automated testing (Part II)

The Google testing blog has posted part two on their series of test flakiness. In this edition, they explore the four conditions that can cause flakiness, advice on triaging those failures, and how to remedy the problems at their source. The tests themselves can introduce flakiness, which can include test data, test workflows, initial setup of test prerequisites, and initial state of other dependencies. Additionally, an unreliable test-running framework can introduce flakiness. The application and underlying services / libraries that the testing framework depends upon can cause flakiness. Lastly, the OS and hardware that the application and testing framework depend upon can cause flakiness.

Series Navigation<< From The Pipeline v31.0From The Pipeline v33.0 >>

Leave a Reply

%d bloggers like this: