【インフラ_10日目】CI/CD_1冊目
こんにちは投資ロウトです。
背景
・CI/ CDをシステムに導入していかなければならない背景があります。
アクションには種類がある
以下の3種類のアクションがあるとのこと。
・Composite Action
→yamlで実装
・JavaScript Action
→javascriptに慣れている人であれば、実装しやすい
・Docker Container Action
→任意のプログラミングで選べるので、自由度が高いとのこと。
アクションの制限
企業で運用するアクションはプライベートリポジトリで運用することが多いとのこと。アクションをプライベートリポジトリで運用する場合は、別途リポジトリ設定が必要とのことでした。
【ローカルアクションでのルール】
・最初にチェックアウトを行うこと
・usesキーでは「./」から始まるパスにする
メタデータ構文
# アクションの概要を書くことで、他の人がわかりやすくできる
description: |
事細かにアクションについて説明の文章を書き、他の方がそのアクションがわかるように記載する
キーの簡易解説
・runキー・・・シェルコマンドを実行する
・usesキー・・・アクションを呼び出す
どのようにActionを組んでいけばいいのか
・利用する人はアクションを使いたいだけなので、名前の命名規則をわかりやすくすることが重要とのこと。
・ステップの実装が長くなったら、別ファイルに切り出しを検討
※XXX.shのファイルで、切り出しを行い、GITHUB_ACTION_PATHを使って、切り出したファイルを呼び出せばいいとのこと。
コードレビュー
・コードレビューはプルリクエストのタイミングで確認するのが一般的とのこと。
・GitHubのデフォルト設定では、コードレビューなしにマージが可能とのこと
※ただしそれをしてしまうと、コードレビューのメリットがなくなってしまうとのこと。
ブランチを守る
以下のような規約を行っていくことで、品質を担保できるような仕組みづくりを行っていけるとのこと。
・プルリクエストなしの変更等を拒否させる
・CIが通っていない状態でマージさせないようにする
・ブランチを削除させないようにする
まだブランチルールがない場合は、このように表示されるとのこと。
ルールセットを作成しようとすると、下記のような画面が表示される。
ルールの設定
・ブランチのどの対象かについて設定が可能
※release/*などの指定も可能とのことでした。
上記のように、
・プルリクエストの作成を必須にする設定も可能
→これは直接対象のブランチにpushをさせない役目を果たせるとのことでした。
・また開発者の承認の人数指定もすることで、勝手にマージさせることを防ぐ役割を果たすことも可能
→自分は承認者になることができないため、ソースレビューを必須にすることができるとのことでした。
・CIが通っているときにマージをできるようにする
→今回CI/ CDを導入するので、こちらは必須かと思いました。
重要情報が漏れない仕組みを検討する
クレデンシャル情報が漏洩してしまうと、会社に対して大損害を起こしてしまう可能性があります。
そのため、以下の2点でそういったリスクを減らしていくことができるとのことでした。
・シークレットスキャン
→ソースコードからクレデンシャル情報が混入していないか検知する仕組み
・プッシュプロテクション
→ソースをpushする段階でクレデンシャル情報が混入していないか検知してくれる仕組み
README
リポジトリを理解するために重要な情報を記載するもの。以下のように記載するのがいいとのことです。
【オープンソフトウェアなら】
・全体像：何ができるのかなど
・設定方法：環境を構築する上で、どういったパッケージ等が必要なのかについて
・使い方：どうやって利用できるのかについて
・補足情報：参考リンク等について
【社内システムであれば】
・システムの全体像：システム構成等
・環境を作るための概要：どのバージョンを利用するかなど含めて諸々
・開発方法：テストの実行コマンドやローカル環境の作り方について
・リリース：クラウド等にリリースする方法について
・問い合わせ窓口：誰に問い合わせればいいのかについてなど
ライセンス
初めて知ったのですが、フリーで公開されたとしても、コードの権利自体を放棄しているわけではないんだと知りました。そういったビジネス法務についても理解を深めていかなければならないと感じました。
と短いですが、以上で学習を区切りたいと思います。ご精読ありがとうございました。焦らずコツコツ頑張っていきたいと思います。
Discussion