Kiểm soát nguồn

Khi phát triển cho các thiết bị nhúng và các thế giới kỳ quặc khác, rất có thể quy trình xây dựng của bạn sẽ bao gồm nhiều tệp nhị phân độc quyền, sử dụng các phiên bản rất cụ thể của chúng. Vì vậy, câu hỏi là, chúng là một phần của kiểm soát nguồn của bạn? Các văn phòng của tôi tuân theo quy tắc "kiểm tra từ kiểm soát nguồn bao gồm mọi thứ bạn cần để biên dịch mã" và điều này đã dẫn đến một số đối số nghiêm trọng.

Các đối số chính mà tôi thấy chống lại điều này là làm đầy DB kiểm soát nguồn, thiếu các tệp nhị phân khác nhau ( xem các câu hỏi trước về chủ đề này) . Điều này chống lại khả năng kiểm tra, xây dựng, biết rằng bạn có môi trường chính xác mà nhà phát triển trước đó dự định và không tìm kiếm các tệp thích hợp (với các phiên bản cụ thể không hơn không kém!)

Ý tưởng của VERSION KIỂM SOÁT (viết sai: kiểm soát nguồn) là cho phép bạn quay ngược lại lịch sử, khôi phục hiệu quả của các thay đổi, xem các thay đổi và lý do thực hiện. Đây là một loạt các yêu cầu, một số trong đó cần điều nhị phân, một số trong đó không.

Ví dụ: Đối với công việc phần mềm nhúng, thông thường bạn sẽ có một chuỗi công cụ hoàn chỉnh: hoặc là trình biên dịch độc quyền có giá rất nhiều tiền hoặc một số phiên bản của gcc. Để có thể thực hiện vận chuyển, bạn cần có toolchain cũng như nguồn.

Kiểm tra các công cụ vào kiểm soát phiên bản là một nỗi đau, các tiện ích khác là khủng khiếp (nếu có), nhưng không có sự thay thế. Nếu bạn muốn chuỗi công cụ được bảo tồn cho anh chàng đến xem mã của bạn sau 5 năm để tìm hiểu xem nó làm gì, thì bạn không có lựa chọn nào khác: bạn cũng phải có bộ công cụ dưới sự kiểm soát phiên bản.

Trong nhiều năm qua, tôi đã phát hiện ra rằng phương pháp đơn giản nhất để thực hiện việc này là tạo một hình ảnh ZIP hoặc ISO của CD cài đặt và kiểm tra điều này. Nhận xét đăng ký cần phải là số phiên bản nhà sản xuất cụ thể của chuỗi công cụ. Nếu gcc hoặc tương tự, sau đó kết hợp mọi thứ bạn đang sử dụng vào một ZIP lớn và làm tương tự.

Trường hợp cực đoan nhất mà tôi đã thực hiện là Windows XP Embedded trong đó "toolchain" là Windows XP VM đang chạy, bao gồm (trước đó) SQL Server và một chồng tệp cấu hình cùng với hàng trăm và hàng trăm tệp vá. Cài đặt toàn bộ lô và cập nhật được sử dụng mất khoảng 2-3 ngày. Bảo toàn rằng cho hậu thế có nghĩa là kiểm tra ENTIRE VM vào kiểm soát phiên bản. Nhìn thấy như đĩa ảo được tạo thành từ khoảng 6 x 2GB hình ảnh, nó thực sự đã hoạt động khá tốt. Âm thanh trên đỉnh cao, nhưng nó làm cho cuộc sống rất dễ dàng cho người đến sau tôi và phải sử dụng nó - 5 năm sau.

Tóm tắt: Kiểm soát phiên bản là một công cụ. Sử dụng nó để có hiệu quả, đừng nôn nao về những thứ như nghĩa của từ và đừng gọi nó là "kiểm soát nguồn" vì nó lớn hơn thế.

Neal Ford lập luận trong Lập trình viên năng suất rằng bạn nên kiểm soát nhị phân trong nguồn:

