Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報(sensitive data)について調査を実施し、対応
この講義ノートについて これは、理工学部の三年学部生向けのGit/GitHubを用いたソフトウェア開発演習のための講義ノートである。概ね一般的な記述となっているが、一部に大学のPC室特有の記述があるので、他大の方が利用される際は注意されたい。4回の座学、4回の実習の、計8回の講義/演習で学ぶ構成となっている。 なお、この講義ノートを元にした書籍が出版されている。 ゼロから学ぶGit/GitHub 現代的なソフトウェア開発のために はじめに 座学 バージョン管理とは 講義スライド バージョン管理システムとは バージョン管理システムの歴史 プログラミングができる人、できない人 Gitの仕組みと用語 講義スライド プロジェクト リポジトリとワーキングツリー コミット インデックスとステージング HEADとブランチ マージ コマンドラインの使い方 講義スライド シェルとコマンドライン Unixコマ
簡単な自己紹介 渋谷のとあるプログラミングスクールを経営する会社でCTOを担当しています。 昨年、2019年3月にこの会社にジョインしてから開発から新商品企画まで幅広く担当してます。 背景 2019年3月に私が入社した時、システム開発の案件管理に色々と問題がありました。 それらの問題を各ステークホルダーにヒヤリングして問題点と解決案をまとめて社長に提案し、社長の賛同を得て開発体制の構築を進めてきました。 この度、ようやく開発体制の構築ができて順調に開発案件の管理、運用できるようになってきたので、今回、他の会社の参考になればと思ってまとめてみました。 弊社の組織体制 組織としては、CEO(社長)をトップとして、以下チームが下にある形です。 私は、CTOとして開発チームのマネージャーを担当しています。 開発体制の問題点をステークホルダーの声を聞いて整理した 問題の解決にあたって、まずは各ステー
はじめに githubのコラボレーションには、 チームメンバーでプロジェクトリポジトリを共有する 個々の開発者がプロジェクトリポジトリをforkする の2つの方法があると思います。 OSSプロジェクトのような見知らぬ人とコラボレーションするプロジェクトの場合はfork一択ですが、社内で使うときや外注先との共同作業などのときはどうするのが良いのでしょうか? リポジトリ共有の場合 プロジェクトリポジトリ内にブランチが作られるので、マージ済みのブランチは定期的に削除するなどしないと、リポジトリのサイズが肥大する。 権限の管理ができない。基本的にプロジェクトリポジトリ内のすべてのブランチの権限がチームメンバーに与えられる。protected branchesに設定することもできるが、個々のブランチごとに設定する必要がある。protected branchesに設定すると、プルリクエストによる承認を
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
Zenhub Enterprise Server brings the power of Zenhub on-premise.
あらすじ Githubのissueでプロダクトバックログを作ってみようでプロダクトバックログを作ることができたので、次はスプリントバックログを作ってみよう。 我々はスプリントプランニングを行っている想定である。 前半はスプリントバックログを作るため今スプリントに完了するユーザーストーリーについてPOと合意を取る。 後半はスプリントバックログのタスクを洗い出して見積もる。 issueでどうやってスプリントとタスクを表現することができるかがポイントかな。 マイルストーンを設定する マイルストーンでスプリントを表現する。 期限として、スプリントの終了日を設定する。 Descriptionにスプリント期間はいつからいつまでって記載してもいいかも。 4スプリント分作ってみた。 スプリントバックログを作る スプリントプランニングで、ユーザーストーリーにマイルストーンを設定するだけ。 マイルストーンでフ
#あらすじ 実はGithubのissueって使い道がよくわからず、 今の職場ではTodoタスクを積み上げる感じになっているので、これじゃ勿体無いと思い使い道を探してみた。 プロダクトバックログに必要なのは ユーザーストーリーの優先順位の変更 ができること。 issueは並べ替えができないものの、並べ替えをする方法があった。 つまり、プロダクトバックログ作ることができるのだ。 でも、手法は実に原始的。 しかし、手法は問わないのがアジャイルである。 というわけでやってみよう。 #ラベルを作る 「product backlog」というラベルを作る。 「user story」というラベルを作る。 #プロダクトバックログのissueを作る issueを作って「product backlog」のラベルを貼る。 #ユーザーストーリーを作る こんな感じで。 「user story」のラベルを付ける。 受け
⚠ This page contains old, outdated, obsolete, … historic or WIP content! No warranties e.g. for correctness! All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Please use the correct (perma)link to bookmark this article, not the page listing all wlog entries of the last decade. Thank you.</update> Some updates inline and at the bottom
こんにちはー!こねひとちほーのえんじにあのフレンズ@Utmrerだよー! 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…? タイトルにIssue Idを含めてもらえますか? WIPみたいなんですがレビューして大丈夫ですか? Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
BeforeGitHub Enterprise is the on-premises version of GitHub.com that you can deploy a whole GitHub service in your private network for businesses. You can get 45-days free trial and download the VM from enterprise.github.com. After you deployed, you will see like bellow: Now, I have all the GitHub environment in a VM. It’s interesting, so I decided to look deeper into VM :P EnvironmentThe beginni
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く