Ship / Show / Ask
A modern branching strategy Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the ability to keep shipping changes. Changes are categorized as either Ship (merge into mainline without review), Show (open a pull request for review, but merge into mainline immediately), or Ask (open a pull request for discussion before merging). 08 September 2021 Rouan is a softw
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
チーム開発におけるプルリクの作法 - Qiita
僕の考える、GitHubでチーム開発をする際のプルリクエスト（プルリク）の作法を書いてみました。プルリクという名前から当たり前ですがGitHubを使うことを想定してます。 十分小さくプルリクを作ろう プルリクが小さいと、レビューが簡単になり、変更がすばやく中央のブランチに取り込まれるため、レビューの精度が高くなり開発スピードも早くなります。 タスクやIssueが一つで表現されていても、やりたいことを予めいくつかに分けて、それに対して一つプルリクを出しましょう。コードレビュー中に他にやりたいことややるべきことが出てきたら、同じプルリクで作業せずに別のプルリクで行いましょう。 プルリクを出す前に「これとこれとこれのプルリクを出します」とIssueなどで宣言されている状態がベストです。プルリクの分け方に不安があるならこの状態でもレビューをもらっておくと良いでしょう。 単体でリリースできる単位でプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
