タグ

ブックマーク / www.ryuzee.com (20)

  • 【資料公開】Chef ベーシックトレーニング

    みなさんこんにちは。@ryuzeeです。 これから新たにChefを学ぶ人向けに非常に基的なトレーニングの資料を作ったので公開します。 資料の構成は以下のとおりです。 まずDevOpsの文脈から自動化が必要な背景を説明Infrastructure as Codeについての利点を説明ChefのアーキテクチャChefの用語解説Vagrantで仮想マシンを2台使った一番単純なハンズオン(boxも用意済み)Serverspecを使ったCookbookのテストの書き方(VirtualBoxの仮想マシンの中でDockerを使っています)その他なお、2-3時間でさくっと触りながら全体像を掴むことを目的にしているので、網羅性はありません。 ハンズオン用のVagrantのboxには、あらかじめ、Chef DK(Development Kit)、Dockerなどが含まれており、すぐに触れると思います(ただしb

    【資料公開】Chef ベーシックトレーニング
  • Docker + Capistrano3で簡単にWebアプリをデプロイする

    こんにちは。@ryuzeeです。 アプリケーションのデプロイを楽にするためにDockerを使いたいけど、別にクラスタは必要ない規模だったりクラスタの管理もしたくないという人は多いのではないかと思います。 そこで、今回は、DockerとCapistrano3を組み合わせて単にデプロイを楽にする方法を紹介します。 構成図まず今回の構成図はこんな感じです。AWS上での構成例になっていますが別にどの環境でもあまり関係ない普通のWebアプリケーションを想定してください。 実現したい要件次に実現する要件です。特に変わったことはありません。 いつも同じ方式でデプロイするダウンタイムなしでデプロイするデプロイに失敗したら簡単にロールバックできるようにするサーバが増えてもデプロイの方式は変えなくて済むようにするサーバを再起動してもサービスは自動で復旧する方式では方式を見ていきましょう。 Webアプリケーショ

    Docker + Capistrano3で簡単にWebアプリをデプロイする
  • プロジェクトが失敗する10の兆候

    今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

    プロジェクトが失敗する10の兆候
  • 【資料公開】トヨタ生産方式の基本と考え方

    いまは時間があるので呼ばれればお伺いして相談にのったり、社内勉強会で喋ったりしているのですが、珍しく毛色の違う話をしてきたので資料を公開しておきます(内容は非常に基礎的な話です)。 呼ばれた先でよく言われるのが「スクラムがうまくいっていない」「スクラム的に正しいかどうか分からない」「DevOpsになかなか切り替わらない」といった話なのですが、 そういうのを聞くたびに危ないなぁという感覚を持ちます。スクラムをやるのも、DevOpsな方向に進めるのもビジネス上の目的や課題があるからそうするはず(すなわちスクラムをやるのは目的じゃない。クラウドも同様)なのですが、どうも話が手法やツールに関連する話に閉じてしまう。もしくは当に開発部門が全体の中での一番の問題なのかも分からないうちに、「開発」側だけの観点でみて全体のプロセスを大きくいじくろうとしてしまうケースもあるようです。(仏作って魂入れず、み

    【資料公開】トヨタ生産方式の基本と考え方
  • 【小ネタ】Railsアプリ開発用のVagrantfile

    人材流動性の高まりを感じているみなさんこんにちは。 比較的時間があるので今までCakePHP2.7で作っていたアプリケーションをRails4に移行しているのですが、その開発開発環境としてはVagrantを使っています(みなさん、VagrantとかDockerとか使っていると思います)。 そこで今回は、僕が使っているVagrantのベース部分をシェアします。 特に難しいことはしていないのですが、以下のような仕様になっています。肝は共有フォルダの設定だけです。 ソースコード自体はローカル側のMacで編集したいのでVagrantとディレクトリを共有しますただ共有の際に、VagrantのSynced Folder機能だとファイルやディレクトリのパーミッションがローカル側のものになってしまい不都合が多い(たとえばgemのNative Extensionが権限の理由でビルドできない)ので、NFS共有機

    【小ネタ】Railsアプリ開発用のVagrantfile
  • 【資料公開】スクラムの基礎 | Ryuzee.com

    みなさんこんにちはこんにちは。 ふと思い立ったので昔スクラムのコーチングで使っていた説明資料(2013年のもの)を公開します。以下からどうぞ。 それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者/訳者:西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社:翔泳社発売日:2020-05-20単行(ソフトカバー):288ページISBN-13:9784798163680ASIN:4798163686

    【資料公開】スクラムの基礎 | Ryuzee.com
  • デプロイ自動化を進めるためのチェックリスト | Ryuzee.com

    いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター

    デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
  • 5分で分かるDockerのキホン

    全国100万人のImmutable Infrastructure職人のみなさんこんにちは。 もう誰も彼もがDockerなので、あんまりブログに書こうという気にもならなかったのですが、知り合いからリクエストを貰ったので、5分くらいで分かるようにかいつまんで概略を説明します。 Dockerとは詳しくは家サイト見ればだいたい分かる。仮想化技術コンテナ単位でパッケージングVirtualBoxとかと違って高速、オーバーヘッドが少ない。chrootに近い。LXCには依存しなくなっているコンテナごとにIDが振られるコンテナは差分保存なのでロールバックも簡単一回作ればどこでも動く。JavaっぽいDockerfileでコンテナを作成するDockerfileの1行ごとにコンテナIDがフラれる動作環境Linux Kernel 3.8以降 64bit OSMacの場合はVirtualBoxの中で動かす形になる→

    5分で分かるDockerのキホン
  • vagrant-global-status v0.1.4をリリースしました

    以前、このサイトでVagrantの仮想マシンの一覧を簡単に取得する方法として、vagrant-global-statusというプラグインを使う方法を紹介しました。 その後何回かGitHub上でPRを送っていたところ、vagrant-lxcの作者でもあるFabio Rehmさんから、自分は思ったほどこのプラグイン使わないので、権限付与するのでどんどん開発してくれていいよ、という流れになり、バージョンアップしましたのでお知らせします。(Saharaの時と同じパタン…) インストール vagrant plugin install vagrant-global-status v0.1.4で出来ること 起動中の仮想マシンの一覧を取得する(VirtualBoxに限らず、他のモノにも対応しています) vagrant global-status 起動の状態に関係なく全仮想マシンの一覧を取得する(いままでp

    vagrant-global-status v0.1.4をリリースしました
  • vagrant-serverspecを使ってプロビジョニング結果をテストする

    全国1000万人のVagrant利用者のみなさんこんにちは。 Vagrantいいですよね!そしてインフラの状態をテストするserverspecもいいですよね!この2つがシームレスに統合されるとかなりうれしいですよね! ということで日12/2にvagrant-serverspecというプラグインがリリースされたので早速紹介します。 インストールインストールは簡単です。いつも通りvagrant plugin install vagrant-serverspec としてください。 コード自体は https://github.com/jvoorhis/vagrant-serverspec で公開されています。まだバージョン0.0.1なので、問題を見つけたらPR送るなりIssueを切るなりすると良いと思います。 使い方使い方も簡単です。まずVagrantfileを見てみましょう。 これは何をやって

    vagrant-serverspecを使ってプロビジョニング結果をテストする
  • vagrant-awsの環境別オプション指定方法

    全国1000万人のVagrantユーザーのみなさんこんにちは。今回はVagrantからAmazon EC2を操作する際に利用するvagrant-awsプラグインについて詳細を見ていきましょう。 インストールもうこれは書くまでないのですが、以下のようにインストールしてください。vagrant plugin install vagrant-aws Amazon EC2のネットワークについて知っておこう今回の肝はここです。Amazon EC2のインスタンスを立ち上げる際に選択可能な環境は3つあります。EC2-Classic環境内に構築するデフォルトVPCの環境内に構築する自分でVPCを定義し、その中に構築するそれぞれによってvagrant-awsで指定すべきオプションの内容が変わってきます。したがって自分がどの環境内にEC2のインスタンスを構築するのかをまず明らかにしてください。それぞれの違いは

    vagrant-awsの環境別オプション指定方法
  • vagrant-execによるラクラク仮想マシン操作

    全国3000万人のVagrantユーザーのみなさんこんにちは。 通常Vagrantを利用している際に仮想マシン内部でコマンドを実行したい場合はvagrant sshコマンドを使ってコマンドを実行します。この際、Vagrantの標準機能を使って、仮想マシンにログインすることなく、コマンドを実行できますが、このvagrant-execプラグインを利用することでさらに簡単に仮想マシン上のコマンドをログインせずに実行できるようになります。 たとえばログの確認や設定状況の確認のような簡単な作業は作業を効率化できます。 インストール方法インストールは以下のようにコマンドを実行します。vagrant plugin install vagrant-exec 使い方使い方はかなり簡単です。 最低限このプラグインで設定しないといけない項目は1つで、コマンド実行時のルートディレクトリの指定が必要です。 以下のよ

    vagrant-execによるラクラク仮想マシン操作
  • Vagrantで仮想マシンの一覧を簡単に取得する方法

    全国1000万人のVagrantユーザーのみなさんこんにちは。 Vagrantを普段から多用していると、知らないうちに仮想マシンが沢山起動していて母艦に負荷がかかったり、止めるの面倒くさい~といったことがよくあります。 VirtualBoxの場合は以下のようにVirtualBoxの画面で起動中の仮想マシンの一覧を把握できますが、どこのパスで起動した仮想マシンなのかもよく分からないため十分ではありません。 そこで今日は起動中のVagrantの仮想マシンの一覧を簡単に取得する方法を紹介します。 プラグインのインストール 今回使うのはvagrant-global-statusというプラグインです。 インストールは vagrant plugin install vagrant-global-status でOKです。 実行するには、好きな場所で vagrant global-status -a と

    Vagrantで仮想マシンの一覧を簡単に取得する方法
  • DevOpsに関する12のアンチパターン

    みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います! えっとDevOpsを始めたいのかな?おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける

    DevOpsに関する12のアンチパターン
  • veeweeを使ってVagrant用のboxを自分で作る方法

    Vagrant用のbox(OSのテンプレート)はhttp://www.vagrantbox.es/などで多数配布されています。 とりあえず試してみる分にはこちらにあるものを使ってみるのも良いですが、実際に開発で使おうとするといくつか問題があります。 そのOSに怪しいプログラムがインストールされているかもしれない初期の設定が自分たちの環境と大きく乖離している。例えばyumのレポジトリが多数追加されたりしているVirtualBoxのGuestAdditionsなどのバージョンが古くてそもそも正しく動かないかもしれないこういったことを避けるためには、自分たちでセキュアなboxを作るのが良いと思います。ここではveeweeを使って、自分用のboxを作る方法を紹介します。 veeweeのインストールveeweeはrubyで書かれたツールで、vagrantをはじめとする多くの仮想化ツール用にOSの雛形

    veeweeを使ってVagrant用のboxを自分で作る方法
  • test-kitchenを使ってChefのレシピを複数環境でテストする方法

    test-kitchenはopscodeが提供するChefのレシピをテストするための仕掛けで、Vagrantを使って複数のOSやOSのバージョンを立ち上げレシピをテストすることができる。(Vagrant以外も使える) テストはminitestやcucumberなどを使って記述する。 テストの流れは以下のようになる。 設定ファイルに記載されたOSをVagrantで起動する(既にOSが起動している場合はそのまま利用する。ひな形となるbaseboxが存在しない場合は、設定ファイルに記載された入手元からbaseboxをダウンロードする)Vagrant側とレシピが共用され、レシピが実行されるレシピ実行後、テストが実行されるテストが終了すると、OSの設定が複数あれば次のOSを使ってテストするでは早速設定を行なってみよう。まず1つのレシピをテストする場合だ。 1つのレシピをテストする場合まずトップディレ

    test-kitchenを使ってChefのレシピを複数環境でテストする方法
  • 大きなリリースの際にチェックすべき34のこと

    以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ

    大きなリリースの際にチェックすべき34のこと
  • PHPUnitのアンチパターンとベストプラクティス

    みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたらPHPUnitのアンチパターン・ベストプラクティスに関する素晴らしいスライドを見つけたので内容を抜粋で紹介します。 1. テストの中で何もテストしていない class FooTest extends PHPUnit_Framework_TestCase { public function testSomething() { $foo = new Foo; $foo->doSomething(new Bar); } } こういうテスト。どこにもアサーションがなくて何もチェックしていません。 $foo->doSomethingの戻り値を検証しないならなんの意味もありません。 純粋にTDDをしていれば、テストコード作成→テスト実行でRed→プロダクションコード作成→テスト実行でGreenなのでこういうテストは登場しませ

    PHPUnitのアンチパターンとベストプラクティス
  • より良いテスト駆動開発を行うためのチートシートの紹介

    みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが当にテストしたいのが何なのか?ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが1つではなく複数の機能をチェックしているか、テストが1つ以上のことをやろう

    より良いテスト駆動開発を行うためのチートシートの紹介
  • 永和さんの新しい受託開発サービスについて考えてみた

    永和システムマネジメントさんが、新しい受託開発サービスを立ち上げられてアジャイル界隈では話題になってるので、ちょっと考えてみた。 骨子はこんな感じ 初期投資不要。最少のSSプラン(月15万円)〜LLプラン(月150万円) ソースコードの権利は永和さんが保持 解約は自由だが、解約時にデータ以外のプログラムは引き上げる 月々の支払いの範囲内で一定数のチケットが渡される。1チケットは1人日程度の作業 体制はどうするのか? 1社15万円/月では1人丸抱えはできない。 でも1社だけということは無いので、一定規模の開発にはなるだろう。7社SSプランがあれば105万円/月なので、普通の受託SIerなら1人分くらいにはなる。 そしてチケット1枚が1人日分とのことなので、7社であれば約0.35人月程度の稼働になる。これは悪くない。 (※スイッチングのオーバーヘッドはあるがここでは無視。他にも月1回くらいは顧

    永和さんの新しい受託開発サービスについて考えてみた
  • 1