(ほぼ) まったくの初心者向けの GitLab での CI/CD ガイド

または、一晩の簡単なコーディングでプロジェクトの美しいバッジを取得する方法

おそらく、少なくとも XNUMX つのペット プロジェクトを持っているすべての開発者は、nuget のステータス、コード カバレッジ、パッケージ バージョンを含む美しいバッジに悩まされたことがあるでしょう...そして、このかゆみが私にこの記事を書くきっかけを与えました。 この記事を書く準備をしているときに、私は自分のプロジェクトの XNUMX つでこの美しさを手に入れました。

この記事では、GitLab での .Net Core クラス ライブラリ プロジェクトの継続的統合と配信の基本的な設定、GitLab Pages へのドキュメントの発行、Azure DevOps のプライベート フィードへのビルドされたパッケージのプッシュについて説明します。

開発環境としてVS Codeを使用し、拡張機能を追加しました。 GitLab ワークフロー (開発環境から直接設定ファイルを検証するため)。

簡単な紹介

CD - プッシュしたばかりで、すべてがすでにクライアントに落ちているときですか?

CI / CD とは何か、なぜそれが必要なのか - 簡単に Google で検索できます。 GitLab でパイプラインの構成に関する完全なドキュメントを検索します。 それも簡単。 ここでは、システムのプロセスを鳥瞰図から簡単に、できれば欠陥なく説明します。

• 開発者はリポジトリにコミットを送信し、サイトを通じてマージリクエストを作成します。 または他の方法で、明示的または暗黙的にパイプラインを開始します。,
• すべてのタスクは設定から​​選択され、その条件により特定のコンテキストでタスクを起動できます。
• タスクは段階に応じて整理されており、
• ステージは順番に実行されます。つまり、 に平行 この段階のすべてのタスクが完了すると、
• ステージが失敗すると (つまり、ステージのタスクの少なくとも XNUMX つが失敗すると)、パイプラインは停止します (ほとんどいつも),
• すべてのステージが正常に完了すると、パイプラインは成功したとみなされます。

したがって、次のようになります。

• パイプライン - コードのビルド、テスト、パッケージ化、完成したビルドのクラウド サービスへのデプロイなどを行うことができる段階に編成された一連のタスク。
• ステージ（ステージ) — パイプライン組織単位。1 つ以上のタスクが含まれます。
• タスク （ジョブ) はパイプライン内の作業単位です。 これは、スクリプト (必須)、起動条件、アーティファクトの公開/キャッシュの設定などで構成されます。

したがって、CI/CD をセットアップするときのタスクは、コードとアーティファクトの構築、テスト、公開に必要なすべてのアクションを実装する一連のタスクを作成することになります。

始める前に: なぜですか?

• なぜ Gitlab なのか?

なぜなら、ペットプロジェクト用にプライベートリポジトリを作成する必要が生じたとき、それらは GitHub で支払われ、私は貪欲だったからです。 リポジトリは無料になりましたが、今のところ、これは私が GitHub に移行する十分な理由にはなりません。

• なぜ Azure DevOps パイプラインを使用しないのでしょうか?

この設定は基本的なものであるため、コマンド ラインの知識さえ必要ありません。 外部 git プロバイダーとの統合 - 数回クリックするだけで、SSH キーをインポートしてリポジトリにコミットを送信できます。また、パイプラインはテンプレートからでなくても簡単に構成できます。

スタート地点：持っているものと欲しいもの

我々は持っています：

• GitLab のリポジトリ。

私たちが望んでいるのは:

• 各マージリクエストの自動アセンブリとテスト、
• コミットメッセージに特定の行があれば、マージリクエストごとにパッケージを構築してマスターにプッシュします。
• ビルドされたパッケージを Azure DevOps のプライベート フィードに送信する、
• ドキュメントのアセンブリと GitLab Pages での公開、
• バッジ!11

説明されている要件は、次のパイプライン モデルに有機的に当てはまります。

• ステージ 1 - 組み立て
  • コードを収集し、出力ファイルをアーティファクトとして公開します
