Có phải là bất thường khi một công ty nhỏ (15 nhà phát triển) không sử dụng kiểm soát nguồn / phiên bản được quản lý? [đóng cửa]

Đây thực sự không phải là một câu hỏi kỹ thuật, nhưng có một số câu hỏi khác ở đây về kiểm soát nguồn và thực tiễn tốt nhất.

Công ty tôi làm việc (sẽ ẩn danh) sử dụng chia sẻ mạng để lưu trữ mã nguồn và mã phát hành. Nhà phát triển hoặc người quản lý có trách nhiệm di chuyển mã nguồn theo cách thủ công vào thư mục chính xác tùy thuộc vào việc nó được phát hành hay không và đó là phiên bản nào. Chúng tôi có nhiều bảng tính khác nhau rải rác xung quanh nơi chúng tôi ghi lại tên và phiên bản tệp và những gì đã thay đổi, và một số nhóm cũng đặt chi tiết của các phiên bản khác nhau ở đầu mỗi tệp. Mỗi đội (2-3 đội) dường như làm điều này khác nhau trong công ty. Như bạn có thể tưởng tượng, đó là một mớ hỗn độn có tổ chức - có tổ chức, bởi vì "đúng người" biết công cụ của họ ở đâu, nhưng một mớ hỗn độn vì tất cả đều khác nhau và nó phụ thuộc vào việc mọi người nhớ phải làm gì bất cứ lúc nào.

Tôi đã cố gắng thúc đẩy một số loại kiểm soát nguồn được quản lý trong một thời gian, nhưng dường như tôi không thể có đủ hỗ trợ cho nó trong công ty. Đối số chính của tôi là:

• Chúng tôi hiện đang dễ bị tổn thương; tại bất kỳ thời điểm nào, ai đó có thể quên thực hiện một trong nhiều hành động phát hành mà chúng tôi phải thực hiện, điều đó có nghĩa là toàn bộ phiên bản không được lưu trữ chính xác. Có thể mất hàng giờ hoặc thậm chí vài ngày để ghép một phiên bản lại với nhau nếu cần thiết
• Chúng tôi đang phát triển các tính năng mới cùng với sửa lỗi và thường phải trì hoãn việc phát hành cái này hay cái kia vì một số công việc chưa được hoàn thành. Chúng tôi cũng phải buộc khách hàng sử dụng các phiên bản bao gồm các tính năng mới ngay cả khi họ chỉ muốn sửa lỗi, vì thực sự chỉ có một phiên bản chúng tôi đang làm việc
• Chúng tôi đang gặp sự cố với Visual Studio vì nhiều nhà phát triển đang sử dụng cùng một dự án cùng một lúc (không phải cùng một tệp, nhưng nó vẫn gây ra sự cố)
• Chỉ có 15 nhà phát triển, nhưng tất cả chúng ta đều làm những thứ khác nhau; Sẽ tốt hơn nếu có một cách tiếp cận toàn công ty tiêu chuẩn mà tất cả chúng ta phải tuân theo?

Câu hỏi của tôi là:

1. Có phải bình thường đối với một nhóm có kích thước này không có kiểm soát nguồn?
2. Cho đến nay tôi chỉ được đưa ra những lý do mơ hồ cho việc không kiểm soát nguồn - những lý do nào bạn đề xuất có thể hợp lệ cho việc không thực hiện kiểm soát nguồn, được cung cấp thông tin ở trên?
3. Có thêm lý do nào để kiểm soát nguồn mà tôi có thể thêm vào kho vũ khí của mình không?

Tôi đang hỏi chủ yếu để có được cảm giác về lý do tại sao tôi có quá nhiều sức đề kháng, vì vậy hãy trả lời thành thật.

Tôi sẽ đưa ra câu trả lời cho người mà tôi tin là đã thực hiện phương pháp cân bằng nhất và đã trả lời cả ba câu hỏi.

Cảm ơn trước

1. Nó có thể không bình thường , nhưng như Treb nói , nó có lẽ không phải là bất thường

