2015年9月28日月曜日

SubversionとGitの連携

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載の途中なのですが、その副産物でちょっとした事に気付いたので、今回は番外編です。

内容は、「SubversionとGitの連携」です。

今の潮流はGit

さて、このブログをご愛読の皆さんはGitをご存じでしょうか?
使ったことの無い人でも名前くらいは聞いたことのある、世界的に有名なバージョン管理システムです。

細かい内容は専門サイトにお任せするとして、やっぱり最近はGitが流行ですよね。

流行の原動力となっているのは、こちら、GitHubが最大の要因でしょう。


まあ、簡単に言ってしまえばGitサーバレンタルサービスとでも申しましょうか。

オープンソースを開発してGitHubに掲載!!
今の時代はこれが世界で一番クールなIT技術者というイメージです。

プログラマーなら一度はオープンソースを作ってGitHubデビューしてみたいですね。

弊社はSubversion

しかし、バージョン管理システムはGitだけではありません。
他にも色々なバージョン管理システムがあり、その一つにSubversion(以下、SVN)があります。

弊社、ジェニシスでは主にこのSVNが使われています。

何故、GitではなくSVNを使っているかって?
そりゃ、前からSVNだからですよ。

今までSVNでソース管理してきちゃってるんだから、今更Gitに引っ越しなんて大変でしょ?

分かり易い事情としてご理解頂けると思います。(泣)

このため、私もGitを使う機会が殆ど無かったのですが、最近の連載であるAzureはGitを使う都合上で触っていたら、なーんだ。
既にSVN運用していても途中からGitデビューする方法があることに気付きました。

これが今回のテーマになります。

SVNの問題点

さて、何故私がSVNからGitに乗り換えることを画策するのか?
それはSVNには困った問題点があるからです。
それは「ゴミコミット」です。

まず前置きとして、SVNは特にチーム内で運用ルールを設けない限り、開発メンバーは以下のようにガンガンソースをコミットしてきます。



結果、このようにコミット履歴がボンボコボンボコ。。。
中にはミスコミットも混ざり込んでいることもあります。
リポジトリの肥大化が著しいですね。
これがゴミコメット問題です。




「だったらコミットルールを作れば良いじゃん?」

ってのはありますね。

  • レビューが完了するまでコミットしない。
  • コミットする時は複数人でコミット。

こういうルールにしておけばゴミコメット問題は発生しません。
しかし、これは面倒&非効率なのですよ。

実装者の立場としては、

  • ちょっと作って、動作確認。コミット。
  • ちょっと作って、動作確認。コミット。
  • ちょっと作って、動作確認。コミット。

これを繰り返したいのです。
そして何かミスってソースが壊れちゃった場合は、前回コミット段階までロールバック。
綺麗スッキリやり直し。

こうやって実装を進めるのが効率が良いのです。

しかし、「レビューが完了するまでコミット禁止」なんてやられるとこのテクニックが使えません。
あっちこっち未コミット状態になってしまって、何が何やら……。

逆にミスして変なバグが起きたりしないか、心配でなりません。



小まめにコミットした方が安全、合理的。

これは絶対そうなのですよ。
しかしこれだと上記のゴミコメット問題が発生する……。

Gitの利点

しかし、Gitだとこのゴミコメット問題が解消されます。


Gitでは本体リポジトリのクローンを自分のリポジトリに作って、クローンに対してコミットします。
そしてレビュー完了など万全な状態になったら、「プッシュ」を行うことで本体と統合!!

自分のパソコンに作ったクローンに何をコミットしようが本体リポジトリには影響がありません。

これで作業効率は高いまま、リポジトリへのミスコミット、ゴミコメットを防ぐことが可能になります。

これはぜひGit使いたいなぁ……。
でもウチの会社って本体がSVNだし……。

SubversionとGitの連携

ずっとこう思っていたのですが、Gitを触り始めて気がつきました。

本体SVNをGitクローン化。
これが出来るじゃありませんか。



本体がGitでなければGitは使えないと思っていたが、そんなこと無かった。

例えばTortoizeGitのクローン操作画面でも、以下のようにSVNからのクローンというメニューが出てきます。


Gitクローンを自分のローカルPCに作ったら、後は普通のGitと同じです。

本体がSVNである以上はGitの全機能が解放されているとは言えませんが、
少なくとも自分のローカルPC内ではGit機能がバッチリ使えます。

ゴミコミット問題もこれで解決です。

すぐに始めてOK

このGitクローンの好都合な点は、自分のローカルPCの中だけで完結する話だということです。

