Làm thế nào để tạo máy chủ dàn cho nhiều nhánh git?

Tôi phải tạo ra một quy trình dàn mới cho sự phát triển và thử nghiệm của chúng tôi.

Tại bất kỳ thời điểm nào, chỉ có khoảng 4 nhánh git tích cực được phát triển và thử nghiệm. Trong mỗi nhánh git, có thể có các tập lệnh tiến hóa cơ sở dữ liệu (SQL thẳng) phải được chạy, cũng như các tập lệnh tiến hóa từ phụ trợ để xử lý nặng hơn (về cơ bản đây là các tuyến HTTP phải được gọi trong ứng dụng bằng thông tin quản trị viên thực hiện cơ sở dữ liệu di chuyển và các thay đổi khác sẽ quá khó / không thể thực hiện được trong các kịch bản tiến hóa SQL đơn giản đã nói ở trên).

DB trực tiếp của chúng tôi có kích thước vừa phải ~ 4.2 GB. Chúng tôi có một máy chủ Dell PowerEdge hoàn toàn mới đã sẵn sàng để được thiết lập và sẵn sàng sử dụng.

Tôi rất thích lời khuyên về các câu hỏi sau đây, cũng như để biết DevOps có kinh nghiệm hơn sẽ tiếp cận vấn đề này như thế nào:

1. Làm thế nào tôi có thể chạy một số chi nhánh khác nhau trên máy chủ dàn? Các nhánh này bật lên và biến mất thường xuyên khi chúng vượt qua QA và được sáp nhập vào chủ và được phát hành.

2. Làm cách nào để thiết lập hệ thống tiến hóa DB để đảm bảo nó luôn có DB phù hợp cho từng nhánh? Mỗi nhánh có thể sửa đổi DB theo những cách khác nhau không nhất thiết phải tương thích với nhau cho đến khi chúng được hợp nhất.

3. Làm thế nào để tôi giữ cho các chi nhánh cập nhật? Có cách nào để tự động kéo cam kết trên mỗi chi nhánh không?

Sẽ thích thêm bất kỳ đầu vào nào vì tôi hơi mất phương hướng thiết lập tất cả. Quy trình công việc hiện tại rất khó khăn cho tất cả mọi người tham gia: Các nhà phát triển có một bản sao hoàn toàn bị cô lập của ứng dụng chạy cục bộ và QA có 3-4 máy tính xách tay xoay vòng hoạt động như các "máy chủ" dàn dựng của họ

1) Làm cách nào tôi có thể chạy một số nhánh khác nhau trên máy chủ dàn?

Docker

2) Làm cách nào để thiết lập hệ thống tiến hóa DB để đảm bảo nó luôn có DB phù hợp cho từng nhánh?

Điều này phụ thuộc vào mức độ bạn mong đợi DB của bạn mở rộng. Bạn có thể trở nên khá điên rồ với các phương pháp sao chép dữ liệu cơ sở dữ liệu nhưng thông thường bạn sẽ muốn có một bản sao chính mà bạn không thay đổi cho đến khi mã của bạn được phát hành vào sản xuất - và giữ các bản sao lưu tốt khi bạn làm. Trong khi cơ sở hạ tầng của bạn có thể là bất biến và dùng một lần, dữ liệu của bạn thì không. Bạn chỉ có thể mô phỏng khả năng xử lý với dữ liệu của bạn. 4.2 GB thực sự không phải là nhiều để sao chép. Bạn có thể tạo một tập lệnh để sinh ra một cá thể cơ sở dữ liệu mới cho mỗi bản dựng để hoạt động, sau đó loại bỏ nó sau khi thử nghiệm hoàn tất.

3) Làm cách nào để giữ cho các chi nhánh này được cập nhật? Có cách nào để tự động kéo cam kết trên mỗi chi nhánh không?

Bạn có thể cân nhắc sử dụng một cái gì đó như git hook để kích hoạt bản dựng, buộc kiểm tra mã hoặc bắt đầu sinh ra một container và sao chép cơ sở dữ liệu của bạn. Bạn có thể thực hiện lệnh gọi API đến một hệ thống tự động hóa xây dựng như Jenkins và / hoặc sử dụng nó để khởi động một hệ thống quản lý cấu hình như Puppet, Chef, Salt Stack, Ansible hoặc một cái gì khác. Điều này sẽ giống như tự động kéo hơn là tự động đẩy.

Từ cách đặt câu hỏi của bạn, rõ ràng bạn đang nghĩ về một cơ sở hạ tầng có thể thay đổi, nhưng hãy xem xét sử dụng các triển khai thử nghiệm bất biến thay thế.

