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

Nghe CI / CD nhưng không chắc 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 chuyển đến môi trường sản xuất để doanh nghiệp có nhu cầu sử dụng sản phẩm có thể sử dụng nó. Để đáp ứng doanh nghiệp (thường được gọi là người dùng / khách hàng), điều cần thiết là các sản phẩm không có lỗi.

Cách tiếp cận điển hình được theo sau bởi các kỹ sư phần mềm là làm việc trong các nhánh và tạo một 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 thực hành viết bài kiểm tra như một phương tiện để đả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 làm việc trên một tính năng trong hầu hết các trường hợp, họ thường không tạo yêu cầu kéo cho đến khi hoàn thành với tính năng này. Điều gì xảy ra khi họ sẵn sàng là vậy;

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

Nếu bạn đã từng ở trong tình huống này, bạn sẽ đồng ý rằng đó có thể là một nỗi đau – không ai sẵn sàng dành ngày làm việc của họ như thế này.

Giải pháp gì?

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

https://www.youtube.com/watch?v=HnWuIjUw_Q8

Để ngăn chặn các kịch bản tôi đã nêu ở trên; đội kỹ thuật có thể áp dụng thực hành được gọi là hội nhập liên tục – như tên cho thấy, nó liên quan đến việc tích hợp liên tục các thay đổi mã được thực hiện bởi các nhà phát triển vào nhánh / kho lưu trữ được chia sẻ. Mã được tích hợp phải trải qua một thử nghiệm được xác minh để đảm bảo nó không phá vỡ ứng dụng. Chỉ khi bài kiểm tra vượt qua, nó mới được tích hợp

Để hiểu điều này, chúng ta hãy tưởng tượng một kịch bản thực tế trong đó có một nhóm gồm 10 nhà phát triển. Các nhà phát triển này tạo ra một nhánh cục bộ trong đó họ viết mã để thực hiện các tính năng nhất định. Thay vì gửi yêu cầu kéo khi chúng hoàn toàn được thực hiện với tính năng, họ chọn gửi yêu cầu kéo khi họ thực hiện một số thay đổi nhỏ. Một ví dụ về sự thay đổi như vậy sẽ là việc tạo ra một phương thức mới, giả sử nhà phát triển đang làm việc trên một tính 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ì chờ đợi cho đến khi tính năng nhiệm vụ hoàn thành, để tuân thủ mô hình tích hợp liên tục, nhà phát triển đẩy thay đổi nhỏ này (khi so sánh với những gì cô ấy đang làm) và tạo một yêu cầu kéo để hợp nhất với mã.

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

Đội ngũ kỹ thuật phần mềm sử dụng các công cụ như Travis CI để tạo ra các quá trình tích hợp và kiểm tra. Với các công cụ như thế này, các thử nghiệm được tự động hóa, sao cho nó chạy ngay khi yêu cầu kéo được gửi đến nhánh đích được chọn trong quá trình thiết lập.

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

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

Điều quan trọng cần lưu ý trong thực tiễn này là nó khuyến khích nhóm đẩy mã đến nhánh chính thường xuyên. Làm đ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 rút khỏi nhánh chính để cập nhật kho lưu trữ cục bộ của họ.

Các loại xét nghiệm

Trong các bài kiểm tra viết sẽ là một phần của quá trình tích hợp, đây là một số bài có thể được thực hiện trong quy trình:

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

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

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

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

  • Travis CI – được biết đến trong thế giới nguồn mở và hứa với bạn rằng mã của bạn sẽ được kiểm tra liền mạch trong vài phút.
  • Vòng tròn CI – cung cấp cho bạn sức mạnh, tính linh hoạt và kiểm soát để tự động hóa đường ống của bạn từ kiểm soát đến triển khai.
  • 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 thì tôi khuyên bạn nên dùng cái này Khóa học của kẻ thù để học CI với Java và .NET.

Triển khai liên tục

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

Mục tiêu khi thực hành triển khai liên tục là để có được những thay đổi được thực hiện cho người dùng ngay khi các nhà phát triển tích hợp những thay đổi này trong nhánh chính.

Giống như trong trường hợp tích hợp liên tục, khi sử dụng triển khai liên tục, kiểm tra và kiểm tra tự động được thiết lập để đảm bảo rằng các thay đổi tích hợp mới được xác minh. Việc triển khai chỉ xảy ra khi các thử nghiệm này vượt qua.

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

  • Kiểm tra tự động là xương sống thiết yếu của tất cả các thực hành kỹ thuật liên tục. Trong trường hợp triển khai liên tục, mã được triển khai phải đáp ứng với tiêu chuẩn mà nhóm đã đưa ra cho những gì họ dự định đưa ra cho người dùng cuối. Lý tưởng nhất, nếu một thay đổi mới nằm dưới ngưỡng, thử nghiệm sẽ thất bại và không được tích hợp. Khác, nó trở nên tích hợp.
  • Mặc dù đã tự động kiểm tra back-to-back, nhưng có thể một số lỗi sẽ lọt vào môi trường sản xuất. Đối với điều này, điều cần thiết là nhóm có thể hoàn tác một thay đổi đã được thực hiện – hoàn tác một triển khai. Điều này sẽ hoàn nguyên mã sản xuất về 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 các thay đổi đã được đẩy vào môi trường sản xuất. Đây là cách 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ụ được đề cập để tích hợp liên tục cũng cung cấp cho bạn chức năng để thiết lập một hệ thống triển khai liên tục. Có rất nhiều trong số đó bạn cũng có thể đọc lên.

Phần kết luận

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

Với sự tích hợp liên tục, các đội có thể đẩy càng nhiều mã càng tốt hàng ngày. Với điều này đạt được, việc triển khai các thay đổi mới được thêm vào người dùng càng sớm càng tốt. Triển khai những thay đổi này giúp có được phản hồi từ người dùng. Cuối cùng, doanh nghiệp sẽ có thể đổi mới dựa trên phản hồi nhận được, đây là một lợi ích cho tất cả mọi người.

Nếu bạn là nhà phát triển và thích học CI / CD, thì hãy xem cái này khóa học tuyệt vời.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map