ソフトウェア開発」カテゴリーアーカイブ

[git] クローンからプルしてマージ、コミットしてプッシュする

 

こんにちは、最近流行の git(ギット)。
分散バージョン管理の概要を理解するためのコンテンツを公開しました。

 はじめてバージョン管理システムを利用する人、初学の人から、すでに開発に使っている人までこれまでのバージョン管理に比べ圧倒的に便利だ。という反面、「バージョン管理の利点と使い方はなんとなくわかる。が、分散バージョン管理はよくわからない」という声があります。私自身も git の利用を開始した当初は、「Index? HEAD? なにそれ? 」状態でした。

社内メンバー向けに作成し、お客様にも利用して頂いた資料をもとに新たに編集し直して公開します。(画像なども新たに編集)

この「git 基礎勉強」を読めば、
「クローンからプルしてマージ、コミットしてプッシュする」

の意味が理解できるようになります。

ぜひご覧下さい。

 


手書き風の画像は、だものメーカーを使っています。

[book][bts] 組込みソフトウェア開発における品質向上の勧め(バグ管理手法)本の紹介

 

バグ管理のやり方や運用ルールは開発チームや会社によっていろいろな方法があります。
専用のバグ管理システムを利用したり、表計算ソフトを利用したり、ワープロで作成した紙もあるかもしれません。

バグ管理の大きな目的は「バグを見つけたら速やかに、かつ確実に正しく修正し、その再発を防ぐこと」です。そのために必要な考え方を体系立てて説明している無料の書籍をご紹介します。

 

IPA(情報処理推進機構):組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]
PDF版のダウンロードはこちら
(書籍で欲しい場合は Amazon.co.jp で購入することができます。)

 

tracpath を利用している企業へのヒアリングで

  • 業務アプリケーションの受託開発
  • 組込みシステムの開発
  • クラウドサービス・ASPサービスの開発
  • コンシューマ向けゲーム・ソーシャルゲーム開発
  • スマートフォン・モバイル開発

多くのソフトウェア開発に携わる方に利用頂いております。
バグ管理方法や tracpath の使い方についてヒアリングし、多くの人がバグ管理のルール決めとバグ管理のプロセス(ワークフロー)を自分たちにあったやり方にしなければうまくいかない。と言われます。

これは、どのようなツールを使うのか、オープンソースの無料ソフトウェアを利用するのか、商用サービスを購入するのかは重要ではないことを言っています。また、ワークフローは極力シンプルにする必要がある。とも言われます。

ソフトウェア開発に携わるすべての開発者に言えることですが、バグ管理の目的や管理プロセスを理解し、自分たちのチームに最適な方式(運用ルール)を決めることがとても重要になります。

IPAの組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]はバグ管理やプロセスの標準的な方法を体系立てて説明しています。

組込みソフトウェア開発向けだけではなく、他多くのソフトウェア開発の現場で役立つ情報だと思います。

PDF版は無料で読むことができますのでぜひ皆様の現場で活用されることをオススメします。

 

Git のリポジトリを履歴保持したまま ciklone に移行する方法

 

Suvbersion / Git / Mercurial のリポジトリを tracpath にインポートする機能がリリースされております。外部リポジトリをサイクロンに移行(Git / Subversion / Mercurial) をご確認ください。
以下のエントリーは古い情報となります。


Subversion のリポジトリを履歴保持したまま ciklone に移行する方法の Git 編です。
Git/Mercurialのリポジトリ移行はユーザの操作で可能です。

GIt の移行

はじめに

Gitは分散バージョン管理システムのためリポジトリが変更履歴を保持しています。Gitリポジトリを別サーバから移行する方法を説明します。

注意すべき点は、サイクロンのGitはチケット管理システムのコミットフック(commit-fook)が設定されているため事前にコミットフックの設定を変更する必要があります。

コミットフックを変更しない場合、インポートに時間がかかる場合があります。

手順

  1. サイクロンで新規リポジトリを作成
  2. サイクロンのコミットフック設定を無効にする
  3. Gitコマンド
  4. 移行されたデータの確認
  5. サイクロンのコミットフック設定を有効にする

1. サイクロンのプロジェクトにリポジトリを新規作成

