プロホスト > ブログ > 行政 > 継続的インテグレーションの一般的な状況

継続的インテグレーションの一般的な状況

Git コマンドを学習しましたが、継続的インテグレーション (CI) が実際にどのように機能するかを想像したいと思ったことはありますか? それとも、毎日の活動を最適化したいですか? このコースでは、GitHub リポジトリを使用した継続的インテグレーションの実践的なスキルを習得します。 このコースは、単にクリックするだけで実行できるウィザードを目的としたものではなく、実際に人々が仕事で行うのと同じ操作を、同じ方法で実行します。 関連する手順を実行しながら理論を説明します。

私たちは何をしますか？

作業が進むにつれて、典型的な CI ステップのリストを徐々に作成していきます。これは、このリストを覚えておくのに最適な方法です。 言い換えれば、継続的インテグレーションを行う際に開発者が実行するアクションのリストを作成します。 また、CI プロセスを実際のプロセスに近づけるために、単純なテストのセットも使用します。

この GIF は、コースの進行に伴うリポジトリ内のコミットを模式的に示しています。 ご覧のとおり、ここでは複雑なことは何もなく、最も必要なものだけです。

継続的インテグレーションの一般的な状況

次の標準的な CI シナリオを実行します。

  • 機能に取り組みます。
  • 品質を保証するための自動テストの適用。
  • 優先タスクの実装。
  • ブランチをマージするときの競合解決 (マージ競合)。
  • 本番環境ではエラーが発生します。

何を学びますか？

次の質問に答えることができます。

  • 継続的インテグレーション (CI) とは何ですか?
  • CI ではどのようなタイプの自動テストが使用され、どのようなアクションに応じてテストがトリガーされますか?
  • プル リクエストとは何ですか?いつ必要になりますか?
  • テスト駆動開発 (TDD) とは何ですか?また、それは CI とどのように関係しますか?
  • 変更をマージまたはリベースする必要がありますか?
  • ロールバックするか、次のバージョンで修正しますか?

当初は「プルリクエスト」などを随所に訳していましたが、結果的に文章の狂気度を減らすために所々英語のフレーズに戻すことにしました。 私は、人々が実際に仕事で使用する素晴らしい動詞「commit」のように、「programmer surzhik」を時々使用します。

継続的インテグレーションとは何ですか?

継続的インテグレーション、または CI は、各チーム メンバーが自分のコードを少なくとも XNUMX 日に XNUMX 回共通のリポジトリに統合する技術的な実践であり、結果として得られるコードは少なくともエラーなくビルドされなければなりません。

この用語については意見の相違があります

論点は統合の頻度です。 コードを XNUMX 日に XNUMX 回だけマージするだけでは、実際に継続的に統合するには十分ではないと主張する人もいます。 チームの例として、朝に全員が新しいコードを取得し、夕方に一度統合するというものがあります。 これはもっともな反論ですが、XNUMX 日 XNUMX 回の定義はかなり実用的で具体的であり、さまざまな規模のチームに適していると一般に考えられています。

もう XNUMX つの反対意見は、C++ が開発で使用される唯一の言語ではなくなり、検証方法として単にエラーのないアセンブリを要求するだけでは弱いということです。 一部のテスト セット (ローカルで実行される単体テストなど) も正常に完了する必要があります。 現時点では、コミュニティはこれを要件にする方向で動いており、まだではないにしても、将来的にはおそらく「ビルド + 単体テスト」が一般的な慣行になるでしょう。

継続的インテグレーション とは違う 継続的デリバリー (継続的デリバリー、CD) 各統合サイクル後にリリース候補を必要としないという点で。

コース全体で使用するステップのリスト

  1. 最新のコードを取り込みます。 からブランチを作成します master。 働き始める。
  2. 新しいブランチにコミットを作成します。 ローカルでビルドしてテストします。 合格？ 次のステップに進みます。 失敗？ エラーまたはテストを修正して、再試行してください。
  3. リモート リポジトリまたはリモート ブランチにプッシュします。
  4. プルリクエストを作成します。 変更について話し合い、議論が続くにつれてさらにコミットを追加します。 機能ブランチでテストを通過させます。
  5. マスターからのコミットをマージ/リベースします。 マージ結果をテストに渡すようにします。
  6. 機能ブランチから実稼働環境にデプロイします。
  7. 一定期間実稼働環境ですべてが良好な場合は、変更をマスターにマージします。

