プログラマーの継続的インテグレーションと開始点

Roscosmosで、彼らは設計図やロケットの配置方法を明確に理解することなく、新しいロケットを建設することを決めたと想像してください。 別のプラントでロケット本体を扱い、別のプラントでエンジンを製造し、別のノズルで処理します。 Roscosmosのチーフマネージャーは、彼が専門家を信頼していると言い、すべての作業を専門的にプラントに委任しました。







1年後、すべてのコンポーネントがメインアセンブリショップに配送され、エンジンが車体に入らず、テストエンジンの始動中でもノズルが溶け始めることがわかりました。



そのようなゴミの発生を防ぐために、実際のプロジェクトには常に計画と設計の段階があり、部品の相互作用の仕様と、それらが持つべき特性が固定されています。



ソフトウェアを開発するとき、長い設計段階を行う余裕はありません。なぜなら、 この間、私たちが開発しようとしているもののビジネス価値は失われます-私たちは競合他社に愚かに打ちのめされます。



そのため、プログラムコンポーネント（モジュール）を開発するチームは、モジュールが他の部分とどのように相互作用するかを完全に理解せずに作業を余儀なくされることがよくあります。



ロケットの場合のように、複数のチームによって部分的に開発されたアプリケーションの新しいリリースをリリースしようとすると、一部のモジュールに互換性がないことが判明する場合があります。



1991年、 Grady Butchは明らかにこのような不名誉にうんざりしていたため、プロジェクト全体を毎日組み立てて、リリース日ではなく以前の非互換性を見つけることを提案し、このアプローチを継続的インテグレーションと呼びました。



確かに、プログラムをコンパイルすることは、ロケットを構築するよりも簡単です（特に未完成のコンポーネントから）。1日に1回それを始めてみませんか？ エクストリームプログラミングでは、このトピックを悪化させ、1日に数回アセンブリを配置することにしました。

アセンブリとは何ですか？

たとえば、モジュールを1か所にコピーして、プログラムのコンパイルを開始する必要があります。

すべてがうまくいった場合、アセンブリは成功したと見なすことができ、そうでない場合、チームは詳細を整理し、すべてが行き過ぎになるまで問題を解決する機会があります。



PHP、Python、Rubyなどのインタープリター言語でコンパイルするものはありません。 それらのアセンブリは、単体テストの開始、テストサーバーへのWebアプリケーションの展開、およびこのテストサーバーでの受け入れテストの実行です。



したがって、継続的インテグレーションは実践です。 このプラクティスの目的は、統合fakapsの数を減らし、生成されるソフトウェアの品質を向上させることです。 この方法は、プロジェクトのアセンブリを1日に数回起動することです。



古くからGrad Butchは一般的に手作業でCIを練習し始め、会社の部署を駆け回って、全員に最新バージョンのモジュールをフロッピーディスクに入れさせ、その後言語ですべて手動でコンパイルできるようにしました:)



2018年には、CIのプロセスがシステムの山で自動化されているので、もう少し簡単になりました。好みに合わせていずれかを選択してください。

CIシステムについて

たくさんあります 。 彼らは違います。 特定のプログラミング言語に特化しています。 IDE用に開発されたモバイルアプリケーション、ビルトインIDE、GUIを介した設定、リポジトリ内の構成ファイルを介した設定があります。 一部はクラウドでのみ動作し、一部はサーバーにインストールできます。



それらをすべてカバーするつもりはありません。 Webアプリケーションである最新の汎用システムのみを取り上げましょう。



最新の開発は、バージョン管理システムを使用していることを意味します。

バージョン管理はほとんどの場合gitです。

Gitはほとんどの場合GitHubまたは同様のサービスです。

モダンなデザインのベストプラクティス-機能ブランチとプルリクエスト。



CIはpullrequestのストーリーに完全に適合します。



すべての変更が表示されるだけでなく、特定の機能の開発について1か所で話し合うだけでなく、対応するCIアセンブリのステータスがすぐに表示されます。





（ここでアセンブリが失敗しました-詳細に移動し、どこで壊れたかを見つけて修復する必要があります）



それを修正し、コミットし、開始し、プロセスが新しいものを開始します-CIシステムはブランチ上の新しい変更を検出し、新しいアセンブリを開始します。







アセンブリはいくつかの段階で構成されます。 最も典型的なのは、テスト、コンパイル、展開です。



当然、CIシステムはこれらのステップが何であるかを説明する必要があります。

CIシステムの構成

CIシステムの指示がプロジェクトのリポジトリ内の別のファイルである場合、すべての正しいCIシステムはコードとしての構成の原則に従います。 そのため、ほとんどのシステムでは、命令でYAML形式が使用されています。



