What is Continous Integration?#
You may define the Continous Integration (commonly abbreviated CI) as a set of rules and practices that allow you to contunously integrate all the changes made by the developers into your project. That process also involves running automated builds and performing tests.
One of the common scenarios of introducing CI in your daily workflow may look like this: every time someone makes any modification to the project and thier changes are merged to the repository, a task is being scheduled on some remote machine. The purpose of this task is to sync with these latest changes and try to actually build your project. If everything will go fine, the next step will be to run some unit tests that are going to verify if the application is still working properly. In case of any failure, the developers will be notified about the negative results.
This way you are able to control the state of your project and immediately react to the issues that may occur during the development process. CI helps you ensure that whatever change is being merged to your repository, it won't break your product or introduce any crucial regressions.
Sounds promising - but is is really the one and only solution that you should start using everywhere? Let us start by anwsering a simple question:
Do I even need CI in a gamedev project?#
If you're an indie developer who works on a gamedev-related project either completely on their own or in a small team consisting of only a few people, then you may probably wonder if introducing Continous Integration is really required in your daily work. Will you actually benefit from having such solution or is it redundant in your case?
These are perfectly vaild concerns. We believe that the solutions you use in your workflow should be awlays suited for your needs - this is why we recommend testing out different approaches and choosing the one that fits your company the most. There's no point in blindly sticking to the practices that were proven not working in the case of your project, even though they may fit well for the others.
We can safely say that it is pretty much about the size of the project and the amount of people who are working on it. When there are literally a few developers in your team and you're working alone on your product, it is much easier to keep control over its state. You will most likely spot integration issues sooner than later and the risk of ruining your application is relatively low. Also, when the scope of the project gets bigger, the developemnt process gets much more inpredicateble. You may then notice that the amount of potential issues continously grows with the number of implemented features and this may be sign that you are going to need the support of CI pipeline.
Large GameDev companies have a different situation than the indie ones. They will most likely benefit from having a solid CI pipeline form the very begging of the production process, since hundreds of people tend to work there on the same product and it's almost impossible to completely avoid integration issues in such situation. Here the CI comes to the aid and allows to lower the risks by identifying problems at the moment they occur.
As you most likely already noticed, the question we aksed ourselves is an extremely open one and it it's rather impossible to give a precise anwser that will be true in every single case. But we'll try to give you at least some clues on that to sum up the things we mentioned in this paragraph. Here are some examples of situation when you may be needing CI in your project:
- If your project has plenty of different configurations and you want to have them all tested on every introduced change
- If you cooperate with numerous people and want to lower the risk of introducing regression
- If your project keeps growing and so are the potential risks of breaking it with some new changes
Creating our own build server for CI - let's get started!#
If you are an indie developer who just decided that having a proper implementation of a CI pipeline will be beneficial for you project, but actually don't know where to start, then we will gladly share with you all the experience we gained while building such server for the needs of Nocturne project!
We will try to provide you a setup that will require an absolutely minimal cost. In this guide we'll be using the Jenkins software, which is based on the MIT license. We believe that the most reasonable solution is to use a separate machine for our buildserver, especially when you're working in a team of a few people who will be using it simultaneously. However it is also possible to host Jenkins on the same machine you're working on, which will probalby be suffecient if you work alone.
Of course you can use some online remote server to install Jenkins there, which is a perfectly fine approach, but in this tutorial we will be hosting it on our private, physical machine, that we've prepared just to serve us as a basic buildserver in case we wanted to extend its functionalities in the future.
The goal of this guide is to end up with having a working build server that will allow you to:
- Define, view and run tasks related to you project
- Run tasks on schedule
- Run tasks automatically after every submit to the project's repository - we will be working with Perforce here
Users#
We will need to setup users for our system. For the needs of this tutorial we will require 2 of them:
build-admin : admin user account, should be used only when there’s a real need of using admin rights, like during setting up the system, installing programs, configuring etc.
build-user : regular user account, without admin privileges - it will be the default account, which will run all the daily buildserver tasks
Security tip: All user accounts should be password-protected!
Establishing remote connection
When we will be working with our buildmachine, it would be nice to be able to establish connection with it from the PC you are usually working on on daily basis. This will allow the configuration to happen much faster and without the need of physically interfacing with the build server every time you will need to test something out.
This step should be an easy one. In case of troubles you can always follow this tutorial: How to use Remote Desktop - Microsoft Support.
On your buildmachine:
Go to Start → Settings → System → Remote Desktop
Turn on Enable Remote Desktop
Now, on some computer that is in the same LAN network and has connection to your buildmachine:
Open Remote Desktop Connection. Make sure to show hidden options.
Type the name/adress of the PC you want to connect to, enter the name of the user, whose account you want to use and then select Connect. You should be asked for a password, so please type it.
Voilà! Now you should be able to remotely access your server machine.