サイクロンのプロジェクトに新規Gitリポジトリを作成します。

  1. リポジトリの追加をクリック
  2. リポジトリ名を「projectA」入力
  3. 「作成」をクリック

2. サイクロンのコミットフック設定を変更

サイクロンにログインし、管理画面のサイドナビゲーション[trac.ini] -> ticketをクリックします。
チケットの動作設定に関する設定画面が表示されます。

  • 項目名:commit_ticket_update_ignore_repositories
  • 変更時にチケットを更新させないリポジトリの名前を設定します。

テキストボックスに1)で新規作成したGitリポジトリ名を入力します。
複数入力する場合は「,(カンマ)」で区切ってください。

3. Git コマンドで移行

新規作成したサイクロン上のGitリポジトリにローカルにあるGitリポジトリを移行します。
サンプルとして Ruby の Git ライブラリである Grit をクローンして自分のサイクロンリポジトリに移行します。

リポジトリを取得します。

> git clone git://github.com/schacon/grit.git mygrit

Cloning into 'mygrit'...
remote: Counting objects: 4051, done.
remote: Compressing objects: 100% (2261/2261), done.
remote: Total 4051 (delta 1810), reused 3911 (delta 1733)
Receiving objects: 100% (4051/4051), 1.84 MiB | 636 KiB/s, done.
Resolving deltas: 100% (1810/1810), done.

取得したリポジトリのクローン元情報を削除します。

> git remote
> git remote rm origin
> cd mygrit   ... ここは利用環境によって異なります。

サイクロンにリポジトリを移行します。

> git push --all origin

Username for 'https://.ciklone.com': user-name
Password for 'https://@.ciklone.com':
Counting objects: 4021, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2179/2179), done.
Writing objects: 100% (4021/4021), 1.84 MiB | 3.11 MiB/s, done.
Total 4021 (delta 1793), reused 4011 (delta 1786)
To https://.ciklone.com/git/

他サイト(サーバ)のリポジトリをサイクロンに移行することができました。

4. リポジトリの確認

ブラウザでサイクロンにアクセスし、リポジトリを確認します。

5. コミットフックの設定を戻す

1) コミットフックの設定を無効から有効にします。

コミットフックの除外リポジトリとして登録したリポジトリ名を削除して、「変更を適用」をクリックします。

以上で他サイト・他サーバで管理している Git リポジトリを簡単にサイクロンに移行することができます。

ぜひ、お試しください。

Subversionのリポジトリを履歴保持したままcikloneに移行する方法

Suvbersion / Git / Mercurial のリポジトリを tracpath にインポートする機能がリリースされております。外部リポジトリをサイクロンに移行(Git / Subversion / Mercurial) をご確認ください。
以下のエントリーは古い情報となります。


こんにちは。

サイクロンをご利用されている皆様よりよくあるお問い合わせ内容について、これまで社内開発で利用しているリポジトリをサイクロンのリポジトリに移行したい。というお問い合わせがあります。

リポジトリには、コミットログ、ソースコードの差分、コミットしたユーザなど多くの情報が記録されており、プロジェクトの大切な資産の1つです。開発環境が変わったり、クラウドサービスを利用し始めたり、ソフトウェア開発のインフラはセキュリティが担保された上で、より便利で効率的な方法に移行することがあります。

このとき、これまで開発で利用していたリポジトリを新しい環境に移行して、開発を継続するための方法をバージョン管理システム Subversion,git,mercurialに合わせて手順を説明します。

現バージョンのサイクロンではユーザがSubversionの移行をするためには、データを当社に送付して頂く必要があります。今後のバージョンアップでユーザによるデータ移行が可能になります。ご期待ください。

Subversion の移行

はじめに

Subversionリポジトリをサイクロンに移行します。リポジトリの履歴を含めたデータの移行方法について説明します。履歴を含めない場合、エクスポート・インポートコマンドによりリポジトリの移動が可能です。

Subversionの場合、ユーザのみで移行するための機能が実装されていないため以下の手順となります。

  1. (ユーザ)のリポジトリからダンプファイルを生成
  2. ダンプファイルを当社に送付(セキュアなファイル受け渡し)
  3. ダンプファイル受領後、約1営業日内にユーザ領域にインポート
  4. あなたのアカウントでサイクロンにログインし、リポジトリを確認

