Git: Các bước chuyển từ Perforce sang Git

Như chúng ta đã thảo luận trong bài viết trước, Git hiện là sự lựa chọn thực tế cho SCM cho bất kỳ loại phát triển kỹ thuật số nào. Nhưng nếu bạn có nhiều năm lịch sử có giá trị được lưu trữ trong Perforce, có lẽ bạn đang cân nhắc chi phí chuyển đổi. Trong bài viết này, chúng tôi sẽ giải quyết những vấn đề đó ngay từ đầu và cho bạn biết cách di chuyển dữ liệu sang Git. Chúng tôi đã phá vỡ quy trình di chuyển Perforce sang Git xuống còn 8 bước:

• Di chuyển dữ liệu Perforce
• Ánh xạ người dùng và quyền vào một repo Git mới
• Tệp nhị phân lớn
• Phụ thuộc phức tạp
• Cấu trúc nhóm của bạn trong quá trình di chuyển
• Phản ánh dữ liệu
• Công cụ ALM
• Cách xác định thành công sau khi di chuyển Perforce sang Git

Bước 1: Di chuyển dữ liệu Perforce

Có hai cách tiếp cận chung để chuyển dữ liệu từ Perforce sang Git. Trước khi đi sâu vào khu vực đó, chúng ta cần xem xét một sự khác biệt cơ bản giữa cách Perforce và Git xử lý các dự án phần mềm.

Một máy chủ Perforce có thể chứa hàng chục hoặc hàng trăm dự án phần mềm riêng biệt, mỗi dự án có mô hình phân nhánh riêng. Một nhà phát triển định nghĩa một chế độ xem của Wap, thông báo cho máy chủ Perforce biết tập tin nào sẽ được đưa vào một bản sao đang hoạt động. Mặt khác, một kho lưu trữ Git thường chứa một dự án phần mềm và các nhánh và thẻ của nó (mặc dù các kho Git nguyên khối lớn vẫn tồn tại). Bạn thường nhân bản repo và, có lẽ, kiểm tra các mô hình con hoặc cây con.

Sau đó, câu hỏi về việc di chuyển dữ liệu có hai phần: làm thế nào để trích xuất dữ liệu từ Perforce và làm thế nào để dịch dữ liệu đó thành một bộ kho Git tương đương.

Di chuyển dữ liệu Perforce Tùy chọn 1: Sử dụng Git Fusion

Nếu bạn muốn lưu giữ toàn bộ lịch sử dữ liệu của mình trong Perforce, bạn có thể sử dụng công cụ Git Fusion của riêng Perforce để trích xuất một phần của máy chủ Perforce (một dự án) vào repo Git. Về cơ bản, bạn:

• Cài đặt Git Fusion
• Thiết lập chế độ xem chính xác của dữ liệu của bạn, bao gồm cấu trúc phân nhánh
• Sử dụng bất kỳ ứng dụng khách Git nào để sao chép từ Git Fusion
• Đẩy repo của bạn vào Bitbucket

Hands-on example
*In order to work through this example you’ll need a Perforce server with Git Fusion already operational.*
Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches:
- //depot/acme/main/…
- //depot/acme/r1.0/…
- //depot/acme/r1.1/…
Keep in mind that with Perforce you see branches as additional directories in the tree.
Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file:
[@repo]
description = Acme project
charset = utf8
[master]
git-branch-name = master
view = //depot/acme/main/… …
[r1.0]
git-branch-name = r1.0
view = //depot/acme/r1.0/… …
[r1.1]
git-branch-name = r1.1
view = //depot/acme/r1.1/… …
Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config
Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards.
Next, clone from Git Fusion:
git clone https://<git fusion server url>/acme
cd acme
git remote add bitbucket <bitbucket project URL>
git push –u --all bitbucket
git push --tags Bitbucket
That’s it! You should now see the imported history in Bitbucket.

Bây giờ, điều này có thể không phải lúc nào cũng cung cấp cho bạn một bản sao trung thực 100% dữ liệu Perforce của bạn. Có một số hoạt động của Perforce, như sáp nhập một phần, không có tương đương trong Git. Nhưng tất cả trong tất cả, phương pháp này sẽ có được hầu hết lịch sử của bạn mà không cần quá nhiều nỗ lực.

Hãy nhớ rằng việc lưu giữ lịch sử phân nhánh 10 năm qua khỏi một di sản SCM không có nghĩa là bạn phải tiếp tục sử dụng cùng một quy trình công việc. Đáng chú ý, bạn nên xem xét việc áp dụng các quy trình công việc nhánh tính năng như Git Flow là bước đầu tiên thực tế.

Ưu và nhược điểm

• Yêu cầu nhiều công việc thiết lập và thời gian chạy nhất
• Giữ gìn lịch sử nhất (cho phép bạn tắt máy chủ Perforce cũ)
• Duy trì mô hình phân nhánh kế thừa trong lịch sử

Di chuyển dữ liệu Perforce Tùy chọn 2: Bắt đầu lại