GitLab CIの最も単純な指示ファイルは次のようになります。

test_job: script: - ls -l
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し複雑な指示（Circle CI）：

 version: 2 jobs: test: docker: - image: circleci/ruby:2.4-node steps: - checkout - run: rspec deploy: docker: - image: circleci/ruby:2.4-node steps: - checkout - run: cap deploy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここでこれらすべての指示はどこかで起動されるべきであることを思い出します。

内部のCIシステムの内容

リポジトリへのプッシュごとに、CIシステムは、内部で指示を起動し、作業の結果を取得し、マシンを消滅させる仮想マシンを作成します。







アセンブリに対する外部要因の影響を制限するために、クリーンなシステムが必要になるたびに。



一部のCIシステムはこれにdockerを使用しますが、一部のCIシステムはそれなしで出ます。 ヒント：Dockerを使用してください;）



（実際には、すべてがやや複雑であり、ほとんどのCIシステムはさまざまなモードで動作しますが、デフォルトモードから開始する方がよいでしょう。ドッカーコンテナー内でタスクを開始するだけです）

なぜこれが普通の開発者にとってすべてなのでしょうか？

1. クローズできる開発の側面が多いほど、価値が高くなります。 コードを作成して開始し、草が成長しなくても、これは1つのことです。 テストとアプリケーションの展開を同時に行うと、まったく異なります。 CIでこれをすべて自動化した場合-3番目:)
2. 時間がたてば、CIはバージョン管理と同じデフォルトになることを理解してください。

練習からいくつかの状況を説明します。 次のいずれかにアクセスした可能性があります。

状況番号1

2人の開発者が異なるブランチで開発します。 それらの各テストは、マスターとのマージ後を含め、正常に合格します。



しかし、両方のブランチがマスターにマージされるとすぐに、テストは失敗し始めます。 問題は、CIがなければ、そのようなコードは簡単に本番環境に入り、エラーの存在はそこだけで発見されることです。

状況番号2

15人のチームがWebアプリケーションを開発しています。 ヴァシリーは鼻に家族の休日を持っています。 彼は当局に早めに出て行って、コードをあまり注意深くチェックせず、コマンドラインでデプロイを開始し、コンピューターをシャットダウンし、同時に電話を切断して仕事を辞めました-家族は仕事よりも重要です！



その結果、生産が中断し、展開ログがロックされたコンピューターに残り、残りの開発者は、何が辱され、展開プロセスで何が間違っていたのか、誰が責任を負うのかを理解しようとして髪を引き裂きました。



チームがCIシステムを使用している場合、すべての展開ログ（およびその他のタスク）がCIシステムに保存されるため、何が問題であったかを常に確認できます。

どのCIシステムから始めますか？

Githubは良い手がかりを与えてくれます：







GitHubのオープンソースプロジェクトは、ほとんどの場合Travis CIでテストを実行します。 あなたはそれに直面することはできません。 わかりました、Travis CIをメモしますが、Googleを実行して実行するまでマニュアルを読みます。



The Forrester Waveによる継続的統合ツールに関する最近の調査結果を見てみましょう。







一言で言えば、CIシステムの現在の機能、開発の可能性、現在の市場規模を調べました。

テスト方法論に興味がある人は、研究自体を読んでください。 結論に興味があります。



リーダーは次のとおりです。



4） CloudBeesはJenkinsの背後にある会社です。 これは最も古いオープンソースCIシステムの1つであり、それらが先頭に立たないのは奇妙です。



3）すでに2番目のソースにあるサークルCIがリードしていました。 また、注意が必要です。



2） Microsoft-コメントなし。 大きな影響力を持つ巨大企業。 Windows用のソフトウェアを開発している場合、ほとんどの場合、選択肢さえありません。 会社がTFSとそのCIシステムを備えたMicrosoftの開発ツールスタックのライセンスを購入した場合、実際に見回すのではなく、彼らが提供するものだけを手にする



1） GitLabが最初に登場します。 過去数年間会社をフォローしていない人にとって、これは完全な驚きとして来るかもしれません。 それについてもっと詳しく話しましょう。

Gitlab

^{著者はGitlabで1年間、Developer Advocateとして働いていたので、次の段落を読むとき、あなたは私が偏見を持ち、懐疑主義のノブを数十パーセント緩めることを考えるすべての権利を持っています。 それでも、Gitlabについて多くのことを知る必要があると思います。}



