開発基礎知識

まず、開発の一般的な流れは、、、
「Commit → Build → Test → Deploy」
大雑把にでも下記大枠のイメージをおさえます。

Commit
・変更をCommitする
・複数の変更を統合する
・変更の履歴を統合する

Build
・成果物をBuildする
・複数の成果物の依存関係を解決する
・(Docker)イメージを作る

Test
・成果物の単体テスト実行
・成果物の結合テスト実行
・テスト結果を出力

Deploy
・成果物を開発環境に反映
・成果物を本番環境に反映

次に、開発ツールを学ぶ上でおさえておくべき基礎用語です。

CLI

（CLI：コマンドラインインターフェース）

AmazonのクラウドサービスであるAmazon Web Services (AWS) をコマンドラインから利用するために、公式に提供されているツール。
一回のPUTオペレーションでアップロードできるオブジェクトの最大サイズは5GB。

※AWS操作は主にAWSマネジメントコンソールとAWS CLIを利用。

【コマンド】

• start-build コマンド
  使用してビルド仕様(buildspec)をオーバーライドできる。

• aws configure コマンド
  AWS CLI のインストールをセットアップするための最も簡単な方法。このコマンドを入力すると、AWS CLI によって 4 つの情報の入力が求められる。
  
  ●アクセスキー ID
  ●シークレットアクセスキー
  ●AWS リージョン
  ●出力形式

Software Development Kit
【構築ツールセット】

（Software Development Kit：SDK)

ソフトウェアの開発と実行に必要なすべてを 1 か所にまとめる。
開発者向けのプラットフォーム固有の構築ツールのセット。

さらに、ドキュメント、チュートリアル、ガイドなどのリソースや、アプリケーション開発を高速化するための API やフレームワークも含まれる。

※特定のプラットフォーム、オペレーティングシステム、またはプログラミング言語で実行されるコードを作成するには、デバッガー、コンパイラー、ライブラリなどのコンポーネントが必要。

・「AWS SDK」と「AWS CLI」はIAMロールから一時的なセキュリティ認証情報を自動取得できる。

DataPipeline
【リソース上でデータの移動支援】

指定された間隔でAWSのさまざまなコンピューティングサービスやストレージサービスのほか、オンプレミスのデータソース間で信頼性の高いデータ処理やデータ移動を支援するウェブサービス。

データの取り出し・変換・保存など順次処理が可能。
（※オンプレミス環境からのデータ転送にはDataSyncを利用）

【スケジュールされたパイプラインに関連付けられる項目は 3 つ】

[１]パイプラインコンポーネント：
【 データ管理のルールを定義】

・パイプラインのビジネスロジックを表し、パイプライン定義のさまざまなセクションによって表される。

・ワークフローのデータソース、アクティビティ、スケジュール、および前提条件を指定する。

・これらは親コンポーネントからプロパティを継承でき、コンポーネント間の関係は参照によって定義される。

[２]インスタンス：
各インスタンスには、特定のタスクを実行するためのすべての情報が含まれている。

・パイプラインを実行するときに、パイプラインコンポーネントをコンパイルして、一連のアクション可能なインスタンスを作成する。

・完全なインスタンスのセットは、パイプラインの To-Do リスト。Task Runner に処理するインスタンスを渡す。

[３]試行：
堅牢なデータ管理を提供するために、失敗したオペレーションを再試行する。
(※この処理は、タスクが最大許容再試行回数に到達するまで続行される)

・試行オブジェクトは、さまざまな試行、結果、および失敗の理由（該当する場合）を追跡する。

・基本的に、試行はカウンター付きのインスタンス。Amazon EMR クラスターや EC2 インスタンスなど、以前の試行と同じリソースを使用して再試行を行う。

Code Star
【開発環境作成・ステータス管理】

アプリケーションのすばやい開発、ビルド、デプロイを行うために必要なツールが用意されている。

さまざまなプロジェクトテンプレートを利用して、EC2、Lambda、Elastic Beanstalk でのアプリケーションの開発を開始。そして、事前設定された継続的デリバリーツールチェーンを提供することでアプリケーションの提供を迅速化。

• 継続的デリバリー
  ソフトウェア開発手法の一つ。コード変更が発生すると、自動的に実稼働環境へのリリース準備が実行される。アプリケーションのアップデートを素早く反映できる。

• ツールチェーン
  ある目的を達成するために組み合わせて使用する一連のツール(道具)のセット。

