1. 初めに
最近 Azure を使うことが多い私ですが、いつも驚かされるのはそのスピードの速さです。
Azure DevOps, Microsoft が力を入れていることがうかがわされるサービスですね。
Microsoft Azure DevOpsがサービス開始されたのは、以下の記事にある通り、2018年9月10日のこと。
www.atmarkit.co.jp
当初触ったときには、まだできたばかりで足らないところも多い感じだったのが、今ではかなり充実していますね。
また、DevOps や CI/CDに慣れていない人向けの学習サイトも充実しているのにも驚かされます。
Azure learn, Azure DevOps Labs など、実際に触って、デモを作って、理解することができるサイトが数多く用意されています。今日は、Azure DevOps Labs の中の一つで、「Deploying a CD pipeline for a Django-based Python app」を実際に触ってみようと思います。
2. Azure DevOps Demoの事前準備
事前準備として、やらないといけないのが、
Azure Accountの準備と、
Azure DevOps Accountの準備。
そのあたりは、こちらのサイトを見て実行。
www.azuredevopslabs.com
3. Azure Demo Generator でプロジェクト作成
まずは、Azure DevOps Demo Generatorで、 Python テンプレートを利用し、Django-based-python Project というのを作成します。
Demo用テンプレートもかなり充実しています。
しばらくすると、処理が完了し、自分の Azure DevOps アカウント上にプロジェクトが作成されます。
こちらにある、オレンジのDマークアイコンがついているプロジェクトが作成されました。
4. Project の設定。
4.1 用意されたテンプレートの確認
まずは、3. で作成したプロジェクトを開き、
左側の Repos をクリックすると、用意されたテンプレートのリポジトリが参照できます。
詳細なフォルダ構成は、こちら。
Application フォルダに、サンプルアプリケーションが展開されており、
Tests フォルダの下には、functional_tests , unit_tests の２つのテスト関連のフォルダも用意されているのがわかります。
4-2. ビルドパイプライン設定
次に、画面左の Pipeline → Builds をクリックすると、Python-CI のビルド画面になりますが、この段階では、ビルドの定義は何もない状態です。
なので、画面右上の Edit ボタンを押して、設定画面を開きます。
そして、画面左の Use Python 2.x を選択し、使用する Pythonのバージョンを設定します。
設定したら、次は、Install-dependencies を選択します。
（ここでは、右側に、コマンドで pip install -r ・・・・とありますが、これは、python のライブラリのインストールコマンド（pip install) で、pythonに必要なライブラリなどをインストールする設定をしています）
次に、画面左の pytest を選択。pytest というのは、pythonを使っている人であればご存知の、python用の単体テスト等の実行コマンドです。画面右に、pytest 自身のインストールと、pytest コマンドによるテストが設定されているのがわかります。
次に、画面左、Publish Test Resultsを選択します。
テスト結果をどういうフォーマットで出力するかが定義されています。
そして次、Archive application をクリックすると、ディレクトリ下のApplication を zip 圧縮する定義が設定されているのがわかります。
そしてその次、Archive Tests をクリックすると、ディレクトリ下のTestsをzip圧縮する定義がされているのがわかります。
その次、Publish Artifact をクリック。Artifacts を publish する定義がされています。
次に、Trigger タブをクリックし、Enable continuous integration のチェックボックスをチェックします。
ここまでを行ったら、画面上部の Save & queue → Save を押して、保存します。
4-3. リリースパイプライン設定。
次は、ビルドパイプラインと同様に、リリースパイプラインの設定を行います。
画面左、Releases を選択し、画面右上の Edit を選択。
表示された、Devの下の、1job 7 tasks という場所をクリック。
次のように、タスクが表示されます
そして、 Azure CLI をクリックし、画面右で使用可能なサブスクリプションを選択後、Authorize ボタンを押します。
すると、Azure へのログイン認証が要求されるので、ログインを実行。
次に、Variables タブを開きます。
Location など、変更が必要な場所を変更。（リソースグループも、先にPythonというリソースグループをAzure上に作っておいた方が良いのかな。。と思い作成しました。）
Tasksに戻り、画面右でInstall Python Extensionsを開き、必要な設定を行います。
- サブスクリプションを設定
- Action は Install Extensions
- App Service Name は $(appservice-name)
- Install Extensions は、Python 3.5.4 x86 を選択
次、Azure App Service Deploy の設定。
こちらも、ほぼ同様。サブスクリプションの設定と、App Servce Name へ $(appservice-name) を設定します。
そして、画面左、Run functional tests を選択。
設定を確認後、Pipeline Tab に戻り、Python-CI のタスクの右上のイナズママーク（Continuous Deployment Trigger)を押します。
画面右、上部の
Creates a release every time a new build is available. を Enable にした後、画面上部の Saveボタンを押してセーブ。・・・と手順には書いてあったんですが、セーブが押せませんね。
Agent Phase の所が設定できておらず、セーブができませんでした。
Agent Phaseの所を設定。ここの解説がなかったので、Agent specificationを適当に、Ubuntuとかにしたら、Pipeline が通りませんでした。正解はvs2017-win2016の模様。
で、セーブ。
4-4. ソース更新、パイプライン実行。
設定のセーブをしたら、ソースを更新して、パイプラインを実行してみます。
修正はまあどこでも良いのですが、アプリケーションには影響のない部分、index.html を修正します。
Repos → Application → templates/app の下にある、index.htmlを選択し、
画面上部のEditを押し、32行あたりにある、Continuous Delivery を Continuous Delivery for Pythonに変更し、画面上部のCommit を押します。
コメントなどは適当にいれ、commit を実行。
画面左のPipelinesを選択、画面右で、実行されているタスクを選択すると、
ビルド＆Ｔｅｓｔフェーズが実行されている状況が見えます。
すべて正常終了した画面がこちら。
ビルド＆Ｔｅｓｔが正常終了したので、画面左の Pipeline → Release を見てみると、同じようにリリースパイプラインが動いているのを見ることができます。
すべて正常終了した画面がこちら。
ちゃんとリリースした後の Functional Test では、Seleniumを使ったテストも実行されていますね。素晴らしい。
そして、リリースが終了したということは、Azure の Python リポジトリ上に、アプリケーションがデプロイされているということです。Azure の方を見てみましょう。
4-5. Azure で、デプロイされたアプリを確認
Pythonリポジトリを見てみると、ちゃんとアプリケーションがデプロイされていますね。
デプロイされた App Service をクリックし、
AppServiceの画面上の 'Browse’メニューをクリックしてみると、
デプロイされたアプリケーションが表示されます。
ちゃんと修正したた部分も、「Continuous Delivery for Python」と表示されていますね。
5. 感想
さて、今回 Azure DevOps Labo に載っている、Demoを実行しただけですが、サンプルが非常に良いですね。
Python の Djangoという Webフレームワークのアプリケーションを AppService にデプロイして実行しているんですが、ちゃんとビルド、ユニットテストを実行し、出来上がったものに関しても、デプロイし、Seleniumを使った 機能テストも行っています。
とても良いと思うのは、こういったテンプレートを使ってアプリケーションを学んだ人は、ビルド時の Unit Test, リリース時の 機能テストは当然やるのが当たり前という習慣を持つことができそうな点です。
30年以上この業界で働いていますが、まだまだ自動Functional Test どころか、Unit Test すら当たり前に実施しているプロジェクトがどれだけあるかはちょっと疑問を持ったりしています。
（10年くらい前に、某プロジェクトに新しく入った時に、単体テストくらいはやった方が良くないですか？と言ったら、Unit Test を書くのであれば、コードが約2倍になりますから、2倍発注してくれないと仕事を受けられないという答えが返ってきて愕然としたのはまだ覚えてます（笑））
うちの会社の中でもこういったテンプレートを利用する人が増えて、単体テスト、機能テストは実施するのが当たり前になり、技術も品質も上がっていくのを期待しております。