継続的インテグレーションの一般的な状況

️準備

適切なソフトウェアがあることを確認してください

このコースを受講するには、次のものが必要です Node.js и Gitクライアント.

任意の Git クライアントを使用できますが、ここではコマンド ラインのコマンドのみを提供します。

コマンドラインをサポートする Git クライアントがインストールされていることを確認してください

コマンドラインをサポートする Git クライアントをまだお持ちでない場合は、インストール手順をご覧ください。 ここで.

リポジトリを準備する

個人用コピー (フォーク) を作成する必要があります。 コースのコードを含むテンプレート リポジトリ GitHub 上で。 これを個人的なコピーと呼ぶことに同意しましょう コースリポジトリ.

終わり？ デフォルト設定を変更していない場合、コース リポジトリはおそらく次のように呼ばれます。 continuous-integration-team-scenarios-students、GitHub アカウント内にあり、URL は次のようになります。 

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

このアドレスに電話するだけです <URL репозитория>.

山括弧のようなもの <тут> は、そのような式を適切な値に置き換える必要があることを意味します。

それを確認してください GitHub のアクション このコース リポジトリに含まれています。 有効になっていない場合は、ページの中央にある大きなボタンをクリックして有効にしてください。このボタンには、GitHub インターフェイスの [アクション] をクリックするとアクセスできます。

GitHub Actions が有効になっていない場合、私の指示に従ってコースを完了することはできません。

継続的インテグレーションの一般的な状況

GitHub の Markdown レンダリング機能をいつでも使用して、ここで作成しているリストの現在の状態を確認できます。

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

回答について

このコースを完了する最善の方法は自分で行うことですが、いくつかの困難があるかもしれません。

何をすべきか理解できず、続行できないと感じた場合は、スレッドを参照してください。 solution、これは開始リポジトリにあります。
合併しないでください solution в master コースの最中。 このブランチを使用して、Git が提供するすべての機能を使用して、何をすべきかを判断したり、コードを作成者のコードと比較したりできます。 完全に迷った場合は、ブランチを完全に置き換えることができます master 枝の上で solution 次に、作業ディレクトリを必要なコースステップにリセットします。

本当に必要な場合にのみこれを使用してください

コードをコミットする

git add .
git commit -m "Backing up my work"

これらのコマンド

  • 名前を変更する master в master-backup;
  • 名前を変更する solution в master;
  • 新しいブランチにチェックアウトする master そして作業ディレクトリの内容を書き換えます。
  • 将来「ソリューション」ブランチが必要になった場合に備えて、「マスター」(以前は「ソリューション」でした) から「ソリューション」ブランチを作成します。

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

これらの手順の後、使用できるようになります git log master どのコミットが必要かを判断します。
次のように作業ディレクトリをこのコミットにリセットできます。 

git reset --hard <the SHA you need>

結果に満足した場合は、ある時点でリポジトリのバージョンをリモート リポジトリに公開する必要があります。 これを行うときは、リモート ブランチを明示的に指定することを忘れないでください。 

git push --force origin master

ご了承ください。 git push --force。 これを頻繁に行うことは考えにくいですが、ここでは、自分が何をしているのかを理解している XNUMX 人のリポジトリ ユーザーを対象とした非常に具体的なシナリオを考えます。

働き始める

継続的インテグレーションの一般的な状況

CI ステップのリストのコンパイルを開始しましょう。 通常、リモート リポジトリから最新バージョンのコードをチェックアウトしてこのステップを開始しますが、ここではまだローカル リポジトリがないため、代わりにリモート リポジトリからクローンを作成します。

️ タスク: ローカル リポジトリを更新し、からブランチを作成します master、 働き始める

  1. からコース リポジトリのクローンを作成します <URL репозитория>.
  2. 走る npm install コースリポジトリディレクトリ内。 これは、テストの実行に使用する Jest をインストールするために必要です。
  3. ブランチを作成して名前を付ける feature。 このスレッドに切り替えてください。

  4. テストコードを追加する ci.test.js これをするように求めるコメントの間に。

    it('1. pull latest code', () => {
  expect(/.*pull.*/ig.test(fileContents)).toBe(true);
});

