ブランチ戦略（GitHub Flow）を見直してステージング環境の運用を改善しました
こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
GitHub、コード中に書いてはいけないアクセストークンを発見、通知してくれる「Secret scanning」機能、プライベートリポジトリで正式対応
GitHub、コード中に書いてはいけないアクセストークンを発見、通知してくれる「Secret scanning」機能、プライベートリポジトリで正式対応 GitHubは、本来ソースコード中に書くべきではないアクセストークンなどを、コードやアーカイブから発見し通知してくれるSecret scanning機能がプライベートリポジトリでも正式な機能として利用可能になったことを明らかにしました。 Check out two new ways to ship secure applications with GitHub Advanced Security! Secret scanning for private repos is now generally available, and we've released the beta of our new security overview for
GitHubのサービスを駆使してウェブサイトの死活監視が無料で行える「Upptime」
ウェブサイトの死活監視サービスは数多く存在しますが、自分でサーバーを用意する必要があったり、監視対象が一定数を超えると有料になったりと、導入に障壁を感じる場合もあります。無料の死活監視ソフトウェア「Upptime」は、GitHub ActionsやGitHub PagesといったGitHubのサービスを使って、簡単にウェブサイトの死活監視を行うことができます。 Upptime https://upptime.js.org/ GitHub - upptime/upptime: ⬆️ Uptime monitor and status page powered by GitHub https://github.com/upptime/upptime UpptimeはGitHub Actionsで5分ごとにウェブサイトの死活監視を行い、ウェブサイトがダウンした場合はGitHubのIssuesに報
Pull Request発行時にそのコミットIDでデプロイされた環境を自動構築してレビュー時/マージ前に確認しやすくする仕組み - トレタ開発者ブログ
インフラをアレしてる佐野です。Pull Request(以下、p-r)が発行されると、そのp-rのコミットIDでデプロイされた環境を自動構築する仕組みを作ったので、今日はそれについて。マージ直前の環境が立ち上がるのでレビューアはレビュー時にコードを追うだけでなく、ブラウザ/アプリの接続先をこの環境に向きかえることで実際のアプリケーションの動作も確認できるようになります。レビューが非常に捗ります。 動作 仕組み GitHubのWebhookについて 自動構築の処理 Dockerの活用 tmpfsの活用 まとめ 1. 動作 こんな感じです。ここで、この通知するボットおよびこの仕組みを以下、シャイニング・ウィザードと呼ぶことにします。シャイニング・ウィザードというのは好きなプロレスの技でして最初はこの基盤の仮名だったのですが、チーム内で定着してしまったのでもうこれでいいや的な…。ちなみに、Ama
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
Compass - GitHubのコードブラウジングを快適にしてくれるGoogle Chrome機能拡張 MOONGIFT
GitHubのファイルブラウザは良くできているので、ライブラリをわざわざダウンロードすることなく動作を確認するのに便利です。しかしライブラリによっては多くのディレクトリに分かれているため、ナビゲーションが面倒に感じることもあります。 そこで使ってみたいのがCompassです。Google Chrome向けにスムーズなGitHub上のナビゲーションを提供します。 Compassの使い方 Compassを使うには任意のGitHubリポジトリにてコマンド+K（Windowsの場合はCtrl+K）を押します。そうするとフローティングが表示されますのでファイルのパスを入力していきます。 ファイルを選択してエンターキーを押せばそのファイルが表示されます。 実際に操作しているところです。結構スムーズなのが分かるかと思います。 Compassを使えばGitHub上でのファイル移動やコードのブラウジングがと
Github Markdown CSS - for Markdown Editor Preview
github.css � �HV ��9�HV body { font-family: Helvetica, arial, sans-serif; font-size: 14px; line-height: 1.6; padding-top: 10px; padding-bottom: 10px; background-color: white; padding: 30px; } body > *:first-child { margin-top: 0 !important; } body > *:last-child { margin-bottom: 0 !important; } a { color: #4183C4; } a.absent { color: #cc0000; } a.anchor { display: block; padding-left: 30px; margi
GitHub実践入門、Pull Requestによる開発の変革。GitHub Kaigi 2014
GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。GitHubを利用した開発は、スタートアップやオンラインサービス系の企業などを中心に広まりつつあり、いままさに数多くのノウハウの交換が求められているツールでもあります。 本記事ではGitHub Kaigiの最初のセッションとなった大塚弘記氏の「GitHub実践入門 ─ Pull Requestによる開発の変革」の内容をダイジェストで紹介します。 GitHub実践入門 ─ Pull Requestによる開発の変革 大塚弘記といいます。会社でもリアルでもほとんど@hirocasterと呼ばれています。 今日はメッセージを3つ持ってきました。まず、GitHubを使っている世界と使っていない世界についての話を少し。次に、GitHubを使っているけれど、十分に使っているかどうか、という話をして、最後に本
pjax を利用したサイト向けの Chrome Extension の書き方 - @kyanny's blog
Chrome Extension の Content Scripts を使うと Greasemonkey のようにウェブサイトを加工できて便利だが、 Content Scripts はページのロード後に一度だけ実行されるので、 github.com のように pjax を利用しているサイトではページ遷移後に期待通り実行されないことがある。 pjax は pjax:success などの独自イベントを発火するが、 Content Scripts はサンドボックス環境で実行されるので pjax が発火するイベントを Listen することができない。しかし DOM の変更時に発生するイベントを Listen することはできる。 DOM の変更を検知するためには DOMSubtreeModified が利用できるが、このイベントは DOM Level 3 で deprecated になってしまっ
GitHub実践入門が3/20発売 現場で使える実用的なガイド | Act as Professional - hiroki.jp
本書は、世界中の開発者が行っているGitHubを利用した開発方法を、みなさんが現場で使えるようになるためのガイドとして執筆しました。よって、GitHubの解説だけにとどまらず、開発ワークフローやそれを支えるほかのツールにも踏み込んで解説しています。 現場で使えるノウハウが凝縮されたGitHubのガイド 本書は現場でGitHubを徹底的に活用するために、UIの解説、Gitの操作、実際に手を動かしながら試せるPull Request、開発ワークフロー（GitHub Flow, Git Flow）の解説、Jenkinsなど開発を支えるツールのGitHubとの連携について丁寧に執筆しました。こちらで目次が公開されています。GitHubを今まで使っていた人も、こんなのあったの？ってなるようなTipsなどもちりばめました。 GitHubを使ってPull Request文化の開発をどうやるべきなのか開発
JenkinsプラグインのGitHub pull request builder pluginを使ってみる - 技術めも
現在、GitHubのPull Requestでコードレビューし、問題なければマージするというフローで開発しているのですが、 コードは問題なさそうなのでマージしてみると、specが落ちている・・といったことがありました。 そこで、Pull Requestされた時点でそれをマージしspecを実行してくれる、そしてその結果を通知してくれる といったことが自動でできれば良いなと考えていました。 そこで発見したのがGitHub pull request builder pluginというJenkinsのプラグインです。 このプラグインは、以下のようなことをやってくれます。 Pull Requestされた（またはそのPull Requestにコミットを積み重ねた）時にそれを検知し、自動でマージしビルドしてくれる （実際はcrontabで設定したタイミングで） GitHubのPull Requestペー
Scala の開発に学ぶコードレビュー体制とプロジェクト開発 - xuwei-k's blog
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が（ソースコード上で直接）コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
githubのURLを貼るときに気をつけていること - xuwei-k's blog
結論から先にいうと、みんなgithubへの URL のリンク貼るときに、masterのbranchへのリンク*1貼ってることがほとんどだけど、それって微妙にあとから不便になるから、特定のtreeかtagへの参照を貼りませんか？っていう話 いまの一文で意味わかる人は以下の文章読む必要ありません。以下詳細な説明 githubでのそれぞれのプロジェクトのトップページは、デフォルトだとmasterのbranchを表示します。ちなみにこれは設定から変えられます( tag は無理っぽい? ) 例えば、 specs2はトップページのデフォルトが1.6のbranchになっています https://github.com/etorreborre/specs2 今書いたことは、プロジェクトの管理者側の話で、直接関係ないです。*2 で、ここから本題というか言いたいことですが、 githubは、左の行番号表示の部分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubを快適にブラウジングするための3種の神器
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
Coveralls.io - Test Coverage History and Statistics
GIG