Phần nào trong dự án của bạn nên nằm trong Kiểm soát mã nguồn?

Một nhà phát triển đồng nghiệp đã bắt đầu làm việc với một dự án Drupal mới và sysadmin đã đề xuất rằng họ chỉ nên đặt các trang web / thư mục con mặc định trong kiểm soát nguồn, bởi vì nó "sẽ giúp cập nhật dễ dàng theo kịch bản." Đặt sang một bên yêu cầu hơi mơ hồ đó, nó đặt ra một câu hỏi khác - những tập tin nào sẽ được kiểm soát nguồn? Và có một tình huống mà một số lượng lớn các tập tin nên được loại trừ?

Ý kiến ​​của tôi là toàn bộ cây cho dự án nên được kiểm soát, và điều này sẽ đúng với một dự án Drupal, đường ray hoặc bất cứ thứ gì khác. Điều này có vẻ như không có trí tuệ - bạn rõ ràng cần phiên bản cho khung của bạn nhiều như bạn làm cho bất kỳ mã tùy chỉnh nào bạn viết.

Điều đó nói rằng, tôi rất thích có được ý kiến ​​khác về điều này. Có bất kỳ lý lẽ cho việc không kiểm soát mọi thứ?

Tôi muốn nói rằng mức tối thiểu mà kiểm soát nguồn nên chứa là tất cả các tệp cần thiết để tạo lại phiên bản đang chạy của dự án. Điều này thậm chí bao gồm các tệp DDL để thiết lập và sửa đổi bất kỳ lược đồ cơ sở dữ liệu nào và theo trình tự chính xác. Tất nhiên, trừ các công cụ cần thiết để xây dựng và thực hiện dự án cũng như mọi thứ có thể tự động được tạo / tạo từ các tệp khác trong điều khiển nguồn (chẳng hạn như các tệp JavaDoc được tạo từ các tệp Java trong điều khiển nguồn).

Tốt nhất là đặt mọi thứ dưới ánh mặt trời vào kiểm soát nguồn.

• Mã

• Thư viện

• Tài nguyên

• Xây dựng / Triển khai tập lệnh

• Tạo kịch bản và cập nhật cơ sở dữ liệu

• Tài liệu nhất định

• Tập tin cấu hình cụ thể môi trường

Điều duy nhất không nên đưa vào kiểm soát nguồn là xây dựng các tạo phẩm cho dự án của bạn.

Tôi sẽ nói rằng;

• bất kỳ tệp nào cần để thực hiện quá trình xây dựng đều đi vào kiểm soát phiên bản
• bất kỳ tệp nào (có thể) được tạo bởi bản dựng không

Tôi có xu hướng đặt các tệp nhị phân lớn như các gói cài đặt công cụ ở đâu đó bên ngoài thân cây, nhưng chúng vẫn phải nằm dưới sự kiểm soát phiên bản.

Và đừng quên đặt tất cả mã cơ sở dữ liệu vào Kiểm soát nguồn! Điều này sẽ bao gồm các tập lệnh tạo ban đầu, tập lệnh để thay đổi bảng (được đánh dấu bởi phiên bản phần mềm nào sử dụng chúng, do đó bạn có thể tạo lại bất kỳ phiên bản cơ sở dữ liệu nào cho bất kỳ phiên bản ứng dụng nào) và tập lệnh để điền vào bất kỳ bảng tra cứu nào.

Kinh nghiệm khó giành được đã dạy tôi rằng hầu hết mọi thứ thuộc về kiểm soát nguồn. (Nhận xét của tôi ở đây được tô màu bởi một thập kỷ rưỡi phát triển cho các hệ thống nhúng / viễn thông trên phần cứng độc quyền với các công cụ độc quyền và đôi khi khó tìm.)

