Search

Sunday, January 14, 2018

Continuous Delivery of Games

The traditional overhead of "getting a game ready to release" can take quite a bit of time and reduce how quickly you can release new features to your players and respond to what the market is telling you.

Take, for example, the steps a mobile game development team I recently visited goes through for a release every few months:

  1. Merge the development branches
  2. Fix the merge-caused bugs
  3. Optimize, polish and debug for release quality
  4. Send to QA
  5. QA does their regression tests
  6. If bugs are found, return to step 3
  7. If quality is good, submit
  8. If the submission is rejected, return to step 3 to fix it
This took a lot of time! As a result, the team could only release major features several times a year, often behind those of their competitors who captured many of their impatient players.


Continuous delivery is a series of practices that ensures your code and assets can be rapidly and safely released to players by delivering every change to a production-like environment and ensuring that the game functions as expected through painstaking automated testing.

As more games move to more continuous delivery, tools and practices for supporting the ability to deploy with less hassle become more valuable.  Examples are:

  • Feature toggles
  • Continuous integration
  • Unit testing
  • Automated gameplay testing
  • Blessed build indicators
  • Form a stability team
  • Integrate QA
  • Etc
Most of theses practices can be found in my latest book Gear Up!


1 comment:

Anthony Barnes said...

Hello +Keith!

Could you please elaborate on the idea of "blessed build indicators? It reads as a synonym for a Definition of Done for qualifying a submission-ready build.

Thank you very much!