Tin tức và phân tích của tất cả các thiết bị di động

Hiểu tích hợp liên tục và triển khai liên tục

Bạn đã nghe nói về CI/CD nhưng không biết nó là gì?

Lý tưởng nhất là các kỹ sư phần mềm được thuê để viết mã cần được gửi đến môi trường sản xuất để công ty cần sản phẩm có thể tận dụng lợi thế của nó. Để giữ cho công ty (thường được gọi là người dùng/khách hàng) hài lòng, điều quan trọng là các sản phẩm không có lỗi.

Một cách tiếp cận điển hình được các kỹ sư phần mềm sử dụng là làm việc trong các nhánh và tạo các yêu cầu kéo để cập nhật nhánh chính với bản cập nhật mới đã được thực hiện. Chúng tôi đã áp dụng phương pháp viết bài kiểm tra để đảm bảo rằng những thay đổi mới không gây ra lỗi. Khi các nhà phát triển chủ yếu làm việc trên một tính năng, họ thường không tạo yêu cầu kéo cho đến khi họ hoàn thành xong tính năng đó. Điều gì xảy ra khi họ sẵn sàng là thế này;

  • Họ dành nhiều thời gian để cố gắng cập nhật cơ sở mã của mình với những thay đổi đã xảy ra trong ngành sản xuất khi đang làm việc.
  • Để làm như vậy, họ cần khắc phục một số xung đột hợp nhất.
  • Cũng có khả năng một chi nhánh sản xuất bị hỏng, ảnh hưởng đến những người rút khỏi chi nhánh trước khi vấn đề được chú ý và khắc phục.

Nếu bạn đã từng ở trong tình huống này, bạn sẽ đồng ý rằng nó có thể gây phiền toái – không ai thích trải qua ngày làm việc của mình như thế này.

Câu trả lời là gì?

Hội nhập liên tục

Để ngăn chặn các kịch bản tôi đã đề cập ở trên; các nhóm kỹ thuật có thể áp dụng một phương pháp gọi là tích hợp liên tục – như tên gợi ý, nó bao gồm tích hợp liên tục các thay đổi mã do nhà phát triển thực hiện vào một nhánh/kho lưu trữ chung. Mã được tích hợp phải vượt qua kiểm tra đã được xác minh để đảm bảo rằng mã không phá vỡ ứng dụng. Chỉ khi vượt qua bài kiểm tra, nó mới được tích hợp

Để hiểu điều này, hãy tưởng tượng một kịch bản thực tế với một nhóm gồm 10 nhà phát triển. Những nhà phát triển này tạo một nhánh cục bộ nơi họ viết mã để triển khai một số tính năng nhất định. Thay vì gửi yêu cầu kéo khi họ sử dụng xong tính năng này, họ chọn gửi yêu cầu kéo vì họ đang thực hiện những thay đổi nhỏ. Một ví dụ về sự thay đổi như vậy sẽ là việc tạo một phương thức mới, giả định rằng nhà phát triển đang làm việc trên một chức năng cho phép người dùng quản lý các tác vụ riêng lẻ trong ứng dụng. Thay vì đợi chức năng công việc hoàn thành để tuân theo mô hình tích hợp liên tục, nhà phát triển đẩy thay đổi nhỏ đó (so với những gì anh ta đang làm) và tạo yêu cầu kéo để hợp nhất với mã.

Trước khi có thể tích hợp thay đổi mới này, một loạt thử nghiệm phải được thực hiện.

Các nhóm kỹ thuật phần mềm sử dụng các công cụ như Travis CI để tạo các quy trình thử nghiệm và tích hợp này. Với những công cụ như vậy, các bài kiểm tra được tự động hóa để chúng chạy ngay lập tức sau khi gửi yêu cầu kéo tới nhánh mục tiêu được chọn trong quá trình cài đặt.

Kết quả kiểm tra được tạo và nhà phát triển đã tạo yêu cầu kéo có thể xem kết quả và thực hiện bất kỳ thay đổi cần thiết nào. Lợi ích của việc tuân theo mẫu tích hợp mã này càng ít càng tốt và có một thử nghiệm đã được xác minh để chạy là;

  • Nhóm liên quan có thể biết nguyên nhân khiến quá trình xây dựng hoặc thử nghiệm không thành công. Điều này làm giảm khả năng gửi lỗi đến sản xuất.
  • Nếu nhóm tự động hóa quy trình, họ sẽ có nhiều thời gian để tập trung vào năng suất.

Điều quan trọng cần lưu ý về phương pháp này là nó khuyến khích nhóm thường xuyên đẩy mã lên nhánh chính. Điều này sẽ không hiệu quả nếu các thành viên khác trong nhóm không lấy từ nhánh chính để cập nhật kho lưu trữ cục bộ của họ.

Các loại bài kiểm tra