• ステージ 2 - テスト
  • ビルド段階から成果物を取得し、テストを実行し、コードカバレッジデータを収集します。
• ステージ 3 - 送信
  • タスク 1 - nuget パッケージをビルドして Azure DevOps に送信する
  • タスク 2 - ソース コード内の xmldoc からサイトを収集し、GitLab Pages で公開します。

始めましょう！

設定の収集

アカウントの準備

1. でアカウントを作成します Microsoft Azure

2. に行く Azure DevOps

3. 新しいプロジェクトを作成します

   1. 名前 - 任意
   2. 可視性 - 任意
      

4. 「作成」ボタンをクリックすると、プロジェクトが作成され、そのページにリダイレクトされます。 このページでは、プロジェクト設定 (左側のリストの下のリンク -> 概要 -> Azure DevOps Services ブロック) に移動して、不要な機能を無効にすることができます。
   

5. 「属性」に移動し、「フィードの作成」をクリックします。

   1. ソースの名前を入力してください
   2. 可視性の選択
   3. チェックを外します 一般的なパブリック ソースからのパッケージを含める、ソースがダンプ nuget クローンにならないようにするため
      

6. [フィードに接続] をクリックし、Visual Studio を選択し、マシン セットアップ ブロックからソースをコピーします。
   

7. アカウント設定に移動し、パーソナルアクセストークンを選択します
   

8. 新しいアクセストークンを作成する

   1. 名前 - 任意
   2. 組織 - 現在
   3. 最長1年間有効
   4. 範囲 - パッケージ化/読み取りおよび書き込み
      

9. 作成したトークンをコピーします - モーダルウィンドウが閉じられると、値は使用できなくなります

10. GitLab のリポジトリ設定に移動し、CI / CD 設定を選択します。
    

11. 変数ブロックを展開し、新しい変数ブロックを追加します

    1. 名前 - スペースを含まない任意の名前 (コマンド シェルで使用可能)
    2. 値 - 段落 9 のアクセス トークン
    3. マスク変数の選択
       

これで事前設定は完了です。

構成フレームワークの準備

デフォルトでは、GitLab の CI/CD 構成では次のファイルが使用されます。 .gitlab-ci.yml リポジトリのルートから。 リポジトリ設定でこのファイルへの任意のパスを設定できますが、この場合は必要ありません。

拡張子からわかるように、このファイルには次の形式の設定が含まれています。 YAML。 ドキュメントには、構成の最上位レベルおよびネストされた各レベルにどのキーを含めることができるかが詳しく説明されています。

まず、タスクが実行される構成ファイルに Docker イメージへのリンクを追加しましょう。 このために、私たちは見つけます Docker Hub の .Net Core イメージ ページ。 で GitHubの さまざまなタスクにどの画像を選択するかについての詳細なガイドがあります。 .Net Core 3.1 を含むイメージはビルドに適しているため、構成に最初の行を自由に追加してください

image: mcr.microsoft.com/dotnet/core/sdk:3.1

ここで、パイプラインが Microsoft イメージ リポジトリから起動されると、指定されたイメージがダウンロードされ、そこで構成のすべてのタスクが実行されます。

次のステップは追加することです ステージさんの。 デフォルトでは、GitLab は 5 つのステージを定義します。

• .pre - すべてのステージまで実行され、
• .post - すべてのステージの後に実行されます。
• build - 最初の後の .pre ステージ、
• test - 第二段階、
• deploy - 第三段階。

ただし、それらを明示的に宣言することを妨げるものはありません。 ステップがリストされている順序は、ステップが実行される順序に影響します。 完全を期すために、構成に追加しましょう。

stages:
  - build
  - test
  - deploy

デバッグの場合、タスクが実行される環境に関する情報を取得することは意味があります。 各タスクの前に実行されるコマンドのグローバル セットを追加しましょう。 before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

コミットが送信されたときにパイプラインが開始されるように、少なくとも XNUMX つのタスクを追加する必要があります。 ここでは、空のタスクを追加してデモンストレーションしてみましょう。

dummy job:
  script:
    - echo ok