〇作成要素

[１]プロジェクトテンプレート

・EC2、Lambda、Elastic Beanstalk にデプロイするアプリケーションの開発をすばやく開始する助けになり、複数用意されている。

・Java、JavaScript、Python、Ruby、PHP などの多くのプログラミング言語をサポート

[２]自動化された継続的デリバリーパイプライン

AWS CodePipelineと連携して、コードのビルド、テスト、デプロイが自動化された事前設定済みのパイプラインがプロジェクトごとに設定（継続的デリバリー）されている。

[３]自動化されたデプロイ

AWS CodeDeployやAWS CloudFormationと統合することで、アプリケーションコードを簡単に更新し、EC2やLambdaにデプロイすることができる。

〇管理要素

[１]チームのアクセス管理

・セキュリティ対策として、IAM によって開発者のアイデンティティ管理がおこなわれる。

・アクセス管理は、「所有者 / コントリビューター/ ビューワー」などのさまざまなロールに対応する、簡単な組み込みのセキュリティポリシーにより、プロジェクトへのアクセスを簡単に保護する。

[２]ホスト型の Git リポジトリ(Code Commitで安全管理)

・AWS CodeStarでのアプリケーションコードはCodeCommit に安全に保存される。

・CodeCommit は完全マネージド型のソース管理サービスであり、Git リポジトリをホストするために独自のインフラストラクチャを管理する必要がなくなる。

※独自の GitHub リポジトリをプロジェクトのソースコードが保存されるように選択も可能。

[３]一元化されたプロジェクトダッシュボード
一元的に、アプリケーションアクティビティの監視と、最近のコードのコミット、ビルド、デプロイなどの日常的な開発タスクの管理を容易に行える。

・さまざまなサービスコンソールを行き来する必要がない。
・アプリケーション開発全体をわかりやすく管理することができる。

• 継続的デプロイメント
  【開発アクティビティ管理】
  CI/CD パイプラインでのコードのコミット、ビルド、テスト、デプロイなどのアクティビティを一元的に管理し、表示。
  ・アプリケーションのビルドが正常に完了すると全て成功と表示する。
  ・デプロイの進行状況やコミットの履歴なども同時に確認が可能。
  
  ※ステージの追加、編集を行いたい場合には「Code Pipelineの詳細」を選択する。

• チームwiki
  内容をカスタマイズしてチームノートに保存したり、プロジェクトにリンクさせる、コードサンプル、チームメモなどのチーム情報の提供が容易。

• アプリケーションアクティビティの監視と JIRA の問題管理
  アプリケーション監視サービスであるCloudWatchやプロジェクト管理ツールであるAtlassian JIRA Softwareなどと統合することで、アプリケーションやJIRAの問題の監視、追跡、管理が可能。

• アプリケーションエンドポイント
  エンドポイントのリンクが表示。アプリケーションまたはサービスを表示するにはリンクを選択。

• コミット履歴
  リポジトリの最近のコミット履歴が表示。
  コミットやリポジトリに関する全てのコミットや詳細を表示したい場合は…
  →コードがCodeCommitに保存されている　⇒　CodeCommitの詳細
  →コードがGitHubに保存されている　⇒　GitHubで開く

• アプリケーションアクティビティ
  プロジェクトのAmazon CloudWatchメトリクスが表示。例えば、Code DeployリソースによってデプロイされたAmazon EC2のCPU使用率や、AWS Lambdaを使用すればLambda関数の呼び出しとエラーのメトリクスが表示され、情報は時間単位で表示される。

[４]完全マネージド型ビルドサービス
AWS CodeBuild を使用することで、コードのビルド、テスト、統合をより頻繁に実行できるよう になり、ソースコードのコンパイルとパッケージ化を行える。

CodePipeline
【流れの見える化】

書いたソースコードを自動でビルド、デプロイ、テストしてくれる。アプリをデプロイするために必要なステップを、可視化・自動化できる。

継続的にプロダクトの自動的なリリースを実現するCI/CD プロダクト。
※CI/CD：実装 > テスト > デプロイ・リリース のフローを可能な限り自動化する（Code＞Build＞Test＞Deploy）

