
Want to stay up to date? For announcements of new conferences, useful materials, and inspiration - subscribe to us!
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
CI サービスをいくつか触ってみたのでまとめ。 今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。 ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。 ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。 触ってみたサービス一覧 アルファベット順。 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。 機能比較 機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。 比較項目は私の独断と偏見で適当に選出した。 項目
2011年8月5日(金)に、クックパッドにて食べログ様と合同勉強会を開催いたしました。 そのときにクックパッドエンジニアが使用した発表資料を公開いたしますので、ぜひご覧くださいませ。 当日お忙しい中お集まりくださった皆様、Usteramでご覧になった皆様、どうもありがとうございました。 ●高田悟史(@satoship) いかにしてユーザ体験を保証するか [slideshare id=8835134&w=425&h=355&sc=no] View more presentations from Satoshi Takada ●太田昌吾(@os0x) Javascript integration (3) [slideshare id=8892178&w=425&h=355&sc=no] View more presentations from cookpadtech Ustreamはこちらから
Continuous Integration and Deployment on CircleCI just got better: now it's free. Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs for current information. Continuous Integration and Delivery are best practices for software development, and are part of CircleCI’s mission: to help developers move faster and
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
In 2011, I wrote a three-part series called How GitHub Works. I wanted to detail how we planned ideas, built them, and shipped them. GitHub no longer works like this, electing instead to institute a hierarchical, manager-driven, top-down, geocentric organization. I’m going to keep these posts up, though, because I think they address extremely important aspects of how good technical companies shoul
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで,10以上のプロジェクト,コードベースを抱える場合にどのようにデプロイの自動化を進めたか,工夫したこと,考慮したことなどをまとめておく. デプロイツールには,Python製のfabricを採用しているが,他のツールでも同様のことはできそう.なお,fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない(最後の参考の項を見てください). fabricの選択 シェルスクリプトとCapistranoを考慮した. まず,シェルスクリプトは人によって書き方が違うため,統一が難しくメンテナンスコストも高い.また共通化も難しい. 次に,Capistranoは,裏でやってくれることが多く,学習コストも高い.プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため,Capistranoの前提から外れる
https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.(以下、ペパボ)で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
はじめに はじめまして。(株)ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI(rrrspec)などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
社内でLTする機会があったので資料を公開します Githubエコシステムを活用したイマドキの趣味開発 from Go Sueyoshi (a.k.a sue445) バックグラウンド 実はこれは先日同僚がRubyKaigi2014で発表した "Gem of this Week" - building culture and making gem のカウンターエントリだったり、補足だったり、そんな感じです。 登壇者のエントリ: RubyKaigi2014で発表した - mitaku.log 残念ながら社内版のcodeclimateやcoverallsに相当するものはないので、業務ロジックや社内のコンテキストが絡まないところに関してはgithubで公開してしまった方がいろいろなエコシステムを活用できると思ってます。 社外に出すとなると 英語でコメント書く issueやPRで英語やり取りが発生す
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」(Continuous Integration、以下CI)のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
技術部の松尾(@Kazu_cocoa)です。 iOSアプリデザインリニューアルの舞台裏でも書かれていた、" 修正期間中は毎日夜間にアプリケーションの全画面のスクリーンショットを記録するスクリプトを実行し、画面崩れが起きてないか、新デザイン未反映の画面はないか、進捗状況の確認に利用していました。"の舞台裏を少し書いてみようと思います。 はじめに モバイルアプリケーションのテスト環境はまだまだ成長中で、様々なツールが飛び交っていることかと思います。ここでは、E2Eテストに対しての話題に絞り、使っているツール、シナリオの書き方、クックパッドでは、という話しをします。この記事におけるE2Eテストは、UIからの操作によりユーザの操作を模倣して実施するテスト、という意味合いです。 ツール E2Eテストを自動化する為のツールの選定には以下を気にしていました。 OSの更新に追従できそうなもの 特別なテスト
#概要 Slack / Hubot / GitHub / CircleCI などをつかってChatOpsにチーム開発できるフローをつくったので、ChatOpsによるデプロイ方法を中心にその方法をまとめてみます。 ChatOpsの主役であるチャットアプリには今回Slackを使いました。 HipChatでも同じように出来ますが、Slackの方がUIが優れていており、外部サービスとの連携も洗練されていたのでこちらを選択しました。 #ChatOpsな環境の概要 SlackとHubot(PaaSであるheroku上にデプロイ)を連携させる SlackからHubot経由でGitHubにプルリクエストをつくる GitHub上の変更を監視し、CircleCIでテストを実施 デプロイ用のブランチに変更があった場合(GitHubのWEBコンソールでデプロイ用ブランチへのプルリクエストをマージした場合)、Cir
この書籍に関連する記事があります! はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが,チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章 チーム開発とは 1.1 1人だけでも開発はできる 1.2 チーム開発で直面する課題 1.3 どのように課題に立ち向かうか 1.4 本書の構成 第2章:ケーススタディ 第3~5章:基礎的なプラクティス 第6~7章:継続的デリバリーとリグレッションテスト 1.5 本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章 チーム開発で起きる問題 2.1 ケーススタディの前提 プロジェクトの前提条件 2.2 ケーススタディ(1日目) 問題1:重要なメールが多
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く