Di chuyển đến kiểm soát nguồn


10

Chúng tôi là một công ty khá nhỏ (3-4 lập trình viên và 3-4 nhà thiết kế trang web) phát triển ứng dụng web PHP đơn mục đích cung cấp chức năng cho hơn 100 trang web. Chúng tôi đã hoạt động được một vài năm trong một môi trường sản xuất và phát triển riêng biệt hoạt động khá tốt. Luôn có đủ các tính năng riêng biệt được phát triển để các lập trình viên không bao giờ thực sự đụng độ và sẽ thuận tiện hơn khi làm việc mà không cần kiểm soát nguồn; mặc dù nó có nguy cơ mất dữ liệu và chúng tôi đã chia sẻ công bằng các tệp bị mất trong một động thái vô ý.

Sự cân nhắc khác là các nhà thiết kế của chúng tôi không am hiểu về công nghệ (tôi đã giới thiệu cho họ về đánh dấu html, thay vì sử dụng WYSIWYGs). Đây là một trong những lý do để do dự khi chuyển sang phiên bản.

Tuy nhiên, hiện tại chúng tôi đã đạt hơn 100 trang web và nhóm phát triển đang phát triển, tôi đang cố gắng chuẩn hóa các quy trình và kiểm soát nguồn của chúng tôi có vẻ là một bước hợp lý khi các lập trình viên đi xa. Tôi hy vọng điều này cũng sẽ tăng tốc độ triển khai bản vá của chúng tôi.

Thật không may, tôi có rất ít kinh nghiệm trong việc thiết lập hệ thống kiểm soát nguồn. Điều tôi tò mò muốn nghe về những người có thiết lập tương tự hoặc kinh nghiệm thực hiện chuyển đổi:

1) Bạn có phiên bản mọi thứ (trang web, css, mẫu html và mã ứng dụng) và do đó buộc các nhà thiết kế phải học phiên bản không? Hay đó chỉ là các nhà phát triển làm việc trên mã ứng dụng?

2) Một số cạm bẫy cần chú ý khi thiết lập kiểm soát nguồn ban đầu là gì?

3) Triển khai dev => mẹo sản xuất để kiểm soát nguồn.

Cảm ơn vì tất cả cái nhìn sâu sắc.

Chỉnh sửa 1: Đăng. Mọi người cho đến nay đang khuyên bạn nên kiểm soát mọi thứ. Điều đó sẽ khiến tôi rụng tóc sớm. Có lẽ nó sẽ châm ngòi cho một câu hỏi mới trong tương lai gần. Cảm ơn lời khuyên cho đến nay, giữ cho nó đến!

Chỉnh sửa 2: Rất nhiều câu trả lời hay và chúng tôi sẽ xem xét các hệ thống kiểm soát phiên bản khác nhau. Cảm ơn đã trả lời tất cả mọi người!


@mattdm ahh, 'kiểm soát phiên bản' ... tôi đã thử 'kiểm soát nguồn' / thở dài
DTest

Cũng "kiểm soát sửa đổi".
mattdm

Adobe và hầu hết các nhà phát triển phần mềm đồ họa lớn hơn khác đã có các triển khai kiểm soát phiên bản tài sản của riêng họ - chỉ ra rằng điều này thực sự đáng mong đợi hơn đối với các nhà thiết kế imho (và có bao gồm các tài sản phiên bản và không chỉ các tệp mô tả văn bản).
Oskar Duveborn

Câu trả lời:


10

Thật hữu ích khi có mọi thứ được phiên bản, ngay cả đối với các nhà thiết kế. Và nếu được thực hiện tốt với sự huấn luyện tốt, tôi nghĩ họ sẽ thấy nó hữu ích hơn là gánh nặng.

Nếu bạn mới bắt đầu, tôi thực sự khuyên bạn nên sử dụng hệ thống kiểm soát phiên bản phân tán như git hoặc mercurial . Đây là xu hướng chung trên thế giới, và có rất nhiều lợi thế. Thật dễ dàng để làm việc ở chế độ ngắt kết nối, không phụ thuộc vào mạng và khả năng thực hiện công việc riêng tư, chưa được đánh bóng vẫn nằm dưới sự kiểm soát của phiên bản, kiểm tra mọi thứ ở trung tâm khi nó sẵn sàng.