Khi viết các bài kiểm tra sẽ là một phần của quy trình tích hợp, đây là một vài điều có thể được triển khai trong quy trình:

  • Tích hợp – kết hợp các đơn vị phần mềm riêng lẻ và kiểm tra chúng theo nhóm.
  • Đơn vị – kiểm tra các đơn vị hoặc thành phần phần mềm riêng lẻ, chẳng hạn như phương pháp hoặc chức năng.
  • Giao diện người dùng – đảm bảo rằng phần mềm hoạt động tốt từ quan điểm của người dùng.
  • Chấp nhận – kiểm tra xem phần mềm có đáp ứng các yêu cầu kinh doanh hay không.

Điều quan trọng cần lưu ý là bạn không cần phải kiểm tra tất cả chúng, vì một số ít trong số chúng có thể đã được mô tả trong mã do nhà phát triển viết.

Công cụ tích hợp liên tục

Không cần tìm hiểu quá sâu, đây là những công cụ bạn có thể bắt đầu sử dụng trong dự án hiện tại hoặc dự án mới của mình;

  • Travis CI – được biết đến trong thế giới mã nguồn mở và hứa hẹn kiểm tra mã dễ dàng trong vài phút.
  • Bánh xe CI – Cung cấp sức mạnh, tính linh hoạt và khả năng kiểm soát để tự động hóa quy trình từ kiểm tra đến thực hiện.
  • Jenkins – cung cấp hàng trăm plugin để hỗ trợ xây dựng, triển khai và tự động hóa bất kỳ dự án nào.

Nếu bạn chưa quen với Jenkins, tôi khuyên bạn nên tham gia khóa học Udemy này để học CI với Java và .NET.

Triển khai liên tục

Sẽ tốt biết bao nếu chức năng bạn xây dựng nằm trong kho lưu trữ hàng tuần hoặc hàng tháng trước khi nó được triển khai vào sản xuất. Mặc dù các nhóm kỹ thuật có thể tích hợp các thay đổi nhỏ vào nhánh chính như hiện tại, nhưng họ cũng có thể đưa những thay đổi đó vào môi trường sản xuất càng sớm càng tốt.

Mục tiêu của bài tập Triển khai liên tục là đẩy các thay đổi của bạn tới người dùng ngay khi các nhà phát triển tích hợp những thay đổi đó vào nhánh chính.

Tương tự như tích hợp liên tục, khi sử dụng triển khai liên tục, các thử nghiệm và kiểm tra tự động được thực hiện để đảm bảo các thay đổi mới được tích hợp được xác thực. Việc triển khai chỉ diễn ra khi các bài kiểm tra này vượt qua.

Để một nhóm được hưởng lợi từ việc thực hành liên tục, những điều sau đây phải được thực hiện;

  • Kiểm thử tự động là nền tảng của tất cả các thực hành kỹ thuật. Với việc triển khai liên tục, mã được triển khai phải tuân theo tiêu chuẩn mà nhóm đã đặt ra cho những gì nhóm dự định cung cấp cho người dùng cuối. Lý tưởng nhất là nếu thay đổi mới nằm dưới ngưỡng, thử nghiệm sẽ không thành công và không được tích hợp. Nếu không, nó trở nên tích hợp.
  • Mặc dù chạy thử nghiệm tự động từng cái một, có thể một số lỗi sẽ rò rỉ vào môi trường sản xuất. Đối với điều này, nhóm cần có khả năng hoàn tác thay đổi được đưa ra – hoàn tác việc triển khai. Điều này sẽ đưa mã sản xuất trở lại trạng thái trước khi thay đổi mới được thực hiện.
  • Hệ thống giám sát là cần thiết để theo dõi những thay đổi đã được thực hiện đối với môi trường sản xuất. Bằng cách này, nhóm có thể theo dõi các lỗi mà người dùng gặp phải khi sử dụng các thay đổi đã triển khai.

Các công cụ tích hợp liên tục này cũng cung cấp chức năng để cấu hình một hệ thống triển khai liên tục. Có rất nhiều mà bạn có thể đọc về là tốt.

Đăng kí

Hiệu quả của nhóm phát triển là rất quan trọng đối với sự thành công của công ty. Để đảm bảo năng suất của họ, các thực hành khuyến khích nó phải được thông qua. Ví dụ về các thực hành như vậy là tích hợp và triển khai liên tục.

Với sự tích hợp liên tục, các nhóm có thể tải lên nhiều mã nhất có thể mỗi ngày. Điều này giúp dễ dàng triển khai các thay đổi mới được thêm cho người dùng nhanh nhất có thể. Việc triển khai những thay đổi này cho phép bạn nhận phản hồi từ người dùng của mình. Cuối cùng, công ty sẽ có thể đổi mới dựa trên phản hồi nhận được, đó là một chiến thắng đôi bên cùng có lợi.

Bạn cũng có thể tìm hiểu cách chia tỷ lệ và tối ưu hóa CI/CD.

Nếu bạn là một lập trình viên và muốn học CI/CD, hãy xem khóa học tuyệt vời này.

Thích bài viết? Làm thế nào về chia sẻ với thế giới?

Mục lục