Làm thế nào để đạt được sự chuyển đổi suôn sẻ từ một kho lưu trữ VCS lớn cho tất cả các sản phẩm Mô hình tổ chức thành một mô hình lưu trữ VCS nhỏ?

Một kịch bản phổ biến là cơ sở mã của sản phẩm được lưu trữ trong kho lưu trữ trong một số hệ thống VCS phát triển đến điểm mà cơ sở mã hóa có thể được coi là có chứa một số sản phẩm. Việc phân tách cơ sở mã trên một số kho lưu trữ VCS, mỗi kho dành riêng cho một sản phẩm, có thể tận dụng một số lợi ích (xem Lợi ích của việc có một sản phẩm trên mỗi kho lưu trữ VCS qua mô hình kho lưu trữ bên dưới). Về mặt kỹ thuật, tách codebase là một bước khá dễ dàng vì hầu hết các VCS đều hỗ trợ thao tác này. Tuy nhiên, sự phân chia có thể làm tăng các vấn đề kỹ thuật liên quan đến thử nghiệm tự động, phân phối liên tục, tích hợp hoặc giám sát dịch vụ (xem Các vấn đề được đưa ra bởi sự phân tách.) Các tổ chức có kế hoạch thực hiện việc phân chia như vậy do đó cần biết cách thực hiện quá trình chuyển đổi này một cách trơn tru nhất có thể, nghĩa là, không làm gián đoạn đường ống phân phối và giám sát của họ. Bước đầu tiên của điều này có lẽ là để hiểu rõ hơn về khái niệm dự án và làm thế nào để phân định sự phân chia trong một cơ sở mã nguyên khối.

Trong câu trả lời cho câu hỏi này, tôi muốn xem:

1. Một nỗ lực để đưa ra một định nghĩa làm việc về sản phẩm là gì, đưa ra các tiêu chí thực tế để phân định các sản phẩm thực sự trong một cơ sở mã hiện có.

2. Theo định nghĩa làm việc này, xây dựng một kế hoạch thực sự phân chia. Chúng ta có thể làm cho các giả định đơn giản hóa mà codebase được xử lý bởi một hoàn toàn tự động SDLC thực hiện liên tục hội nhập và liên tục giao hàng . Đó là, mỗi nhánh được xác nhận bởi một testsuite tự động được triển khai trong cơ sở mã hiện tại và mỗi hợp nhất với một số nhánh ma thuật của Cameron tạo ra các sản phẩm tạo tác phẩm được thử nghiệm và triển khai. ( Các vật phẩm của sản phẩm là ví dụ tarball nguồn, tài liệu, gói phần mềm nhị phân, hình ảnh Docker , AMI, unikernels.)

3. Kế hoạch như vậy là thỏa mãn nếu nó giải thích làm thế nào để phá vỡ

Các vấn đề được đưa ra bởi sự phân chia

1. Làm thế nào các thủ tục kiểm tra tự động liên quan đến kho lưu trữ nguyên khối có sẵn và các kho lưu trữ phân chia?

2. Làm thế nào các quy trình triển khai tự động liên quan đến kho lưu trữ nguyên khối có sẵn và các kho lưu trữ phân chia?

3. Trường hợp được lưu trữ mã cho các thủ tục triển khai tự động?

4. Cơ sở hạ tầng được lưu trữ , giám sát và chiến lược sẵn sàng cao ở đâu?

5. Làm thế nào để đảm bảo rằng nhà phát triển chỉ cần một cơ sở mã hóa tại một thời điểm (nhưng có thể sử dụng các vật phẩm từ các cơ sở mã khác).

6. Làm thế nào một công cụ như git-bisect

Lưu ý cận biên: Lợi ích của việc có một sản phẩm trên kho lưu trữ VCS so với mô hình kho lưu trữ phình to

Có một số kho lưu trữ nhỏ đang giữ codebase cho một sản phẩm cụ thể có những ưu điểm sau so với cách tiếp cận kho lưu trữ bloat của Blond:

1. Với một kho lưu trữ phình to, thật khó để lấy lại một bản phát hành khi một sản phẩm không ổn định, bởi vì lịch sử được trộn lẫn với lịch sử sản phẩm khác.

2. Với một kho lưu trữ phình to, thật khó để xem lại lịch sử dự án hoặc kéo, với các kho lưu trữ nhỏ, chúng tôi có nhiều khả năng đọc thông tin này. (Điều này có thể dành riêng cho VCS như git, không giống như svn, chúng tôi không thể kiểm tra các cây con!)

3. Với một kho lưu trữ phình to, chúng ta phải nhảy nhánh nhiều hơn khi chúng ta phát triển. Nếu chúng ta có kho lưu trữ N, chúng ta có thể làm việc song song trên N nhánh, nếu chúng ta chỉ có 1 kho lưu trữ, chúng ta chỉ có thể làm việc trên một nhánh hoặc có vô số bản sao làm việc cũng gây rắc rối.

