継続的インテグレーション (CI) を啓蒙するスレ

**デフォルトの名無しさん** · 2018/02/17(土) 23:31:46.57

GitHubの普及で身近になってきた、Travis CIやAppVeyorなどのCIの便利さやテクニックなどについて、語りましょう。

**デフォルトの名無しさん** · 2018/02/18(日) 00:08:48.88

あるならあるで良いんだが、効果は限定的だと考えるようになってきた。

なぜならCIで実行するものは何かというと通常テストの実行だが、
テストの実行というのはどちらにしろローカルでも行うから

「テストを実行するの忘れない」とか「みんなが見れる場所でテストが実行されている」
というメリットは有るのだが品質にはあまりつながらない気がする。

もちろんローカルでやるのが大変なものを、CIだと簡単にやれる
という状況であれば効果は高いのだが、ローカルでやるのが大変なものってなんだ？
それがCIで簡単にやれるためには相当ハイスペックなマシンが必要じゃないか？
みたいになる。

重要なのはCIで実行する「内容」であって、CIという手段ではないので、
あまり手段にこだわってもなぁという気がしている。

もちろんあるのとないのではあったほうが良いんだよ。でもアレば少しマシぐらいの感覚

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/02/18(日) 00:13:22.23

LinuxとiOSとWin、x86とx64でビルド&テスト&デプロイやれって言われて、普通、人間にやらせるか？ CIに任せるだろ。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/02/18(日) 00:17:59.59

CIは仮想化の力で複数の環境におけるビルド&テスト&デプロイをバッチ処理として、自動化する。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/02/18(日) 00:29:11.34

テスト要員を半分以下に。単純作業のテスターは要らない。

**デフォルトの名無しさん** · 2018/02/18(日) 02:17:46.61

>>3
それスクリプト流せばいいだけだろ
CIの価値とは全く関係ない

**デフォルトの名無しさん** · 2018/02/18(日) 02:48:20.51

先に>>6に言われたなｗ

例えばgoはコマンド一つで複数のプラットフォーム用のバイナリを生成することができる
CIはビルド&テスト&デプロイをやってくれるものだと考えているかもしれないが、
別に自分のマシンからだってビルド&テスト&デプロイは行える

つまりCIの価値というのは、ビルド&テスト&デプロイそのものではなくて
ワークフローを統一化できるというところにある

それはそれで良いことなんだが、CIのメリットというのはワークフローの統一化だと思うと
思っているほど大したことしてないと思うだろ？

そしてもう一つは、テストマシンリソースのレンタル
テスト自体は自分のマシンでできる。だけど自分のマシンで追いつかないようなものは、
CIサーバーに頼んで借りられる。ただしCIサーバーのスペックが高いか、
クラスタでも組んでないと自分のマシンでやったほうが速いってことになりかねないｗ

ちなみに普段の開発中にはCIは利用しない。なぜならCIでは特定のメソッドだけテストの実行を行う
なんてことがやりづらく自分のマシンでテストを実行したほうが速いから。
CIによるテストは時間が掛かるテストをお行うもので、時間がかからないテストはローカルで済ませる

>>5
> テスト要員を半分以下に。単純作業のテスターは要らない。

それを実現するにはCIサーバーを導入しても実現できない。
単純作業（テスト）を行うためのテストコードが必要。
だがテストコードがあるなら、それは自分のマシンでも実行できる

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/02/18(日) 06:10:30.39

C言語におけるCIのサンプルです。ご参考に。

https://github.com/katahiromz/getoptwin
https://github.com/katahiromz/getoptwin/blob/master/.travis.yml
https://github.com/katahiromz/getoptwin/blob/master/appveyor.yml

**デフォルトの名無しさん** · 2018/02/18(日) 09:28:42.57

それCIじゃねーよ

**デフォルトの名無しさん** · 2018/02/18(日) 18:08:34.16

