ASP.NET Core MVCのプロジェクトの.NET Coreを2.1 RCにアップグレードした

 このブログでバックエンドに使っている.NET Coreのバージョン2.1がRelease Candidateまで来た。ここらでアップグレード準備をしておくことにした。
 このブログのバックエンドになっているプロジェクトは、Dockerコンテナに入ったASP.NET Core MVC使用のアプリで、TravisCIにてコンテナのビルドとテストまで行われる構成になっている。


 やってみると、参考になるドキュメントさえあれば一時間足らずで終わるものだった。アップグレードのための変更点は、プレビューの時点のもので抑えておくことで問題なかった。
ASP.NET Core 2.1.0-preview2 now available


 具体的な変更としてまず最初にコミットへのリンクを置いておく。
https://github.com/hMatoba/tetsujin/commit/3bc013f237007c64008dc41adb81f14d1384792c


 ここから行った変更について書いていく。まず開発環境に.NET Core 2.1(RC)のSDKをインストールする。
https://www.microsoft.com/net/download/all

 つづいてVisual Studioで、プロジェクトエクスプローラで対象プロジェクトを右クリックして、プロパティからターゲットフレームワークを.NET Core 2.1に変更する。



 同じくプロジェクトエクスプローラで対象プロジェクトを右クリックして、「NuGetパッケージの管理」を開いて、プレリリースを含めるにチェックを入れて導入済みパッケージで必要なパッケージのアップグレードを施していく。

 C#コードをちょっとだけ変更。
Program.cs

public class Program
{
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>();
}


 Startup.csの該当箇所を変更。
services.AddMvc();

  ↓
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);


 Dockerfileで使うコンテナを変更。これまではmicrosoft/aspnetcoreをつかっていたが、これは廃止されてmicrosoft/dotnetでタグ分けで配布されるようになるというハナシ。
https://blogs.msdn.microsoft.com/webdev/2018/04/12/asp-net-core-2-1-0-preview2-now-available/#user-content-deprecating-aspnetcore-and-aspnetcore-build-docker-images
Dockerfile

FROM microsoft/dotnet:2.1.0-rc1-aspnetcore-runtime


 さいごにTravisCIの設定YAML。使用するdotnet CLIを2.1対応のものに変更する。
.travis.yml

dotnet: 2.1.300


 いわゆるフレームワークのアップグレードを実行した。変更箇所が少なかったのがありがたいところ。一方で、動作を保証したいところには自動テストを組んでたことがやはりよかった。最低限の動作が壊れないことに加え、どこを変更すべきかという勘所をつけることができた。
comment: 0

TravisCIで環境にPython3(3.6)を入れる

 TravisCI上でSeleniumを使ってテストがしたい。テスト対象のアプリはC#で書いているが、経験上C#でSeleniumを動かすのきっつい。Pythonのほうが好み。Pythonを使う。
 TravisCIでコマンド”python”を打つと、Ubuntu環境だから現在はPython2.7が立ち上がる。でもいまはもう3系を使いたい。もう3.6でいく。ライブラリも入れたいからpipも用意する。
 .travis.ymlに下記を追加。
.travis.yml

addons:
apt:
sources:
- deadsnakes
packages:
- python3.6
- python3-pip


 ↑の追記によって、環境準備のタイミングでaptを使ってパッケージを入れてくれる。
https://travis-ci.org/hMatoba/tetsujin/builds/370164937#L510


 あとは普段のUbuntu環境を使うかのごとく、”python3”、”pip3”。
pip3 install requirements

python3 setup.py test
comment: 0

このブログの技術的なところの暫定まとめ

 Dockerやら自動テスト、継続的デプロイなどなどを個人的に試すプロジェクトとなっているこのブログ。ここ最近施したことと考えを書いておく。

