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

1 ：デフォルトの名無しさん：2018/02/17(土) 23:31:46.57 ID:EwTJGG8P.net

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

2 ：デフォルトの名無しさん：2018/02/18(日) 00:08:48.88 ID:dp9S/ZRw.net

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

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

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

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

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

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

3 ：片山博文MZ ：2018/02/18(日) 00:13:22.23 ID:zL4UkFvD.net

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

4 ：片山博文MZ ：2018/02/18(日) 00:17:59.59 ID:zL4UkFvD.net

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

5 ：片山博文MZ ：2018/02/18(日) 00:29:11.34 ID:zL4UkFvD.net

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

6 ：デフォルトの名無しさん：2018/02/18(日) 02:17:46.61 ID:ydkJE298.net

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

7 ：デフォルトの名無しさん：2018/02/18(日) 02:48:20.51 ID:dp9S/ZRw.net

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

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

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

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

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

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

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

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

8 ：片山博文MZ ：2018/02/18(日) 06:10:30.39 ID:1UUb2h0E.net

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

9 ：デフォルトの名無しさん：2018/02/18(日) 09:28:42.57 ID:fvmxJoRp.net

それCIじゃねーよ

10 ：デフォルトの名無しさん：2018/02/18(日) 18:08:34.16 ID:zd+wqEcu.net

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

11 ：デフォルトの名無しさん：2018/02/18(日) 18:38:31.65 ID:F2O3xW/S.net

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

12 ：デフォルトの名無しさん：2018/02/18(日) 19:30:06.94 ID:zd+wqEcu.net

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

13 ：デフォルトの名無しさん：2018/02/18(日) 19:38:21.45 ID:zd+wqEcu.net

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

14 ：デフォルトの名無しさん：2018/02/18(日) 19:39:15.73 ID:zd+wqEcu.net

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

15 ：デフォルトの名無しさん：2018/02/18(日) 20:13:05.44 ID:ydkJE298.net

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

16 ：デフォルトの名無しさん：2018/02/18(日) 20:17:21.91 ID:LfAicYVt.net

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

17 ：デフォルトの名無しさん：2018/02/18(日) 20:26:49.49 ID:LfAicYVt.net

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

18 ：デフォルトの名無しさん：2018/02/18(日) 22:55:00.28 ID:ydkJE298.net

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

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

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

19 ：デフォルトの名無しさん：2018/02/18(日) 23:13:32.08 ID:F2O3xW/S.net

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

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

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

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

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

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

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

20 ：デフォルトの名無しさん：2018/02/18(日) 23:21:49.77 ID:F2O3xW/S.net

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

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

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

21 ：デフォルトの名無しさん：2018/02/19(月) 07:18:39.86 ID:YvDQTksi.net

絵に描いたような逆張り野郎だな

22 ：デフォルトの名無しさん：2018/02/19(月) 08:23:59.56 ID:YvDQTksi.net

>>18
君の言っていることは「メモ帳があれば高機能なエディタもIDEも不要」というのと同じくらいの暴論だよ

23 ：デフォルトの名無しさん：2018/02/19(月) 20:36:46.45 ID:anRYL6nk.net

>>20
CIの祖先はデイリービルドなんだよ
元々インテグレーションの苦痛を減らす目的で始まったプラクティスなわけ
ローカルかどうかとかは全然本質と関係ないから

24 ：デフォルトの名無しさん：2018/02/19(月) 20:39:13.91 ID:anRYL6nk.net

>>22
どこをどう読めばそういう解釈になるんだよww
俺はCIツールを否定してるんじゃなくCIってなんなのかって話をしてるだけだぞ

25 ：デフォルトの名無しさん：2018/02/19(月) 22:28:28.96 ID:bxmPXsfI.net

ローカルでやるからツールはいらないってか
なんというか、頑張ってくれとしか言いようがないw

26 ：デフォルトの名無しさん：2018/02/19(月) 23:20:16.94 ID:uhfYTKrf.net

>>23 >>25
違う違う。ローカルでやるから〜じゃなくて
逆にローカルでもリモートでも同じだって言いたい

みんなCIをリモートで専用のCIツール使ってやろうとするけど、
同じことをCIツール使わずにmakeとかnpmとかrakeとか
そういった言語用のツールでビルドやテスト実行してるでしょ？
もちろん必要と思われる任意のタイミングで手動で実行してるんだけど。

ローカルで手動でこれらの作業をやってるだけじゃ、
CIと言わないと思うんだけど、CIツールで行うとされてる
作業の全てはローカルで実行できるわけさ。
（自動的に実行もgitのフックを使えばできる）