Gitlabがそれ自体を単にGithubのクローンと見なすことを拒否したことが重要であり、会社はGitlabを開発者向けの「ワンストップシステム」に向けて開発することを決定しました。 GitlabはすでにリストのGithub、Trello、CIシステムなどに置き換えることができます。 すべてのツールはすでに構成されており、互いに統合されています。 開発者にとっての結果は、設定に関する最小限の騒ぎです。



Gitlabのソースコードは公開されており、必要に応じて自分のサーバーで無料で使用できます。 しかし、私たちはこのストーリーで、クラウドバージョン-GitLab.comとそれがもたらす可能性に最も興味を持っています。

• プライベートプロジェクトを無制限にホストする
• ビルトインCIを無料で使用する場合、1か月あたり2000ビルド分

景品、ええ。 まあ、結果として、個人的なプロジェクトに使用して、学ぶ機会。



要するに、あなたは私の個人的な推奨事項がGitLab CIであるとすでに推測しました。 Gitlabには、将来的に次の大きなものになる可能性がすべてあります。 そして、突然ファッショナブルなものになる経験豊富なスペシャリストになることは、人気のスペシャリストになることです;）



githubを離れる準備ができていない場合は、 Circle CIまたはTravis CIを試してください。



CIを理解する初期段階では、 JenkinsとTeamCityを避けてください 。 これらの旧式のシステムにはオーバーヘッドが多すぎるため、CI自体よりもシステムの機能を多く扱う必要があります。



あなたはジェンキンスがCIだと考え始めます、そして、これは愚かです。 可能性のある例外は、あなたがジャビスト、ロックマン、またはコトリニストであり、そこですべてが箱から出して動作することです。



Windowsでプログラムするためにあなたの種類に書かれている場合、あなたは間違いなくMicrosoftスタックを追い越しませんが、私は自分の自由意志でそれを使用しません。



では、先に進みましょう...

開始するタスク

良いニュースは、すぐにCIの専門家になる必要がないことです。 手始めに、単純な「被写体にいる」だけで十分です。 軽いものから始めましょう：

1. たとえば、マスターにプッシュするときに個人用サイトを展開する方法を学びます。
2. 個人用Webサイトのテキスト用にyaspellerでスペルチェックを埋め込む
3. マイナーワーキングドラフトのCIでいくつかのリンターを起動します。

CI内での最初のビルドの起動は2分間のタスクです。 有用なものを開始するには、もう少し時間を費やす必要があります。 スクリプトの作業環境をセットアップする必要があります。



ここでは、これについて詳しく説明しません。 興味のある方のために-記事の最後にあるリンク。



それまでの間、大規模なプロジェクトでCIがどのように使用されているか、そしてそれがあなたに与える力を見てみましょう。

大規模プロジェクトでCIを提供するもの

大規模なプロジェクト-深刻な要件。 ここでは、1つまたは2つのチームの立ち上げだけを行うことはできません。 このようなロジックは簡単に想像できます。1）特定のブランチにコミットする場合にのみタスクを完了する、2）次のタスクを正常に完了する、3）特定のタスクを実行するときにエラーを無視する、4）ハンドヘルド信号がすべてを完了するのを待つ



私のお気に入りの例はGitLab自体です。







作業は常に本格的であり、CIの動作をリアルタイムで確認できます： https : //gitlab.com/gitlab-org/gitlab-ce/pipelines



これは大きなプロジェクトであり、事前の準備なしにCI-configを監視することはお勧めしません。



代わりに、CIタスクチェーンの視覚化を見てください。







https://gitlab.com/gitlab-org/gitlab-ce/pipelines/20201164



1）これは、すべてのCIシステムに決してありません。 それがどこにある-それはチームにCIで何が起こっているかを視覚的に表現し、それは価値があると思います。



2）さらに、CIシステム設定ファイルは、コマンドの継続的インテグレーションプロセスの作業用ドキュメントになります。 開発者は、目的の変更を含むプルリクエストを作成することで、そこに何かを追加または変更できます。



3）最後に、CIシステムは、展開またはテスト実行中にどこで何が問題になったかを確認できる中心的な場所になります。



開発プロセスの高速化、信頼性の向上、およびリスクの削減について、これらすべての伝統的な何とか何とかをあなたの好みに加えてください。

さらに掘る場所

（もう少し深く勉強したい場合）



1）GitLab CIを使用してS3およびHerokuでデプロイを実行する方法の例を含むスクリーンキャストをご覧ください。



2） GitLab CIの概要と展開ガイドをお読みください 。



3） ドキュメントをスモークします 。



4）1つのCIシステムに慣れたら、有望なCIシステムから他のシステムを選択して遊んで、原則がどこにでも共通していることを確認し、自信を高めます。