Một số câu trả lời ở đây cho biết "không đặt nhị phân trong kiểm soát nguồn". Sai rồi. Khi bạn đang làm việc trên một sản phẩm có nhiều mã bên thứ ba và nhiều thư viện nhị phân từ các nhà cung cấp, bạn hãy kiểm tra trong các thư viện nhị phân . Bởi vì, nếu bạn không, thì đến một lúc nào đó bạn sẽ nâng cấp và bạn sẽ gặp rắc rối: bản dựng bị hỏng vì máy dựng không có phiên bản mới nhất; ai đó đưa cho anh chàng mới đĩa CD cũ để cài đặt; wiki dự án có các hướng dẫn cũ về cài đặt phiên bản nào; v.v. Tệ hơn nữa, nếu bạn phải hợp tác chặt chẽ với nhà cung cấp để giải quyết một vấn đề cụ thể và họ gửi cho bạn năm bộ thư viện trong một tuần, bạn phảicó thể theo dõi tập hợp nhị phân nào thể hiện hành vi nào. Hệ thống kiểm soát nguồn là một công cụ giải quyết chính xác vấn đề đó.

Một số câu trả lời ở đây cho biết "không đặt toolchain trong kiểm soát nguồn". Tôi sẽ không nói sai, nhưng tốt nhất là đặt chuỗi công cụ trong kiểm soát nguồn trừ khi bạn có hệ thống quản lý cấu hình (CM) vững chắc cho nó . Một lần nữa, hãy xem xét vấn đề nâng cấp như đã đề cập ở trên. Tệ hơn nữa, tôi đã làm việc trong một dự án nơi có bốn hương vị riêng biệt của chuỗi công cụ nổi xung quanh khi tôi được thuê - tất cả chúng đều được sử dụng tích cực ! Một trong những điều đầu tiên tôi đã làm (sau khi tôi quản lý để có một bản dựng hoạt động) là đặt chuỗi công cụ dưới sự kiểm soát nguồn. (Ý tưởng về một hệ thống CM vững chắc đã vượt quá hy vọng.)

Và điều gì xảy ra khi các dự án khác nhau đòi hỏi các bộ công cụ khác nhau? Tình huống cụ thể: Sau một vài năm, một trong những dự án đã được nâng cấp từ một nhà cung cấp và tất cả các Makefiles đã bị phá vỡ. Hóa ra họ đang dựa vào một phiên bản GNU mới hơn. Vì vậy, tất cả chúng tôi nâng cấp. Rất tiếc, Makefiles của dự án khác đã phá vỡ tất cả. Bài học: cam kết cả hai phiên bản GNU tạo và chạy phiên bản đi kèm với kiểm tra dự án của bạn.

Hoặc, nếu bạn làm việc ở một nơi mà mọi thứ khác vượt quá tầm kiểm soát, bạn sẽ có những cuộc trò chuyện như "Này, anh chàng mới bắt đầu hôm nay, CD cho trình biên dịch ở đâu?" "Dunno, đã không thấy họ kể từ khi Jack bỏ cuộc, anh ấy là người bảo vệ đĩa CD." "Uhh, không phải là trước khi chúng ta di chuyển lên từ tầng 2 sao?" "Có lẽ họ đang ở trong một cái hộp hoặc một cái gì đó." Và vì các công cụ này đã được ba năm tuổi, không có hy vọng có được đĩa CD cũ đó từ nhà cung cấp.

Tất cả các tập lệnh xây dựng của bạn thuộc về kiểm soát nguồn. Mọi điều! Tất cả các cách xuống các biến môi trường. Máy xây dựng của bạn sẽ có thể chạy bản dựng của bất kỳ dự án nào của bạn bằng cách thực thi một tập lệnh duy nhất trong thư mục gốc của dự án. ( ./buildlà một tiêu chuẩn hợp lý; ./configure; makegần như là tốt.) Kịch bản nên thiết lập môi trường theo yêu cầu và sau đó khởi chạy bất kỳ công cụ nào xây dựng sản phẩm (make, ant, v.v.).

Nếu bạn nghĩ rằng nó quá nhiều công việc, thì không. Nó thực sự tiết kiệm được một tấn công việc. Bạn cam kết các tệp một lần vào đầu thời gian, và sau đó bất cứ khi nào bạn nâng cấp. Không một con sói đơn độc nào có thể nâng cấp máy của chính mình và cam kết một loạt mã nguồn phụ thuộc vào phiên bản mới nhất của một số công cụ, phá vỡ bản dựng cho mọi người khác. Khi bạn thuê các nhà phát triển mới, bạn có thể bảo họ kiểm tra dự án và chạy ./build. Khi phiên bản 1.8 có nhiều điều chỉnh hiệu năng và bạn tinh chỉnh mã, cờ trình biên dịch và biến môi trường, bạn muốn đảm bảo rằng các cờ trình biên dịch mới không vô tình được áp dụng cho các bản dựng phiên bản 1.7, vì chúng thực sự cần mã những thay đổi đi cùng với chúng hoặc bạn thấy một số điều kiện cuộc đua đầy lông.

