Tại GitLab, chúng tôi xử lý các bản sửa lỗi phần mềm theo hai cách: thủ công và tự động. Đọc tiếp để tìm hiểu về công việc của người quản lý phát hành trong việc tạo và cung cấp các bản cập nhật quan trọng thông qua triển khai tự động tới gitlab.com, cũng như các bản vá để người dùng tự làm việc với bản cài đặt của họ.
Tôi khuyên bạn nên đặt lời nhắc trên đồng hồ thông minh của mình: vào ngày 22 hàng tháng, người dùng làm việc với GitLab tại cơ sở của họ có thể xem các bản cập nhật cho phiên bản hiện tại của sản phẩm của chúng tôi. Bản phát hành hàng tháng chứa các tính năng mới, sự phát triển của các tính năng hiện có và thường hiển thị kết quả cuối cùng của các yêu cầu của cộng đồng về công cụ hoặc hợp nhất.
Tuy nhiên, như thực tế cho thấy, việc phát triển phần mềm hiếm khi không có sai sót. Khi phát hiện ra lỗi hoặc lỗ hổng bảo mật, người quản lý phát hành trong nhóm phân phối sẽ tạo bản vá cho người dùng của chúng tôi cùng với các bản cài đặt của họ. Gitlab.com được cập nhật trong quá trình CD. Chúng tôi gọi đây là quá trình triển khai tự động CD để tránh nhầm lẫn với tính năng CD trong GitLab. Quá trình này có thể kết hợp các đề xuất từ các yêu cầu kéo do người dùng, khách hàng và nhóm phát triển nội bộ của chúng tôi gửi, để việc giải quyết vấn đề nhàm chán khi phát hành bản vá được giải quyết theo hai cách rất khác nhau.
«Chúng tôi đảm bảo rằng mọi thứ mà nhà phát triển tạo ra đều được triển khai cho tất cả các môi trường hàng ngày trước khi triển khai trên GitLab.com", giải thích , Giám đốc kỹ thuật cấp cao, Phòng Cơ sở hạ tầng. "Hãy coi các bản phát hành cho bản cài đặt của bạn dưới dạng ảnh chụp nhanh cho quá trình triển khai gitlab.com. Chúng tôi đã thêm các bước riêng biệt để tạo gói để người dùng có thể sử dụng gói đó để cài đặt trên bản cài đặt của họ'.
Bất kể lỗi hay lỗ hổng bảo mật nào, khách hàng của gitlab.com sẽ nhận được các bản sửa lỗi ngay sau khi chúng được xuất bản, đây là một lợi ích của quy trình CD tự động. Các bản vá dành cho người dùng có bản cài đặt riêng của họ yêu cầu người quản lý phát hành phải chuẩn bị riêng.
Nhóm phân phối đang nỗ lực tự động hóa hầu hết các quy trình liên quan đến việc tạo bản phát hành để giảm thiểu (thời gian trung bình cho đến khi sản xuất, tức là thời gian dành cho sản xuất), khoảng thời gian từ khi xử lý yêu cầu hợp nhất của nhà phát triển đến khi triển khai trên gitlab.com.
«Mục tiêu của đội giao hàng là đảm bảo rằng chúng ta có thể phát triển nhanh hơn với tư cách là một công ty, hoặc ít nhất là khiến những người giao hàng làm việc nhanh hơn, đúng không??, Marin nói.
Cả khách hàng gitlab.com và người dùng cài đặt của họ đều được hưởng lợi từ nỗ lực của nhóm phân phối nhằm giảm thời gian chu kỳ và tăng tốc độ triển khai. Trong bài viết này, chúng tôi sẽ giải thích những điểm tương đồng và khác biệt giữa hai phương pháp này. và chúng tôi cũng sẽ mô tả cách nhóm phân phối của chúng tôi chuẩn bị các bản vá cho người dùng làm việc tại cơ sở của họ cũng như cách chúng tôi đảm bảo rằng gitlab.com được cập nhật bằng cách triển khai tự động.
Người quản lý phát hành làm gì?
Thành viên nhóm hàng tháng các bản phát hành của chúng tôi tới người dùng tại cơ sở của họ, bao gồm các bản vá và bản phát hành bảo mật có thể xảy ra giữa các bản phát hành. Họ cũng chịu trách nhiệm lãnh đạo quá trình chuyển đổi của công ty sang triển khai tự động, liên tục.
Marin giải thích, các bản phát hành tự cài đặt và bản phát hành gitlab.com sử dụng quy trình công việc tương tự nhưng chạy vào những thời điểm khác nhau.
Đầu tiên và quan trọng nhất, người quản lý phát hành, bất kể loại phát hành, đều đảm bảo rằng GitLab luôn sẵn có và an toàn kể từ thời điểm ứng dụng được khởi chạy trên gitlab.com, bao gồm cả việc đảm bảo rằng các vấn đề tương tự không xảy ra trong cơ sở hạ tầng của khách hàng với của họ. năng lực của bản thân.
Sau khi một lỗi hoặc lỗ hổng bảo mật được đánh dấu là đã sửa trong GitLab, người quản lý phát hành phải đánh giá xem liệu lỗi hoặc lỗ hổng đó có được đưa vào các bản vá hoặc bản cập nhật bảo mật cho người dùng trong quá trình cài đặt của họ hay không. Nếu anh ta quyết định rằng một lỗi hoặc lỗ hổng bảo mật xứng đáng được cập nhật thì công việc chuẩn bị sẽ bắt đầu.
Người quản lý phát hành phải quyết định xem có nên chuẩn bị bản sửa lỗi hay khi nào triển khai nó - và điều này phụ thuộc nhiều vào bối cảnh của tình huống, "trong khi đó, máy móc lại không giỏi quản lý bối cảnh như con người" Marin nói.
Đó là tất cả về các bản sửa lỗi
Bản vá là gì và tại sao chúng ta cần chúng?
Người quản lý phát hành quyết định có phát hành bản sửa lỗi hay không dựa trên mức độ nghiêm trọng của lỗi.
Lỗi khác nhau tùy thuộc vào mức độ nghiêm trọng của họ. Vì vậy, lỗi S4 hoặc S3 có thể mang tính phong cách, chẳng hạn như dịch chuyển pixel hoặc biểu tượng. Điều này không kém phần quan trọng nhưng không có tác động đáng kể đến quy trình làm việc của bất kỳ ai, điều đó có nghĩa là khả năng tạo ra bản sửa lỗi cho các lỗi S3 hoặc S4 như vậy là rất nhỏ, Marin giải thích.
Tuy nhiên, lỗ hổng S1 hoặc S2 có nghĩa là người dùng không nên cập nhật lên phiên bản mới nhất hoặc có lỗi nghiêm trọng ảnh hưởng đến quy trình làm việc của người dùng. Nếu chúng được đưa vào trình theo dõi, nhiều người dùng đã gặp phải chúng, vì vậy người quản lý phát hành ngay lập tức bắt đầu chuẩn bị bản sửa lỗi.
Khi bản vá cho lỗ hổng S1 hoặc S2 đã sẵn sàng, người quản lý phát hành sẽ bắt đầu phát hành bản vá.
Ví dụ: bản vá GitLab 12.10.1 đã được tạo sau khi xác định được một số sự cố chặn và các nhà phát triển đã khắc phục sự cố cơ bản gây ra chúng. Người quản lý bản phát hành đã đánh giá tính chính xác của mức độ nghiêm trọng được chỉ định và sau khi xác nhận, quy trình phát hành bản sửa lỗi đã được khởi chạy, bản sửa lỗi này sẵn sàng trong vòng XNUMX giờ sau khi phát hiện ra sự cố chặn.
Khi tích lũy nhiều S4, S3 và S2, người quản lý phát hành sẽ xem xét bối cảnh để xác định mức độ khẩn cấp của việc phát hành bản sửa lỗi và khi đạt đến một số lượng nhất định, tất cả chúng đều được kết hợp và phát hành. Các bản sửa lỗi sau phát hành hoặc cập nhật bảo mật được tóm tắt trong các bài đăng trên blog.
Cách người quản lý phát hành tạo các bản vá
Chúng tôi sử dụng GitLab CI và các tính năng khác như ChatOps để tạo các bản vá. Người quản lý bản phát hành bắt đầu phát hành bản sửa lỗi bằng cách kích hoạt nhóm ChatOps trên kênh nội bộ của chúng tôi #releases ở Slack.
/chatops run release prepare 12.10.1ChatOps hoạt động trong Slack để kích hoạt các sự kiện khác nhau, sau đó được GitLab xử lý và thực thi. Ví dụ: nhóm phân phối đã thiết lập ChatOps để tự động hóa nhiều thứ khác nhau nhằm phát hành bản vá.
Sau khi người quản lý phát hành khởi động nhóm ChatOps trong Slack, phần còn lại của công việc sẽ tự động diễn ra trong GitLab bằng CICD. Có sự liên lạc hai chiều giữa ChatOps trong Slack và GitLab trong quá trình phát hành khi người quản lý phát hành kích hoạt một số bước chính trong quy trình.
Video bên dưới trình bày quy trình kỹ thuật chuẩn bị bản vá cho GitLab.
Cách triển khai tự động hoạt động trên gitlab.com
Quy trình và công cụ được sử dụng để cập nhật gitlab.com tương tự như quy trình và công cụ được sử dụng để tạo bản vá. Theo quan điểm của người quản lý phát hành, việc cập nhật gitlab.com yêu cầu ít công việc thủ công hơn.
Thay vì triển khai bằng ChatOps, chúng tôi sử dụng các tính năng CI, ví dụ: , nhờ đó người quản lý phát hành có thể lên lịch thực hiện một số hành động nhất định vào thời điểm cần thiết. Thay vì quy trình thủ công, có một quy trình chạy định kỳ mỗi giờ một lần để tải xuống các thay đổi mới được thực hiện cho các dự án GitLab, đóng gói chúng và lên lịch triển khai, đồng thời tự động chạy thử nghiệm, QA và các bước cần thiết khác.
Marin cho biết: “Vì vậy, chúng tôi có rất nhiều hoạt động triển khai chạy trong các môi trường khác nhau trước gitlab.com và sau khi các môi trường đó ở trạng thái tốt và quá trình thử nghiệm cho thấy kết quả tốt, người quản lý phát hành sẽ bắt đầu các hành động triển khai gitlab.com”.
Công nghệ CICD để hỗ trợ các bản cập nhật gitlab.com tự động hóa toàn bộ quy trình đến mức người quản lý phát hành phải khởi chạy thủ công quá trình triển khai môi trường sản xuất lên gitlab.com.
Marin trình bày chi tiết về quy trình cập nhật gitlab.com trong video bên dưới.
Đội ngũ giao hàng còn làm gì nữa?
Sự khác biệt chính giữa quy trình cập nhật gitlab.com và phát hành bản vá cho khách hàng nội bộ là quy trình sau đòi hỏi nhiều thời gian hơn và nhiều công việc thủ công hơn từ người quản lý phát hành.
Marin cho biết: “Đôi khi chúng tôi trì hoãn việc phát hành các bản vá cho khách hàng cùng với các bản cài đặt của họ do các sự cố được báo cáo, các vấn đề về công cụ và vì có nhiều sắc thái cần được tính đến khi phát hành một bản vá duy nhất”.
Một trong những mục tiêu ngắn hạn của nhóm phân phối là giảm lượng công việc thủ công của người quản lý phát hành để tăng tốc độ phát hành. Nhóm đang nỗ lực đơn giản hóa, hợp lý hóa và tự động hóa quy trình phát hành, điều này sẽ giúp khắc phục các sự cố có mức độ nghiêm trọng thấp (S3 và S4, khoảng người phiên dịch). Tập trung vào tốc độ là một chỉ số hiệu suất chính: cần giảm MTTP - thời gian từ khi nhận được yêu cầu hợp nhất đến khi triển khai kết quả lên gitlab.com - từ 50 giờ hiện tại xuống còn 8 giờ.
Nhóm phân phối cũng đang nỗ lực di chuyển gitlab.com sang cơ sở hạ tầng dựa trên Kubernetes.
NB của biên tập viên: Nếu bạn đã nghe nói về công nghệ Kubernetes (và tôi tin chắc là bạn đã biết), nhưng chưa tận tay chạm vào nó, tôi khuyên bạn nên tham gia các khóa học chuyên sâu trực tuyến , sẽ diễn ra từ ngày 28 đến ngày 30 tháng XNUMX và , sẽ diễn ra từ ngày 14 đến ngày 16 tháng XNUMX. Điều này sẽ cho phép bạn tự tin điều hướng và làm việc với công nghệ.
Đây là hai cách tiếp cận theo đuổi cùng một mục tiêu: cung cấp nhanh chóng các bản cập nhật, cho cả gitlab.com và cho khách hàng tại cơ sở của họ.
Bất kỳ ý tưởng hoặc khuyến nghị cho chúng tôi?
Mọi người đều được hoan nghênh đóng góp cho GitLab và chúng tôi hoan nghênh phản hồi từ độc giả. Nếu bạn có bất kỳ ý tưởng nào cho đội ngũ giao hàng của chúng tôi, đừng ngần ngại với thông báo team: Delivery.
Nguồn: www.habr.com