Và, không phải dùng đến kháng cáo lên chính quyền hay bất cứ điều gì, mà hãy xem Joel Spolsky nói gì về chủ đề này . (Trích dẫn lựa chọn: "Subversion = Leeches. Mercurial và Git = Kháng sinh.") Trong số những điều khác, ông đưa ra một điểm thú vị là các hệ thống mới này sử dụng mô hình tinh thần mới, khác với kiểm soát phiên bản truyền thống - đó là lý do tại sao đi vào loại này tiếp cận từ đầu là một chiến thắng.


cảm ơn đã trả lời, mattdm. Tôi sẽ kiểm tra các liên kết đó
DTest

+1 cho con trỏ đó đến bài viết Spolsky; Tôi chỉ đọc hướng dẫn Hg của anh ấy (HgInit) và tôi nghĩ rằng tôi bắt đầu nhận được dVCS, lần đầu tiên. Cảm ơn (bạn và Joel).
MadHatter

3

Tôi sẽ nói đặt mọi thứ dưới sự kiểm soát phiên bản. Khi tất cả đều hoạt động, bạn có thể sao chép nó vào thẻ mà hầu hết các hệ thống SCM không yêu cầu nhiều dung lượng đĩa trên máy chủ.

Theo như những cạm bẫy ban đầu, bạn không nên lo lắng nhiều; cam kết mọi thứ với máy chủ và nếu nó không chính xác, bạn có thể xáo trộn nó xung quanh và xóa những thứ bổ sung sau đó. Điều duy nhất tôi không cam kết là các tạo phẩm được xây dựng từ nguồn, tức là các tệp mã java thuộc về kiểm soát phiên bản nhưng không phải là các lớp được biên dịch hoặc toàn bộ ISO / DVD của các nhị phân "được xây dựng từ nguồn".

Dev để sản xuất là dễ dàng, tại mỗi cột mốc quan trọng tạo ra một chi nhánh. Bố cục thư mục trong hệ thống kiểm soát phiên bản thường trông giống như:

/ trunk / dự án / chi nhánh / dự án / phiên bản1 / chi nhánh / dự án / phiên bản 2 / chi nhánh / dự án / phiên bản3

Vì vậy, giả sử bạn tìm thấy một lỗi trong phiên bản 2 của sản phẩm, bạn điều hướng đến chi nhánh đó, sửa nó và phát hành phiên bản 2.1. Trong khi bạn đang làm việc trên thư mục / trunk / dự án cho phiên bản 4 mới và tùy thuộc vào bạn, tính năng nào được hợp nhất ngược và xuôi.

Đừng để những người uống hỗ trợ kool SCM đánh lừa bạn, có rất ít sự khác biệt về chức năng giữa các hệ thống kiểm soát phiên bản phổ biến ngoài kia, cụ thể là Subversion và Git. Điều quan trọng nhất đối với nhóm của bạn sẽ là các máy chủ đó tích hợp tốt như thế nào với các công cụ hiện có của bạn. Tôi cũng không thích WYSIWYG nhưng chắc chắn sẽ rất tuyệt khi có nhật thực-php hoặc các IDE khác tương thích với máy chủ.


Người đàn ông, bạn cần một số hỗ trợ kool tốt hơn. Bạn có thể sử dụng kiểm soát phiên bản phân tán để chỉ sao chép một cái gì đó như hệ thống CVS hoặc SVN, nhưng thực sự có một sự khác biệt cơ bản. (Điều này không đánh gục SVN, điều này tốt cho những gì nó làm, làm phiền bạn.)
mattdm

3

Tôi là một nhà phát triển và đã từng tham gia làm quản trị viên CNTT trước đây.

Để trả lời các câu hỏi cụ thể của bạn:

1) Có, Phiên bản mọi thứ.

2) Đề nghị bạn thiết lập một kho lưu trữ kiểm soát phiên bản giả và dự án giả để mọi người tìm hiểu.

3) Gắn thẻ các phiên bản được đưa vào sản xuất. ngay cả những thử thách. Sau đó, bạn luôn có thể kiểm tra một phiên bản cụ thể mà ai đó đang chạy.

Tôi thấy bạn đã gắn thẻ CVS câu hỏi.

Thay vào đó, tôi đề nghị một cách nghiêm túc về lật đổ, kết hợp với TortoiseSVN, điều này làm cho nó rất dễ sử dụng. Ngoài ra còn có một TortoiseCVS là tốt.

Tôi đề nghị bạn nên chạy một hướng dẫn nội bộ về kiểm soát phiên bản. Tôi sẽ ngạc nhiên nếu các nhà phát triển / nhà thiết kế của bạn chưa gặp phải điều này trước đây. Rùa chỉ làm cho nó rất thân thiện với người dùng.

