タグ

devopsに関するwinterfallのブックマーク (6)

  • DevOpsとは何か? そのツールと組織文化、アジャイルとの違い

    両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者(以下、Dev)と運用者(以下、Ops)の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは(DevOpsの概念と同じく)、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている

    DevOpsとは何か? そのツールと組織文化、アジャイルとの違い
  • 突撃!隣のDevOps 【エウレカ編】 | Developers.IO

    はじめに こんにちは、DevOps導入支援担当の藤村です。突撃!隣のDevOpsが帰ってきました!パート1からなんと2年ぶりのパート2、2といえばペア、ペアといえばPairs!ということで、今回はPairsを運営するエウレカさんにお邪魔して、DevOpsに関して根掘り葉掘り聞いてきました! 突撃!隣のDevOpsとは パート1からあまりに時間が経っているため、改めてこのシリーズの趣旨について再掲します。 突撃!隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、「開発」に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発(Development)と運用(Operations)が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求

    突撃!隣のDevOps 【エウレカ編】 | Developers.IO
  • Infrastructure as Code 再考 - Gosuke Miyashita

    Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、 Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code というを出す (現在 Early Relase 版や Free Chapters が入手できる)ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日でも最近、 サーバ/イ

    Infrastructure as Code 再考 - Gosuke Miyashita
  • 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering

    はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください! こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得

    入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
  • インフラの継続的デリバリー - naoyaのはてなダイアリー

    事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更

    インフラの継続的デリバリー - naoyaのはてなダイアリー
  • 構成管理ツール Ansibleを使ってみる | DevelopersIO

    構成管理ツールといえばChefですが 弊社ブログでも構成管理ツールに関する記事はけっこうありますが、ほとんどがChefに関する記事です。 私もChefについてを書いてたりしますが、Rubyが苦手な自分としては、Chefのレシピを書いたりするのは難しいわけです。 (こういう記事もありますが) で、Chefのかわりに使えそうな構成管理ツールを探して、これならいけるんじゃないかと思ったのが、今回紹介するAnsibleです。 Ansibleとは Ansibleとは、Pythonで記述された構成管理ツールです。 まずはAnsibleの基用語について解説します。 ・モジュール クライアント内での動きは「モジュール」として定義されます。 ソフトウェアをインストールしたり、サービスの起動をしたりするモジュールはあらかじめ用意されてます。 自分でモジュールを作成することも可能です。 このモジュールは何で作

    構成管理ツール Ansibleを使ってみる | DevelopersIO
  • 1