Làm thế nào để bạn xử lý phiên bản trong một dự án nhiều mặt?

Tôi biết đó là một câu hỏi rộng vì vậy tôi sẽ cố gắng cụ thể nhất có thể. Câu hỏi này là một câu hỏi "tổ chức" hơn là một câu hỏi kỹ thuật.

Chúng tôi có một dự án nhiều mặt với các thành phần chính này:

• Một máy chủ, lưu trữ logic kinh doanh cốt lõi (mô hình dữ liệu)
• Một backoffice cho khách hàng sử dụng logic kinh doanh cốt lõi
• API ứng dụng (REST) ​​cũng sử dụng logic nghiệp vụ cốt lõi
• Có các ứng dụng điện thoại thông minh (iOS và Android) sử dụng API ứng dụng
• Có một ứng dụng máy tính bảng khác (android) khác với điện thoại thông minh sử dụng cùng API ứng dụng.

Tôi sẽ sớm sản xuất với các khách hàng tích cực. Và như bất kỳ dự án nào, tôi sẽ cần duy trì tất cả các thành phần khác nhau theo thời gian. Điều đó có nghĩa là tất cả những điều sau đây có thể được nâng cấp:

• mã logic kinh doanh cốt lõi trong máy chủ (được sử dụng bởi văn phòng hỗ trợ, API và như một hiệu ứng phụ, bởi các ứng dụng di động)
• chính API (được sử dụng bởi cả ứng dụng điện thoại thông minh và máy tính bảng)
• tất cả các ứng dụng di động (thông qua appstore / googleplay)

Tất nhiên, các bộ phận phía máy chủ (mã logic nghiệp vụ cốt lõi và mã API) có thể được thay đổi ngay lập tức. Tuy nhiên, các ứng dụng di động mới phải được khách hàng tải xuống trên appstore / googleplay và tôi không thể chắc chắn chúng đã được cập nhật.

Bạn có thể cung cấp bất kỳ hướng dẫn, mẹo thực hành tốt, để làm cho các nâng cấp luận án trơn tru và, không bị cản trở cho khách hàng?

Thành phần nào tôi cần "phiên bản"? Làm thế nào để đảm bảo mọi thứ hoạt động ngay cả khi khách hàng không nâng cấp ứng dụng di động của mình? Tôi có nên buộc anh ta nâng cấp để làm cho công việc của tôi dễ dàng hơn?

Nói một cách dễ hiểu, tôi nên tổ chức như thế nào để dự án đa diện của mình sống theo thời gian?

Vì bạn không thể kiểm soát khi nào các ứng dụng di động sẽ được cập nhật lên bản phát hành mới, bạn cần phiên bản ít nhất là API REST. Nếu bạn không thể thực hiện các thay đổi không tương thích ngược với giao diện đó.

Bên cạnh API REST, một phiên bản giao diện truyền thông khác đi qua giao diện mạng cũng là một ý tưởng hay. Bằng cách đó, bạn cũng không bị buộc phải nâng cấp tất cả các máy khách backoffice cùng lúc với các máy chủ và bạn có thể thực hiện chuyển dần dần sang phiên bản mới với giai đoạn "thử nghiệm beta".

Bên cạnh việc phiên bản các giao diện truyền thông, bạn cũng nên cố gắng thực hiện các thay đổi tương thích ngược càng nhiều càng tốt. Lý tưởng nhất là bạn có thể tung ra một phiên bản giao diện mới vẫn hỗ trợ đầy đủ các máy khách cũ để họ không nhận thấy bất cứ điều gì đã thay đổi.

Bài đăng này làm cho một điểm thú vị về câu hỏi của bạn.

Nói một cách thực tế hơn, nếu bạn có 3 thành phần:

• 2 người tiêu dùng: Front-End và Mobile App
• 1 nhà cung cấp API: Back-End

Bạn có thể sử dụng lược đồ phiên bản Mmp (Major.minor.patch) điển hình cho từng loại nhưng trên url Back-End của bạn, bạn có thể đặt một cái gì đó như http://youhost/M.m/resourceURI.

