誰も信用しないで、誰も信用しないでください.サーバ開発者は常に疑って準備しなければならない.誰も信じていないので、信頼できるサーバを作成します.
コンピューターは盲目だ.間違いなく、マスターが作成したコードを実行します.自分でさえ間違いを犯す.プログラムの作成中にパソコンや他の電子機器が停止したという驚きの経験があります.

もし私たちが作成したWebサーバに欠陥があったら?サーバ開発で最も避けたいのは、500エラーがユーザーに露出することです.このような事態は防止しなければならない.つまり、サーバが実行される前に、欠陥が発見されるはずです.でも、どうしよう?

テストの自動化

テストオートメーションによって論理を確認することです.このコミットが既存のサーバを破壊しないという人を信じないでください.自動化されたテストで一貫性を検証するシステムを構築し、失敗した場合、サーバは受け入れられません.

自動化ツールの使用

そのためには、github actionやtravis ciなどの自動化ツールを用いることが望ましい.また、codecov等により試験カバー率等を確認することもできる.
https://github.com/typelevel/cats/pull/3754のような例を見てみましょう.既存のコードとの一貫性を確保するために、複数の環境でテストを行います.

Githubから動作

ドッキングステーションの利用

現在稼働しているプロジェクトでは、最も簡単なgithub actionを使用してテスト自動化環境を構築しています.既にDockerが使用されているため、テスト時にも既存の画像の使用が開始される.
github actionのyamlファイルの一部を修正します.

jobs:
  # Run tests.
  # See also https://docs.docker.com/docker-hub/builds/automated-testing/
  test:
    runs-on: ubuntu-20.04

    steps:
    - uses: actions/checkout@v2

    - name: create dotenv
      run: echo "${{ secrets.DOTENV }}" > project/.env

    - name: Log into GitHub Container Registry
      run: echo "${{ secrets.TOKEN }}" | docker login https://docker.pkg.github.com -u ${{ github.actor }} --password-stdin

    - name: docker build
      run: docker-compose build

    - name: test
      run: docker-compose run test

docker-composeファイルは次のとおりです.

version: "3.7"

services:
  # 테스트를 위한
  test:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - DJANGO_SETTINGS_MODULE=settings.${DEPLOY_STAGE:-dev}
    env_file:
      - project/.env
    working_dir: /root
    command: python manage.py test --keepdb
  # 배포를 위한
  rest-server:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - DJANGO_SETTINGS_MODULE=settings.${DEPLOY_STAGE:-dev}
    image: docker.pkg.github.com/<path_to_image>
    ports:
      - "8000:8000"
    env_file:
      - project/.env
    working_dir: /root

ドッキングファイルは次のとおりです.

FROM docker.pkg.github.com/<path_to_image>
WORKDIR /root
ADD project .
RUN pip install -r ./requirements-dev.txt

上記のシステムにより、テスト自動化が構築されました.十分なテストケースがある場合は、少なくともこれらのシステムは安全です.

ドッキングを使用しない

今回は画像がなく、github action容器で直接テストを実行しました.まずlocalhostを使用するため、環境にCI用のファイルを作成します.

# settings/ci.py
from .base import *

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "github-actions",
        "USER": "postgres",
        "PASSWORD": "postgres",
        "HOST": "localhost",
        "PORT": "5432",
    },
}

そして動作を修正しましょう

test:
    runs-on: ubuntu-20.04

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: github-actions
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    steps:
    - name: checkout code
      uses: actions/checkout@v2

    - name: Cache dependency # caching dependency will make our build faster.
      uses: actions/cache@v2 # for more info checkout pip section documentation at https://github.com/actions/cache
      with:
        path: ~/.cache/pip
        key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
        restore-keys: |
          ${{ runner.os }}-pip-
    - name: create dotenv
      run: echo "${{ secrets.DOTENV }}" > snulife/.env

    - name: Setup python environment # setting python environment to 3.x
      uses: actions/setup-python@v2
      with:
        python-version: '3.8.5'
        
    - name: Install dependencies
      run: pip install -r requirements.txt

    - name: migrate and test
      run: |
        python manage.py migrate
        python manage.py test
      env:
        DJANGO_SETTINGS_MODULE: settings.ci

ドッキングステーションに既に存在するpostgres画像、health check画像をコンテナ内で実行します.このプロシージャを実行しないと、データベースが実行される前にテストを迂回しようとし、失敗します.上記のコードはPostgreSQLで記述されていますが、他のデータベースでも同様のコードを使用できます.

- name: Cache dependency # caching dependency will make our build faster.
  uses: actions/cache@v2 # for more info checkout pip section documentation at https://github.com/actions/cache
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
    restore-keys: |
      ${{ runner.os }}-pip-

この部分はpip依存性管理でキャッシュを使用します.もちろんスピードを上げるためです.

- name: migrate and test
  run: |
    python manage.py migrate
    python manage.py test
  env:
    DJANGO_SETTINGS_MODULE: settings.ci

最後に、移行とテストを行います.インストールモジュールを指定するために、環境変数はDJANGO_SETTINGS_MODULE: settings.ciで、この部分は自分の項目に応じて適切に変更されます.

結び目。

テストを自動化するだけで、システムの安定性を確保できますか?答えは否定的だ.何度テストを行っても、システム自体の安定性は保証されません.
テストは帰納法にかかわる.つまり、私が毎朝何度も太陽の昇りを確認しなくても、明日の朝太陽が昇るかどうか分からないのと同じです.
ソフトウェアが安全かどうかをより直接決定するには、より高いレベルの議論、すなわちタイプネットワークが必要です.しかし,静的タイプの導入は単純な議論ではない.言語を変え、枠組みを変え、組織全体の認識と思考構造を変えるからだ.
これに対する議論はひとまず棚上げにする.github actionを使用してテストと導入を自動化することから始めましょう.