CodeCatalyst を使ってバージョンの管理とリリース管理しよう

バージョンの番号を作り、　命名規則なんかを考えるようになったら。
開発のDevチームと　リリースする運用Opeチームで話し合うべきは、「次のリリース何入れよっか？」

リリースされてCode N 兄弟と呼ばれた時代からはや10年くらいですよ。
このCodeCataystばかりはちょっと異色ではあるけど、　アプリケーションをリリースしながら、ソースの管理をCICD的に継続リリースできる。　昨年のFurugalアーキテクチャの中に　繰り返し継続できる仕組みをコストとして考えようなんてKeynoteもありました。

CodeDeployしてますか！？

Code Commit してますか！？

どちらも大事なことですが

アーティファクトやシステムの管理する時のバージョンの付け方

と

AWSリソースの名前の付け方って　環境や面数、仕組みとしてはとても面倒ですよね。

そんなみんなに共有したいのが、俺流でとても便利な命名規則です

バージョンの付け方

命名規則の付け方

🚚 こちらは　Cloudforamtionの記事の中に移動させました

　次のアプリケーションリリースする時は「どんな機能を盛り込もうか計画してからコーディングする」

個人でもお仕事でも、　次にアプリケーションをリリースする時には「どんな機能を盛り込もうか計画してからコーディングする」
これが大事。
Gitでブランチ戦略やタグづけをする。
その次にリリースノートを書くなんてやっていたりすると思います。　

ただ、AWS re:invent 2023 Keynote では「非機能要件には　コストを念頭に入れましょう」という熱いメッセージがあるのです。

そこでタイトルにもあるCodeCatalyst！　このページを見てください。　そう、チケットの管理がCatalystには統合されています。

いままで　

📂CodeCommitでコードを管理し　＞
⚙️ CodePiplineを　🔨CodeBuild　と　🚗CodeDeploy　を組みあわせてリリースする。

せめてあるのは　Commit上のRELEASENOTE.ｍｄ　のみ。　リリースノートを管理するには　個別にチケットや看板を管理するミドルウェアが必要だったのです。　それを解決してくれるのが　このCodeCatalyst

Workshopにもチュートリアルがあるように、　コードとCICD管理に加えての　「リリースを計画できるようになった」
この仕組み使っていかないてはないと思いますよ。

（本日はご紹介までに！　使ってるところ別記事にしよ❤️）

参考：　CodeCatalyst は　IaCとDevOps の夢のような仕組み

https://aws.amazon.com/jp/codecatalyst/
https://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/welcome.html
https://codecatalyst.aws/explore
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-CodeCatalyst-Overview_1031_v1.pdf