GitHub Organizationの安全な運用とモニタリングに関するスライド（全44ページ）を無償公開しました - Flatt Security Blog
はじめに こんにちは、株式会社Flatt Securityプロダクトマネージャーの小島です。Shisho Cloud というソフトウェアサプライチェーンに関するセキュリティ上の問題の発見から修正までを包括的にサポートする開発者向けセキュリティツールを開発しています。 shisho.dev 本日はこのサービスに関連して、GitHub Organizationを安全に運用していくためのベストプラクティス、そしてそのベストプラクティスがきちんと開発組織の中で運用されているかをモニタリングする方法についてまとめたスライドを公開しました。 スライドは下記のSpeakerdeckのURLより無料/登録不要で閲覧/ダウンロードいただけます。 https://speakerdeck.com/flatt_security/2022-github-org-best-practices この記事では、そのスライ
趣味の開発で使えるGitHubのブランチ運用 - t-hom’s diary
今回はGitHubの話。 基本的な使い方は入門書がいくらでも出ているので今更私が解説するまでもないけど、ブランチ運用については腑に落ちるまで少し苦労したので今回は自分流のブランチ運用をメモとして残しておこうと思う。 ガチの開発勢から色々と文句を言わるかもしれないけど、趣味開発なのでご容赦願いたい。 thomの2ブランチ開発フロー 私は次の表の1～8のような流れで開発を進めている。 このブログの読者はExcelマクロ開発者が多いのでバージョン管理システムを使わないExcel開発を例えとして挙げてみた。対比させるとGitでやっている作業が何をしているのか少しは分かりやすいかなと思う。 本来は2～4を繰り返してこまめにdevブランチを更新しつつ、ある程度キリの良いところで充分にテストをしたうえでmasterへ取り込むんだけど、なんせ一人で開発していてユーザーも大抵自分ひとりというケースが多いので
Terraform Cloud から GitHub Actions に移行したお話
スタディスト開発ブログ Advent Calendar 2021の13日目の記事です。 こんにちは、SRE Unit の wind-up-bird です。以前、 Serverless Framework を移行しているお話を書きましたが、今回は移行シリーズ第2弾ということで、 Terraform Cloud を Terraform on GitHub Actions に移行したお話をお届けしたいと思います。 # 移行前の運用スタディストではこれまで Terraform Cloud の Team & Governance プランを契約していました。移行前の Terraform による開発の流れは、以下のとおりです。 Terraform Cloud 上で Workspace を作成し、Version control workflow を利用する。Workspace には環境変数として、 AWS
GitHub Actionsを使ってコンテナ版AWS Lambdaにデプロイしてみた | DevelopersIO
GitHub Actionsを使い、コンテナイメージをAmazon ECRにプッシュし、AWS Lambdaにデプロイする方法を紹介します。 GitHubからAWSへの認証では、OpenID Connect(OIDC)を利用します。 本ブログでは、GitHub Actionsを使い、main ブランチへの push をトリガーにコンテナイメージをビルドしてコンテナレジストリのAmazon ECRにプッシュし、AWS Lambdaにコンテナイメージをデプロイする方法を紹介します。 実質的にやっていることは、GitHub の ECS 向けドキュメントをベースに、以下の変更を加えています。 GitHub から AWS への認証に、IAMアクセスキーの代わりに OpenID Connect(OIDC)を利用 デプロイ先をAmazon ECSからAWS Lambdaへ変更 大前提として、デプロイのゴ
エンジニアの採用情報をまとめた GitHub Repository を公開しました #GameWith #TechWith - GameWith Developer Blog
ごぶさたしています。@serima です。 このたび GameWith では採用情報をまとめた GitHub Repository を公開しました。 github.com 採用に関する情報の分散化問題 GameWith ではエンジニアを積極採用中ですが、いざ採用候補者の立場にたってみると情報が各所に分散しており、せっかくの情報発信が十分に届いていないのではないかと感じていました。 たとえば年単位で運用している技術ブログの記事のなかで、どれが現在の会社の雰囲気や開発スタイルを適切に伝えているものなのかは外からでは分かりません。 さらに昨今は、採用にまつわる情報があらゆる媒体に分散して掲載される傾向があり、候補者視点では情報の収集も一苦労です。 特に、なかの人のインタビュー記事は自社運用の Wantedly や外部の求人媒体などそれぞれで掲載されたりする傾向が強いように思います。 さまざまな媒
Serverless Framework & DockerによるローカルフレンドリーなLambda開発・運用
会社のチームメンバーにLambdaの開発・デプロイ方法について共有するために書いた記事ですが、Lambdaを触ったことない人にも有益そうな内容なので、Zennに投稿してみました🙏 今回作りたいLambda 指定したS3バケットに画像がアップロードされたら、リサイズして同じまたは別のS3バケットにアップロードする 完成リポジトリ https://github.com/samuraikun/image-resizer-lambda-serverless Runtime Ruby2.7 前準備 AWSアカウントが作成済み、AWS CLIインストール済み アクセスキーIDとシークレットアクセスキーを事前に設定する必要あり Serverless Framworkについて Lambdaをデプロイするまでに必要な各設定を簡単にできるツールです。 他にも、AWS公式のSAMやTerraformなど他のl
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応 GitHubは大規模な組織での利用にも対応したソースコード管理ソフトウェアの新版「GitHub Enterprise 2.5」のリリースを発表しました。 GitHub Enterprise 2.5の最大の変更点は、大規模な開発チームでの利用にも対応するようにクラスタリング構成によるスケールアウトが可能になったことです。 ただしクラスタリングは非常に大規模な運用向けに特別に設計されているため、管理リソースの追加も必要となるとのこと。 また、GitHub Enterprise 2.5では内部的にキャッシュインテンシブな処理を実現し、大量の開発プロジェクトを抱えていたり、大規模な継続的インテグレーションなどによって集中的にソースコ
ラクスルの開発フローについて - RAKSUL TechBlog
ラクスルのWebシステムの開発・運用を行っている大嶋です。 今回はラクスルの開発フローで利用しているツールと利用方法についてご紹介します。 1. GitHub GitHubとはGitリポジトリを利用した、プロジェクトやソースコードの管理を行うためのホスティングサービスです。 ラクスルではざっくり以下のような流れでGitHubを運用しています。 1. 機能単位でブランチを切る 2. 開発完了後にプルリクエスト 3. レビュー 4. 問題なければmasterブランチへのマージ 5. マージ後に機能ブランチを破棄 2. Redmine Redmineとはオープンソースのプロジェクト管理ツールです。 ラクスルではエンジニアだけではなく事業系、管理系の部署メンバーも含め社内全体でRedmineを利用しています。 特にエンジニアによる開発が伴うチケットの場合には、上述したようにGithub上で新規ブラ
Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する：Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）（1/2 ページ） 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow／GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
時雨堂を支える Slack 運用方法
Pull Request ベースのインフラ運用と Cookbook CI