Tuyệt vời nhất , nó sẽ cứu lấy mông của bạn một ngày nào đó: hãy tưởng tượng rằng bạn sẽ gửi phiên bản 3.0.2 cho sản phẩm của mình vào thứ Hai. Hoan hô, ăn mừng. Vào sáng thứ Ba, một khách hàng VIP gọi đến đường dây nóng hỗ trợ, phàn nàn về lỗi khẩn cấp, siêu tới hạn này trong phiên bản 2.2.6 mà bạn đã vận chuyển 18 tháng trước. Và bạn vẫn phải hỗ trợ nó theo hợp đồng và họ từ chối nâng cấp cho đến khi bạn có thể xác nhận chắc chắn rằng lỗi đã được sửa trong mã mới và chúng đủ lớn để khiến bạn nhảy. Có hai vũ trụ song song:

• Trong vũ trụ nơi bạn không có thư viện, chuỗi công cụ và xây dựng tập lệnh trong kiểm soát nguồn và bạn không có hệ thống CM vững chắc .... Bạn có thể kiểm tra phiên bản mã phù hợp, nhưng nó mang lại bạn tất cả các loại lỗi khi bạn cố gắng xây dựng. Hãy xem, chúng ta đã nâng cấp các công cụ vào tháng 5 chưa? Không, đó là các thư viện. Ok, quay trở lại các thư viện cũ - chờ đã, có hai bản nâng cấp? À đúng rồi, có vẻ tốt hơn một chút. Nhưng bây giờ sự cố liên kết kỳ lạ này trông quen thuộc. Ồ, đó là vì các thư viện cũ không hoạt động với chuỗi công cụ mới, đó là lý do tại sao chúng tôi phải nâng cấp, phải không? (Tôi sẽ dành cho bạn sự đau đớn của phần còn lại của nỗ lực. Phải mất hai tuần và không có ai hạnh phúc khi kết thúc nó, không phải bạn, không phải quản lý, không phải khách hàng.)

• Trong vũ trụ nơi mọi thứ đều nằm trong kiểm soát nguồn, bạn kiểm tra thẻ 2.2.6, chuẩn bị sẵn bản sửa lỗi trong một giờ hoặc lâu hơn, dành một hoặc hai ngày để tạo lại "lỗi VIP", theo dõi nguyên nhân, khắc phục bản phát hành hiện tại và thuyết phục khách hàng nâng cấp. Căng thẳng, nhưng gần như không tệ như vũ trụ khác nơi chân tóc của bạn cao hơn 3cm.

Như đã nói, bạn có thể đưa nó đi quá xa:

• Bạn nên cài đặt hệ điều hành chuẩn mà bạn có "bản sao vàng". Tài liệu về nó, có lẽ trong README nằm trong kiểm soát nguồn, để các thế hệ tương lai biết rằng phiên bản 2.2.6 trở về trước chỉ được xây dựng trên RHEL 5.3 và 2.3.0 và sau đó chỉ được xây dựng trên Ubuntu 11.04. Nếu bạn dễ dàng quản lý chuỗi công cụ theo cách này, hãy tìm kiếm nó, chỉ cần đảm bảo rằng đó là một hệ thống đáng tin cậy.
• Tài liệu dự án là cồng kềnh để duy trì trong một hệ thống kiểm soát nguồn. Các tài liệu dự án luôn đi trước mã, và không có gì lạ khi làm việc trên tài liệu cho phiên bản tiếp theo trong khi làm việc với mã cho phiên bản hiện tại. Đặc biệt nếu tất cả các tài liệu dự án của bạn là tài liệu nhị phân mà bạn không thể tìm hoặc hợp nhất.
• Nếu bạn có một hệ thống kiểm soát các phiên bản của mọi thứ được sử dụng trong bản dựng, hãy sử dụng nó ! Chỉ cần đảm bảo rằng nó dễ dàng đồng bộ hóa trên toàn bộ nhóm, để mọi người (bao gồm cả máy xây dựng) được kéo từ cùng một bộ công cụ. (Tôi đang nghĩ về các hệ thống như pbuilder của Debian và việc sử dụng virtualenv của python có trách nhiệm.)