• パイプライン
  【一連の処理の流れ】
  ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造。
  各パイプラインは一連のステージで構成。
  
  (※CloudFormationテンプレートのデプロイ、テストに利用できる。）
  (※パイプライン内の処理を定義するにはUIから手動で行うか、CloudformationでStackを定義して行う形になる)

• ステージ
  【処理を実行する環境の単位】
  各ステージのアプリケーションアーティファクトに対して実行される複数アクションが含まれる。(※各ステージ毎にコンテナを立ち上げて処理するイメージ)
  
  各ステージは、連続または並列のアクションで構成されている。
  環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニット。

• アクション
  【実際に行われる処理の単位】
  ソースコードを取ってきたり、テストしたり、デプロイしたりする。
  アクションには[source / build / test / deploy / approval] というタイプがある。
  
  パイプラインのステージに承認アクションを追加した箇所でパイプラインを停止することで、このアクションを主導で承認または拒否できる。

※一例

CodeArtifact
【共有リポジトリ】

Python の pip や Node.js の npm 等の各種ソフトウェアパッケージを安全に保存、公開、共有できるようにするソフトウェアパッケージプライベートリポジトリサービス。

また、パッケージ化したものを配布できる
※PyPI（Python Package Index）, pip, npm, mavenなど
(※AWS Key Management Serviceと統合して、暗号化されたストレージを提供)

• ドメイン（ドメイン＞リポジトリ＞アセット）
  CodeArtifact の最上位のエンティティ。ドメイン配下に複数のリポジトリを持つことが出来る。
  
  ドメイン内のアセット (パッケージ) は KMS の暗号化キーで暗号化される。すべてのアセットとメタデータはドメインに保存される為、複数のリポジトリに同じアセットが存在する場合、アセットはドメインに 1 つだけ保存される。

• リポジトリ：（ドメイン＞リポジトリ＞アセット）
  各アセットのバージョンセットが保存される。
  1 つのリポジトリには、サポートされる全てのタイプのパッケージのエンドポイントを提供。

【簡素化された管理】

・ソフトウェアの更新やサーバーの管理は不要。

・数回クリックするだけで、中央リポジトリをセットアップでき、開発チームが必要なソフトウェアパッケージを簡単に見つけて使用できるようにすることができる。

・ソフトウェアパッケージと依存関係をパブリックなアーティファクトリポジトリから自動的にフェッチするように設定できるため、デベロッパーには最新バージョンが提供される。

【アクセス管理】

・管理者はパッケージを承認し、組織全体への配布を制御することもできるため、開発チームが使用するソフトウェアパッケージの安全性を確保することができる。

・AWS IAM をサポートしているため、IT リーダーは AWS アカウント全体のさまざまなチームに適切なレベルのアクセス権を付与できる。

【オペレーションのオーバーヘッドを削減する】

・アーティファクトリポジトリの管理には、必要なインフラストラクチャをセットアップして運用する必要がない。

・CodeArtifact は可用性が高く、あらゆる規模の組織のニーズに合わせてスケーリングできる。

・一般的に使用されるパッケージマネージャーや各種のビルドツール (Maven、Gradle、npm、yarn、twine、pip、NuGet) で動作するため、既存の開発ワークフローに簡単に統合できる。

Code Commit
【ソースコード管理】

ソースコードやドキュメント等の成果物をAWS上のプライベートな「Gitリポジトリ」にホスティングして、ユーザのデータを預かって管理する、ソース管理の収納庫。

※一般的な流れ：リポジトリの作成 → ファイルの追加

・AWS特有の完全マネージド型サービスなため、Gitをホスティングするサーバの構築は不要。

・CodeCommit リポジトリのトリガーを作成して、リポジトリのイベントから Lambda 関数を呼び出すことができる。

• 機能ブランチ
  別のパイプラインを作成し、テストされたコードを本番環境にマージする機能を支援する。

• Git
  ソースコードや設計書等のドキュメントの変更履歴を記録して管理する、オープンソースの分散型バージョン管理システム（対象ユーザは、主にソフトウェア開発者）

【仕様】

・共同でのソフトウェア開発向けに設計されている。

・コードのアップロード、履歴の確認,ソースのプレビュー、ブラウザ上での編集、プルリクエスト、ブラウザ上でレビューコメント、承認ルールの設定が可能。

・複数のファイルにわたる変更を一括管理でき、並行分岐化、（S3のみ）バージョン比較（diffing）を利用できる。

【セキュア性】

・CodeCommitにアクセスする際にAWSのユーザーIDとPWが求められる。

・CodeCommit リポジトリ内のデータは、転送中と不使用時のいずれも暗号化される。

・クラウド内のアセット（ドキュメント、ソースコード、バイナリファイルなど）を非公開で保存及び管理できる。

CodeBuild
【コードのテスト】

ソースコードを受け取り、それを仕様書（buildspec.ymlファイル）に基づいて、ビルド環境（イメージ）を構築し、問題がないかテストを行う。

【順序】
①ソースコードの編集とアップロード（CodeCommitにプッシュ）
②buildspec.ymlファイルの作成とアップ（CodeCommitにプッシュ）
③ビルドプロジェクトを作成（CodeBuild上で作成）
④ビルドを開始する（CodeBuild）

• BuildSpecファイル
  yaml形式で記述されたAWS CodeBuildの設定ファイル。
  ここで記述された設定がAWS CodeBuildによってビルドされる。この設定ファイルの問題を確認するには、AWS CodeBuildビルドをローカルで実行する。
  ローカルで実行することで、BuildSpecファイルで記述した設定をローカル環境で試行錯誤することができる。これにより、BuildSpecファイルにおける問題をローカル環境で確認することができる。

CodeDeploy
【自動デプロイ】

ビルドした、EC2、オンプレミスインスタンス、サーバーレス Lambda 関数、または ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービス。

アプリケーションを構成している「ファイル群」をステージング環境や本番環境といった「グルーピングされたサーバー群」に定められた手順で自動配置するサービス。

• CodeDeploy エージェント
  インスタンスにインストールして設定すると、そのインスタンスを CodeDeploy デプロイで使用できるようにするソフトウェアパッケージ。

• デプロイグループ
  デプロイ中に使用される設定と構成が含まれる。
  ほとんどのデプロイグループ設定は、アプリケーションで使用されるコンピューティングプラットフォームによって異なる。ロールバック、トリガー、アラームなどの一部の設定は、どのコンピューティングプラットフォームのデプロイグループでも設定できる。

• AppSec
  Lambdaのバージョンを管理することができる。

• AppSpec file
  (Application Specification File)
  CodeDeployがEC2インスタンスに対して、 S3 または GitHub にあるアプリケーションのリビジョンをどのようにインストールするか決定する、YAML フォーマットのファイル。
  
  また同様に、デプロイの様々なライフサイクルイベントをフックして処理を実行するか決定する。
  
  ●AppSpec ファイル
  appspec.yml として、アプリケーションのソースコンテンツのディレクトリ構造のルートディレクトリに配置される。
  
  ・この要件を満たしていない場合、デプロイは失敗する。
  ・AppSpec ファイルが既に存在する場合は、これを含めたデプロイ用のコンテンツを .zip (Windows Server 以外は .tar および .tar.gz も可能) 形式の圧縮ファイルにできる。

〇デプロイ方法

• Blue/Green
  CodeDeploy によって制御される ブルー/グリーンデプロイモデルを使用する。
  このデプロイタイプは、本番稼働用トラフィックを送信する前にサービスの新しいデプロイを検証するために使用する。

• インプレースデプロイ
  デプロイグループの各インスタンスのアプリケーションが停止され、最新のアプリケーションリビジョンがインストールされて、新バージョンのアプリケーションが開始され検証される。
  EC2/オンプレミスコンピューティングプラットフォームを使用するデプロイのみが、インプレースデプロイを使用できる。

【デプロイのライフサイクルイベント】

フックして差し込む1つ以上のスクリプトを指定する。
hooks セクションは、何らかの処理を追加したい場合のみ指定する。

• ApplicationStop
  前回のリビジョンのシャットダウンが開始したとき(フック可能)。

• DownloadBundle
  AWS CodeDeploy Agent がリビジョンをCドライブの[Archiive]階層にコピーしたあと(フック不可能)。

• BeforeInstall
  AWS CodeDeploy が files セクションで指定された場所にファイルをコピーする前(フック可能)。
  ファイルの復号や現在のバージョンのバックアップの作成などの事前インストールタスクに使用。

• Install
  CodeDeploy が files セクションで指定された場所にファイルをコピーするとき(フック不可能)。

• AfterInstall
  CodeDeploy が files セクションで指定された場所にファイルをコピーした後(フック可能)。
  アプリケーションの設定やファイルのアクセス権限の変更などのタスクに、このデプロイライフサイクルイベントを使用。

• ApplicationStart
  アプリケーションのリビジョンが開始する直前(フック可能)。

• ValidateService
  サービスの検証が終わった後(フック可能)。