GitHubの運用を「会社」にしていく話
Ubie DiscoveryでSREなどをしている@itkqです。 UbieではGitホスティングにgithub.comを使っています。プロダクト開発に必要なprivateなコードベースはもちろん、OSSや就業規則といったドキュメントをpublicにホストしたりもしています。また、この記事を書いている時点で、メインのOrganizationのメンバーは121名です。 自分が入社したのは一年前（2021年1月）で、まだ情報システム専任の人がいませんでした。それから今に至るまで、GitHubの運用を「会社」にしていく話を書きます。 一年前のGitHubの運用 当時、UbieのOrganizationに所属していた人数は、業務委託含め80〜90名ぐらいで、Businessプランを利用していました。私はSREとして入社しましたが、情報システム専任の人がおらず、SREをはじめとする何名かのメンバーが
GitHub Actions の Workflow を高速化する - Qiita
はじめに Github Actions の Workflow を高速化する方法を解説します。 解説はフロントエンドのデプロイワークフローを例にしますが、他にも転用できると思います。 前提 実行環境として Node.js、パッケージマネージャに Yarn を使ったプロジェクトを想定をします。 フロントエンドでは、デプロイするまでに行うこととして、主に以下の事項があります。 モジュールのインストール リンターによる静的チェック 各種テスト（Unit, E2E） ビルド デプロイ 基本的には、これらを事項について、ワークフローで上から行っていけばいいわけですが、プロジェクトが大きくなると、パッケージのインストールは遅くなり、静的チェックも時間がかかるようになります。よってこれらを高速化することを目指しましょう。 モジュールのインストールを高速化する モジュールのインストールを高速化することは、手
Dependabotで依存パッケージ更新のプルリクを作成してもらう - Qiita
はじめに 皆さん、依存パッケージのアップデートを定期的にしていますか？ 自分はGitHubのセキュリティアラートがきてからバーション確認をすることが多いです。。 そんな中、Twitterを見ていると依存パッケージ更新のプルリクを出してくれるDependabotというサービスがあるとのことでjavascriptのプロジェクトで試してみました。 Dependabotとは Dependabotは依存パッケージの更新を定期的にチェックし、更新があった際にプルリクエストを作成してくれるサービスです。 2019年の5月にGitHubにJoinしたことで無料で使えます😊 Dependabot is joining GitHub サポート言語 2019/07/15時点では下記言語がサポートされているようです。 導入手順 インストール GitHubのMarketplaceからDependabotを検索しま
GitHubの新機能「GitHub Actions」で試すCI/CD | さくらのナレッジ
GitHubが2019年11月、新機能「GitHub Actions」を正式に公開した。GitHub上のリポジトリやイシューに対するさまざまな操作をトリガーとしてあらかじめ定義しておいた処理を実行できる機能で、今まで外部サービスとの連携が必要だった自動テストや自動ビルドなどがGitHubだけで実現できるようになる。今回はこのGitHub Actionsについて、機能の概要や基本的な使い方などを紹介する。 GitHubだけでCI/CD的な機能を実現できる「GitHub Actions」 昨今では、ソフトウェア開発におけるさまざまな工程を自動化するような技術の開発や普及が進んでいる。その1つに、CI（Continuous Integration、継続的インテグレーション）やCD（Continuous Delivery、継続的デリバリー）と呼ばれるものがある。CIはソフトウェアのビルドやテストを
全社的に会社用GitHubアカウントを廃止した件 - ZOZO TECH BLOG
はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
GitHubで使われている実用英語コメント集
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
Issuesのラベルを管理（編集）する方法 - 22時に寝ようと思って2時に寝る。
最近、複数人でGithubを使ってコードを共有していて、Issuesを活用し始めました。 Issuesとは「重要事項、(提起された)問題」という意味で、主に「こんなの作りたいんだけどどうかな？」とか、「ここの動作がブラウザによって動きません」などの提案やバグ対応、課題の共有に使えます。 Issuesにはlabelsというのがあり、issueごとに意味を持たせるラベルを貼り整理することで、ラベルごとに検索できたりします。ブログでいうと、カテゴリーやタグみたいなものです。 ちなみに以下の通り、デフォルトでラベルが用意されています。 それぞれの意味については、 labels 意味 enhancement 機能追加。実装したらクローズ。 bug バグ。修正したらクローズ。 duplicate 他のイシューと重複している。重複先のイシューにリンクしてクローズ。 help wanted 助けが必要。解
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub English Challenge Cheat Sheet - Qiita
効果的にGitHubを使うために
GitHubを快適にブラウジングするための3種の神器