Giữ cho môi trường máy chủ thử nghiệm và sản xuất máy chủ luôn sạch sẽ, đồng bộ và nhất quán

Question

Dường như công ty tôi làm việc luôn là đang phải vật lộn với môi trường máy chủ của khách hàng.

Cụ thể, chúng tôi hầu như luôn gặp phải sự cố với máy chủ thử nghiệm và máy chủ sản xuất và thực tế là chúng dường như luôn được định cấu hình khác nhau. Khi chúng tôi kiểm tra các ứng dụng mà chúng tôi phát triển, các máy chủ thử nghiệm hoạt động theo một cách và do đó chúng tôi tinh chỉnh và định cấu hình các ứng dụng của mình để phù hợp với hành vi cụ thể đó. Nhưng khi chúng tôi cài đặt cùng một ứng dụng trên các máy chủ sản xuất, chúng tôi quan sát một hành vi khác không phù hợp với các máy chủ thử nghiệm, do đó, việc hiển thị các chỉnh sửa và cấu hình của chúng tôi vô dụng. Phần khó chịu nhất là điều này xảy ra mọi lúc và dường như không ai biết phải làm gì với nó.

Tất nhiên chúng tôi có ý tưởng chung về lý do tại sao điều này xảy ra. Mỗi môi trường nhân bản bắt đầu giống nhau và hoạt động giống nhau trong vài ngày đầu, nhưng sớm hay muộn ai đó cấu hình lại thứ gì đó chỉ trong một môi trường máy chủ (có thể là cập nhật cơ sở dữ liệu, cập nhật thư viện thành phần, cập nhật tệp web, hoặc các cấu hình khác), do đó dẫn đến sự khác biệt. Và như thời gian trôi qua, ngày càng nhiều sự khác biệt xây dựng. Nhưng câu hỏi đặt ra là: chúng ta có thể làm gì với nó?

Tôi đã thử tìm kiếm trên web nhưng không thể tìm thấy bất kỳ câu trả lời hay nào về những việc cần làm. Tôi cũng đã cố gắng tìm ra một số giải pháp của riêng mình, nhưng hầu hết các ý tưởng của tôi dường như có vấn đề theo một cách nào đó. Các thói quen mới, bất kể nghiêm ngặt như thế nào, có thể bị phá vỡ. Thường xuyên nhân bản của các máy chủ sản xuất để tạo ra các máy chủ thử nghiệm là một quá trình tẻ nhạt và thường rất chậm. Tự động sao chép không phải lúc nào cũng đáng tin cậy hoặc thậm chí có thể. Vậy chúng ta nên làm gì với vấn đề này? Làm cách nào chúng tôi có thể đảm bảo rằng trải nghiệm khi thử nghiệm sẽ khớp với trải nghiệm khi phát trực tiếp?

Tôi tưởng tượng rằng những người khác cũng gặp phải vấn đề này. Hay là họ? Có lẽ đó chỉ là công ty cụ thể của tôi mà không đủ năng lực? Bạn có gặp phải vấn đề nào không? Nếu vậy, bạn đã làm gì về nó?

Trân trọng,

Linus, hệ thống của Thụy Điển phát triển

Answer 1

Bạn cần phải chắc chắn rằng bất kỳ thay đổi đối với môi trường được thực hiện một cách nhất quán.

Tôi muốn xem xét bắt đầu với hình ảnh mới và thực thi chính sách đăng nhập sửa đổi nghiêm ngặt hoặc sử dụng Capistrano để thực thi lệnh từ xa và triển khai mã cho tất cả các máy cùng một lúc. Lý tưởng nhất, tất cả các yêu cầu cần được kiểm tra trong hệ thống điều khiển phiên bản của bạn (dọc theo dòng cách Rails cho phép bạn lưu trữ đá quý trong thư mục/vendor và ưu tiên tải chúng trong thời gian chạy), cùng với tệp readme mô tả chính xác cách thiết lập môi trường (thư viện bắt buộc, v.v.). Tệp readme cần được cập nhật một cách nghiêm ngặt bởi bất kỳ ai thay đổi môi trường.