2. Như những người khác đã nói, không có lý do hợp lệ cho việc không kiểm soát nguồn trong một công ty có quy mô của bạn. Vì vậy, bạn cần xác định và tấn công những lý do không hợp lệ :

   a) cái chính là hiện trạng : "nếu nó không bị hỏng, đừng sửa nó". Điều này thật khó: bạn có thể bắt đầu chỉ ra tất cả những thứ không hoạt động tốt như chúng (có thể nhanh chóng khiến bạn bị gắn mác là "người tiêu cực"), hoặc bạn chỉ cần chờ đợi một cái gì đó nổ tung (có thể không bao giờ xảy ra), hoặc bạn có thể nhấn mạnh tất cả những điều có thể đi sai. Thật không may, những người phụ trách các công ty nhỏ tương đối không tin vào 'những điều có thể sai' cho đến khi họ thực sự làm sai ...

   b) thờ ơ / sợ hãi / không chắc chắn : "chúng tôi không thực sự hiểu kiểm soát nguồn là gì; chúng tôi không biết cách sử dụng nó; chúng tôi không biết nên chọn công cụ nào; nó sẽ làm hỏng phong cách của chúng tôi" . Đây là một lý do tôi chắc chắn sẽ không gửi chúng ở đây! Nó có thể là một thứ tự khá cao đối với bạn, nhưng tôi nghĩ để tối đa hóa cơ hội bạn cần đưa ra giải pháp 'chìa khóa trao tay', và không có quá nhiều biến thể hoặc giải pháp thay thế. Bạn cần một ý tưởng rõ ràng về: cách bạn muốn điều chỉnh / biến đổi quy trình làm việc của bạn để làm việc với công cụ đã cho; Làm thế nào / nếu bạn có kế hoạch sao lưu mã hiện có; bạn nghĩ bạn có thể 'đào tạo' người dùng nhanh như thế nào và giúp họ chạy và chạy; làm thế nào bạn có thể quản lý thời gian chuyển tiếp (nếu có); nó có khả năng 'chi phí' bao nhiêu (tính bằng giờ, nếu không tính bằng đô la).

   c) có thể có những lý do khác (ví dụ như những trải nghiệm tồi tệ trước đây với VSS hoặc đã đọc 'câu chuyện kinh dị' về các công cụ được cho là quá phức tạp), nhưng bạn sẽ phải cá nhân hóa chúng khi bạn phát hiện ra chúng.

3. Có nhiều lý do để kiểm soát nguồn được nêu trong các câu trả lời khác. Lời khuyên của tôi sẽ được chọn ra chính 2 hoặc 3 có thể thực sự tạo sự khác biệt cho công ty của bạn và đánh bóng chúng lên và trình bày chúng trong một cuộc họp để như nhiều đồng nghiệp của bạn càng tốt. Cố gắng kích động thảo luận: ngay cả khi bạn không thuyết phục được họ ngay lập tức, bạn sẽ hiểu rõ hơn về những điểm gắn bó có thể là gì.

(Bạn đã đọc / nghe về Hàm thay đổi chưa?)

Hoàn toàn không bình thường khi một nhóm có kích thước hoạt động mà không có kiểm soát nguồn. Kích thước của nhóm lập trình viên lớn nhất có thể hoạt động hiệu quả mà không cần kiểm soát nguồn nhỏ hơn hoặc bằng một. Đó là hoàn toàn không thể tha thứ để làm việc mà không kiểm soát phiên bản dành cho một đội ngũ chuyên nghiệp của bất kỳ kích thước, và có lẽ tôi sẽ không cảm thấy sáng tạo, nhưng tôi không thể đưa ra bất kỳ lý do tại sao bạn muốn từ bỏ nó.

Kiểm soát phiên bản chỉ là một công cụ khác, một công cụ đặc biệt mạnh mẽ và mang lại lợi ích to lớn so với chi phí tối thiểu của nó. Nó mang lại cho bạn sức mạnh để quản lý tốt tất cả các thay đổi của bạn theo cách có tổ chức, với tất cả các loại tiện ích khác như phân nhánh, hợp nhất tự động, gắn thẻ, v.v. Nếu bạn cần xây dựng một phiên bản từ nhiều phiên bản trước, bạn có thể kiểm tra mã từ thời điểm đó và chỉ cần xây dựng mà không phải nhảy qua bất kỳ vòng đua nào khác.

Quan trọng hơn, nếu bạn cần viết một bản sửa lỗi, bạn có thể hợp nhất nó vào một bản cập nhật mà không phải cung cấp các tính năng mới mà bạn đang làm việc trên hệ thống vì họ đang ở một nhánh khác và trong phần còn lại của sự phát triển cần Hãy quan tâm, họ chưa tồn tại.

Bạn đang gặp phải sự kháng cự vì bạn đang thách thức văn hóa của công ty. Sẽ mất thời gian để họ điều chỉnh, bất kể bạn nói gì. Điều tốt nhất bạn có thể làm là tiếp tục thúc đẩy nó và nếu công ty thực sự không nhúc nhích, hãy tìm một công việc khác phù hợp hơn với trình độ của bạn với tư cách là nhà phát triển.

Có phải bình thường đối với một nhóm có kích thước này không có kiểm soát nguồn?

Theo kinh nghiệm của tôi, nó không phải là chuẩn mực, nhưng không hoàn toàn bất thường như các câu trả lời khác ở đây cho thấy. Phần lớn các công ty nhỏ không sử dụng kiểm soát nguồn, nhưng một số lượng đáng kể không, không may.

Cho đến nay tôi chỉ được đưa ra những lý do mơ hồ cho việc không kiểm soát nguồn - lý do nào bạn đề xuất có thể hợp lệ cho việc không thực hiện kiểm soát nguồn, được cung cấp thông tin ở trên?

Xem câu hỏi này trên SO để thảo luận tốt. Câu trả lời được chấp nhận cho biết:
"Không có lý do chính đáng để không sử dụng kiểm soát phiên bản. Không phải là một."

Có thêm lý do nào để kiểm soát nguồn mà tôi có thể thêm vào kho vũ khí của mình không?

