DevOps and Game Dev with GitLab CI/CD

DevOps and Game Dev with GitLab CI/CD

随着 WebGL 和 WebSockets 的进步，浏览器作为游戏开发平台非常可行，而无需使用 Adobe Flash 之类的插件. 此外，通过使用 GitLab 和 ，单个游戏开发人员以及游戏开发团队可以轻松地在线托管基于浏览器的游戏.

在本教程中，我们将专注于 DevOps，以及使用GitLab CI / CD使用持续集成/部署方法测试和托管游戏. 我们假设您熟悉 GitLab，JavaScript 和游戏开发的基础知识.

我们的由一个简单的太空飞船组成，该太空飞船通过在给定方向上单击鼠标进行射击.

在开发另一款游戏Dark Nova的开始时，创建强大的 CI / CD 流水线对于团队工作的快速节奏至关重要. 本教程将以我并执行以下步骤：

  1. 使用上一篇文章中的代码开始由 gulp 文件构建的准相位游戏
  2. 添加和运行单元测试
  3. 创建可以触发以给定方向生成的Weapon类
  4. 添加使用此武器并在屏幕上四处移动的Player类
  5. 添加我们将用于Player和Weapon的精灵
  6. 使用持续集成和持续部署方法进行测试和部署

到最后，我们将拥有一个的核心，该游戏在每次推送到 master分支时都经过测试和部署. 这还将提供样板代码，用于启动具有以下组件的基于浏览器的游戏：

  • 用TypeScript和
  • 使用Gulp构建，运行和测试
  • 和Mocha 的单元测试
  • 使用 GitLab 进行 CI / CD
  • 在 GitLab.com 上托管代码库
  • 在 AWS 上托管游戏
  • 部署到 AWS

Requirements and setup

请参考我以前的文章DevOps 和 Game Dev，以学习基础开发工具，运行类似于 Hello World 的游戏，以及从每次新推手到使用 GitLab CI / CD 来构建此游戏. 此游戏的master分支包含具有所有配置的完整版本. 如果您想继续阅读本文，可以从devops-article分支进行克隆并进行工作：

接下来，我们将创建一小部分测试，以举例说明我希望该Weapon类经历的大多数状态. 首先，创建一个名为lib/tests的文件夹，并将以下代码添加到一个新文件weaponTests.ts ：

  1. import { expect } from 'chai';
  2. import { Weapon, BulletFactory } from '../lib/weapon';
  4. describe('Weapon', () => {
  5.     var subject: Weapon;
  6.     var shotsFired: number = 0;
  7.     // Mocked bullet factory
  8.     var bulletFactory: BulletFactory = <BulletFactory>{
  9.         generate: function(px, py, vx, vy, rot) {
  10.             shotsFired++;
  11.         }
  12.     };
  13.     var parent: any = { x: 0, y: 0 };
  15.     beforeEach(() => {
  16.         shotsFired = 0;
  17.         subject = new Weapon(bulletFactory, parent, 0.25, 1);
  18.     });
  20.     it('should shoot if not in cooldown', () => {
  21.         subject.trigger(true);
  22.         subject.update(0.1);
  23.         expect(shotsFired).to.equal(1);
  24.     });
  26.     it('should not shoot during cooldown', () => {
  27.         subject.trigger(true);
  28.         subject.update(0.1);
  29.         subject.update(0.1);
  30.         expect(shotsFired).to.equal(1);
  31.     });
  33.     it('should shoot after cooldown ends', () => {
  34.         subject.trigger(true);
  35.         subject.update(0.1);
  36.         subject.update(0.3); // longer than timeout
  37.         expect(shotsFired).to.equal(2);
  38.     });
  40.     it('should not shoot if not triggered', () => {
  41.         subject.update(0.1);
  42.         subject.update(0.1);
  43.         expect(shotsFired).to.equal(0);
  44.     });
  45. });