Tại sao giữ nhị phân? Các dự án ngày nay phụ thuộc vào một loạt các công cụ và thư viện bên ngoài. Giả sử bạn đang sử dụng một trong các khung ghi nhật ký phổ biến (như Log4J hoặc Log4Net). Nếu bạn không xây dựng các tệp nhị phân cho thư viện ghi nhật ký đó như là một phần của quy trình xây dựng của mình, bạn nên giữ nó trong kiểm soát phiên bản. Điều đó cho phép bạn tiếp tục xây dựng phần mềm của mình ngay cả khi khung hoặc thư viện nghi vấn biến mất (hoặc, nhiều khả năng, giới thiệu một thay đổi đột phá trong phiên bản mới). Luôn giữ toàn bộ vũ trụ cần thiết để xây dựng phần mềm của bạn trong kiểm soát phiên bản(trừ hệ điều hành và thậm chí có thể thực hiện được với ảo hóa; hãy xem Sử dụng ảo hóa, sử dụng sau trong chương này). Bạn có thể tối ưu hóa các nhị phân giữ lại bằng cách giữ chúng trong kiểm soát phiên bản và trên một ổ đĩa mạng chung. Bằng cách đó, bạn không phải đối phó với chúng trên cơ sở hàng giờ, nhưng chúng được lưu trong trường hợp bạn cần xây dựng lại một cái gì đó một năm sau đó. Bạn không bao giờ biết nếu bạn sẽ cần phải xây dựng lại một cái gì đó. Bạn xây dựng nó cho đến khi nó hoạt động, sau đó quên nó. Thật hoang mang khi nhận ra rằng bạn cần phải xây dựng lại một cái gì đó từ hai năm trước và không có tất cả các bộ phận.

Tôi không thể đồng ý nhiều hơn; trong khi điều này được cho là lật đổ VCS cho một nhiệm vụ mà nó không được thiết kế để (giữ nhị phân), tôi nghĩ rằng lợi ích vượt xa những nhược điểm tiềm năng. Nhưng, như tác giả lưu ý sau này, đôi khi việc giữ các nhị phân trong VCS có thể không phải là một giải pháp thực tế, vì vậy các lựa chọn khác nên được xem xét - như giữ chúng trên một ổ đĩa mạng được ánh xạ.

Nếu các nhị phân không quá lớn, tôi chắc chắn sẽ giữ chúng trong VCS. Điều này dường như còn đúng hơn trong trường hợp của bạn, vì các nhị phân có thể nhỏ và bạn làm việc với các phiên bản rất cụ thể. Chúng cũng có thể khó tìm, vì nhiều lý do (các tác giả đóng trang web của họ hoặc phiên bản bạn cần không còn được liệt kê để tải xuống). Mặc dù không có khả năng, bạn không bao giờ biết điều gì sẽ xảy ra trong một vài năm.

Tôi ước tôi đọc cuốn sách này vài năm trước, khi tôi đang làm việc với một trò chơi bằng thư viện đồ họa (là tập tin dll); Tôi đã làm gián đoạn sự phát triển trong một thời gian và khi tôi muốn tiếp tục, tôi không thể tìm lại dll vì dự án đã chết.

Về nguyên tắc, tôi đánh giá cao trại "kiểm tra mọi thứ bạn cần để xây dựng thành kiểm soát nguồn", nhưng quản lý phụ thuộc đã phát triển khá nhiều trong vài năm qua, với các công cụ như Maven, Ivy và NuGet.

Ngoài ra, trong thực tế, tôi thấy việc kiểm tra nhị phân để tạo ra một số tác dụng phụ khó chịu. Ví dụ, Git / Mercurial không thực sự điều chỉnh cho nó, và Subversion và Perforce có thể khiến bạn phát điên khi hợp nhất các nhánh có chứa nhị phân.

Với giải pháp quản lý phụ thuộc, bạn chỉ định trong tệp được kiểm soát nguồn trong dự án của bạn, tên gói và phiên bản nào mà dự án của bạn phụ thuộc. Hầu như tất cả các công cụ quản lý phụ thuộc đều cho phép bạn tạo một kho lưu trữ riêng về các phụ thuộc của mình, tuân theo một số quy ước đặt tên và phiên bản; khi bạn thực hiện xây dựng, công cụ quản lý phụ thuộc sẽ giải quyết tất cả các phụ thuộc nguồn mở và quyền sở hữu của bạn từ danh sách các nguồn được phê duyệt, sau đó nhét chúng vào bộ đệm cục bộ của bạn. Lần tới khi bạn xây dựng với cùng phụ thuộc phiên bản, mọi thứ đã ở đó và nó sẽ nhanh hơn nhiều.

Kho lưu trữ riêng của bạn sau đó có thể được sao lưu bằng các công cụ sao lưu hệ thống tập tin thông thường.

Điều này tránh được sự chậm chạp mà tôi gặp phải khi hàng tấn nhị phân được kéo ra khỏi cây nguồn và ngăn kho lưu trữ của bạn có nhiều tệp khó phân biệt. Chỉ có một vị trí cho bất kỳ sự phụ thuộc nhất định nào, theo tên và số phiên bản, do đó không có xung đột hợp nhất để giải quyết và bộ đệm ẩn hệ thống tệp cục bộ có nghĩa là bạn không phải đối phó với chi phí đánh giá liệu bản sao cục bộ của bạn có thay đổi khi bạn kéo cập nhật.

