Di chuyển từ GitLab sang GitHub｜Giới thiệu phương pháp từ so sánh đến triển khai

Kanno

Xin chào, tôi là Sugano, một người quản lý yêu thích sự phát triển và yêu thích ramen.

Chúng tôi đã sử dụng GitLab trong một thời gian dài tại Sun-El, nhưng chúng tôi đã quyết định chuyển sang GitHub.Trang web chính thức của GitLabĐiều này là do gói Miễn phí đã bị giới hạn ở 5 người dùng trên mỗi không gian tên kể từ ngày 19 tháng 10 năm 2022, như được mô tả trong . Không phải là tôi không hài lòng với chức năng của GitLab, nhưng tôi vẫn sẽ sử dụng nó nếu không có sự thay đổi này. Giống như Docker, có phải vì GitLab đã được công khai? GitHub hiện có một kho lưu trữ riêng miễn phí, nhưng GitLab dường như có giới hạn chặt chẽ hơn đối với bậc miễn phí. Có vẻ như có khá nhiều người đã được di cư với sự thay đổi này.

Trong bài viết này, tôi sẽ giới thiệu những gì tôi học được sau khi thực sự chuyển sang GitHub thông qua quá trình cân nhắc giới thiệu. Tôi hy vọng nó sẽ hữu ích cho những người đang thu thập thông tin về di cư và những người đang cân nhắc nên giới thiệu cái nào.

Về tình hình của San-El trước khi chuyển sang GitHub và đối tượng mục tiêu của bài viết này

Trước khi vào chủ đề chính, tôi xin giới thiệu về hoàn cảnh của San-El trước khi chuyển sang GitHub.

• Đã sử dụng GitLab hơn 10 năm
• GitLab có 7 kỹ sư, 3 người thử nghiệm và 3 người quản lý dự án
• GitLab CI đã được sử dụng để xây dựng CI/CD
• GitHub đã được sử dụng cho các lý do dự án như ký gửi

Xin lưu ý rằng bài viết này không giải thích kiến thức cơ bản về Git hoặc cách cài đặt node.js.

Chuyển từ kiểm tra so sánh GitLab và GitHub sang di chuyển

Phần kết luận

Đối với những người muốn có cái nhìn tổng quan nhanh về sự khác biệt giữa GitLab và GitHub, đây là kết luận của tôi trước tiên.

• Nếu thang điểm từ 5 trở xuống, GitLab miễn phí nên bạn có thể sử dụng nếu muốn.
• GitHub nếu bạn không thể đưa ra $19/tháng cho mỗi người. GitHub miễn phí hoặc $4/tháng cho mỗi người
• hết $19/tháng,Chức năng quản lý dự ánGitLab nếu bạn coi trọng
• Nếu chi phí học tập là quan trọng, GitHub. GitLab có ít người dùng hơn (đặc biệt là ở Nhật Bản) so với GitHub

Phần 1 Cân nhắc có nên tiếp tục GitLab

Nếu tôi muốn tiếp tục sử dụng GitLab, tôi có ba lựa chọn:

1. Tránh 5 người dùng trên mỗi không gian tên
2. Nâng cấp lên phiên bản trả phí
3. Di chuyển sang phiên bản tự quản lý nơi bạn thiết lập máy chủ của riêng mình

Đầu tiên là sự từ chối ngay lập tức. Nói một cách đơn giản, bạn chỉ có thể sử dụng tối đa 5 người cho mỗi dự án. Ngoài ra, việc quản lý trở nên khá phức tạp. Tiếp theo là 2,kế hoạchChỉ có ba, Miễn phí, Cao cấp và Cuối cùng và Cao cấp có giá $19. Này, tôi không muốn trả số tiền đó đâu. Phần còn lại là 3, nhưng ban đầu Sanel sử dụng phiên bản Tự quản lý. Và hai năm trước. Tuy nhiên, chúng tôi đã phải chuyển sang phiên bản đám mây vì chúng tôi không chỉ phải bảo trì máy chủ mà còn phải tự nâng cấp phiên bản, vì vậy tôi không muốn quay lại phiên bản tự quản lý.
Vì vậy, tôi quyết định chuyển từ GitLab sang GitHub.

Phần 2 Xem xét kế hoạch định giá GitHub

