Prohoster > Blog > quản lý > Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Hoặc cách nhận huy hiệu đẹp cho dự án của bạn trong một buổi tối viết mã dễ dàng

Có lẽ, mọi nhà phát triển có ít nhất một dự án thú cưng tại một thời điểm nào đó đều cảm thấy khó chịu về những huy hiệu đẹp mắt với trạng thái, phạm vi mã, phiên bản gói trong nuget ... Và điều ngứa ngáy này đã khiến tôi viết bài này. Để chuẩn bị viết nó, tôi đã có được vẻ đẹp này trong một trong những dự án của mình:

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Bài viết này sẽ hướng dẫn bạn cách thiết lập cơ bản về tích hợp và phân phối liên tục cho dự án thư viện lớp .Net Core trong GitLab, xuất bản tài liệu lên Trang GitLab và đẩy các gói đã xây dựng lên nguồn cấp dữ liệu riêng tư trong Azure DevOps.

Mã VS được sử dụng làm môi trường phát triển với phần mở rộng Quy trình làm việc GitLab (để xác thực tệp cài đặt trực tiếp từ môi trường phát triển).

Giới thiệu ngắn gọn

CD - có phải khi bạn vừa mới đẩy và mọi thứ đã đổ dồn về máy khách không?

CI/CD là gì và tại sao bạn cần nó - bạn có thể dễ dàng google. Tìm tài liệu đầy đủ về cấu hình đường ống trong GitLab cũng dễ dàng. Ở đây tôi sẽ mô tả ngắn gọn và nếu có thể, không có sai sót nào về quy trình của hệ thống từ góc nhìn toàn cảnh:

  • nhà phát triển gửi một cam kết đến kho lưu trữ, tạo yêu cầu hợp nhất thông qua trang web, hoặc theo một số cách khác, bắt đầu đường ống một cách rõ ràng hoặc ngầm định,
  • tất cả các tác vụ được chọn từ cấu hình, các điều kiện cho phép chúng được khởi chạy trong ngữ cảnh nhất định,
  • nhiệm vụ được tổ chức theo các giai đoạn của họ,
  • các giai đoạn được thực hiện lần lượt - tức là song song tất cả các nhiệm vụ của giai đoạn này được hoàn thành,
  • nếu giai đoạn không thành công (nghĩa là ít nhất một trong các tác vụ của giai đoạn không thành công), thì đường ống dẫn sẽ dừng (gần như luôn luôn),
  • nếu tất cả các giai đoạn được hoàn thành thành công, quy trình được coi là thành công.

Như vậy, chúng ta có:

  • đường ống - một tập hợp các tác vụ được tổ chức thành các giai đoạn mà bạn có thể xây dựng, thử nghiệm, đóng gói mã, triển khai bản dựng đã hoàn thành cho dịch vụ đám mây, v.v.
  • sân khấu (giai đoạn) — đơn vị tổ chức đường ống, chứa hơn 1 tác vụ,
  • nhiệm vụ (việc làm) là một đơn vị công việc trong đường ống. Nó bao gồm một tập lệnh (bắt buộc), điều kiện khởi chạy, cài đặt để xuất bản/tạo bộ nhớ đệm, v.v.

Theo đó, nhiệm vụ khi thiết lập CI / CD bắt nguồn từ việc tạo một tập hợp các nhiệm vụ thực hiện tất cả các hành động cần thiết để xây dựng, thử nghiệm và xuất bản mã và tạo phẩm.

Trước khi bắt đầu: tại sao?

  • Tại sao Gitlab?

Bởi vì khi cần tạo các kho lưu trữ riêng cho các dự án thú cưng, chúng đã được trả tiền trên GitHub và tôi đã rất tham lam. Các kho lưu trữ đã trở nên miễn phí, nhưng cho đến nay đây vẫn chưa đủ lý do để tôi chuyển sang GitHub.

  • Tại sao không phải Azure DevOps Pipelines?

Bởi vì ở đó, cài đặt là cơ bản - kiến ​​​​thức về dòng lệnh thậm chí không cần thiết. Tích hợp với các nhà cung cấp git bên ngoài - trong một vài cú nhấp chuột, nhập các khóa SSH để gửi các xác nhận đến kho lưu trữ - cũng vậy, đường dẫn được định cấu hình dễ dàng ngay cả khi không phải từ một mẫu.

Vị trí bắt đầu: những gì bạn có và những gì bạn muốn

