2.0 への移行のヒント

CircleCI v1.0 のサポート期限の終了が近付いています。まだ 2.0 への移行作業を開始していない場合は、以下にまとめられたヒントとベストプラクティスを確認してください。

1.0 ビルドの最終日は 2018 年 8 月 31 日です。 CircleCI 上で引き続きプロジェクトをビルドするには、すべてのプロジェクトを変換する必要があります。 1.0 のサポート終了の詳細とその他の参考情報については、1.0 の終了に関するページを参照してください。

CircleCI 1.0 と 2.0 で同じプロジェクトをビルド可能
CircleCI 2.0 のセットアップに関するヒント
1.0 から 2.0 への移行のヒント
Python
Ruby
Java

CircleCI 1.0 と 2.0 で同じプロジェクトをビルド可能

CircleCI 2.0 への移行を開始するにあたり、直ちにすべてを移行する必要はありません。 1.0 でプロジェクトのビルドを継続しながら、以下の方法で 2.0 を試用してください。

2.0 のテストのための新しいブランチを作成します。
そのブランチから circle.yml を削除し、.circleci/config.yml ファイルを追加します。
2.0 設定ファイルにそのブランチに対する最小限の処理を記述して、ビルドが成功するまでプッシュします。
動作具合を細かく確認できるように、少しずつ構成を追加します。最初はコードをチェックアウトするだけにし、次に依存関係をインストールし、さらにテストを実行します。その後、依存関係をキャッシュしたり、ワークフローなどの高度な機能を使用したりします。設定ファイルを徐々に作り上げていってください。
すべてが正常に機能するようになったら、新しい設定ファイルを含むブランチを主プロジェクトにマージします。

CircleCI 2.0 のセットアップに関するヒント

steps にリストされたコマンドは、docker セクションで最初にリストされたコンテナ内でのみ実行されます。
こまめにビルドを実行して構成をテストします。そうすれば、何かが壊れても、最後のビルドから何を変更していたかがわかります。
最初はワークフローを追加せずに、正常に機能するビルドを先に完成させます。ワークフローを追加したら、CircleCI アプリケーションの [Workflows (ワークフロー)] タブで、ジョブが実行されているかを確認します。ワークフローの構成が誤っていると、ジョブが実行されなくなり、エラーと共に問題の詳細がアプリケーションの [Workflows (ワークフロー)] ページに表示されます。
設定ファイルはゼロから手動で作成しますが、config-translation エンドポイントを参考として利用できます。
設定ファイルの environment セクションで環境変数を定義することはできません。
- 回避策として、変数を $BASH_ENV にエコーします。
  - $BASH_ENV への変数のエコーは、bash でのみ機能し、sh では機能しません (Alpine イメージには sh のみ)。
bash の if ステートメントを使用して、条件付きでコマンドを実行できます。
- if [ $CIRCLE_BRANCH =master] ; then ./ci.sh ; fi
circleci-agent step halt を使用すると、そのステップで条件に基づいてビルドを停止できます。
- 停止することによって、条件付きで setup_remote_docker を使用できます。
環境変数を定義するだけでタイムゾーンを変更できます。
- TZ: America/New_York
プロジェクトによっては、/dev/shm (たとえば、/dev/shm/project) からビルドを実行すると、速度を向上できます。
- Ruby gems など、共有メモリからロードできないものもあります。その場合は、システム内の別の場所 (たとえば、~/vendor) にインストールしてシンボリックリンクを設定します。
多数のコマンドの前に sudo を付ける代わりに、その実行用のシェルを sudo に設定することを検討してください。
- shell: sudo bash -eo pipefail
通常、Docker ビルドと docker-compose は machine で実行する必要があります。しかし、事前に言語固有のツール (Ruby、Node、PHP など) が必要になる場合は、リモート環境でも十分です。
全体のビルド時間を短縮するために、一部のタスクをバックグラウンドで実行するように設定できますが、リソースの不足に注意してください。
異なる resource_class サイズの方が良い結果を得られる場合があります。サイズを変えて影響を確認してみてもよいでしょう。
$PATH には文字列を設定できます。 Docker イメージの $PATH がわからない場合は、単に実行して echo $PATH を行うか、env の出力を確認します。
イメージの sha は、Spin up Environment ステップで参照できます。イメージをその sha 値にハードコーディングして、変更不可にすることができます。
サービスコンテナをカスタムフラグ付きで実行できます。
- command: [mysqld, --character-set-server=utf8mb4, --collation-server=utf8mb4_unicode_ci, --init-connect='SET NAMES utf8mb4;']
CI でテストランナーを実行するときは、スレッドまたはワーカーを 2 つだけ (または、resource_class を使用する場合はそれ以上) 生成するように構成します。それらは、不正な値に基づいて自動的に最適化される場合があります。詳細については、こちらのビデオを参照してください。

1.0 から 2.0 への移行のヒント