GitHub có ba gói, Miễn phí, Nhóm và Enterpise và Nhóm là 1 TP4T4 mỗi người dùng mỗi tháng. Nó khá tận tâm so với GitHub. Enterpise là $21 nên bạn có thể thấy GitLab đắt như thế nào. Ngay từ đầu, GitLab có khá nhiều chức năng quản lý dự án, vì vậy tôi đoán bạn không nên so sánh giá cả đơn giản ngay từ đầu.

So sánh từng kế hoạchnhững ai quan tâm đến thì vui lòng hãy check thử trên websiteVà để lại cho các trang khác, tôi nghĩ rằng hai điểm sau đây là điểm Free hay không tốt.

1. Tôi không thể tạo mã thông báo Tổ chức
2. Tôi không thể tạo yêu cầu kéo dự thảo
3. Không thể đặt nhánh được bảo vệ

Trước đây, có giới hạn đối với Kho lưu trữ riêng, vì vậy khi các công ty sử dụng nó, phiên bản trả phí (Nhóm) là bắt buộc, nhưng giờ đây bạn có thể tạo Kho lưu trữ riêng không giới hạn ngay cả với phiên bản Miễn phí. Vì lý do này, nếu hai điểm này không phải là vấn đề, tôi nghĩ rằng miễn phí là đủ. Tất nhiên, tôi nghĩ nó phụ thuộc vào nơi bạn đặt tầm quan trọng, nhưng Sanel sử dụng Notion để quản lý tài liệu, vì vậy GitHub Wiki là không cần thiết và 2.000 phút mỗi tháng cho GitHub Actions là đủ.

Khá là bất tiện khi không dùng được Organization token của 1, và mỗi dự án đều phải dùng PAT (Personal Access Token) của user phụ trách, mà quản lý thì không ổn nên khá rắc rối. 2 và 3 là các chức năng có thể được sử dụng ngay cả trong phiên bản miễn phí của GitLab, vì vậy thật đáng tiếc khi không thể sử dụng chúng. Nó sẽ dẫn đến sự cố vận hành, vì vậy quy mô phát triển, chẳng hạn như xây dựng CI/CD, là khó khăn với Free.

Tại San-El, chúng tôi đã sử dụng phiên bản Miễn phí trong thời gian hiện tại và đã chuyển sang phiên bản này, nhưng vì hai điểm này có vấn đề nên chúng tôi dự định chuyển sang phiên bản Nhóm trong tương lai.

Phần 3 Ấn tượng khi thực sự chuyển sang GitHub

Đó là điểm tốt

Tích hợp Slack tiện lợi

Đối với tôi, điều này là tốt nhất. Bạn cũng có thể liên kết với GitLab, nhưng vì không có cơ chế đăng nhập nên nội dung của Sự cố sẽ không hiển thị trên Slack. Để so sánh, GitHub cho phép bạn xem nội dung của các vấn đề từ Slack và bạn cũng có thể nhận xét và đóng chúng. Ngoài ra, nếu bạn đăng nhập vào GitHub từ Slack, tên tài khoản GitHub của bạn sẽ được chuyển đổi thành tên tài khoản Slack của bạn, vì vậy bạn chắc chắn sẽ được nhắc đến trên Slack. GitLab rất bất tiện cho việc này. Người ta cho rằng ứng dụng GitHub có thể được cài đặt trong Slack, nhưng trong kênh đích

/github đăng nhập

Tất cả bạn phải làm là nhập và làm theo hướng dẫn. Rất dễ.

GitHub Actions nhanh hơn và dễ dàng hơn

Tôi nghĩ điều này phụ thuộc vào những gì bạn muốn làm với CI/CD và đó có thể là sở thích của bạn, nhưng tôi cảm thấy rằng GitHub Actions dễ xây dựng hơn GitLabCI. Tôi nghĩ rằng điều này phần lớn là do số lượng lớn người dùng và sự hiện diện của MarketPlace. Có những hành động phổ biến nhất và bạn thường có thể tìm thấy cách thực hiện bằng cách tra cứu trên Google. GitLab CI có cảm giác giống như viết một tập lệnh, nhưng GitHub Actions có cảm giác giống như gọi Hành động và thực thi nó.

Ứng dụng điện thoại thông minh tiện lợi

