タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
AWS CodeBuildでRidgepoleをdry-runで動かしてMigration予定のDDLをGithubのPullRequestコメントに追記する - ANDPAD Tech Blog
ANDPAD バックエンド担当の原田(@tomtwinkle)です。 普段はGolangでモリモリコードを書いていますがDevOps関連の記事ばかり書いてます。 お察しの通りなんですが、今回もDevOps関連の記事だったりします。 やり方だけ知りたい人は Motivation の部分は読み飛ばして貰っても問題ないです。 Motivation AWS CodeBuild側の準備 GithubのPrivate Access Tokenを発行する AWS Systems ManagerのParameter StoreにDBとGithubへのアクセス情報を記述 CodeBuildを作成 Github Repository側の用意 Buildspecの記載 動作結果 謝辞 さいごに Motivation 私が担当しているANDPADボードではRDS(MySQL)を利用しています。 そして、DBのsc
初めてPullRequestを対応する前に知りたいGitのコミットについて - ANDPAD Tech Blog
こんにちは！2021年2月にアンドパッドに入社しました、エンジニアの浜田です。 私の経歴として入社前までチームでの開発をほとんどしてきませんでした。アンドパッドに入社して初めてチーム開発をするようになりました。 入社当初、私がPR(Pull Request)を対応する中で教えてもらったことや、他の方が教えてもらっていたことを社内向けに初めてPRを対応する前に知りたいことというタイトルで記事をまとめました。今回はその記事の内容からGitに関してまとめた4点を紹介させていただきます。 はじめに 1. コミットメッセージは1行目がタイトルで3行目から説明 2. 1コミットに複数の対応を混ぜない 3. コミットメッセージに有益な情報を残す 4. レビュー前にGitのコミット整理 まとめ はじめに アンドパッドではGitHub上で開発を進めています。PRのマージ条件の1つにレビュアーのApprove
teyuに届いたPullRequestで使われているRubyの高速化手法 - takanamitoのブログ
この記事は ZOZOテクノロジーズ #1 Advent Calendar 2019 21日目の記事です。 昨日の記事は @awsmgsさんによる「Classic ASPによるRESTful APIのルーティング実装例」でした。 この記事では、会社の開発合宿でつくったgem teyu に届いたPullRequestで使われていた高速化手法の紹介と、なぜ速くなるのか？の考察をします。 techblog.zozo.com 届いたPullRequest 高速化その1 each → while 高速化その2 define_method → class_eval 最後に 届いたPullRequest sonots さんから2件の高速化PullRequestが届きました。 Improve performance and readability #2 Fastest version #3 前者では eac
前提として Pull Requestの運用方法など、各プロジェクトによって方針が定められているところもあるかと思います。 その上、この記事ではあくまで筆者の考えを殴り書きしているだけのものですので、基本的にはプロジェクトの方針に沿った運用を行い、この記事は参考程度にしていただくのが良いかと思います。 概要 昨今の開発では、GitHubを利用される方が大半だと思われます。 その中でも、ほとんどの人が利用している機能として「Pull Request」が挙げられます。 Pull Requestは「実装者が実装した機能・コードの品質をレビュワーがチェックする工程」であり、「実装者とレビュワーのコミュニケーションを取る場」となります。 Pull Requestも万能ではなく、そもそもレビューも実装も人間が行う（2023年時点だとまだ人間がやってる）ので、確認漏れや認識のずれが発生してしまうこともチラ
Github上にローカル環境からTerminalなどのコマンドラインを使ってPush,PullRequestを作成する流れをまとめてみました。 大まかな流れ ①Github上からローカルにファイルをclone(保存)する ②GithubへPullRequest用のBranchをローカルで作成する ③データを更新編集し、ローカルに add, commitする ④Githubにpushする ⑤GithubにPullRequestする ※⑥PullRequestをMergeする 用語の整理 ①Github…オンライン上にレポジトリーを保管し、複数人で共有・編集できる ②ローカル…自分のPC ③clone...Githubなどオンライン上のリポジトリーをローカルにコピー保存すること ④Branch...１つのレポジトリに複数のBranchを作ることで同時に複数のバージョンでレポジトリを管理すること
GithubのPullRequestのコメントにラベルを書くようにして生産性を少し改善する - エキサイト TechBlog.
エキサイト株式会社メディア開発の佐々木です。 メディア開発では、github.comを使ってソースコード管理を行っています。人数やプロジェクトが多くなってくるとPullRequestのコメントの書き方がバラバラになってくるので、生産性を確保する為に下記のようなラベルっぽいものを書くことを推奨する方針としています。 [MUST]… (Must) 必ず直してほしいところをコメントで記載します。どう直してほしいのか具体例をつけて書くことを推奨します。メンテしづらくなったり、パフォーマンスが著しく悪かったり、色々な観点がありますが、その観点がコミュニケーションでは大事なので、その点を書くようにします。 (例) [MUST] この実装はパフォーマンスがよくないとおもうので、 `xxxx` を使った書き方になおしてほしいです GithubのSuggestion機能 明確な修正提案は、GithubのSu
dbtCloudから作成したPullRequestにコンパイル済みSQLをコメントする仕組みを作成した話 - Timee Product Team Blog
こんにちは☀️ タイミーでアナリストとアナリティクスエンジニアしてますokodoonです 今回の記事はdbt CloudでPull Requestを作るときに、レビュー負荷が高くなってしまっていた問題を解消できるように、コンパイル済みのSQLをPR上にコメントするような仕組みを作成したことについての紹介です。 もし同じような課題感を抱えている方がいらっしゃれば、参考にしていただければ幸いです 課題感 今回選択した解決策 背景/前提 実装概要 各ステップの説明 PRの情報をもとにprofiles.ymlの動的生成 コンパイル処理の実施 PR上にコメント どんなふうに動くかみてみる 結果 We’re Hiring! 課題感 弊社のデータ基盤ではDWH層DataMart層は「分析用に加工されたデータを扱う層」として定義しています。 各種ドメインに依存した集計や変換のロジックが含まれるため、この層
Auto AssignでPullRequestのreviewers, assigneesを自動割り当てする - ひと夏の技術
チームのGitHubリポジトリへPRを出すときに毎回ポチポチReviewerとAssigneeをクリックするのがダルすぎたのでなんとかしたくて設定した。 要求事項としては 対象のリストのメンバーの全員をPRが作成されるたびにreviewerに自動アサイン PRのassigneeにはPRの作成者が自動アサイン これを実現したかった。 Auto Assign probot.github.io GitHub - kentaro-m/auto-assign: 🤖 A Probot app that adds reviewers to pull requests when pull requests are opened. Auto AssignはGitHub連携して使用するBotツールで、めちゃくちゃ便利な最高のツール。 使い方はREADMEに書いてあるとおりで、GitHubのリポジトリにApp
PullRequestの統計情報をBigQueryに送り、変更のリードタイムを柔軟に可視化する - $shibayu36->blog;
以前PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;のようなことをやってみたのだが、BigQueryにデータを送ることでもう少し柔軟に変更のリードタイム*1などを可視化してみたのでメモ。 BigQueryで可視化するためにやったことは3つ。 BigQueryにマージされたPullRequest情報を送るスクリプトを作成 上記スクリプトをGithub Actionsで動かし、定期的にデータを送る BigQueryでViewを作り、Data Studioで可視化 BigQueryにマージされたPullRequest情報を送るスクリプトを作成 こういうイメージ。 import { execFileSync } from "child_process"; import { writeSync } from "fs"; imp
ふぉーくで始めるぷるりくえすと 「Fork ってなにそれ、怖い」 そんな風に思っていた昔の自分に贈る。 そういえば当時、解説ページを一瞬読んで、なんだか難しそうだと思って閉じてしまっていたような記憶もある。 で Fork って何？ ひとつのレポジトリを丸コピして、自分のレポジトリを作れる機能。 (どういうこと？) 「つまり、やりたい放題ってことだ！」 Pull Request と何の関係が？ 僕が思うに、ここが分かりづらい。 言葉の響き的に関係してるような気がしない (フォークは‥肉を食べるための‥道具‥！) Githubでは、このForkという機能を「利用」して、本体のレポジトリを汚さずに、安全にPullRequestを送れる仕組みがある。 ここでは「PullRequestを送るための手順」ぐらいに考えておいたら良い。 試してみよう 好きなレポジトリを Fork する 好きなレポジトリを
はじめにこんにちは。 フューチャーアーキテクト株式会社、TIG/EXユニット所属の宮永です。 ※TIG(Technology Innovation Group)はテクノロジーカットでお客様の課題解決を行う部門です。 中でもEX(Energy Transformation)ユニットは2022年に新設されたエネルギー業界特化型のコンサルティング集団で、「エネルギー×テクノロジー」をコンセプトにエネルギーサプライチェーン全体での需給の最適化やレジリエンス強化を図り、地域の活性化やビジネスモデルを変革することで透明性の高いフェアなマーケット形成を目指します。 本記事ではCircleCIでGitHubのPR作成時の負荷を軽減するために、PR作成者の自動アサインおよびラベルの付与を自動化した話をご紹介します。 経緯CircleCIでGitHubのPullRequest作成時の負荷を軽減したいと思った経
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![偽造マイナカードで携帯機種変→225万円のロレックス買われた！「被害は雪だるま式に」市議が警鐘鳴らす - Smart FLASH/スマフラ[光文社週刊誌]](https://cdn-ak-scissors.b.st-hatena.com/image/square/57aaa940ece94aec00f8ac27f2c4180e847193d2/height=288;version=1;width=512/https%3A%2F%2Fdata.smart-flash.jp%2Fwp-content%2Fuploads%2F2024%2F05%2F06155046%2Fmaina_1_thumb_jiji.jpg)
みんなが幸せになれるPullRequestの作り方を考えてみた - Qiita
初心者向けGithubへのPullRequest方法 - Qiita
Github で Fork して PullRequest を送るのはこんなに簡単 - Qiita
CircleCIでPullRequest作成時の負荷を軽減する | フューチャー技術ブログ
www.jpita.or.jp
b.hatena.ne.jp
www.nli-research.co.jp
www.47news.jp
riku0.nk.awe.jp
qiita.com/ak-sakatoku