Điểm:2

Cách triển khai Tích hợp liên tục với Puppet và nhiều dịch vụ

lá cờ sa

Chúng tôi đang cố gắng triển khai quy trình Tích hợp liên tục trong môi trường của mình. Chúng tôi có rất nhiều dịch vụ khác nhau, mỗi dịch vụ có kho lưu trữ Git riêng.Việc triển khai được thực hiện thông qua Puppet, sử dụng bộ phân loại nút bên ngoài để xác định lớp nào sẽ triển khai cho từng loại máy chủ. Và các tệp Con rối đang nằm trong repo Git của riêng chúng, như được mô tả ở đây:

Con rối và Git

Chỉ có điều, nó không chỉ có 3 dịch vụ, nó giống như 100. Vì vậy, dự án Con rối là khối nguyên khối khổng lồ gồm nhiều tệp kê khai và tất nhiên nó nằm trong repo Git độc lập của riêng nó.

Bây giờ, tôi đi cùng, được giao nhiệm vụ thiết lập một mẫu cho CI, để khi ai đó yêu cầu hợp nhất một nhánh từ, chẳng hạn, Dịch vụ A, thành nhánh chính, chúng tôi sẽ có thể bắt đầu xây dựng CI sẽ tạo môi trường ảo, triển khai Dịch vụ A cho một số máy ảo và đảm bảo rằng nhánh mới vượt qua tất cả các thử nghiệm tự động. Tất nhiên, vấn đề là để triển khai bản dựng mới của Dịch vụ A, tôi không chỉ phải xây dựng nó mà còn phải cập nhật bảng kê khai Con rối để tham khảo phiên bản bản dựng mới...và các tệp Con rối đang nằm trong một repo hoàn toàn độc lập, không thuộc chi nhánh của tôi. Vì vậy, tôi không có cách nào dễ dàng để nói với Bậc thầy Múa rối rằng cái này nhánh, chúng tôi cần sử dụng bản dựng CI, không phải phiên bản chính.

Tôi không thể là người đầu tiên muốn thiết lập CI cho một môi trường như thế này, nhưng tôi đã tìm kiếm các giải pháp trên web và không có kết quả nào. Có lẽ tôi đang sử dụng các cụm từ tìm kiếm sai.

Có ai có thể đề xuất một mẫu thiết kế phù hợp cho phép tôi triển khai CI cho tất cả các kho dịch vụ của mình không?

Điểm:2
lá cờ cn

Cách dễ nhất (nhưng không nhất thiết là tốt nhất) mà tôi có thể thấy để thực hiện việc này là thiết lập thứ gì đó yêu cầu CI xây dựng môi trường thử nghiệm, nó yêu cầu tên nhánh phù hợp hoặc thứ gì đó tương tự. Điều đó sẽ buộc các nhà phát triển phải tạo một nhánh trong mã Con rối để triển khai phiên bản xây dựng của họ.

Có hiệu quả:

  1. Dave the Developer tạo một nhánh tính năng mới của một dịch vụ, dựa trên một yêu cầu: ví dụ: tính năng/JIRA-999-một số-nhiệm vụ
  2. Dave đẩy mã của mình
  3. CICD phát hiện nhánh mới hoặc PR hoặc bất cứ thứ gì, bắt đầu chạy
  4. Giai đoạn của đường ống tìm kiếm như nhau tên chi nhánh trong repo Puppet
  5. Nếu nhánh không tồn tại, lỗi đường ống và yêu cầu Dave tạo nhánh
  6. Nếu nó tồn tại, có thể thêm một số xác thực để kiểm tra xem ít nhất nó đã được thay đổi chưa?
  7. chạy thử nghiệm
  8. Bài kiểm tra trôi qua, mọi người đều vui vẻ

Đây không phải là vấn đề dễ giải quyết và cách tiếp cận này bạn phải đảm bảo Nhà phát triển biết nơi cập nhật phiên bản (có thể trong tệp dữ liệu Hiera?).

Cách khác duy nhất mà tôi có thể thấy điều này đang hoạt động là một sự thay đổi lớn hơn nhiều sang thứ gì đó như container hóa, cho phép bạn quản lý một lớp (cơ sở hạ tầng) bằng Puppet, sau đó triển khai các container ở trên cùng. Sau đó, bạn có thể cung cấp cho các nhà phát triển các công cụ để triển khai các vùng chứa trong khi vẫn giữ quyền kiểm soát nền tảng.

Một suy nghĩ ngẫu nhiên cuối cùng - bạn có thể thực hiện một số thử nghiệm trên đám mây để tránh sử dụng mã Con rối cho bất kỳ thứ gì ngoại trừ sản xuất/dàn dựng không? Hoặc tận dụng con rối dựa trên đám mây theo một cách nào đó?

Shaul Behr avatar
lá cờ sa
Đây là một gợi ý tốt. Hóa ra, tôi đang nghiêng nhiều hơn về ý tưởng phá vỡ nguyên khối Con rối và đặt bản kê khai Con rối có liên quan đến dịch vụ bên trong repo dịch vụ. Nhưng câu trả lời của bạn xứng đáng với tiền thưởng. Cảm ơn!
Điểm:1
lá cờ us

Thách thức ở đây là mã bị ngắt kết nối khỏi quá trình triển khai.

Cách tiếp cận của tôi là chuyển hàm băm cam kết Git cho Puppet, sau đó Puppet sẽ sử dụng hàm băm cam kết đó để lấy mã để triển khai. Tuy nhiên, tôi không biết liệu Puppet có hỗ trợ chuyển các đối số như vậy cho công việc hay không.

Trong giai đoạn kiểm tra kho lưu trữ mã thực tế, hàm băm sẽ được ghi lại và sau đó được chuyển đến Puppet.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.