Kiểm soát nguồn là cho các nguồn. Nguồn là những gì bạn không thể xây dựng từ những thứ khác. Một số tệp đủ điều kiện là nguồn xảy ra là nhị phân.

VCS của tôi có rất nhiều nhị phân được kiểm tra, nhưng mỗi cái là đơn vị phát hành từ một số sản phẩm tôi không viết và không duy trì. Đây có thể là một cái gì đó giống như GNU ccRTP, được phát hành dưới dạng tarball nén. Tarball đó là nguồn của tôi và nó đã được kiểm tra cùng với bất kỳ cơ sở hạ tầng nào tôi cần để biến nó thành một sản phẩm hoàn chỉnh (một thông số Makefile và RPM trong trường hợp của tôi) trong một bước tự động duy nhất. Khi có phiên bản ccRTP mới, tôi coi tarball mới là nguồn thay đổi: nó đi vào một bản sao đã thanh toán, được xây dựng, thử nghiệm và cam kết trở lại với VCS. Tôi đã làm tương tự với các sản phẩm thương mại không giao hàng với nguồn (trình biên dịch, thư viện, v.v.) và nó hoạt động theo cùng một cách. Thay vì giải nén gói cấu hình-biên dịch-gói, nó chỉ giải nén gói. Phần mềm xây dựng hàng đêm không 'make và nhận thành phẩm.

Hầu hết các VCS đều có các tính năng giúp nguồn dễ đọc của con người dễ dàng xử lý hơn và hiệu quả hơn để lưu trữ, nhưng để nói rằng chúng không phù hợp với các tệp nhị phân không thực sự đúng nếu các tệp nhị phân được đưa ra không bị biến dạng. Làm thế nào một VCS xử lý các nhị phân trong nội bộ phụ thuộc hoàn toàn vào việc các tác giả của nó có nghĩ rằng chỉ cố gắng lưu trữ sự khác biệt có đáng để nỗ lực hay không. Cá nhân, tôi nghĩ rằng việc lưu trữ các bản sao đầy đủ của bản phân phối ccRTP ở mức 600K một pop sẽ được bù đắp bằng khả năng gắn thẻ phiên bản của nó cùng với tất cả các nguồn khác của tôi.

Điều này nhắc nhở tôi về vấn đề "bình trong kho" mà trước đây Java có. Những người xây dựng các ứng dụng java đã được sử dụng để đẩy các phụ thuộc của họ (tệp jar nhị phân) vào kho lưu trữ. Mọi người đều hài lòng với điều này, bởi vì chúng tôi bạn sẽ có hệ thống xây dựng "một cú nhấp chuột" và không gian đĩa rất rẻ, vì vậy ai quan tâm. Sau đó đến Maven và bạn có thể thoát khỏi tất cả các hành trình nhị phân đó và với kho lưu trữ chỉ bộ nhớ cache cục bộ vẫn duy trì các bản dựng prof-prof. Vẫn có hệ thống xây dựng "một cú nhấp chuột", nhưng kiểm soát nguồn không phải xáo trộn xung quanh các tệp nhị phân không có ý nghĩa ở đó.

Vì vậy, yeah, bạn có thể lấy các tệp nhị phân ra khỏi kiểm soát nguồn, nhưng điều này sẽ yêu cầu bạn phải điều chỉnh hệ thống xây dựng, để có được chúng trong thời gian xây dựng. Không có phần mềm chuyên dụng (như Maven), đây có thể là rất nhiều nỗ lực để đưa chúng ra ngoài.

Kiểm soát nguồn của bạn giữ các nguồn cho những gì bạn làm. Nếu một blob nhị phân nhất định có thể được xây dựng lại từ các nguồn thì đó không phải là nguồn và không nên đi vào kho mã nguồn. Chỉ các đốm màu không thể tái tạo nên trong kiểm soát nguồn.

Bạn thường có một thư mục mạng kho lưu trữ các đốm màu nhị phân khác mà bạn đã tạo qua thời gian của các nguồn. Chúng có thể được triển khai cho khách hàng hoặc được sử dụng trong các dự án (thay vì xây dựng mọi thứ từ đầu mỗi lần).

Vì vậy, đặt nó vào nếu nó là một nguồn. Đừng nếu không.

Mục tiêu là để có thể lấy mã mới nhất và xây dựng nó mà không phải cài đặt / thiết lập bất cứ điều gì (vì vậy, bản dựng "một lần nhấp").

Ở nhiều nơi tôi đã từng đến, điều đó có nghĩa là kiểm tra các nhị phân của các phụ thuộc. Trong những trường hợp khác, điều này có nghĩa là các tập lệnh xây dựng tải xuống và nhận các phụ thuộc tự động.