Chúng ta có:

  • kho lưu trữ trong GitLab.

Chúng tôi muốn:

  • lắp ráp và thử nghiệm tự động cho từng yêu cầu hợp nhất,
  • xây dựng các gói cho từng yêu cầu hợp nhất và đẩy lên gói chính, với điều kiện là có một dòng nhất định trong thông báo cam kết,
  • gửi các gói đã xây dựng tới nguồn cấp dữ liệu riêng tư trong Azure DevOps,
  • lắp ráp tài liệu và xuất bản trong Trang GitLab,
  • phù hiệu!11

Các yêu cầu được mô tả tự nhiên rơi vào mô hình đường ống sau:

  • Giai đoạn 1 - lắp ráp
    • Chúng tôi thu thập mã, xuất bản các tệp đầu ra dưới dạng hiện vật
  • Giai đoạn 2 - thử nghiệm
    • Chúng tôi nhận được các tạo phẩm từ giai đoạn xây dựng, chạy thử nghiệm, thu thập dữ liệu bao phủ mã
  • Giai đoạn 3 - Gửi
    • Nhiệm vụ 1 - xây dựng gói nuget và gửi tới Azure DevOps
    • Nhiệm vụ 2 - chúng tôi thu thập trang web từ xmldoc trong mã nguồn và xuất bản nó trong Trang GitLab

Bắt đầu nào!

Thu thập cấu hình

Đang chuẩn bị tài khoản

  1. Tạo một tài khoản trong Microsoft Azure

  2. Đi đến Azure DevOps

  3. Chúng tôi tạo một dự án mới

    1. Tên - bất kỳ
    2. Khả năng hiển thị - bất kỳ
      Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  4. Khi bạn nhấp vào nút Tạo, dự án sẽ được tạo và bạn sẽ được chuyển hướng đến trang của nó. Trên trang này, bạn có thể tắt các tính năng không cần thiết bằng cách đi tới cài đặt dự án (liên kết phía dưới trong danh sách bên trái -> Tổng quan -> khối Dịch vụ Azure DevOps)
    Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  5. Chuyển đến Atrifacts, nhấp vào Tạo nguồn cấp dữ liệu

    1. Nhập tên của nguồn
    2. Chọn chế độ hiển thị
    3. Bỏ chọn Bao gồm các gói từ các nguồn công khai phổ biến, để nguồn không biến thành bản sao nuget kết xuất
      Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  6. Nhấp vào Kết nối với nguồn cấp dữ liệu, chọn Visual Studio, sao chép Nguồn từ khối Thiết lập Máy
    Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  7. Vào cài đặt tài khoản, chọn Personal Access Token
    Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  8. Tạo mã thông báo truy cập mới

    1. Tên - tùy ý
    2. Tổ chức - Hiện tại
    3. Có giá trị tối đa 1 năm
    4. Phạm vi - Đóng gói/Đọc & Viết
      Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  9. Sao chép mã thông báo đã tạo - sau khi đóng cửa sổ phương thức, giá trị sẽ không khả dụng

  10. Chuyển đến cài đặt kho lưu trữ trong GitLab, chọn cài đặt CI / CD
    Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

  11. Mở rộng khối Biến, thêm khối mới

    1. Tên - bất kỳ không có dấu cách (sẽ có sẵn trong trình bao lệnh)
    2. Giá trị - mã thông báo truy cập từ đoạn 9
    3. Chọn biến Mặt nạ
      Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Điều này hoàn thành cấu hình trước.

Chuẩn bị khung cấu hình

Theo mặc định, cấu hình CI/CD trong GitLab sử dụng tệp .gitlab-ci.yml từ thư mục gốc của kho lưu trữ. Bạn có thể đặt đường dẫn tùy ý đến tệp này trong cài đặt kho lưu trữ, nhưng trong trường hợp này thì không cần thiết.

Như bạn có thể thấy từ tiện ích mở rộng, tệp chứa cấu hình ở định dạng YAML. Tài liệu nêu chi tiết khóa nào có thể được chứa ở cấp cao nhất của cấu hình và ở mỗi cấp lồng nhau.

Trước tiên, hãy thêm một liên kết đến hình ảnh docker trong tệp cấu hình, trong đó các tác vụ sẽ được thực hiện. Đối với điều này, chúng tôi tìm thấy Trang hình ảnh .Net Core trên Docker Hub. Trong GitHub có một hướng dẫn chi tiết về việc chọn hình ảnh nào cho các nhiệm vụ khác nhau. Một hình ảnh với .Net Core 3.1 phù hợp để chúng tôi xây dựng, vì vậy vui lòng thêm dòng đầu tiên vào cấu hình

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

