継続的インテグレーション (CI) を啓蒙するスレ
1デフォルトの名無しさん [sage]
AAS
2デフォルトの名無しさん [sage]
3片山博文MZ [sage]
4片山博文MZ [sage]
5片山博文MZ [sage]
6デフォルトの名無しさん [sage]
7デフォルトの名無しさん [sage]
8片山博文MZ [sage]
9デフォルトの名無しさん [sage]
10デフォルトの名無しさん [sage]
11デフォルトの名無しさん [sage]
12デフォルトの名無しさん [sage]
13デフォルトの名無しさん [sage]
14デフォルトの名無しさん [sage]
15デフォルトの名無しさん [sage]
16デフォルトの名無しさん [sage]
17デフォルトの名無しさん [sage]
18デフォルトの名無しさん [sage]
19デフォルトの名無しさん [sage]
20デフォルトの名無しさん [sage]
21デフォルトの名無しさん [sage]
22デフォルトの名無しさん
23デフォルトの名無しさん [sage]
24デフォルトの名無しさん [sage]
25デフォルトの名無しさん [sage]
26デフォルトの名無しさん [sage]
27デフォルトの名無しさん [sage]
28デフォルトの名無しさん [sage]
29デフォルトの名無しさん [sage]
30デフォルトの名無しさん [sage]
31デフォルトの名無しさん [sage]
32デフォルトの名無しさん [sage]
33片山博文MZ [sage]
34デフォルトの名無しさん
35デフォルトの名無しさん
36過去ログ ★
AAS
GitHubの普及で身近になってきた、Travis CIやAppVeyorなどのCIの便利さやテクニックなどについて、語りましょう。
2018/02/17(土)23:31:46.57(EwTJGG8P.net)
2デフォルトの名無しさん [sage]
あるならあるで良いんだが、効果は限定的だと考えるようになってきた。
なぜならCIで実行するものは何かというと通常テストの実行だが、
テストの実行というのはどちらにしろローカルでも行うから
「テストを実行するの忘れない」とか「みんなが見れる場所でテストが実行されている」
というメリットは有るのだが品質にはあまりつながらない気がする。
もちろんローカルでやるのが大変なものを、CIだと簡単にやれる
という状況であれば効果は高いのだが、ローカルでやるのが大変なものってなんだ？
それがCIで簡単にやれるためには相当ハイスペックなマシンが必要じゃないか？
みたいになる。
重要なのはCIで実行する「内容」であって、CIという手段ではないので、
あまり手段にこだわってもなぁという気がしている。
もちろんあるのとないのではあったほうが良いんだよ。でもアレば少しマシぐらいの感覚
なぜならCIで実行するものは何かというと通常テストの実行だが、
テストの実行というのはどちらにしろローカルでも行うから
「テストを実行するの忘れない」とか「みんなが見れる場所でテストが実行されている」
というメリットは有るのだが品質にはあまりつながらない気がする。
もちろんローカルでやるのが大変なものを、CIだと簡単にやれる
という状況であれば効果は高いのだが、ローカルでやるのが大変なものってなんだ？
それがCIで簡単にやれるためには相当ハイスペックなマシンが必要じゃないか？
みたいになる。
重要なのはCIで実行する「内容」であって、CIという手段ではないので、
あまり手段にこだわってもなぁという気がしている。
もちろんあるのとないのではあったほうが良いんだよ。でもアレば少しマシぐらいの感覚
2018/02/18(日)00:08:48.88(dp9S/ZRw.net)
3片山博文MZ [sage]
LinuxとiOSとWin、x86とx64でビルド&テスト&デプロイやれって言われて、普通、人間にやらせるか？ CIに任せるだろ。
2018/02/18(日)00:13:22.23(zL4UkFvD.net)
4片山博文MZ [sage]
CIは仮想化の力で複数の環境におけるビルド&テスト&デプロイをバッチ処理として、自動化する。
2018/02/18(日)00:17:59.59(zL4UkFvD.net)
5片山博文MZ [sage]
テスト要員を半分以下に。単純作業のテスターは要らない。
2018/02/18(日)00:29:11.34(zL4UkFvD.net)
6デフォルトの名無しさん [sage]
2018/02/18(日)02:17:46.61(ydkJE298.net)
7デフォルトの名無しさん [sage]
先に>>6に言われたなｗ
例えばgoはコマンド一つで複数のプラットフォーム用のバイナリを生成することができる
CIはビルド&テスト&デプロイをやってくれるものだと考えているかもしれないが、
別に自分のマシンからだってビルド&テスト&デプロイは行える
つまりCIの価値というのは、ビルド&テスト&デプロイそのものではなくて
ワークフローを統一化できるというところにある
それはそれで良いことなんだが、CIのメリットというのはワークフローの統一化だと思うと
思っているほど大したことしてないと思うだろ？
そしてもう一つは、テストマシンリソースのレンタル
テスト自体は自分のマシンでできる。だけど自分のマシンで追いつかないようなものは、
CIサーバーに頼んで借りられる。ただしCIサーバーのスペックが高いか、
クラスタでも組んでないと自分のマシンでやったほうが速いってことになりかねないｗ
ちなみに普段の開発中にはCIは利用しない。なぜならCIでは特定のメソッドだけテストの実行を行う
なんてことがやりづらく自分のマシンでテストを実行したほうが速いから。
CIによるテストは時間が掛かるテストをお行うもので、時間がかからないテストはローカルで済ませる
>>5
> テスト要員を半分以下に。単純作業のテスターは要らない。
それを実現するにはCIサーバーを導入しても実現できない。
単純作業（テスト）を行うためのテストコードが必要。
だがテストコードがあるなら、それは自分のマシンでも実行できる
例えばgoはコマンド一つで複数のプラットフォーム用のバイナリを生成することができる
CIはビルド&テスト&デプロイをやってくれるものだと考えているかもしれないが、
別に自分のマシンからだってビルド&テスト&デプロイは行える
つまりCIの価値というのは、ビルド&テスト&デプロイそのものではなくて
ワークフローを統一化できるというところにある
それはそれで良いことなんだが、CIのメリットというのはワークフローの統一化だと思うと
思っているほど大したことしてないと思うだろ？
そしてもう一つは、テストマシンリソースのレンタル
テスト自体は自分のマシンでできる。だけど自分のマシンで追いつかないようなものは、
CIサーバーに頼んで借りられる。ただしCIサーバーのスペックが高いか、
クラスタでも組んでないと自分のマシンでやったほうが速いってことになりかねないｗ
ちなみに普段の開発中にはCIは利用しない。なぜならCIでは特定のメソッドだけテストの実行を行う
なんてことがやりづらく自分のマシンでテストを実行したほうが速いから。
CIによるテストは時間が掛かるテストをお行うもので、時間がかからないテストはローカルで済ませる
>>5
> テスト要員を半分以下に。単純作業のテスターは要らない。
それを実現するにはCIサーバーを導入しても実現できない。
単純作業（テスト）を行うためのテストコードが必要。
だがテストコードがあるなら、それは自分のマシンでも実行できる
2018/02/18(日)02:48:20.51(dp9S/ZRw.net)
8片山博文MZ [sage]
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
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(日)06:10:30.39(1UUb2h0E.net)
9デフォルトの名無しさん [sage]
それCIじゃねーよ
2018/02/18(日)09:28:42.57(fvmxJoRp.net)
10デフォルトの名無しさん [sage]
自分のマシンでできない事はないけど、複数のOS上かつ複数のランタイムバージョンでテストを実行してついでにオーケーならデプロイまでしてくれるからなあ。
それをローカルでやるとなると必要な分だけの仮想環境を用意してさらにそれら環境全部の実行待ちの時間もバカにならんし、ぎゃくにローカルでやるメリットがあまり思い浮かばない
それをローカルでやるとなると必要な分だけの仮想環境を用意してさらにそれら環境全部の実行待ちの時間もバカにならんし、ぎゃくにローカルでやるメリットがあまり思い浮かばない
2018/02/18(日)18:08:34.16(zd+wqEcu.net)
11デフォルトの名無しさん [sage]
2018/02/18(日)18:38:31.65(F2O3xW/S.net)
12デフォルトの名無しさん [sage]
2018/02/18(日)19:30:06.94(zd+wqEcu.net)
13デフォルトの名無しさん [sage]
つかスレの流れを見てなかったけど、何でもかんでも猫も杓子もCI使えばいいってもんじゃねえって話なのね。
それなら完全に同意だわ。
それなら完全に同意だわ。
2018/02/18(日)19:38:21.45(zd+wqEcu.net)
14デフォルトの名無しさん [sage]
といってもCIを使うデメリットも特に思い当たらないから何となく使うのもいいとは思うけどな
2018/02/18(日)19:39:15.73(zd+wqEcu.net)
15デフォルトの名無しさん [sage]
微妙に噛み合わない会話が続いているのはCIツールのことをCIって呼んでるやつと
プラクティスの名前としてCIって言葉を使ってるやつとに分かれてるからだね
プラクティスの名前としてCIって言葉を使ってるやつとに分かれてるからだね
2018/02/18(日)20:13:05.44(ydkJE298.net)
16デフォルトの名無しさん [sage]
プラクティスとしてのCIなら自分のローカルマシンでやってても、上で書いてあるようなことをやってるならそれはCIだわな
2018/02/18(日)20:17:21.91(LfAicYVt.net)
17デフォルトの名無しさん [sage]
CIの肝はセントラルリポジトリに対してテストを行う時点で、自分のローカルとCI環境の最低二ヶ所の環境でパスすることを確認できる事なんだけどな。
ローカルだけでやってたら、環境依存の問題は絶対に見つけられんからあまりやる意味もない気がする。
ローカルだけでやってたら、環境依存の問題は絶対に見つけられんからあまりやる意味もない気がする。
2018/02/18(日)20:26:49.49(LfAicYVt.net)
18デフォルトの名無しさん [sage]
>>16
それはもう一段階詳細な相違点
プラクティスとしてのCIをローカルとは別のCIサーバーを使う前提で捉えてる人もいるってこと
>>17
ローカルでもVM使って複数環境のテストできるし
CIじゃなくてもビルドスクリプトでリモート環境を複数利用したテストもできる
結局それらを”自動で継続的に”実行するかどうか
それはもう一段階詳細な相違点
プラクティスとしてのCIをローカルとは別のCIサーバーを使う前提で捉えてる人もいるってこと
>>17
ローカルでもVM使って複数環境のテストできるし
CIじゃなくてもビルドスクリプトでリモート環境を複数利用したテストもできる
結局それらを”自動で継続的に”実行するかどうか
2018/02/18(日)22:55:00.28(ydkJE298.net)
19デフォルトの名無しさん [sage]
>>15
普通CIっていったらCIツールの導入じゃね？
俺が言いたいのは、テストコード無くて別に自動的にデプロイするわけでもないのに
CIツール入れても意味ないよね？って話
まずはテストコードは書くことが重要。
で書いてしまえば、ローカルでもできるじゃん？
ビルドとかデプロイとかコマンド一つでできるじゃん？
じゃあCIツール入れるメリットってなんだろう？って話
CIがテストやMakefile書きましょうレベルの話ならば
なんだ俺は普段からCIやっていたのかｗってことになる
もちろんそんなわけないので、テストやMakefileを書いている俺からすると
CIツールの導入で得られるメリットというのは、
MacのAutomatorのフォルダアクション（指定したフォルダにファイルが
追加された時に指定したコマンドを実行）レベルのものなんだってこと
もちろんそれがみんなに共有されるってことはわかるんだけど、
フォルダアクション＋情報共有がCIツールの本質なんだなぁって話
普通CIっていったらCIツールの導入じゃね？
俺が言いたいのは、テストコード無くて別に自動的にデプロイするわけでもないのに
CIツール入れても意味ないよね？って話
まずはテストコードは書くことが重要。
で書いてしまえば、ローカルでもできるじゃん？
ビルドとかデプロイとかコマンド一つでできるじゃん？
じゃあCIツール入れるメリットってなんだろう？って話
CIがテストやMakefile書きましょうレベルの話ならば
なんだ俺は普段からCIやっていたのかｗってことになる
もちろんそんなわけないので、テストやMakefileを書いている俺からすると
CIツールの導入で得られるメリットというのは、
MacのAutomatorのフォルダアクション（指定したフォルダにファイルが
追加された時に指定したコマンドを実行）レベルのものなんだってこと
もちろんそれがみんなに共有されるってことはわかるんだけど、
フォルダアクション＋情報共有がCIツールの本質なんだなぁって話
2018/02/18(日)23:13:32.08(F2O3xW/S.net)
20デフォルトの名無しさん [sage]
まあ要するにローカルでテストできる体制も整ってないのに
Travis使います。Jenkins使いましょう。といっても効果ないよってことだよ
まず最初にテストやMakefile相当のものを作る。
そしたらCIツール使える状態になるけど、
次は、あれ？CIツール使わなくても全部ローカルでできるじゃん？
ってなると思うよｗ
そこから先、CIツールを導入する目的が何かを自動化できるだと
理由として弱い。全部ローカルで出来てることだから
Travis使います。Jenkins使いましょう。といっても効果ないよってことだよ
まず最初にテストやMakefile相当のものを作る。
そしたらCIツール使える状態になるけど、
次は、あれ？CIツール使わなくても全部ローカルでできるじゃん？
ってなると思うよｗ
そこから先、CIツールを導入する目的が何かを自動化できるだと
理由として弱い。全部ローカルで出来てることだから
2018/02/18(日)23:21:49.77(F2O3xW/S.net)
21デフォルトの名無しさん [sage]
絵に描いたような逆張り野郎だな
2018/02/19(月)07:18:39.86(YvDQTksi.net)
22デフォルトの名無しさん
>>18
君の言っていることは「メモ帳があれば高機能なエディタもIDEも不要」というのと同じくらいの暴論だよ
君の言っていることは「メモ帳があれば高機能なエディタもIDEも不要」というのと同じくらいの暴論だよ
2018/02/19(月)08:23:59.56(YvDQTksi.net)
23デフォルトの名無しさん [sage]
2018/02/19(月)20:36:46.45(anRYL6nk.net)
24デフォルトの名無しさん [sage]
2018/02/19(月)20:39:13.91(anRYL6nk.net)
25デフォルトの名無しさん [sage]
ローカルでやるからツールはいらないってか
なんというか、頑張ってくれとしか言いようがないw
なんというか、頑張ってくれとしか言いようがないw
2018/02/19(月)22:28:28.96(bxmPXsfI.net)
26デフォルトの名無しさん [sage]
>>23 >>25
違う違う。ローカルでやるから〜じゃなくて
逆にローカルでもリモートでも同じだって言いたい
みんなCIをリモートで専用のCIツール使ってやろうとするけど、
同じことをCIツール使わずにmakeとかnpmとかrakeとか
そういった言語用のツールでビルドやテスト実行してるでしょ？
もちろん必要と思われる任意のタイミングで手動で実行してるんだけど。
ローカルで手動でこれらの作業をやってるだけじゃ、
CIと言わないと思うんだけど、CIツールで行うとされてる
作業の全てはローカルで実行できるわけさ。
（自動的に実行もgitのフックを使えばできる）
そうするとこのローカルでやってる作業・・・がCIからみて足りないものは、
自動化されて忘れない。みんなと情報共有できる。という点で
もちろんこれはチーム開発では重要なことなんだけど、品質が上がるか？と
言われればケアレスミス防止程度だよなぁって思ってるんだよ。
だってローカルでしっかり手動でテスト（CIといって良いのか？）をやってるんだから
違う違う。ローカルでやるから〜じゃなくて
逆にローカルでもリモートでも同じだって言いたい
みんなCIをリモートで専用のCIツール使ってやろうとするけど、
同じことをCIツール使わずにmakeとかnpmとかrakeとか
そういった言語用のツールでビルドやテスト実行してるでしょ？
もちろん必要と思われる任意のタイミングで手動で実行してるんだけど。
ローカルで手動でこれらの作業をやってるだけじゃ、
CIと言わないと思うんだけど、CIツールで行うとされてる
作業の全てはローカルで実行できるわけさ。
（自動的に実行もgitのフックを使えばできる）
そうするとこのローカルでやってる作業・・・がCIからみて足りないものは、
自動化されて忘れない。みんなと情報共有できる。という点で
もちろんこれはチーム開発では重要なことなんだけど、品質が上がるか？と
言われればケアレスミス防止程度だよなぁって思ってるんだよ。
だってローカルでしっかり手動でテスト（CIといって良いのか？）をやってるんだから
2018/02/19(月)23:20:16.94(uhfYTKrf.net)
27デフォルトの名無しさん [sage]
>>26
手動でスクリプトを流してるうちはCIとは呼ばないよね
CIツール使わずにnpmやrakeだけでも自動で継続的にやってるなら
ローカル実行でもCIと言っていいと思うよ
現実的には個人開発かそれに近い場合以外は
サーバー実行にしないと著しく不便なだけで
手動でスクリプトを流してるうちはCIとは呼ばないよね
CIツール使わずにnpmやrakeだけでも自動で継続的にやってるなら
ローカル実行でもCIと言っていいと思うよ
現実的には個人開発かそれに近い場合以外は
サーバー実行にしないと著しく不便なだけで
2018/02/19(月)23:57:13.37(anRYL6nk.net)
28デフォルトの名無しさん [sage]
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.
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.
2018/02/19(月)23:59:47.39(anRYL6nk.net)
29デフォルトの名無しさん [sage]
>>27
CIって結局テストのためだと思うんだよね。
なぜなら毎日デプロイしたりバイナリをリリースしたいか？って
言われるとそうなってないところが大半だと思うから。
毎日とまでは行かなくても短いスパンでリリースやビルドしたいなら
自動化する意味は感じられるけど、それが必要とされるところが少ない。
そしてテストに限った話をすると、上でも書いたけどCIツールを使った
テストって全体のテストを行うのがメインで修正した箇所を局所的に
テストすることはないと思う。局所的にテストしようと思ったらその設定を
作らないといけないから。そして全体のテストだから時間もかかる。
って考えるとローカルで開発しながらちょこちょこっとテストを実行すると思うんだよね。
この場合ローカルでの手動のテストのほうが効率が良い
そうなると個人のPCでは時間的に到底できないほど多くのテストが必要なんです。
プラットフォームやミドルウェアのバージョンが違っても全部テストやる必要があるんです。
みたいなマイナーなケースでしか「手動でのスクリプト実行」を超えるものは
必要にならないんじゃないかなと
なんだろ、ないよりはあったほうが良いけど、あっても多くの場合劇的な効果は
得られないよって言ったほうが良いのかな。俺がCIツール導入の話を聞くたびに
その前にテストコードちゃんと書いてローカルでいいからテストしろよって思うからかもしれない
CIって結局テストのためだと思うんだよね。
なぜなら毎日デプロイしたりバイナリをリリースしたいか？って
言われるとそうなってないところが大半だと思うから。
毎日とまでは行かなくても短いスパンでリリースやビルドしたいなら
自動化する意味は感じられるけど、それが必要とされるところが少ない。
そしてテストに限った話をすると、上でも書いたけどCIツールを使った
テストって全体のテストを行うのがメインで修正した箇所を局所的に
テストすることはないと思う。局所的にテストしようと思ったらその設定を
作らないといけないから。そして全体のテストだから時間もかかる。
って考えるとローカルで開発しながらちょこちょこっとテストを実行すると思うんだよね。
この場合ローカルでの手動のテストのほうが効率が良い
そうなると個人のPCでは時間的に到底できないほど多くのテストが必要なんです。
プラットフォームやミドルウェアのバージョンが違っても全部テストやる必要があるんです。
みたいなマイナーなケースでしか「手動でのスクリプト実行」を超えるものは
必要にならないんじゃないかなと
なんだろ、ないよりはあったほうが良いけど、あっても多くの場合劇的な効果は
得られないよって言ったほうが良いのかな。俺がCIツール導入の話を聞くたびに
その前にテストコードちゃんと書いてローカルでいいからテストしろよって思うからかもしれない
2018/02/20(火)00:37:16.03(wdwe47Ke.net)
30デフォルトの名無しさん [sage]
>>29
一般的なCIの話をすると複数のコンポーネントをそれぞれのチームや個人が並行開発してて
それぞれの担当部分はローカルでテストしてからテストに通ったものだけCI用のリポジトリにpushする
んでCIサーバー側ですべてのコンポーネントを結合したものをビルドしてテストする
だからコンポーネント間で齟齬が生じたらすぐに検知できる
そういうインテグレーションが必要ない開発なら
CIをやることによるメリットも当然小さくなるよ
一般的なCIの話をすると複数のコンポーネントをそれぞれのチームや個人が並行開発してて
それぞれの担当部分はローカルでテストしてからテストに通ったものだけCI用のリポジトリにpushする
んでCIサーバー側ですべてのコンポーネントを結合したものをビルドしてテストする
だからコンポーネント間で齟齬が生じたらすぐに検知できる
そういうインテグレーションが必要ない開発なら
CIをやることによるメリットも当然小さくなるよ
2018/02/20(火)01:30:16.83(+H4kL9LD.net)
31デフォルトの名無しさん [sage]
>>30
たしかに単体毎ではテストにとって
それぞれmasterにコンフリクト無しでマージできるけど
２つともマージしたらエラーになるってのは有るね。
これはローカルでそれぞれテストしていても見つけられないバグだ。
まあそういう事が発生した経験はないんだけど
モジュールが細かく別れていて、同じところを修正することが少ないからかな
たしかに単体毎ではテストにとって
それぞれmasterにコンフリクト無しでマージできるけど
２つともマージしたらエラーになるってのは有るね。
これはローカルでそれぞれテストしていても見つけられないバグだ。
まあそういう事が発生した経験はないんだけど
モジュールが細かく別れていて、同じところを修正することが少ないからかな
2018/02/20(火)01:44:39.31(wdwe47Ke.net)
32デフォルトの名無しさん [sage]
言ってることはわからなくもないけど、ここCIを啓蒙するスレなんだよな
2018/02/20(火)06:43:14.06(qL04aTa6.net)
33片山博文MZ [sage]
.travis.ymlやappveyor.yml の書き方、わからない人が居るようだから、指導してやってよ。
2018/03/01(木)09:38:18.47(JoXX949F.net)
34デフォルトの名無しさん
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
N20BU
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
N20BU
2018/05/23(水)20:23:49.07(Au5e7VGg.net)
35デフォルトの名無しさん
AQW
2018/07/05(木)01:22:00.19(RfoszcD2.net)
36過去ログ ★
■ このスレッドは過去ログ倉庫に格納されています
[過去ログ]