Điều duy nhất mà tôi không đặt dưới sự kiểm soát nguồn là các tệp mà bạn có thể dễ dàng tạo lại hoặc dành riêng cho nhà phát triển. Điều này có nghĩa là các tệp thực thi và nhị phân bao gồm mã nguồn của bạn, tài liệu được tạo từ việc đọc / phân tích tệp dưới sự kiểm soát nguồn và các tệp dành riêng cho IDE. Mọi thứ khác đi vào kiểm soát phiên bản và được quản lý phù hợp.

Trường hợp sử dụng để kiểm soát nguồn là: Điều gì xảy ra nếu tất cả các máy phát triển của chúng tôi và tất cả các máy triển khai của chúng tôi bị thiên thạch tấn công? Bạn muốn phục hồi càng gần với thanh toán và xây dựng càng tốt. (Nếu điều đó quá ngớ ngẩn, bạn có thể đi với "thuê một nhà phát triển mới.")

Nói cách khác, mọi thứ khác ngoài HĐH, ứng dụng và công cụ nên có trong VCS và trong các hệ thống nhúng, nơi có thể có sự phụ thuộc vào phiên bản nhị phân của công cụ cụ thể, tôi cũng đã thấy các công cụ được giữ trong VCS!

Kiểm soát nguồn không đầy đủ là một trong những rủi ro phổ biến nhất mà tôi gặp khi tư vấn - có tất cả các loại ma sát liên quan đến việc mang đến một nhà phát triển mới hoặc thiết lập một máy mới. Cùng với các khái niệm về Tích hợp liên tục và Phân phối liên tục, bạn phải có ý thức về "Phát triển liên tục" - một nhân viên CNTT có thể tự động thiết lập một máy phát triển hoặc triển khai mới để nhà phát triển có thể xem mã trước khi họ hoàn thành tách cà phê đầu tiên của họ?

Bất cứ điều gì đóng góp cho dự án và mà bạn muốn theo dõi các thay đổi.

Các ngoại lệ có thể bao gồm các đốm nhị phân lớn như hình ảnh, nếu bạn đang sử dụng một scm không xử lý dữ liệu nhị phân rất tốt.

Drupal sử dụng git nên tôi sẽ sử dụng thuật ngữ của git. Tôi sẽ sử dụng thay thế cho từng mô-đun để có thể kéo xuống các bản cập nhật mô-đun từ các kho chính thức của drupal, trong khi vẫn bảo tồn cấu trúc của các triển khai riêng lẻ. Bằng cách đó, bạn có được các lợi ích về kịch bản mà không mất các lợi ích của việc kiểm soát mọi thứ.

Mọi thứ phải được kiểm soát nguồn, ngoại trừ:

• Các tệp cấu hình, nếu chúng bao gồm các tùy chọn cấu hình khác nhau cho từng nhà phát triển và / hoặc từng môi trường (phát triển, thử nghiệm, sản xuất)
• Tập tin bộ nhớ cache, nếu bạn đang sử dụng bộ nhớ đệm hệ thống tập tin
• Đăng nhập tệp, nếu bạn đang đăng nhập vào tệp văn bản
• Bất cứ điều gì như tập tin bộ nhớ cache và tập tin nhật ký được tạo ra nội dung
• (Rất) Các tệp nhị phân lớn không có khả năng thay đổi (một số hệ thống kiểm soát phiên bản không thích chúng, nhưng nếu bạn đang sử dụng hg hoặc git thì chúng không bận tâm nhiều)

Hãy nghĩ về nó như thế: Mỗi thành viên mới trong nhóm sẽ có thể kiểm tra một bản sao làm việc của dự án (trừ các mục cấu hình).

Và đừng quên đặt các thay đổi lược đồ cơ sở dữ liệu (các bãi sql đơn giản của mọi thay đổi lược đồ) dưới sự kiểm soát phiên bản. Bạn có thể bao gồm tài liệu người dùng và api, nếu nó có ý nghĩa với dự án.

