【Linux】サクッとシェルは書けた方がいいって言う話
こんにちは、ベーシストエンジニアのフクナガです。
記事の内容をうまくまとめたタイトルが思い浮かばなかったので、よくわからないタイトルになってしまいましたが、要約するとこれです↓
インフラソースコードをGitにプッシュする作業をシェルで短縮した話
本記事は「こんな技術があるよ」というものではなく、「サクッと運用を改善できる手段を持っとくと役立ちました！」という内容の記事です。結論だけみたい方は「まとめ」まで読み飛ばしてください
概要
案件の中で「Terraform」というインフラをコードで構築するツールをCodeCommit（AWS版Git的な）を使って管理しています。
今回の記事はシェルの話がメインなので「Terraform」「CodeCommit」については説明を省略します。一応参考までにURLは貼っておきます
CodeCommit： https://dev.classmethod.jp/articles/codecommit-try/
ソースコードをプッシュする際に以下コマンドを手動で実施していました。
terraform fmt -recursive ...ソースコードのフォーマット修正
git add * ... ソースコードの変更内容をコミット対象にする
git commit ... ソースコードの変更内容をリモートブランチへコミット
git push ... ブランチへ変更を適用
上記をシェルに集約して、シェルを実行すれば完了するようにまとめたわけですね。
シェルにした理由
概要で説明した運用について説明したドキュメントはあるものの、コマンドを手動で入力する際の操作ミス（特にフォーマット忘れが多い）について機械的に防ぐことができないのが課題として挙げられていました。
日常の業務が優先だったため、こういった運用のレベルアップ対応は後回しにされがちでした。（会社勤めエンジニアの方なら共感いただけるのでは..）
では、なぜ今回実施したのか？
理由は「会社を退職するから」です。いわゆる「属人化」（特定の人しか実施できなくなること）を防ぐために実施しました。
要件
シェル実装の際に注意したことを記載します。
1. 現行のGit運用のお約束に従った実装
現行では、以下の流れで開発をしています。（特殊ではないと思います）
(1)masterブランチ(今はmainですかね?)を取得
(2)masterブランチを元に新規ブランチを作成(命名規則は決まっていない)
(3)作成したブランチを編集し、pushする(masterへ直接pushしない)
(4)ブランチの内容とmasterブランチをマージ
上記の中で自動化の課題となるのは「ブランチを作成する際の名前が共通でない」ことです。そのため、対話型（read）のシェルにしました。
参考URL： https://tech.mamezou00000.com/entry/taiwa-shell
2. 禁止事項
1で説明した通り、masterへ直接pushするのは禁止しているのでブランチ名がmasterの場合シェルがNGメッセージを吐くように実装しました。（単純にif文で分岐）
まとめ
命名規則、だったりコメントは人によってこだわりがあるものです。ここをあらかじめシェルとしてまとめておけば、設計書やマニュアルを見にいく手間も省けますし、ミスも起こりません。ただ、気をつければミスは起きないと考えてこういった自動化は見送られがちです。
僕はこれまでの経歴からシェルが手癖としてあるので、今回はシェルで自動化を実施しました。手段はなんでも良いと思いますが、こういった自動化を10~15分くらいで実施できると作業効率化・属人化の防止という観点でよいなと身を持って感じることができました。