Điều này hoàn toàn bất ngờ cho đến khi bạn dùng thử, nhưng nó rất tiện lợi. Đặc biệt là xung quanh xác thực. Xác thực hai yếu tố quá rắc rối nếu không có ứng dụng, vì vậy tôi không thể bỏ qua. Ngoài ra, đây là cách sử dụng nó với tư cách là người đánh giá, nhưng với ứng dụng GitHub, bạn có thể thực hiện đánh giá bằng cách nào đó. GitLab ngay từ đầu không có ứng dụng nên bạn chỉ có thể xem nó bằng trình duyệt, còn với smartphone thì khá khó thao tác. Tôi đi du lịch rất nhiều, vì vậy sẽ rất thuận tiện nếu có thể vội vàng xem lại mọi thứ trên điện thoại thông minh của mình, nhưng tôi đã từ bỏ GitLab. Nó không thoải mái bằng ứng dụng GitHub, nhưng bạn có thể xem lại, nhận xét và hợp nhất bình thường.

điểm xấu

Đúng như dự đoán, chức năng quản lý dự án sẽ được chuyển lên GitLab.

Không thể nhóm kho lưu trữ

Điều này thật bất tiện. Đặc biệt nếu bạn muốn tách các kho lưu trữ mặt trước và mặt sau, nhưng bạn muốn quản lý chúng như một dự án. Về khía cạnh đó, GitLab thuận tiện vì có thể nhóm các kho lưu trữ và quản lý Nhãn sự cố và Cột mốc theo cách chia sẻ. Ngoài ra, vì không có nhóm nên không thể có nhãn thống nhất cho các vấn đề trong tổ chức. Bạn có thể đặt Nhãn mặc định trong cài đặt Tổ chức, tuy nhiên đây chỉ là nhãn mặc định khi tạo kho lưu trữ nên nếu bạn muốn thêm Nhãn này cho toàn bộ tổ chức thì không thể thêm tất cả cùng một lúc.

Không thể quản lý Ban (Kanban) chỉ với Vấn đề

GitLab có thể tự đặt Ngày đến hạn và Cột mốc trong Sự cố và quản lý chúng trong chế độ xem bảng, nhưng GitHub không có tính năng đó trong Sự cố, nó có một tính năng gọi là Dự án. Và nó là một cơ chế có thể được quản lý bằng cách liên kết Dự án và Kho lưu trữ.
Lúc đầu, tôi nghĩ điều này sẽ hữu ích vì nó cho phép bạn đóng gói nhiều kho lưu trữ. Tuy nhiên, khi bạn thực sự sử dụng nó, nó thực sự bất tiện. Tôi nghĩ đó là vấn đề với cấu trúc giao diện người dùng, nhưng GitHub cũng có một khía cạnh là bạn không thể quản lý các bảng trên màn hình sự cố và bạn không thể thực hiện các thao tác chi tiết về các sự cố trên màn hình bảng. Là một người quản lý dự án, cảm giác vận hành chi tiết thật căng thẳng.

Phương pháp di chuyển thực tế

Từ đây, chúng tôi sẽ giải thích công việc di chuyển thực tế. Thật dễ dàng để di chuyển mã nguồn, nhưng vấn đề là di chuyển Sự cố và Yêu cầu Hợp nhất. cuộc di cư nàyhttps://github.com/piceaTech/node-gitlab-2-githubsử dụng một công cụ gọi là Cách sử dụng được mô tả khá cẩn thận trong README, nhưng quy trình chính như sau.

1. git clone nút-gitlab-2-github
2. cài đặt npm
3. Phản chiếu từ kho lưu trữ GitLab sang kho lưu trữ GitHub
4. Sao chép sample_settings.ts vào stings.ts
5. chỉnh sửa settins.ts
6. bắt đầu chạy npm

Để biết chi tiết về từng phương pháp, hãy xem README, vì vậy tôi sẽ bỏ qua chúng và giải thích các điểm chính.

Những gì phương pháp di chuyển này không giải quyết

Công cụ này có thể di chuyển Sự cố và Yêu cầu Hợp nhất, nhưng không phải tất cả đều di chuyển một cách hoàn hảo. Tôi nghĩ rằng tất cả chúng đều có thể chấp nhận được, nhưng nếu các nội dung sau không được chấp nhận thì không thể sử dụng phương pháp di chuyển này.