Khi bạn phát triển và các thay đổi trong API không ảnh hưởng đến hợp đồng của bạn với người tiêu dùng mà bạn giữ nguyên M.mnhư trong URL. Từ thời điểm bạn thực hiện thay đổi trong BackEnd ảnh hưởng đến người tiêu dùng của bạn (có thể là thay đổi về hành vi hoặc đối tượng khác), bạn sử dụng một M.m+1, M+1.m+1hoặc M+1.m.

Cách để duy trì mọi thứ hoạt động là triển khai đồng thời Back-End mới với cái cũ, trong khi người dùng của bạn cài đặt người tiêu dùng mới và từ từ ngừng API cũ.

Bạn có thể thấy một cách trả lời tốt hơn của tôi, tại đây: Phiên bản API REST trên Stackoverflow

Tôi khuyên bạn nên cài đặt một máy chủ tích hợp liên tục, nối nó với kho lưu trữ mã của bạn và kho lưu trữ snapshot / phát hành và tự động hóa các bản dựng của bạn. Điều này sẽ có một số lợi thế:

1. Mỗi thành phần sẽ được phiên bản khi nó được phát hành. Điều này bao gồm các thư viện cấp thấp cũng như các sản phẩm cuối cùng của bạn.
2. Mỗi cam kết mã sẽ kích hoạt một bản dựng ảnh chụp nhanh. Điều này giúp giữ cho các nhà phát triển của bạn trung thực, đặc biệt nếu bạn sử dụng thiết bị để gửi email cho thủ phạm đã phá vỡ bản dựng.
3. Mỗi bản dựng có thể chạy thử nghiệm đơn vị. Điều này cải thiện rõ rệt chất lượng mã.
4. Mọi bản phát hành sẽ được gắn thẻ, vì vậy nếu cần phải sửa lỗi sản xuất, bạn có thể dễ dàng phân nhánh từ thẻ và thực hiện sửa lỗi.
5. Bạn sẽ cần phải duy trì một thanh ghi tương thích của một số loại. (ví dụ: BackScript 1.0.23 tương thích với REST API 2.0.267, v.v.). Tôi không biết về một công cụ sẽ giúp trong lĩnh vực này.

Kinh nghiệm của tôi đã có với các công cụ nguồn mở: SVN, Maven 2, Jenkins và Nexus, nhưng có những lựa chọn thay thế cho tất cả những thứ này.

Đừng đánh giá thấp thời gian học tập để giúp nhóm của bạn tăng tốc. Nhưng một khi họ đã tăng tốc, họ sẽ không bao giờ quay trở lại.

Đối với một nhóm tương đối nhỏ để phát triển và triển khai, mô hình tương thích Client N-1 do IBM Jazz sử dụng có thể hoạt động khá tốt

Cố gắng giữ máy khách và máy chủ ở cùng một số phiên bản. [Thay vì quản lý một ma trận các phiên bản độc lập và tính tương thích của chúng]

Đưa ra chính sách rằng phiên bản máy khách Xyy phải hoạt động với tất cả các phiên bản máy chủ trên Xyy nhưng thấp hơn X + 2.0.0

Đối với phiên bản máy chủ 4.0, lý tưởng nhất là phải có phiên bản máy khách 4.0 cho mọi loại máy khách. Tuy nhiên, tính tương thích phải được duy trì để cho phép các phiên bản máy khách và máy chủ hơi khác nhau.

Phiên bản máy khách 4.x phải tương thích với máy chủ phiên bản 4.x trở lên nhưng dưới 6.0; Máy chủ 4.x phải tương thích với tất cả các máy khách phiên bản 3.0 trở lên nhưng nhỏ hơn hoặc bằng 4.x

Bằng cách này, bạn có thể cập nhật một phiên bản trên máy chủ mà không phải lo lắng về việc phát hành ngay các phiên bản mới của máy khách, nhưng sẽ chỉ có một cửa sổ tương thích được xác định rõ để duy trì.

