デプロイ対象環境ごとに別々のSlackチャンネルに通知するGitHub Actionsの実装例 - KAYAC engineers' blog
SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変
GitHub Copilotの全社導入とその効果 - ZOZO TECH BLOG
はじめに こんにちは、CTO/DevRelブロックの堀江（@Horie1024）です。ZOZOではGitHub Copilotを全社へ導入しました。本投稿では、GitHub Copilotの導入に際して検討した課題とその課題の解決策としてどのようなアプローチを取ったのかを紹介します。 目次 はじめに 目次 GitHub Copilotとは何か？ GitHub Copilot導入の背景と目的 導入する上での課題 セキュリティ上の懸念 ライセンス侵害のリスク GitHub Copilot for Businessの利用 導入による費用対効果 試験導入による費用対効果の見積もり 試験導入の実施 対象者の選出 アンケートの設計 試験導入の実施 アンケート結果の集計 アンケート結果の考察 費用対効果の見積もり 全社導入の判断 導入決定後のGitHub Copilot利用環境の整備 社内LT会 おまけ
Google Cloud の Workload Identity 連携でGitHub Actionsから認証する | Marginalia
いまさらだが、秘密鍵を共有する方法ではなく、GitHub Actions のOIDCトークンを使った方法を使ってGCPの認証を有効にしてみたので、その作業メモ。 基本的には Google Cloud Blog に書いてあるとおりのことをやっただけだが、ほとんどのドキュメントが gcloud コマンドを使った設定手順しか説明していないので、あえてWebコンソール上で同等の操作を読み解いて作業した。 GCP: Workload Identity プロバイダの作成下の図でいうところの Cloud Provider を準備する。GCPではこの部分が IDプロバイダ と、それのコンテナになる Workload Identity プール という2つのリソースからなる。 手順は4つある。 Workload Identity プールを作成する プールに IDプロバイダ を追加する IDプロバイダ と Gi
リリースノート管理術
みなさま、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署名付きでコミットしてかっこつける
署名とは このようにVertifiedと書かれたコミットを見たことがありませんか？ かっこよ！！！ 調べてみると公式のヘルプページにはこう書かれていました GPG あるいは S/MIME を使って、タグやコミットにローカルで署名できます。 それらのタグやコミットは検証済みとして GitHub上でマークされ、他の人々がその変更が信頼できるソースから来たものと信頼できるようになります。 つまり、「これは信頼できるコミットだよ」って表現することができるということですね。（かっこつけるためではないようです）と そもそも、署名を行わない場合GitHub側でクライアントとGitHubアカウントとの紐付けをメールアドレスの一致のみで行います。もし、Gitに他人のメールアドレスを設定した場合そのメールアドレスを持ったGitHubアカウントと紐付けられます。 ここで、自分のアカウントと署名を紐付けることで自
GitHub Discussionsでチームの暗黙知を共有する
Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！ この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！ Tebiki社のDiscussionsとは？Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus
GitHub Actions で簡単にバージョン番号付きリリースとリリースノートを作成する方法
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1: GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
昔作ったGitHubのLabelを供養する
はじめに ⚡ 昔、あるプロジェクト用にGitHubのLabelをいくつか作成しました。 作ったものの、上手いこと使いこなせてなかったのでこの記事で供養したいと思います。 合掌🙏 そもそもラベル機能って何？ 🧐 IssueやPull Requestを分類するための機能です。 新規Repositoryを作成したらデフォルトで用意されています。 プロジェクトで作成したIssue, PRにラベルを適用することで、 参照時にフィルタリングを行えたりできます。 ラベルの追加、編集、削除はもちろん可能です。 Organizationの場合は、 全Repositoryのdefault Labelを管理することもできます。 GitHubのdefault Labelはこちら ラベル作る必要ある？ 🤔 デフォルトのもので十分だと思います。 またラベルを使わない選択肢もありかもしれません。 本件では「チケッ
プルリクレビュー必須にしてやった - もがき系プログラマの日常
参考サイト https://dev.classmethod.jp/tool/github/protect-branch/ はじめに 先日、お世話になっている会社のあるエンジニアさんが、緊急ということでプルリク後セルフマージするという事がありました。 そのエンジニアさんはドメイン知識も豊富な頼れるエンジニアさんなので、その方のセルフマージは許せますが、経歴が若いエンジニアさんにそういうことをやられると困ります。 なんか制限できないかなーといろいろ調べてたら、参考サイト様に出会いました。 ちょっとやってみます。 やってみた 参考サイト様におんぶにだっこでやってみます。 まずレポジトリの Setting から Branches を選択します。 Branch protection rules で 保護するブランチを選択します。 まぁ大体のプロジェクトは master かなと。 選択すると以下のよう
GitHub Container registry が GA したので触ってみる
GitHub Container registry とは GitHub Packages を構成する1つで Docker を始めとしたコンテナを扱えるレジストリです。 Docker registry (docker.pkg.github.com) から Container registry (ghcr.io) へ統合されました。 パブリックコンテナへの匿名アクセス コンテナの Organizational レベルの所有権 コンテナのきめ細かいパーミッション制御 有益な情報が豊富なコンテナ用ランディングページ コンテナの可視性はリポジトリの可視性から独立 Organizational におけるコンテナの内部的な可視性設定 GITHUB_TOKEN による Actions ワークフローからコンテナへのセキュアでシームレスなアクセス Container registry (ghcr.io) へパ
GitHubで会社用とプライベートアカウントを分けよう(問題ないよ)
普段使うサービスで、会社用のアカウントとプライベートのアカウントを分けると便利でセキュアですよね？うっかり間違って仕事のデータを大公開してしまうリスクも小さくなります ただ、日本国内では、アカウント分離はNGで、個人ごとに1つのアカウントに集約しないと規約違反であるという言説が広まっているようです。 認識共有用に頑張って書いた図。指摘歓迎ですそこでGitHub Supportに事実を確認したところ(英語)、規約違反ということはないという話でした。会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば、各自のプライベートアカウントは無料でOKです。 ロジックとしては、オーガニゼーションに所属させているアカウントは有償コーポレートアカウント(名称仮)なので、個人アカウントに対する無料アカウントの複数所持禁止条項は無関係となります。 該当条項 One person or l
GitHub Actions を使ってリリース時のあれこれを自動化する
GitHub Actions を使ってリリース時のあれこれを自動化する 結論 リリース時のタグとリリースノートを自動で生成するようにした リリース時に自分がやることは 動作確認 => Merge pull request を押すだけにした なぜやるのか Release ノートを手動で作るのは面倒 手動でやることには人為的なミスの恐れがある 面倒なことを続けるとモチベーションが低下する(これ重要) 要件 リリース リリースは週に1度行う リリース前に開発した PR をリストで見ながら動作確認をしたい PR のリストがそのままリリースノートに記載されて欲しい 自動化 タグの作成は手動でやりたくない リリースのための PR を手動で作りたくない リリース時のバージョンを手動で入力したくない 自動化の必要性を感じたきっかけ 都内でシステムエンジニアをしている itizawa です。 理想のブックマ
GitHub の Pull Request の差分から変更されたファイル名一覧を抜き出す
こんにちは、kenzauros です。 資料をまとめたりするときに使えるかもしれない、ちょっとした小ネタです。 Git で差分のあるファイル名を抽出するには git diff を使えばいいのですが、そのファイル名を使ってごにょごにょ加工したい場合、（私は）JavaScript のほうが便利なので、 GitHub の Pull Request を利用することにしました。 やりたいこと ちなみに git diff コマンドでコミット間の変更ファイル名一覧を取得するのは下記のようにします。 diff-filter=d オプションで「削除以外」、 name-only でファイル名のみ、 origin/master と HEAD の差分を抽出します。 これでずらずらーっとファイル名が得られます。 が、このあとこの一覧を加工しようと思うとシェルスクリプトや PowerShell でごにょごにょしなけれ
GitHub経由で海外から仕事が来た話 - その後のその後
はじめて海外から（フリーランスとして）仕事をいただく、という貴重な経験ができたので、その経緯などを書いてみたいと思います。 きっかけ 7月末のある日、知らないメールアドレスから英語のメールが来ました。内容を一部だけ抜粋すると、 We are looking for someone to develop a very simple apple watch app and a companion apple phone app. というわけで、Apple Watch アプリをつくって欲しい、とのこと。内容を読むと加速度センサとジャイロを使いたいそうで、必然的に watchOS 2 案件になりそうです。 メールには明記されてませんでしたが、GitHub で公開している watchOS-2-Sampler を見て連絡くれたのかなと。（※もちろん面識はなく、共通の知り合いもいないので、これ以外にわざ
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
mixiの新人研修トレーニングが非常にわかりやすくて実践的すぎる - Android Javascript iOS
mixiは新人研修用のトレーニングをgithubに公開しています。 公開していることは知っていたけれど、いざみてみると… とってもわかりやすく実践的！！！ 普通に参考書で勉強するよりも企業が公開しているものだから、より実践的という感じもします。 自分はこのAndroidTrainingをやっているのですが、最後に課題もあり、到達度や理解度もすごく把握できていい感じです。 READMEもかなり充実しており、一通りを学べるように工夫されています。 mixiに入社した方がこれを一通りやったと思うと、大変な印象ですが…だからこそやったときに達成感がありそうです。 開発環境の構築から書かれているので、ほとんどつまづくことはありません。 かなり詳しくわかりやすく書かれている印象を受けました。 ちょっと初めて学習するには、難しい箇所もありますが適宜ぐぐって補えばよいでしょう。 ・AndroidTrain
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催、海外から来日した多くのゲストスピーカーによるセッションが行われました。 GitHubのJohn Britton氏は「Ops for Everyone」（みんなの運用）という題で、GitHub社内で開発から運用までをデベロッパー自身が行うためのツール、BoxenとHubotの紹介と社内の利用例を解説しています。 Ops for Everyone John Britton氏。 GitHubでエンジニアと教育の橋渡しをしています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - banga/git-split-diffs: Syntax highlighted side-by-side diffs in your terminal
Githubページを利用したブログを構築できる・「HubPress.io」
