Independent Deployments — Release Train

Continuous improvement…

Increasing the efficiency…

Releasing products faster…

These and some more are the hottest topics we regularly discuss. Trying to find the fastest ways so satisfy our customers, users, etc. It’s also imperative failing fast for startups.

We, as software developers/teams/startups/companies, progressed a lot on that path. One of the most important part has always been DevOps practices.

One of the most important aspect of good DevOps practices is being independent from other development tracks. While bigger companies organize theirselves as autonomous small teams(as mentioned in agile practices) smaller companies or startups works as a single unit. They’re as big as a team of bigger companies :).

Anyways if you’re in a multi-team company then separating the responsibilities of teams is easy. Mostly all teams focus on a feature or a separate work unit so they work autonomously.

In a small team, though, it’s harder to organize the structure so every dev can make their own deployments regardless of what others had done.

We’re using some concepts in our team to have this kind of environment.

Release train concept

Release train is a deployment strategy in which you don’t care if a feature is completed or not. By using feature toggling, a feature remains hidden (although the code remains in the release) until it’s completed and tested.

In our latest project Whale Islands we’ve 4 different dev tracks: Blockchain, backend, frontend and unity.

Because we’re using Spica as our backend, it’s easy setting up the controllers and endpoints. We create cloud functions and assign a path. Every change in our backend requires increasing the version number of the backend. This allows us deploying backend without any concern or dependency to another track. No one knows until the client, that uses this new endpoint, is deployed.

On the Unity side we’ re using Cloud build and CCD service of Unity3d. By setting up badges on CCD. we’re able to make shallow deploys to all environments so we can review the deployment(probably make a regression test) before releasing it to our players/users. By following the SOLID principles in the codebase and using DI heavily, feature toggling is easy to implement.

This requires some practice of course. Everybody in the project/team must understand how things work. The development discipline should be solid. No must change a remaining endpoint for instance (especially for a breaking change)

We reduced deployment stress/burnout a lot. Because we don’t have a rush in case of having a failed deployment or find our a bug in the latest version. We make multi release in a day on different dev tracks and everything works fine. No one is blocked by anyone else in the team.