Các thư viện mà ứng dụng dựa vào có nên được lưu trữ trong kiểm soát nguồn không? Một phần tôi nói nên và một phần khác nói không. Thật sai lầm khi thêm một thư viện 20mb làm giảm toàn bộ ứng dụng chỉ vì bạn dựa vào một vài chức năng từ nó (mặc dù khá nặng). Bạn chỉ nên lưu trữ jar / dll hoặc thậm chí có thể là zip / tar được phân phối của dự án?
Những người khác làm gì?
Câu trả lời:
Cũng như có thư viện của bên thứ ba trong kho lưu trữ của bạn, bạn nên làm điều đó theo cách giúp dễ dàng theo dõi và hợp nhất trong các bản cập nhật trong tương lai cho thư viện một cách dễ dàng (ví dụ: các bản sửa lỗi bảo mật, v.v.). Nếu bạn đang sử dụng Subversion bằng cách sử dụng một chi nhánh nhà cung cấp thích hợp là điều đáng giá.
Nếu bạn biết rằng đó sẽ là một ngày lạnh lẽo trong địa ngục trước khi bạn sửa đổi mã của bên thứ ba thì (như @Matt Sheppard đã nói), một bên ngoài có ý nghĩa và mang lại cho bạn lợi ích bổ sung mà việc chuyển đổi trở nên rất dễ dàng phiên bản mới nhất của thư viện nên các bản cập nhật bảo mật hoặc một tính năng phải có mới khiến điều đó trở nên mong muốn.
Ngoài ra, bạn có thể bỏ qua các phần bên ngoài khi cập nhật mã lưu cơ sở của bạn trong quá trình tải chậm kéo dài nếu bạn cần.
@Stu Thompson đề cập đến việc lưu trữ tài liệu, v.v. trong kiểm soát nguồn. Trong các dự án lớn hơn, tôi đã lưu trữ toàn bộ thư mục "khách hàng" của chúng tôi trong kiểm soát nguồn bao gồm hóa đơn / hóa đơn / biên bản cuộc họp / thông số kỹ thuật, v.v. Toàn bộ cảnh quay trùng khớp. Mặc dù, ahem, hãy nhớ lưu trữ chúng trong một kho lưu trữ RIÊNG từ kho lưu trữ mà bạn sẽ cung cấp cho: các nhà phát triển khác; khách hàng; "chế độ xem nguồn trình duyệt" của bạn ... khụ ... :)
lưu trữ mọi thứ bạn cần để xây dựng dự án trong 10 năm kể từ bây giờ. Tôi lưu trữ toàn bộ bản phân phối zip của bất kỳ thư viện nào, đề phòng
Chỉnh sửa cho năm 2017: Câu trả lời này không hợp tuổi :-). Nếu bạn vẫn đang sử dụng một cái gì đó cũ như ant hoặc make, những điều trên vẫn được áp dụng. Nếu bạn sử dụng thứ gì đó hiện đại hơn như maven hoặc graddle (hoặc Nuget trên .net chẳng hạn), với quản lý phụ thuộc, bạn nên chạy một máy chủ quản lý phụ thuộc, ngoài máy chủ kiểm soát phiên bản của bạn. Miễn là bạn có bản sao lưu tốt của cả hai và máy chủ quản lý phụ thuộc của bạn không xóa các phụ thuộc cũ, bạn sẽ ổn. Để biết ví dụ về máy chủ quản lý phụ thuộc, hãy xem ví dụ: Sonatype Nexus hoặc JFrog Artifcatory , trong số nhiều máy chủ khác.
Không lưu trữ các thư viện; họ không nói chính xác một phần dự án của bạn và vô dụng chiếm chỗ trong hệ thống kiểm soát sửa đổi của bạn. Tuy nhiên, hãy sử dụng maven (hoặc Ivy cho các bản dựng kiến) để theo dõi các phiên bản thư viện bên ngoài mà dự án của bạn sử dụng. Bạn nên chạy một bản sao của repo trong tổ chức của bạn (đã được sao lưu) để đảm bảo bạn luôn có các phần phụ thuộc trong tầm kiểm soát của mình. Điều này sẽ mang lại cho bạn điều tốt nhất của cả hai thế giới; các lọ bên ngoài bên ngoài dự án của bạn, nhưng vẫn có sẵn một cách đáng tin cậy và có thể truy cập tập trung.
không bao giờ lưu trữ mã nhị phân của bên thứ 3 trong kiểm soát nguồn. Hệ thống kiểm soát nguồn là nền tảng hỗ trợ chia sẻ tệp đồng thời, làm việc song song, nỗ lực hợp nhất và lịch sử thay đổi. Kiểm soát nguồn không phải là một trang FTP cho các tệp nhị phân. Các hội đồng của bên thứ 3 KHÔNG phải là mã nguồn; chúng có thể thay đổi hai lần cho mỗi SDLC. Mong muốn có thể xóa sạch không gian làm việc của bạn, kéo mọi thứ xuống khỏi kiểm soát nguồn và xây dựng không có nghĩa là các tổ hợp của bên thứ 3 cần phải mắc kẹt trong kiểm soát nguồn. Bạn có thể sử dụng tập lệnh xây dựng để điều khiển việc kéo các hội đồng bên thứ 3 từ máy chủ phân phối. Nếu bạn lo lắng về việc kiểm soát nhánh / phiên bản nào của ứng dụng sử dụng một thành phần cụ thể của bên thứ ba, thì bạn cũng có thể kiểm soát điều đó thông qua các tập lệnh xây dựng. Mọi người đã đề cập đến Maven cho Java và bạn có thể làm điều gì đó tương tự với MSBuild cho .Net.
Tôi thường lưu trữ chúng trong kho lưu trữ, nhưng tôi đồng cảm với mong muốn của bạn để giảm kích thước.
Nếu bạn không lưu trữ chúng trong kho lưu trữ, bạn hoàn toàn cần phải lưu trữ và tạo phiên bản bằng cách nào đó, và hệ thống xây dựng của bạn cần biết cách lấy chúng. Nhiều người trong thế giới Java dường như sử dụng Maven để tự động tìm nạp các phụ thuộc, nhưng tôi chưa sử dụng I, vì vậy tôi không thực sự khuyên bạn nên ủng hộ hay chống lại nó.
Một lựa chọn tốt có thể là giữ một kho lưu trữ riêng cho các hệ thống của bên thứ ba. Nếu bạn đang sử dụng Subversion, thì bạn có thể sử dụng hỗ trợ bên ngoài của subversion để tự động kiểm tra các thư viện tạo thành kho lưu trữ khác. Nếu không, tôi khuyên bạn nên giữ một máy chủ FTP Ẩn danh nội bộ (hoặc tương tự) mà hệ thống xây dựng của bạn có thể tự động tìm nạp các yêu cầu từ đó. Rõ ràng là bạn sẽ muốn đảm bảo rằng bạn giữ tất cả các phiên bản thư viện cũ và có mọi thứ ở đó được sao lưu cùng với kho lưu trữ của bạn.
Những gì tôi có là một kho lưu trữ giống như Maven của mạng nội bộ nơi lưu trữ tất cả các thư viện của bên thứ 3 (không chỉ các thư viện, mà còn phân phối nguồn tương ứng của chúng với tài liệu, Javadoc và mọi thứ). Lý do là như sau:
Tôi đặt mọi thứ ngoại trừ JDK và IDE trong kiểm soát nguồn.
Triết lý của Tony là âm thanh. Đừng quên các tập lệnh tạo cơ sở dữ liệu và các tập lệnh cập nhật cấu trúc dữ liệu. Trước khi wiki ra đời, tôi thậm chí còn lưu trữ tài liệu của chúng tôi trong phần kiểm soát nguồn.
Sở thích của tôi là lưu trữ các thư viện của bên thứ ba trong một kho lưu trữ phụ thuộc ( ví dụ: Artifactory với Maven ) hơn là giữ chúng trong Subversion.
Vì thư viện của bên thứ ba không được quản lý hoặc tạo phiên bản giống như mã nguồn, nên việc trộn lẫn chúng sẽ không có ý nghĩa gì. Các nhà phát triển từ xa cũng đánh giá cao việc không phải tải xuống các thư viện lớn qua liên kết WPN chậm khi họ có thể lấy chúng dễ dàng hơn từ bất kỳ kho lưu trữ công cộng nào.
Tại một nhà tuyển dụng trước đây, chúng tôi đã lưu trữ mọi thứ cần thiết để xây dựng (các) ứng dụng trong kiểm soát nguồn. Quay một máy xây dựng mới là vấn đề đồng bộ hóa với điều khiển nguồn và cài đặt phần mềm cần thiết.
Lưu trữ các thư viện của bên thứ ba trong quyền kiểm soát nguồn để chúng có sẵn nếu bạn kiểm tra mã của mình trong môi trường phát triển mới. Bất kỳ lệnh "bao gồm" hoặc xây dựng nào mà bạn có thể có trong tập lệnh xây dựng cũng phải tham chiếu đến các bản sao "cục bộ" này.
Ngoài việc đảm bảo rằng mã hoặc thư viện của bên thứ ba mà bạn phụ thuộc vào luôn có sẵn cho bạn, điều đó cũng có nghĩa là mã (gần như) đã sẵn sàng để xây dựng trên PC hoặc tài khoản người dùng mới khi các nhà phát triển mới tham gia vào nhóm.
Lưu trữ các thư viện! Kho lưu trữ phải là một ảnh chụp nhanh những gì cần thiết để xây dựng một dự án vào bất kỳ thời điểm nào. Vì dự án yêu cầu các phiên bản thư viện bên ngoài khác nhau nên bạn sẽ muốn cập nhật / kiểm tra các phiên bản mới hơn của các thư viện này. Bằng cách đó, bạn sẽ có thể có được tất cả phiên bản phù hợp để đi cùng với ảnh chụp nhanh cũ nếu bạn phải vá một bản phát hành cũ hơn, v.v.
Cá nhân tôi có một thư mục phụ thuộc như một phần của các dự án của tôi và lưu trữ các thư viện tham chiếu trong đó.
Tôi thấy điều này làm cho cuộc sống dễ dàng hơn khi tôi làm việc trên một số dự án khác nhau, thường là các phần phụ thuộc lẫn nhau cần cùng một phiên bản thư viện, nghĩa là không phải lúc nào cũng khả thi để cập nhật lên phiên bản mới nhất của một thư viện nhất định.
Có tất cả các phụ thuộc được sử dụng tại thời điểm biên dịch cho mỗi dự án có nghĩa là một vài năm sau khi mọi thứ đã bắt đầu, tôi vẫn có thể xây dựng bất kỳ phần nào của dự án mà không phải lo lắng về việc phá vỡ các phần khác. Nâng cấp lên phiên bản mới của thư viện chỉ đơn giản là thay thế tệp và xây dựng lại các thành phần liên quan, không quá khó để quản lý nếu cần.
Phải nói rằng, tôi thấy hầu hết các thư viện mà tôi tham khảo đều tương đối nhỏ với trọng lượng khoảng vài trăm kb, hiếm khi lớn hơn, điều này khiến tôi không gặp vấn đề gì khi chỉ gắn chúng vào kiểm soát nguồn.
Sử dụng các dự án con git và tham chiếu từ kho lưu trữ git chính của thư viện bên thứ 3 hoặc (nếu nó không có) tạo một kho lưu trữ git mới cho mỗi thư viện bắt buộc. Không có lý do gì khiến bạn chỉ giới hạn trong một kho lưu trữ git và tôi không khuyên bạn nên sử dụng dự án của người khác như một thư mục của riêng bạn.
lưu trữ mọi thứ bạn cần để xây dựng dự án, vì vậy bạn có thể kiểm tra và xây dựng mà không cần làm gì cả.
(và, là một người đã trải qua nỗi đau - hãy giữ một bản sao của mọi thứ cần thiết để cài đặt các điều khiển và hoạt động trên nền tảng nhà phát triển. Tôi đã từng có một dự án có thể xây dựng - nhưng không có tệp cài đặt và khóa reg, bạn không thể 'không thực hiện bất kỳ thay đổi nào đối với bố cục điều khiển của bên thứ ba. Đó là một bài viết lại thú vị)
Bạn phải lưu trữ mọi thứ bạn cần để xây dựng dự án. Hơn nữa, các phiên bản mã khác nhau của bạn có thể có sự phụ thuộc khác nhau vào các bên thứ ba. Bạn sẽ muốn phân nhánh mã của mình thành phiên bản bảo trì cùng với các phụ thuộc bên thứ ba của nó ...
Cá nhân tôi đã làm và thích kết quả cho đến nay là lưu trữ các thư viện trong một kho lưu trữ riêng biệt và sau đó liên kết đến từng thư viện mà tôi cần trong các kho lưu trữ khác của mình thông qua việc sử dụng tính năng Subversion svn: externals. Điều này hoạt động tốt vì tôi có thể giữ các bản sao đã được phiên bản của hầu hết các thư viện của chúng tôi (chủ yếu là các tập hợp .NET được quản lý) trong kiểm soát nguồn mà chúng không làm tăng kích thước của kho lưu trữ mã nguồn chính của chúng tôi. Việc có các tập hợp được lưu trữ trong kho lưu trữ theo cách này giúp máy chủ xây dựng không cần phải cài đặt chúng để tạo bản dựng. Tôi sẽ nói rằng việc xây dựng thành công mà không có Visual Studio được cài đặt là một việc vặt nhưng bây giờ chúng tôi đã làm cho nó hoạt động, chúng tôi rất vui với nó.
Lưu ý rằng chúng tôi hiện không sử dụng nhiều bộ điều khiển thương mại của bên thứ ba hoặc những thứ tương tự như vậy, vì vậy chúng tôi chưa gặp phải vấn đề cấp phép, nơi có thể được yêu cầu thực sự cài đặt SDK trên máy chủ bản dựng nhưng tôi có thể thấy điều đó có thể dễ dàng trở thành một vấn đề. Thật không may, tôi không có giải pháp cho điều đó và sẽ có kế hoạch giải quyết nó khi tôi gặp nó lần đầu tiên.