Giờ đây, khi đường dẫn được khởi chạy từ kho lưu trữ hình ảnh của Microsoft, hình ảnh được chỉ định sẽ được tải xuống, trong đó tất cả các tác vụ từ cấu hình sẽ được thực thi.

Bước tiếp theo là thêm giai đoạn'S. Theo mặc định, GitLab xác định 5 giai đoạn:

  • .pre - thực hiện đến tất cả các giai đoạn,
  • .post - thực hiện sau tất cả các giai đoạn,
  • build - trước sau .pre sân khấu,
  • test - giai đoạn thứ hai,
  • deploy - giai đoạn thứ ba.

Tuy nhiên, không có gì ngăn cản bạn khai báo chúng một cách rõ ràng. Thứ tự các bước được liệt kê ảnh hưởng đến thứ tự thực hiện chúng. Để hoàn thiện, hãy thêm vào cấu hình:

stages:
  - build
  - test
  - deploy

Để gỡ lỗi, bạn nên lấy thông tin về môi trường trong đó các tác vụ được thực thi. Hãy thêm một tập lệnh chung sẽ được thực thi trước mỗi tác vụ với before_script:

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

Vẫn còn phải thêm ít nhất một tác vụ để khi các xác nhận được gửi, đường dẫn sẽ bắt đầu. Hiện tại, hãy thêm một tác vụ trống để chứng minh:

dummy job:
  script:
    - echo ok

Chúng tôi bắt đầu xác thực, chúng tôi nhận được thông báo rằng mọi thứ đều ổn, chúng tôi cam kết, chúng tôi thúc đẩy, chúng tôi xem kết quả trên trang web ... Và chúng tôi gặp lỗi tập lệnh - bash: .PSVersion: command not found. wtf?

Mọi thứ đều hợp lý - theo mặc định, người chạy (chịu trách nhiệm thực thi các tập lệnh tác vụ và do GitLab cung cấp) sử dụng bash để thực hiện các lệnh. Bạn có thể khắc phục điều này bằng cách chỉ định rõ ràng trong phần mô tả tác vụ những thẻ mà trình chạy đường dẫn thực thi nên có:

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

Tuyệt vời! Các đường ống hiện đang chạy.

Một người đọc chu đáo, sau khi lặp lại các bước được chỉ định, sẽ nhận thấy rằng nhiệm vụ đã được hoàn thành trong giai đoạn test, mặc dù chúng tôi không chỉ định giai đoạn. Như bạn có thể đoán test là bước mặc định.

Hãy tiếp tục tạo khung cấu hình bằng cách thêm tất cả các tác vụ được mô tả ở trên:

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

Chúng tôi có một đường ống không đặc biệt chức năng, nhưng vẫn chính xác.

Thiết lập trình kích hoạt

Do không có bộ lọc kích hoạt nào được chỉ định cho bất kỳ tác vụ nào, đường dẫn sẽ đầy đủ được thực hiện mỗi khi một cam kết được đẩy vào kho lưu trữ. Vì đây không phải là hành vi mong muốn nói chung, nên chúng tôi sẽ thiết lập bộ lọc kích hoạt cho các tác vụ.

Bộ lọc có thể được cấu hình ở hai định dạng: chỉ/ngoại trừ и quy tắc. Tóm tắt, only/except cho phép bạn định cấu hình bộ lọc theo trình kích hoạt (merge_request, ví dụ - đặt tác vụ sẽ được thực thi mỗi khi yêu cầu kéo được tạo và mỗi lần xác nhận được gửi đến nhánh là nguồn trong yêu cầu hợp nhất) và tên nhánh (bao gồm cả việc sử dụng cụm từ thông dụng); rules cho phép bạn tùy chỉnh một tập hợp các điều kiện và tùy ý thay đổi điều kiện thực hiện tác vụ tùy thuộc vào sự thành công của các tác vụ trước đó (when trong GitLab CI/CD).

Hãy nhớ lại một tập hợp các yêu cầu - chỉ lắp ráp và thử nghiệm đối với yêu cầu hợp nhất, đóng gói và gửi tới Azure DevOps - đối với yêu cầu hợp nhất và đẩy lên bản chính, tạo tài liệu - để đẩy lên bản chính.

Trước tiên, hãy thiết lập tác vụ xây dựng mã bằng cách thêm quy tắc chỉ kích hoạt theo yêu cầu hợp nhất:

build job:
  # snip
  only:
    - merge_request

Bây giờ, hãy thiết lập tác vụ đóng gói để kích hoạt yêu cầu hợp nhất và thêm các cam kết vào bản gốc:

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

Như bạn có thể thấy, mọi thứ đều đơn giản và dễ hiểu.

Bạn cũng có thể đặt tác vụ chỉ kích hoạt nếu một yêu cầu hợp nhất được tạo với một nhánh đích hoặc nhánh nguồn cụ thể:

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

Trong điều kiện, bạn có thể sử dụng các biến được liệt kê ở đây; quy tắc rules không phù hợp với các quy tắc only/except.

Định cấu hình lưu hiện vật

Trong một nhiệm vụ build job chúng tôi sẽ có các tạo phẩm xây dựng có thể được sử dụng lại trong các tác vụ tiếp theo. Để thực hiện việc này, bạn cần thêm các đường dẫn đến cấu hình tác vụ, các tệp mà bạn sẽ cần lưu và sử dụng lại trong các tác vụ sau, vào khóa artifacts:

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

Đường dẫn hỗ trợ ký tự đại diện, điều này chắc chắn làm cho chúng dễ đặt hơn.

Nếu một tác vụ tạo ra các tạo phẩm, thì mỗi tác vụ tiếp theo sẽ có thể truy cập chúng - chúng sẽ nằm dọc theo cùng một đường dẫn so với thư mục gốc của kho lưu trữ được thu thập từ tác vụ ban đầu. Hiện vật cũng có sẵn để tải về trên trang web.

Bây giờ chúng ta đã có một khung cấu hình sẵn sàng (và đã được thử nghiệm), chúng ta có thể tiến hành viết các tập lệnh thực sự cho các tác vụ.

Chúng tôi viết kịch bản

Có lẽ, ngày xửa ngày xưa, ở một thiên hà xa xôi, việc xây dựng các dự án (bao gồm cả những dự án trên .net) từ dòng lệnh là một điều khó khăn. Giờ đây, bạn có thể xây dựng, thử nghiệm và xuất bản dự án theo 3 nhóm:

dotnet build
dotnet test
dotnet pack

Đương nhiên, có một số sắc thái do đó chúng ta sẽ làm phức tạp hóa các lệnh một chút.

  1. Chúng tôi muốn bản dựng phát hành, không phải bản dựng gỡ lỗi, vì vậy chúng tôi thêm vào mỗi lệnh -c Release
  2. Khi thử nghiệm, chúng tôi muốn thu thập dữ liệu về mức độ phù hợp của mã, vì vậy chúng tôi cần đưa bộ phân tích mức độ phù hợp vào thư viện thử nghiệm:
    1. Thêm gói vào tất cả các thư viện thử nghiệm coverlet.msbuild: dotnet add package coverlet.msbuild từ thư mục dự án
    2. Thêm vào lệnh chạy thử /p:CollectCoverage=true
    3. Thêm một khóa vào cấu hình tác vụ kiểm tra để nhận kết quả về phạm vi bảo hiểm (xem bên dưới)
  3. Khi đóng gói mã vào các gói nuget, hãy đặt thư mục đầu ra cho các gói: -o .

Thu thập dữ liệu bảo hiểm mã

Sau khi chạy thử nghiệm, bản in Coverlet chạy số liệu thống kê cho bảng điều khiển:

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 cho phép bạn chỉ định một biểu thức chính quy để nhận số liệu thống kê, sau đó có thể nhận được thống kê này dưới dạng huy hiệu. Biểu thức chính quy được chỉ định trong cài đặt tác vụ bằng phím coverage; biểu thức phải chứa một nhóm chụp, giá trị của nhóm này sẽ được chuyển đến huy hiệu:

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

Ở đây chúng tôi nhận được số liệu thống kê từ một dòng có tổng độ bao phủ của dòng.

Xuất bản các gói và tài liệu

Cả hai hành động đều được lên lịch cho giai đoạn cuối cùng của quy trình - vì quá trình lắp ráp và thử nghiệm đã hoàn thành nên chúng tôi có thể chia sẻ những phát triển của mình với mọi người.

