How Continuous Integration boosts development

TL;DR

• It's all about setting up automated processes that replace tasks you would perform manually, but it would take your precious time and you'd only do it from time to time.

• It happens to be extremely important to repeat some tasks frequently, so you can easily detect issues with your game.

• These processes are easy to set up for any kind of team. Popular software is available for free and easier to use than most of the development tools.

  • You can simply install one of these tools on your computer if working alone. Or if your personal computer is also a server for your team.

  • Or you can install tools on your dedicated server machine. It could be an old computer, initially.

  • Eventually, you can use one of many cloud solutions, i.e. BitBucket.

Commonly Continous Integration Software is abbreviated to CIS or even just CI.

Layers

Using "source control"

The first layer for every team is to use Version Control System, which provides an easy way to maintain your project data. You need this to use the next layers.

• Don't make backups manually, by copy-pasting your entire project to pen drive or some Dropbox. Use solutions tailored for software development, including video games.

• Read Every project needs a version control system if you don't know what's the "version control".

Continous building the code

• If your project is a C++ project already, CIS gonna automatically compile the source code every time programmer submitted code to the repository. The server compiles the code and submits binaries back to the repository.

• You don't need this if working with blueprints in UE4 or C\# in Unity - code is compiled on every machine separately.

Cooking frequently

Cooking (packaging) the entire game every single day, at least if any changes were submitted. Or you could trigger a cooking game after every submitted change, or every few hours.

Why do that? You only need the packaged game while sending a demo to someone or finished game to the store, right? Wrong. You need to test a packaged game frequently to ensure everything works there correctly. People gonna play a cooked version of the games, not that what you have in the editor.

• Continous cooking allows detecting major issues just after it appeared, not weeks after. If something sent asset breaking the cooking process and you'd notice that after a month... It will take a lot of time to understand why this asset is broken and how to fix it.

• You'll understand the differences between "editor game" and actual "packaged game" soon enough. Especially important while coding mechanics in C++. There are also a few fundamental differences in how the game works in the editor compared to the cooked version.

• You gonna quickly find that some assets or entire folder aren't included while packaging, it's a common issue. There are many reasons for that, but usually, it's easy to apply the fix.

• Basic programmer's mistakes will be detected shortly after submitting code. Probably the most common issue with the cooking game is a single line of editor-only code that hasn't be marked to "compile only for editor builds".

It's extremely easy to set up automated cooking with Unreal. All you need is an automated way to run a single command, i.e. every day at midnight.

%teamcity.build.workingDir%\[UE4]\Engine\Build\BatchFiles\RunUAT.bat BuildCookRun -project="%teamcity.build.workingDir%\MyProject\MyProject.uproject" -noP4 -platform=Win64 -clientconfig=Development -cook -build -stage -pak -archive -archivedirectory="[AnyFolder]\Cooks\%build.vcs.number% dev"

Tasks do perform on frequently cooked game

Obviously, if you have a QA team, they would often play on cook and report issues.

Nevertheless, with the time you can prepare automated tests\! Yes, it wouldn't require a developer to repeat all these boring steps every day!

• Simply launching a game, testing if it loads properly.

• Reporting performance stats, saving in to log or sending to your chat channel automatically. Thanks that you have to do nothing else, the system itself would notify if performance in-game got worse. Also, you easily browse performance stats for the last month or any particular day.

• Manually define spots for performance capture in the game. This way you'll get reliable results: checking framerate and memory in the very same spot every day.

• The last part would be to create automated functional tests. The game can test itself if basing systems work properly! Although this requires you to prepare testing scripts, the most time-consuming part of these workflows.

Story of the studio before and after using Continous Integration