GitOps とデプロイ - Mitsuyuki.Shiiba
昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている
Trunk Based Development
One line summary A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. * main for the Git community since 2020 (master with unsavory connotations before) Sh
トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
バージョン管理システム「Git」がどのように発展してきたのかを可視化した「Git: An Interactive Development History」
「Git」はLinuxカーネルのソースコードを管理するために生み出された分散型バージョン管理システムで、2021年時点ではLinux以外の分野でも幅広く利用されています。そんなGitの開発履歴について、エンジニアのジェフ・パルマーさんが分かりやすくインタラクティブなグラフ「Git: An Interactive History」にまとめて公開しています。 Git: An Interactive History https://git-history.jpalmer.dev/ Git: An Interactive Development History | jpalmer.dev https://jpalmer.dev/2021/05/interactive-git-history/ ウェブサイトにアクセスすると、適切に表示するには「1024x1024」以上の解像度が必要だと表示されます。
綺麗なコミットログを作りたいときのgitテクニック - Qiita
これは何 僕は開発作業をしているとき、PRをあげるまでの開発途中はwipコミットに変更を記録していき、最後にコミットを仕上げていくような作業をよくします。 初めからコミットを綺麗に書きながら開発ができれば良いのですが、 にあるようなコミットログを仕上げていこうと思うとどうしても最後にコミットログを整理したくなります。 この記事はこのようにgitを使うと綺麗なコミットログを作れるよ、というTipsです。 具体的にこういうコミットを作ると良いよ、みたいな話はこの記事ではしません。 僕はこのような工程でPRを出す前にコミットログを作っています。 git rebase -iで作業中のコミットを全て一つのコミットにsquashする git reset HEAD~で一度コミットを取り消す git add -pで作りたいコミットごとに変更をstageにあげていく コミットを作成する git rebase
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
先行リリース…？ - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」の12日目です。参加できて嬉しいです。 https://qiita.com/advent-calendar/2020/yarakashi-production ※この話はフィクションです。また、派手な内容ではありません。 AM8:35 私は某ソフトウェア開発会社でシステムのヘルプデスクを担当している。いつも通りに出勤し、パソコンを立ち上げ、問い合わせメールがないかチェックする。 正確には「開発以外担当」である。体制図にも文字通りそう書いてある。開発担当が「開発の要件が決まってから商用リリースまで」を、開発以外担当が「それ以外」をやる。ユーザニーズをまとめて開発内容を整理するのも「以外担当」であるし、開発担当が作ったバグも、リリース後ならお客様対応含め「以外担当」がやる。あなた方に瑕疵担保責任という概念はない
「ソースコードブランチ管理のパターン」のダイアグラム - 日々常々
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
継続的デリバリの基礎としてのトランクベース開発
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud