Thực hành CI/CD: Quy trình tích hợp liên tục đơn giản nhưng đầy đủ chức năng [Phần 1]

CI/CD là một giáo điều phát triển phần mềm đã có từ lâu đời. Internet có đầy rẫy các bài viết và trang nói về CI/CD. Chúng luôn có cùng một hình ảnh CI/CD . Tôi cá là bạn biết hình ảnh tôi đang nói đến.

Tôi đã đọc hàng tá bài viết về chủ đề này và trải nghiệm quá trình triển khai quy trình CI/CD từ đầu đến cuối. Thực tế là việc triển khai quy trình CI/CD phức tạp hơn nhiều so với việc đọc các bài báo, hiểu bức tranh tổng thể về CI/CD và sử dụng lý thuyết. Việc phát triển quy trình CI/CD đòi hỏi các đội ngũ liên ngành và có kinh nghiệm.

Bài viết này giải thích cách xây dựng quy trình CI khả thi tối thiểu của ứng dụng Python. Bạn có thể điều chỉnh nội dung bài viết cho phù hợp với các ngôn ngữ và yêu cầu khác. Mẫu sử dụng Tác vụ FastAPI và GitHub.

CI: Tích hợp liên tục

Hãy để tôi thêm hai xu của mình vào các mô tả tích hợp liên tục hiện có. Tích hợp liên tục có nghĩa là thường xuyên hợp nhất các thay đổi mã được kiểm tra, phê duyệt và phân phối tự động vào kho lưu trữ dự án.

Ví dụ này sử dụng Tác vụ GitHub để tự động thực hiện các kiểm tra bắt buộc đối với mỗi sự kiện 'Yêu cầu kéo' hoặc 'Đẩy vào chính' để đảm bảo rằng mã tuân thủ các tiêu chuẩn chất lượng của kho lưu trữ. Thị trường cung cấp một bộ sưu tập đa dạng các công cụ CI/CD: Jenkins , Travis , CircleCI , GitLab, v.v. Hãy chọn một công cụ phù hợp nhất với yêu cầu quy trình của bạn.

Quy trình làm việc mẫu sẽ kiểm tra xem mã mới có tuân theo các quy tắc định dạng chạy pre-commit hay không. Sau đó, nó thực hiện các thử nghiệm nhỏ bằng Pytest và cuối cùng là thử nghiệm trung bình cài đặt ứng dụng Helm Chart trên cụm Kin D.

Quy trình tích hợp liên tục của bạn sẽ phụ thuộc vào quy mô nhóm, mức độ trưởng thành, yêu cầu ứng dụng và chiến lược phân nhánh của bạn.

Phân tích mã tĩnh

Phân tích các thay đổi mã mà không thực hiện chúng. Các công cụ phân tích tĩnh kiểm tra xem mã của bạn có tuân thủ các quy tắc định dạng hay không, không sử dụng các phần phụ thuộc không được dùng nữa hoặc bị hỏng, đồng thời có thể đọc được và đủ đơn giản. Họ cũng đề xuất các kiểu mã hóa và lỗi tùy thuộc vào ngôn ngữ lập trình.

Chúng tôi sẽ giải thích cách cài đặt, định cấu hình và chạy Pre-commit. Bạn có thể kết hợp Pre-commit với các công cụ phân tích khác như Sonar hay Synk .

Cam kết trước

Cam kết trước là một công cụ được viết bằng Python. Để định cấu hình nó trên kho lưu trữ của bạn cũng đơn giản như tạo tệp YAML và thêm các hook được phiên bản mà bạn muốn chạy trước mỗi lần xác nhận. Cam kết trước tự động quản lý các phần phụ thuộc mà hook yêu cầu và tự động sửa các lỗi tìm thấy. Nó hỗ trợ nhiều loại tệp: JSON, YAML, tf, py, ts, v.v.

Tiết kiệm chi phí cơ sở hạ tầng bằng cách chạy kiểm tra mã cục bộ trước khi đẩy chúng. Bạn có thể chạy Cam kết trước trên CI của mình để kiểm tra định dạng của mã được đẩy.

Cài đặt, định cấu hình và chạy công cụ Pre-commit:

 repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace

 $ pip install pre-commit $ pre-commit install $ pre-commit run --all-files

Bài kiểm tra

Các định nghĩa và phạm vi thử nghiệm Đơn vị, Tích hợp và End-to-End đôi khi rất khác nhau. Như tôi đã làm với mô tả Tích hợp liên tục, tôi sẽ thêm hai xu của mình vào Kỹ thuật phần mềm tại các loại bài kiểm tra của Google :

• Nhỏ : Kiểm tra nhanh. Kiểm tra các đoạn mã nhỏ. Sử dụng môi trường thử nghiệm nhân đôi hoặc mô phỏng (ví dụ: SQLite). Không cần thiết phải xây dựng bất kỳ hiện vật nào. Thời gian: ~ 60 giây.

