Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

cloudとCIに関するraimon49のブックマーク (6)

  • 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

    CIOpsとGitOpsの話 - inductor's blog
  • Gitのスケーリング(と、その背景) | POSTD

    数年前、Microsoftは、社内全体のエンジニアリングシステムを活性化させるため、数年間にわたる投資を行う決定をしました。私たちは山のような数のチームを抱える大企業です。チームはそれぞれ、担当のプロダクト、独自の優先順位、プロセス、ツールを持っています。”共通の”ツールもありますが、チームによって様々に異なる点も多く、内部で開発した単発のツールも数え切れないほどあります(「チーム」とは社の部門のようなもので、数千のエンジニアの集まりです)。 この状況にはたくさんのマイナス面があります。 似たようなツールを構築しているチームがいくつもあり、巨額の冗長な投資が生まれている 「クリティカルマス(損益分岐点を超える生産量、普及率)」に向けた設備投資ができない 皆がバラバラのツールやプロセスを用いているため、従業員が異動しにくい 組織の垣根を越えてのコード共有が難しい “MS限定”ツールの過多のた

    Gitのスケーリング(と、その背景) | POSTD
    raimon49
    raimon49 2017/03/19
    Git採用の経緯や、導入後トライアンドエラーの背景まで。マイクロソフトって本当に変わったと実感する。
  • インフラエンジニアのいない会社で働いて 1 年半 - Diary

    インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMSAmazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一化する予定、というかんじ。 当に自分達でなにもサーバーを管理してい

    raimon49
    raimon49 2016/12/28
    CI as a ServiceもPlatform as a Serviceも、「いつでも自分達は他の選択肢にスイッチできる」という前提で乗っかることが大事なんだろうな。
  • クラウドサービスの Web API とそのユースケース #apijp

    フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

    クラウドサービスの Web API とそのユースケース #apijp
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

    raimon49
    raimon49 2014/03/14
    移植性・疎結合を保つための方法論。暗黙的なsite packagesに依存せず全て宣言させる、デプロイ先ごとに異なる設定は環境変数に持たせる、デプロイ(開発、ステージング、本番環境)は同じバックエンドサービスを利用。
  • 今さら聞けない Immutable Infrastructure - 昼メシ物語

    Immutable (不変な) Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S

    今さら聞けない Immutable Infrastructure - 昼メシ物語
    raimon49
    raimon49 2013/11/27
    プロビジョニングツールがオーバースペックになる、確かに。
  • 1