4. Với một số kho lưu trữ nhỏ, các bản ghi đưa ra một bản đồ nhiệt của dự án. Chúng thậm chí có thể được sử dụng như một ủy quyền phổ biến kiến ​​thức trong nhóm nhà phát triển: nếu tôi không tham gia repo X từ 3 tháng, thì việc giao cho tôi trong một nhóm làm việc trên repo X là điều tốt để tôi biết về sự phát triển trong thành phần đó.

5. Với các kho lưu trữ nhỏ, sẽ dễ dàng có được một cái nhìn tổng quan rõ ràng về một thành phần. Nếu mọi thứ đi vào một kho lưu trữ lớn duy nhất, không có vật phẩm hữu hình nào phân định rõ từng thành phần và cơ sở mã có thể dễ dàng trôi về phía quả bóng bùn lớn .

6. Các kho nhỏ buộc chúng ta phải làm việc trên các giao diện giữa các thành phần. Nhưng vì chúng tôi muốn có một viên nang tốt, dù sao đây cũng là công việc chúng tôi nên làm, vì vậy tôi sẽ coi đây là một lợi thế cho các kho lưu trữ nhỏ.

7. Với một vài kho lưu trữ nhỏ, việc có nhiều chủ sở hữu sản phẩm sẽ dễ dàng hơn.

8. Với một số kho lưu trữ nhỏ, việc có các tiêu chuẩn mã đơn giản phù hợp với kho lưu trữ đầy đủ sẽ dễ dàng hơn và có thể được xác minh tự động.

Đó là một câu hỏi hấp dẫn mà câu trả lời thực sự có thể không thực sự tồn tại; Tôi đánh giá cao rằng trong khi bạn cố gắng giữ câu hỏi được bối cảnh hóa trên VCS, thì nó tự nhiên được mở rộng theo thiết kế cơ sở hạ tầng và lập kế hoạch thực hiện.

Mặc dù, có vẻ như nhiều người trong chúng ta đang làm việc với loại chuyển đổi này, có thể thú vị, nhưng đồng thời rất bực bội và đau đớn; và tôi muốn chia sẻ kinh nghiệm và quan điểm của mình, cố gắng không trở thành người phạm tội, và chỉ vì tôi có thể không phải là một kỹ sư giỏi như vậy, cũng không bị nhàm chán.

Thiết kế

Cơ sở hạ tầng và kiến ​​trúc nên đi cùng nhau để viết một phần mềm hiện đại. Kết hợp chặt chẽ, nếu bạn muốn. Nghe có vẻ lạ khi sử dụng những từ đó, nhưng chúng tôi không chắc chắn nói về chính mã ở đây: Ý tôi là chúng phải là một phần của cùng một bản thiết kế. Khi những đám mây xuất hiện và mọi người bắt đầu viết phần mềm cho họ, bao nhiêu người sau đó nhận ra rằng bằng cách đặt những quả bóng bùn ở đó, họ sẽ chỉ là những quả bóng bùn ở một nơi khác (?) Có thể một vài người nghĩ về phía trước có thể thấy trước điều đó, và họ có khả năng làm việc trong các tín đồ ngày hôm nay. Vì các tín đồ chỉ là một từ thông dụng với rất nhiều ý nghĩa khác nhau đối với những người khác nhau, tôi đã thấy những nơi mà nhóm tín đồ sẽ ngồi trong mọi cuộc họp kiến ​​trúc; những nơi khác chỉ là tự động hóa. Để đạt được loại chuyển đổi này, chúng tôi phải chiến đấu theo cách của chúng tôi để ngồi ở đó.

Sự tự tin

Quá trình chuyển đổi phải được cách ly, theo nghĩa là phải có một đoạn cắt lịch sử nhất quán, chỉ cung cấp quá trình chuyển đổi và bản thân nó, mà không có bất kỳ thay đổi nào khác (sau vài tháng chuẩn bị). Với sự tự tin nào người ta sẽ chấp nhận nó và nhấn nút màu đỏ?

Ý tôi là cơ sở mã phải thay đổi để phù hợp với cấu trúc VCS mới và sẽ rất khó để giữ cho nó được hợp nhất trong quá trình phát triển. (đối với vấn đề này có thể có các chiến lược tạo điều kiện, tôi sẽ nói về một chiến lược chung sau này, có thể giúp phát triển song song một chút).

Vâng, tôi cá là cách duy nhất là kiểm tra hành vi và cùng một bộ kiểm tra hành vi nên được đưa ra để xác minh cái cũ với cơ sở mã mới. Chúng tôi không xác minh ứng dụng hoạt động như mong đợi ở đây, nhưng việc chuyển đổi không làm thay đổi hành vi. Có bài kiểm tra thất bại có thể là một điều tốt! Nếu họ tiếp tục thất bại!