そうするとこのローカルでやってる作業・・・がCIからみて足りないものは、
自動化されて忘れない。みんなと情報共有できる。という点で
もちろんこれはチーム開発では重要なことなんだけど、品質が上がるか？と
言われればケアレスミス防止程度だよなぁって思ってるんだよ。

だってローカルでしっかり手動でテスト（CIといって良いのか？）をやってるんだから

27 ：デフォルトの名無しさん：2018/02/19(月) 23:57:13.37 ID:anRYL6nk.net

>>26
手動でスクリプトを流してるうちはCIとは呼ばないよね
CIツール使わずにnpmやrakeだけでも自動で継続的にやってるなら
ローカル実行でもCIと言っていいと思うよ

現実的には個人開発かそれに近い場合以外は
サーバー実行にしないと著しく不便なだけで

28 ：デフォルトの名無しさん：2018/02/19(月) 23:59:47.39 ID:anRYL6nk.net

https://www.agilealliance.org/glossary/continuous-integration/
the practice of continuous integration should not be confused with the tools that assist it. Continuous integration is first and foremost a matter of attitude rather than tools, and it relies on more than one kind of tool.

https://martinfowler.com/articles/continuousIntegration.html
Although Continuous Integration is a practice that requires no particular tooling to deploy, we've found that it is useful to use a Continuous Integration server.

29 ：デフォルトの名無しさん：2018/02/20(火) 00:37:16.03 ID:wdwe47Ke.net

>>27
CIって結局テストのためだと思うんだよね。
なぜなら毎日デプロイしたりバイナリをリリースしたいか？って
言われるとそうなってないところが大半だと思うから。
毎日とまでは行かなくても短いスパンでリリースやビルドしたいなら
自動化する意味は感じられるけど、それが必要とされるところが少ない。


そしてテストに限った話をすると、上でも書いたけどCIツールを使った
テストって全体のテストを行うのがメインで修正した箇所を局所的に
テストすることはないと思う。局所的にテストしようと思ったらその設定を
作らないといけないから。そして全体のテストだから時間もかかる。

って考えるとローカルで開発しながらちょこちょこっとテストを実行すると思うんだよね。
この場合ローカルでの手動のテストのほうが効率が良い

そうなると個人のPCでは時間的に到底できないほど多くのテストが必要なんです。
プラットフォームやミドルウェアのバージョンが違っても全部テストやる必要があるんです。
みたいなマイナーなケースでしか「手動でのスクリプト実行」を超えるものは
必要にならないんじゃないかなと

なんだろ、ないよりはあったほうが良いけど、あっても多くの場合劇的な効果は
得られないよって言ったほうが良いのかな。俺がCIツール導入の話を聞くたびに
その前にテストコードちゃんと書いてローカルでいいからテストしろよって思うからかもしれない

30 ：デフォルトの名無しさん：2018/02/20(火) 01:30:16.83 ID:+H4kL9LD.net

>>29
一般的なCIの話をすると複数のコンポーネントをそれぞれのチームや個人が並行開発してて
それぞれの担当部分はローカルでテストしてからテストに通ったものだけCI用のリポジトリにpushする
んでCIサーバー側ですべてのコンポーネントを結合したものをビルドしてテストする
だからコンポーネント間で齟齬が生じたらすぐに検知できる

そういうインテグレーションが必要ない開発なら
CIをやることによるメリットも当然小さくなるよ

31 ：デフォルトの名無しさん：2018/02/20(火) 01:44:39.31 ID:wdwe47Ke.net

>>30
たしかに単体毎ではテストにとって
それぞれmasterにコンフリクト無しでマージできるけど
２つともマージしたらエラーになるってのは有るね。

これはローカルでそれぞれテストしていても見つけられないバグだ。
まあそういう事が発生した経験はないんだけど
モジュールが細かく別れていて、同じところを修正することが少ないからかな

32 ：デフォルトの名無しさん：2018/02/20(火) 06:43:14.06 ID:qL04aTa6.net

言ってることはわからなくもないけど、ここCIを啓蒙するスレなんだよな

33 ：片山博文MZ ：2018/03/01(木) 09:38:18.47 ID:JoXX949F.net

.travis.ymlやappveyor.yml の書き方、わからない人が居るようだから、指導してやってよ。

34 ：デフォルトの名無しさん：2018/05/23(水) 20:23:49.07 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

N20BU

35 ：デフォルトの名無しさん：2018/07/05(木) 01:22:00.19 ID:RfoszcD2.net

AQW