Sự đồng thuận giữa tất cả các nhà phát triển và quản lý dự án mà tôi đã gặp, và tất nhiên ở đây trên Lập trình viên và SO là kiểm soát nguồn là bắt buộc. Đó là một thực tiễn tốt nhất được chấp nhận . Nếu ai đó quyết định phớt lờ nó, anh ta cần phải có một số lập luận rất mạnh mẽ và thuyết phục tại sao đây là quyết định đúng đắn của anh ta (nghĩa là hơn một chút so với 'chúng ta không bao giờ cần nó, vậy tại sao chúng ta cần nó trong tương lai'). Các đối số bạn đã trình bày cho đến nay đều tập trung vào các vấn đề cụ thể, có lẽ bạn nên thử một cách tiếp cận rộng hơn dọc theo dòng chữ 'mọi người làm điều đó, vậy tại sao chúng ta cũng không?

Kiểm soát nguồn là tốt cho ngay cả một nhóm nhà phát triển. Bất kỳ hệ thống kiểm soát nguồn nào về cơ bản là một hệ thống kiểm soát phiên bản giúp theo dõi các thay đổi. Hãy tưởng tượng về một nhà phát triển duy nhất, người có thể đã xóa một số mã và cảm thấy rằng mã này hiện đang được yêu cầu. Anh ta có thể lấy lại mã cũ không?

Chỉ cần đi cho một công cụ giúp bạn. Kích thước không quan trọng ở mọi nơi. Chất lượng không thành vấn đề ở mọi nơi.

Có vẻ như bạn đã sử dụng một hệ thống kiểm soát phiên bản, nhưng không phải là một hệ thống rất tốt. Mọi người dường như đã nhận ra sự kiểm soát phiên bản cần thiết. Bạn chỉ cần giới thiệu chúng với cấp độ tiếp theo - kiểm soát phiên bản phần mềm.

Nếu là tôi, tôi sẽ giới thiệu SCM như một phiên bản cải tiến của những gì họ đang làm. Tôi sẽ nhấn mạnh việc sử dụng một công cụ tốt sẽ tự động hóa rất nhiều công việc đang diễn ra.

• Thay vì ghi lại các thay đổi trong bảng tính, hệ thống SCM theo dõi không chỉ những gì đã thay đổi, mà cả những người đã thay đổi nó và tại sao.

• Như một phần thưởng, bạn có thể quay lại bất kỳ điểm nào trong cuộc sống của mã và xem những gì thực sự ở đó.

• Thay vì có các phiên bản mã khác nhau trong các thư mục khác nhau và cần di chuyển / hợp nhất mọi thứ giữa các thư mục để chuyển một thay đổi, bạn có thể giữ mọi thứ ở cùng một vị trí và (quan trọng hơn), hãy để công cụ thực hiện việc hợp nhất.

Như những người khác đã nói, tôi sẽ mong đợi một số kháng cự, vì vậy tôi sẽ tạo nguyên mẫu cho hệ thống bằng cách sử dụng nó vào những thứ tôi đang làm.

.

Cho đến nay tôi chỉ được đưa ra những lý do mơ hồ cho việc không kiểm soát nguồn - những lý do nào bạn đề xuất có thể hợp lệ cho việc không thực hiện kiểm soát nguồn, được cung cấp thông tin ở trên?

• Sản phẩm bạn đang phát triển là một hệ thống kiểm soát phiên bản; các nhà quản lý lo ngại về việc ngăn chặn các sản phẩm hiện có ảnh hưởng đến việc thiết kế và triển khai sản phẩm mới.

• Giữa những ngày cuối tuần BASE nhảy và chạy với những con bò đực, những người quản lý tìm kiếm cảm giác thích thú lái xe đi làm để tự hỏi liệu mọi thứ đã đi vào địa ngục chưa.

• Tránh tiếp quản thù địch. Ai sẽ muốn có được một bộ trang phục phát triển phần mềm được quản lý theo cách này?

Có thêm lý do nào để kiểm soát nguồn mà tôi có thể thêm vào kho vũ khí của mình không?

• Bạn đã thực hiện kiểm soát phiên bản, nhưng hiện tại bạn đang thực hiện nó theo cách ít hiệu quả nhất, tốn nhiều công sức nhất, dễ bị lỗi nhất có thể tưởng tượng được. Sử dụng VCS sẽ tiết kiệm tiền, tiết kiệm thời gian và cải thiện chất lượng.

• Tiết kiệm không gian đĩa. Hầu hết các hệ thống kiểm soát phiên bản chỉ lưu các vùng đồng bằng giữa các tệp. Hiện tại, bạn đang lưu toàn bộ bản sao của mọi phiên bản của mọi tệp. (Sao lưu tất cả các bản sao đó phải mất rất nhiều thời gian và không gian!)

• Một số nhà phát triển có thể làm việc trên cùng một tệp cùng một lúc và điều hòa sự khác biệt mà không gặp quá nhiều khó khăn. Việc hợp nhất các thay đổi tất nhiên là có thể nếu không có VCS, nhưng gần như không thể theo dõi ai đã thay đổi cái gì, khi nào và tại sao trong trường hợp đó.

• Cho phép các nhà phát triển tự do thử các ý tưởng mới khi biết rằng họ có thể khôi phục bất kỳ phiên bản nào vào bất kỳ lúc nào.