自分のマシンでできない事はないけど、複数のOS上かつ複数のランタイムバージョンでテストを実行してついでにオーケーならデプロイまでしてくれるからなあ。
それをローカルでやるとなると必要な分だけの仮想環境を用意してさらにそれら環境全部の実行待ちの時間もバカにならんし、ぎゃくにローカルでやるメリットがあまり思い浮かばない

**デフォルトの名無しさん** · 2018/02/18(日) 18:38:31.65

>>10
でもさ、それって複数のランタイムバージョンでテストしなければいけない状態
にのみ成り立つでしょ？意外と少ないと思うんだよね

**デフォルトの名無しさん** · 2018/02/18(日) 19:30:06.94

>>11
まあ必要ない状況ならそれでいいんじゃないの。
俺が扱ってるプロダクトだとそれが必須だからCIツール様に足向けて寝られないくらい助かってるんだわ。

**デフォルトの名無しさん** · 2018/02/18(日) 19:38:21.45

つかスレの流れを見てなかったけど、何でもかんでも猫も杓子もCI使えばいいってもんじゃねえって話なのね。
それなら完全に同意だわ。

**デフォルトの名無しさん** · 2018/02/18(日) 19:39:15.73

といってもCIを使うデメリットも特に思い当たらないから何となく使うのもいいとは思うけどな

**デフォルトの名無しさん** · 2018/02/18(日) 20:13:05.44

微妙に噛み合わない会話が続いているのはCIツールのことをCIって呼んでるやつと
プラクティスの名前としてCIって言葉を使ってるやつとに分かれてるからだね

**デフォルトの名無しさん** · 2018/02/18(日) 20:17:21.91

プラクティスとしてのCIなら自分のローカルマシンでやってても、上で書いてあるようなことをやってるならそれはCIだわな

**デフォルトの名無しさん** · 2018/02/18(日) 20:26:49.49

CIの肝はセントラルリポジトリに対してテストを行う時点で、自分のローカルとCI環境の最低二ヶ所の環境でパスすることを確認できる事なんだけどな。
ローカルだけでやってたら、環境依存の問題は絶対に見つけられんからあまりやる意味もない気がする。

**デフォルトの名無しさん** · 2018/02/18(日) 22:55:00.28

>>16
それはもう一段階詳細な相違点
プラクティスとしてのCIをローカルとは別のCIサーバーを使う前提で捉えてる人もいるってこと

>>17
ローカルでもVM使って複数環境のテストできるし
CIじゃなくてもビルドスクリプトでリモート環境を複数利用したテストもできる

結局それらを”自動で継続的に”実行するかどうか

**デフォルトの名無しさん** · 2018/02/18(日) 23:13:32.08

>>15
普通CIっていったらCIツールの導入じゃね？

俺が言いたいのは、テストコード無くて別に自動的にデプロイするわけでもないのに
CIツール入れても意味ないよね？って話

まずはテストコードは書くことが重要。
で書いてしまえば、ローカルでもできるじゃん？

ビルドとかデプロイとかコマンド一つでできるじゃん？
じゃあCIツール入れるメリットってなんだろう？って話

CIがテストやMakefile書きましょうレベルの話ならば
なんだ俺は普段からCIやっていたのかｗってことになる
もちろんそんなわけないので、テストやMakefileを書いている俺からすると

CIツールの導入で得られるメリットというのは、
MacのAutomatorのフォルダアクション（指定したフォルダにファイルが
追加された時に指定したコマンドを実行）レベルのものなんだってこと

もちろんそれがみんなに共有されるってことはわかるんだけど、
フォルダアクション＋情報共有がCIツールの本質なんだなぁって話

**デフォルトの名無しさん** · 2018/02/18(日) 23:21:49.77

まあ要するにローカルでテストできる体制も整ってないのに
Travis使います。Jenkins使いましょう。といっても効果ないよってことだよ

まず最初にテストやMakefile相当のものを作る。
そしたらCIツール使える状態になるけど、
次は、あれ？CIツール使わなくても全部ローカルでできるじゃん？
ってなると思うよｗ

そこから先、CIツールを導入する目的が何かを自動化できるだと
理由として弱い。全部ローカルで出来てることだから