自分のローカルPCに何が起きても周囲に派生しませんし、
本体SVNから見れば普通にチェックアウトしてコミットしているようにしか見えませんからね。

今までSVNを使っているチームメンバー全員が一気にこのやり方に変更するのはチーム運用上手間がかかる話ですが、
このSubversion-Git連携の場合、自分一人だけコッソリGit活用していても周囲には何の影響もありません。

さあ、Gitを使いたがっているそこのあなた、さっさと移行してしまいましょう。

ただし、今までGitを使ったことの無い人は、事前にちゃんと使い方を覚えてからをオススメします。
微妙に高機能で複雑ですから。

例えば、当記事の「何度も作業コミットして、最後に一回だけ本番プッシュしたい」という目的の時に、
普通に「SVNへコミット」を実行すると、ご丁寧にも作業コミット履歴まで遡ってSVNに入ってしまってゴミコミット状態と何も変わらないという憤怒のオチになっちゃったりします。

事前に「一つのコミットに集約」をやっておくとか、Gitの機能を知っておかないと目的を果たせませんので、事前勉強は怠らないようにして下さい。



終わりに

既にGitを使っている人にとっては当たり前の知識かもしれませんが、
新しい技術領域にチャレンジしてみると、副産物でこういうチョイテクに気付くこともあるものです。

技術者たる者、アンテナは幅広く伸ばしていきたいものですね。

2015年9月24日木曜日

【Azure】ソースチェックアウト

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載中です。
引き続き調査を継続していきます。

ソースを見たい

さて、前回までの記事の通り、AzureではWebアプリ作成時に最初からデフォルトで一通りのアプリがセットアップされた状態でスタート出来ます。
よって、Web上では既にソースが展開されているはずなのですが……、どうやってそのソースに手を加えれば良いのでしょうね?

どこかからチェックアウト出来るはず。今回はそれを探してみましょう。

ソース管理の統合

該当箇所はどこかな、と探していると、Webコンソールの最初の所にそれっぽいものがありました。

「ソース管理の統合」です。


トップページの一番下にありますね。
これを選択してみると……。


ふむ。
「デプロイの設定」というタイトルで一覧が表示されてきました。

  • Visual Studio Online
  • ローカル Git リポジトリ
  • GitHub
  • Dropbox
  • Bitbucket
  • CodePlex
  • 外部リポジトリ


色々ありますが、見た限りだと「Git」が目立つ印象です。
やっぱりGitにPushした瞬間にリリース完了、という手順が一番合理的なように思えますね。

話はそれますが、こんな所にDropboxが……。
画像とかドキュメントとかを共有したりクラウド活用したりする為のサービスだと思っていましたが、同じ要領でソースのデプロイにも使えるようです。
意外でした……。

さて今回、私は「ローカルGitリポジトリ」を選択したいと思います。


自分のパソコンにGitリポジトリを置いて、そこと連動するモードのようです。
これに当たって、私は先にGit本体と「TortoiseGit」をインストールしています。
WindowsでGitするならこれが定番でしょう。

では、次に進みます。

すると、ユーザとパスワードを登録する画面に来てしまいました。


んー。
AzureコンソールのログインIDとは別にデプロイ用のIDを必要とするようですね。

ここはIDは一緒にさせて貰った方がお手軽なのになぁ、と思う所ですが、
Dropboxとか別のアプリと連動する機能もある以上、別に権限管理しなければいけない技術的な都合があるのでしょうね。

お好みでIDを作成して次の画面へ。


おお。
心の準備をする前にGitリポジトリを作り始めてしまいました。ちょっと驚きました。

この辺りは外国製らしさを感じます。
日本のサービスだったら、きっと「Gitリポジトリを作成します。宜しいですか?」と確認メッセージが出て、そこで「はい」を押すと作成開始に進む流れだと思います。
しかし、外国製サービスでは問答無用で作っちまうというスタイルが多いです。

ユーザが作るつもりは無いのに間違えて作ってしまったら? その時は消せばいいのですよ。

  • 日本:間違えないように確認する為に確認画面を作成する。⇒工数高
  • 外国:間違えた? 修正画面で直せば大丈夫でしょ?⇒工数安

こういうノリなんですね。
日本人のおもてなし精神が垣間見える一面です。
しかし、その分だけ開発効率が……。なかなか悩ましい問題です。

さて、そうこうしているうちにリポジトリの作成が終わった模様です。


GITのURLをゲット出来ました!!

