継続的インテグレーション (CI) を啓蒙するスレ ->画像>1枚

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それCIじゃねーよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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


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

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

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

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

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

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

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

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

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

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

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

N20BU

AQW