Bạn có kiểm tra các thư mục bin hoặc gỡ lỗi (và dll) vào TFS của mình không?


11

Câu hỏi nhanh về TFS - Các bạn có kiểm tra các thư mục bin / gỡ lỗi vào TFS không? (nếu vậy, tại sao?) Vì nội dung của các thư mục đó được tạo động nên tốt hơn là bỏ chúng ra để lập trình viên không gặp phải các vấn đề chỉ đọc?


Bạn có thể quan tâm đến đề xuất trao đổi ngăn xếp này . Nó gần như đã sẵn sàng để bắt đầu phiên bản beta, chỉ cần thêm một vài thứ nữa.
Greatwolf

Câu trả lời:


27

Theo nguyên tắc chung, kiểm soát nguồn chỉ được sử dụng tốt nhất cho nguồn và các tệp được tạo không phải là nguồn.

Có những ngoại lệ. Đôi khi (sử dụng Visual Studio) bạn có thể muốn giữ tệp .pdb để đọc các kết xuất nhỏ. Đôi khi, bạn không thể sao chép một chuỗi công cụ để bạn không nhất thiết phải tạo lại các tệp được tạo một cách chính xác. Trong những trường hợp này, bạn chủ yếu quan tâm đến việc làm điều này cho phần mềm được phát hành, không phải cho mọi thay đổi của VCS và trong mọi trường hợp, những điều này có thể dễ dàng nằm trong các thư mục được phiên bản. (Dù sao, đây thường là các tệp nhị phân và không có các thay đổi dễ hiểu từ phiên bản này sang phiên bản khác và không được hưởng lợi nhiều từ việc ở trong một VCS.)


6
Nếu bạn quan tâm đến việc giữ các biểu tượng gỡ lỗi, tốt hơn hết là bạn nên thiết lập một máy chủ biểu tượng . Nếu bạn làm đúng (với lập chỉ mục nguồn), việc gỡ lỗi một minidump trước tiên sẽ lấy các ký hiệu từ máy chủ biểu tượng của bạn và sau đó là nguồn có liên quan từ kiểm soát nguồn của bạn ... Nếu bạn chỉ cần đăng nhập và gắn thẻ cho mỗi bản dựng, bạn sẽ phải làm điều này bằng tay.
Shog9

8

Câu trả lời đơn giản? Không, đừng làm thế! Tôi không thể nghĩ ra nhiều lý do để không, nhưng không có lý do nào khiến bạn muốn như vậy.

Lần duy nhất tôi có thể nghĩ rằng bạn sẽ kiểm tra trong một dll là nếu đó là từ thư viện bên thứ ba mà bạn không mong đợi mọi nhà phát triển đã cài đặt để xây dựng. Nhưng ngay cả vẫn vậy, điều đó không nằm trong thư mục bin.

Điều đó được nói rằng tôi đã làm việc tại một công ty yêu cầu mỗi gói triển khai phải được kiểm soát nguồn, nhưng đó là để chúng tôi có thể theo dõi các bản dựng khác nhau mà chúng tôi đã cung cấp cho khách hàng của mình và có thể dễ dàng quay lại nếu cần.


1
Lý do chính là không: Bạn muốn kiểm soát nguồn của mình tiêu thụ bao nhiêu terabyte?
EKW

1
Ví dụ, @EKW C # trong lịch sử không tạo ra các nhị phân giống hệt nhau từ cùng một nguồn. Điều đó có thể khác với .NET Core nhưng đây là một lý do để giữ các nhị phân được tạo cho các bản dựng được phát hành chẳng hạn. Tôi sẽ không đặt chúng trong kiểm soát nguồn mặc dù. Nó không phải là công cụ phù hợp cho công việc đó.
Shiv

5

Chúng tôi không kiểm tra thư mục bin vào TFS. Như bạn có thể nhận thấy, nếu bạn làm điều đó, mỗi khi bất kỳ nhà phát triển nào xây dựng giải pháp, họ sẽ kiểm tra thư mục bin. Không tốt. Tuy nhiên, có những thư viện mà dự án cần để biên dịch và chạy, và quy tắc của chúng tôi là bất kỳ dự án nào cũng có thể được mở từ kiểm soát nguồn, và nó sẽ biên dịch và chạy. Vì vậy, những gì chúng tôi làm là tạo một thư mục "BinRef" cho bất kỳ DLL nào mà dự án phải có tham chiếu và tạo Tham chiếu dự án cho bản sao trong thư mục BinRef. Thư mục BinRef được kiểm tra trong TFS.

