Thực hành DevOps hoạt động. Bản thân chúng tôi đã bị thuyết phục về điều này khi giảm thời gian cài đặt bản phát hành xuống 10 lần. Trong hệ thống Hồ sơ FIS mà chúng tôi sử dụng tại VTB, quá trình cài đặt hiện chỉ mất 90 phút thay vì 10. Thời gian xây dựng bản phát hành đã giảm từ hai tuần xuống còn hai ngày. Số lượng lỗi triển khai dai dẳng đã giảm xuống gần như ở mức tối thiểu. Để thoát khỏi “lao động chân tay” và loại bỏ sự phụ thuộc vào nhà cung cấp, chúng tôi đã phải làm việc bằng nạng và tìm ra những giải pháp bất ngờ. Dưới đây là câu chuyện chi tiết về cách chúng tôi xây dựng sự phát triển nội bộ toàn diện.
Mở đầu: DevOps là một triết lý
Trong năm qua, chúng tôi đã thực hiện rất nhiều công việc để tổ chức phát triển nội bộ và triển khai các hoạt động DevOps tại VTB:
- Chúng tôi đã xây dựng quy trình phát triển nội bộ cho 12 hệ thống;
- Chúng tôi đã đưa vào hoạt động 15 đường ống, XNUMX trong số đó đã được đưa vào sản xuất;
- Kịch bản thử nghiệm 1445 tự động;
- Chúng tôi đã triển khai thành công một số bản phát hành do nhóm nội bộ chuẩn bị.
Một trong những hệ thống tổ chức phát triển và triển khai DevSecOps nội bộ khó khăn nhất hóa ra lại là hệ thống Hồ sơ FIS - bộ xử lý sản phẩm bán lẻ trên DBMS không liên quan. Tuy nhiên, chúng tôi đã có thể xây dựng quá trình phát triển, khởi chạy quy trình, cài đặt các gói không phát hành riêng lẻ trên sản phẩm và học cách tập hợp các bản phát hành. Nhiệm vụ này không hề dễ dàng, nhưng thú vị và không có hạn chế rõ ràng trong việc thực hiện: đây là hệ thống - bạn cần xây dựng một quy trình phát triển nội bộ. Điều kiện duy nhất là sử dụng đĩa CD trước môi trường sản xuất.
Lúc đầu, thuật toán triển khai có vẻ đơn giản và rõ ràng:
- Chúng tôi phát triển chuyên môn phát triển ban đầu và đạt được mức chất lượng có thể chấp nhận được từ nhóm mã mà không có sai sót nghiêm trọng;
- Chúng tôi tích hợp vào các quy trình hiện có nhiều nhất có thể;
- Để chuyển mã giữa các giai đoạn rõ ràng, chúng tôi cắt một đường ống và đẩy một trong các đầu của nó vào phần tiếp theo.
Trong thời gian này, nhóm phát triển có quy mô được yêu cầu phải phát triển các kỹ năng và tăng tỷ lệ đóng góp của mình trong các bản phát hành lên mức chấp nhận được. Thế là xong, chúng ta có thể coi như nhiệm vụ đã hoàn thành.
Có vẻ như đây là con đường hoàn toàn tiết kiệm năng lượng để đạt được kết quả mong muốn: đây là DevOps, đây là số liệu hiệu suất của nhóm, đây là chuyên môn tích lũy... Nhưng trên thực tế, chúng tôi đã nhận được một xác nhận khác rằng DevOps vẫn là về triết học , và không “được gắn vào quy trình gitlab, ansible, nexus và các phần tiếp theo trong danh sách.”
Sau khi phân tích kế hoạch hành động một lần nữa, chúng tôi nhận ra rằng chúng tôi đang xây dựng một loại nhà cung cấp dịch vụ thuê ngoài bên trong mình. Do đó, việc tái cấu trúc quy trình đã được thêm vào thuật toán được mô tả ở trên, cũng như việc phát triển chuyên môn trong toàn bộ lộ trình phát triển để đạt được vai trò dẫn đầu trong quy trình này. Không phải là lựa chọn dễ dàng nhất, nhưng đây là con đường phát triển đúng đắn về mặt tư tưởng.
Phát triển nội bộ bắt đầu từ đâu?
Đó không phải là hệ thống thân thiện nhất để làm việc cùng. Về mặt kiến trúc, nó là một DBMS phi quan hệ lớn, bao gồm nhiều đối tượng thực thi riêng biệt (tập lệnh, thủ tục, lô, v.v.), được gọi khi cần và hoạt động theo nguyên tắc hộp đen: nó nhận được yêu cầu và phát hành một phản ứng. Những khó khăn khác đáng lưu ý bao gồm:
- Ngôn ngữ kỳ lạ (MUMPS);
- Giao diện điều khiển;
- Thiếu tích hợp với các công cụ và khuôn khổ tự động hóa phổ biến;
- Khối lượng dữ liệu tính bằng hàng chục terabyte;
- Tải trên 2 triệu hoạt động mỗi giờ;
- Ý nghĩa - Kinh doanh quan trọng.
Đồng thời, phía chúng tôi không có kho lưu trữ mã nguồn. Ở tất cả. Có tài liệu, nhưng tất cả kiến thức và năng lực chính đều thuộc về một tổ chức bên ngoài.
Chúng tôi bắt đầu nắm vững việc phát triển hệ thống gần như từ đầu, có tính đến các tính năng và khả năng phân phối thấp của nó. Bắt đầu vào tháng 2018 năm XNUMX:
- Nghiên cứu tài liệu và kiến thức cơ bản về tạo mã;
- Chúng tôi đã nghiên cứu khóa học ngắn hạn về phát triển nhận được từ nhà cung cấp;
- Nắm vững các kỹ năng phát triển ban đầu;
- Chúng tôi đã biên soạn sổ tay đào tạo cho các thành viên mới trong nhóm;
- Chúng tôi đồng ý đưa đội vào chế độ “chiến đấu”;
- Đã giải quyết vấn đề về kiểm soát chất lượng mã;
- Chúng tôi đã tổ chức một lập trường để phát triển.
Chúng tôi đã dành ba tháng để phát triển kiến thức chuyên môn và hòa mình vào hệ thống, và từ đầu năm 2019, hoạt động phát triển nội bộ đã bắt đầu hướng tới một tương lai tươi sáng, đôi khi gặp khó khăn nhưng đầy tự tin và có mục đích.
Di chuyển kho lưu trữ và tự động kiểm tra
Nhiệm vụ DevOps đầu tiên là kho lưu trữ. Chúng tôi nhanh chóng đồng ý về việc cung cấp quyền truy cập, nhưng cần phải di chuyển từ SVN hiện tại với một nhánh trung kế sang Git mục tiêu của chúng tôi cùng với việc chuyển đổi sang mô hình gồm một số nhánh và phát triển Git Flow. Chúng tôi cũng có 2 đội có cơ sở hạ tầng riêng và một phần đội ngũ của nhà cung cấp ở nước ngoài. Tôi phải sống với hai Git và đảm bảo đồng bộ hóa. Trong tình huống như vậy, đó là cái ít tệ hơn trong hai tệ nạn.
Việc di chuyển kho lưu trữ đã nhiều lần bị trì hoãn, nó chỉ được hoàn thành vào tháng XNUMX với sự giúp đỡ của các đồng nghiệp ở tuyến đầu. Với Git Flow, chúng tôi quyết định giữ mọi thứ đơn giản ngay từ đầu và giải quyết theo sơ đồ cổ điển với hotfix, phát triển và phát hành. Họ quyết định từ bỏ chủ nhân (hay còn gọi là prod-like). Dưới đây chúng tôi sẽ giải thích lý do tại sao tùy chọn này hóa ra lại tối ưu cho chúng tôi. Một kho lưu trữ bên ngoài thuộc về nhà cung cấp, dùng chung cho hai nhóm, được sử dụng làm công nhân. Nó được đồng bộ hóa với kho lưu trữ nội bộ theo lịch trình. Giờ đây với Git và Gitlab, chúng ta có thể tự động hóa các quy trình.
Vấn đề về kiểm tra tự động đã được giải quyết dễ dàng một cách đáng ngạc nhiên - chúng tôi đã được cung cấp một khuôn khổ làm sẵn. Có tính đến đặc thù của hệ thống, việc gọi một hoạt động riêng biệt là một phần dễ hiểu của quy trình kinh doanh, đồng thời được dùng như một bài kiểm tra đơn vị. Tất cả những gì còn lại là chuẩn bị dữ liệu thử nghiệm và đặt thứ tự mong muốn để gọi các tập lệnh và đánh giá kết quả. Khi danh sách các kịch bản được hình thành trên cơ sở thống kê hoạt động, mức độ quan trọng của các quy trình và phương pháp hồi quy hiện có được điền đầy đủ, các thử nghiệm tự động bắt đầu xuất hiện. Bây giờ chúng ta có thể bắt đầu xây dựng đường ống.
Nó như thế nào: mô hình trước khi tự động hóa
Mô hình hiện tại của quá trình thực hiện là một câu chuyện riêng biệt. Mỗi sửa đổi được chuyển thủ công dưới dạng gói cài đặt gia tăng riêng biệt. Tiếp theo là đăng ký thủ công trong Jira và cài đặt thủ công trên môi trường. Đối với các gói riêng lẻ, mọi thứ đều có vẻ rõ ràng, nhưng với việc chuẩn bị phát hành, mọi thứ trở nên phức tạp hơn.
Việc lắp ráp được thực hiện ở cấp độ giao hàng riêng lẻ, là những đối tượng độc lập. Mọi thay đổi đều là giao hàng mới. Trong số những thứ khác, 60–70 phiên bản kỹ thuật đã được thêm vào gói 10-15 của thành phần phát hành chính - các phiên bản có được khi thêm hoặc loại trừ nội dung nào đó khỏi bản phát hành và phản ánh những thay đổi về doanh số bán hàng bên ngoài bản phát hành.
Các đối tượng trong quá trình phân phối chồng chéo với nhau, đặc biệt là trong mã thực thi, mã này có ít hơn một nửa duy nhất. Có nhiều sự phụ thuộc vào cả mã đã được cài đặt và mã vừa được lên kế hoạch cài đặt.
Để có được phiên bản mã yêu cầu, cần phải tuân thủ nghiêm ngặt trình tự cài đặt, trong đó các đối tượng được viết lại về mặt vật lý nhiều lần, khoảng 10–12 lần.
Sau khi cài đặt một loạt gói, tôi phải làm theo hướng dẫn thủ công để khởi tạo cài đặt. Bản phát hành được lắp ráp và cài đặt bởi nhà cung cấp. Thành phần của bản phát hành đã được làm rõ gần như trước thời điểm triển khai, kéo theo việc tạo ra các gói “tách rời”. Kết quả là, một phần đáng kể của nguồn cung cấp đã chuyển từ bản phát hành này sang bản phát hành khác với cái đuôi "tách rời" riêng của nó.
Bây giờ rõ ràng là với cách tiếp cận này - tập hợp câu đố phát hành ở cấp độ gói - một nhánh chính duy nhất không có ý nghĩa thực tế. Việc lắp đặt trên sản xuất mất từ một tiếng rưỡi đến hai giờ lao động thủ công. Điều tốt là ít nhất ở cấp độ trình cài đặt, thứ tự xử lý đối tượng đã được chỉ định: các trường và cấu trúc được nhập trước dữ liệu và quy trình cho chúng. Tuy nhiên, điều này chỉ hoạt động trong một gói riêng biệt.
Kết quả hợp lý của phương pháp này là các lỗi cài đặt bắt buộc ở dạng phiên bản sai lệch của đối tượng, mã không cần thiết, thiếu hướng dẫn và không tính đến ảnh hưởng lẫn nhau của các đối tượng, đã bị loại bỏ một cách sốt sắng sau khi phát hành.
Cập nhật đầu tiên: cam kết lắp ráp và giao hàng
Tự động hóa bắt đầu bằng cách truyền mã qua một đường ống dọc theo tuyến đường này:
- Nhận hàng đã hoàn thành từ kho;
- Cài đặt nó trên một môi trường chuyên dụng;
- Chạy thử nghiệm tự động;
- Đánh giá kết quả cài đặt;
- Gọi đường dẫn sau ở bên cạnh lệnh kiểm tra.
Quy trình tiếp theo sẽ đăng ký nhiệm vụ trong Jira và chờ các lệnh được phân phối đến các vòng thử nghiệm đã chọn, điều này phụ thuộc vào thời gian thực hiện nhiệm vụ. Trình kích hoạt - một lá thư về sự sẵn sàng giao hàng đến một địa chỉ nhất định. Tất nhiên, đây là một sự hỗ trợ rõ ràng, nhưng tôi phải bắt đầu từ đâu đó. Vào tháng 2019 năm XNUMX, quá trình chuyển mã bắt đầu bằng việc kiểm tra môi trường của chúng tôi. Quá trình đã bắt đầu, tất cả những gì còn lại là đưa nó về trạng thái tốt:
- Mỗi sửa đổi được thực hiện trong một nhánh riêng biệt, tương ứng với gói cài đặt và hợp nhất vào nhánh chính mục tiêu;
- Trình kích hoạt khởi chạy quy trình là sự xuất hiện của một cam kết mới trong nhánh chính thông qua yêu cầu hợp nhất, được đóng bởi những người bảo trì từ nhóm nội bộ;
- Các kho lưu trữ được đồng bộ hóa cứ năm phút một lần;
- Quá trình lắp ráp gói cài đặt được bắt đầu - sử dụng trình biên dịch mã nhận được từ nhà cung cấp.
Sau này bên mình đã có sẵn các bước kiểm tra chuyển mã, khởi động pipe và lắp ráp.
Tùy chọn này đã được đưa ra vào tháng Bảy. Những khó khăn trong quá trình chuyển đổi đã dẫn đến một số sự không hài lòng giữa nhà cung cấp và tuyến đầu, nhưng trong tháng tiếp theo, chúng tôi đã cố gắng loại bỏ tất cả những khó khăn và thiết lập một quy trình giữa các nhóm. Bây giờ chúng tôi đã lắp ráp theo cam kết và giao hàng.
Vào tháng 40, chúng tôi đã cố gắng hoàn thành quá trình cài đặt gói riêng biệt đầu tiên được sản xuất bằng cách sử dụng đường dẫn của mình và kể từ tháng XNUMX, không có ngoại lệ, tất cả việc cài đặt các gói không phát hành riêng lẻ đều được thực hiện thông qua công cụ CD của chúng tôi. Ngoài ra, chúng tôi đã cố gắng đạt được tỷ lệ nhiệm vụ nội bộ trong XNUMX% thành phần phát hành với một nhóm nhỏ hơn nhà cung cấp - đây rõ ràng là một thành công. Nhiệm vụ nghiêm trọng nhất vẫn là - lắp ráp và cài đặt bản phát hành.
Giải pháp cuối cùng: gói cài đặt tích lũy
Chúng tôi hiểu rất rõ rằng việc viết kịch bản hướng dẫn của nhà cung cấp là một quá trình tự động hóa tầm thường; chúng tôi phải suy nghĩ lại về quy trình đó. Giải pháp rất rõ ràng - thu thập nguồn cung tích lũy từ nhánh phát hành với tất cả các đối tượng của các phiên bản được yêu cầu.
Chúng tôi bắt đầu với bằng chứng về khái niệm: chúng tôi đã lắp ráp thủ công gói phát hành theo nội dung của quá trình triển khai trước đây và cài đặt nó trên môi trường của chúng tôi. Mọi thứ đều ổn, ý tưởng này hóa ra có thể thực hiện được. Tiếp theo, chúng tôi đã giải quyết vấn đề về việc viết kịch bản cho các cài đặt khởi tạo và đưa chúng vào cam kết. Chúng tôi đã chuẩn bị gói mới và thử nghiệm nó trong môi trường thử nghiệm như một phần của bản cập nhật đường viền. Quá trình cài đặt đã thành công mặc dù có rất nhiều ý kiến từ nhóm thực hiện. Nhưng điều quan trọng nhất là chúng tôi đã được phép đi vào sản xuất trong bản phát hành tháng XNUMX cùng với quá trình lắp ráp của chúng tôi.
Chỉ còn hơn một tháng nữa, những nguồn cung cấp được lựa chọn thủ công rõ ràng cho thấy rằng thời gian sắp hết. Họ quyết định tạo bản dựng từ nhánh phát hành, nhưng tại sao nó phải tách ra? Chúng tôi không có mô hình giống như Prod và các nhánh hiện tại cũng không hoạt động tốt - có rất nhiều mã không cần thiết. Chúng tôi cần khẩn trương cắt giảm lượt thích sản phẩm và con số này là hơn ba nghìn lần cam kết. Lắp ráp bằng tay không phải là một lựa chọn nào cả. Chúng tôi đã phác thảo một tập lệnh chạy qua nhật ký cài đặt sản phẩm và thu thập các cam kết cho chi nhánh. Lần thứ ba nó hoạt động chính xác và sau khi “hoàn tất với một tập tin”, nhánh đã sẵn sàng.
Chúng tôi đã viết trình xây dựng riêng cho gói cài đặt và hoàn thành nó trong một tuần. Sau đó, chúng tôi phải sửa đổi trình cài đặt từ chức năng cốt lõi của hệ thống vì nó là nguồn mở. Sau một loạt kiểm tra và sửa đổi, kết quả được coi là thành công. Trong khi đó, thành phần của bản phát hành đã thành hình, để cài đặt chính xác, cần phải căn chỉnh mạch thử nghiệm với mạch sản xuất và một tập lệnh riêng đã được viết cho việc này.
Đương nhiên, có rất nhiều nhận xét về lần cài đặt đầu tiên, nhưng nhìn chung mã đã hoạt động. Và sau lần cài đặt thứ ba, mọi thứ bắt đầu ổn. Kiểm soát thành phần và kiểm soát phiên bản của các đối tượng được giám sát riêng biệt ở chế độ thủ công, điều này khá hợp lý ở giai đoạn này.
Một thách thức nữa là số lượng lớn các sản phẩm không được phát hành phải được tính đến. Nhưng với nhánh giống Prod và Rebase, nhiệm vụ trở nên rõ ràng.
Lần đầu tiên, nhanh chóng và không có lỗi
Chúng tôi tiếp cận bản phát hành với thái độ lạc quan và hơn chục lượt cài đặt thành công trên các mạch khác nhau. Nhưng đúng nghĩa là một ngày trước thời hạn, hóa ra nhà cung cấp vẫn chưa hoàn thành công việc chuẩn bị phát hành để cài đặt theo cách được chấp nhận. Nếu vì lý do nào đó bản dựng của chúng tôi không hoạt động, việc phát hành sẽ bị gián đoạn. Hơn nữa, thông qua nỗ lực của chúng tôi, điều này đặc biệt khó chịu. Chúng tôi không có cách nào để rút lui. Vì vậy, chúng tôi đã suy nghĩ kỹ các phương án thay thế, chuẩn bị kế hoạch hành động và bắt đầu lắp đặt.
Đáng ngạc nhiên là toàn bộ bản phát hành, bao gồm hơn 800 đối tượng, đã khởi động chính xác ngay lần đầu tiên và chỉ trong 10 phút. Chúng tôi đã dành một giờ để kiểm tra nhật ký để tìm lỗi nhưng không tìm thấy lỗi nào.
Toàn bộ ngày hôm sau có sự im lặng trong cuộc trò chuyện về bản phát hành: không có vấn đề gì về triển khai, phiên bản quanh co hoặc mã “không phù hợp”. Nó thậm chí còn khó xử bằng cách nào đó. Sau đó, một số nhận xét xuất hiện, nhưng so với các hệ thống khác và trải nghiệm trước đó, số lượng và mức độ ưu tiên của chúng thấp hơn đáng kể.
Một tác động bổ sung từ hiệu ứng tích lũy là sự gia tăng chất lượng lắp ráp và thử nghiệm. Do có nhiều lần cài đặt bản phát hành đầy đủ nên các lỗi xây dựng và lỗi triển khai đã được xác định kịp thời. Thử nghiệm trong cấu hình phát hành đầy đủ giúp xác định thêm các khiếm khuyết về ảnh hưởng lẫn nhau của các đối tượng không xuất hiện trong quá trình cài đặt gia tăng. Đó chắc chắn là một thành công, đặc biệt là với sự đóng góp 57% của chúng tôi vào việc phát hành.
Kết quả và kết luận
Trong vòng chưa đầy một năm, chúng tôi đã làm được:
- Xây dựng sự phát triển nội bộ toàn diện bằng cách sử dụng một hệ thống kỳ lạ;
- Loại bỏ sự phụ thuộc quan trọng của nhà cung cấp;
- Khởi chạy CI/CD cho một di sản rất không thân thiện;
- Nâng cao quy trình thực hiện lên trình độ kỹ thuật mới;
- Giảm đáng kể thời gian triển khai;
- Giảm đáng kể số lỗi thực hiện;
- Tự tin khẳng định mình là chuyên gia phát triển hàng đầu.
Tất nhiên, phần lớn những gì được mô tả trông có vẻ hoàn toàn vớ vẩn, nhưng đây là những tính năng của hệ thống và những hạn chế về quy trình tồn tại trong đó. Hiện tại, những thay đổi này đã ảnh hưởng đến các sản phẩm và dịch vụ của Hồ sơ IS (tài khoản chính, thẻ nhựa, tài khoản tiết kiệm, ký quỹ, cho vay tiền mặt), nhưng phương pháp này có thể được áp dụng cho bất kỳ IS nào có nhiệm vụ triển khai thực hành DevOps. Mô hình tích lũy có thể được sao chép một cách an toàn cho các lần triển khai tiếp theo (bao gồm cả những mô hình chưa phát hành) từ nhiều lần phân phối.
Nguồn: www.habr.com