Cũng có thể có ích khi cài đặt một trong các giao diện web vào cvs hoặc lật đổ.

Lý do tôi đề nghị lật đổ CVS là trong khi CVS rất tốt, nó có một số vấn đề nghiêm trọng về thiết kế và triển khai. Các vấn đề lớn đối với tôi là: 1) Bạn không thể phiên bản thư mục 2) Xử lý tệp nhị phân không quá tốt vì nhiều thứ mặc định là văn bản. 3) Không cam kết nguyên tử. 4) Tôi nhớ rằng nó thường gây rối và để lại các tệp khóa xung quanh mà tôi phải xóa thủ công khỏi kho lưu trữ mã. Có chỗ cho tham nhũng khi làm điều này vì rm của bạn các tập tin khóa. 5) Hỗ trợ SSL và quản lý người dùng / mật khẩu

Subversion về cơ bản sửa chữa tất cả những vấn đề có lẽ là nhiều vấn đề khác. Nó cũng có rất nhiều tính năng nâng cao như externals (mà tôi thực sự sử dụng). Và có thể liên kết người dùng / nhóm vào thư mục hoạt động mà bạn có thể thấy hữu ích. Tại thời điểm tôi sử dụng CVS không có sẵn. Có thể là bây giờ, tôi chưa kiểm tra.

Có lẽ sự khác biệt lớn nhất để bạn hiểu về svn khi sử dụng nó là bạn không tạo thẻ. Thay vào đó, bạn tạo những gì có vẻ là bản sao trong đó thư mục dự án được sao chép vào thư mục Thẻ và được đặt tên. Hãy xem tài liệu và bạn sẽ hiểu ý tôi là gì. Tôi biết nó trông lạ nhưng bạn đã quen với nó.

Trang web này có thể có một số lợi ích (mặc dù tôi không thể bảo đảm cho nó): Thiết lập kho lưu trữ svn mô-đun cho các trang web php http://www.howtoforge.com/set-up-a-modular-svn-reposeective-for -php-website


Vâng, tôi chỉ được gắn thẻ là cvs vì tôi không thể tìm thấy thẻ phù hợp (hóa ra là 'kiểm soát phiên bản') Tôi đã từng chơi với svn một chút trong quá khứ và có thể sẽ kiểm tra git và một vài người khác trước đây đưa ra quyết định cuối cùng. Cảm ơn những lời đề nghị quá, đặc biệt là về phiên bản giả. Liên kết đó sẽ hữu ích vì tôi chắc chắn đó sẽ là một trong những câu hỏi của tôi khi cuối cùng tôi đã thiết lập kiểm soát phiên bản
DTest

3

Với sự tôn trọng tuyệt vời để nhiều sự khôn ngoan mà xuất hiện phía trên - và nó khôn ngoan - triển khai kiểm soát phiên bản là như triển khai các hệ thống giám sát. Khách hàng của tôi nói "tôi nên theo dõi những gì" và câu trả lời rõ ràng là "giám sát mọi thứ". Nhưng đây không phải là tin đáng hoan nghênh: họ có 350 hệ thống, mỗi hệ thống có 20-30 biến hệ thống cộng với một loạt các biến cụ thể sử dụng và tất cả chúng đều có thể được theo dõi một cách hữu ích; nhưng chỉ có một người trong tôi và họ muốn thấy một số kết quả trong một hai tuần.

Vì vậy, mặc dù tôi đồng ý rằng thực tiễn tốt nhất là kiểm soát phiên bản mọi thứ, nếu điều này không thực tế trong trường hợp đầu tiên, hãy bắt đầu bằng cách kiểm soát những điều mà sự thiếu kiểm soát đã gây ra cho bạn hầu hết các vấn đề cho đến nay .

Nếu hầu hết các lần ngừng hoạt động là do mã ứng dụng, hãy bắt đầu bằng cách kiểm soát điều đó; nếu hầu hết bằng các bản vá CSS không có kế hoạch, hãy kiểm soát điều đó; và như thế.

Điều này không chỉ mang lại cho bạn lợi tức đầu tư tốt nhất mà còn mang lại cho bạn lý do âm thanh để mở rộng việc sử dụng kiểm soát phiên bản trong tương lai: "Vì chúng tôi đã thêm kiểm soát phiên bản vào mã ứng dụng, nên ngừng hoạt động ngoài 30 phút đã giảm từ 11 tháng xuống còn 2. Hai nguyên nhân đó là do thay đổi HTML tĩnh, vì vậy chúng tôi dự định kiểm soát phiên bản tiếp theo. ".