Tôi tranh luận rằng đây không thực sự là về máy chủ dàn dựng. Một máy chủ dàn dựng bắt chước chặt chẽ môi trường sản xuất và là nơi phát hành ngay trước khi đi vào sản xuất. Một nhánh tính năng chưa được sáp nhập vào master sẽ không được phát hành trực tiếp vào sản xuất, vì vậy nó không nên đi trên một máy chủ dàn dựng.

Nếu chúng tôi điều chỉnh lại câu hỏi là về các máy chủ phát triển được chia sẻ, thì bạn sẽ tìm thấy nhiều tài nguyên hơn khi bạn tìm kiếm. Như bạn đã nhận thấy, việc chia sẻ tài nguyên phát triển như thế này gây ra một số vấn đề, vì vậy có lẽ tốt hơn nên tập trung vào giải quyết vấn đề cơ bản thay vào đó: tại sao mọi người tham gia vào quá trình này lại khó chạy máy chủ dev trên máy cục bộ của họ máy móc?

Bây giờ, đôi khi tình huống là bạn thực sự cần phải có các máy chủ được chia sẻ này. Nếu bạn đã trải qua và xác định rằng bạn thực sự làm , thì có một số kỹ thuật bạn có thể thực hiện để đơn giản hóa quy trình.

Làm thế nào tôi có thể chạy một số chi nhánh khác nhau trên máy chủ dàn? Các nhánh này bật lên và biến mất thường xuyên khi chúng vượt qua QA và được sáp nhập vào chủ và được phát hành.

Một trong những cách dễ nhất là sử dụng một phần của url để chuyển nhánh mã nào được thực thi (thay đổi này là một phần lý do tại sao đây không phải là môi trường dàn phù hợp). Tôi đã thực hiện điều này trong quá khứ với DNS ký tự đại diện (vì vậy mọi thứ foo.our-dev-domain.comsẽ chuyển hướng đến cùng một máy chủ) và mã định tuyến được tải lên /our/release/directory/footrong đường dẫn bao gồm.

Bạn cũng có thể có một lệnh (sử dụng một cái gì đó như Ansible) để thêm cấu hình cần thiết cho một nhánh khi cần thiết. Đây có lẽ sẽ là một phần của quá trình triển khai, mà tôi sẽ nói trong một phút.

Làm cách nào để thiết lập hệ thống tiến hóa DB để đảm bảo nó luôn có DB phù hợp cho từng nhánh? Mỗi nhánh có thể sửa đổi DB theo những cách khác nhau không nhất thiết phải tương thích với nhau cho đến khi chúng được hợp nhất.

Điều dễ nhất để làm là chỉ cần sống với nó, và khuyến khích mọi người có các chi nhánh ngắn.

Một cách tiếp cận khác là sử dụng mã định tuyến động để chuyển sang các bản sao riêng biệt của cơ sở dữ liệu (theo thuật ngữ RDBMS, "cơ sở dữ liệu") dựa trên tên của chi nhánh.

Làm thế nào để tôi giữ cho các chi nhánh cập nhật? Có cách nào để tự động kéo cam kết trên mỗi chi nhánh không?

Bạn có thể đẩy hoặc kéo. Ví dụ:

• kéo - thiết lập một công việc định kỳ thực hiện một git pull(hoặc có thể, a git fetchvà a git reset --hard) cứ sau vài phút
• đẩy - thiết lập một webhook kích hoạt khi đẩy và một dịch vụ web nhỏ trên máy lắng nghe và cập nhật các repos khi cần thiết
• đẩy - yêu cầu các nhà phát triển chạy một lệnh triển khai để cập nhật các nhánh của họ trên máy chủ

Nói chuyện với người dùng của bạn trước và thu thập các yêu cầu của họ để xem những gì họ muốn (họ có thể không muốn nó tự động cập nhật trong khi họ đang thử nghiệm điều gì đó) và điều đó sẽ thông báo cho quyết định của bạn.

Nhưng một lần nữa:

Các nhà phát triển có một bản sao hoàn toàn biệt lập của ứng dụng đang chạy cục bộ và QA có 3-4 máy tính xách tay xoay vòng hoạt động như các "máy chủ" dàn dựng của họ

Vấn đề dường như là QA xoay các máy tính xách tay dùng chung thay vì chỉ kiểm tra một chi nhánh cụ thể giống như cách các nhà phát triển thực hiện.

Đó là những gì gitlab làm tốt nhất, xem xét để chuyển sang gitlab, thiết lập một cụm kube và tự động triển khai. Điều này sẽ triển khai mỗi chi nhánh đến một URL duy nhất để thử nghiệm.