1. リポジトリからダンプファイルを生成

サイクロンに移行したいリポジトリを svnadmin コマンドを使ってダンプします。

svnadmin dump  >
svnadmin dump /var/svn/project-1 > project-1.dmp

複数リポジトリがある場合、各リポジトリ毎にダンプファイルを作成してください。
ユーザの環境はWindows/Linuxどちらの環境でも問題ありません。OSに関係なく移行することができます。

2. ダンプファイルを当社に送付

ダンプファイルを当社に送付頂きます。送付前に当社にご連絡ください。
セキュアなファイル送付方法を提示いたします。

当社に送付頂くデータの扱い

にて説明しています。ご希望があればNDA(秘密保持契約)も可能です。お問い合わせください。

3. ダンプファイルのインポート

ユーザから送付されたダンプファイルを受領後、利用者のアカウントにインポートします。
これは約1営業日内の作業時間が必要となります。ご了承ください。

4. 通知とご確認

インポートが正常に完了後、ユーザに通知いたします。通知を受けましたら利用者のアカウントでサイクロンにログインしてください。
正常に移行されているか確認をお願いします。

さいごに、サイクロンのリポジトリURLからチェックアウトを行います。正常にチェックアウトされれば移行作業は完了となります。

ビギナーに伝えたいバグ管理ノウハウ 〜バグ管理の必要性〜

ソフトウェア開発に携わる人は必ず出会っているバグ。バグとはプログラムのソースコードの間違いや誤動作するコーディング上のミスのこと。設計工程で発生する仕様間違いなどもバグである。

 

このバグを効率よく管理してみんなが幸せになるためにどのような点を注意して日々の業務を進めるべきか、について考えてみる。

 

プログラマーのスキルによる成果物の品質

 

どこのチームや会社にもスーパーエンジニアと評されるスキルが高いエンジニアがいる、という話を聞く。
私の関わるプロジェクトでもあるエンジニアがいるというだけでチームにとって技術的な安心感であったり、品質面でも安心感を与えてくれることを実感している。

 

これは管理する側からみても同様に安心感を得られる場合が多い。

 

特に最近のソフトウェア開発は顧客から短納期・低予算が求められ、専門性の高いエンジニアに大きく依存しているプロジェクトばかりである。開発ではオープンソースソフトウェアやミドルウェア製品、フレームワーク、言語が多数存在しており、それらを「うまく組み合わせた総合的なソリューションを提供」する必要がある。

 

このような状況もあり、専門性の高いエンジニアに大きく依存しているプロジェクトが多いように思う。このようなプロジェクトでは経験に価値があり、技術全体を俯瞰して考えることができるエンジニアの付加価値が大きい。

 

このスキルは簡単に身につくものではないが物事の理由を考えながら高い意識で仕事することで養われていくと信じている。

 

スキルの高いエンジニアでは成果物の品質にも大きく影響し、バグの少ない、メンテナンスしやすいプログラムができる。

すべての開発をスーパーエンジニアに依頼することが理想だが、決められた予算とスケジュールを持つプロジェクトでは到底無理な話で、スキルがバラバラのチームで開発することになる。

 

スキルの異なるチームの生産性を上げるための話題や研究は考えられてきているが。。。ここではプログラマー、テスターが一番触れる機会の多いバグ管理の運用管理について書いていこうと思う。

 

バグ管理の必要性(メリット)

開発の現場でよく聞かれる管理方法として

  • Excelなどの表計算ソフトで管理
  • オープンソースのBTS
  • パッケージ製品

最近はTrac、Redmine、Mantis、BugzillaなどのBTSの利用が増えてきていると実感している。

世の中にはバグ管理だけでも多くのツールが存在しており、各製品には多くの特徴やバグ管理をサポートする機能が提供されている。これから数回に分けてビギナー向けバグ管理のノウハウをまとめていくがツールに依存した説明は避け、バグ管理の運用と考え方にフォーカスしようと思う。

バグ管理の必要性(メリット)について

 

1.バグが管理されデータベースが用意されることで、発生障害についてチーム内の意思疎通がスムーズになる

管理方法が統一されることで、電子メールによる共有や都度作成するレポートよりも正確に内容を伝えることが可能