• Medium : Kiểm tra sự tương tác giữa nhiều đoạn mã. Chúng có thể bao gồm việc xây dựng các tạo phẩm, sử dụng các tạo phẩm của bên thứ ba (ví dụ: cơ sở dữ liệu ) và kết nối với mạng localhost. Việc sử dụng môi trường giả mạo (ví dụ: docker-compose, Kind, Minikube, v.v.) hoặc các dịch vụ bên ngoài (ví dụ: Azure Blob Storage hoặc AWS S3). Thời gian: ~ 300 giây.

• Lớn : Họ sử dụng các môi trường giống như sản xuất (ví dụ: Kiểm tra hiệu suất). Thời gian: +900 giây.

  
  

Việc có hoặc không có các thử nghiệm trung bình/lớn trên quy trình tích hợp liên tục tùy thuộc vào yêu cầu của bạn.

Bé nhỏ

Ví dụ này sử dụng Pytest để chạy thử nghiệm và ứng dụng khách thử nghiệm FastAPI để mô phỏng môi trường. Không có bí mật; công cụ kiểm tra ngôn ngữ lập trình của bạn sẽ cung cấp cho bạn tất cả các phụ thuộc cần thiết để kiểm tra ứng dụng của bạn.

Ngoài ra, bạn có thể thêm kiểm tra phạm vi kiểm tra tối thiểu và tải nó lên như một phần kết quả của bạn. Phạm vi kiểm tra là một thước đo phức tạp. Phạm vi kiểm tra cao không hoàn toàn có nghĩa là có mã được kiểm tra tốt, nhưng 50% cao hơn mã được kiểm tra 0%.

Trung bình

Kin D là cụm Kubernetes nhẹ docker-in-docker được sử dụng để phát triển cục bộ hoặc CI. Chúng tôi sử dụng Kind để thiết lập môi trường thử nghiệm và chạy thử nghiệm trên môi trường đó:

1. Tạo cụm Loại
2. Xây dựng hình ảnh Docker
3. Tải hình ảnh Docker vào loại
4. Cài đặt MetalLB và áp dụng CDR cần thiết
5. Cài đặt Ingress-Nginx
6. Cài đặt Biểu đồ Helm của bạn
7. Thiết lập máy chủ hệ điều hành của bạn

Tải hình ảnh Docker

Loại sẽ không tải xuống được hình ảnh của bạn vì nó không thể tải xuống được từ sổ đăng ký. Loại yêu cầu phải tải hình ảnh trước khi sử dụng.

kim loạiLB

MetalLB là bộ cân bằng tải Kubernetes bằng kim loại trần. Đọc thêm về lý do cần có bộ cân bằng tải trên trang web MetalLB .

Sau khi cài đặt bằng Biểu đồ Helm, chúng ta có thể tạo CRD cần thiết:

 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"

Docker tạo một mạng con cho cụm Loại (ví dụ: 172.26.0.0/16). Kiểm tra giao diện mạng Kind để biết dải địa chỉ IP được chỉ định và sử dụng địa chỉ này làm giá trị cho tài nguyên IPAddressPool. Thông tin thêm về cấu hình MetalLB có trên trang web KinD .

Ứng dụng phơi bày

Cài đặt Biểu đồ Helm Ingress-Nginx. Sau đó, cài đặt Biểu đồ Helm cho ứng dụng của bạn, xác định đối tượng Ingress. Đặt thuộc tính ingressClassName thành nginx và xác định máy chủ (ví dụ: api.local). Cuối cùng, sửa đổi /etc/host để nối thêm dòng sau:

 192.168.1.10 api.local

Bạn có thể xác định bao nhiêu máy chủ tùy thích, trỏ đến cùng một địa chỉ. Nginx sẽ làm phần còn lại.

Vận chuyển

Trước khi cung cấp các tạo phẩm cần thiết, quy trình làm việc sẽ thực hiện các bước tìm lỗi mã nguồn và kiểm tra.

Chúng tôi sử dụng Commitizen để quản lý việc phát hành các tạo phẩm. Commtizen tự động cập nhật phiên bản tạo tác và đẩy các thay đổi. Nó tạo một thẻ git mới với định dạng thẻ được định cấu hình. Bạn cũng có thể định cấu hình Commtizen để cập nhật Changelog của mình với những thay đổi mới nhất.

 [tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]

Quy trình làm việc sử dụng phiên bản đầu ra của Commitizen để đặt thẻ Hình ảnh Docker và Biểu đồ Helm.

Kết luận

Bài viết này phác thảo một quy trình tích hợp liên tục đơn giản nhưng đầy đủ chức năng. Có thể cần thay đổi để hoạt động với các ngôn ngữ lập trình khác hoặc phù hợp với yêu cầu của bạn, nhưng một số bước phải dễ dàng xuất và hoạt động như hiện tại.

Thực hành CI/CD: Triển khai liên tục [Phần 2] Sắp ra mắt …