プロジェクトの立ち上がりをスムーズにキメるためには、開発環境の整備が、欠かせません。

受託開発を始めた当初は、社内に開発環境を構築するのに、手間と時間がかかっていました。アプリケーションの開発ばかりやってきて、環境作りを、あまりやって来なかったので、毎回が試行錯誤の連続で、随分と、時間を浪費していたように思います。この当時は、プロジェクトの2初回の進捗報告のときから、すでに、遅れが出ているということも、少なくなかったように思います。

自社内で開発をするためには、この状況を何とかせねば、ということで、カイゼンに乗り出したわけですが、おかげさまで、今では、大きく解消できていると思います。

手順書ライブラリの運用

最初に取り組んだのは、開発環境の構築手順の作成です。
手順書を運用する前は、頭の中に手順があるので、同じ環境を作るだけなのに、担当する人が違うと、それぞれで、試行錯誤していて、「・・・言ってくれれば、教えたのに・・・」という会話が聞こえてきたりして、イライラしたものです。

これは、まだDevOpsが言われる前の話なので、環境を作るというのは、全部手作業でした。 ミドルウェア毎に、インストール時のコマンドや、設定ファイルの修正箇所と、設定値を、文書化して、手順のライブラリ化に取り組みました。

プロジェクト毎の手順書は、手順ライブラリから、必要なところを、コピーして、プロジェクト用の冊子にする感じです。まぁまぁ、うまくいったと思います。

Vagrant と Docker

次に取り組んだのは、Vagrant、Docker です。
上記の手順書ライブラリも、悪くはないけれど、環境を作った後に、ターミナルのログを拾って、手順を起こしていた関係で、たまに、間違った記述があったり、パッケージのバージョンが書かれてなかったりと、手順書のとおりに、環境が作れないことがあるんですね。
Vagrant、Dockerを知った時に、この問題を解決してくれることが、すぐにピンときたので、躊躇なく乗っかりました。

だた、一緒に紹介されることの多い、 chef と ansible は、全面的には、取り入れていません。
この2つのツールについても、チーム内の全員が、学習しないといけないのか？と考えた時に、そこまでは、やりすぎかも・・・という点と、シェルスクリプトだけでも、結構、作れるので、今は chef と ansible については、優先度を落としてます。
何しろ、他にも、やりたいことがたくさんあるので。

イメージの固定化

Vagrant と、Docker を併用した環境準備は、ほぼすべてのプロジェクトで、これらを使うようになりました。かなり浸透しました。
以下は、次に、やろうとしている取り組みです。

開発が進んでいく中で、環境を作り直すことがあります。必要なライブラリが追加されたり、ミドルウェアが追加された時などですが、外部のリポジトリがダウンしてたり、ネットワークが混んでいて、異常に時間がかかったり、外部要因によって、開発が停滞することがあります。
特に、最初の開発環境を作る段階では、何度もダウンロードとbuildを繰り返すので、どこかに、キャッシュできるとよいし、そのキャッシュをチーム内で共有できると、もっとよいと思っています。

さらに、OSS等のマイナーなバージョンアップで、動かなくなったりすると困るので、開発の元にしたライブラリやパッケージを、Dockerイメージの中に封入して、原則、社内リポジトリからの docker pull だけで環境を作れないものか、模索しています。

標準PC

開発用PCを統一するのも、環境構築のスピード化に寄与するかもしれません。
社内では、Windowsでの開発を、原則としています。
Macで作ったから、Windowsじゃ動かないかもです・・・という、めんどくさい会話で時間を無駄にしたくないのが理由で、納品先のお客様の多くが、Windows環境なので、Macじゃなくて、Windowsを標準PCとして、統一しました。
Macを使ってる人の中には、 Windows を嫌う人もいますが、悪くないですよ、仕事には、十分です。

ちなみに、弊社は、全員の PC が Vaio です。
購入時期によってモデルが違うものの、主なスペックは、13インチのノートPCで、Core i7、メモリ8～16Gで、他に、外付ディスプレイを使ってます。
どこに移動しても、Vaio用のACアダプターが、延びているので、デスクの移動は楽ですかね。あまりメリット感が出てませんが。