Trước tiên, hãy xem xét xuất bản lên nguồn gói:

  1. Nếu dự án không có tệp cấu hình nuget (nuget.config), tạo một cái mới: dotnet new nugetconfig

    Để làm gì: hình ảnh có thể không có quyền ghi vào cấu hình chung (người dùng và máy). Để không bắt lỗi, chúng tôi chỉ cần tạo một cấu hình cục bộ mới và làm việc với nó.

  2. Hãy thêm một nguồn gói mới vào cấu hình cục bộ: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name - tên nguồn địa phương, không quan trọng
    2. url - URL của nguồn từ giai đoạn "Chuẩn bị tài khoản", trang 6
    3. organization - tên tổ chức trong Azure DevOps
    4. gitlab variable - tên của biến có mã thông báo truy cập được thêm vào GitLab ("Chuẩn bị tài khoản", trang 11). Đương nhiên, ở dạng $variableName
    5. -StorePasswordInClearText - một bản hack để bỏ qua lỗi truy cập bị từ chối (Tôi không phải là người đầu tiên bước lên cái cào này)
    6. Trong trường hợp có lỗi, có thể hữu ích để thêm -verbosity detailed
  3. Gửi gói đến nguồn: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. Chúng tôi gửi tất cả các gói từ thư mục hiện tại, vì vậy *.nupkg.
    2. name - từ bước trên.
    3. key - bất kỳ dòng nào. Trong Azure DevOps, trong cửa sổ Kết nối với nguồn cấp dữ liệu, ví dụ luôn là dòng az.
    4. -skipduplicate - khi cố gắng gửi một gói đã tồn tại mà không có khóa này, nguồn sẽ trả về lỗi 409 Conflict; bằng phím, quá trình gửi sẽ bị bỏ qua.

Bây giờ hãy thiết lập việc tạo tài liệu:

  1. Đầu tiên, trong kho lưu trữ, trong nhánh chính, chúng tôi khởi tạo dự án docfx. Để làm điều này, hãy chạy lệnh từ thư mục gốc docfx init và thiết lập một cách tương tác các tham số chính cho tài liệu xây dựng. Mô tả chi tiết về thiết lập dự án tối thiểu đây.
    1. Khi định cấu hình, điều quan trọng là chỉ định thư mục đầu ra ..public - GitLab theo mặc định lấy nội dung của thư mục chung trong thư mục gốc của kho lưu trữ làm nguồn cho Trang. Bởi vì dự án sẽ được đặt trong một thư mục được lồng trong kho lưu trữ - thêm một đầu ra để tăng cấp trong đường dẫn.
  2. Hãy đẩy các thay đổi vào GitLab.
  3. Thêm một tác vụ vào cấu hình đường ống pages (từ dành riêng cho các tác vụ xuất bản trang trong Trang GitLab):
    1. Kịch bản:
      1. nuget install docfx.console -version 2.51.0 - cài đặt docfx; phiên bản được chỉ định để đảm bảo rằng đường dẫn cài đặt gói là chính xác.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - thu thập tài liệu
    2. Hiện vật nút:

pages:
  # snip
  artifacts:
    paths:
      - public

Lạc đề trữ tình về docfx

Trước đây, khi thiết lập dự án, tôi đã chỉ định nguồn mã cho tài liệu dưới dạng tệp giải pháp. Nhược điểm chính là tài liệu cũng được tạo cho các dự án thử nghiệm. Trong trường hợp không cần thiết, bạn có thể đặt giá trị này cho nút metadata.src:

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

  1. metadata.src.src: "../" - chúng tôi tăng một cấp so với vị trí docfx.json, bởi vì trong các mẫu, việc tìm kiếm cây thư mục không hoạt động.
  2. metadata.src.files: ["**/*.csproj"] - một mẫu toàn cầu, chúng tôi thu thập tất cả các dự án C# từ tất cả các thư mục.
  3. metadata.src.exclude: ["*.tests*/**"] - mẫu toàn cầu, loại trừ mọi thứ khỏi các thư mục với .tests Trong tiêu đề

Tổng phụ

Một cấu hình đơn giản như vậy có thể được tạo chỉ trong nửa giờ và một vài tách cà phê, điều này sẽ cho phép bạn kiểm tra xem mã đã được tạo chưa và các bài kiểm tra đã vượt qua chưa, xây dựng một gói mới, cập nhật tài liệu và làm đẹp mắt huy hiệu trong README của dự án với mỗi yêu cầu hợp nhất và gửi tới chủ.

.gitlab-ci.yml cuối cùng

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

Nói về phù hiệu