Trong thực tế, rất hiếm khi các quả bóng bùn được kiểm tra tốt; thông thường mã được ghép rất chặt chẽ và có thể, đối với hầu hết các mã kế thừa, nó không được phát triển với cách tiếp cận hướng kiểm tra, thậm chí không phải kiểm tra đơn vị.

Nếu mã kiểm tra đó bị thiếu bất cứ điều gì, nó sẽ được viết trước.

Chiến lược

Có, quá trình chuyển đổi phải được cách ly; nhưng đồng thời tích hợp. Tôi biết tôi nghe có vẻ điên rồ ở đây, nhưng tôi sẽ không tìm thấy những từ khác để mô tả làm thế nào sự tự tin có thể theo kịp kinh doanh. Rất ít, nếu không có gì, các công ty muốn ngừng phát triển cho một cơ sở mã hóa nguyên khối lớn, để tạo không gian cho quá trình chuyển đổi này và chúng tôi sẽ không làm cho nó chỉ xảy ra trong một lần tung đồng xu. Có thể hàng trăm nhà phát triển có thể liên tục đóng góp cho codebase (tôi sẽ sử dụng từ giả mạo ở đây, từ POV của chúng tôi). Mặc dù công việc của chúng tôi phải giải quyết một ảnh chụp nhanh cụ thể để cung cấp sự tự tin, chúng tôi phải giữ cho mình nổi loạn (không phải theo nghĩa git ở đây), để tránh bị tụt lại phía sau mãi mãi.

Chiến lược thực hiện ở đây có thể cho những kinh nghiệm khác nhau. Một dòng phát triển chung là bao bọc / thích ứng (phơi bày các điểm cuối với các sơ đồ được sắp xếp lại tùy ý) các nhánh thực hiện mới hơn (tốt, sống trong các kho lưu trữ khác trong trường hợp này), khi chúng cần tương tác với lõi. Chuyển đổi với một chiến lược như thế này, cùng với tái cấu trúc, đồng thời có thể đưa ra một kịch bản POC cho quá trình chuyển đổi VCS, và sau đó là cách tiếp cận từng bước. Xem nó như điêu khắc quả bóng bùn. Vâng cuộc sống cung cấp rất nhiều điều hài hước hơn.

Nợ kỹ thuật

Lĩnh vực quản lý kinh doanh bắt đầu hiểu nợ kỹ thuật và xem xét nó. Không, gãi mà, không đúng. Mặc dù ngày càng phổ biến để thu thập các phép đo và dữ liệu chất lượng, về mặt phân tích mã tĩnh, xem xét mã, kết quả kiểm tra hành vi và hiệu suất, và tạo ra các báo cáo đẹp và mọi thứ ... vẫn khó khăn để khiến doanh nghiệp chấp nhận liên tục phương pháp tái cấu trúc. Các giá trị kinh doanh của nó. "Chúng tôi đang theo một quy trình nhanh, và điều này sẽ không mang lại bất kỳ sự cải tiến nào cho các tính năng, phải không?" . Về cơ bản, bằng cách đó họ đang phủ nhận sự tồn tại của nợ kỹ thuật. Tôi thấy đây là bước thiếu cần thiết phổ biến để có thể bắt đầu bất kỳ quá trình chuyển đổi nào từ kiến ​​trúc nguyên khối sang kiến ​​trúc microservice.

Tái lập

Sau tất cả những điều này, bạn vẫn có thể muốn cung cấp một chế độ xem giống như kho lưu trữ trong đó bạn có thể xây dựng nhiều hơn một sản phẩm. Vì bất kỳ lý do gì, tức là phát hành hiện tại / tiếp theo, multibrand, khách hàng xây dựng. Các công cụ như google repo có thể giúp ích trong trường hợp này. Không bao giờ sử dụng một mình, nhưng tôi biết tôi sẽ cần một ngày.

Thử nghiệm hội nhập

Với microservice, thử nghiệm tích hợp giả định một bối cảnh khác, về "API riêng của thử nghiệm". Các lớp thử nghiệm cao hơn, chức năng hoặc hiệu suất, có thể và sẽ tồn tại, nhưng chúng có ý nghĩa nhiều nếu không có thử nghiệm tích hợp thích hợp? Nó sẽ giống như có thử nghiệm tích hợp mà không cần thử nghiệm đơn vị. Dĩ nhiên là không. Đó là lý do tại sao, nếu bạn cần git bisect, bạn sẽ thực thi nó trong một nhánh kho lưu trữ microservice, hãy quên việc chạy nó trong kho bùn.

Tái bút đây là bản nháp, tiếng anh của tôi rất tệ và một ngày nào đó tôi sẽ sửa nó