Đưa bản phát hành dự án mới vào sản xuất đòi hỏi sự cân bằng cẩn thận giữa tốc độ triển khai và độ tin cậy của giải pháp. Slack coi trọng việc lặp lại nhanh, chu kỳ phản hồi ngắn và phản hồi nhanh chóng các yêu cầu của người dùng. Ngoài ra, công ty còn có hàng trăm lập trình viên luôn cố gắng làm việc hiệu quả nhất có thể.
Các tác giả của tài liệu, bản dịch mà chúng tôi xuất bản ngày hôm nay, nói rằng một công ty cố gắng tuân thủ các giá trị đó đồng thời phát triển phải không ngừng cải tiến hệ thống triển khai dự án của mình. Công ty cần đầu tư vào tính minh bạch và độ tin cậy của các quy trình làm việc, làm điều này để đảm bảo rằng các quy trình này tương ứng với quy mô của dự án. Ở đây chúng ta sẽ nói về các quy trình công việc đã phát triển trong Slack và về một số quyết định đã khiến công ty sử dụng hệ thống triển khai dự án hiện có.
Quy trình triển khai dự án hoạt động như thế nào hiện nay
Mỗi PR (yêu cầu kéo) trong Slack phải được xem xét mã và phải vượt qua tất cả các bài kiểm tra thành công. Chỉ sau khi đáp ứng được những điều kiện này, lập trình viên mới có thể hợp nhất mã của mình vào nhánh chính của dự án. Tuy nhiên, mã này chỉ được triển khai trong giờ làm việc, giờ Bắc Mỹ. Do đó, do nhân viên của chúng tôi đang ở nơi làm việc nên chúng tôi sẵn sàng giải quyết mọi vấn đề bất ngờ.
Mỗi ngày chúng tôi thực hiện khoảng 12 đợt triển khai theo kế hoạch. Trong mỗi lần triển khai, lập trình viên được chỉ định làm trưởng nhóm triển khai sẽ chịu trách nhiệm đưa bản dựng mới vào sản xuất. Đây là một quy trình gồm nhiều bước đảm bảo việc lắp ráp được đưa vào sản xuất một cách suôn sẻ. Nhờ phương pháp này, chúng tôi có thể phát hiện lỗi trước khi chúng ảnh hưởng đến tất cả người dùng của chúng tôi. Nếu có quá nhiều lỗi, quá trình triển khai hội có thể bị lùi lại. Nếu một vấn đề cụ thể được phát hiện sau khi phát hành, bản sửa lỗi có thể dễ dàng được đưa ra cho vấn đề đó.
Giao diện của hệ thống Checkpoint được sử dụng trong Slack để triển khai dự án
Quá trình triển khai một bản phát hành mới vào sản xuất có thể được coi là bao gồm bốn bước.
▍1. Tạo một nhánh phát hành
Mỗi bản phát hành bắt đầu bằng một nhánh phát hành mới, một điểm trong lịch sử Git của chúng tôi. Điều này cho phép bạn gán thẻ cho bản phát hành và cung cấp nơi bạn có thể thực hiện các bản sửa lỗi trực tiếp cho các lỗi được tìm thấy trong quá trình chuẩn bị bản phát hành để phát hành chính thức.
▍2. Triển khai trong môi trường dàn dựng
Bước tiếp theo là triển khai việc lắp ráp trên các máy chủ chạy thử và chạy thử nghiệm tự động về hiệu suất tổng thể của dự án (thử nghiệm khói). Môi trường dàn dựng là môi trường sản xuất không nhận được lưu lượng truy cập bên ngoài. Trong môi trường này, chúng tôi thực hiện kiểm tra thủ công bổ sung. Điều này giúp chúng tôi có thêm niềm tin rằng dự án đã sửa đổi hoạt động chính xác. Chỉ kiểm tra tự động là không đủ để cung cấp mức độ tin cậy này.
▍3. Triển khai trong môi trường dogfood và canary
Quá trình triển khai vào sản xuất bắt đầu bằng môi trường dogfood, được biểu thị bằng một nhóm máy chủ phục vụ không gian làm việc nội bộ của Slack của chúng tôi. Vì chúng tôi là những người dùng Slack rất tích cực nên việc áp dụng phương pháp này đã giúp chúng tôi sớm phát hiện được nhiều lỗi trong quá trình triển khai. Sau khi chúng tôi đảm bảo rằng chức năng cơ bản của hệ thống không bị hỏng, quá trình lắp ráp sẽ được triển khai trong môi trường canary. Nó đại diện cho các hệ thống chiếm khoảng 2% lưu lượng sản xuất.
▍4. Đưa dần vào sản xuất
Nếu các chỉ số giám sát đối với bản phát hành mới ổn định và nếu sau khi triển khai dự án trong môi trường canary mà chúng tôi không nhận được bất kỳ khiếu nại nào, chúng tôi sẽ tiếp tục chuyển dần các máy chủ sản xuất sang bản phát hành mới. Quá trình triển khai được chia thành các giai đoạn sau: 10%, 25%, 50%, 75% và 100%. Do đó, chúng tôi có thể từ từ chuyển lưu lượng sản xuất sang bản phát hành mới của hệ thống. Đồng thời, chúng tôi có thời gian để điều tra tình hình nếu phát hiện bất thường.
▍Nếu có sự cố xảy ra trong quá trình triển khai thì sao?
Việc sửa đổi mã luôn là một rủi ro. Nhưng chúng tôi giải quyết được điều này nhờ sự hiện diện của các “lãnh đạo triển khai” được đào tạo bài bản, những người quản lý quá trình đưa bản phát hành mới vào sản xuất, giám sát các chỉ số giám sát và điều phối công việc của các lập trình viên phát hành mã.
Trong trường hợp có sự cố thực sự xảy ra, chúng tôi cố gắng phát hiện sự cố càng sớm càng tốt. Chúng tôi điều tra sự cố, tìm ra PR gây ra lỗi, khôi phục, phân tích kỹ lưỡng và tạo bản dựng mới. Đúng, đôi khi vấn đề không được chú ý cho đến khi dự án đi vào sản xuất. Trong tình huống như vậy, điều quan trọng nhất là khôi phục dịch vụ. Do đó, trước khi bắt đầu điều tra sự cố, chúng tôi ngay lập tức quay lại bản dựng hoạt động trước đó.
Các khối xây dựng của một hệ thống triển khai
Hãy xem xét các công nghệ làm nền tảng cho hệ thống triển khai dự án của chúng tôi.
▍Triển khai nhanh chóng
Nhìn lại, quy trình làm việc được mô tả ở trên có vẻ hơi rõ ràng. Nhưng hệ thống triển khai của chúng tôi không trở nên như vậy ngay lập tức.
Khi công ty còn nhỏ hơn nhiều, toàn bộ ứng dụng của chúng tôi có thể chạy trên 10 phiên bản Amazon EC2. Triển khai dự án trong tình huống này có nghĩa là sử dụng rsync để đồng bộ hóa nhanh chóng tất cả các máy chủ. Trước đây, mã mới chỉ còn một bước nữa là đến giai đoạn sản xuất, được thể hiện bằng môi trường chạy thử. Các tổ hợp được tạo và thử nghiệm trong môi trường như vậy, sau đó được đưa thẳng vào sản xuất. Rất dễ hiểu một hệ thống như vậy; nó cho phép bất kỳ lập trình viên nào triển khai mã mà anh ta đã viết bất cứ lúc nào.
Nhưng khi số lượng khách hàng của chúng tôi tăng lên, quy mô cơ sở hạ tầng cần thiết để hỗ trợ dự án cũng tăng theo. Chẳng bao lâu sau, với sự phát triển không ngừng của hệ thống, mô hình triển khai của chúng tôi, dựa trên việc đẩy mã mới đến máy chủ, đã không còn hoạt động được nữa. Cụ thể, việc thêm mỗi máy chủ mới đồng nghĩa với việc tăng thời gian cần thiết để hoàn thành quá trình triển khai. Ngay cả các chiến lược dựa trên việc sử dụng rsync song song cũng có những hạn chế nhất định.
Cuối cùng, chúng tôi đã giải quyết được vấn đề này bằng cách chuyển sang một hệ thống triển khai hoàn toàn song song, được thiết kế khác với hệ thống cũ. Cụ thể là hiện tại chúng tôi không gửi mã đến máy chủ bằng tập lệnh đồng bộ hóa. Bây giờ, mỗi máy chủ đã tải xuống bản hợp ngữ mới một cách độc lập, biết rằng nó cần phải làm như vậy bằng cách theo dõi sự thay đổi khóa Lãnh sự. Các máy chủ tải mã song song. Điều này cho phép chúng tôi duy trì tốc độ triển khai cao ngay cả trong môi trường hệ thống tăng trưởng liên tục.
1. Máy chủ sản xuất giám sát khóa Lãnh sự. 2. Khóa thay đổi, điều này cho máy chủ biết rằng họ cần bắt đầu tải xuống mã mới. 3. Máy chủ tải file tarball có mã ứng dụng
▍Triển khai nguyên tử
Một giải pháp khác giúp chúng tôi đạt được hệ thống triển khai nhiều tầng là triển khai nguyên tử.
Trước khi sử dụng triển khai nguyên tử, mỗi lần triển khai có thể dẫn đến một số lượng lớn thông báo lỗi. Thực tế là quá trình sao chép các tệp mới vào máy chủ sản xuất không hề đơn giản. Điều này dẫn đến một khoảng thời gian ngắn mà mã gọi là hàm mới đã có sẵn trước khi bản thân các hàm đó có sẵn. Khi mã như vậy được gọi, nó sẽ dẫn đến lỗi nội bộ được trả về. Điều này thể hiện ở các yêu cầu API không thành công và các trang web bị hỏng.
Nhóm giải quyết vấn đề này đã giải quyết nó bằng cách đưa ra khái niệm về thư mục “nóng” và “lạnh”. Mã trong thư mục nóng chịu trách nhiệm xử lý lưu lượng sản xuất. Và trong các thư mục “lạnh”, mã, trong khi hệ thống đang chạy, chỉ được chuẩn bị để sử dụng. Trong quá trình triển khai, mã mới sẽ được sao chép vào một thư mục lạnh chưa được sử dụng. Sau đó, khi không có tiến trình nào đang hoạt động trên máy chủ, việc chuyển đổi thư mục tức thời sẽ được thực hiện.
1. Giải nén mã ứng dụng vào một thư mục “lạnh”. 2. Chuyển hệ thống sang thư mục “lạnh”, thư mục này trở nên “nóng” (hoạt động nguyên tử)
Kết quả: chuyển trọng tâm sang độ tin cậy
Vào năm 2018, dự án đã phát triển đến mức việc triển khai quá nhanh bắt đầu gây tổn hại đến tính ổn định của sản phẩm. Chúng tôi có một hệ thống triển khai rất tiên tiến mà chúng tôi đã đầu tư rất nhiều thời gian và công sức vào đó. Tất cả những gì chúng tôi cần làm là xây dựng lại và cải thiện quy trình triển khai của mình. Chúng tôi đã phát triển thành một công ty khá lớn, những phát triển của công ty đã được sử dụng trên toàn thế giới để tổ chức liên lạc không bị gián đoạn và giải quyết các vấn đề quan trọng. Vì vậy, độ tin cậy đã trở thành trọng tâm chú ý của chúng tôi.
Chúng tôi cần làm cho quá trình triển khai các bản phát hành Slack mới trở nên an toàn hơn. Nhu cầu này đã khiến chúng tôi phải cải thiện hệ thống triển khai của mình. Trên thực tế, chúng tôi đã thảo luận về hệ thống cải tiến này ở trên. Trong chiều sâu của hệ thống, chúng tôi tiếp tục sử dụng các công nghệ triển khai nhanh và nguyên tử. Cách triển khai được thực hiện đã thay đổi. Hệ thống mới của chúng tôi được thiết kế để triển khai dần dần mã mới ở các cấp độ khác nhau, trong các môi trường khác nhau. Hiện tại chúng tôi sử dụng các công cụ hỗ trợ và công cụ giám sát hệ thống tiên tiến hơn trước. Điều này mang lại cho chúng tôi khả năng phát hiện và sửa lỗi từ rất lâu trước khi chúng có cơ hội đến tay người dùng cuối.
Nhưng chúng tôi sẽ không dừng lại ở đó. Chúng tôi không ngừng cải tiến hệ thống này, sử dụng các công cụ phụ trợ và công cụ tự động hóa công việc tiên tiến hơn.
Gởi bạn đọc! Quá trình triển khai các bản phát hành dự án mới ở nơi bạn làm việc diễn ra như thế nào?
Nguồn: www.habr.com