先日dynamics 365のコミュニティで、Azure DevOps Pipelineに関する話題を見つかりました。
上記の記事で書かれたのは、dynamics 365のプロジェクトにおいて、DevOps開発手法も使えるという話であり、関心が高まっていました。
一般的なシステム開発では、ソースコードしか扱われていなく、GitHubやBitbucketなど、ソースコードのバージョン管理ツールを使っています。ブランチから切って、「チェックアウト→コーディング→コミット（チェックイン）→ビルド」というルートは当然のことでした。
ただ、dynamics 365 プロジェクトにおける開発では、カスタマイズの部分（フロー、ビジネスプロセスフロー、ビジネスルール）と、開発の部分（プラグイン）があり、ソースおよびバージョン管理が複雑になっています。
記事が主張したことは、システム開発でよく使われるDevOpsはdynamics 365にも適用できることであり、その経緯や理由などを解説してみていきたいと思います。
DevOps、CI/CDとは
まず、DevOpsの概念はこちらでおさらいしましょう。DevOps とは – Azure DevOps | Microsoft Docs
開発 (Dev) と運用 (Ops) の複合である DevOps は、顧客に継続的に価値を提供する人、プロセス、テクノロジの和合です。
DevOpsの基本的なプラクティスには、アジャイルプランニング、継続的インテグレーション、継続的デリバリー、アプリケーションのモニタリングなどがあります。
DevOpsではよく言われる概念の1つはCI・CDです。
「Continuous Integration/Continuous Delivery」と言い、継続的なインテグレーション・デリバリーを示しています。
開発者やテスト担当者が、構造化された環境で、より早く、より安全にソフトウェアを出荷できるようにするというアジャイル開発の思考です。
dynamics 365 Solution解説
dynamics 365のカスタマイズ開発においては、すべでの成果物はSolutionに包まれる。開発段階では、Solution自体は修正可能であり、unmanaged Solutionの状態になります。修正、テストが終わり、一旦プロダクト環境へプッシュしたら、unmanaged Solutionはmanaged Solutionに変わり、1個丸ごとのパッケージとして見られています。
生成されたSolutionをエクスポートすると、Zipファイルが出てきます。そして、中身の構造は以下のようになります。プラグイン、Webリソース、ワークフローのフォルダーがあり、カスタマイズして生成された内容は中に包まれている状況です。
アンパックされたソリューションの粒度の高さは、チーム開発に最適です。開発者は、リポジトリからソリューションをパックして様々な開発環境にインポートし、変更を加え、エクスポート、アンパック、そしてソリューションをリポジトリにコミットすることができます。
Solution Packagerは、マージコンフリクトを完全に取り除くことはできませんが、その管理は容易ではあります。
Azure DevOps
Azure DevOpsは、「Boards, Repos, Pipelines」といったサービスが含まれます。
| Boards | Repos | Pipelines |
| チケット・タスク管理ボード | バージョンコントロールのツール | 継続的にビルド、テスト、デプロイ可能のツール |
これらの開発者向けのサービスを提供し、チームが作業計画を立てたり、コード開発を共同で行ったり、アプリケーションをデプロイすることをサポートします。また、IDEであるVisual Studioとの連携もしております。環境により、Visual StudioからAzure DevOpsへのルートも少し違います。
| 環境 | Visual Studio | Azure |
| オンプレミス | TFS：Visual Studio Team Foundation Server | Azure DevOps Server |
| クラウド | VSTS：Visual Studio Team Services | Azure DevOps Services |
dynamics 365 SolutionとAzure DevOps Pipelinesを活用
ここまではD365のSolutionとAzure DevOpsの説明を行いました。
dynamics 365 Solutionは開発の部分とカスタマイズ部分が含まれており、Azure DevOps Pipelinesを活用して、DevOpsを実現する方法を説明します。
1、開発環境では、開発チームと要件定義チームは色んな作業を行いSolutionが生成された。
2、プラグインといった開発のコードをパッケージとして包まれ、トリガーとしてAzure DevOpsが認識され、Pipelinesが始まります。Pipelinesでプラグインのソースをチェックアウト、チェーンイン、ビルドの自動化デプロイ処理を行い、生成されたSolutionのプラグイン(開発)部分は開発環境に反映されます。
3、ワークフローといったカスタマイズの部分は既に開発環境に反映されている状況です。つまり、Out Of Boxのカスタマイズはコーディング開発と違い、Publish出来た時点ですでに開発環境にデプロイしたのです。これまでは、開発環境へのデプロイは完了となり、開発環境での単体テストが行えるようになります。
4、開発環境にテストが終わったSolutionをステージング環境（またはUAT環境）にデプロイして、UATテストを行います。
5、単体テストが終わったSolutionをエクスポートして、UAT環境にインポートする。そこで丸ごとのSolutionはUAT環境に入れるようになり、UATテストが可能になる状況です。
まとめ：
Azure DevOps Pipelinesの役割は、dynamics 365 Solutionのコーディング部分（例えば、プラグイン）をトリガーとして認識し、自動的に開発環境にデプロイすることです。
また、Solutionを開発環境からUAT環境にデプロイする際に、手動でエクスポート、インポートを行う必要があります。
上記は必ずしもベストプラクティスではありませんが、ロジックは明確であり、管理がしやすいと考えています。
コメント