为了使用gulpfile.js构建和运行这些测试，我们还要将以下gulpfile.js函数添加到现有的gulpfile.js文件中：

  1. gulp.task('build-test', function () {
  2.     .pipe(tap(function (file) {
  3.       // replace file contents with browserify's bundle stream
  4.       file.contents = browserify(file.path, { debug: true })
  5.         .plugin(tsify, { project: "./tsconfig.test.json" })
  6.         .bundle();
  7.     }))
  8.     .pipe(buffer())
  9.     .pipe(sourcemaps.init({loadMaps: true}) )
  10.     .pipe(gulp.dest('built/tests'));
  11. });
  13. gulp.task('run-test', function() {
  14.     gulp.src(['./built/tests/**/*.ts']).pipe(mocha());
  15. });

我们将开始实施游戏的第一部分，并通过这些Weapon测试. Weapon类将公开一种方法，以给定的方向和速度触发子弹的生成. 稍后，我们将实现一个Player类，将用户输入绑定在一起以触发武器. 在src/lib文件夹中，创建一个weapon.ts文件. 我们将添加两个类： Weapon和BulletFactory ，它们将封装 Phaser 的sprite和group对象，以及游戏特定的逻辑.

最后，我们将重做我们的入口点game.ts ，将Player和Weapon对象绑定在一起，并将它们添加到更新循环中. 这是更新的game.ts文件的外观：

  2. import { Weapon, BulletFactory } from "./weapon";
  4. window.onload = function() {
  5.     var game = new Phaser.Game(800, 600, Phaser.AUTO, 'gameCanvas', { preload: preload, create: create, update: update });
  6.     var player: Player;
  7.     var weapon: Weapon;
  9.     // Import all assets prior to loading the game
  10.     function preload () {
  11.         game.load.image('player', 'assets/player.png');
  12.         game.load.image('bullet', 'assets/bullet.png');
  13.     }
  15.     // Create all entities in the game, after Phaser loads
  16.     function create () {
  17.         // Create and position the player
  18.         var playerSprite = game.add.sprite(400, 550, 'player');
  19.         playerSprite.anchor.setTo(0.5);
  20.         player = new Player(game.input, playerSprite, 150);
  22.         var bulletFactory = new BulletFactory(game.add.group(), 30);
  23.         weapon = new Weapon(bulletFactory, player.sprite, 0.25, 1000);
  25.         player.loadWeapon(weapon);
  26.     }
  28.     // This function is called once every tick, default is 60fps
  29.     function update() {
  30.         var deltaSeconds = game.time.elapsedMS / 1000; // convert to seconds
  31.         player.update(deltaSeconds);
  32.         weapon.update(deltaSeconds);
  33.     }
  34. }

为了确保我们的更改不会破坏构建并且所有测试仍然通过，我们利用持续集成（CI）来为每次推送自动运行这些检查. 通读本文以了解持续集成，持续交付和持续部署 ，以及 GitLab 如何利用这些方法. 在上我们已经设置了一个.gitlab-ci.yml文件，用于从每次推送开始构建我们的应用程序. 我们需要设置一个新的 CI 作业进行测试，GitLab CI / CD 将使用我们从 gulp 生成的工件在构建作业后运行.

请通读CI / CD 配置文件的文档，以探索其内容并根据需要进行调整.

我们需要更新构建作业以确保测试也能运行. 将gulp build-test添加到现有build作业的script数组的末尾. 一旦这些命令运行，我们就知道需要访问 GitLab CI / CD artifacts提供的built文件夹中的所有内容. 我们还将缓存node_modules以避免不得不完全重新拉动那些依赖项：只需将它们打包在缓存中即可. 这是完整的build工作：

  1. build:
  2.   stage: build
  3.   script:
  4.     - npm i gulp -g
  5.     - npm i
  6.     - gulp
  7.     - gulp build-test
  8.   cache:
  9.     policy: push
  10.     paths:
  11.       - node_modules
  12.   artifacts:
  13.     paths:
  14.       - built

Test your game with GitLab CI/CD