it('2. add commits', () => {
  expect(/.*commit.*/ig.test(fileContents)).toBe(true);
});

it('3. push to the remote branch with the same name', () => {
  expect(/.*push.*/ig.test(fileContents)).toBe(true);
});

it('4. create a pull request and continue working', () => {
  expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
});

  5. 最初の 4 つのステップを含むテキストをファイルに追加します ci.md. 
    1. Pull in the latest code. Create a branch from `master`. Start working.    
2. Create commits on your new branch. Build and test locally.  
Pass? Go to the next step. Fail? Fix errors or tests and try again.  
3. Push to your remote repository or remote branch.  
4. Create a pull request. Discuss the changes, add more commits  
as discussion continues. Make tests pass on the feature branch.

    チーム

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

新しいブランチにコミットを作成し、ローカルでビルドしてテストする

コミットする前に実行するテストを設定し、コードをコミットします。

テストが自動的に実行される場合の一般的なシナリオ

  • ローカル：
    • 継続的に、または適切なコード変更に応じて。
    • 保存時 (インタープリタ言語または JIT コンパイル言語の場合)。
    • アセンブリ中 (コンパイルが必要な場合)。
    • コミット時。
    • 共有リポジトリに公開する場合。

  • ビルドサーバーまたはビルド環境上で:
    • コードが個人のブランチ/リポジトリに公開される場合。
    • このスレッドのコードはテスト中です。
    • 合併の潜在的な結果がテストされます（通常は master).
    • 継続的インテグレーションステージ/継続的デリバリーパイプラインとして

通常、テスト スイートの実行が速くなると、テスト スイートをより頻繁に実行できるようになります。 典型的なステージ分布は次のようになります。

  • 高速単体テスト - ビルド中、CI パイプライン内
  • 単体テストは遅く、コンポーネントおよび統合テストは高速 - コミット時、CI パイプラインで
  • 遅いコンポーネントおよび統合テスト - CI パイプライン内
  • セキュリティ テスト、負荷テスト、およびその他の時間のかかる、または高価なテスト - CI/CD パイプライン内ですが、ビルドの特定のモード/ステージ/パイプラインでのみ (リリース候補の準備時や手動で実行する場合など)。

️タスク

最初にコマンドを使用して手動でテストを実行することをお勧めします npm test。 その後、コミット時にテストを実行するための git フックを追加しましょう。 問題が XNUMX つあります。Git フックはリポジトリの一部とみなされないため、残りのコース教材と一緒に GitHub から複製することはできません。 フックをインストールするには、次を実行する必要があります install_hook.sh またはファイルをコピーする repo/hooks/pre-commit ローカルディレクトリへ .git/hooks/.
コミットすると、テストが実行され、特定のキーワードがリストに存在するかどうかがチェックされることがわかります。

  1. コマンドを実行してテストを手動で実行します npm test コースリポジトリフォルダーにあります。 テストが完了したことを確認します。
  2. 次のコマンドを実行して、コミットフック (コミット前フック) を設定します。 install_hook.sh.
  3. 変更をローカル リポジトリにコミットします。
  4. コミットする前にテストが実行されていることを確認してください。

これらの手順を実行すると、リポジトリは次のようになります。
継続的インテグレーションの一般的な状況

チーム

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.

コードをリモート リポジトリまたはリモート ブランチに公開する