@maple_shaft đặt ra một vấn đề quan trọng với tuyên bố đầu tiên của tôi về các tệp cấu hình môi trường trong các bình luận. Tôi muốn làm rõ rằng câu trả lời của tôi là về các chi tiết cụ thể của câu hỏi, đó là về các dự án CMS hoặc Drupal chung chung. Trong các kịch bản như vậy, bạn thường có cơ sở dữ liệu cục bộ và cơ sở sản xuất và một tùy chọn cấu hình môi trường là thông tin đăng nhập cho các cơ sở dữ liệu này (và thông tin tương tự). Chúng tôi khuyên rằng những điều này KHÔNG được kiểm soát nguồn, vì điều đó sẽ tạo ra một số lo ngại về bảo mật.

Tuy nhiên, trong một quy trình phát triển điển hình hơn, tôi đồng ý với maple_shaft rằng các tùy chọn cấu hình môi trường phải được kiểm soát nguồn để cho phép xây dựng và triển khai một bước trong bất kỳ môi trường nào.

Bất cứ điều gì bản dựng tự động của bạn tạo ra đều không đi trong kiểm soát nguồn. Bất cứ điều gì không yêu cầu sửa đổi trong quá trình xây dựng đều đi vào kiểm soát nguồn. Nó đơn giản mà.

Ví dụ: những điều sau đây không được kiểm soát nguồn:

• mã được tạo
• nhị phân được tạo
• bất cứ thứ gì được tạo bởi bản dựng của bạn
• bất cứ điều gì được tạo ra trong thời gian chạy bởi dịch vụ, quy trình, ứng dụng web của bạn

Điều gì không đi trong kiểm soát nguồn:

• bất cứ thứ gì con người tạo ra
• bất cứ thứ gì được tạo bởi người hoặc nhóm khác (ví dụ: thư viện nội bộ của bên thứ ba nơi kiểm soát nguồn được phân phối hoặc nhị phân của dự án nguồn mở).
• các tập lệnh và nguồn khác tạo ra những thứ như cơ sở dữ liệu (nghĩa là bạn sẽ tạo lại db như thế nào nếu tất cả các DBA đi AWOL).

Những quy tắc này được xác định dựa trên quan niệm rằng bất cứ điều gì trong kiểm soát nguồn đều có thể được sửa đổi bởi con người và có thể mất thời gian quý báu của ai đó để hiểu tại sao nó ở đó.

Bất cứ điều gì bạn cần để làm việc và có thể thay đổi cần phải được phiên bản theo cách này hay cách khác. Nhưng hiếm khi cần phải có hai hệ thống độc lập theo dõi nó.

Bất kỳ thứ gì được tạo theo cách đáng tin cậy thường có thể được gắn vào phiên bản nguồn - do đó, nó không cần phải được theo dõi một cách độc lập: nguồn được tạo, các tệp nhị phân không được truyền từ hệ thống này sang hệ thống khác, v.v.

Xây dựng nhật ký và những thứ khác mà có lẽ không ai quan tâm (nhưng bạn không bao giờ biết chắc chắn) thường được theo dõi tốt nhất bởi bất cứ ai đang tạo ra nó: jenkins, v.v.

Xây dựng các sản phẩm được truyền từ hệ thống này sang hệ thống khác cần phải được theo dõi, nhưng repo maven là một cách tốt để làm điều đó - bạn không cần mức độ kiểm soát mà kiểm soát nguồn cung cấp. Việc giao hàng thường trong cùng một danh mục.

Bất cứ điều gì còn lại (và tại thời điểm này, sẽ có ít hơn các tệp nguồn và cấu hình máy chủ xây dựng) đi vào kiểm soát nguồn.

Câu trả lời của tôi khá đơn giản: không phải nhị phân. Theo ngụ ý, hầu hết mọi thứ khác.

(Tuy nhiên, chắc chắn không phải sao lưu cơ sở dữ liệu hoặc di chuyển lược đồ hoặc dữ liệu người dùng.)

Kiểm soát nguồn là một cơ chế theo dõi thay đổi. Sử dụng nó khi bạn muốn biết ai đã thay đổi những gì và khi nào.

Kiểm soát nguồn không miễn phí. Nó thêm sự phức tạp vào quy trình làm việc của bạn và yêu cầu đào tạo cho các trường đại học mới. Cân nhắc lợi ích so với chi phí.

