より良い開発を With github
github深堀りしよう
最近、githubの運用といいますか、チーム開発での工夫に関する記事をいくつか見ていました。せっかくなので、それらをまとめてみました！
各企業様の取り組みを見て、おもしろいな～～と思ってみていました。
（実際に苦労されていた方もいると思いますので、安易におもしろい、と書いてはいけないとも思っていますが・・すごく勉強になります）
本記事では、以下について話をします。
- what is Git?
- ブランチ戦略
- PR対応
- コードレビュー
- copilot(少しだけ)
What is Git?
githubを使うためには、そもそも土台となるGitがわかっていないと、話を進まないので、最初にこの内容を挙げております。
雑な回答かもしれませんが、以下スライドに内容が一通り理解できてしまえば、現場で困ることはそうそうないと思えるボリュームかと思います。（スライド450枚！）
ブランチ戦略
googleのソフトウェアエンジニアリングにも記載されている内容となります。
こちらの書籍、発売されてからちょうど1年半くらい経過しますが、ある技術を取り上げるというよりは、手法やあるべき姿、といった部分を記載する箇所が多い印象なので、年数が大きく影響する書籍ではないかと思います。気になる方はぜひ。このボリュームで4000円でいいの？？？って感じでーす
さて、本題に戻ります。
Flow
github-flowという開発フローが存在します。master(main)ランチとfeatureブランチによる開発方法です。これはよく見るフローではないでしょうか。
github-flow以外にも、git-flowやgitLab-flowといったflowが存在するようです。
どのflowが適しているのかは、開発状況次第となりそうですね。そのあたりのメリット・デメリットも以下記事に記載いただいています。
トランクベース開発
この開発手法はプロジェクトのリリースサイクルによるかと思います。短期間でのリリースでない場合トランクベース開発は適していない印象を受けました。マイクロサービス開発チームでの事例で、PR作成からマージまでが3日間といった事例が記載されています。この機会で初めて見たので、まだまだ勉強が必要です
スライドの中で紹介されていた、パフォーマンス可視化ツールです。
PR対応
ブランチを作成して、マージをしたいとなれば必ず発生する作業ですが、プロジェクトが大きくなると、PRを裁き切れない・PRの更新行数が多すぎて・・・などなど問題を抱えているケースがあったようです。
PRのサイズ制限
理想的なサイズとその理由
実際に行われた調査をもとに、そのデータ情報に関するまとめをされている記事です。
以下のような情報が記載されています。
- レビュー時の修正は低コスト
- QA時の発見となると、修正コストが大きくなる
- 1時間ごえのレビューで低品質なものに
- 欠陥を見つける検知能力は、行数が多くなると下がる
- 1時間以内にするとなると、～400行
サイズに縛られすぎて本末転倒にならないように
サイズを制限するのが、目的ではないはず。実際どういった問題を解決する予定だったのか、またサイズにこだわりすぎた結果、副作用が大きくなっていないか、そういったことを伝えている記事だと感じました。
サイズ制限の仕組みを作りたい！
こちらは自分でやってみました。
PRの行数が30行を超えた場合には、マージができないようにする設定をしたymlファイルを作成しています。実装するまでの過程に関しては、別途記事にしようかと考えていますが、現状完成した状態のみとなりますが、共有していますので、気になる方はぜひ！
ちょうど30行更新した場合
30行オーバー更新した場合
リポジトリはこちら
環境変数ファイル(.envへの書き込みもやっていますが、今回はファイルに書き込んで、変数の値が読み取れるかを確認したかっただけで、それ以上の理由はないです！)
コードレビュー
いずれの記事も、PRが作成されてからマージするまでの時間を抑える、という話が記載されていました。
レビュワーの時間を抑えるには・・・、レビュワーに優先して対応してもらわねば・・・対応してもらうために、どういった仕組みを作ればよいだろうか、といったパートです。
PRの時間削減
PRの生存期間が長い（10営業日）ことで、コンフリクトも発生してしまう、この状況をどのように改善していったのか。
開発着手からPR作成までの期間とPR作成からマージまでの期間の改善を試み、PRがたまってしまう問題をどう解決するか、そういった内容が記載されています。
スケジュールを優先して抑える
タイトルの通りですが、レビューをするということはレビュワーがいます。
各プロジェクトの状況にもよりますが、レビューをする立場の方々はお忙しい可能性が高いかと思います。
そういった中で開発スピードを上げるためには、レビュワーの予定の中でレビューに関する優先度を高めてもらう必要がありました。優先度を高めるだけではなく、レビューの質を下げないために、githubをどのように活用していったのか、そういった内容が記載されています。
自動化に向けて
pushされた後に、CI/CDや通知など色々アクションを発生させていると思います。それを都度手動でやっているのは辛いですし、毎回同じ操作が行える保証はありません・・・
既存のgit運用課題とそれら課題への対応
以下内容が記載された記事になります。
-
Git FlowとGitHub Flowのブランチ戦略統一 - リリース作業の自動化
- リリース粒度のミニマム化
github Actionsと仲良くする
Github Actionsに関して、どういった利用をするのがおすすめなのか、初めて触る方にとっては、難易度が多少高いと思いますが、実践的な使い方をする上で、参考になる記事ではないでしょうか。
また読んでいて、特に参考になったのはGitHub Actionsの学び方の課題でした。学習の上で以下のような課題がある、と記載されていました。
- コミットやUI 操作をしないと動作確認できない
- ブラウザで作業することが大変
以下のオープンソースで、リポジトリに変更を加えることなく、ローカルでワークフローの実行できるようです。また試せていないので、試して追記できる情報がありましたら追記します・・・
github Copilot
最後にちょこっと・・・
ここ1か月で世間を大変をにぎやかにしている、OpenAIのGPT関連のニュースですが、
githubと関連した部分ですと、以下の記事あたりになるでしょうか。
従業員に対して、このサービスを支給するようなニュースもでてきています。
これからたーくさんの便利なサービスがリリースされそうです！！！
従業員に対する支給に関する記事
まとめ
githubは開発上、必要不可欠なもののはずです。しかし、なんとなく使っているだけでは開発の効率は上がらず、問題を抱えながら・不満を言いながらの利用となってしまいます。そうならないために、各企業さんが様々な取り組みをされていることが、ここで記載した僅かな文量でも分かるかと思います。Copilotなどの新しいサービス含め触れていない部分があるので、そういったところをアップデートしてきたいです。
ありがとうございました。
Discussion