Xem bài đăng blog này của Derek Greer về chủ đề này.

Tôi đang làm việc tại một dự án với hai giai đoạn xây dựng khác nhau

• "xây dựng chương trình chính" chỉ cần một vài nhị phân, so với hàng ngàn tệp văn bản mã nguồn, vì vậy các nhị phân được kiểm tra vào kho lưu trữ. Điều này hoạt động tốt.

• bản dựng trình cài đặt cần rất nhiều thành phần của bên thứ ba (một số trong số chúng chỉ được sao chép vào đĩa CD cài đặt, như Adobe Reader). Chúng tôi sẽ không đưa chúng vào kho lưu trữ. Thay vào đó, các thành phần đó nằm trên một ổ đĩa mạng (thậm chí các phiên bản cũ hơn của chúng) và các tập lệnh xây dựng sao chép chúng vào đúng nơi. Tất nhiên, để có các bản dựng có thể tái tạo, bất kỳ ai cũng phải cẩn thận không thay đổi bất kỳ thư mục nào nơi các thành phần của bên thứ ba được lưu trữ.

Cả hai chiến lược đều hoạt động tốt và đáp ứng yêu cầu "kiểm tra từ kiểm soát nguồn bao gồm mọi thứ bạn cần để biên dịch mã".

Bạn cần giữ mọi thứ bạn cần để xây dựng lại các phiên bản cụ thể của sản phẩm tại một thời điểm nào đó trong tương lai.

Tuy nhiên, bạn không phải giữ mọi thứ trong Kiểm soát nguồn.

Một công ty giữ giá đỡ máy chủ bị đóng băng (vì HĐH chỉ chạy trên phần cứng cụ thể đó và chuỗi công cụ chỉ chạy trên HĐH đó và nguồn phụ thuộc vào chuỗi công cụ đó). Không thể kiểm tra điều đó vào Kiểm soát nguồn.

Nếu bạn cần phải phân tách các yêu cầu cho bản dựng, thì bạn có vấn đề về kế toán là giữ cho hai hệ thống kiểm soát phiên bản được đồng bộ hóa. ví dụ: hộp phần cứng trong tủ quần áo này, hoặc VM hoặc nhị phân trong khối sao lưu được bảo toàn này, đi kèm với sửa đổi Mã nguồn SVN này, v.v ... Điều này rắc rối hơn khi sử dụng một hệ thống kiểm soát nguồn duy nhất, nhưng có thể giải quyết được.

Trong tâm trí tôi rất hỗn loạn khi đăng ký nhị phân vào SCM. Tôi đã chạy một dự án rất phức tạp, có rất nhiều phụ thuộc vào các thư viện phần thứ ba. Các nguyên tắc mà chúng tôi áp dụng:

1. Tất cả mã nguồn được quản lý bằng SCM
2. Tất cả các phụ thuộc được quản lý với Ivy, có tích hợp nhật thực tuyệt vời.

Điều này hoạt động khá tốt. Chúng tôi có một tệp cấu hình về phiên bản của mỗi thư viện bên ngoài mà mã nguồn có thể được biên dịch. Tệp cấu hình này được kiểm tra vào SCM, vì vậy nó phát triển khi mã nguồn phát triển. Bằng cách áp dụng phương pháp này, chúng tôi có thể tái tạo chính xác một bản dựng mà không làm rối tung phiên bản của các thư viện bên ngoài.

Về mặt triết học, tôi có khuynh hướng cho phép kiểm soát nguồn kiểm tra các con trỏ tới các tệp nhị phân lớn (tài nguyên nhị phân nhỏ là OK), chứ không phải nội dung của tệp. Con trỏ này sẽ chứa một hàm băm của nội dung tệp nhị phân.

Bản thân tệp nhị phân sẽ không được quản lý bởi kiểm soát nguồn. Nó sẽ được lưu trữ trong một số loại thư viện nơi nó có thể được truy xuất bằng cách sử dụng con trỏ hoặc hàm băm cụ thể.

Git LFS và git annex làm điều đó, nhưng họ cũng cố gắng quản lý các tệp nhị phân ở một mức độ nào đó, tôi không muốn họ làm điều đó. Tôi muốn Git chỉ lưu trữ tổng kiểm tra và cho tôi biết liệu các tệp nhị phân của tôi có thay đổi hay không - nhưng tôi không muốn nó cố gắng quản lý chúng và lưu trữ chúng. Tôi muốn làm điều này bản thân mình.

Tôi nghĩ rằng git có thể xử lý các tệp nhị phân vừa và nhỏ nhưng tôi không chắc chắn rằng đó là công cụ phù hợp để quản lý các tệp nhị phân lớn.