$CIRCLE_ARTIFACTS と $CIRCLE_TEST_REPORTS は 2.0 で定義されていないことに注意してください。
- ユーザーご自身で定義できますが、その場合は mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS を実行してください。
1 つのリポジトリにある Linux と macOS (React Native など) を移行する場合は、2 つの設定ファイルを組み合わせて 1 つのワークフローにする前に、Linux と macOS のそれぞれに 1 つのブランチを開く必要があります。
sudo echo は使用できません。echo 192.168.44.44 git.example.com | sudo tee -a /etc/hosts のようにパイプしてください。
Ubuntu システムと Debian システムではフォントが異なります。
Apache 2.2 と 2.4 では設定ファイルの構成方法が大幅に異なります。必ず 2.2 の設定ファイルをアップグレードしてください。
1.0 によって自動的に推測されていたコマンドと、UI から手動で格納されたコマンドをすべて移行することを忘れないでください。

Python

通常、テストの実行にはファイル名ではなくクラス名が必要です。

Ruby

Ruby ファイルは、AUFS で想定される順序とは異なる順序でロードされる可能性があります。
$RAILS_ENV と $RACK_ENV を test と定義します (1.0 では自動で行われていました)。

Java

Java (アプリ、ツール、サービス) は使用可能な RAM の量を認識しないため、OOM (メモリ不足) が発生する可能性があります。その場合は環境変数を定義する必要があります。それでもメモリ不足になる場合は、コンテナを大きくする必要があります。
- CircleCI のブログ記事「How to Handle OOM Errors (OOM エラーの対処方法)」
Scala プロジェクトのファイル名は長すぎる場合があるため、-Xmax-classfile-name フラグを追加してください。

``` scalacOptions ++= Seq( -encoding, utf-8, -target:jvm-1.8, -deprecation, -unchecked, -Xlint, -feature, -Xmax-classfile-name, 242 <= add here ),

## ブラウザーテストに関するヒント
- テストに再現性がなく、理由なく失敗するように見える場合があります。失敗したブラウザーテストは自動的に再実行できます。ただし、タイミングデータは破損します。
- 失敗したテストのスクリーンショットを撮ると、デバッグが容易になります。
- VNC をインストールして使用できます。 metacity をインストールしたら、VNC 内でブラウザーをドラッグできます。ブラウザーイメージの 1 つから以下を実行してください。
```
  ssh -p PORT ubuntu@IP_ADDRESS -L 5902:localhost:5901 # SSH で接続します
  sudo apt install vnc4server metacity
  vnc4server -geometry 1280x1024 -depth 24
  export DISPLAY=:1.0
  metacity &
  firefox &
```
## Docker に関するヒント
- cron ジョブで Docker イメージをビルドすると、以下のメリットがあります。
  - 毎週、毎日、または必要に応じてビルドできます。
    - API から容易に新しい Docker イメージのビルドをトリガーできるようになります。
  - node_modules のような依存関係をイメージに含めると、以下のメリットがあります。
    - DNS 障害による問題を緩和できます。
    - 依存関係のバージョン管理を行うことができます。
    - ノードリポジトリから消失したモジュールがあっても、アプリケーションの実行に必要な依存関係は安全です。
  - プライベートイメージには、プライベート gems およびプライベートソースキャッシュを含めることができます。
- データベース用のソケットファイルはないため、ホスト変数 ($PGHOST、$MYSQL_HOST) を定義して 127.0.0.1 を指定し、TCP を使用する必要があります。
- CircleCI コンビニエンスイメージまたは公式 Docker Hub イメージを使用すると、イメージがホスト上でキャッシュされる可能性が高くなります。
  - これらのイメージからビルドすると、ダウンロードが必要なイメージレイヤーの数が減ります。
- コンテナの -ram バージョンを使用すると、指定されたデーモンが /dev/shm で実行されます。
- すべてがプリインストールされたカスタムイメージをビルドすると、ビルドが高速化され、信頼性が向上します。
  - これにより、一例として、ビルドを破壊するような不良な更新を Heroku がインストーラーにプッシュする状況を防止できます。
- dockerize ユーティリティを使用して、サービスコンテナが使用可能になるまでテストの実行を待つことができます。
  - https://github.com/jwilder/dockerize
- ElasticSearch には独自の Docker レジストリがあり、そこからプルできます。
  - https://www.docker.elastic.co/
- コンテナに名前を付けることができます。そのため、特定のサービスの複数のコンテナを、異なるホスト名を持つ同じポートで実行できます。
- 特権コンテナをリモート環境および machine Executor で実行できます。
- ベース Docker Executor からリモート環境にボリュームをマウントすることはできません。
  - docker cp でファイルを転送できます。
  - 参照されるボリュームは、リモート環境内からコンテナにマウントされます。
## その他のヒント
- CircleCI 2.0 では、ユーザーの想像力を無限に活かすことができます。
- シェルを Python に設定すれば、YAML で任意の Python を実行できます。
```
  - run:
      shell: /usr/bin/python3
      command:
          import sys
          print(sys.version)
```

``` - bash を上手に活用することで、何でも実行可能です。 for i in {1..5}; do curl -v $ENDPOINT_URL && break || sleep 10; done