• Quá trình tốt hơn làm cho việc thuê và giữ các nhà phát triển tài năng dễ dàng hơn.

Có phải bình thường đối với một nhóm có kích thước này không có kiểm soát nguồn?

Không chắc chắn không. Khi tôi bắt đầu ở công ty hiện tại của mình, có một người mà bạn nên gửi mã đã thay đổi và anh ấy sẽ hợp nhất nó. Tôi có thể thuyết phục mọi người trong vòng vài ngày để sử dụng SVN.

Cho đến nay tôi chỉ được đưa ra những lý do mơ hồ cho việc không kiểm soát nguồn - lý do nào bạn đề xuất có thể hợp lệ cho việc không thực hiện kiểm soát nguồn, được cung cấp thông tin ở trên?

Tôi nghĩ lý do bạn chỉ nghe thấy những lý do mơ hồ là vì không có lý do hợp lệ cho việc không sử dụng kiểm soát phiên bản.

Có thêm lý do nào để kiểm soát nguồn mà tôi có thể thêm vào kho vũ khí của mình không?

Vâng, có rất nhiều lý do.

1. Sự phân nhánh mang đến cho bạn khả năng phát triển chức năng mới mà không can thiệp vào các phát triển khác.
2. Mỗi cam kết cung cấp cho bạn thông tin về chính xác những gì đã được thay đổi, ai đã thực hiện thay đổi đó và khi nào thay đổi đó được thực hiện.
3. Bạn có thể dễ dàng phạm lỗi và triển khai chúng cho khách hàng và bỏ qua chức năng mới chưa hoàn thành.
4. Bạn có thể duy trì các phiên bản khác nhau, nếu khách hàng sợ đến phiên bản mới hơn.
5. Bạn có thể làm việc trên cùng một dự án (ngay cả các tệp nguồn giống nhau!) Một cách dễ dàng.
6. Bạn có thể dễ dàng hoàn nguyên một lỗi, với việc giữ nguyên các thay đổi sau lỗi đã phạm.

Một số người gặp khó khăn khi nhận ra hiện trạng tồi tệ như thế nào cho đến khi họ thấy điều gì đó tốt hơn cho chính mình. Những gì bạn cần là một bản demo tốt . Hiển thị một số ví dụ thực tế của các nhiệm vụ nó có thể cải thiện. "Điều này khiến tôi mất 4 giờ để theo dõi hệ thống hiện tại của chúng tôi, nhưng lệnh điều khiển nguồn này đã cho tôi biết ngay lập tức."

Không sử dụng kiểm soát nguồn là yêu cầu các vấn đề, ngay cả đối với một nhà phát triển solo. Một thực tế đơn giản là bạn có thể chỉnh sửa một cách tàn nhẫn mà không có nguy cơ mất bất cứ thứ gì bù đắp cho nỗ lực học tập trong vòng vài tuần hoặc vài ngày.

Điều đó nói rằng, nếu bạn không thể thuyết phục các nhà quản lý của mình giới thiệu kiểm soát nguồn, hãy tạo cho mình một sự ưu ái và ít nhất là sử dụng một cái gì đó như git hoặc đồng bóng tại địa phương - nếu mọi thứ nổ tung do thiếu kiểm soát nguồn, ít nhất bạn sẽ không một người đã làm nó

Công ty của tôi sử dụng GIT để kiểm soát phiên bản. Công ty là một nhà phát triển, một CEO, một nhân viên bảo vệ, một phụ nữ dọn dẹp và một người tiếp nhận. Tất cả bọn họ là tôi. Kiểm soát phiên bản nguồn là PHẢI mọi lúc.

Tôi làm việc trên rất nhiều dự án một mình và tôi vẫn sử dụng kiểm soát phiên bản. Kích thước không quan trọng. Nó luôn giúp kiểm soát phiên bản.

Có một lý do nó là số 1 trong Bài kiểm tra Joel: http://www.joelonsoftware.com/articles/fog0000000043.html

Ngoài ra, nó làm cho # 2 và # 3 trong danh sách có thể.

Chúng tôi đã ở một vị trí tương tự với một đội 6 người vài năm trước. Một trong những nhà phát triển đã thực hiện bước cài đặt SVN trên máy chủ dev nơi thư mục dùng chung và bắt đầu sử dụng nó.

Mọi người đều làm theo, và không lâu trước khi chúng tôi triển khai CI ( CruiseControl ) và cách mạng hóa quy trình xây dựng và phát hành của chúng tôi để bao gồm kiểm tra chất lượng và tự động hóa.

WTF?! Đây có thể là câu hỏi lố bịch nhất mà tôi từng thấy. Bạn cần tìm một công việc mới. 15 nhà phát triển?! Bạn nghĩ đó là một đội nhỏ? Điều này là điên rồ. Người quản lý nên được chấm dứt ngay lập tức. Thành thật mà nói, tôi sẽ gặp ác mộng sau khi đọc câu hỏi này. Xin vui lòng cho chúng tôi biết sản phẩm bạn bán để tất cả chúng ta biết không mua nó! Tôi không biết những gì đáng sợ hơn, câu hỏi này hoặc câu trả lời nói rằng điều này không phải là bất thường!