Ưu điểm khác của phương pháp này là BinRef luôn ở cấp độ gốc của dự án web. Nếu dự án của tôi tồn tại C:\Projects\Marcie\SomeProjectCategory\ProjectAvà tôi tạo một tham chiếu đến một DLL nằm trong đó C:\DLLsThatILike, thì tham chiếu đó cuối cùng sẽ trông giống như

\..\..\..\NiceThing.dll

. Bạn có thể giữ các tệp dự án của mình C:\ProjectA, điều đó có nghĩa là tham chiếu dự án tới NiceThing sẽ xuất hiện trên máy của bạn. Hy vọng mọi người không tham khảo theo cách này, nhưng tôi đã thấy điều đó xảy ra.


2

Chúng tôi đăng ký nội dung của các thư mục bin như một phần của quy trình Yêu cầu Thay đổi của chúng tôi. Để tránh các vấn đề chỉ đọc, chúng tôi sao chép nội dung vào một thư mục riêng và kiểm tra chúng từ đó. Chính sách công ty của chúng tôi yêu cầu tất cả các tệp nhị phân đi vào sản xuất phải được đăng ký riêng với nguồn. Đây không phải là giải pháp tốt nhất nhưng nó hoạt động và nó cung cấp cho chúng tôi các tệp chính xác đang được sản xuất.


2
Lúc đầu tôi sẽ đi qua câu trả lời này, sau đó tôi nghĩ về nó nhiều hơn một chút. Trong công ty của tôi, chúng tôi không thực sự có kế hoạch khắc phục thảm họa (quá lâu để đi vào). Điều này có thể hữu ích trong trường hợp phải bắt đầu lại từ đầu. Tôi chỉ có thể kéo các nhị phân ra khỏi kiểm soát nguồn, ném chúng vào máy chủ và được thực hiện.
dùng7676

@ user7676 - bạn chỉ có thể biên dịch lại mã theo số phiên bản đang sản xuất. Nhưng phải thừa nhận rằng nếu bạn không có kế hoạch DR và ​​bạn đang ở trong một loại diaster nào đó, nó sẽ dễ dàng hơn và nhanh hơn theo cách của bạn. Tái bút BẠN CẦN MỘT KẾ HOẠCH DR !!!
Ali

1

Tôi ngần ngại kiểm tra bất kỳ tập tin phi văn bản nào vào kiểm soát nguồn. Đặc biệt là những người nên được tạo ra bởi các nhà phát triển. Tôi cũng thích giữ các tệp nhị phân khác, chẳng hạn như hình ảnh và tệp PDF, được nén và lưu trữ ở nơi khác cho mỗi thẻ / bản phát hành.


0

Không, nhưng công cụ kiểm soát dự án nội bộ của chúng tôi tự động thực hiện, điều đó làm tôi khó chịu.

Giải pháp của tôi là đánh dấu tất cả các tệp trong bản phát hành và gỡ lỗi là có thể ghi được và khi TFS phàn nàn tôi bảo nó bỏ qua các tệp, vì vậy tôi không bao giờ gặp vấn đề với việc xây dựng thất bại.


0

Tôi tránh nhập chúng vào kiểm soát nguồn. Chúng là thông tin dư thừa, các nhị phân có thể được xây dựng bằng mã nguồn trong lần sửa đổi đó. Ngoài ra, mã nguồn luôn được cập nhật, các bản dựng có thể không được cam kết.


0

Tôi lưu một số tệp nhị phân được tạo, như .NET interops từ một dự án khác. Vì vậy, nếu tôi có một dự án A tạo ra một đối tượng COM, và sau đó bạn sử dụng đối tượng COM đó trong một dự án B liên quan rất lỏng lẻo sử dụng nó thông qua .NET interop, tôi kiểm tra xem interop được tạo từ dự án A vào dự án B. Đó là không phải là một ý tưởng hay, nhưng nó phải đi đâu đó vì AFAIK Visual Studio sẽ không tự động tạo ra interop cho bạn trong quá trình xây dựng.


-2

Theo tôi, không lưu trữ nhị phân trong kiểm soát nguồn là một trong những lỗi phổ biến nhất. Chúng nên được lưu trữ, phiên bản, cơ sở / dán nhãn cùng với các nguồn và cũng có thể xây dựng các công cụ. Tự mình xây dựng phần mềm không theo dõi được ...


5
Bạn đã nêu ý kiến ​​của mình nhưng chưa cho chúng tôi bất kỳ lý do nào về lý do tại sao đó là một thực tiễn tốt. Ai đó quan tâm đến chủ đề này sẽ nhận được ít giá trị từ câu trả lời này mà không cần sao lưu thêm.
Walter
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.