アジャイル宣言の背後にある原則
私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意
HashiCorp | The Infrastructure Cloud Company
PackerBuild and manage images as code
DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い
両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者（以下、Dev）と運用者（以下、Ops）の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは（DevOpsの概念と同じく）、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている
Docker でデータのポータビリティをあげ永続化しよう - Qiita
こんにちは、Docker 0.91 が出ましたね。 CoreOS でのデータの置き場所をどうすべきか考えていた時に、CoreOS-devで出ていた話です。 なので知っている人は知ってるかも知れません。 全てにおいて使えるパターンではないのですが、運用形態のひとつとして紹介します。 （もちろん、Dockerはどんどん進化しているのでこのパターンは陳腐化する可能性もあります） データの永続化の問題 Docker で悩ましいのはデータの永続化をどうするか？というとこでしょうか. 例：mysql のコンテナを立ち上げる -v オプションをつけて mysql のデータを永続化していますね。 さてこれはこれでよいのですが、Docker の旨みを活かせていませんね。 Docker の特徴はコンテナであり、コンテナにするとポータビリティがあげられるわけです。 上記の方法だと Volume でホストにべった
Hashicorp AtlasでVagrant, Packer, Terraformを連携させる | DevelopersIO
ども、大瀧です。 VagrantやPackerを開発するHashicorp社から、Atlasという新しいサービスがローンチしました。現在はtech previewとして触ることができます。今回はチュートリアルを試しつつ、その様子をレポートします。 Atlasとは? Hashicorp AtlasはHashicorpが開発するDevOpsツールを連携させ、開発・デプロイの一連のワークフロー管理を実現するクラウドサービスです。以下がAtlasの概念図ですが、各フェーズの左下に"Powered by"のあとにツール名が示されているのがわかります。 ツールを軸に、今回のチュートリアルの範囲でAtlasの機能を示してみました。 Vagrant、Packer、Terraformが操作の軸になることがわかりますね。これ以外にも、仮想イメージ(Box)を共有する機能やConsulと連携する運用向けの機能も
Knife-ZeroをマスターしてChef Soloの引退に備えよう！ | さくらのナレッジ
今年の6月にChef Soloは役割を終え、今後引退への道をたどると言うアナウンスがChefの公式ブログでありました。Chef Soloがなくなるということは、必ずChef Serverが必要になると言うことでしょうか？答えはなんとYesです。 しかし安心してください。そのためにChef Zeroが用意されています。一言で言うと、Chef Zeroはローカルで動かせるChef Serverです。 そしてChef Clientをローカルモードで動かすことでローカルのChef Zeroに接続するため、別のChef Serverは必要ありません。要するにChef Soloと同じような感覚でChefを使い続けることができます。 更にKnife-Zeroを使うとChef Solo同様にセットアップ先のマシンにChef Clientを簡単に入れることができます。そこで今回はこのKnife-Zeroを使
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
大規模にchefを使い倒すためのcookbook pattern - Qiita
概要 チームや組織、プロダクトをまたいでcookbookを使っていく場合に使えるcookbookの書き分け方を紹介します。 要はプロダクト毎にサーバに対する要求は変わりうるのでサービス毎にcookbookを分けるんだけど、会社全体として組織プロダクトをまたいで共通化しておきたい部分は共通のcookbookを使いましょうという話です。 こういう分け方をしたらよい、という話もします。 組織やプロダクトの成長とcookbook 小さな組織やチーム内でchefを導入した場合、cookbookを書くのは大抵の場合一人だと思います。 扱うサーバの種類もそんなに多くないので、apacheのインストールやphpの設定を一つのrecipeにベタ書きしても人間が管理できるボリュームに収まると思います。 というか、変に分割するよりもベタ書きのほうがrecipeの見通しがいいと思います。 ところが、組織が大きくな
vagrantのネットワークについて - Qiita
Vagrantfileのnode1はゲスト1、node2はゲスト2。 ホストオンリーアダプタ 仮想ネットワークインタフェースを作成し、ホストとゲストの間での閉じたネットワークを形成。ゲストとホスト間のみ通信可能。ゲスト同士の通信はできない。 Vagrantfile VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "centos65-x86_64-20140116" config.vm.box_url = "https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box" config.vm.define :
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) | DevelopersIO
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか？ 上手くいく／上手くいかない取り組みの違いはどこなのか？ そもそもそれは本当にやるべきか？ 組織とエンジニアの関係、評価はどのようにすれば良いのか？ といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
AWS 認定プログラム DevOpsの対策
久々にブログ書きます！ まずAWSには現在アソシエイトレベルで3つ、プロフェッショナルで2つの認定があります。 でもってタイトルのDevOpsはプロフェッショナルの方になります。 詳しくはここ http://aws.amazon.com/jp/certification/ ウチの会社はAWSのプレミアコンサルティングパートナーを頂いておりまして、仕事の殆どが AWSの設計・構築・運用となってます。という事で毎日AWSばっかりさわってます。 ただ最近はお客様先に訪問したり、社内組織作り的なお仕事が多くなってきてしまいまして 自分の技術力がめっきり落ちているのでは？最近入って来たエンジニアにはアイツ偉そうに してるけど、実は何も分かってないんじゃね？と思われていると勝手に思い込んでます（笑） と、いう事で技術力の再チェックと、エンジニアである証明（みんなにアピール）をするために、 6月の「AW
Ansible チュートリアル | Ansible Tutorial in Japanese
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
Homepage | Ansible Collaborative
A gathering space to build automation skills and success Welcome to the Ansible® Collaborative, a destination for Ansible users, customers, partners, and vendors to learn and share automation content. No matter your role, or your automation goals, Ansible can help you connect teams and deliver efficiencies. Ansible is an open source IT automation engine that automates provisioning, configuration m
「Serverspec」を使ってサーバー環境を自動テストしよう | さくらのナレッジ
ChefやPuppet、Vagrantといったサーバーの設定を自動で行うツールが普及しつつあるが、それと同時にサーバーの自動テストについても注目されるようになっている。今回はサーバーの自動テストを実現するツール「Serverspec」をLinux環境で利用する手順を紹介する。 サーバーの自動テストの必要性とテスト駆動開発 最近ではサーバーの設定やソフトウェアのインストールといった作業を自動で行えるツールが注目されている。しかし、設定後のテストについてはあまり注目されておらず、各種設定やソフトウェアのインストールが正しく行われているかどうかは手作業で確認することが一般的だった。しかし、手作業での確認にはミスや抜けが発生する可能性があり、また対象とするサーバーの数が増えるとそれに比例して手間も増えてしまう。そこで活用したいのが、サーバーの自動テストツールだ。 サーバーの自動テストツールは、あら
新しいクラウドパフォーマンス管理サービス Mackerel 正式リリースのお知らせ - Mackerel お知らせ #mackerelio
本日、Mackerelを正式リリースしました。 Mackerelは、Immutable Infrastructureを取り入れたアーキテクチャや、ChatOpsといった運用スタイルに最適化した、新しいクラウドパフォーマンス管理サービスです。 Mackerelは2014年5月8日にベータ公開し、それから4ヶ月間、機能追加と安定化を目指してきました。今後も引き続き、クラウド上のサーバとそれらによって構築されるWebサービスを管理するための、より使いやすく、より便利なサービスとして開発運用を加速させていきます。並行して国際化対応し、グローバルへの展開も積極的に行います。 本日より、フル機能をご利用いただける「Standardプラン30日間無料！」キャンペーンを実施しております。ぜひお試しください。 ご意見ご要望などがありましたら、お気軽にサポートまでお知らせください。 Mackerelの特徴 M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
やって覚えるVault | DevelopersIO
「運用改善」を考える 〜「自動化」を考える前に
