404 Error Page Not FoundWe can't find what you're looking for, but the links below may get you back on track.
![Welcome to CircleCI Documentation - CircleCI](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c05b0f5c55356b61c85e223a4ad6cb5b3d0ce87/height=288;version=1;width=512/https%3A%2F%2Fcircleci.com%2Fdocs%2Fassets%2Fmeta%2Fopen-graph-cci-docs.jpg)
404 Error Page Not FoundWe can't find what you're looking for, but the links below may get you back on track.
プルリクエストのレビュー時に 「規約では1行あたり最大80文字なので、1文字削ってください」 などと一々指摘していると人間関係が破綻する可能性があります。 こういう定量的なものに関してはロボットに任せるのが一番です。 そこでHoundCIを使いましょう。 これはRubocopにリポジトリを監視させるというコンセプトのサービスです。 HoundCIを使うメリット コーディング規約違反のコードがmasterに入る前に必ず検知できる チームメンバー全員でRubycopを使う必要がない ダルいコーディング規約に関する議論が可視化できる 人間関係が壊れない(重要) 気軽にみんなでRubocopを使える Rubocopをsyntasticを使ってVimから自動実行する Rubocopを使ってコーディングルールへの準拠チェックを自動化 Qiitaの上のような記事を読んでから、暇があったら導入しようと思っ
Docker Meetup Tokyo #2でLTしてきた:「Docker+serverspecで作るconfigspec CI」 #dockerjp はじめに 2014年4月11日(金)に開催されたDocker Meetup Tokyo #2で、「Docker + serverspecで作る configspec CI」というタイトルでLTしてきました。 この内容について、少し詳細に落とし込んだのがこの記事です。拙いところも改善するべきところもいっぱいあるんですが、とりあえず動いたよ、というところで。 イベント中のtweetはTogetterにまとめました。 Docker Meetup Tokyo #2 #dockerjp - Togetterまとめ やりたいこと 結果としてやりたいこと、出来上がるものがこちらの図になります。 configspecとserverspecをRakefile
Kiwi+CocoaPodsで始めるiOSアプリの振る舞いテスト入門:iOSアプリ開発でもCI/継続的デリバリしようぜ(2)(1/4 ページ) 現代の開発現場において欠かせないCI/継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する連載。今回は、iOSアプリの機能の振る舞いをテストするテスティングフレームワークの特長とインストールの仕方、主な使い方を解説します。 前回の「iOSアプリ開発でCI/継続的デリバリ環境を始めるための4種の神器」では、CI/継続的デリバリ環境を構築するために必要なツール・サービスを紹介しました。 今回はiOSアプリのためのテスティングフレームワークの1つである「Kiwi(キウィ)」を使った振る舞いテストの書き方について解説します。 振る舞いをテストするテスティングフレームワーク「Kiwi」とは KiwiはiOSアプリケーションの機能の振る
いやー、めっちゃ楽しかったわ、JSオジサン。 もう色々と感想ブログは出てるけど、僕も一言で感想を言うと以下の様な感じです。 #JSオジサン 楽しかった。ギャルにも会えたし、typescriptオジサンにも会えた。ECMA-262 Edition 5.1を読む本も貰えたし、じゃんけんに勝ってエコバックも貰えた。50-60位の中規模なカンファレンスだとやっぱり話が濃くなるから良かった。— Yosuke FURUKAWA (@yosuke_furukawa) March 27, 2014 実際名前は知ってても顔を見たことない人もちゃんと話したことない人も多くて、そういう人たちと知り合えたのがやっぱり大きかった。 僕が発表した内容 ここ最近、substack wayでモジュールを書くことを実践してます。 本当は上のリンクにあるsubstack wayの話をすごくしたかったんですが、5分で伝えきれる
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。 【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 from Kotaro Ogino ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。 背景:開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
“Docker 使うなら Ubuntu だろ jk” とか言われそうですが CentOS 6.5 で使いたかったので試してみました。Docker の公式サイトには “Our recommended installation path is for Ubuntu linux, because we develop Docker on Ubuntu and our installation package will do most of the work for you.” と書いてあったり、Drone は Ubuntu 用のパッケージしかなかったりするので、深淵な理由がなければ Ubuntu 使うのがいいんじゃないかと思います。 Docker のインストール CentOS 6.5 なら簡単にインストールできるので特にハマりどころはありませんでした。 rpm -Uvh http://downl
Try TeamCity - the powerful Continuous Integration and Deployment tool for Developers and DevOps Engineers.
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.(以下、ペパボ)で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
継続的インテグレーションの手順のうち、デプロイに焦点を当てて、テストの実行から、GitによるHeroku環境へのデプロイまでを自動化する方法を解説。Mac向けのGrowlを使って実行結果を通知する方法も説明。 ← 前回 連載 INDEX 次回 → 連載第1回「Jenkinsを使ってみよう」ではMac(OS X)/Linux/Windowsへのインストール方法を、第2回「Jenkinsでテストを実行してみよう」ではユニットテストおよびインテグレーションテストを作成し、Jenkinsから実行する手法を解説した。ここまで読んでいただいた読者の皆さんもJenkinsをインストールして自分なりの使い方を模索していることと思う。 さて、連載第1回で「継続的インテグレーションとは次のような手順の繰り返しだ」と説明したのを覚えているだろうか? プログラミング テストの実行 リファクタリング デプロイ 今回
こちらの記事について、最新のTravis CIの環境(2014/4/15)ではコード署名に失敗する問題があります。 その問題の修正については下記の記事にまとめました。 Travis CIでipaを作るときのCode Signが失敗するのを修正したメモ - 24/7 twenty-four seven 実際は完全に移行したわけではなくて、Travis CIの有料プラン(プライベートリポジトリが使える)のフリートライアルを試しているところなのですが、しばらくはTravis CIでCIを動かすことにしたので、そのときの設定などをまとめます。 もともとは社内のサーバでJenkinsをホストしていて、それがダメということは全然ないのですが、社内でサーバをメンテナンスするのも面倒だし、ビルドスクリプトとかをポータブルな状態にしておくのは手元でサクッと実行できたりいろいろ都合が良さそうだと思い、試しにや
CIって? CIはContinuous Integration(継続的インテグレーション)の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
cross.md CROSS 2014 : CI/DevOps Github, Pull Request Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー pull request を利用した開発ワークフロー // Speaker Deck Hatena Blog Development Flow // Speaker Deck Continuous Integration/Delivery Continuous Delivery in COOKPAD // Speaker Deck Hatena Blog for Engineer // Speaker Deck ソフトウェアテスト テスト考2014 - Hidden in Plain Sight テスト書きすぎ問題 - hitode909の日記 RE: テスト考20
at RubyWorld Conference 2013, on Nov. 21st, 2013.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く