Chiến lược xúc tiến phụ thuộc: im lặng hay phối hợp?

Chúng tôi có rất nhiều ứng dụng và dịch vụ web (một số sản phẩm phải đối mặt công khai, một số nội bộ và một phần của "phụ trợ" riêng) phụ thuộc lẫn nhau. Mỗi một trong các thành phần này có 4 môi trường (cụm máy chủ / nút phục vụ các mục đích cụ thể):

• Phi sản xuất
  • DEV- Môi trường phát triển tích hợp nơi CI xây dựng các thay đổi đẩy; hữu ích cho các kỹ sư để khắc phục các lỗi khó tìm mà không thể tái tạo cục bộ
  • QA - Môi trường thử nghiệm / QA bị cô lập
  • DEMO - Môi trường UAT ổn định cho các bên liên quan kinh doanh
• Sản xuất
  • LIVE - Môi trường sống / sản xuất của chúng tôi

Mã khuyến mãi đi: LOCAL(máy của nhà phát triển) => DEV=> QA=> DEMO=> LIVE.

Giả sử chúng ta có một ứng dụng được gọi myapplà được hỗ trợ bởi một dịch vụ web RESTful được gọi myws, chính nó được hỗ trợ bởi một DB được gọi mydb.

Hiện tại, chúng tôi có những gì tôi sẽ gọi là quảng cáo "được phối hợp " trong số các phụ thuộc này: các myapp-devđiểm myws-devsử dụng mydb-dev. Tương tự, myapp-qađiểm myws-qamà sử dụng mydb-qa. Tương tự cho DEMOvà LIVE.

Vấn đề với điều này là bất cứ lúc nào tôi thực hiện một thay đổi, chẳng hạn, myapp, điều này đòi hỏi tôi phải thay đổi mywsvà mydblà tốt. Nhưng vì mỗi DEVmôi trường đều chỉ ra các DEVmôi trường phụ thuộc của nó, điều đó có nghĩa là tôi phải lên lịch và triển khai tất cả các thay đổi này cùng một lúc. Hơn nữa, nếu một bản dựng trở nên không ổn định / bị hỏng, nó thường đưa xuống các thành phần ngược dòng khác; chẳng hạn, nếu một nhà phát triển phá vỡ một cái gì đó khi thay đổi mydb-dev, các cụm myws-devvà myapp-devthường cũng trở nên không ổn định.

Để giải quyết vấn đề này, tôi đưa ra một đề xuất cho chiến lược quảng cáo " im lặng ": tất cả các phụ thuộc giữa các thành phần đều tuân theo hướng dẫn này:

• Phụ thuộc thượng nguồn phụ thuộc vào DEMOmôi trường phụ thuộc hạ của họ, cho tất cả các môi trường phi sản xuất của họ ( DEV, QAvà DEMO); và
• Phụ thuộc vào thượng nguồn phụ thuộc vào LIVEmôi trường cho các phụ thuộc hạ nguồn của họ cho môi trường sản xuất của họ

Sử dụng quy ước này, myapp-devsẽ chấp hành điểm myws-demo, sẽ sử dụng mydb-demo. Tương tự, myapp-qacũng sẽ chỉ đến myws-demovà mydb-demo.

Lợi thế ở đây mà tôi có thể tìm thấy là ổn định xây dựng : ít có khả năng DEMOmôi trường cho một thành phần cụ thể sẽ trở nên không ổn định, bởi vì mã không thể thực hiện được DEMOnếu không kiểm tra nghiêm ngặt cả trên DEVvà QA.

Nhược điểm duy nhất tôi có thể tìm thấy đối với phương pháp này là, nếu DEMOphá vỡ một thành phần cụ thể, tất cả các môi trường phi sản xuất cho tất cả các phụ thuộc ngược dòng sẽ đột nhiên bị phá vỡ. Nhưng tôi sẽ phản bác rằng điều này sẽ hiếm khi xảy ra do thử nghiệm được thực hiện trên DEVvà QA.

Điều này đã nhận được là một vấn đề mà nhiều nhà phát triển (thông minh hơn nhiều và có kinh nghiệm hơn so với bản thân mình) đã được giải quyết, và tôi sẽ không ngạc nhiên nếu vấn đề này và các giải pháp của nó đã có tên họ (ngoài những gì tôi đang kêu gọi dàn / bị bưng bít). Vì vậy, tôi hỏi: Liệu những ưu điểm của một chiến lược xúc tiến ngớ ngẩn có lớn hơn bất kỳ nhược điểm nào không, và những nhược điểm mà tôi có thể đang nhìn thấy ở đây là gì?

