亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

AppVeyorを使ってCI環境構築してみた

艦これビューアで。

.NET用のCIサービス、AppVeyor

てなわけで、AppVeyorです。

元はといえば、このツイートでして。

流れとしては

  1. Grabacrせんせー自動ビルドを願う(多分)
  2. 僕がJenkinsを建てようとする
  3. tanaka_733せんせーに止められる

はい、僕が悪いです。

それはともかくとして。

AppVeyorってのは、ざっくり言うと、.NET用のTravisCIです。もっとざっくり言うとクラウド上におわします執事さんです。いや、Jenkinsではないんですけどね。

かなり.NET特化です。CLIではなく、ちゃんと.NETです。つまり、

  • ホストOSはWindows Server系(デフォルトは2012)
  • MSSQLPowershellなどもしっかりサポート

です。

また説明を聞く限りでは、割とImmutable Infrastructure っぽいです。というのもですね・・・

Every build runs on a fresh virtual machine which is not shared with other builds and the state of which is not preserved between consequent builds. After the build is finished its virtual machine is decommissioned.

とありまして、一回一回、フレッシュなVMを立ち上げて、環境をその場で構築しているようです。なので、設定からInstall用のScriptを書くことができます。これで必要になるサブソフトウェアをインストールするという寸法ですね。

ちなみにお値段ですが、OSSプロジェクト、すなわちGithubなどでPublicレポジトリとして動いている限り、現在のところ無料となっています。個人で遊ぶ分には十分に楽しめそうですね。

さて、んじゃさくっとビルドしてみましょうか、、、と言っても実はすでに@tanaka_733さんが記事を書いていまして・・・

んー、あんまり書くことはないのですが、まぁハマりそうなとこもあるので、車輪を再発明しちゃいましょうか。

目標

目標は、最初に示したようなCIの管理状態を作ることです。こんな感じね。

やっていることは、

  • ビルド状態を示すバッジを表示
  • 各ビルドにおける成果物を保存し、ダウンロード可能に
  • ↑をmasterとdevelopの2つのブランチについて行う

あたりですね。これくらいなら、ものの数分で出来てしまうあたりが、サービス系CIの嬉しいとこですね。んじゃやってみましょう。

まずはビルドだけ

サインアップしてもぞもぞしますと、以下の様なProjectの追加に行くことができます。

見て分かるように、githubタブを選んでると、自分のリポジトリと自分がContributorになっているリポジトリがずらっと表示されます。ここからビルドするプロジェクトを追加してやります。

そうすると、まずはProjectができあがります。このまま、特にいじらなくても単純なプロジェクトならビルドできますが、最低限の設定はしておきましょう。

というわけで[Setting]タブを選んで、[Build]タブをそこから選びます。

設定できるのは

  • Platform(x86とかx64とかAnyCPUとか)
  • Configulation(DebugとかReleaseとか)
  • ビルドするSolution or Projectのパス。rootはgitのrootフォルダになっているのに注意。

です。他のものはほとんどがWebデプロイ向け(一部はNuget向け)なので、一旦無視。

たとえば、AnyCPUのReleaseビルドで、ソリューションファイルを指定するとこんな感じに。

この状態で、新しいコミットがPushされるか、手動でビルドをトリガするかすれば、ビルドが発生します。 とはいえ、この状態では、実は本当にビルドをしてるだけでして、ビルドを壊すコミットがあったかどうかが分かる、くらいになります。

まぁ、以下で示すバッジまで貼れば、なんとなくCIしている感じにはなりますね。

ビルド結果は、[Setting]から[History]に切り替えればみることができます。

バッジを貼る

そのままBadgeタブに移動すると、バッジのURLが表示されます。

ご丁寧にMarkdownまで書いてくれているので、はっつければおしまい。楽ちんですね。

成果物を保存する

「成果物」という形でビルドしたものを残しておかないと、ビルドした結果どんなバイナリができたか、ということができないということになります。 逆にこれだけやっておけば、ひとまず全コミットに対するバイナリを保存しておくことができますので、ぐっとCI回しているっぽくなります。 また、このあとデプロイメントしてテストして・・・ということにも繋がりますね。

成果物の保存は、[Artifacts]タブで行います。基本的には、保存する成果物のパスを指定して、それをZip圧縮したものが保存されます。ファイルを指定すればそのファイル、ディレクトリを指定すればそのディレクトリ以下をZip圧縮します。

例えばKanColleViewerのReleaseバイナリを保持しようと思うと、以下の様な感じですね。

こうしておくと、History画面で、ビルドごとにその成果物を集めることができます。

ブランチごとにバッジやHistoryを作る

さて、デフォルトだとgh-pagesを除く全てのbranchに対して、コミットが入ればビルドが行われHistoryやバッジが更新されます。この運用がいい場面もあるとは思うのですが、例えば安定版ブランチとNightlyブランチは、やっぱ別々に管理しておきたく、なりますよね?

どうするかというと、ビルドするブランチを限定し、複数Projectを作ればよろしい。ビルドするブランチの限定は、[Setting]→[General]で行います。例えば『masterブランチだけ監視してビルドしたい』場合だと、以下のようになります。

これとは別に、developブランチのみ監視するProjectを作っておけば、色々とOKですね。

もっと色々できそうなAppVeyorたん

というわけで、ひとまずさっくり使う分にはこんな感じになります。ですが、AppVeyorたん、まだまだこんなもんじゃありませぬ。こちらが介入できるビルドパイプラインをざっと書き出すと、

  1. FreshなVMを作成

  2. initスクリプトを実行

  3. レポジトリをクローン

    • ビルドするコミットをチェックアウト
    • クローンしたフォルダにcd
  4. installスクリプトを実行

  5. AssemblyInfoを書き換え(バージョン番号などを変更する)

  6. hostsファイルを設定(参考

  7. サービスをスタート

    • 実行するサービスは事前に設定できる
  8. Build

  9. Test

  10. build_successwebhooksを呼ぶ

  11. 成果物をパッケージング

  12. デプロイ

  13. 成功したビルドに対して・・・

  14. 失敗したビルドに対して・・・

    • build_failurewebhooksを呼ぶ
    • deployment_failurewebhooksを呼ぶ
    • on_failureスクリプトを実行

これらのプロセスのほぼ全てをせってしたりScriptを差し込んだりできますので、かなりのことができます。またデプロイは標準で、AWS S3やAzure BLOBなどのストレージ保存サービス、Azure WebなどのPaaSサービスなどにできますし、Deployment Agentを利用すれば、任意のWindowsマシンに成果物を保存することもできます。

また、試していないのですが、おそらくローカルユーザアカウントで動作しているっぽいので、UI系のテストも難なく行えそうな気がしています。

ビルドパイプラインの例としてもなかなか勉強になりますし、これは面白いサービスでしたね。

教えていただいた皆様に感謝!