Một buổi giới thiệu tốt nghiệp cũng cung cấp cho bạn người dùng có kỹ năng trong tổ chức. Có, bạn phải dạy cho tất cả sáu nhà phát triển ứng dụng cách sử dụng hệ thống, nhưng họ đã học được và họ vẫn ổn với nó; bây giờ đã đến lúc đưa hệ thống ra cho nhóm CSS, bạn có thêm sáu chuyên gia nội bộ so với ba tháng trước. Bạn thậm chí có thể chuyển đổi vào thời điểm này; một nhà phát triển đã cứu được mông của mình bằng khả năng kịp thời sao lưu một thay đổi có hại có thể là nhà truyền giáo tốt nhất của bạn cho nhóm CSS.

Chỉnh sửa 1: nếu bạn quyết định đi theo con đường này, một điểm dừng chân giá rẻ là thêm ba dây trên đầu, ít nhất là trên hộp sản xuất. Theo cách đó, nếu Things Break nhưng VCS nói rằng hiện tại không có trách nhiệm gì, bạn có thể nhanh chóng xác định những gì đã thay đổi, cả hai đều tăng tốc độ khắc phục và đề nghị ứng cử viên tiếp theo của bạn kiểm soát phiên bản.


1
IMHO chỉ tốt hơn để đi trong giày và tất cả và phiên bản mọi thứ. Nó sẽ thường xuyên quay lại cắn bạn nếu bạn không. ví dụ tôi đã từng không kiểm tra trong thư viện của bên thứ 3, nhưng bây giờ thì có. Lý do là, do sự phụ thuộc, tốt hơn là có thể đưa toàn bộ hệ thống ra khỏi sự kiểm soát phiên bản hơn là cố gắng ghép tất cả lại với nhau và làm cho nó hoạt động. Nếu bạn không làm điều này thì bạn sẽ phải duy trì các bản sao của các bit có thể tương thích và ghi lại những gì phụ thuộc vào cái gì. Với VC, chỉ cần kiểm tra tất cả và nó sẽ hoạt động khi bạn kiểm tra tất cả. Ý tôi là sao?
Matt

Này, tôi cũng vậy; đọc đoạn có nội dung "Tôi đồng ý rằng thực tiễn tốt nhất là kiểm soát phiên bản mọi thứ". Nhưng trong lần chỉnh sửa 1, OP đặc biệt yêu cầu các chiến lược thay thế cho chiến lược tốt nhất, và điều này rất tốt thứ hai, tốt nhất.
MadHatter

Xin lỗi người đàn ông, tôi đã đọc sai đoạn đó là "nó không thực tế" khi nó nói "nếu nó không thực tế ..." vì vậy bạn hoàn toàn đúng đó là một sự thay thế.
Matt

Đây thực sự là một sự thay thế khả thi. Đặc biệt với tư duy của công ty 'Chứng minh điều đó trước khi chúng tôi hoàn toàn cam kết với nó'.
DTest

2

Phiên bản kiểm soát mọi thứ. Không có điểm nào có các tệp HTML dưới sự kiểm soát phiên bản và sau đó có một trang web hoàn toàn bị hỏng do thay đổi CSS không được kiểm soát và do đó không thể dễ dàng bị đảo ngược.

Cạm bẫy: Cá nhân tôi đã không gặp phải bất kỳ vấn đề nào trong quá trình sử dụng kiểm soát phiên bản khá hạn chế.

Triển khai: Tôi hiện đang sử dụng lật đổ được lưu trữ trên các hộp Windows, cả ở nơi làm việc và ở nhà. Windows chỉ vì đó là những gì có sẵn. Nếu không, nó có thể dễ dàng trở thành một hệ điều hành khác. Chìa khóa cho người dùng phi công nghệ i cung cấp cho họ một công cụ dựa trên GUI đơn giản để xử lý nhập, xuất, cam kết, khác biệt, v.v. Công cụ nào sẽ sử dụng sẽ phụ thuộc một chút vào hệ điều hành và hệ thống VCS được sử dụng.

Sử dụng: Khi tôi thực hiện thay đổi mã, tôi kiểm tra và cam kết thường xuyên. Điều này cho phép tôi quay trở lại khi cần thiết khi tôi bắt vít. Ngoài ra, bằng cách so sánh các bản sửa đổi và sao chép các phần khác nhau của mã, tôi không phải mất mọi thay đổi chỉ vì tôi cần quay lại phiên bản trước để sửa một số nội dung trong phần khác của mã.

