![自己紹介 髙尾 哲朗
システム構築のプロセス評価、改善、策定、開発フレームワークの設計、実装管理、プリセールスや
プロジェクトの立ち上げなど
ブログ ：http://blog.processtune.com
プロフィール ：Tetsuro Takao on
Facebook, Twitter or http://mvp.microsoft.com
コミュニティ ：.NETラボの運営スタッフ
https://dotnetlab.connpass.com/
Microsoft MVP：Developer Technologies
[July 2010 – June 2019]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (17)
Similar to Cdci for asaserviceera
Similar to Cdci for asaserviceera (20)
More from Takao Tetsuro
More from Takao Tetsuro (20)
Recently uploaded
Recently uploaded (12)
Cdci for asaserviceera
- 1. As a Service時代のCD/CI As a Service時代の 継続的インテグレーションと継続的デリバリー Continuous Integration Continuous Delivery
- 2. 自己紹介 髙尾 哲朗 システム構築のプロセス評価、改善、策定、開発フレームワークの設計、実装管理、プリセールスや プロジェクトの立ち上げなど ブログ ：http://blog.processtune.com プロフィール ：Tetsuro Takao on Facebook, Twitter or http://mvp.microsoft.com コミュニティ ：.NETラボの運営スタッフ https://dotnetlab.connpass.com/ Microsoft MVP：Developer Technologies [July 2010 – June 2019]
- 9. これからのシステム開発BtoXとは BtoXはBtoBtoCやBtoBtoBの商流のための製品開発の総称 基本的にはB （Data API→）toB（toCやtoBに情報サービスを提供→） インターフェイスはREST API（JSONが主流） ビジネスユースなので継続的インテグレーション、継続的デリバリーが必須 昨年の振り返り内容は一層加速している
- 10. 継続的デリバリーの具体例 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更
- 11. Microsoft Azure DevOpsの場合 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更 Microsoft Azure DevOps
- 12. Jenkinsのイベントトリガーで各種連携 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更 Selenium WebDriver
- 13. Jenkinsとコンテナ・オーケストレーション 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更 Container Orchestration Azure Kubernetes Service Container Repository Azure Container Repository
- 14. 設計とインプリメンテーション 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更
- 15. 設計 実装 ビルド 試験 デプ ロイ 統合 検証 スロット 変更 Microsoft Azure DevOps WebアプリケーションのCD / CI
- 20. Build Pipelines
- 21. Commit & Push
- 26. ブロックチェーン方式のUniversal Resolver DIF Universal Resolver DID Document DID Document アリスは最近大学を卒業しました。 彼女は、卒業証書のデジタルコピー（彼女の DIDに対して大学が発行した）を要求できま す。 彼女は、卒業証書の発行者、発行時期、およ びその状態を独自に確認できる潜在的な雇 用者などだれにでも卒業証書を提示すること を選択できます。
- 30. Visual Studio
Editor's Notes
- 本日は継続的インテグレーション／継続的デリバリーのお話をします。 モダンな開発プロセスとそうでない従来型の開発プロセスを比べると ・従来のシステム開発手法のコストはウォーターフォール的にシステムを作り5年経ったらシステムを更改する、または刷新するというコストに比べ ・モダンな開発プロセスのコストはアジャイル開発手法でプロジェクト推進をするシステム開発がマイクロサービスアーキテクチャで設計された場合のコストですから、圧倒的にモダンな開発手法を選択した方が良いにも関わらず従来型の開発プロセスを続けている企業はたくさんあります。 この2つを比較すると十数倍のコストの開きがあるにも関わらず、日本でモダンな開発プロセスがあまり進まない理由として考えられるのが まずは、IT産業の構造が固定化されており大手企業が見積しやすい従来の開発手法による受注案件の割合がまだ高い傾向にあるという点。 また発注側にしても社内稟議の通りやすい従来型の提案を採用する傾向があるという点が考えられます。 本日は、モダンな開発プロセスを選択した場合、プリセールスから開発、運用までをどのように継続的インテグレーションし、継続的配置をしていくのかについてお話ししますので、モダンな開発プロセスを積極的に採用するための手掛かりとなるかもしれません。
- でははじめましょう。自己紹介をよむ
- 毎度のことですが…スライドを読む
- 昨年のセッションにて、日本のクラウドコンピューティングの採用率は16.9%であり、残りの80%以上の企業へのクラウド投資は行われていないというお話をしました。そしてそれは、海外の企業が日本の市場に目をつけているという話をしました。これにより様々な変化が起きてきているという話をしました。まず↓ 【Inputが変化している】Realmやドメインという業務上の概念は、物理サーバーやシステム都合によって配置や改修頻度が制限されるべきでなく、今まではたまたま物理サーバーに構築され、5年に1度の更改や新規載せ替えが行われることが多かっただけです。これはSDS/SDNに置き換わって仮想化され物理的な障害はソフトウェアの稼働にほぼ関係は無くなってきている（もちろんそのように構築する必要はありますが）。また、業務に利用するデータの一部はクラウドのものを利用したり、システムの一部の機能をWeb APIとマッシュアップするといった流れが増えつつあります。たとえばOffice 365を導入している企業は認証機構をわざわざ作らず、Graph APIの認証機能を利用しスコープとしてOffice 365上のカレンダー、メール、ドキュメントへのアクセス制御を行うのがスタンダードになってきています（実際そういうように作り変えてくれという案件とか、Azure Active DirectoryとOffice 365の設計といった案件は増えてます）。つまり、システムで扱うデータのうち社内の物理ストレージに保存されているものとクラウドから引いてきているものの比率はどんどん変化してきています。このようなインプットの変化は、同時にシステムが扱うデータの増え方が予測しにくいという特徴があり、システムが安定稼働するためのネットワークのスループットやストレージの大きさについて最適化を想定し設計することが困難です。そのため垂直スケールや水平スケールスケールを計画する必要があってクラウドシフト、クラウドリフトの案件も増えてきています（実際にクラウドシフト、クラウドリフトの案件に携わった方はおられますか？）。予想しにくいものの代表的なものに「GPUを使ったAIの計算量」とか「IoTのセンシングから上がってくるコグニティブデータ」とか「ブロックチェーン方式で転送されるハッシュ履歴付き情報」などがあります。これらの多くはクラウドファーストで設計することでその最適化を実現する傾向があります。
- 次に↓ 【Outputが変化している】マルチディスプレイ、スクリーンレス、マルチデバイスを意識しておく必要があるという話をしました。マルチディスプレイのOutputはメディアクエリなどのスキルを必要とするようになりましたし、アウトプットはディスプレイに限らず機器やアプリケーションに向けたAPIに変化してきました。 アウトプットの見た目には業務が大きく影響しますが、As a Service時代のBtoXではアウトプットするデータがビジネスを産み、そのデータをどう見せるかが別のビジネスを産みます。我々の仕事はディスプレイに業務として成り立つ情報を伝送するという形から、どのような使われ方をするのかとは関係なく相手が求めるデータを的確に、必要に応じてリアルタイムに汎用的な手順で送信するという形に変化しつつあります。または、それを利用する側として汎用的な手順で送信されてきたインプットから業務として意味のあるUIを提供する側の仕事も従来のとおり残っていくとは思いますが、その比率は明らかに下がっていきます。それらの仕事はOffice 365やSalesforce CRM、Wordpress CMS、TableauやSAPのBIなどによってエンドユーザー自ら行えるようになってきているからです。
- その意味では↓ 【Proceedingを完全分離する】というお話もしました。AIにおける機械学習の話を例にして、特徴データを算出するモデルは再学習を繰り返すのですが、モデルの学習のインプットデータはある程度ゴミを取り除く必要があり、インプットとなるデータを収集機能とフィルター機能、モデルの再学習といった機能は同じシステムとしてオーケストレーションを行うものの同居する必要は無く、また同居させて動かせるハイパワーなコンピューティングを構築する必要もありません。これらのプロセッシングはAWSのLambdaやAzureのFunctions、Google Cloud Functionsなどによって完全に分離され、時にはデータに重みづけを持たせるためエッジとして分割されることもあります。AIの実体となるニューラルネットワークは、ノードをレイヤー化した深層学習用のものや可変長の入力に耐えうるための双方向型の長短記憶再帰型ニューラルネットワーク、固定長を得意とする畳み込み型のニューラルネットワークなどがあります。このデータネットワークはデータストアでもありますが、基本的には傾向や相関を算出し、関係性をトレーニングし得られるモデルから入力に対してランキングとインデキシングを行うことを目的としています。つまり、ため込んだデータが重要なのではなくため込んだデータからモデルが生成されたらそのパラメータの重みづけが重要となります。このようにプロセッシングは入力→フィルタリング→整形→ニューラルネットワークへ投入→特徴データの再算出→パラメーターの重みづけ再定義→新モデルによる再計算という機能群のオーケストレーションであり、分割され全く別レイヤーで実行されることでサーバーレスコンピューティングとしての意味を持ちます。 プロセッシングを完全に分離するというのは、このように「その計算はいつ必要か？」を視点に分離することです。AIも一つのニューラルネットワークでなく、目的に応じた複数のアプローチによるAIから得られる結果をどこに、どのタイミングで、どのように配信するかがドメインとなります。従来のシステムのプロセッシングをこのように完全に分離するとインプットやアウトプットが変化してきている現在のビジネス要求に対応できるシステムになります。
- 続いて↓ 【クラウド時代のIT戦略】では、実際にビジネスの決定はどこで行われるのか？という話をしました。ディシジョンメイキングの話です。従来のビジネスが日々のデータをデータベースにため込んで1か月後にビジネスの成果レポートを作成し、経営会議で6か月前からの傾向を見ながら経営判断を下していくことが無くなるとは思いませんが、なにせ遅い。現在ではPCの画面や紙のレポートに出力していた経営分析の結果はCRMやCMSなどでデータは見える化していますし、定型的な分析であればBIツールを使ってエンドユーザー自身が行えます。また、リアルタイムに音声やモバイルに通知が来ますし相関や傾向から何かしらの可能性を提示するAIもあります。ディシジョンメイキングの種類によって現場でのディシジョンメイキング（Data-driven decision management）できることがあり、クラウドとAIを組み合わせることで6か月前からの傾向を見る必要のないディシジョンメイキングはそのメイキングプロセスを作ってしまうことでビジネススピードをあげることができるというお話でした。 では、そのプロセスはどのように作成していくか？というのが次のお話しになります。
- 【MS Graphと機械学習】では、Microsoft Graphの紹介とIntelligent cloud and Intelligent edgeのお話し、チャットボットなど機械学習のインターフェイスが用意されていることを紹介しました。Microsoft Graphの話は後ほどしますのでここは割愛します。 機械学習を例に現場でのディシジョンメイキングのプロセスの作成をお話しします。 インプットとアウトプットが変化することに対応するためにプロセッシングを完全に分離分割した場合、稼働レイヤーが異なるため必然的にマイクロサービスになります。マイクロサービスの特徴のひとつにシステム要件の変化に強く、アジャイル開発との相性が良いという特徴があります。これは永続化層でのステートの共有を行っておらず、ステートフルミドルウェアとして、マイクロサービス間でステートマシンを形成することによって実現できている特徴です。もちろんバーチャルアクターパターンで設計されている必要があるのですが、バーチャルアクターパターンのインプリメンテーションは多々あり、Azure FunctionsやGoogle Cloud Functions、AWS Step Functionsはそのインプリメンテーションの上で稼働するサーバーレスコンピューティングの実行環境です。 この実行環境を使うことでディシジョンメイキングのプロセスを作成することができます。 ディシジョンメイキングは経営層、意思決定層が長・短期の経営状況と市場などの現況を鑑みながら経営のある要素について決定することです。PCの画面や紙面のレポートでは、その決定に必要な要素を取りまとめる、集計する、時系列に並べる、掘り下げるといったことを決定の事前に用意する必要があり、マイクロサービスとしてそれらを実装、必要に応じてステートフルに組み合わせることで意思決定に必要な要素を必要になった時点で用意することができます。これは事前にプログラムしている必要のないプロセスであり、従来のシステムはその部分をプログラムしていました。
- これからのシステム開発はこちらが主流になっていくのだろうと感じています。
- 継続的配信、継続的統合はMicrosoft Azureがもっともシンプルに実現できると私は考えていますが、JenkinsやGitHub、Dockerもそれぞれ個別にCD/CI機能を拡張しています。 どのようなツールを使うにしても、重要なのはProject管理とソースのバージョン管理、デプロイとテスト、プロダクションリリースといった作業を同期させ、いかに次のイテレーションにつなげていくかがCD/CIの肝となります。次のイテレーションで重要なのは、機能拡張の計画や運用時のモニタリングやインサイト、利用のトラッキングなどによってシステムの挙動を修正することも含まれます。
- 例えばAzure DevOpsの場合、Visual Studioとの連携は、ローカルリポジトリからコミット、プッシュ、プルリクでMicrosoft Azure DevOpsのReposにリモートリポジトリとして同期され、PipelinesでBoardsのワークアイテムやTest Plansの各種試験とつなげることができます。これによってイテレーションに定義されたバックログのタスクやワークアイテムとバージョン管理されたソース、テストと配置が同期します。
- JenkinsとGitHubの連携では、Visual Studio - GitHubの流れからGitHubの更新を検知しJenkinsがGitHubに最新ソースを要求、取得後Build、セレニウムでテストしステージングWebにデプロイ、シナリオテストを行ってJIRAのタスクと連携した後にプロダクションWebに配信するといった流れや、Visual StudioからJenkinsのMS Build Plug-inで連携するといった流れを構築することができます。
- Dockerを使う場合、コンテナオーケストレーションツールを使うのが一般的ですので、KubernetesやAzure Kubernetes Serviceを使ったCD / CIやDocker HubとJenkinsを連携させる方法などが考えられます。また、プロジェクト管理との同期を考慮しAzure Kubernetes Serviceを使うのであればAzure DevOpsを使うのが有効ですし、別途JIRAなどでJenkinsを使ったプロジェクト管理との連携を構築することが重要です。オーケストレーションツールが操作するリポジトリのバージョン管理やタスクなどを
- 作図からコードを自動生成するジェネレーターは無いわけではありませんが、圧倒的に多いのがコードから作図するツールです。つまり、設計から実装、その後リリース時に設計文書の図を更新するというフローが最も自然なのかもしれません。しかし、それでもシーケンス図や相互作用外観図はプログラムのフローとステートマシンを表すものですのでこれを自動生成するのは困難なうえ、マイクロサービスやサーバーレスコンピューティングでインプリメンテーションしている場合はコードと設計書の同期は手作業になります。 その意味で、設計文書の作図はいかに簡単に描けるか？再利用可能な形式か？可搬性に優れているか？が重要と感じています。その結果、私はdraw.ioを使っています。
- Azure AntennaではVisual Studio、Docker for Windows、Git for Windowsを使った例を学習しました。Visual StudioのDockerサポート機能を利用する例です。
- Dockerはインストールして、ほぼ既定のまま使えますがSettingsのShared DrivesとNetworkは確認が必要です。Shared DrivesはCをチェックしておいてください。Visual StudioのDockerサポート機能を使う際に、DockerがCドライブにコンテナを作成できるようにしておきます。また私の場合、会社で使っていたのでNetworkをFixedにしていました。これはAutomaticが既定の設定になっています。
- Webアプリを作成する際にDockerサポートを有効にするためのチェックボックスが選べるのでチェックして作成します。作成したWebアプリのプロジェクトを右クリックして、[追加][コンテナオーケストレーターサポート]を選択し[Docker Compose]を選んで[OK]ボタンを選択するとOSを選択するダイアログが表示、続けて[OK]ボタンを選択すると処理が始まります。これは少し時間がかかるのでそのまま待ちます。最後に出力ペインに完了が表示されたら準備完了です。
- 出力ペインに完了が表示されたら、Docker Composeが追加されていることを確認し、Dockerfileの「EXPOSE」が80になっていることを確認します。 これによってローカルでDockerを使ったデバッグが可能になりました。初回は時間がかかりますが‘2’回目以降のデバッグはそれほど時間がかかりません。
- ローカルの環境が出来上がったので、ここでは、Azure DevOpsのBuild Pipelineの設定を例にAzure DevOps Pipelinesを使ったCD/CIをご紹介します。 Azure DevOps PipelinesはJenkinsのように、トリガーアダプターの役割を果たします。非常に多くのトリガーに対応することができるので、それらを組み合わせてCD/CIをくみ上げていきます。 図の例ではFTP Uploadを選ぶことも可能です。 つまり、CD/CIを実際に行われている組織などが、その作業を自動化するためのツールがAzure DevOpsだとも言うことができます。 Azure DevOps PipelinesはBuild PipelineとRelease Pipelineがあります。Release Pipelineには、Azureのあらゆる配置先が用意されており選択することができます。また、テストプランからタスクをインポートすることもできるので、Bordでのプロジェクトタスクの管理、テスト、リリースを同期させることが可能です。
- Build Pipelineはローカルリポジトリのビルドをトリガーにして、ビルド、プッシュ、ロック、ステージングディレクトリへのコピー、製品リリース（リリース判定前のもの）までを自動化する例を学習してきました。
- ソースを変更し、コミットしてプッシュをセンタくするとAzure DevOps側では新しいログが出力され、稼働中であるアイコンが表示されます。
- システムの継続的インテグレーションの最初につまずくのが認証と認可です。ソフトウェアを作って たとえば外部情報の活用では、FacebookなどのアイデンティティプロバイダーのAPIでSSOを行うことでサービスを提供する側はアカウントの管理から解放されます。また、Microsoft GraphによるOffice 365連携をすることでユーザーの既存資産を活用します。その他の外部Webサービスとのマッシュアップを利用するシーンも増えてきています。Microsoft Graphでスコープの制限を使った情報共有のユーザーごとの制御の必要のあった開発の経験がある方は？【会場に挙手を促す】【デモ】 ログイン時にアカウントをアイデンティティプロバイダーから選択できる画面の開発経験がある方は？【会場に挙手を促す】
- 分散型IDは現在スタンダードというわけではありません。様々な企業が分散型のIDをインプリメンテーションしていこうという目的でファウンデーションを作ったという状態です（2017/5/22に設立をアナウンス）。 右が参加している企業です。
- ブロックチェーンテクノロジのサイクルとしての視点ではBlockchainは幻滅期に差し掛かろうとしているとガートナーが提唱している。
- しかし、分散型IDのUniversal ResolverはBlockchainの有用なインプリメンテーションのひとつであるといえます。
- creation of identifiers, authentication, data encryption, and management of keys and permissions
- Decentralized Public Key Infrastructure （JSON ：public key material）
- Decentralized Public Key Infrastructure （JSON ：public key material）
- NeoGovern.DIDは分散型IDのモデルが入っている
- https://github.com/decentralized-identity/universal-resolver/