Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
インフラが苦手でも大丈夫！紙芝居Kubernetes
Women Developers Summit で登壇したときの資料です。
CIOpsとGitOpsの話 - inductor's blog
はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub
ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「（特に、失敗した）話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円（税別）のプレミアム会員制度には159万人（2020年9月末現在）の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス
マージボタン1つで本番適用するための仕組み - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Yakumoチーム兼コネクト支援チームの@ueokandeです。 本日はYakumoチームで構築した、デプロイパイプラインとその工夫について紹介します。 Yakumoプロジェクトはグローバル市場向けに、kintone.comをAWSから提供することを目指すプロジェクトです。 これまで日本のデータセンターから提供していたkintone.comを、現在AWS上に移行しています。 プロジェクトのもう1つのゴールとして、開発・運用体制を見直してクラウドネイティブなリリースプロセスを確立するというのがあります。 このプロジェクトは、国内向けのcybozu.comと完全に切り離されて開発がスタートしました。 ゼロからリリースフローを作るということで、これまでのインフラの経験や反省点を活かしつつ、チームの理想的なデプロイパイプラインの構築を目指しました。 そして最終的には、マージボタン1つで
Kubernetes で実践するクラウドネイティブ DevOps / Cloud Native DevOps with Kubernetes (DevOps, CloudNative and GitOps)
コンテナと Kubernetes の到来によりソフトウェアをデプロイおよび運用する方法は大きく変わりました。ソフトウェアはコンテナ化された分散システムとなり、Kubernetes（または類似の基盤）の上で自動化を通じて動的に管理されるものになっています。そうしたアプリケーションを開発し、本番（プロダクション）に高頻度でデプロイしながらも安定した運用を実現することが今求められています。 本セッションでは Kubernetes でのアプリケーションの開発、デプロイにおける継続的インテグレーションや継続的デプロイから、運用、監視におけるメトリクスやオブザーバビリティまで DevOps のプラクティスを実践する方法と具体的に利用できるツールを紹介します。 OpenShift Meetup Tokyo #9 - DevOps/GitOps編 (2020/5/29) https://openshift
クックパッドアプリはみんなが寝ている間にサブミットされる - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 先日のiOSDCは大盛況でしたね。とても楽しく、実りあるカンファレンスでした。この記事で僕は ididblog! ということにしようと思っています 😋 クックパッドからは @giginet と僕の二人が登壇しました。発表を聞きに来ていただいた方はありがとうございました。 @giginet の 詳解Fastfile という発表中でさらっと話された、”毎週自動的にリリースされる”という言葉が気になった方はいるのではないでしょうか。実はこのリリースフローについての話もプロポーザルに出していたのです(もっともっと細かくリリースをしてユーザーに最速で価値を届けるためのリリースフロー)。 この記事ではこのリリースフローについての話をしたいと思います。 クックパッドアプリの開発体制 クックパッドアプリの開発体制は人数の変動はあ
CocoaPods・Carthageでインストールした成果物はバージョン管理に含めるべきか？ - Qiita
以下のTwitterアンケートを見かけたので、記事書いてみました。 結果は、母数が10人なので参考程度にするのが良いと思いますが、僕も多数派の「CocoaPodsもCarthageも含めている」を特に迷い無く選択しています僕は今ではCocoaPodsもCarthageも含めていない運用にしています。 【iOSアプリプログラマに質問】 あなたはアプリのリポジトリにCocoaPodsで取得したソースコードやCarthageでビルドしたフレームワークを含めていますか？ — りず (r.izumita) (@rizumita) October 6, 2016 ちょうどCocoaPodsのガイドにこのことが記載されているので、まずはその訳を載せます。 (この記載はわりと有名なはずで、ここでオススメされているからバージョン管理に含める選択を取っている人も多そう。) CocoaPodsのガイドの訳 原文
最近のPython-dev(2017-04) : DSAS開発者の部屋
バックナンバー: 3月号 2月号 1月号 NEWS (changelog) の作り方 Mercurial時代からNEWSファイル (changelog) の扱いは面倒だったのですが、Githubに移行したことでよりコンフリクトが起こりやすくなり面倒さに拍車がかかりました。 また、コンフリクトせずに間違った状態でマージされるというかなり致命的な事故も起こってしまっています。 (ワークフローが cherry-pick になったためにマージ時に履歴が考慮されなくなったのか、それともMercurialよりもGitの方がマージがバカなのか、詳細は把握してません。) それで、1つの大きなNEWSファイルにエントリを追記していく代わりに、1つのエントリだけを含む小さいファイルを追加していき、ツールでそれらのファイルからNEWSファイルを生成する仕組みへの移行が急務となり、ツールの選定のためにコンペが行わ
「技術的革新について話すだけのヤツはクソだ、黙って手を動かせ」とLinux生みの親のリーナス・トーバルズが語る
Linuxカーネルを開発したリーナス・トーバルズ氏が、Linux Foundationが開催したOpen Source Leadership Summit 2017(OSLS 2017)で行われた対談で、近年のテクノロジー業界についてや、自身の仕事の考え方を語りました。 Talk of tech innovation is bullsh*t. Shut up and get the work done – says Linus Torvalds • The Register http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/ OSLS 2017でリーナス・トーバルズ氏は、Linux Foundationで取締役を務めるジム・ゼムリン氏と対談を
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応 GitHubは大規模な組織での利用にも対応したソースコード管理ソフトウェアの新版「GitHub Enterprise 2.5」のリリースを発表しました。 GitHub Enterprise 2.5の最大の変更点は、大規模な開発チームでの利用にも対応するようにクラスタリング構成によるスケールアウトが可能になったことです。 ただしクラスタリングは非常に大規模な運用向けに特別に設計されているため、管理リソースの追加も必要となるとのこと。 また、GitHub Enterprise 2.5では内部的にキャッシュインテンシブな処理を実現し、大量の開発プロジェクトを抱えていたり、大規模な継続的インテグレーションなどによって集中的にソースコ
大企業でスクラムしたら筋肉だった
あなたのチームの「いい人」は機能していますか？Minoru Yokomichi169.5K views•56 slides 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013Minoru Yokomichi13.8K views•35 slides
「Jenkins ユーザ・カンファレンス 2015 東京」 において 「はてなにおける継続的デプロイメントの現状と Docker の導入」 という発表を行いました - Hatena Developer Blog
アプリケーションエンジニアの id:nobuoka です。 現在は 「少年ジャンプルーキー」 の開発に携わっています。 面白い漫画作品が数多く集まっておりますので、是非ご覧ください！ さて、去る 1 月 11 日に 「Jenkins ユーザ・カンファレンス 2015 東京」 が開催されました。 はてなからも 「はてなにおける継続的デプロイメントの現状と Docker の導入」 というタイトルでセッション発表を行いました。 ここに発表資料を公開します。 発表資料 はてなにおける継続的デプロイメントの現状と Docker の導入 from Yu Nobuoka 概要 内容としては次の 3 点です。 はてな全体のサービス開発と Jenkins についての概要 「少年ジャンプルーキー」 の開発プロセスと Jenkins の活用 開発中の機能を確認するための web アプリケーションを Docker
iOS開発とGitタグ
いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打
GitLabにGitoliteが必要なくなるよ いいことばかりじゃないけど
by @dekokun on 2013/02/19 23:28 Tagged as: GitLab, git. プライベートGitHubが構築できる(Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構築する)などとして絶賛話題沸騰中、「貧者のGItHub Enterprize」であるところのGitLabですが、次のメジャーバージョンアップでGitoliteが不要になるという大ニュースが数日前に発表されたにもかかわらず、日本語の情報が全くないのでそれではわたくしめがと思いましてブログを執筆させていただく次第です。 あ、あと、私事で恐縮ですが今度結婚することになりました。 はじめに 皆さん、Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowは死んだ