開発環境編成計画：Gitによる分散管理体制への移行（前編）
Posted by 867 on
社内の開発環境を一新し、今までの集中管理体制からGitを使った分散管理体制にスイッチすることにしました。 今回はその概要をまとめたいと思います。
大幅な変更をする理由
旧環境は前社時代から継続して採用していたもので、現状でも大きな問題はなく、初心者であっても急に参加した人でもスムーズにプロジェクトインできる、効率的かつ分かり易いいい環境だったと思います。ただし、特定のソフトウェア（Dreamweaver）に大きく依存している点、また「会社に来て作業をする」ことを前提としている点で、多様化する働き方・協業の仕方に合わなくなってきているなと感じ、大きく方向転換することにしました。
旧環境の概要図とメリット・デメリット
旧環境の全体像は次のようなイメージです。
ネットワーク上に仮想サーバを構築
旧環境では、LAN上に仮想化された開発サーバを複数台構築し、そこをローカル環境として使用していました。
- 各自のマシンにはローカル開発環境を持たず
- ファイルもローカルマシンには保有せず、すべて開発サーバで集中管理していた。
- 開発サーバにDNSを構築しており、プロジェクトごとにサブドメイン形式でブラウザ参照することができた（例：http://projectA.nutmeg.gf, http://projectB.nutmeg.gf）
- 開発サーバにSambaを構築しており、ファイルの操作はWindowsのエクスプローラでできていた。（開発サーバへのファイル操作にFTPは不要）
- 月次にフルバックアップを、日次で差分バックアップを取っていた。
ファイルの操作はDreamweaverで完結
また、各自のマシンにはDreamweaverを入れ、次のような環境を実現していました。
- チェックイン／チェックアウトの機能を使うことで作業競合を防いでいた。（この機能を使うと、作業者Aが操作するファイルにはロックが掛かり他者が操作できない状態になる）
- ローカルサーバ＝ネットワーク上のサーバ、リモートサーバ＝公開テストサーバを指定することで、テストサーバへのアップロードに別のFTPクライアントを操作する必要がなく、作業効率が良かった。
- 上記により、ローカルとリモートが常に同期されていた。
- プロジェクトごとの設定ファイルを共有することで、どのマシンでも同じ環境をすぐに整備することができていた。
デメリット
旧環境の一番の良さは、新しくメンバーが増えても環境構築に時間を費やすことなく、設定ファイルさえインポートすればすぐにでも制作に参加できたことだろうと思っています。 ただ、とても会社（場所・インフラ）に依存した環境である点と、新しい技術を存分に使えない点に、改善の必要性を感じました。
- ファイルの操作のために、サテライトメンバーにもDreamweaverが必要なこと
- ローカル開発サーバに障害が起こるとホームメンバー全員の仕事が止まること
- バージョンのバックアップがあるのはローカル開発サーバのみで、サテライトメンバーの作業・およびホームとサテライト両者の結果（テストーサーバ）においてはバージョン管理がされていないこと
- ローカルマシンでの稼働を想定した新しい開発技術（例：SASS）の利点を活かせないこと
新環境への移行にあたって
旧環境は、設備・インフラ整備の負荷が高い反面、それを利用する側のハードルが低く、環境面へのリテラシーが問われない状況でした。また、どんなスキルの人が来ても、同じような環境を提供できる仕組みを作ることが、一つ私の仕事でもあると思っていました。
しかし、会社がすべての環境を用意することや、誰かがいないと仕事の環境に影響する体制はもう旧式なのだと思います。組織ではなく、もっと個に焦点が当たるようになっていく。それは反面、個に自力が求められるということ。チームとして用意すべきことと、個に求めることのバランスを考えることが、当面の課題になりそうです。
新しい環境の全体像については、開発環境編成計画：Gitによる分散管理体制への移行（後編）をご覧ください。