サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは！「家族アルバム みてね」（以下、みてね）SREグループのおじまです。 今回は、みてねの開発プロセスを支えるデプロイパイプライン、特にブランチ戦略を改善し、ステージング環境における占有問題などの課題を解決したお話をご紹介します。 みてねの開発フローとこれまでの課題みてねでは、ブランチ戦略としてGitHub Flowを採用しています。GitHub Flow では、はじめにメインブランチからフィーチャーブランチを作成します。フィーチャーブランチで機能開発を行った後、プルリクエストを作成します。フィーチャーブランチは、プルリクエストにおけるコードレビューを経て、メインブランチにマージされます。メインブランチは常にデプロイ可能な状態に保たれます。GitHub Flowは、シンプルで分かりやすいのが特徴です。 しかし、GitHub Flow自体には、本番環境以外へのデプロイ方法について明確
はじめに本当に悔しいし許せないし、エンジニアとして不甲斐ないです。2025年2月26日深夜にハッキングにあいました。どのように相手と繋がり、どのような手口でハッカーに資産を抜かれたか、コードベースで全てお伝えします。今後同じ被害に遭う方が少しでも減ることがあればこんな嬉しいことはないです。 コード解説、さらに対策案も書いていきます。もし他に良い対策案などあればコメントでご教示ください。ハッカーとのやりとりの流れハッカーとは Linkedin でブロックチェーンを使ったプロジェクトを手伝ってくれないかという連絡がりそこからやりとりが始まりました。そして移行の大まかな流れは下記のような感じです。 Linkedinでプロジェクトを手伝ってほしいと言う内容でDMがくるGithubリポを見て実装できそうか確認してほしいと言われる 自分のGithubアカウントを共有してプライベートリポジトリに
この四半世紀に構築されたレガシーシステムによって、DX（デジタルトランスフォーメーション）の推進が妨げられる「ITロックイン」が起きている。ITロックインを解決すべく戦略を立案するためには、企業システムを構成する6つの技術群を理解しておく必要がある。 その技術がなぜ生まれ、どう活用され、逆にどのような問題があるのかを理解することがITロックインから逃れるカギの1つとなる。そこで本特集では6つの技術群のうち2000年代後半に登場した「クラウドとDevOps」を解説する。2024年12月発売の書籍『DXリーダー必修講義 6つのキーテクノロジー』（日経BP）から抜粋した内容を掲載する。アジャイル開発が普及し、開発部門のリリースの頻度が高まる一方で、運用部門は障害を発生させないために慎重なリリースを求める。開発部門と運用部門は分かり合えない――。 「DevOps」誕生のきっかけとなった米Flic
GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される 大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。 さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。 最後にワークフローのCron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーがCron スケ
AWSでチーフエバンジェリストを務めるジェフ・バー氏は、2024年7月30日のX（旧Twitter）への投稿の中でこの変更を認め、AWS CodeCommit、「AmazonSimple Storage Service」（Amazon S3）の「SelectSQL」機能、マネージド検索サービス「Amazon CloudSearch」、IDE「AWS Cloud9」、データベースサービス「AmazonSimpleDB」、時系列データ分析サービス「Amazon Forecast」「AWS Data Pipeline」で新規ユーザーを受け入れていないことを確認した。 バー氏は、現時点ではこれらのサービスを廃止する予定はないが、新機能は追加せず、AWSの代替機能や他社のサービスへの移行をサポートする予定だと述べている。また、既に同サービスを利用している顧客のサポートは継続するという。 同氏は
TortoiseGitで、GitHubからリポジトリをクローンしようとしたとき、以下のエラーメッセージが表示された。 git.exe clone --progress -v "https://github.com/XXX/OOO.git" "C:\Users\@@@\Desktop" Cloning into 'C:\Users\@@@\Desktop\OOO'... remote: HTTP Basic: Access denied fatal: Authentication failed for 'https://github.com/@@@/@@@.git/' gitは正常に終了しませんでした (終了コード 128) (68485 ms @ 2019/04/01 23:15:48) なにやら認証に失敗している様子。 セットアップの最中にユーザ名とパスワードを求められたが、どうやらタイ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Git にせよAWS CLI にせよ、プロキシや証明書まわりの設定は（特に会社から使う場合だと）面倒で、よくわからなくて、毎度ググりながらテキトーにしていた。けど、いいかげんちゃんとするべきだと思ったので、気合入れて調べた＆まとめた。 知識として押さえておくこと 設定対象は二つある。 プロキシを適切に設定する必要がある CA 証明書を適切に証明する必要がある 設定箇所は手段ごとに違う。 ツールによって設定箇所が異なる(ので適切な設定箇所に設定する必要がある) 例: Git の場合はここ、AWS CLI の場合はここ、Python の
You are in the right place if you're trying to use git clone on a computer and running into one of the followingerrors: SSLcertificate problem: self signedcertificate incertificate chain SSLcertificate problem: unable to get local issuercertificate A popular workaround is to disable SSL Verification using git config --global http.sslVerify false but thatcreates largesecurity risks. SSL is
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
GitHubでマルウェアを仕込んだリポジトリを本物に見せかけて拡散させる手口が横行し、10万を超す感染リポジトリが見つかっているとしてサイバーセキュリティ企業が注意を呼びかけている。攻撃は今も続いており、何も知らない開発者がこうしたリポジトリを使えば、マルウェアに感染してパスワードなどの情報が流出する恐れがある。 サプライチェーンのセキュリティ対策を手掛ける米Apiiroによると、GitHubのリポジトリを狙う「リポコンフュージョン（取り違え）攻撃」は2023年11月ごろから激化したという。 攻撃者は、開発者をだまして悪質なコードやファイルをダウンロードさせる目的で、正規のリポジトリのクローンを作成。そこにマルウェアを呼び出すコードを仕込み、同一の名称でGitHubにアップロードする。次に自動化の仕組みを使ってそれぞれを何千回もフォークさせ、Web上のフォーラムなどで宣伝しているという。
いつのまにかSSH鍵生成時のデファクトスタンダードが変わっていた 気付いた発端 実は前回の記事「VertexAI WorkbenchとGitHubの繋ぎ込み」を書いている時に、GitHubのドキュメント「新しい SSH キーを生成して ssh-agent に追加する」を参照していたら、気になる記載が… ssh-keygen -t rsa なんてもう皆が何でも無いときにでも打ってしまうようなフレーズだと思っていたらいつのまにか ed25519 なるものが推奨されていたという衝撃。 調べて見るとここ数年はRSAよりEd25519のほうが強固だからそっちを使おう、みたいな話がたくさんヒットしてきて完全に乗り遅れていたことがバレてしまいました… せっかくなので、本記事では rsa と Ed25519 で何が違うかについて調べながら書いてみます。 ssh鍵生成の方式 とりあえずマニュアルで全方式を
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgitswitchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
GitHub のAutomatically generated releasenotesを使ってリリースノートの内容を PR に基づいて自動生成するフローを作りました。 今までは、コミットメッセージのルールであるConventional Commitsとconventional-github-releaserを使って、コミットからリリースノートを自動生成していました。 他の人の PR でも、squah merge でコミットメッセージを書き換えることで、リリースノートに反映されるようにしていました。 ただGitHub に仕組みは違うけどほぼ似たことをするAutomatically generated releasenotesという機能が実装されているので、これをベースに移行しようと思って、そのワークフローを作っていました。 リリースノート自動生成テクニック - mizdra’sbl
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
数えてみたら意外と数あったのでまとめます。 release-pleaseGoogle謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
はじめに 今回の記事では、私たちプログラマーが開発や学習を進める中で必ず確認しておくべきGitHubリポジトリを20紹介する。今回の記事の対象は主に以下の通り。 開発・学習に必要な情報を収集しているプログラマーGitHubを開発・学習の参考にしたいプログラマー 情報収集の方法がわからないプログラマー freeCodeCamp 世界最大規模のプログラミングメディアであるfreeCodeCampのGitHubリポジトリ。扱う内容はWeb開発、モバイルアプリ開発やデータサイエンスなど非常に幅広い。特にPythonやReact、Node.js、Flutterを実務で扱うプログラマーは必見。 最大の特徴はGitHubリポジトリの名前にあるように完全無料で学べることだ。初心者から上級者まで毎日確認するべきGitHubリポジトリ。 free-programming-books ネット上にあるすべての無
Noteプロジェクトには、最大で 50,000 個のアイテムと 10,000 個のアーカイブ済みアイテムを含めることができます。 アイテムのアーカイブ アイテムをアーカイブして、そのアイテムに関するコンテキストをプロジェクト中に保持しながら、アイテムをプロジェクトのビューから削除できます。 特定の抽出条件を満たす項目を自動的にアーカイブするように、プロジェクトのビルトイン ワークフローを設定できます。 詳しくは、「アイテムを自動的にアーカイブする」をご覧ください。 テーブルまたはボード レイアウトを使用している場合は、まず項目を選択します: テーブル レイアウトで、行番号をクリックします。 ボード レイアウトで、カードをクリックします。 複数のアイテムを選択するには、以下のいずれかのようにしてください。 command (Mac) または Ctrl (Windows またはLinux)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