Tham chiếu: Mô hình Jazz của IBM [ https://www.ibm.com/support/ledgeledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

Đầu tiên, tôi sẽ bắt đầu bằng cách đóng khung vấn đề một chút khác biệt. Bạn đã hỏi những phần mềm nào bạn cần "phiên bản". Phiên bản là một thuật ngữ quá tải trong CS và có thể có nghĩa là khoảng 100 điều khác nhau. Những điều chính tôi sẽ xem xét là:

1. Kiểm soát phiên bản - Kiểm soát phiên bản là một công cụ quản lý cấu hình giúp bạn theo dõi các ảnh chụp nhanh và lịch sử phát triển của bạn. TẤT CẢ MÃ SỐ NÊN ĐƯỢC HIỂU KIỂM SOÁT PHIÊN BẢN. Tôi không quan tâm nếu đó chỉ là các tập lệnh tiện lợi mà bạn thêm vào thư mục bin của mình, bất cứ điều gì đáng để dành thời gian viết đều đáng giá trong hai giây để thêm vào phần mềm kiểm soát sửa đổi.
2. Quản lý cấu hình - Làm cách nào để kiểm soát nội dung trong bản dựng. Tất cả các phần mềm nên có một số mức độ quản lý cấu hình. Tôi muốn mô tả cho các nhà quản lý sự khác biệt giữa kiểm soát phiên bản và quản lý cấu hình vì kiểm soát phiên bản chỉ là một công cụ để theo dõi lịch sử phát triển, trong khi quản lý cấu hình là hướng dẫn về cách chúng tôi tạo lịch sử và cách chúng tôi làm những việc như quyết định mã tốt.
3. Phiên bản phần mềm - gán tên cho bản phát hành mã. Đây là điều mà nhiều người mắc phải khi lần đầu tiên nhìn thấy vấn đề bởi vì họ thường thấy "MineSweeper 7.129290149210" hoặc bất cứ thứ gì họ mua, nhưng thật lòng tôi thấy đây là phần nhỏ nhất của một vấn đề lớn hơn nhiều. Thành thật mà nói, chỉ cần sử dụng hàm băm được tạo bởi 1 và không quan tâm đến mức mà con người không thể đọc được là hoàn toàn tốt.

Vì nó là thứ vớ vẩn và thú vị nhất đối với tôi, tôi sẽ tập trung vào # 2. Không có giải pháp cắt cookie một kích cỡ phù hợp cho tất cả để quản lý cấu hình. Các quy tắc hoạt động tốt cho một nhóm 2 hoặc 3 có thể quá lỏng lẻo để giữ sự tỉnh táo trong một dự án cần hàng trăm công nhân. Các quy tắc làm việc cho nhóm lớn có thể yêu cầu quá nhiều chi phí cho nhóm nhỏ. Rất có thể bạn sẽ phải tự lắp một thứ gì đó của riêng mình để có được thứ gì đó cùng nhau, nhưng tôi sẽ sử dụng danh sách sau đây như một cách để phát triển thông số kỹ thuật cho hệ thống quản lý cấu hình của bạn:

1. Làm cách nào tôi có thể theo dõi các phiên bản (và các vấn đề liên quan đến chúng) mà tôi đang hỗ trợ trên thị trường?
2. Làm thế nào tôi sẽ quyết định những con đường phát triển nào đã sẵn sàng để phát hành cho các hệ thống sản xuất? (Nó cũng có thể sẵn sàng cho bất kỳ bước nào khác trong một quy trình)
3. Ai nên có quyền kiểm soát / quản lý cấu hình của hệ thống? Quy trình làm việc để thêm mã được phân phối cho các nhà phát triển khác là gì?
4. Làm thế nào tôi có thể kiểm soát sự tương tác giữa các phần tương tác? Làm sao tôi biết nếu thay đổi một phần sẽ phá vỡ phần còn lại của hệ thống?
5. Làm thế nào chúng ta sẽ cải thiện hệ thống quản lý cấu hình của chúng tôi theo thời gian.

Cần giúp đỡ trả lời các câu hỏi trên? Bạn có lẽ nên thuê một nhà tư vấn hoặc người quản lý kỹ thuật phần mềm ... trả lời có thể điền vào sách giáo khoa và nằm ngoài phạm vi của loại diễn đàn này.