Tùy chọn khác là bắt đầu lại. Quên tất cả lịch sử tồi tệ đó: chỉ cần trích xuất phần đầu (mẹo) của mỗi chi nhánh trong Perforce tương ứng với dự án của bạn và kiểm tra nội dung đó vào một repo Git trống mới. (Điều này ngụ ý rằng bạn có không gian làm việc Perforce được xác định với 'chế độ xem' chính xác của dữ liệu bạn muốn.)

Đây là kỹ thuật đơn giản và nhanh nhất. Cho dù lịch sử Perforce của bạn phức tạp đến mức nào, repo Git mới của bạn vẫn gọn gàng và có ý nghĩa. Bạn có cơ hội bắt đầu một quy trình làm việc dựa trên Git mới mà không có bất kỳ hành lý tích lũy nào.

Hạn chế chính là bạn có thể muốn giữ máy chủ Perforce cũ ở chế độ chỉ đọc trong trường hợp bất kỳ ai cần đào sâu vào mã lịch sử vì bất kỳ lý do nào. Điều này sẽ không làm bạn mất bất kỳ chi phí giấy phép nào nhưng điều đó có nghĩa là bạn sẽ giữ máy chủ cũ đó tồn tại được một thời gian.

**Hands-on example**
Go into your Perforce workspace (the directory where the master branch of your project data is checked out) and run:
p4 sync
This fetches the latest revision of your files.
Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards.
Next, create a new Git repo in your workspace and push to Bitbucket:
git init .
git remote add origin <bitbucket project URL>
git push –u --all origin
git push --tags origin
You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.

Ưu và nhược điểm

• Nhanh chóng và đơn giản
• Thiết kế lại mô hình phân nhánh và quy trình làm việc
• Máy chủ Legacy Perforce được sử dụng để truy cập chỉ đọc

Bước 2: Người dùng và quyền

Sau khi dữ liệu được chuyển qua, nhiệm vụ tiếp theo thường là bắt đầu ánh xạ người dùng và quyền của bạn vào các dự án Bitbucket mới. Nếu bạn sử dụng LDAP cho một thư mục người dùng, bạn sẽ tiết kiệm được một chút thời gian ở đây. Mặt khác, bạn có thể dễ dàng trích xuất một tập hợp các tài khoản người dùng từ Perforce bằng lệnh p4 người dùng p4 và sau đó nhập chúng vào Bitbucket một dự án tại một thời điểm.

Việc dịch các quyền của Perforce thành các quyền Bitbucket tương đương có thể khó khăn vì các quyền của Perforce là chi tiết và phức tạp, với khả năng loại trừ quyền truy cập vào các tệp riêng lẻ. Lược đồ cấp phép phức tạp này là một lý do khiến máy chủ Perforce có thể ngừng hoạt động - mọi nỗ lực truy cập có thể khiến máy chủ thực hiện một tính toán đắt tiền trên cấu trúc dữ liệu phức tạp.

Trong hầu hết các trường hợp, chỉ cần yêu cầu dự án dẫn đến xác định một nhóm quyền đơn giản hơn trong Bitbucket bằng cách sử dụng các quyền cấp dự án, repo và cấp chi nhánh thông thường. Thật vậy, dù sao bạn cũng sẽ muốn xem lại thiết lập quyền của mình, vì Git cung cấp rất nhiều tùy chọn quy trình công việc mới. Ví dụ: trong Perforce, bạn có thể đã hạn chế tạo chi nhánh, trong khi trong Bitbucket, bạn có thể chỉ cần hạn chế quyền truy cập đẩy vào nhánh chính.

Bước 3: Tệp nhị phân

Nếu bạn đã lưu trữ các đốm nhị phân lớn trong Perforce, hãy suy nghĩ cẩn thận về cách bạn muốn quản lý những người trong Git. Bạn có thể dùng thử Git LFS hoặc đơn giản là bạn có thể sử dụng hệ thống quản lý tạo tác thông thường để thay thế. Trong mọi trường hợp, bạn không muốn mù quáng đẩy những đốm sáng lớn vào repo Git.

Bước 4: Phụ thuộc phức tạp

Một bản sao làm việc của Perforce thực sự có thể ánh xạ trong các bản sao dữ liệu chỉ đọc từ một số mô-đun. Trong Git, điều này được thực hiện bằng cách sử dụng các mô hình con, cây con hoặc bằng cách tận dụng các hệ thống quản lý CI / CD hoặc tạo tác. Không có câu trả lời dễ dàng ở đây, nhưng một số công cụ nhập dữ liệu có thể mô hình hóa mối quan hệ mô hình con giữa các repos Git. Để có cái nhìn sâu hơn về cách sử dụng các mô hình con hoặc cây con, bạn có thể đọc về từng loại ở đây:https://bloss.atlassian.com/2013/05/alternigin-to-git-submodule-git-subtree/ .

Bước 5: Cách cấu trúc nhóm của bạn trong quá trình di chuyển

Vì vậy, máy chủ Perforce của bạn có 100 dự án từ 10 đội. Bạn đã có một chiến lược di chuyển và bộ công cụ được đặt ra. Lịch trình cửa sổ bảo trì và đi!

Không có.

