タイトルのような組み合わせを構築して運用していい感じに回してる話しをよく聞きます。Jira のところが Redmine のケースや他のサービスを使ってるっていうパターンもありますね。Circle CI のところは自前 Jenkins とかみたいなケースもありますね！ 私は Jenkins は太古のバージョン（Hudson から名前が変わった直後くらい）と Redmine を一時期使ったことがあるくらいなので、これから書く、これらのツール類についてのことは正しいことを書いてない可能性が高いです。間違えてたらコメントなどで是非最近の〇〇はこういうところが凄くいい！！って教えてください。
とりあえず言いたいのは「それ Visual Studio Team Services(VSTS) でも出来るよ！？」ということです。 別に今時点で運用がうまく回ってるものを無理に VSTS にしてほしいわけではなくて、これからこういう環境整えたいなという人が VSTS ってのもあるのか～って思ってもらえたら目的達成です！
Visual Studio Team Services
以下の機能を提供する SaaS です。
- プライベート git リポジトリ
- 自動ビルド
- 自動でデプロイ
- Wiki
- カスタマイズ可能なタスク管理
- 各種レポート機能
- テスト
ということで、VSTS を使うとこれらの環境が全部使える状態が整います。強いのは開発者 5 人まで無料。開発しない人でタスクとか見れたらいいっていう人は、ここにカウントされないということです。 純粋にデベロッパーが 5 人まで無料です。
料金面の詳細については下記ページをご確認ください。
プライベート git リポジトリ
VSTS は 1 つのプロジェクトに対して複数個の git のリポジトリを持たせることが出来ます。
このスクリーンショットでは、UWP book と Sources という 2 つのリポジトリを作ってます。 これ、地味に便利だと思うのですがどうでしょうか？
1 つの VSTS のアカウントに N 個のプロジェクトが作れて、プロジェクトごとに N 個のリポジトリが作れます。例えば共通機能とかを実装する人たちのリポジトリは別途用意しておいて適切なタイミングでリリース。各種個別機能を作る人達はリリースされたライブラリを参照して別リポジトリで開発とかいうことも出来ます。
リポジトリのブランチごとに色々なポリシーが設定できて、直接 push することを禁止して必ず pull request 経由で更新することとかというのが設定できます。pull request をマージするには最低何人のレビューが必要とか、必ず〇〇さんの承認が必要なこととか、特定のビルドが走ってエラーが無いこととか、どのタスクのための pull request なのかをきちんと設定しないとダメとか色々設定できます。これらを駆使することで例えば master ブランチには変なコードが入り込む可能性を減らすことが出来ます。
プライベートなライブラリ公開場所
VSTS には Package Management という機能があってライブラリを世界中には公開したくないけどパッケージマネージャー使ってインストールしたい！といった要望にこたえることが出来るようになっています。
nuget（.NET 向け）、maven（Java 系向け）、npm（言わずと知れた node.js）に対応しています。 先ほど書いたように、ある程度の大きなチーム単位でリポジトリをわけた場合にはビルドした結果のライブラリを参照して使うという形になると思うのですが、このときに、この Package Management を使うと世間のオープンな場所に置かずに自分たちだけのライブラリ置き場が出来て nuget、maven、npm を使ってインストールすることが出来るようになります。
VSTS には後で説明する自動ビルド機能とかもあるので、それと組み合わせて master ブランチに変更があったらビルドしてライブラリを更新するっていうことも出来ます。
自動ビルド・自動でデプロイ
VSTS には自動ビルドしてくれる機能があります。 これは VSTS のリポジトリに対してのビルド以外にも GitHub や SVN や GitHub Enterprise などの外部リポジトリに対してもビルドをすることが出来ます。
組み込みで .NET、Java（maven、Gradle、Ant）、Python、node.js(Grunt、Gulp）、Xcode(オンプレにビルドエージェントが必要、要はビルドを実行するマシンは自分たちで用意して VSTS からビルド時に使うように設定する) 、Go(Preview) などに対応しています。Docker にも対応してるみたい。
ビルドの定義は、1 つ 1 つのタスクを組み合わせて定義できるので Ant でビルドしたあとに Visual Studio のビルドを走らせるとかいったことも出来るようになっています。
やろうと思えば自分たちでタスク自体を作ることもできるので、頑張れば結構なことが出来ます。 まぁタスクを作る前に、任意のシェルスクリプトやバッチファイルを走らせるタスクがあるので、それでかりっとやると割と何でもできちゃいそうな雰囲気はあります。
このビルドの定義の中で、各種クラウドサービスにデプロイまでやることも出来ますが、リリースは偉い人の承認が必要だとかステージング環境にデプロイしたのちに問題がなかったら手動で本番環境に持っていくといった凝ったリリース方法をやるためにリリースは別機能としても提供されています。
Wiki
普通に markdown で書ける Wiki もあります。 Wiki は git で clone してローカルで編集して push とかも出来ます。メモやドキュメント置き場として
カスタマイズ可能なタスク管理・レポート
Scrum、Agile などのいくつかの組み込みのタスク管理のテンプレートが提供されています。 イテレーションを作って、人を割り当てて、各々のキャパシティを割り当てて、フィーチャーを定義してフィーチャーをイテレーションに割り当てて、それぞれにタスクを割り当ててカンバン形式で見たり、タスクに対して任意のクエリを定義して自分たちが見たい方法で見たりとか色々できます。
そして、バーンダウンチャートを見たりダッシュボードに色々ぺたぺたはりつけてレポートちっくに仕立てたりといったことが出来ます。ここらへんは前にチーム開発じゃないけど個人用タスク管理として使ってみた！という記事書いたので見てみてください。
テスト
これ使ったことないんです。 マニュアルテストとかロードテストとかに使えるみたいなんですがユニットテストで自動ビルドで回すくらいまでしかしたことがないのですが、これを使うとマニュアルテストとかロードテストとかいけるみたい。
まとめ
ということで VSTS の認知度が少しでも上がるとうれしいな！ということでした。
ちなみに、VSTS は全機能使わないといけないというわけではなく、一部機能だけ使って他は外部サービス使うとかもできます。リポジトリは GitHub だけどタスク管理とかは VSTS みたいなのも OK です。