Ví dụ, có thể khó kiểm soát cơ sở dữ liệu. Chúng tôi đã từng có một hệ thống mà bạn phải lưu thủ công các định nghĩa trong tệp văn bản và sau đó thêm chúng vào kiểm soát nguồn. Điều này đã mất rất nhiều thời gian và không đáng tin cậy. Vì nó không đáng tin cậy, bạn không thể sử dụng nó để thiết lập cơ sở dữ liệu mới hoặc để kiểm tra thời điểm thay đổi được thực hiện. Nhưng chúng tôi đã giữ nó trong nhiều năm, lãng phí vô số giờ, bởi vì người quản lý của chúng tôi nghĩ rằng "tất cả mọi thứ nên nằm trong sự kiểm soát nguồn".

Kiểm soát nguồn không phải là phép thuật. Hãy thử nó, nhưng từ bỏ nó nếu nó không thêm đủ giá trị để bù đắp chi phí.

Những thứ tôi sẽ không đặt trong kiểm soát nguồn:

• Khóa bí mật và mật khẩu
• SDK mặc dù đó là cùng một thư mục và nếu tôi tạo một bản vá cho SDK thì nên biến nó thành một dự án khác vì nó sẽ là trên mỗi khung thay vì mỗi ứng dụng
• Thư viện của bên thứ 3 như. Phần còn lại từ di chuyển, sao lưu, mã được biên dịch, mã theo giấy phép khác (có lẽ)

Vì vậy, tôi không làm một hg addremoveví dụ vì thỉnh thoảng tạo một bản sao mới khi SDK cập nhật. Điều đó cũng khiến tôi thực hiện sao lưu hoàn chỉnh mỗi khi SDk cập nhật và kiểm tra xem phiên bản mới được sao chép từ kho lưu trữ có tốt không.

Tôi đặc biệt giới thiệu cho bạn cuốn sách sau đây giải quyết mối quan tâm của bạn:

Phân phối liên tục: Phần mềm đáng tin cậy phát hành thông qua xây dựng, thử nghiệm và tự động triển khai . Cụ thể, Chương 2 giải quyết các mục được đặt trong kiểm soát nguồn, mà như nhiều người đã nói, thực tế là tất cả mọi thứ ngoại trừ nội dung chủ yếu được tạo ra do kết quả của một bản dựng.

Tôi không đồng ý với một phần của câu trả lời được chấp nhận được cung cấp bởi @FrustratedWithFormsDesigner vì ông không ủng hộ việc đưa vào phiên bản kiểm soát các công cụ cần thiết để xây dựng dự án. Ở đâu đó trong kiểm soát nguồn (liền kề với mã đang được xây dựng) nên là các tập lệnh xây dựng để xây dựng dự án và xây dựng các tập lệnh chỉ chạy từ một dòng lệnh. Nếu anh ta có nghĩa là các công cụ, IDE và biên tập viên, thì họ không cần phải xây dựng dự án nào. Chúng rất tốt cho việc phát triển nhanh / tích cực cho các nhà phát triển và thiết lập loại môi trường này cũng có thể được viết kịch bản hoặc tải xuống từ một phần khác của SCM hoặc từ một số loại máy chủ quản lý nhị phân và thiết lập các IDE như vậy nên càng tự động càng tốt.

Tôi cũng không đồng ý với những gì @Yannis Rizos nói về việc đặt cấu hình cho các môi trường trong kiểm soát nguồn. Lý do là bạn sẽ có thể xây dựng lại bất kỳ môi trường nào theo ý muốn mà không sử dụng tập lệnh nào và nó không thể quản lý được nếu không có cài đặt cấu hình trong kiểm soát nguồn. Cũng không có lịch sử về cách cấu hình cho các môi trường khác nhau đã phát triển mà không đặt thông tin này vào kiểm soát nguồn. Bây giờ, cài đặt môi trường sản xuất có thể được bảo mật hoặc các công ty có thể không muốn đặt chúng trong kiểm soát phiên bản, do đó, tùy chọn thứ hai là vẫn đặt chúng trong kiểm soát phiên bản để chúng có lịch sử và cung cấp quyền truy cập giới hạn cho kho lưu trữ này.

Giữ tất cả mã trong kiểm soát phiên bản và tất cả các cấu hình và dữ liệu người dùng. Để cụ thể cho drupal, bạn cần đặt mọi thứ trong kiểm soát phiên bản ngoại trừ tệp và settings.php