Nếu tôi đang đọc đúng bài viết của bạn, có vẻ như đề xuất này thực sự giải quyết được một trong những vấn đề bị cáo buộc.

bất cứ khi nào tôi thực hiện thay đổi, giả sử, myapp, điều này đòi hỏi tôi phải thay đổi cả myws và mydb nữa. Nhưng vì mỗi môi trường DEV đều trỏ đến môi trường DEV phụ thuộc của nó, điều đó có nghĩa là tôi phải lên lịch và triển khai tất cả các thay đổi này cùng một lúc

"Chiến lược xúc tiến ngớ ngẩn" dường như sẽ chỉ làm cho điều này tồi tệ hơn. Nếu myapp v2, myws v2 và mydb v2 chỉ có trên DEV và myapp v2 dựa vào mydb v2 để không gặp sự cố, thì khi tôi thử chạy myapp v2 trên DEV, tôi sẽ gặp mydb v1 DEMO và nó gặp sự cố. Về cơ bản, bạn buộc phải ghi đè lên các silo hoặc triển khai mydb v2 mọi cách để sản xuất trước khi bạn thậm chí có thể bắt đầu làm việc trên myapp v2. Quan trọng hơn, bạn sẽ không bao giờ kiểm tra mydb v2 trên DEV, vì vậy nếu nó bị hỏng, bạn thậm chí không tìm ra cho đến khi nó bị hỏng trên DEMO, và sau đó bạn quay lại hình vuông.

Ở một mức độ nào đó, vấn đề bạn mô tả là không thể tránh khỏi cho dù quy trình công việc của bạn được thiết lập như thế nào, nhưng nó có thể được giảm thiểu. Mẹo nhỏ là đảm bảo rằng giao diện giữa mydb và myws (và giao diện giữa myws và myapp) được xác định nghiêm ngặt và yêu cầu tất cả các cập nhật cho giao diện đó phải tương thích hoàn toàn . Trong công việc của tôi, chúng tôi có một lược đồ XML xác định giao diện giữa các ứng dụng và dịch vụ của chúng tôi và nhiều công cụ nội bộ của chúng tôi chỉ đơn giản là không cho phép chúng tôi thực hiện các cập nhật không tương thích với các lược đồ đó.

Hơn nữa, nếu một bản dựng trở nên không ổn định / bị hỏng, nó thường đưa xuống các thành phần ngược dòng khác; chẳng hạn, nếu nhà phát triển phá vỡ thứ gì đó khi thay đổi mydb-dev, cụm myws-dev và myapp-dev thường trở nên không ổn định.

Điều này nghe có vẻ như là một vấn đề nghiêm trọng, nhưng không phải là vấn đề triển khai. Một cơ sở dữ liệu bị hỏng chắc chắn sẽ ngăn dịch vụ và ứng dụng hoạt động bình thường, nhưng chúng không nên trở nên "không ổn định". Họ nên trả lại các thông báo lỗi thuộc loại nào đó, để bất kỳ ai chạy myapp trên dev đều thấy "Chúng tôi xin lỗi, cơ sở dữ liệu của chúng tôi đang gặp sự cố ngày hôm nay" thay vì đơn giản là bị sập.

Nếu vấn đề là cơ sở dữ liệu bị hỏng gây ra những vấn đề này, thì những gì bạn có thể làm là thiết lập một số hệ thống "im lặng tạm thời" cho phép bạn nói "mydb DEV bị hỏng ngay bây giờ, vui lòng định tuyến tất cả các truy vấn DEV của tôi tới mydb DEMO cho Hiện đang". Nhưng đây chỉ là một cách để thực hiện các sửa lỗi tạm thời cho đến khi mydb DEV hoạt động bình thường trở lại. Nếu mọi thứ đều "im lặng" theo cách đó theo mặc định, thì bạn sẽ quay lại với các vấn đề tôi đã mô tả ở trên vì không ai từng chống lại mydb DEV cả.

Tôi cảm thấy có lẽ tôi đang hiểu nhầm đề xuất của bạn bằng cách nào đó, nhưng hy vọng câu trả lời này ít nhất làm cho nó rõ ràng những gì đang bị hiểu lầm và cách tốt nhất để viết lại nó.