デイリービルドならぬウィークリービルド
=================================
 このブログのバックエンドは.NET CoreのC#で、ビルドされたDLLをDockerコンテナにつっこんだもの。ビルドが必要。.NET Coreはまだ出てきてそれほど間がないので、バージョンアップが活発。
 まだまだまだDockerでやることはあるので、このブログの開発は続行していく。ただ単におもしろいという理由もあるが。だから.NET Coreのバージョンアップは積極的に追う。そうすると、デイリービルドをしておけばどのバージョンで問題が出たかわかって、それがわかればバージョンの変更点をチェックすることで修正箇所の把握が簡単になる。
 デイリービルド、まあちょいとした都合で頻度をウィークリーに落として行ってる。TravisCIで。ビルドということでDockerイメージのビルドまで行ってバージョン番号をタグにつけてDockerHubにプッシュしている。デイリービルドにするとDockerHubで容量を浪費しそうなのでウィークリービルドにしている。

コントローラからOAuthの処理を切り出した、モデルではない何かに
=====================================================
https://github.com/hMatoba/tetsujin/commit/3bbdddc9413b785a601069e401b035d1342beb41
 OAuthの処理は状態がいらんと思っている。OAuthでユーザ情報を持って帰ってきたら、あとはすでに実装してあったUserモデルなりSessionモデルに任せる。OAuthでやるのは、ユーザ情報を持ってくること。そういうわけで、それをやってくれる処理をコントローラから外に出し、モデルとは別のオブジェクトに入れて、コントローラにDependency Injectionで渡した。
comment: 0

TravisCIからのテスト成功時の自動デプロイの書き方がまずかったので直す

TravisCIでGitHubフローをやるために、masterブランチの場合のみデプロイする。
 以前に、TravisCIから、テスト成功時に自動でデプロイするためにスクリプトを書いた。
# !/bin/sh -x

if test "$TRAVIS_BRANCH" = "master"; then
doDeploy
else
echo "$TRAVIS_BRANCH branch"
fi


 上記のは条件が一つ足りていなくて危なかった。masterへのコミット時にTravisCIでのビルド成功時に実行されるが、masterにプルリクを投げた時も同様にビルド成功時にスクリプトが走ってしまう。プルリクをはじかなければいけない。
# !/bin/sh -x

if [ "$TRAVIS_BRANCH" = "master" ] && [ "$TRAVIS_PULL_REQUEST" = "false" ]; then
doDeploy
else
echo "$TRAVIS_BRANCH branch"
fi
comment: 0

Github - TravisCI - DockerHub連携

 Webアプリをコンテナに入れて、それで運用できるようにしておくのが昨今のお気に入り。環境構築とか管理を手軽に済ませたいので。
 API keyなどのパブリックにしたらまずい情報は環境変数から読むようにしているので、コンテナを含めたもろもろのコードはGithubでパブリックにして管理している。結果物として出てくるDockerイメージは、これまでは手元でビルドしたものを自分でDockerHubへプッシュしていた。はい、自分でDockerHubにプッシュするのめんどい。


Github - DockerHub連携を使う
============================
Docker Hubを使ってGitHubにあるDockerfileからimageを自動生成する
 手っ取り早い。

CI環境でビルドしてDockerHubへプッシュ
=====================================
 たとえばTravisCI上でDockerイメージをビルドし、そいつをDockerHubへプッシュする。GithubとDockerHubの直接の連携より手間は増えるが、テストが可能になる。少し前、GoogleがDockerイメージに対するテスト自動化フレームワークとか公開してたし。

 TravisCIを使ったDockerHubへの自動プッシュの組み方を。TravisCIの前段にはGithubがあり、リポジトリの変更でTravisCIにコードが渡るように連携しておく。そしてTravisCIのSettingsの環境変数に、公開されないようにDockerHubのアカウントとパスワードを入れる。
 .travis.ymlを書く。以下のように書いたが、わりと最小構成に近いと思う。タグでTravisCIのビルド番号を使ってバージョンを変更しつつ、latestとしてもプッシュしている。テストは入れていない。
.travis.yml

services:
- docker

script:
- docker build -t matoba/cdcc:${TRAVIS_BUILD_NUMBER} .

after_success:
- docker login -u="${DOCKER_USERNAME}" -p="${DOCKER_PASSWORD}"
- docker push matoba/cdcc:${TRAVIS_BUILD_NUMBER}
- docker tag matoba/cdcc:${TRAVIS_BUILD_NUMBER} matoba/cdcc:latest
- docker push matoba/cdcc:latest


実行結果




 また開発の手間を一つ減らすことができた。
comment: 0