GitHub のラベルを宣言的に管理する - tellme.tokyo
ソフトウェアの宣言的設定について “何かを管理する"となったときに、宣言的に設定できるようになっていると非常に便利である。 この宣言的設定 (Infrastructure as Code) とは、イミュータブルなインフラ (Immutable Infrastructure) を作るための基本的な考え方で、システムの状態を設定ファイルにて宣言するという考え方である。 具体的には Kubernetes のマニフェストファイル (YAML) だったり、Terraform のコード (HCL) が挙げられる。 この考え方は、インフラ領域に限らず、何らかの状態管理にはもってこいの手法である。 GitHub のラベルは Issues/P-Rs を管理するために便利な機能である。 しかし、リポジトリの規模やラベルの数が増えてくると、ラベル自体も管理する必要が出てくる。 実際に Kubernetes 規模
Sane GitHub Labels
TLDR; the default GitHub labels kinda suck; use a sane labelling scheme instead; and use git-labelmaker to simplify GitHub label editing. If you work for a company that manages any part of their codebase using GitHub, or if you work in some open-source repositories with at least a few contributors, then I’m sure you’re aware of how wonderful labels can be at organizing everyone’s work. Maybe you n
GitHub Issues: Tagging Best Practices - Save Time! | Robin
For people who make software, the internet has no shortage of best practice for workflow organization like Git Flow, release versioning, GitHub, etc. When you get to the topic of issue management, the reading material plummets. At Robin, GitHub issues are the core of just about every action the team takes. Over the past year, we've worked out an internal tagging system that keeps engineering and p
Wiplock - 作業途中の Pull Request を間違えてマージするのを防止する
English TL;DR 未完了のタスクやタイトルに WIP という文字列を含む Pull Request からメインブランチを保護する Wiplock をリリースしました。 よかったら試して下さい。 https://wiplock.com ソースコードを公開しています。Go と React + Redux で開発しました。 https://github.com/ngs/wiplock 動機 日々の GitHub を使った開発フローで、作業途中 (WIP) の Pull Request を作成し、同僚と実装に関する議論に役立てたりします。 これらの Pull Request を、タスクが未完了のままマージしてしまったり、タイトルに WIP を付けたままマージしてしまい、紛らわしいマージコミットを作成してしまいます。 このようなミスオペレーションを防止するため、Wiplock という、小さ
GitHub flow - GitHub Docs
Introduction GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers. For example, here at GitHub, we use GitHub flow for our site policy, documentation, and roadmap. Prerequisites To follow GitHub flow, you will need a GitHub account and a repository. For information on how to create an account, see "Creating an account on GitHub." For info
Pull Request発行時にそのコミットIDでデプロイされた環境を自動構築してレビュー時/マージ前に確認しやすくする仕組み - トレタ開発者ブログ
インフラをアレしてる佐野です。Pull Request(以下、p-r)が発行されると、そのp-rのコミットIDでデプロイされた環境を自動構築する仕組みを作ったので、今日はそれについて。マージ直前の環境が立ち上がるのでレビューアはレビュー時にコードを追うだけでなく、ブラウザ/アプリの接続先をこの環境に向きかえることで実際のアプリケーションの動作も確認できるようになります。レビューが非常に捗ります。 動作 仕組み GitHubのWebhookについて 自動構築の処理 Dockerの活用 tmpfsの活用 まとめ 1. 動作 こんな感じです。ここで、この通知するボットおよびこの仕組みを以下、シャイニング・ウィザードと呼ぶことにします。シャイニング・ウィザードというのは好きなプロレスの技でして最初はこの基盤の仮名だったのですが、チーム内で定着してしまったのでもうこれでいいや的な…。ちなみに、Ama
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mergify - CI/CD pipeline optimizer
組織全体でGitHubを使うようになるまで / Everyone Can Use GitHub Issues
GitHub - mzp/prpr: GitHub pull requests' reaction bot
コミュニケーションツールとしての Git & GitHub
crocos.jp
OSS と GitHub
GitHub - DavyJonesLocker/party_foul: Use GitHub to track your application errors!
SSSSLIDE