Tôi không thể tưởng tượng làm thế nào 15 nhà phát triển có thể làm việc mà không cần kiểm soát nguồn. Tuy nhiên, từ:

(...) Sử dụng chia sẻ mạng để lưu trữ mã nguồn của nó (...)

Tôi giả sử bạn đã tạo kiểm soát phiên bản của người nghèo như VSS (cũng dựa trên thư mục dùng chung). Đó là rủi ro và không hiệu quả.

Giải thích cho sếp của bạn biết nó tệ như thế nào, đầu tư vào một số khóa đào tạo SVN hoặc GIT 2 ngày và bắt đầu sử dụng hệ thống kiểm soát phiên bản thực trong khi bạn vẫn có mã của mình trong hình dạng hợp lý.

Nếu tôi không cam kết nhiều lần trong ngày, hoặc ít nhất là trước khi tôi rời khỏi nhà, tôi cảm thấy như .. đôi khi thiếu, đôi khi sai.

Tôi đã từng làm việc trong một công ty chỉ có 2 nhà phát triển (tôi + anh chàng quản trị viên tóc dài), vào năm 1998. Thậm chí sau đó chúng tôi đã sử dụng svn. Thật tiện lợi.

Nhiều lần trong sự nghiệp, tôi đã mất một ngày làm việc vì tôi đã làm một cái gì đó như mv thay vì cp và sau đó rm -rf. Khiến tôi khóc và lang thang trên đường phố trong tuyệt vọng.

Tôi đã làm việc tại 5 công ty trong hơn 13 năm ở SE, tham gia một số hội nghị và chưa bao giờ gặp phải một công ty không sử dụng kiểm soát phiên bản.

Tuy nhiên, công ty thiết kế nội thất yêu thích của tôi, 20 nhân viên, sử dụng bảng trắng để quản lý dự án + cộng tác. Họ biết sai lầm rõ ràng, nhưng dường như họ không tìm thấy thời gian để nâng cấp. Bằng cách nào đó nó hoạt động mặc dù. Đừng hỏi tôi như thế nào.

Là một nhà lãnh đạo. Trở thành một nhà lãnh đạo có nghĩa là làm những gì đúng; chủ động giải quyết vấn đề. Lãnh đạo không làm gì cả vì không có đủ sự đồng thuận. Và một nhà lãnh đạo giỏi học cách nhận ra các tình huống khi một người nên xây dựng sự đồng thuận và khi nào nên làm. Đây rõ ràng là một tình huống làm. Việc thiếu kiểm soát mã SILL sẽ nổ tung trong khuôn mặt của bạn sớm hay muộn.

Các nhà lãnh đạo thường không ở vị trí quản lý chính thức. Mọi người sẽ theo các nhà lãnh đạo giỏi, quyết đoán bất kể chức danh.

Nếu những nỗ lực quyết định của bạn bị đánh sập, đặc biệt là nếu đó là từ quản lý thì đó là một dấu hiệu rõ ràng để bạn thoát khỏi địa ngục. Đó là một lực cản cho sự phát triển chuyên nghiệp của bạn; và các nhà phát triển có năng lực và quản lý không đủ năng lực không trộn lẫn, và một người không đủ năng lực sẽ làm bạn khó chịu.

OK, hồi tưởng đang đến với tôi. Ký tắt. Chúc may mắn.

1. Nhận đồng hồ bấm giờ,
   • Đếm thời gian bạn dành trong bảng tính chỉ để đồng bộ hóa các phiên bản
   • Đếm thời gian bạn dành để sửa chữa các phiên bản bị hỏng
   • đếm số lần mọi người hét lên trên hành lang " tôi đang chỉnh sửa main.c!, chỉ để đảm bảo không có ai khác ở ngay bây giờ!" .
   • đếm số lượng khiếu nại bạn nhận được từ khách hàng vì lỗi của họ chứa các thay đổi khác
   • đếm thời gian trì hoãn phát hành chỉ vì bạn không thể đồng bộ hóa các phiên bản
2. Tạo một powerpoint với dữ liệu này, so sánh với cách vcs sẽ hoạt động.
3. Hiển thị quản lý

Đây chỉ là một tai nạn chờ đợi để xảy ra. Bạn không có lịch sử mã và trong một lần thất bại, một trong những nhà phát triển của bạn có thể xóa sổ hàng tháng làm việc. Là một công ty nhỏ, bạn không thể đủ khả năng loại thất bại này.

Bạn cũng rất tiếp xúc với ổ đĩa chia sẻ đó. Ngay cả với một bản sao lưu tốt, bạn có thể đủ khả năng để không làm việc trong bao lâu. 1 giờ, 1 ngày, 1 tuần. Sẽ mất bao lâu để có được một máy chủ mới, khôi phục từ bản sao lưu, v.v. Một lần nữa, với tư cách là một công ty nhỏ, bạn có thể không có thêm phần cứng ở chế độ chờ và có thể không dễ dàng bỏ tiền để nhận vận chuyển nhanh, v.v.