Hãy nhớ rằng việc chuyển đổi các công cụ SCM cũng giống như các nhà phát triển cũng như dữ liệu. Bạn đã có người, xử lý và lên lịch để xem xét - đừng cố gắng làm sôi đại dương trong một ngày. Đó là quá rủi ro.

Bạn cần xem xét một kế hoạch dự án trong giai đoạn di chuyển thực tế. (Đây có thể là thời điểm tốt để thử một luồng công việc Jira mới) Dưới đây là một số tùy chọn bạn có thể xem.

• Di chuyển theo nhóm và theo từng dự án. Mục đích để bắt đầu một dự án và nhóm khi bắt đầu tăng tốc nước rút hoặc chương trình, khi bạn có thời gian để thích nghi.
• Di chuyển tăng dần. Nhập tất cả dữ liệu của bạn vào cuối tuần, nhưng sau đó cho phép các nhóm từ từ hoàn thành việc chuyển sang Git theo thời gian. Định kỳ lấy đồng bằng bằng cách chạy lại các công cụ nhập khẩu của bạn. Mặc dù phức tạp hơn, chiến lược này không tệ nếu bạn có sự phụ thuộc giữa các nhóm và những người chấp nhận sớm cần ít nhất một ảnh chụp nhanh gần đây trong Git để cung cấp đường ống CI / CD của họ.
• Sử dụng cả hai hệ thống cùng một lúc trong một khoảng thời gian. Mặc dù không dành cho người yếu tim, nhưng về mặt kỹ thuật, việc sử dụng Git Fusion để thực hiện trao đổi dữ liệu hai chiều miễn là bạn không thực hiện các thao tác phức tạp sẽ gây nhầm lẫn cho trình dịch dữ liệu.

Cuối cùng, đầu tư vào việc truyền đạt các thay đổi cho nhóm - động lực, lý do và một loạt các bước để làm điều đó. Chọn một nhóm người nhận nuôi sớm, với các kỹ sư có kinh nghiệm trong toàn bộ vòng đời phát triển phần mềm và để nhóm đó trở thành hình mẫu cho những người khác. Tìm nhà vô địch Git để hỗ trợ mọi người khi họ gặp khó khăn. Thực hiện những thay đổi nhỏ, dễ hiểu, lặp đi lặp lại sẽ giúp quá trình này thành công.

Bước 6: Gương và cụm

Perforce có một hệ thống đơn giản nhưng hiệu quả để phản chiếu dữ liệu đến các trang web từ xa để giảm ảnh hưởng của độ trễ. Nó có một hệ thống phức tạp hơn để chạy một bộ gương cục bộ để phân cụm chỉ đọc. Mặc dù độ trễ đơn giản không phải là mối quan tâm của Git, nhưng nếu bạn đang điều hành một hoạt động trên toàn thế giới, bạn nên xem Trung tâm dữ liệu Bitbucket để phân cụm và phản chiếu, điều này sẽ tăng tốc đáng kể thời gian nhân bản của bạn cho một nhóm toàn cầu.

Bước 7: Công cụ ALM

Và bây giờ đối với một số tin tức tốt - bạn đã có rất nhiều sự lựa chọn cho ngăn xếp công cụ ALM của mình khi bạn chuyển từ Perforce sang Git. Khá nhiều nhà phát triển và công cụ ALM ngoài kia hoạt động với Git, và tất nhiên Bitbucket mang đến cho bạn sự tích hợp tuyệt vời với Jira và Bamboo. Khi bạn chuyển sang Git, bạn có thể khám phá các tính năng của Tre như Chi nhánh Kế hoạch , tận dụng quy trình làm việc của chi nhánh tính năng.

Bước 8: Xác định thành công

Vậy làm thế nào để bạn đo lường chính xác thành công trong quá trình di chuyển từ Perforce sang Git? Trong nhiều dự án di chuyển, chúng tôi có xu hướng tập trung quá nhiều vào tính trung thực của truyền dữ liệu. Nhưng đó không phải là một số liệu hữu ích vì nhiều lý do. Có vẻ như bạn không bao giờ có thể có được lịch sử từng bit trong Git, chính xác tương đương với những gì đã xảy ra trong một hệ thống SCM tập trung như Perforce.

Một cách tiếp cận thực tế hơn là sử dụng CI / CD để xác minh. Khi bạn chuyển đổi đường ống CI / CD của mình từ Perforce sang Git, tất cả các bài kiểm tra của bạn vẫn vượt qua? Và bạn vẫn có thể triển khai phần mềm của mình chứ? Nếu tất cả các bản dựng cũ quan trọng của bạn vẫn có thể đi qua đường ống CI / CD của bạn, thì đã đến lúc tuyên bố chiến thắng!

Đó là một bọc

Vì vậy, bây giờ bạn đã thấy tại sao có sự chuyển động từ Perforce sang Git và làm thế nào để thực sự đến đó. Bước tiếp theo là chọn giải pháp Git. Nếu bạn đang chuyển đổi từ Perforce để phát triển trò chơi, hãy xem lý do tại sao các nhà phát triển trò chơi yêu thích Bitbucket .