Bởi vì họ, sau tất cả, mọi thứ đã được bắt đầu!

Huy hiệu có trạng thái đường ống và phạm vi mã có sẵn trong GitLab trong cài đặt CI/CD trong khối đường ống Gtntral:

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Tôi đã tạo huy hiệu có liên kết đến tài liệu trên nền tảng Khiên.io - mọi thứ ở đó khá đơn giản, bạn có thể tạo huy hiệu của riêng mình và nhận nó theo yêu cầu.

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

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Azure DevOps Artifacts cũng cho phép bạn tạo huy hiệu cho các gói có phiên bản mới nhất. Để thực hiện việc này, trong nguồn trên trang web Azure DevOps, bạn cần nhấp vào Tạo huy hiệu cho gói đã chọn và sao chép đánh dấu đánh dấu:

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Hướng dẫn về CI/CD trong GitLab dành cho người mới bắt đầu (gần như) tuyệt đối

Thêm vẻ đẹp

Làm nổi bật các đoạn cấu hình phổ biến

Trong khi viết cấu hình và tìm kiếm trong tài liệu, tôi bắt gặp một tính năng thú vị của YAML - tái sử dụng các đoạn.

Như bạn có thể thấy từ cài đặt tác vụ, tất cả chúng đều yêu cầu thẻ windows tại người chạy và được kích hoạt khi yêu cầu hợp nhất được gửi đến bản gốc/được tạo (ngoại trừ tài liệu). Hãy thêm phần này vào đoạn mà chúng ta sẽ sử dụng lại:

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

Và bây giờ chúng ta có thể chèn đoạn đã khai báo trước đó trong phần mô tả tác vụ:

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

Tên đoạn phải bắt đầu bằng dấu chấm để không bị hiểu là tác vụ.

phiên bản gói

Khi tạo một gói, trình biên dịch sẽ kiểm tra các công tắc dòng lệnh và nếu không có chúng, các tệp dự án; khi nó tìm thấy một nút Phiên bản, nó sẽ nhận giá trị của nó là phiên bản của gói đang được xây dựng. Hóa ra là để xây dựng một gói có phiên bản mới, bạn cần cập nhật gói đó trong tệp dự án hoặc chuyển gói đó dưới dạng đối số dòng lệnh.

Hãy thêm một Danh sách mong muốn nữa - đặt hai số phụ trong phiên bản là năm và ngày xây dựng của gói, đồng thời thêm các phiên bản phát hành trước. Tất nhiên, bạn có thể thêm dữ liệu này vào tệp dự án và kiểm tra trước mỗi lần gửi - nhưng bạn cũng có thể thực hiện việc đó trong quy trình bán hàng, thu thập phiên bản gói từ ngữ cảnh và chuyển nó qua đối số dòng lệnh.

Hãy đồng ý rằng nếu thông báo cam kết chứa một dòng như release (v./ver./version) <version number> (rev./revision <revision>)?, sau đó chúng tôi sẽ lấy phiên bản của gói từ dòng này, bổ sung ngày hiện tại và chuyển nó làm đối số cho lệnh dotnet pack. Trong trường hợp không có dòng, đơn giản là chúng tôi sẽ không thu thập gói hàng.

Kịch bản sau giải quyết vấn đề này: 

# регулярное выражение для поиска строки с версией
$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

Thêm tập lệnh vào tác vụ pack and deploy job và tuân thủ nghiêm ngặt việc lắp ráp các gói khi có một chuỗi nhất định trong thông báo cam kết.

trong tổng số

Sau khi dành khoảng nửa giờ hoặc một giờ để viết cấu hình, gỡ lỗi trong powershell cục bộ và có thể là một vài lần khởi chạy không thành công, chúng tôi đã có một cấu hình đơn giản để tự động hóa các tác vụ thông thường.

Tất nhiên, GitLab CI / CD rộng rãi và đa diện hơn nhiều so với vẻ ngoài của nó sau khi đọc hướng dẫn này - điều đó không đúng chút nào. thậm chí có DevOps tự động bây giờ làcho phép

tự động phát hiện, xây dựng, thử nghiệm, triển khai và giám sát các ứng dụng của bạn

Giờ đây, các kế hoạch là định cấu hình một đường dẫn để triển khai các ứng dụng lên Azure, sử dụng Pulumi và tự động xác định môi trường đích, điều này sẽ được đề cập trong bài viết tiếp theo.

Nguồn: www.habr.com

Thêm một lời nhận xét