Thêm lợi ích: Bạn có thể cấp quyền truy cập vào kho lưu trữ nguồn qua VPN hoặc kết nối an toàn, cho phép người dùng làm việc tại nhà hoặc ở nơi khác. ví dụ tôi có thể có một ý tưởng ở nhà và chỉnh sửa mã công việc của mình ở đó và sau đó, trước khi tôi mất ý nghĩ.


2

Phiên bản mọi thứ.

Triển khai tùy thuộc vào mức độ bạn phải "tùy chỉnh" cho mỗi trang web này. Nếu chúng giống hệt nhau ngoại trừ một hoặc hai tệp cấu hình, bạn chỉ cần kiểm tra một bản sao mã cho chúng và thực hiện các thay đổi nhỏ. Khi cần, hãy chạy lệnh cập nhật kiểm soát phiên bản của bạn cho từng máy khách.

Nếu bạn đi theo mô hình phân phối "thanh toán trực tiếp vào trang web của khách hàng", bạn sẽ muốn chắc chắn rằng máy chủ của bạn loại trừ quyền truy cập vào các thư mục kiểm soát phiên bản để mọi người không thể duyệt đến http://example.com/. git / và nhìn trộm vào bên trong của bạn. Ngoài ra, tôi chắc chắn sẽ có một máy chủ ảo thử nghiệm và sản xuất cho mỗi khách hàng để đảm bảo rằng một bản cập nhật trang web không gặp sự cố. Đặc biệt nếu bạn đang thực hiện các thay đổi tùy chỉnh cho các tệp của từng khách hàng, thì bạn sẽ cần xử lý các xung đột trước khi các thay đổi được triển khai. Trong trường hợp này, bạn sẽ kiểm tra / cập nhật máy chủ ảo thử nghiệm và khi mọi thứ hoạt động tốt, bạn sẽ sao chép máy chủ ảo thử nghiệm vào máy chủ ảo sản xuất.


thật không may, nó sẽ phải được thiết lập với mỗi trang web là 'tùy chỉnh' để cho phép khả năng tùy chỉnh (ngay cả khi không tồn tại vào lúc này)
DTest

@DTest điều này vẫn có thể được thực hiện, nó chỉ có nghĩa là nhiều công việc hơn cho nhiều xung đột, tùy thuộc vào bản chất của tùy chỉnh. Tất nhiên, nếu bạn đang thực hiện RẤT NHIỀU tùy chỉnh, phải xử lý các xung đột có thể tốt hơn là quên rằng bạn đã thay đổi index.php cho một khách hàng và thay thế nó bằng một index.php mới không còn các tính năng đặc biệt nữa
DerfK

@DTest cũng vậy, tôi sẽ thứ hai đề xuất "kiểm soát phiên bản phân tán" cho trường hợp này. Bạn thực sự có thể theo dõi các thay đổi tùy chỉnh bạn đã thực hiện cho khách hàng và kiểm tra chúng vào kho lưu trữ "cá nhân" của khách hàng, sau đó kéo các thay đổi từ kho lưu trữ "trung tâm" (không bao giờ đẩy các thay đổi tùy chỉnh của khách hàng trở lại từ một khách hàng đến kho lưu trữ trung tâm)
DerfK

0

Tất cả những gì mọi người đang nói về những gì phiên bản là tốt.

Nếu bạn quyết định chuyển sang lật đổ, tôi có thể khuyên bạn nên thử ngăn xếp Bitnami Trac; http://bitnami.org/stack/trac

Nó đơn giản hóa việc thiết lập lật đổ cho bạn, đi kèm với hệ thống bán vé (bạn có thể chọn sử dụng ở giai đoạn này hay không) để theo dõi các thay đổi và lỗi và wiki mà bạn có thể sử dụng để ghi lại cách bạn muốn nhà phát triển sử dụng hệ thống.

Cung cấp cho tất cả các nhà phát triển Windows của bạn TortoiseSVN. Dạy cho mọi người một vài điều cơ bản về dòng lệnh svn.

Vào cuối ngày, công cụ ít quan trọng hơn suy nghĩ bạn cần thấm nhuần trong các nhà phát triển của mình. Hy vọng rằng họ sẽ sớm thấy rằng kiểm soát phiên bản là Điều tốt vì nó ngăn họ mất việc và cho phép họ hoàn nguyên từ ngõ cụt đang đưa họ trở lại trạng thái tốt đã biết. Những lợi ích lớn hơn chi phí (nhẹ).

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.