クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo
クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。 そこで行われたセッションの1つ「Web.JaSST ～ウェブ開発のテスト～」」では、ミクシィ、ネクスト、クックパッド、グリーの品質管理（QA：Quality Assuarance）マネージャが登壇し、Web開発やモバイル開発分野の品質やテストにおいて、これまで乗り越えてきた課題、現状、そしてこれからの可能性について語りました。 本記事ではその内容をダイジェストで紹介します。 中野氏（モデレータ） 今日のパネリストの方々は現場でテストをリードしている方々です。その現場で取り組んでいる内容や品質管理について
Androidアプリのビルド／テストはCIでここまで変わる
Androidアプリのビルド／テストはCIでここまで変わる：グリーはいかにしてJenkinsを導入したのか（3）（1/2 ページ） グリーのサービス開発における継続的インテグレーションと、CIツールであるJenkinsの導入について、CI導入のモチベーション、進め方のポイントを中心に説明します。今回は、apkの作成までの自動化を手始めに、徐々に自動化の資産を積み上げていくことで開発ワークフローを改善していく過程を紹介します。 前回の「JenkinsでCIすればiOSアプリのビルドは、もう面倒くさくない」に続き、今回はAndroidアプリ開発とJenkinsについて紹介します。 Androidアプリのビルド Android開発の継続的インテグレーションの第一歩として、まずはAndroidアプリをJenkinsでビルドしてapkファイルを作成してみましょう。あらかじめJenkins、Andro
グリーのインフラに Chef を導入した話 | GREE Engineering
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
継続的インテグレーションを始めるための基礎知識
継続的インテグレーションを始めるための基礎知識：グリーはいかにしてJenkinsを導入したのか（1）（1/2 ページ） 本連載では、グリーのサービス開発において導入している継続的インテグレーション（Continuous Integration、以下、CI）と、CIツールであるJenkinsの導入について3回に分けて説明します。Jenkinsのインストールといった“手順”よりも、CI導入の“モチベーション”や“進め方のポイント”を中心に説明します。 グリーの開発と継続的インテグレーション SNSやソーシャルゲームなどを運営するグリーでは、数百名の技術者が日々さまざまな機能やサービスを開発し、リリースしています。このような規模、リリース頻度での開発を支えるには数多くの工夫や仕組みが必要です。この中でも最も大きな仕組みの1つにCIが挙げられます。 グリーでは、開発にCIを本格的に導入し始めたのは
GREEにおけるJenkins, その2 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