Không thể di chuyển yêu cầu hợp nhất không có nhánh nguồn sang yêu cầu kéo

Nếu có nhánh nguồn, yêu cầu hợp nhất có thể được chuyển đổi thành yêu cầu kéo, nhưng nếu nhánh nguồn được đặt thành bị xóa khi hợp nhất, yêu cầu hợp nhất không có nhánh nguồn sẽ được chuyển đổi thành sự cố thay vì yêu cầu kéo. Sau khi được di chuyển, nó sẽ tự động được gắn nhãn là yêu cầu hợp nhất gitlab và được thêm vào vấn đề đã đóng.

Không thể di chuyển các tệp đính kèm Sự cố và Yêu cầu Hợp nhất

Các tệp đính kèm có thể được tải lên S3 bằng chức năng tùy chọn của công cụ, nhưng vì nó không thay thế URL tham chiếu đến tệp, nên nó sẽ lưu tệp đính kèm từ GitLab sang S3.

Thông tin về chủ sở hữu vấn đề không thể kế thừa

Chủ sở hữu của tất cả các Vấn đề sẽ là tài khoản thực thi khi di chuyển lần này, chính xác thì nó sẽ là tên tài khoản được đặt trong script khi thực thi, vì vậy bạn sẽ không biết ai đã phát hành Vấn đề khi được ban hành trong GitLab.

Không thể di chuyển các sự cố không có người dùng mục tiêu

Nếu người dùng được đặt là Người được chỉ định hoặc Người đánh giá không tồn tại trong GitHub, thì không thể di chuyển Sự cố và sẽ xảy ra lỗi. Càng nhiều càng tốt, tốt hơn là nên có tài khoản trên GitLab nguồn và GitHub đích.

1. Chuẩn bị

Nhận tài khoản GitHub của tất cả người dùng mà bạn muốn di chuyển và biết ID tài khoản GitHub của họ. Bạn cũng cần tạo Tổ chức GitHub. Nó không khó để tạo ra. Khi bạn đã sẵn sàng, trước tiên hãy tạo một kho lưu trữ để chuyển sang GitHub. Miễn là bạn có kho lưu trữ để di chuyển đến, bạn có thể để cài đặt kho lưu trữ làm mặc định trong thời gian này. Tiếp theo là phản chiếu tới GitHub, nhưng đây làSơ bộ READMEChỉ cần làm những gì phần nói và bạn sẽ ổn thôi.

2. Sửa mã

Đó là nút-gitlab-2-github, nhưng có 3 vấn đề với mã như hiện tại, vì vậy tôi đã sửa cục bộ và xử lý nó.

Thêm đầu ra lỗi

Hiện tại, tôi đã thêm đầu ra vì tôi không biết nguyên nhân khi tệp đính kèm không tải lên được.

       return Buffer.from(data, 'binary'); } catch (err) { + console.log(`err=${err}`) console.error(`Không thể tải xuống tệp đính kèm #${relurl}.`); return null;

Phải làm gì khi Nhãn bị trùng lặp trong Nhãn nhóm và Nhãn dự án

Thật không tốt khi Nhãn bị trùng lặp ngay từ đầu, nhưng tiếc là Nhãn nhóm và Nhãn dự án đã bị trùng lặp. Có lẽ nó được tạo ra do nhầm lẫn và không được chú ý, nhưng trong trường hợp này đã xảy ra lỗi và quá trình chuyển không thể thực hiện được. Vì vậy, tôi đã thêm mã để buộc sao chép.

       if (settings.conversion.useLowerCaseLabels) { nhãn = nhãn.map((el: string) => el.toLowerCase()); } + nhãn = Array.from(Bộ mới(nhãn)) }

Thư từ khi tiếng Nhật có trong file đính kèm