ローカルでの作業が完了すると、開発者は通常、コードを公開して、最終的に一般公開と統合できるようにします。 GitHub の場合、これは通常、リポジトリの個人用コピー (個人用フォーク) または個人用ブランチに作業を公開することによって実現されます。

  • フォークを使用すると、開発者はリモート共有リポジトリのクローンを作成し、その個人用リモート コピー (フォークとも呼ばれます) を作成します。 次に、この個人リポジトリのクローンを作成して、ローカルで操作します。 作業が完了してコミットが行われると、それを自分のフォークにプッシュします。そこで他の人が利用できるようになり、共通リポジトリに統合できます。 このアプローチは、GitHub 上のオープンソース プロジェクトで一般的に使用されます。 私の上級コース [Git を使用したチームワークと CI] でも使用されています (http://devops.redpill.solutions/).
  • もう XNUMX つのアプローチは、リモート リポジトリを XNUMX つだけ使用し、ブランチのみをカウントすることです。 master 共有リポジトリは「保護」されています。 このシナリオでは、個々の開発者が自分のコードをリモート リポジトリのブランチに公開し、他の開発者がこのコードを参照できるようにします。すべてが正常であれば、それをマージします。 master 共有リポジトリ。

この特定のコースでは、ブランチを使用するワークフローを使用します。

コードを公開しましょう。

️タスク

  • 作業ブランチと同じ名前のリモート ブランチに変更を公開します。

チーム

git push --set-upstream origin feature

プルリクエストを作成する

タイトルを付けてプルリクエストを作成する 手順の確認..。 インストール feature 「ヘッドブランチ」のように、 master 「ベースブランチ」のように。

インストールされていることを確認してください master 前 リポジトリをフォークする 「拠点ブランチ」として、教材リポジトリの変更リクエストには応じません。

GitHub 用語では、「ベース ブランチ」は作業の基礎となるブランチ、「ヘッド ブランチ」は提案された変更を含むブランチです。

変更について話し合い、議論が続くにつれて新しいコミットを追加します

プルリクエスト(PR)

プルリクエスト(PR) コードを議論して文書化し、コードレビューを実施する方法です。 プル リクエストは、個々の変更をコード全体に統合する一般的な方法にちなんで名付けられています。 通常、ユーザーはプロジェクトのリモート公式リポジトリのクローンを作成し、ローカルでコードを操作します。 この後、彼はコードを個人のリモート リポジトリに配置し、公式リポジトリの責任者に取得するよう依頼します(プル) そのコードをローカル リポジトリに追加し、そこでレビューし、場合によっては統合します(マージ） 彼の。 この概念は、次のような別の名前でも知られています。 マージリクエスト.

実際には、GitHub または同様のプラットフォームのプル リクエスト機能を使用する必要はありません。 開発チームは、対面コミュニケーション、音声通話、電子メールなど、他のコミュニケーション方法を使用することもありますが、フォーラム スタイルのプル リクエストを使用する理由は依然として数多くあります。 その一部を次に示します。

  • 特定のコード変更に関連する組織的なディスカッション。
  • 自動テスターと同僚の両方からの進行中の作業に関するフィードバックを表示する場所として。
  • コードレビューの形式化。
  • これにより、後でこのコードまたはそのコード部分の背後にある理由と考慮事項を見つけることができます。

通常、何かについて話し合ったりフィードバックを得る必要がある場合は、プル リクエストを作成します。 たとえば、複数の方法で実装できる機能に取り組んでいる場合、コードの最初の行を記述する前にプル リクエストを作成して、アイデアを共有し、共同作業者と計画について話し合うことができます。 作業がより単純な場合、プル リクエストは、何かがすでに完了し、コミットされ、議論できるときにオープンされます。 シナリオによっては、自動テストを実行したり、コード レビューを開始したりするため、品質管理上の理由のみで PR を開きたい場合があります。 どちらを決定する場合でも、プル リクエストで承認が必要なユーザーを @メンションすることを忘れないでください。

通常、PR を作成するときは次の手順を実行します。

  • 何をどこで変更することを提案しているかを示します。
  • 変更の目的を説明する説明を書きます。 次のものが必要になるかもしれません:
    • コードからは明らかではない重要なもの、または関連する #bugs やコミット番号など、コンテキストを理解するのに役立つものを追加します。
    • 一緒に仕事を始めたい人を @メンションするか、後でコメントで @メンションすることもできます。
    • 同僚に何かを手伝ってもらったり、特定のことを確認したりしてもらいます。

PR を開くと、そのような場合に実行するように構成されたテストが実行されます。 私たちの場合、これはローカルで実行したのと同じテストのセットになりますが、実際のプロジェクトでは追加のテストとチェックが存在する可能性があります。

テストが完了するまでお待ちください。 テストのステータスは、GitHub インターフェイスの PR ディスカッションの下部で確認できます。 テストが完了したら続行します。

️ CI ステップのリストのランダム性に関するメモを追加

このコースで使用されるリストは恣意的かつ主観的なものであるため、これについて注記を追加する必要があります。

️ タスク: このコメントのプルリクエストを作成します

  1. ブランチに切り替える master.
  2. という名前のブランチを作成します bugfix.
  3. ファイルの末尾にメモテキストを追加します ci.md. 
    > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
when code is deployed straight from feature branches. This list is just an interpretation  
that I use in my [DevOps courses](http://redpill.solutions).  
The official tutorial is [here](https://guides.github.com/introduction/flow/).
  4. 変更をコミットします。
  5. スレッドを公開する bugfix リモートリポジトリに。
  6. という名前のプル リクエストを作成します。 コメントの追加 頭枝付き bugfix そしてベースブランチmaster.

インストールされていることを確認してください master 前 リポジトリをフォークする 「拠点ブランチ」として、教材リポジトリの変更リクエストには応じません。

リポジトリは次のようになります。
継続的インテグレーションの一般的な状況

チーム

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

プルリクエスト「コメントの追加」を承認する

️タスク

  1. プルリクエストを作成します。
  2. 「プルリクエストをマージ」をクリックします。
  3. 「結合の確認」をクリックします。
  4. 「ブランチを削除」をクリックします。もう必要ありません。

これはマージ後のコミットの図です。
継続的インテグレーションの一般的な状況

️ 作業を続けてテストを追加してください

プル リクエストで共同作業すると、多くの場合、追加の作業が発生します。 これは通常、コード レビューまたはディスカッションの結果ですが、このコースでは、CI ステップのリストに新しい項目を追加することでこれをモデル化します。

継続的インテグレーションには通常、ある程度のテスト カバレッジが含まれます。 テストカバレッジの要件はさまざまで、通常は「貢献ガイドライン」などと呼ばれる文書に記載されています。 シンプルにして、チェックリストの各行にテストを追加します。

割り当てを実行するときは、最初にテストをコミットしてみてください。 正しくインストールされていれば pre-commit 以前にフックすると、新しく追加されたテストは実行されますが、失敗し、何もコミットされません。 これは、テストが実際に何かをテストしていることを知る方法であることに注意してください。 興味深いことに、テストの前にコードから開始した場合、テストに合格したということは、コードが期待どおりに動作したことを意味するか、テストが実際には何もテストしていないことを意味する可能性があります。 さらに、最初からテストを作成していなかったら、テストを思い出させるものが何もなかったため、テストのことを完全に忘れていたかもしれません。

テスト駆動開発 (TDD)

TDD では、コードの前にテストを記述することをお勧めします。 TDD を使用した一般的なワークフローは次のようになります。

  1. テストを追加します。
  2. すべてのテストを実行し、新しいテストが失敗することを確認します。
  3. コードを書きます。
  4. テストを実行し、すべてのテストが合格することを確認します。
  5. コードをリファクタリングします。
  6. 繰り返す。

失敗したテストの結果は通常赤で表示され、合格したテストの結果は通常緑で表示されるため、このサイクルは赤-緑-リファクタリングとも呼ばれます。

️タスク

まず、テストをコミットして失敗させてから、CI ステップ リスト自体のテキストを追加してコミットします。 テストに合格していることがわかります (「緑色」)。
次に、新しいコードをリモート リポジトリに公開し、プル リクエストのディスカッションの下部にある GitHub インターフェイスで実行されるテストと PR ステータスの更新を確認します。

  1. ブランチに切り替える feature.

  2. これらのテストを以下に追加します ci.test.js 最後の電話の後 it (...);.

    it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
  expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
});

it('6. Deploy from the feature branch to production.', () => {
  expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
});

it('7. If everything is good in production for some period of time, merge changes to master.', () => {
  expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
});

  3. テストをコミットしてみてください。 もし pre-commit フックがインストールされている場合、コミットの試行は失敗します。
  4. 次に、このテキストを追加します ci.md. 
    5. Merge/rebase commits from master. Make tests pass on the merge result.  
6. Deploy from the feature branch with a sneaky bug to production.
7. If everything is good in production for some period of time, merge changes to master.
  5. ローカルで変更を加えてコミットします。
  6. ブランチに変更を投稿する feature.

これで次のようなものができるはずです
継続的インテグレーションの一般的な状況

チーム


# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

マージ競合

変更リクエストに移動 手順の確認.

何も悪いことをしておらず、コードのテストに合格したにもかかわらず、ブランチをマージできません feature и master。 他のスレだからだよ bugfix と合併されました master このPRに取り組んでいる間。
これにより、リモート ブランチが master ブランチのベースとなったバージョンよりも新しいバージョンがある feature。 このため、HEAD を巻き戻すことはできません master スレッドの最後まで feature。 この状況では、コミットをマージまたは適用する必要があります。 feature リベース master。 GitHub は、競合がない場合、実際に自動マージを実行できます。 残念ながら、私たちの状況では、両方のブランチにファイル内に競合する変更があります。 ci.md。 この状況はマージ競合として知られており、手動で解決する必要があります。

マージまたはリベース

マージ

  • 追加のマージ コミットを作成し、作業履歴を保存します。
    • ブランチの元のコミットを元のタイムスタンプと作成者とともに保存します。
    • コミットの SHA を保存し、変更リクエストのディスカッションでコミットにリンクします。
  • 競合を XNUMX 回解決する必要があります。
  • ストーリーを非直線的にします。
    • 分岐が多数あるため (IDE ケーブルを彷彿とさせます)、ストーリーを読むのが難しい場合があります。
    • 自動デバッグがより困難になります。 git bisect それほど有用ではありません。マージ コミットのみが検索されます。

リベース

  • 現在のブランチからのコミットをベース ブランチの上に次々に再生します。
    • 新しい SHA を使用した新しいコミットが生成されるため、GitHub 内のコミットは元のプル リクエストと一致しますが、対応するコメントとは一致しません。
    • コミットはプロセス内で再結合および変更したり、XNUMX つにマージしたりすることもできます。
  • 複数の競合を解決する必要がある場合があります。
  • 直線的なストーリーを維持できます。
    • 合理的な理由がない限り、ストーリーは読みやすいかもしれません。
    • 自動デバッグとトラブルシューティングが少し簡単になり、次のことが可能になります。 git bisectにより、自動ロールバックがより明確かつ予測可能になります。
  • 移行されたコミットを含むブランチをフラグ付きで公開する必要がある --force プルリクエストで使用する場合。

通常、チームは変更をマージする必要がある場合、常に同じ戦略を使用することに同意します。 これは、「純粋な」マージ、上部の「純粋な」コミット、またはその中間、たとえば上部で対話的にコミットを行うなどの可能性があります(git rebase -i) パブリック リポジトリに公開されていないブランチの場合はローカルで実行されますが、「パブリック」ブランチの場合はマージされます。

ここではマージを使用します。

️タスク

  1. コードがローカルブランチにあることを確認してください master リモートリポジトリから更新されます。
  2. ブランチに切り替える feature.
  3. ブランチとのマージを開始する master。 変更の競合によるマージ競合 ci.md.
  4. 競合を解決して、CI ステップのリストとそれに関するメモの両方がテキストに残るようにします。
  5. マージコミットをリモートブランチにパブリッシュする feature.
  6. GitHub UI でプル リクエストのステータスを確認し、マージが解決されるまで待ちます。

チーム

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

素晴らしい仕事だ！

リストの作成は完了しました。次に、プル リクエストを承認する必要があります。 master.

️ タスク: プル リクエスト「ステップ レビュー」を承認する

  1. プルリクエストを開きます。
  2. 「プルリクエストをマージ」をクリックします。
  3. 「結合の確認」をクリックします。
  4. 不要になったので「ブランチを削除」をクリックします。

これが現時点のリポジトリです
継続的インテグレーションの一般的な状況

製品エラー

「テストはエラーの存在を示すことはできるが、エラーの不在を示すことは決してできない」と言われています。 テストを実施し、エラーは示されなかったにもかかわらず、本番環境に潜伏性のバグが忍び込みました。

このようなシナリオでは、次の点に注意する必要があります。

  • 本番環境にデプロイされるもの。
  • スレッド内のコード master エラーが発生し、開発者はそこから新しい作業を開始できます。

ロールバックするか、次のバージョンで修正する必要がありますか?

ロールバックは、既知の良好な以前のバージョンを運用環境にデプロイし、エラーを含むコミットを元に戻すプロセスです。 「前方修正」とは、次のバージョンに修正を追加することを意味します。 master 新しいバージョンをできるだけ早く展開します。 コードが本番環境にデプロイされると API とデータベース スキーマが変更され、継続的デリバリーと良好なテスト カバレッジが得られるため、通常、ロールバックは次のバージョンで修正するよりもはるかに困難でリスクが高くなります。

この場合、ロールバックにはリスクがありませんので、このルートを選択します。

  • 製品のエラーをできるだけ早く修正します。
  • コードを作成する master 新しい仕事を始めるのにすぐに適しています。

️タスク

  1. ブランチに切り替える master ローカルで
  2. リモート リポジトリからローカル リポジトリを更新します。
  3. PR マージコミットを元に戻す 手順の確認 в master.
  4. 変更をリモート リポジトリに公開します。

これは、マージコミットが取り消されたリポジトリの履歴です。
継続的インテグレーションの一般的な状況

チーム

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️セルフテスト

それを確認してください ci.md マージコミットを元に戻した後、「卑劣なバグ」というテキストが含まれなくなりました。

CI ステップのリストを修正し、マスターに戻します

ブランチのマージコミットを完全に元に戻しました。 feature。 良いニュースは、現在はエラーが発生していないことです。 master。 悪いニュースは、継続的統合ステップの貴重なリストもなくなってしまったことです。 したがって、理想的には、次のコミットに修正を適用する必要があります。 feature そしてそれらをに戻します master 修正も一緒に。

この問題にはさまざまな方法でアプローチできます。

  • マージを元に戻すコミットを元に戻す feature с master;
  • 以前からコミットを移動する feature.

この場合、開発チームごとに異なるアプローチが使用されますが、有用なコミットを別のブランチに移動し、この新しいブランチに対して別のプル リクエストを作成します。

️タスク

  1. というスレッドを作成します feature-fix それに切り替えます。

  2. 元のブランチからすべてのコミットを移行する feature 新しいスレッドへ。 移行中に発生したマージ競合を解決します。

    継続的インテグレーションの一般的な状況

  3. 回帰テストを追加する ci.test.js:

    it('does not contain the sneaky bug', () => {
expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
});

  4. テストをローカルで実行して、失敗しないことを確認します。
  5. 「卑劣なバグがある」というテキストを削除 ci.md.
  6. テストの変更とステップ リストの変更をインデックスに追加し、コミットします。
  7. ブランチをリモート リポジトリに公開します。

最終的には次のような結果になるはずです。
継続的インテグレーションの一般的な状況

チーム

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

プルリクエストを作成します。

タイトルを付けてプルリクエストを作成する 機能の修正..。 インストール feature-fix 「ヘッドブランチ」のように、 master 「ベースブランチ」のように。
テストが完了するまでお待ちください。 PR ディスカッションの下部でテストのステータスを確認できます。

インストールされていることを確認してください master 前 リポジトリをフォークする 「拠点ブランチ」として、教材リポジトリの変更リクエストには応じません。

プルリクエスト「機能の修正」を承認する

訂正ありがとうございます！ への変更を承認してください master プルリクエストから。

️タスク

  1. 「プルリクエストをマージ」をクリックします。
  2. 「結合の確認」をクリックします。
  3. 不要になったので「ブランチを削除」をクリックします。

これが現時点で持っておくべきものです。
継続的インテグレーションの一般的な状況

おめでとう！

継続的インテグレーション中に通常実行されるすべての手順が完了しました。

コースに問題があることに気づいた場合、またはコースを改善する方法がわかった場合は、で問題を作成してください。 コース教材のリポジトリ。 このコースには他にも、 インタラクティブバージョン GitHub Learning Lab をプラットフォームとして使用します。

出所： habr.com

コメントを追加します