こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。AXCの開発環境について質問を受けることが少し重なったので、今回は開発環境と新機能をリリースする際などに行うデプロイ方法について書いておこうと思います。

既に知っている人にとっては一般的な内容ではあるかもしれませんが、こういった自動化の取り組みが遅れているネットワークの分野において、これから自動化が進んでいくきっかけになることを期待し、あえて記事として記載しました。

さて、本題ですが、 AXCを構成するのは以下の2つであると前回記載しました。

• API Gateway
• AXC Client

今回の記事では主にAPI Gatewayデプロイ方法について記載します。

API Gatewayの開発

Githubにリポジトリを置いてgit-flowを参考に運用しています。つまり新しい機能を追加する場合はFeature Branchを作成して開発をしています。以下、流れを記載しますが一般的な内容のため分かっている人は読み飛ばしてください。

1. Feature branchを切る

新しいブランチを切って確認します。

リモートリポジトリとの差分をなくすために最新はPullしておきましょう。

2. 開発作業

実装したい機能を追加していきます。必要に応じて、[WIP]付きの空コミットでリモートへpushしておきます。

3. プルリク・マージ

実装・動作確認を繰り返しながら、プルリクをあげてdevelopブランチにマージします。ここまでdevelop環境で作業をします。

API Gatewayのデプロイ

Deploy環境で開発した内容をProduction環境に反映させます。この環境ではgitのtagを使ってリリースバージョンを管理しています。

Tagはリリースする意思を持ったタイミングで付けるため、このTagをJenkinsに監視させてProduction環境でのテスト・反映を行っています。

Jenkins側の実装

「Github Plugin」を使用しています。ソースコードの管理のみを行うJobを作成しておき、定期的に指定のレポジトリをPollingしFetchを行います。

• Git Repositories -> 高度な設定 -> Refspec

• Git Repositories -> Branches to build

tagがつくとSeen branch in repository origin/tags/v0.7.7のような出力がありビルドが行われます。ビルドが正しく実行された場合、ビルド後の処理として次のビルドに処理を渡します。

各ビルドをチェーンで繋げて、以下の順序でサービス断が起きないようにデプロイを行います。

1. API Gatewayの1台目でdeployの更新をマージ
2. ロードバランサーから1台目を外す
3. masterの更新をAPI Gatewayの動作に反映
4. テスト
5. ロードバランサーに1台目を追加する
6. 1〜5を2台目以降で繰り返す
7. 通知

以上で、API Gatewayの本番環境リリースが完了です。もちろん途中で失敗した場合はその時点で通知がされます。

AXCの開発

API Gatewayと同様です。インフラエンジニアの機能実装だけでなく、issuesやchatなどで把握したリクエストを元に開発がスタートします。

AXCのデプロイ

AXCは各クライアントに実装されるため、各ユーザのタイミングでバージョンアップされることとなります。

まとめ

デプロイを手動で全台頑張るのは非常に手間がかかります。特に自動化を推進するツール自体のデプロイということで、手動で行う作業は極力少なくしていくべきだと考えています。

今後の課題としては、まだテストの面では実装が追いついていないものが残っているため、今度もこの環境を元に環境の最適化を進めていきたいと考えています。

多くのネットワークエンジニアに読んでもらえて、何かの気づきや参考になれば幸いです。