検証を開始し、すべてが正常であるというメッセージを受け取り、コミットし、プッシュし、サイトで結果を確認します...そしてスクリプト エラーが発生します - bash: .PSVersion: command not found。 WTF？

すべてが論理的です - デフォルトでは、ランナー (タスク スクリプトの実行を担当し、GitLab によって提供される) は以下を使用します。 bash コマンドを実行します。 これを修正するには、タスクの説明で、実行中のパイプライン ランナーにどのタグを付ける必要があるかを明示的に指定します。

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

素晴らしい！ パイプラインが実行中です。

注意深い読者は、示された手順を繰り返すと、その段階でタスクが完了したことに気づくでしょう。 test、ステージは特定しませんでしたが。 ご想像のとおり test はデフォルトのステップです。

上記のすべてのタスクを追加して、構成スケルトンの作成を続けましょう。

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

特に機能的ではありませんが、それでも正しいパイプラインが完成しました。

トリガーの設定

どのタスクにもトリガー フィルターが指定されていないため、パイプラインは 十分 コミットがリポジトリにプッシュされるたびに実行されます。 これは一般に望ましい動作ではないため、タスクのトリガー フィルターを設定します。

フィルターは XNUMX つの形式で構成できます。 のみ/除く и ルール。 簡単に言うと、 only/except トリガーによってフィルターを設定できます (merge_request例: プル リクエストが作成されるたび、およびマージ リクエストのソースであるブランチにコミットが送信されるたびに実行されるタスク) とブランチ名 (正規表現の使用を含む) を設定します。 rules 一連の条件をカスタマイズし、必要に応じて、前のタスクの成功に応じてタスクの実行条件を変更できます (when GitLab CI/CD 内).

一連の要件 - マージ リクエストのみのアセンブリとテスト、マージ リクエストとマスターへのプッシュの場合のパッケージ化と Azure DevOps への送信、マスターへのプッシュの場合のドキュメント生成 - を思い出してください。

まず、マージ リクエストでのみ起動するルールを追加して、コード ビルド タスクを設定しましょう。

build job:
  # snip
  only:
    - merge_request

次に、マージ リクエストで起動し、マスターにコミットを追加するようにパッケージング タスクを設定しましょう。

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

ご覧のとおり、すべてがシンプルで簡単です。

マージ リクエストが特定のターゲットまたはソース ブランチで作成された場合にのみタスクを起動するように設定することもできます。

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

条件付きでご利用いただけます ここにリストされている変数; ルール rules ルールに適合しない only/except.

アーティファクトの保存の構成

タスク中 build job 後続のタスクで再利用できるビルド アーティファクトが得られます。 これを行うには、タスク設定へのパス、つまり次のタスクで保存して再利用する必要があるファイルへのパスをキーに追加する必要があります。 artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

パスはワイルドカードをサポートしているため、設定が簡単になります。

タスクがアーティファクトを作成すると、後続の各タスクはアーティファクトにアクセスできるようになります。アーティファクトは、元のタスクから収集されたリポジトリ ルートに対して相対的な同じパスに沿って配置されます。 アーティファクトはサイトからダウンロードすることもできます。

構成フレームワークの準備ができた (そしてテストされた) ので、実際にタスク用のスクリプトを作成することに進むことができます。

私たちは脚本を書きます

おそらく、はるか昔、はるか彼方の銀河系で、コマンド ラインからプロジェクト (.net 上のプロジェクトを含む) を構築するのは苦痛だったのでしょう。 これで、3 つのチームでプロジェクトを構築、テスト、公開できるようになりました。

dotnet build
dotnet test
dotnet pack

当然のことながら、いくつかのニュアンスがあるため、コマンドが多少複雑になります。

1. デバッグ ビルドではなくリリース ビルドが必要なので、各コマンドに追加します。 -c Release
2. テスト時にコード カバレッジ データを収集する必要があるため、テスト ライブラリにカバレッジ アナライザーを含める必要があります。
   1. すべてのテスト ライブラリにパッケージを追加する coverlet.msbuild: dotnet add package coverlet.msbuild プロジェクトフォルダーから
   2. テスト実行コマンドに追加 /p:CollectCoverage=true
   3. カバレッジ結果を取得するには、テスト タスク構成にキーを追加します (下記を参照)。