Answer 2

Bạn cần bắt đầu theo dõi mọi thay đổi mà bạn thực hiện đối với môi trường thử nghiệm và cung cấp cách để truyền điều này đến môi trường sản xuất.

Đối với mã, điều này có nghĩa là các hệ thống phiên bản như CVS, Subversion hoặc GIT.

Đối với cơ sở dữ liệu, nó có nghĩa là công cụ so sánh cấu trúc hoặc triển khai tập lệnh cập nhật cơ sở dữ liệu sản xuất.

Để cấu hình, hai hệ thống phải chính xác như nhau và bất kỳ nhu cầu 'chỉnh sửa' hoặc thay đổi nào trước tiên sẽ được áp dụng cho máy chủ thử nghiệm, sau đó được áp dụng cho máy chủ sản xuất trong quá trình triển khai.

Cho đến khi bạn có quy trình hoạt động, bạn sẽ tiếp tục gặp sự cố.

Answer 3

Sự cố của bạn khá bình thường. Có ít nhất hai chiến lược tôi biết làm việc khá tốt:

Nếu bạn đang phân phối trên Linux, bạn có thể tạo rpms/debs từ quá trình phát triển của mình và sử dụng chức năng quản lý gói. Tôi biết rất nhiều dự án làm điều này với thành công lớn cho các dự án trong nhà.

Một lựa chọn khác là gói toàn bộ môi trường dưới dạng một số loại tập lệnh shell. Kịch bản shell này có thể/nên cấu hình môi trường hoàn chỉnh với tất cả các thiết lập. Thông thường, tập lệnh này được duy trì bởi develeopment và tập lệnh này ghi đè mọi sửa đổi đã được thực hiện thủ công. Một kịch bản như thế này thường được duy trì bằng cách phát triển, được giữ trong điều khiển phiên bản và được gửi đến triển khai dưới dạng bản phân phối đầy đủ. Chúng tôi sử dụng Cygwin cho việc này. Thông thường, kịch bản đọc một số loại cấu hình có thể được quản lý bởi các hoạt động. Tôi đã có các kịch bản thực sự thiết lập hệ thống toàn bộ từ đầu như thể cài đặt trên một máy hoàn toàn trống, mới được cài đặt.

Cả hai chiến lược này tốt nhất nên bao gồm sản xuất tự động các tạo phẩm này từ hệ thống xây dựng tập lệnh/xây dựng của bạn. Quá trình này càng mượt mà, càng tốt cho tất cả các bên liên quan.

Answer 4

Tất nhiên chúng tôi có ý tưởng chung về lý do tại sao điều này xảy ra. Mỗi môi trường nhân bản bắt đầu giống nhau và hoạt động giống nhau trong vài ngày đầu tiên, nhưng sớm hay muộn ai đó cấu hình lại thứ gì đó chỉ trong một môi trường máy chủ

Tôi nghĩ bạn đang hào phóng, hoặc bạn rất may mắn. Thường thì không phải các cửa hàng cần hợp đồng cho công việc phát triển không thực sự hiểu được quá trình phát triển. Nếu họ cung cấp cho bạn một môi trường thử nghiệm ở tất cả những gì bạn sẽ nhận được là một hệ thống sản xuất của họ từ trước khi làm mới máy chủ cuối cùng.

Answer 5

Đối với việc giữ cơ sở dữ liệu MySQL đồng bộ, tôi chỉ chạy vào công cụ này:

http://schemasync.org/

tôi đã không thực sự sử dụng nó nhưng vì vậy tôi không thể nói chuyện với cho dù đó là bất kỳ tốt, nhưng chúng ta cần một số cách để kiểm soát trôi dạt giản đồ giữa thử nghiệm và sản lượng vì vậy chúng tôi sẽ cung cấp cho nó một shot.