AWS Codeなんてろシリーズと取り巻く環境の自己解釈
目次
リングフィットアドベンチャーでトレーニングばかりしてるわけにもいかないので、
Code～シリーズの自己解釈を書いてみることにします。
※自己解釈なので、間違っているところとかあれば指摘いただけるとうれしいです。
想定読者
AWSのサービスもよくわからないし、なんならCI/CDもいまいちわからんでござる。
という感じの人を想定しています。
Codeシリーズって？
AWSが言明しているわけではなく、勝手に私が命名しているだけです。他のサイト様でも
同様の表現があったりするので、もしかしたら言明しているのかもしれないです。
具体的には
・AWS CodeStar
・AWS CodeCommit
・AWS CodeBuild
・AWS CodeDeploy
・AWS CodePipeline
の開発者用ツールとして分類されている５サービスを指します。
開発者ツール？
私と同じような境遇の方であれば、そもそも「開発者ツール」が何を指しているのかいまいちピンと来ていないかもしれません。
あるいは「VisualStudio」のようなIDEを思い浮かべているかもしれないです。
それもあるいは開発者ツールの一つだとおもいます。（現に CodeStarの中では開発環境としてVisualStudioを選ぶこともできます。）
ここでの開発者用ツールは、
・①ソースコードを書いて
・②ビルドして
・③テストして（自動化されたテストを指します）
・④本番環境にデプロイする
の一連のプロセスを補助するためのツールのことをさします。
「ほーん。やっぱりVisualStdioやんけ。」と思ったかもしれないです。そうかもしれない。というより大部分を賄えるのは確かだと思います。
ということで以降はある程度VisualStdioでできることと比較しながら説明していきます。
CodePipeline
説明の順序を悩みましたが、先に全体像が見えたほうが良いと考えました。
CodePipelineは前述の「①、②、③、④」を好みの構成、視覚化できるサービスとなります。
なにがうれしいの？
なにがうれしいのかと聞かれたらAWSのQA回答を拝借します。
Q: AWS CodePipeline を使用する利点は何ですか?
AWS CodePipeline では、構築、テスト、およびリリースのプロセスを自動化することで、新しい変更すべてを一貫した品質チェックを通して実行できるため、ソフトウェア更新の速度と品質を向上させることができます。
出典：aws.amazon.com
また「好み」の部分を太字で強調しました。
各ステージ（CodePipeline上では「ステージ」と言っています。）に使用するサービスはある程度融通が利きます。
つまり色々差し替えが可能となります。プロダクトのニーズに合わせて調整が効く。ということですね。
CodeCommit
CodeCommitは前述で言うと「①」に相当します。（怪しいですね。コード書くのは別のところですけど）
ソースコードのバージョン管理はおこなっていますか？行っていると思います。
SVNでもGitでも。Code Commitはそれらの一種と考えて問題ないでしょう。（考え方に互換性がある）
使い方にもよるんですが、だいたいそーいったものには管理用サーバが必要になって、当然それらの管理が必要になります。
Code Commitはその辺のめんどくさいことを考えずに、バージョン管理ができる。というサービスです。
とりあえず、CodeCommitがあれば書いたソースコードのバージョン管理ができる。というわけですね。
なにがうれしいかと聞かれたらバージョン管理を行う理由を漁ってもらうのが一番かと思います。
VisualStdio単体ではソース管理のバージョン管理はできない（はず）です。しかしTeamFundationや、SVN、Gitとの連携も用意に行えるため１開発者の単位では
そこまでこの「CodeCommit」の恩恵を感じることは難しいのではないかと思います。
ある意味ですが、後述のCodePipeline等に組み込めることこそがメリットではないかと考えます。
そういった意味ではGitも同様に組み込めるため、そこまで優位性があるかと言われると私は答えを持っていない。という状態です。
CodeBuild
まぁ、ビルドですね。前述「②、③」に相当します。ビルド後のテストまでサポートしてくれています。
Jenkinsを利用されている方であれば、そのイメージで問題ないと考えます。
OKならそのまま出荷用のモジュールまでセットアップできる（はず）です。
jenkinsとの置き換えも可能です。
「ほらやっぱり。VisualStdioで(ry」
遠い記憶でTeamFundationを使えばテストまで自動化できたような。VisualStdio単体ではある程度環境を整えてやらないと厳しいかと思います。
この辺りはGitHubであればGitActionを使えばできるだろうし。まるでできないわけではないと思います。となると、CodeCommitのようにPipelineに組み込める点がメリットにもなると思います。
あとはQAを張り付けますと
Q: CodeBuild を使用する理由は何ですか?
ビルドサーバーソフトウェアをご自分でセットアップ、パッチ適用、維持することなく、CodeBuild ではフルマネージドの機能を使用することができます。ビルドジョブを CodeBuild に送信すると、ビルドごとに新しく作成される一時コンピューティングコンテナで実行されます。ビルドが完了すると、そのコンテナは破棄されます。ビルドサーバーのハードウェアやソフトウェアを管理する必要がありません。また、CodeBuild ではビルドのボリュームに合わせて自動的にスケールされます。送信したビルドごとに直ちに処理され、個別のビルドを同時に実行することもできるため、ビルドがキューで待機することは決してありません。
となります。ビルド環境であったりそういったものの維持も使用するモジュール数が増えてきたりするとネックになったりしますが、そういったわずらわしさからも解放されそうですね。
AWSの主戦場は「インフラストラクチャ」にあると私は解釈しています。よってインフラ部分の効率化というのが１開発者単位だとわかりづらいところもあるかと思いますが、そういった面でも優位なところがあるぞ。といったところです。
CodeDeploy
デプロイします。前述の「④」に相当します。
が、デプロイというのは「環境」の側面が非常に強く、そもそもこのサービスを使うべきなのか。というところから検討が必要なサービスと言えるでしょう。
以下のように、Pipelineでの選択肢も複数あります。
gyazo.com
CodeStar
最後になります。前述「①、②、③、④」は開発の支援を行う重要な部分ですが、大事なものが足りていないことにお気づきでしょうか。
そうですね。「VisualStudio」を含むエディタ相当。と言えばよいでしょうか。実際のソースコードを書くにはなんらかのエディタが必要ですがそれが提供されていません。
CodeStarは前述の「①、②、③、④」に加えて、開発に使用するエディタ（およびIDE）を結び付け、一つの開発プロジェクトの環境を提供してくれます。
文字にすると異様にわかりづらいのか、私の文章能力の問題なのか。ということで実際の画面に頼ります。
まずはプロジェクトのテンプレートを選びます。
gyazo.com
画像のように、複数のテンプレートが用意されています。私はもっぱら趣味ではPython+Flaskなので、そちらを選択してみます。
次にすすむと、バージョン管理の方法が選べます。
gyazo.com
①のおさらいにちょうどいいですね。CodeCommitを選択して進めます。
Pipelineのイメージをつかむのにこの画面は優秀だと思います。
gyazo.com
進めていくと、以下の画面に行き当たります。VisualStudioもちゃんとありますね。
gyazo.com
VSCodeがいいんですが。面倒なのCloud９を選択します。と、あとは数分まてば作成が完了してしまいます。
頑張り中の画像。
gyazo.com
全体はちょっと見づらいですが、こんな感じだったり
gyazo.com
こんな感じだったり
gyazo.com
する開発に必要な情報が画面に収まってるわけです。そんな感じのサービスがCodeStar。
試しに作ってみて、各種EC2だったり、ネットワークだったり。その辺の構成を理解するにも使えるので
CodeStarとかCloud9とか。AWSの理解に時間がかかる部分を省略してくれるサービスはとても助かりますね。
といったところ終わり。刺さるパイが少ないような気もしますが、誰かの助けになれば幸い。