对于本地测试，我们只需要运行gulp run-tests ，这需要像build作业一样在全球范围内安装 gulp. 我们从缓存中拉出node_modules ，因此npm i命令不必做太多事情. 在准备部署时，我们知道我们仍然需要工件中的built文件夹，该文件夹将作为上一个作业的默认行为被带入. 最后，按照惯例，我们通过给 GitLab CI / CD 一个test 阶段来告知需要在build工作之后运行它. 按照 YAML 结构， test作业应如下所示：

我们为以指定间隔射击的Weapon类添加了单元测试. Player类实现了Weapon以及四处移动和射击的能力. 此外，我们还使用.gitlab-ci.yml在 GitLab CI / CD 管道中添加了测试工件和测试阶段，从而使我们能够在每次推送时运行测试. 现在，我们整个.gitlab-ci.yml文件应如下所示：

  1. image: node:10
  3. build:
  4.   stage: build
  5.   script:
  6.     - npm i gulp -g
  7.     - npm i
  8.     - gulp
  9.     - gulp build-test
  10.   cache:
  11.     policy: push
  12.     paths:
  13.       - node_modules/
  14.   artifacts:
  15.     paths:
  16.       - built/
  18. test:
  19.   stage: test
  20.   script:
  21.     - npm i gulp -g
  22.     - npm i
  23.   cache:
  24.     policy: pull
  25.     paths:
  26.       - node_modules/
  27.   artifacts:
  28.     paths:
  29.       - built/

而已！ 添加所有新文件，提交并推送. 有关此时存储库外观的参考，请参考的最终提交 . 通过同时应用构建和测试阶段，GitLab 将在每次推送到我们的存储库时按顺序运行它们. 如果一切顺利，您将在管道的每个作业上得到一个绿色的复选标记：

您可以通过单击test作业以输入完整的构建日志来确认测试通过. 滚动到底部，观察所有过去的荣耀：

  1. $ gulp run-test
  2. [18:37:24] Using gulpfile /builds/blitzgren/gitlab-game-demo/gulpfile.js
  3. [18:37:24] Starting 'run-test'...
  4. [18:37:24] Finished 'run-test' after 21 ms
  6.   Weapon
  7.     ✓ should shoot if not in cooldown
  8.     ✓ should not shoot during cooldown
  9.     ✓ should shoot after cooldown ends
  10.     ✓ should not shoot if not triggered
  12.   4 passing (18ms)
  14. Uploading artifacts...
  15. built/: found 17 matching files
  16. Uploading artifacts to coordinator... ok            id=17095874 responseStatus=201 Created token=aaaaaaaa Job succeeded

Continuous Deployment

我们在每次推送时都构建并测试了代码库. 为了完成持续部署的全部流程，让我们设置免费的 Web 托管，并通过一项工作来部署构建工件. GitLab 还提供了免费的静态站点托管服务 ，但是 Dark Nova 特别使用需要使用AWS S3其他 AWS 工具. 通读本文，该文章描述了如何同时部署到 S3 和 GitLab 页面，并且比本文讨论的内容更深入地研究 GitLab CI / CD 的原理.

Set up S3 Bucket

  1. 登录您的 AWS 账户并转到S3
  2. 点击顶部的创建存储桶链接
  3. 输入您选择的名称，然后单击下一步
  4. 保留默认属性 ，然后单击下一步
  5. 单击” 管理组”权限 ，然后为” 所有人”组允许” 读取 “，单击”下一步”.
  6. 创建存储桶，然后在您的 S3 存储桶列表中选择它
  7. 在右侧，单击” 属性”并启用” 静态网站托管”类别
  8. Update the radio button to the 使用此存储桶托管网站 selection. Fill in index.html and error.html respectively