3. コードを nuget パッケージにパックするときは、パッケージの出力ディレクトリを設定します。 -o .

コードカバレッジデータの収集

テストの実行後、Coverlet は実行統計をコンソールに出力します。

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab では、正規表現を指定して統計を取得でき、統計はバッジの形式で取得できます。 正規表現はタスク設定でキーを使用して指定されます。 coverage; 式にはキャプチャ グループが含まれている必要があり、その値がバッジに渡されます。

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

ここでは、合計ライン カバレッジを持つラインから統計を取得します。

パッケージとドキュメントを公開する

どちらのアクションもパイプラインの最終段階でスケジュールされています。アセンブリとテストが完了したので、開発内容を世界と共有できます。

まず、パッケージ ソースに公開することを検討してください。

1. プロジェクトに nuget 構成ファイルがない場合 (nuget.config)、新しいものを作成します。 dotnet new nugetconfig

   何のために： イメージには、グローバル (ユーザーおよびマシン) 構成への書き込みアクセス権がない可能性があります。 エラーを検出しないようにするために、新しいローカル構成を作成し、それを操作するだけです。

2. 新しいパッケージ ソースをローカル構成に追加しましょう。 nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. name - ローカルソース名、重要ではありません
   2. url - 「アカウントの準備」段階のソースの URL (p. 6)
   3. organization - Azure DevOps の組織名
   4. gitlab variable - GitLab に追加されたアクセス トークンを含む変数の名前 (「アカウントの準備」、11 ページ)。 当然フォーマット的には $variableName
   5. -StorePasswordInClearText - アクセス拒否エラーを回避するハック (この熊手を踏んだのは私が初めてではありません)
   6. エラーが発生した場合は、次のように追加すると役立つ場合があります -verbosity detailed
3. パッケージをソースに送信します。 nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. すべてのパッケージは現在のディレクトリから送信されるため、 *.nupkg.
   2. name - 上記のステップから。
   3. key - 任意の行。 Azure DevOps の [フィードに接続] ウィンドウでは、例は常に次の行になります。 az.
   4. -skipduplicate - このキーなしで既存のパッケージを送信しようとすると、ソースはエラーを返します。 409 Conflict; キーを押すと送信がスキップされます。

次に、ドキュメントの作成を設定しましょう。

1. まず、リポジトリの master ブランチで docfx プロジェクトを初期化します。 これを行うには、ルートからコマンドを実行します。 docfx init ドキュメントを構築するための主要なパラメータを対話的に設定します。 プロジェクトの最小セットアップの詳細な説明 ここで.
   1. 構成するときは、出力ディレクトリを指定することが重要です ..public - GitLab はデフォルトで、リポジトリのルートにあるパブリック フォルダーの内容を Pages のソースとして取得します。 なぜならプロジェクトはリポジトリ内にネストされたフォルダーに配置されます。パスの上位レベルに出力を追加します。
2. 変更を GitLab にプッシュしましょう。
3. パイプライン構成にタスクを追加する pages (GitLab Pages でのサイト公開タスクの予約語):
   1. 脚本：
      1. nuget install docfx.console -version 2.51.0 - docFX をインストールします。 バージョンは、パッケージのインストール パスが正しいことを確認するために指定されます。
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - 文書の収集
   2. ノードアーティファクト:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx についての歌詞の余談

以前は、プロジェクトをセットアップするときに、ドキュメントのコード ソースをソリューション ファイルとして指定しました。 主な欠点は、ドキュメントがテスト プロジェクト用にも作成されることです。 これが必要でない場合は、この値をノードに設定できます。 metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

1. metadata.src.src: "../" - 場所に対して XNUMX レベル上に移動します docfx.json、 なぜならパターンでは、ディレクトリ ツリーの検索は機能しません。
2. metadata.src.files: ["**/*.csproj"] - グローバル パターン。すべてのディレクトリからすべての C# プロジェクトを収集します。
3. metadata.src.exclude: ["*.tests*/**"] - グローバル パターン。次のフォルダーからすべてを除外します。 .tests 名前に