Hãy suy nghĩ về lưu trữ ngoại vi là tốt. Một trận lụt hay hỏa hoạn không thực sự bất thường. Điều gì sẽ xảy ra nếu có một đám cháy trong tòa nhà sau nhiều giờ. Bao nhiêu tháng làm việc sẽ bị mất. Một kho lưu trữ mã được quản lý như github sẽ có giá trị cho việc này. Ngay cả việc sử dụng máy chủ SVN đơn giản trên dịch vụ lưu trữ cũng sẽ là một bước tiến trong lĩnh vực này.

LordScree, tôi đang ở trong tình trạng gần như giống hệt như bạn, đội ngũ trực tiếp của tôi có khoảng 15 nhà phát triển. Tôi không tin (gần như kinh dị) rằng kiểm soát nguồn không được sử dụng. Phản hồi ban đầu của tôi về "chúng ta nên sử dụng kiểm soát nguồn" là "chúng ta không có thời gian để thực hiện". Đối với tôi, giống như mặc đồ lót, kiểm soát nguồn không phải là tùy chọn. Sau một vài tháng, tôi cũng đã chấp thuận triển khai TFS, được chọn bởi org vì nó là MS và đi kèm với bản dùng thử 90 ngày. Điểm mấu chốt, rất khó để thuyết phục một tổ chức về nhu cầu kiểm soát nguồn khi họ đã đi lang thang mà không có nó. Tôi nói với các nhà phát triển rằng bất cứ khi nào bạn thấy mình sao lưu các tệp, đặc biệt là một ngày trong tên tệp hoặc thư mục được sao lưu, là một ví dụ về thời điểm bạn đặt thứ gì đó trong kiểm soát nguồn. Tôi không Tôi có bất kỳ câu trả lời tuyệt vời cho bạn, nhưng tôi tin rằng điều này là không phổ biến. Tôi đang chiến đấu trong cùng một trận chiến và sẽ thông báo cho bạn về tiến trình. Và, hy vọng sẽ có những tiến bộ khác mà tôi có thể tìm ở nơi khác vì tôi không thể làm việc trong hỗn loạn!

chúng tôi có 3 thành viên của đội ngũ phát triển và sử dụng kiểm soát nguồn. Trong các dự án cá nhân của tôi, tôi có một nhà phát triển và tôi sử dụng kiểm soát nguồn. Nó không chỉ hữu ích cho quản lý nhóm, nó hữu ích để có thể thực hiện công việc thử nghiệm mà không sợ bạn làm gì để phá hủy một cái gì đó.

Cách dễ nhất để thuyết phục quản lý? Có ít rủi ro hơn cho toàn bộ sản phẩm và về lâu dài nó sẽ tăng năng suất của nhà phát triển. Cả hai đều đúng, và cả hai đều hấp dẫn các nhà quản lý.

Đây không phải là một kịch bản bình thường và tôi nghĩ bạn nên đưa ra một cuộc chiến khó khăn để có được thiết lập này trong công ty của bạn. Nó có lợi ích rất lớn và không có điểm nào nhận ra điều tương tự khi bạn đến gần ngày tận thế và đó không phải là tình huống xảy ra nếu nó không bị hỏng thì đừng sửa nó

Bất kỳ lý do cho việc không thực hiện nó có thể chỉ là một cái cớ cho công việc tồi tệ hoặc một sai lầm đang chờ để xảy ra.

Chỉ cần cho họ biết thật tuyệt vời khi tìm thấy ứng dụng này vào ngày 1 tháng 1 năm nay

Làm thế nào về hey chức năng này đã được thêm vào tháng ba tôi nghĩ rằng chúng ta cần mở rộng thêm một chút về điều này.

Wow lỗi này 154256 đã được sửa trong cam kết này.

Tôi có thể phân nhánh ứng dụng và gửi đi triển khai, không có vấn đề gì bạn có thể tiếp tục làm việc.

Điều này có thể tiếp tục và tiếp tục ... (hãy nhớ thêm nhận xét về các lần xác nhận sau này vào câu hỏi khác sẽ được đưa ra dưới dạng câu hỏi khác)

Tôi sử dụng kiểm soát phiên bản cho các dự án một người và các dự án công việc của mình, nơi chúng tôi có tới 30- 40 người làm việc trên cùng một mã. Kiểm soát phiên bản có lợi thế về tổ chức, nhưng khả năng hoàn nguyên các tệp và thay đổi stash thực sự có thể làm đau đầu việc quản lý mã ... và cuối cùng, đó là kịch bản tốt nhất cho lập trình viên, vì vậy họ chỉ có thể tập trung vào mã hóa.

Lý do để hỗ trợ không sử dụng kiểm soát phiên bản là khá hạn chế. Tất cả những gì tôi có thể nghĩ là khía cạnh kỹ thuật của mọi thứ.

• Có quá nhiều đường cong học tập để chuyển đổi quy trình làm việc của toàn bộ nhân viên của bạn để kết hợp một hệ thống phiên bản để có hiệu quả về chi phí.
• Người quản lý dự án của bạn không cảm thấy rằng sẽ có ích khi giới thiệu chi phí chung vào quy trình quản lý và duy trì kho lưu trữ. (Chủ yếu là một vấn đề với các Hệ thống Phiên bản cũ hơn)