我们需要能够使用我们的 AWS 账户凭证部署到 AWS，但是我们当然不希望在源代码中添加机密信息. 幸运的是，GitLab 通过提供了解决方案. 由于IAM管理，这可能会变得复杂. 作为最佳实践，您不应使用根安全凭证. 正确的 IAM 凭据管理不在本文讨论范围之内，但是 AWS 会提醒您，不建议使用 root 凭据，并且应该违反其最佳做法. 随意遵循最佳实践并使用自定义 IAM 用户的凭据，这将是两个相同的凭据（密钥 ID 和密钥）. 充分了解是一个好主意. 我们需要将以下凭据添加到 GitLab：

  1. 登录您的 AWS 账户并转到安全凭证页面

  3. 转到您的 GitLab 项目，单击左侧栏中的设置> CI / CD .

  4. 展开变量部分

  5. 添加一个名为AWS_KEY_ID的密钥，并将步骤 2 中的密钥 ID 复制到” 值”字段中

  6. 添加一个名为AWS_KEY_SECRET的密钥，并将步骤 2 中的密钥机密复制到” 值”字段中

Deploy your game with GitLab CI/CD

要部署构建工件，我们需要在 Shared Runner 上安装AWS CLI . Shared Runner 还需要能够通过您的 AWS 账户进行身份验证以部署工件. 按照约定，AWS CLI 将寻找AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY . GitLab 的 CI 为我们提供了一种使用deploy作业的variables部分传递在上一节中设置的variables的方法. 最后，我们添加指令以确保only在推送到master时进行部署. 这样，每个分支仍然通过 CI 运行，并且只有合并（或直接提交）到 master 才会触发管道的deploy工作. 将它们放在一起可获得以下内容：

确保在最后一个脚本命令中更新区域和 S3 URL 以适合您的设置. 我们的最终配置文件.gitlab-ci.yml看起来像：

  1. image: node:10
  3. build:
  4.   stage: build
  5.   script:
  6.     - npm i gulp -g
  7.     - npm i
  8.     - gulp
  9.     - gulp build-test
  10.   cache:
  11.     policy: push
  12.     paths:
  13.       - node_modules/
  14.   artifacts:
  15.     paths:
  16.       - built/
  18. test:
  19.   stage: test
  20.   script:
  21.     - npm i gulp -g
  22.     - gulp run-test
  23.   cache:
  24.     policy: pull
  25.     paths:
  26.       - node_modules/
  27.   artifacts:
  28.     paths:
  29.       - built/
  31. deploy:
  32.   stage: deploy
  33.   variables:
  34.     AWS_ACCESS_KEY_ID: "$AWS_KEY_ID"
  35.     AWS_SECRET_ACCESS_KEY: "$AWS_KEY_SECRET"
  36.   script:
  37.     - apt-get update
  38.     - apt-get install -y python3-dev python3-pip
  39.     - easy_install3 -U pip
  40.     - pip3 install --upgrade awscli
  41.     - aws s3 sync ./built s3://gitlab-game-demo --region "us-east-1" --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers --cache-control "no-cache, no-store, must-revalidate" --delete
  43.     - master

在您还可以找到一些样板代码来使TypeScript ， ， Gulp和与 GitLab CI / CD 完美地结合在一起，这是在制作Dark Nova 时汲取的教训的结果. 使用免费和开源软件的组合，我们拥有完整的 CI / CD 流水线，游戏基础和单元测试，所有这些操作和部署都可以在每次熟练掌握的情况下完成-只需很少的代码. 可以通过 GitLab 的构建日志轻松调试错误，并且在成功提交后的几分钟内，您就可以在游戏中实时看到更改.

借助 Dark Nova 从一开始就设置持续集成和持续部署可实现快速而稳定的开发. 我们可以轻松地在单独的测试更改，如果需要，可以在多个环境中测试更改. 平衡和更新多人游戏可能会持续且乏味，但是相信使用 GitLab CI / CD 进行稳定部署会在快速获得玩家更改方面有很大的喘息空间.

Further settings

以下是一些可以进一步研究的想法，可以加快或改善您的流程：

  • 代替 npm
  • 设置可以预加载依赖项和工具（如 AWS CLI）的自定义Docker映像
  • 将转发到游戏的 S3 静态网站
  • 如果您发现小型项目不必要，请合并工作