Tôi nghĩ điều này là bình thường. Đặc biệt đối với các ảnh chụp màn hình kèm theo sự cố lỗi, tên tệp mặc định bao gồm tiếng Nhật. Vì lý do này, tôi đã sửa đổi nó thành mã hóa URL.

   async getAttachment(relurl: string) { try { - const attachmentUrl = this.host + '/' + this.projectPath + relurl; + const attachmentUrl = encodeURI(this.host + '/' + this.projectPath + relurl); const data = (

3. Chỉnh sửa và chạy settings.ts

cách chỉnh sửaNơi tìm thông tin cho settings.ts trong READMENó được mô tả chi tiết nơi thông tin được viết. Vị trí của AccessToken cũng được giải thích cẩn thận, vì vậy tôi không nghĩ rằng bạn sẽ bị lạc. Khi bạn đã sẵn sàng, hãy chạy npm run start và bạn sẽ thấy đầu ra bên dưới.

$ npm run start > gitlab-2-github@0.1.5 start > node node_modules/ts-node/dist/bin.js ./src/index.ts ================================================= Chuyển Mô tả ============================================================================== Chuyển các Cột mốc =================================================================================================================================== Chuyển vòng Nhãn ================================================= Tạo: đang xem xét Tạo: thử nghiệm Tạo: thử nghiệm Tạo: sang do Đã tồn tại: Đang tạo: thảo luận Đã tồn tại: tài liệu Đã tồn tại: tài liệu === Đang chuyển các bản phát hành ================================== Đang chuyển 0 bản phát hành ================================================= Đang chuyển các vấn đề =================================== Đang chuyển 14 vấn đề 1. Đang di chuyển vấn đề #1 ('danh sách tài khoản')... Đang di chuyển các nhận xét về vấn đề... ...Hoàn tất việc tạo nhận xét (đã di chuyển 11 nhận xét, bỏ qua 3 nhận xét) ...XONG vấn đề di chuyển #1. ================================================= Đang chuyển các yêu cầu hợp nhất ================================================= 218 yêu cầu hợp nhất Tạo yêu cầu kéo: !1 - Tạo môi trường phát triển Yêu cầu kéo #1 (nhánh nguồn 'sugano/basic_structure' không tồn tại => không thể di chuyển yêu cầu kéo, thay vào đó tạo ra sự cố. Di chuyển nhận xét yêu cầu kéo... ...Hoàn tất việc tạo nhận xét (đã di chuyển 24 nhận xét, bỏ qua 3 nhận xét) ...Hoàn tất tạo nhận xét (đã di chuyển 3 nhận xét, bỏ qua 0 nhận xét) Hoàn tất chuyển!

Nhân tiện, phải mất một thời gian dài để chạy. Mặc dù nó phụ thuộc vào số lượng vấn đề và yêu cầu kéo, nhưng mất khoảng một giờ cho tổng số 500 trường hợp.

4. Viết lại từ GitLabCI sang GItHub Actions

Chà, quá trình di chuyển kho lưu trữ đã hoàn tất. Nó không phải là một vấn đề lớn nếu nó kết thúc với những điều trên. Di chuyển rườm rà nhất là di chuyển CI/CD.

Hiện tại, GitHub mô tả phương pháp di chuyển từ GitLab Ci sang GitHub Actions.

https://docs.github.com/ja/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions

Tuy nhiên, theo tôi, tốt hơn hết là bạn nên học cách viết GitHubActions và viết lại từ đầu thay vì chỉ chuyển đổi phương thức mô tả. GitLab CI và GitHub Actions có cách suy nghĩ và phong cách khác nhau nên nếu bạn viết theo kiểu migration, bạn sẽ bị phong cách của GitLab kéo theo và cái hay của GitHub Actions sẽ phai nhạt.

Nếu bạn đã viết GitLab CI, bạn có thể áp dụng các Tác vụ GitHub tương đối dễ dàng nếu bạn ghi nhớ những điều sau.

Tóm tắt

Kanno

Nó thế nào? Đối với những người đang nghĩ đến việc di chuyển từ GitLab và những người đang băn khoăn không biết nên di chuyển cái nào từ Bitbucket, v.v., tôi sẽ đánh giá cao nếu bạn có thể giúp tôi.

Cá nhân mình dùng GitLab đã lâu nên quen và gắn bó với nó. Tại San-El, chúng tôi có trụ sở ở các vùng nông thôn, nhưng chúng tôi muốn tiếp tục cống hiến hết mình để không hạ thấp tầm quan trọng của chúng tôi đối với công nghệ.

Cuối cùng, chúng tôi tóm tắt các khuyến nghị của chúng tôi cho từng trường hợp.