Có nhiều lý do để sử dụng một hệ thống phiên bản. Ít nhất là ngừng di chuyển mọi thứ xung quanh. Làm việc với các bản vá. Các hệ thống phiên bản có thể làm chính xác những gì bạn nói bạn làm.

• Bạn có thể làm việc trên phiên bản tiếp theo cùng lúc bạn đang thực hiện sửa lỗi và phát hành chúng một cách riêng biệt.
• Thay vì di chuyển các tệp từ vị trí này sang vị trí khác để làm việc trên đó, bạn có thể tạo một nhánh và hợp nhất nó vào bản gốc sau khi hoàn thành.
• Mỗi nhà phát triển có thể có bản sao mã nguồn riêng để ngăn chặn các sự cố với cùng một dự án mở trên nhiều máy.
• Tai nạn xảy ra, nếu mã bị hỏng nghiêm trọng, tất cả những gì bạn cần thực hiện để quay lại số sửa đổi làm việc cuối cùng.
• Kiểm soát phiên bản hoạt động tốt kết hợp với trình theo dõi lỗi và hệ thống tích hợp liên tục.

Cá nhân tôi với tư cách là một nhóm sử dụng phiên bản, theo dõi lỗi, tích hợp liên tục, đánh giá mã, kiểm tra tính nhất quán mã, kiểm tra đơn vị, kiểm tra selen, phân tích mã nguồn và có thể tôi sẽ quên nhiều hơn. Tôi thừa nhận, có một đường cong học tập nhẹ. Ngoài ra còn có sự đánh đổi về thời gian quản trị bổ sung cần thiết cho các bước gây nghiện mà bạn tự động hóa. Theo kinh nghiệm của tôi, nỗ lực tiết kiệm vượt xa thời gian quản trị bổ sung.

Trong công việc nghiêm túc đầu tiên của tôi vào năm 1990, tôi là nhà phát triển duy nhất làm việc trong bộ phận của mình và không biết sử dụng kiểm soát nguồn.

Ngay sau đó tôi mới biết, từ đó trở đi tôi chưa bao giờ thấy một dự án nào không biến nó thành một trong những điều đầu tiên họ thiết lập.

Tôi gần như mất tất cả công việc của mình tại công việc đó vì tôi đã xóa một thư mục ở cấp độ sai. May mắn thay, tôi đã mang một bản sao về một đĩa mềm 5 "vào tuần trước và có thể tạo lại các tuần làm việc trong một vài ngày dài.

Vì vậy, tôi đoán tôi sẽ xem xét nó có thể chấp nhận được nếu đó là dự án đầu tiên cho mọi người trong nhóm và không ai biết rõ hơn, nhưng ngay cả khi một người thực sự có thể giải thích các lợi ích và nhóm vẫn không lắng nghe tôi sẽ phân loại lại ý kiến ​​của nhóm từ "ngây thơ" đến "bất tài nguy hiểm" (Việc chống lại việc sử dụng một công cụ có lợi ích được chứng minh rộng rãi như vậy là gần như tội phạm - giống như nếu nhóm của bạn không tin tưởng "Trình biên dịch" và khăng khăng làm mọi thứ bằng ngôn ngữ lắp ráp ).

Tôi đã mã hóa điều này rất nhiều ... trong các công ty kỹ thuật / điện tử nhỏ nơi họ làm nhiều phần mềm / phần cứng nhúng.

Ở những nơi này, SCM không phải là một phần của văn hóa kỹ thuật điện tử. Họ thường có một kỹ sư cho mỗi dự án, những người chỉ cần sao lưu bản phát hành mới nhất.

Vì vậy, phân nhánh / hợp nhất và thậm chí chia sẻ mã được coi là không liên quan. Ngoài ra, các công ty này có lẽ là 9000, vì vậy quá trình, albiet lạ, có lẽ được ghi lại.

Trong mọi trường hợp, tôi / các nhà phát triển khác mới bắt đầu sử dụng SCM cá nhân.

Nơi tôi làm việc chúng ta có cùng một vấn đề. Tôi hiện đang cố gắng trượt điều khiển nguồn trong "dưới radar" để giải quyết các vấn đề tương tự mà bạn có. Tôi sử dụng hóa thạch cho các dự án tôi phát triển cá nhân.

Gần đây tôi có một máy chủ hóa thạch được thiết lập trên mạng LAN của công ty, vì vậy bây giờ nó còn tiện lợi hơn nữa. Tôi hy vọng rằng khi tôi chứng minh tính hữu ích của một số dự án nhỏ hơn, tôi sẽ làm suy yếu sức đề kháng và đưa chúng ta ra khỏi hiện trạng của các thư mục mạng.

Những lý do lớn nhất tôi từng nghe về việc không sử dụng hóa thạch hoặc một số VCS khác là:

1. Nhiều người trong số các "lập trình viên" là những đứa trẻ kịch bản và sẽ không hiểu cách sử dụng nó
2. Những người có thể học, nghĩ rằng nó là một phiền toái khi sử dụng
3. Những người này là người bảo vệ cũ, thoải mái với các thư mục mạng, vì vậy mọi người nên
4. Không ai có thời gian để thiết lập nó đúng, hoặc tìm hiểu cách sử dụng nó
5. Mặc dù các tính năng có thể là tuyệt vời, nhưng không có tính năng nào là cần thiết

Như bạn có thể thấy, tôi đang cố gắng khắc phục những điều này bằng cách chứng minh rằng nó đơn giản để sử dụng, đã được thiết lập, dễ học và các tính năng hoàn toàn xứng đáng.

Cuối cùng, ngay cả khi bạn không cho họ sử dụng kiểm soát nguồn, tất cả nằm trong cây mạng. Fossil có thể phiên bản mọi thứ trong toàn bộ cây và bạn có thể thiết lập nó để chạy bất cứ khi nào thay đổi tệp xảy ra, hoặc ít nhất mỗi giờ. Tôi đã thực hiện điều đó đối với một số dự án của chúng tôi "không cần kiểm soát nguồn" và nó đã cho phép tôi quay trở lại phiên bản tốt khi có sự cố.

Làm đúng và thậm chí họ sẽ không biết bạn đã làm điều đó. Sau đó, bạn có thể là người hùng khôi phục lại bản dựng bị hỏng và chứng minh công cụ của bạn hữu ích như thế nào.

Giờ đây, các công cụ DVCS như Git và Mercurial đã có sẵn, và rất dễ cài đặt và sử dụng, thực sự không có lý do gì để ngay cả một nhóm 1 (!) Không sử dụng kiểm soát nguồn. Đó không phải là về quy mô nhóm, đó là về lịch sử nhận xét về các thay đổi của bạn và khả năng hỗ trợ quy trình công việc như khắc phục các sự cố sản xuất trong khi làm việc trên một bản phát hành mới và theo dõi trạng thái của mã nguồn cho các phiên bản khác nhau.

Nếu tôi được đề nghị một công việc trong một nhóm có kích thước đó và không một nhà phát triển nào đề nghị sử dụng VCS, hoặc nếu "quản lý" đã ngăn cản họ, tôi sẽ từ chối. Nó chỉ không phải là một cách làm việc chấp nhận được những ngày này.

Bạn nên có cho mình một điều khiển phiên bản GIT ngay lập tức. Bạn có thể sử dụng nó ngay cả từ Google Code Project Hosting. Khi những người khác thấy bạn cam kết thay đổi chỉ bằng một cú nhấp chuột trong khi họ sao chép thủ công mọi thứ, có lẽ họ thay đổi suy nghĩ về nó.

Wow, thật tuyệt vời Mặc dù tôi không nghĩ đó là cách tốt nhất để xử lý kiểm soát mã, nhưng tôi làm việc tại một công ty có 6 nhà phát triển và không có kiểm soát nguồn nào được sử dụng, họ có cách quản lý tệp nội bộ, trình quản lý phát hành và whatnot sẽ giám sát tất cả các thay đổi. Trên thực tế, câu thần chú là chức năng mới có thể được thêm vào các dự án miễn là một loại công tắc nào đó được bọc xung quanh chức năng.

Ví dụ, chúng tôi đang làm việc trên mạng xã hội cấp ab được viết bằng PHP và khách hàng muốn chức năng có thể đăng ký vào hồ sơ người dùng. Về cơ bản, chức năng được gói trong một kiểm tra như thế này nếu (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {sau đó thực thi mã}

Nơi tôi làm việc cũng không bao giờ có nhiều nhà phát triển cùng lúc làm việc trên một tệp cụ thể, hầu hết mọi thứ đều là mô-đun nên trong trường hợp đó không cần kiểm soát nguồn. Tuy nhiên, tôi tin rằng những lợi thế của kiểm soát nguồn vượt xa những nhược điểm của việc không có nó trong hầu hết các trường hợp.

Thực tế công ty của bạn đang dùng đến bảng tính thay đổi tệp tài liệu và những gì đã được thay đổi khi một cái gì đó như Git hoặc Subversion có thể xử lý điều đó đối với bạn là hoàn toàn vô lý.

Có vẻ như bạn là một số người bị thuyết phục, nhưng ai đó trong tổ chức không trao quyền cho bạn để làm điều đó. Khi bạn có thể đọc từ các ý kiến ​​khác, bạn nên làm điều đó.

Bạn có thể tìm thấy một số thông tin ở đây: http://www.iNETcontact.be/scm/?page_id=353

Yếu tố quan trọng nhất là khách hàng của bạn bị buộc đến chi nhánh 'không ổn định' cuối cùng và nếu hợp đồng của bạn với khách hàng khiến bạn phải chịu trách nhiệm triển khai các phiên bản không ổn định, công ty của bạn sẽ mất tiền. Bạn nên thực sự tập trung vào sự ổn định phát hành ở đây. Đây là lý do chính để kiểm soát nguồn và dường như thất bại chính của bạn. Những cái khác sẽ không được cải thiện nhiều bằng cách sử dụng kiểm soát nguồn vì bạn đã có sẵn các hệ thống thay thế.