小計

このようなシンプルな構成は、わずか XNUMX 分とコーヒー XNUMX 杯で作成できます。これにより、コードがビルドされてテストに合格したことを確認したり、新しいパッケージをビルドしたり、ドキュメントを更新したり、美しいもので目を楽しませることができます。各マージ リクエストとともにプロジェクトの README にバッジが追加され、マスターに送信されます。

最終的な .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

バッジといえば

結局のところ、すべては彼らのおかげで始まりました！

パイプライン ステータスとコード カバレッジを示すバッジは、GitLab の Gtntral パイプライン ブロックの CI/CD 設定で利用できます。

プラットフォーム上のドキュメントへのリンクを含むバッジを作成しました シールズアイオ - すべてが非常に簡単です。独自のバッジを作成し、リクエストを使用してそれを受け取ることができます。

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts を使用すると、最新バージョンのパッケージのバッジを作成することもできます。 これを行うには、Azure DevOps サイトのソースで、選択したパッケージの [バッジの作成] をクリックし、マークダウン マークアップをコピーする必要があります。

美しさを加える

共通の構成フラグメントの強調表示

構成を作成し、ドキュメントを検索しているときに、YAML の興味深い機能、つまりフラグメントの再利用を発見しました。

タスク設定からわかるように、すべてのタスクにタグが必要です windows ランナーで実行され、マージ リクエストがマスターに送信または作成されたときにトリガーされます (ドキュメントを除く)。 これを再利用するフラグメントに追加しましょう。

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

これで、タスクの説明で前に宣言したフラグメントを挿入できるようになりました。

build job:
  <<: *common_tags
  <<: *common_only

タスクとして解釈されないように、フラグメント名はドットで始まる必要があります。

パッケージのバージョン管理

パッケージを作成するとき、コンパイラはコマンド ライン スイッチをチェックし、コマンド ライン スイッチがない場合はプロジェクト ファイルをチェックします。 Version ノードを見つけると、その値をビルド中のパッケージのバージョンとして受け取ります。 新しいバージョンでパッケージをビルドするには、プロジェクト ファイル内でパッケージを更新するか、コマンド ライン引数として渡す必要があることがわかりました。

ウィッシュリストをもう XNUMX つ追加しましょう。バージョン内のマイナー XNUMX つの数字をパッケージの年とビルド日とし、プレリリース バージョンを追加します。 もちろん、このデータをプロジェクト ファイルに追加して、各送信前にチェックすることもできますが、パイプラインで実行して、コンテキストからパッケージのバージョンを収集し、それをコマンド ライン引数を通じて渡すこともできます。

コミットメッセージに次のような行が含まれている場合に同意しましょう。 release (v./ver./version) <version number> (rev./revision <revision>)?次に、この行からパッケージのバージョンを取得し、現在の日付を補足して、それをコマンドの引数として渡します。 dotnet pack。 ラインがない場合は、荷物の回収は行いません。

次のスクリプトはこの問題を解決します。

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

タスクへのスクリプトの追加 pack and deploy job そして、コミット メッセージに指定された文字列が存在する場合のパッケージのアセンブリを厳密に観察します。

合計で

構成の作成、ローカル PowerShell でのデバッグ、そして場合によっては数回の起動の失敗に約 XNUMX 分から XNUMX 時間を費やした後、日常的なタスクを自動化するためのシンプルな構成を取得しました。

もちろん、GitLab CI / CD は、このガイドを読んだ後に思われるよりもはるかに広範囲で多面的です。 それは全く真実ではありません. そこにも 自動 DevOps は許可する

アプリケーションを自動的に検出、構築、テスト、展開、監視します

現在の計画では、Pulumi を使用してターゲット環境を自動的に決定し、アプリケーションを Azure にデプロイするためのパイプラインを構成する予定です。これについては次の記事で説明します。

出所： habr.com