2. DB化することで、バグの通番管理(追跡と参照)が自動化され、レポートのための分析や報告が提供できる

3. 開発チームは、プロジェクトチーム、マネージャ、顧客、ユーザのそれぞれにとって重要な観点から考え修正を進めることができる。(バグには優先順位が存在する)

優先度がないバグは「声が大きい人」の報告したバグほど早く修正されがちになる

4. 「バグの発見→レポート→担当者割当→解決」について、全てのライフサイクルを通じたバグ管理が出来る。

バグがどこかのライフサイクルに潜り込み、早期修正が必要なバグから注意がそれることがない。

5. 開発チームやプロジェクトチーム、テスターの全員が最新の状況を簡単に入手できる。解決したバグはナレッジとなる。

これらのバグ情報は、リリース製品に紛れ込み、サポート部隊のコストを上げる原因、売上の伸び悩み、使えないシステムという辛らつな評価につながる問題に対する対策が可能

 

チームにとってスキルや役割の違う人々がスムーズな意思の疎通を行うためにも、ベースとなる一元化されたバグ管理は必要である。

 

SAP:ソーシャルアプリ開発にクラウド(IaaS)を利用するメリット

「クラウドのメリットを一番享受できるのは、個人開発者、ソーシャルアプリ開発企業、IT系ベンチャー企業」

小さく・安く・始めて、成長に合わせてサービスレベルを向上させることが出来るクラウド・コンピューティングはそのような企業にとって大きなメリットがあると考えています。

クラウドは、開発環境、本番環境のインフラ、スケールアップ、運用負荷軽減を低リスクで担保できるサービスになっています。これからのアプリ開発でははじめるときにハードウェアのことをほとんど考えなくて良くなる、と言えます。

サービス提供者の役割によるメリットを簡単にまとめると、

経営者

  • システムの投資の無駄を排除 →「所有」から「利用」
  • 求めるサービス提供のためのハード購入費用がかからない
  • 素早いサービス立ち上げ

開発者

  • 開発環境の迅速な構築
  • スケールアップ・可用性向上
  • 本番リリースに向けたサーバ規模の設計を軽減
  • 負荷分散

