最終成果物を常に手元に
手を動かす前に
見出しにあるように、執筆している最中でも どのような最終成果物になるのかは こまめに確認しておきたいものです。物理的実体をともなうモノであれば難しいことですが、電子書籍は物理的実体をともなわずに済むタイプの最終成果物です。その特徴を活かすために、ソフトウェア開発で身に着けた技術は大いに活用しましょう。ビルドパイプラインは次の流れで大丈夫なはずです。
- バージョン管理システムに対する変更の反映がトリガーとなる
- 最新バージョンの原稿を取得する
- Re:VIEWのビルドを行う
- 成果物をアクセス可能な場所に配備する
1.については「VSTSのGitブランチへのプッシュ」が該当します。さすがに説明不要でしょう。2.については「ビルドマシンからプル」が該当します。これも説明不要でしょう。3.については「Re:VIEWコマンドの実行」が該当します。ここで注意すべきはビルド環境をRe:VIEWの実行可能な状態に設定しておくことです。VSTSでhosted agentを使用した場合、間違いなくRe:VIEWのビルドはできないため後述の工夫を行う必要があります。4.については「成果物を特定のファイルストレージにコピー」が該当します。VSTSの場合はartifactsが該当します。VSTSに管理させる、自前のファイルサーバーに配置する等の選択肢があります。
ビルドマシンでRe:VIEWを実行するために
アイディアとしては二つ考えられます。ローカル環境でビルドする方法とVSTSが用意している環境でビルドする方法です。
ローカル環境でビルドする
Microsoft/vsts-agentを使用して、ローカル環境からVSTSの原稿を取得し、ローカル環境でRe:VIEWのビルドを行うというのが第一案です。この案の特徴は以下の通りです。
- Re:VIEWセットアップ済の状態からビルドを行うため、実行時間が短縮される。
- ローカル環境を使ってビルドを行うので、VSTSの課金枠をあまり意識しなくてもよい。
- ビルド環境を統一しておかないと環境依存の問題が発生し、同じビルド結果が得られない場合がある。
- 執筆中は常にビルド環境を動かしておく必要がある。
VSTSが用意している環境でビルドする
VSTSでhosted agentを使用した場合、その環境にRe:VIEWのセットアップを行う必要があります。前々回の記事でセットアップ時間が約30分とあったように、CIのたびに時間をかけてRe:VIEWのセットアップを行うのは現実的ではありません。この場合、必然的にRe:VIEWのセットアップ済のコンテナイメージを使ってビルドを行うことになります。この案の特徴は以下の通りです。
- Re:VIEWを含むコンテナイメージの取得から行うため、ビルド時間が長くなる。
- VSTSの課金枠を意識する必要がある。
- コンテナイメージを使うため常に同じビルド結果が得られる。
- ビルド環境のON/OFFを意識する必要がない。
- 適切なコンテナイメージを構築 or 取得する必要がある。
どちらを選ぶ？
上記の特徴を考えると、執筆者一名かつ予算不足の現状ではローカル環境でビルドするのが良さそうです。ただし、ローカル環境のセットアップを標準化する意味ではローカル環境でコンテナイメージを使用するのはありだと思います。一方、共同執筆をするのであればhosted agentとAzure Container Registryを使用してビルドするのが良いでしょう。