先ほど作成した私のIDがモロに出てしまっているので一部隠させて頂いていますが、URLをゲットすればこっちのもの。

後はコレをGit機能を使ってクローンしたりチェックアウトしたりすれば、無事にソースに触れるはずです。

続く

記事が長くなってきたので、ここから先は次回に回します。
しかし、かなり簡単に実現出来そうで好印象ですね。

2015年9月7日月曜日

【Azure】DBに接続

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

現在はMicrosoft Azureについて連載中です。
引き続き調査を継続していきます。

DBはどうなった?

さて、前々回のWebアプリ起動にて、CakePHPの起動を行いました。

これを見ると、以下のような記述があります。


  • Your database configuration file is present.

つまるところ、Webアプリ起動時にCakePHPを選んだ時点で、勝手にDBがセットアップされているわけですね。

お手軽なことこの上ないです。
今回はこれに対して接続してみたいと思います。

SQL Databaseではない

まず最初にお断りしておかなければいけないのは、今回のテーマはWebアプリサービスで作ったDBの話です。
Azure界には別のDBもあるのです。

その名は「SQL Database」です。


コンソール画面から行くことが出来ますが、作っていないので当然無いですね。

「SQL Database」は、Microsoftが誇るデータベース「SQL Server」のクラウド版みたいなもので、MySQLとはまた別の製品なんですよ。

検証は出来ておりませんが、クラウドならではの長所はきっとあるのでしょう。
しかし、世の中の製品は、大抵は「SQL Database」なんて想定していなくて、例えば上記で登場しているPHPライブラリ「CakePHP」なんかは、MySQLを選ぶことが標準です。

つまるところ、「SQL Database」を選んでしまうと、「ライブラリが対応していない」「ライブラリの一部機能だけバグる」「そのままでは使えない」みたいなそれなりのハードルがあることが想定されます。
ゼロから気合い入れて大規模サービスを構築する場合はこれも有力選択肢として検討したいですが、今回みたいに「とりあえず初めてみよう」みたいな初期コストを安く抑える発想でスタートするプロジェクトだと、ちょっと敬遠した方が良いんじゃないかなって気がしますね。

Azureの目玉機能の一つである為、「Azure データベース」で検索すると最初に引っかかるのはこちら「SQL Database」ですが、私が今回テーマにしているのは別物ですのでお間違えなく。

設定を探せ

では、DBの接続に必要な設定情報を探していきましょう。
知らないうちに出来上がっているので自分でもどんな設定になっているか分かりません。

探していくと、ここにありました。
Webアプリコンソールの「構成」のページです。


ここの下の方に行くと「接続文字列」という項目があります。


どうやらこれのようです。

「<セキュリティ上の理由により非表示>」とあって接続文字列が非常になっていますが、すぐ上の「接続文字列の表示」をクリックすると表示されます。

厳重機密事項ではありますが、このアプリは検証用で大事なものでも無いですので、一部公開します。

  • Database=tacyA36lcaR9nz8A;Data Source=ja-cdbr-azure-west-a.cloudapp.net;User Id=bcec23b3f13af8;Password=●●●●●●

これらの意味は以下のとおり。

  • データベース名:tacyA36lcaR9nz8A
  • 接続先URL:ja-cdbr-azure-west-a.cloudapp.net
  • ユーザID:bcec23b3f13af8
  • パスワード:●●●●●●

普通ですね。
ポートとかは乗っていませんが、デフォルトということでしょう。

では、これで接続してみます。


これでOKです。
接続出来ました。

簡単ですね!!

ログインしたら既に権限もあって普通に「Create Table」とかも出来ました。

考察

以上、ハッキリ言って特に変わったことなど何も無いです。
本当にハードルが低く作られた良い出来だと思います。

これだけ簡単で互換性も高いとなると有望ですね。

例えば、現行で既に時前でMySQLを持っていますが、これがサーバ故障や負荷などで大変な問題が起きているとします。
でも、サーバ引っ越しは大事ですから、そう簡単には出来ません。

そんな時、こんな風にチョロッとMySQLのインスタンスを作り、DBだけ先行して引っ越しすることも十分可能だということです。
DB接続パラメータを切り替えるだけなら工数も少なめですし、
いつぶっ壊れるか分からないDBを持つより、この方が余程安心でしょう?

理想型は全部Azureに引っ越しですが、こんな小技で乗り切るような柔軟性もAzureにはあるのです。

終わりに

それにしてもAzureは分かり易くて助かりますね。

引き続き検証を進めていきたいと思います。