運用者

  • 利用状況に応じた柔軟なリソース割当
  • システム運用負荷の軽減
  • ハード障害から解放(自前に比べて…

数年前まではデータセンターを借りて自前のハードを用意するか、ホスティングサービスを利用するかが一般的だったと思います。最近はクラウドを使うことで低コストでストレスなく(ハードの面倒を見る必要なく)始めることが出来る。スタートするときの敷居が低くなることはアプリケーションベンダーにとっては良いことです。
2,3年のスパンで見た場合、クラウドよりコスト面でメリットがあるサービスもありますがソーシャルアプリ・ソーシャルゲームに限ればベストなソリューションではないでしょうか。

新しいサービスをすばやく提供するために、その時、そのタイミングで最適なサービスを積極的に利用していきたいですね。

 

SAP:ソーシャルアプリ開発、インフラ構築時に使える10個のチェックリスト

ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。

インフラ構築に使える10個のチェックリスト

  1. 必要なときにスケールアウト、スケールアップができるか
  2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
  3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか
  4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか
  5. メンテナンス時間を最小化できるか
  6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか
  7. サーバの状態を常に把握できているか(全体PV、各ページPV,日毎、時間毎)
  8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
  9. バックアップ・リカバリの方法は確立されているか
  10.  監視用アプリケーションは正しく、漏れなく設定されているか

 

1. 必要なときにスケールアウト、スケールアップができるか

自前でマシンを用意する場合、ある程度余裕を持ったインフラを構築しておきたいものです。しかし多くのサービスでは必要最小限ではじめたい。という声があるのも確かです。(予算もありますし)

これがクラウドサービスを利用した場合、クラウドの一番のメリットと言える内容です。それぞれの意味を把握しておくと良いことがあるかもしれません。

  • スケールアウト(Scale Out) ・・・ 稼働する仮想サーバの台数を増やす機能
  • スケールアップ (Scale Up)・・・ 稼働するサーバ1台の性能をあげる

多くのクラウドサービスではこのスケールアウト、スケールアップは対応しています。その方法については開発しているサービスに合わせて手順書化しておくことがベストです。

ref:クラウドでよく言われる「スケールアウト」の反対の言葉って何だろう?

2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか

障害対応やバグ対応でもっとも大切なことは「障害が発生したときの原因を突き止めること」です。

問題が分かってしまえば解決するための対策を行うことはそんなに難しいことではないですし、いつ解決するのかを見積もることも比較的容易に出来ます。インフラを構築する時は、この原因を突き止めるための材料(ログ、発生手順、システムの挙動、エビデンス)をできるだけ多く、楽に集める仕組みが必要ということを意識して、インフラを構築するべきです。

3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか

多くのシステムでは有料、無料を問わず、使い慣れた監視システムやパッケージ等のソフトウェアを導入していると思います。監視システムにより障害を検知し、関係者にアラートできることは当たり前ですが、障害発生後の

  • 1次受付け
  • 問題の切り分け
  • 判断をする役割、管理者の判断の有無(ビジネス上の)
  • 担当者割当

が重要になります。障害が発生したときは、少なからず現場が混乱した状態になることが考えられますので落ちついて対処するためのルールやマニュアルを問題が起こる前に決めておくべきです。

4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか

アプリケーションの性質に合わせて、特にOS、ミドルウェアの設定は本番サービス開始までに必ず見直しをするべきです。
Apacheの設定ファイルやPHPの設定ファイルが環境によって異なっていたり、開発環境の設定になっている場合がよくありますので注意が必要です。Web#1とWeb#2は同じ役割のはずがApacheの設定やPHP.iniの設定が違う・・・は避けたいですね。

5. メンテナンス時間を最小化できるか

システムを長時間稼働させるように構成されたシステムにおいても、メンテナンスは多くのサービスで必要になります。ソーシャルゲームの場合、メンテナンス中は利用者が「アクセスすることが出来ない = 売上がない」、状態であるため可能な限りメンテナンス時間を最小化させる方法を考えるべきです。

  • メンテナンス中に実施している作業は本当に必要なのか・・・サービス停止しなくても良いのでは?
  • 夜間等のバッチ処理でできるのではないか
  • ジョブの順番や時間帯の変更は可能か

等の今より最適化することは常に考える必要があります。可能なら無停止アップデートができるのかを検討すべきです。

6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか

ウェブアプリケーションやソーシャルアプリでは、Apache、MySQL等のミドルウェアのログ、システムログ、アプリケーションログと見なければいけないログが散らばっており、さらにサーバによっても分散していると思います。開発や運用に多くの情報とヒントを提供するものがこのログファイルです。ログファイルをいつでも、すぐに参照できるように管理(集約、集計)することはとても重要です。

サービスが運用フェーズに入った段階でも、警告やエラー情報、タイムアウト等の異常をすぐに見つけ、原因を探す糸口として活用できるようになっているのかをチェックします。

7. アクセスの状態を把握できているか(全体PV、ページPV、日毎、時間毎、リソース)

サービス提供しているウェブサイトのアクセス解析を導入しているのか、また導入済みのアクセスログから自分たちに必要な数字を把握できているのかはとても重要なことです。直接利用者の動向を把握することが出来るツールになるため、自サイトのターゲットと実際の利用者の行動を把握するために活用できるような仕組みになっている必要があります。

8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか

Webアプリケーションの場合、役割によってサーバを分けたりパフォーマンス向上のために分割したり、をよくやります。ボトルネックになりやすいDB(マスタ)やスレーブDB等、機能の明確化をメモ書きしておくことで

  • システムの全体像を把握したり、
  • 将来の拡張性を考える
  • 運用保守の補助資料として利用
  • チーム内で情報共有(どのようなインフラになっているかを説明出来る)

ができます。役割分担(機能分担)を明示することはとても重要になります。

ソーシャルアプリ開発プラットフォーム(クラウド環境)

ソーシャルアプリ開発プラットフォーム(クラウド環境)/開発・ステージング環境

9. バックアップ・リカバリの方法は確立されているか

アプリケーションやDBのバックアップを実施することは比較的容易に出来るのですが、

  • リカバリにどれくらいの時間が必要なのか、
  • 正常にリカバリできるのか

ということは問題になるのではないでしょうか。

バックアップ・リカバリについては本番機と同等のマシンでリハーサルを実施しなければ正確なリカバリ時間や問題点は見えてこない場合が多々あります。(見積だけでは理想値になりやすく、試験をしない場合、障害が起こったときに想定外のトラブルや取り返しの付かない問題が発生すると考えるべきです。)
どうしても開発中は開発が優先されるため、バックアップ・リカバリは後回しにされる場合がありますが、利用者データや自分たちのシステム保全はとても大切なことなので実際にやってみることはとても重要になります。それが運用マニュアルとして記録されているとベストです。

 

10. 監視用アプリケーションは正しく、漏れなく設定されているか

システムのリソースやサービス監視用の専用ツールはとても高機能で便利に利用しているサイトが多くあります。自分たちのアプリケーション特性にあったチューニングや設定ファイルになっているのかを確認すべきです。デフォルトのままというありがちなミスをしないように注意する必要があります。

 

ソーシャルアプリ、ソーシャルゲーム開発のプラットフォームを構築するインフラエンジニアは表に立って活躍する目立つ存在ではありませんが、縁の下の力持ちな人材です。ソフトウェア開発期間よりももっと長い期間、運用を支える大切な基盤環境を構築しなければいけません。
インフラに関する10個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。

 

SAP:ソーシャルアプリ開発を支える技術(バックエンド)

ソーシャルアプリ・モバイルアプリケーションの開発環境や支える技術についてご紹介。
ソーシャルアプリとは、mixi、mobageやGREEなどのSNSプラットフォーム上で動作するアプリケーションです。
2009年末頃から各SNSプラットフォームのオープン化が進められ、外部開発者でもアプリケーションを開発し、SNSに登録されている多くのユーザに対して公開できるようになっている。数千万人という会員をもつプラットフォームに公開が可能になることで、労せずに大量のユーザに利用してもらえる可能性が高い。
また、これまでのコンシューマ向けのゲームやECサイトと違い、SNSの利点を活用したコミュニケーションを重視していることが特徴の1つになっている。

ビジネスとして考えた場合、

  • 大量のユーザにリーチ
  • 少ない投資で開発が可能
  • その上で大きな成功の可能性あり

など、良いことだけを挙げると一日でもはやく始めたいと思うかもしれないが、そんなに簡単ではないことは承知の通り。
開発者から見たソーシャルアプリ開発で重要だと思われる点は

  1. 競合が多いく、早いリリースが必要 → 開発の効率化
  2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える → インフラ・維持費
  3. クチコミ等、一気にユーザが増えた場合のスケールアップ → インフラ・スケールアップ
  4. 利用者に向けたイベント、日々サイト更新必須 → サービス運営・ソフトウェアライフサイクル

 

1. 競合が多く、早いリリースが必要(開発の効率化)

ciklone(サイクロン)を利用しているお客様で携帯向けやスマートフォン開発されている企業様から話を聞いたり、開発者と話をすると、数名~5,6名の開発チームで2,3ヶ月くらいの期間でリリースとなる場合が多いようです。
開発の効率化について実践していることは

  • Ruby/PHP/Python等フレームワークを利用
  • 開発環境の仮想化・チーム内で共通化
  • バージョン管理システムとバグ管理システムの利用
  • 開発拠点の分散に対応したコミュニケーションツール・情報共有ツールの利用

などがあります。ソーシャルアプリを開発している企業の傾向がベンチャーというのもあるかもしれませんが…

2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える

初期費用で一番コストがかかるのがサーバ費用やデータセンター費用(人件費以外で)。この費用は売りあげゼロでも確実に必要になる費用です。多くの企業でインフラに関する部分は8,9割がクラウドサービスを利用されているようです。最近は国内クラウドサービスも増えてきており、日本語でのサポートや情報が充実しています。

  • GMOクラウド http://www.gmocloud.com/
  • ニフティクラウド http://cloud.nifty.com/
  • Amazon EC2 http://aws.amazon.com/jp/ec2/

 

3. クチコミ等、一気にユーザが増えた場合のスケールアップ

自分たちのアプリケーションのユーザが増えることはとてもうれしいことですが、不測のアクセス増加(それも何十倍)が起こった場合には

  • ハードウェアの増強 – Webサーバを増やす、キャッシュサーバを増やす、DBサーバを増やす
  • アプリケーションのチューニング

などの対応が必要になります。ここでもクラウドによる大きなメリットがあり

  • スケールアップが容易
  • 一気に増える時間帯、特定の日のみサーバ数を増やすなどの柔軟な対応

が可能です。
開発期間中に高トラフィックを発生させ負荷試験を実施したり、チューニングをすることがとても重要です。わかっていても現実のタイトなスケジュール内ではその時間と人材を確保することが難しいのが現実です。

4. 利用者に向けたイベント、日々のサイト更新必須

ソフトウェアやソーシャルアプリは開発期間よりも運用期間の方が長いことが通常だと思います。特にソーシャルアプリの場合、既存のユーザが飽きないように次から次へと新しいキャンペーンやイベントを行っています。
あるソーシャルゲームサイトでは、朝、前日のアイテム課金結果をみてよく売れている傾向から、その日の夕方には傾向に沿った新アイテムをリリースしたり。週替わり、月替わりのタイミングでイベントを実施したりしています。小さな改善だけではなく、コアなシステムに影響のある変更までユーザ動向に合わせた改善が日々くり返されています。

これは

  • 複数サーバの安定した運用
  • 複数サーバ(数台~数十台)に確実にリリースするデプロイ管理
  • 24時間のサーバ、サービス監視
  • ログの解析、ログの視覚化
  • デザイン・素材・プログラムのバージョン管理
  • 不測の事態と前兆を教えてくれるアラートシステム

 

ソーシャルアプリ開発では提供するサービスだけではなく、バックエンド側にも高度な技術力が必要とされます。
すべての環境が満足できるレベルまで整備されたプロジェクトが理想ですが、そのようにできない場合が多いのではないでしょうか。
技術者のスキルによりカバーできる部分とできない部分を見極め、あなたのチームに最適な環境を見つけてください。
そのための開発方式やインフラ技術について情報提供していきたいと考えています。


クラウド型バージョン管理cikloneが近日バージョンアップ

こんにちは。wiki.ciklone担当のhayashidaです。

何だか熱くなったり、寒くなったりで体調管理が難しい気候が続きますね。皆様お元気でお過ごしですか?
そんな今も空はどよどよ。今朝はレインコート着て出勤しました。

さて、cikloneの新バージョンが近日中にリリースされそうです。それに伴いcikloneHPもリニューアル致します。

cikloneHPもリニューアル

Wiki.cikloneはサイクロンのマニュアルを掲載しています。

残念ながらwikicikloneのデザインは変わらずですが・・・cikloneの新機能に付いてなど詳しく掲載していくつもりです。

※wiki.cikloneではciklone(サイクロン)のマニュアルやら便利なTipsやらFAQやらを掲載しています。
いつまでの無料のフリープランもこれまでと同様に使用頂けます。
サイクロンのフリープランはいつまでも無料です。

今日はご報告までですが、次回はより詳しいバージョンアップ内容をご報告出来ると思います。

ではまた!

サイクロンの便利なTipsやFAQを公開中

こんにちは。wiki.cikloneを担当しています、hayashidaです。
Wiki.cikloneはサイクロンのマニュアルを掲載しています。
残念ながら、wiki.cikloneの認知度が低いので、ブログ側でもちょっと紹介させて頂こうとやって来ました。

wiki.cikloneはciklone(サイクロン)のマニュアルやら便利なTipsやらFAQやらを掲載しているページです。

そもそもciklone(サイクロン)って何さって方はこちら

一言で言うとクラウド型のバージョン管理システムです。

ちょっとだけ、サイクロンの画面のイメージをお見せするとこんな感じになります。
サイクロンプロジェクト概要ページ

バージョン管理インシデント管理の必要性は感じているけど、サーバーの設置や管理メンテが面倒・・・という方は是非、いつまでの無料のフリープランから試してみて下さい。
サイクロンのフリープランはいつまでも無料です。

そして利用方法等で不明な点はwiki.cikloneをのぞきに来て下さい。

もちろんお問合わせもおまちしています!(まだまだ情報不足なので・・・)

では、また。wiki.cikloneで更新した情報などこちらでも紹介しにきます。