🧱 Build Setup
Setting up a Continuous Integration (CI) environment is extremely valuable. However it can cost quite a bit of time to set it up properly. In our experience, multiple months can be spend tweaking it for a single developer. That is why we did the work for you, just read and follow the guidelines in this chapter to get your build machine and CI environments setup within a day.
!!! tip "Create your build machine early" Your Continuous Integration build machine and environments have to be setup once. So it is extremely useful to create it at the very beginning of the project so you do not have to come back to it later.
Mobile device build machine
As iOS build can only be build on an Apple device, we advice setting up a Jenkins Apple build machine.
A Mac Mini or Mac Studio can easily be stored in a small space after setting it up. It is up to you to choose if you invest in multiple Mac Mini's or in a single strong Mac Studio environment. When there are multiple projects running in the studio, it is possible to allocate specific builds to specific machines. This prevents having to wait for a long time before the build even starts, or preventing the build time to slow down because the build machine is running multiple build processes at once.
Build machine sharing settings
It is always useful to access jenkins for your team through website access and to be able to control the build machine using the Screen Sharing app in case of trouble shooting.
... ADD HOW TO INSTALL A BUILD MACHINE
Pipelines
Pipelines are your release environments.
Each build will be its own app environment on the app stores. This allows clear separation between all the stages of development. This prevents accidentally sending the wrong build to the wrong audience.
We use these terms throughout GameSuite to talk about the build in different stages of development and release:
Develop
- Bundle id: com.company.game.dev
- Debug menu is enabled
- Does not need to be setup on your app stores or build machine
- Local test builds by developers
QA
- Bundle id: com.company.game.qa
- Debug menu is enabled
- Build is created on TestFlight and Google Play Store etc.
- Release to internal testers (and external QA)
Alpha
- Bundle id: com.company.game.alpha
- Debug menu is disabled
- Build is created on TestFlight and Google Play Store etc.
- Release to external testers
Beta
- Bundle id: com.company.game.beta
- Debug menu is enabled
- Build is created on TestFlight and Google Play Store etc.
Staging
- Bundle id: com.company.game
- Build is created on TestFlight and Google Play Store etc.
- This will be the new production build, but before Apple/Google approved it
- This build should run with a newer version on a newer backend, while production is live at the same time.
Production
- Bundle id: com.company.game
- Build is created on TestFlight and Google Play Store etc.
!!! tip "Bundle id visibility" The Bundle Id is not directly visible to the end user and they wouldn't notice it, unless they specifically go to the application details on the app stores, or on pc, the url shows the full bundle id. If you are still afraid of users calling out that the build ends with *.beta, create a different name for it which is not that obvious.
| Bundle identifier | Users | Usage | Debug | Distribution | Frequency |
|---|---|---|---|---|---|
| Develop | Single local developer | Test functionality on device | Yes | Local only | As often as needed |
| QA | (QA) team | Catch bugs early, test if build is ready for release | Yes | Automatically through CI | Every day & end of sprint |
| Alpha | Larger external groups, external partners, advisors | Closed release through TestFlight | No | Manually | Sprint |
| Beta | Early testers feature release or market test launches | Send to test groups with unlocked features | No | Manually | Sprint |
| Production | Soft or global launch | Builds have to be tested and approved by QA | No | Manually | Sprint |
!!! tip "Testing under a different company or project name" When working on a project which should not be coupled to your production company name, decide before you start working on it what the alternative company and project name should be. Once the project has gone through successful market testing, cancel the old project and create a new project under the final company and project name on the GameSuite website and insert the new api key in Unity.
Jenkins
Jenkins installation
Release notes
For end of sprint builds, Alpha, Beta and Live builds: make sure to edit the automatically generated release notes to contain everything from the last build.
This is a good layout of release notes to communicate to your (test) users all the great new things added to the build:
- Features
- These contain new features added to the game
- Changes
- How existing features in the game have been changed
- Balancing changes
- Visual changes
- Fixes
- Bug fixes and other improvements
Making builds
Read the chapter on build process.