Cách khuyến khích kiểm soát phiên bản

Gần đây tôi đã bắt đầu làm việc trong một nhóm không có kiểm soát phiên bản. Hầu hết các thành viên trong nhóm không được sử dụng cho bất kỳ loại kiểm soát phiên bản nào. Tôi đã sử dụng riêng tư để theo dõi công việc của mình. Tôi muốn khuyến khích người khác chấp nhận nó, và ít nhất là bắt đầu phiên bản mã của họ khi họ phát triển các thay đổi. Bất cứ ai có thể cho tôi lời khuyên về cách tôi có thể khuyến khích áp dụng kiểm soát phiên bản phân tán, chẳng hạn như đồng bóng. Bất kỳ lời khuyên nào về cách thu hút mọi người, kể cả người quản lý vào DVCS sẽ được đánh giá cao.

Bạn cần tạo ra một trường hợp cho việc sử dụng kiểm soát phiên bản, và trước tiên hãy cố gắng bán nó cho đồng nghiệp của bạn, và nếu thất bại, hãy đưa chuỗi lên vị trí lãnh đạo dự án và cao hơn.

Đối với các kỹ sư phần mềm, trường hợp của bạn nên tập trung vào cách nó tiết kiệm thời gian và đau đầu trong thời gian dài. Tìm thời gian từ quá khứ của chính bạn, hoặc những câu chuyện được xuất bản (blog, bài viết trên tạp chí, sách trắng) về cách sử dụng kiểm soát phiên bản giúp cuộc sống của bạn dễ dàng hơn. Nếu bạn đã bị đốt cháy bởi không có kiểm soát phiên bản, hãy biến nó thành cá nhân. Nếu các nhà phát triển đồng nghiệp của bạn đã ở trong tình huống tương tự, họ sẽ thấy ánh sáng và cách các công cụ này có thể giúp họ.

Đây là đặt cược tốt nhất của bạn. Mặc dù tôi không thể tìm thấy (các) nguồn ngay bây giờ, tôi đã đọc (ở một vài nơi) rằng các thay đổi hiệu quả nhất để xử lý đến từ các nhà phát triển, những người phải đối phó với các thay đổi. Nếu bạn có thể đưa các nhà phát triển lên tàu, bạn sẽ đạt được hai điều. Đầu tiên, bạn đã mua từ những người sẽ bị ảnh hưởng bởi sự thay đổi quy trình. Thứ hai, có một nhóm người để thuyết phục ban quản lý rằng đây là một nỗ lực đáng giá và sẽ cải thiện sản phẩm và dự án.

Tuy nhiên, nếu bạn không thể nhận được sự hỗ trợ của nhóm phát triển và bạn vẫn cảm thấy vô cùng mạnh mẽ về việc triển khai kiểm soát phiên bản, thì bạn có thể chuyển sang quản lý. Nhưng nó sẽ trở nên rủi ro hơn nếu bạn đi một mình, vì bạn không chỉ phải lo lắng về việc bán cải tiến, mà còn phải đối phó với phản ứng dữ dội từ các đồng nghiệp của bạn.

Để dự án, chương trình và quản lý tổ chức, trường hợp phải là về cách triển khai kiểm soát phiên bản có thể tiết kiệm thời gian và tiền bạc của tổ chức. Những người ở cấp độ này quan tâm đến việc dự án tốn bao nhiêu tiền, đứng ở đâu so với ước tính, v.v. Tìm kiếm các trang trắng, sách, bài báo và các tài liệu và ấn phẩm chuyên nghiệp khác giải thích cách triển khai kiểm soát phiên bản đã giúp các tổ chức khác tiết kiệm thời gian và tiền bạc trong thời gian dài. Bạn cũng có thể giới thiệu một quan điểm chất lượng ở đây, nếu tổ chức của bạn quan tâm đến chất lượng phần mềm.

Bạn đặc biệt đề cập rằng bạn muốn sử dụng một hệ thống kiểm soát phiên bản phân tán. Đừng ép nó xuống cổ họng của đội hoặc tổ chức. Giới thiệu cho họ để kiểm soát phiên bản và các tùy chọn của họ. Mặc dù cá nhân bạn có thể thích sử dụng DVCS (như Mercurial), nhưng nó có thể không phù hợp nhất với nhóm và tổ chức của bạn. Sử dụng một công cụ không phù hợp sẽ chỉ làm cho vấn đề tồi tệ hơn thông qua việc đập phá.

Ngoài ra, hãy nhận thức được những rủi ro của việc giới thiệu quá trình muộn . Mặc dù việc sử dụng kiểm soát phiên bản là một cách thực hành tốt nhất thường được chấp nhận, nhưng có lẽ đã quá muộn để giới thiệu nó một cách hiệu quả cho dự án hiện tại mà không có rủi ro lớn để hoàn thành dự án. Thay vào đó, tôi sẽ khuyên bạn nên tập trung vào việc cải thiện hiện trạng cho các dự án và nhóm trong tương lai.

Ngoài ra, đây là một cách tiếp cận chung mà bạn có thể làm theo để thực hiện bất kỳ cải tiến quy trình hoặc công nghệ nào.

Câu hỏi đầu tiên là: hiện tại họ làm gì? Chắc chắn mỗi nhà phát triển không có mã nguồn bị kẹt trên hộp riêng của mình mà anh ta thay đổi theo ý muốn. Khi bạn có quy trình mà họ hiện đang tuân theo, bạn có thể đề xuất một số công cụ cải tiến quy trình này - thường thì SCM là lý tưởng để giúp họ thực hiện việc này, thay vì làm cho họ tuân theo quy trình khác.

Vấn đề chính ở đây là, nếu họ có cách làm việc giả SCM, có thể lưu trữ phiên bản hiện tại trên máy chủ ở đâu đó, thì bạn cần xác định xem DVCS hoặc CVS ​​có phù hợp hơn không, đừng thử bán chúng Mercurial nếu SVN là phù hợp hơn.

Cách nhanh nhất là thuyết phục ban quản lý rằng nó cần thiết.

Làm một số tính toán:

Chi phí phần mềm kiểm soát phiên bản - miễn phí.
Chi phí phần cứng để hỗ trợ kho lưu trữ - một máy chủ.
Chi phí triển khai phần mềm - một vài ngày cho một nhóm nhỏ, tăng cho các nhóm lớn hơn.

Chi phí không thực hiện kiểm soát phiên bản:

Trường hợp tốt nhất - ngày bị mất do chỉnh sửa bị mất, ghi đè thay đổi lẫn nhau, v.v., lỗi lặp lại, v.v.
Trường hợp xấu nhất - tuy nhiên nhiều năm nỗ lực của nhóm bạn đã dành cho đến nay.

Hình sau này là trường hợp xấu nhất về việc bạn mất tất cả công việc do lỗi máy chủ, v.v. nhưng ngay cả các tình huống "trường hợp tốt nhất" cũng sẽ mang lại cho họ lý do tại sao cần thiết. Chi phí cho các lỗi định kỳ có thể lớn hơn vì nó có thể dẫn đến mất khách hàng.

Nhóm phát triển cũng nên hiểu các chi phí này và cho rằng phần lớn (nếu không phải tất cả) phần mềm kiểm soát phiên bản tích hợp hoàn hảo với IDE ngày nay họ thậm chí sẽ không nhận thấy nó ở đó hầu hết thời gian.

Quản lý thường quan tâm nhất về tiết kiệm tiền. Nhấn mạnh cách kiểm soát phiên bản có thể mang lại lợi ích về mặt tài chính cho đội và bạn sẽ nhận được sự chú ý của họ ngay lập tức!

Có một khía cạnh mà những người khác ở đây chưa từng chạm đến là tôi nghĩ rằng bạn đã ở trong góc của mình - bạn đang nói về kiểm soát phiên bản phân tán - bởi bản chất của nó, bạn có thể lén lút thực hành, một nhà phát triển tại một thời điểm. Với một điều khiển phiên bản ngột ngạt hơn, giống như những gì chúng tôi sử dụng trong văn phòng của tôi (MS Visual SourceSafe), bạn sẽ gặp khó khăn khi gặp anh chàng trong khối đối diện với tôi và bán anh ta, từng người một kiểm soát phiên bản. Tuy nhiên, với (bất kỳ) DVCS, bạn chỉ cần nói "này, thử cái này và xem bạn có thích nó không. Tôi sẽ chỉ cho bạn những sợi dây, và tôi rất vui lòng trả lời bất kỳ câu hỏi nào, dẫn bạn đi qua, blah blah blah ". Bằng cách đó, bạn không cần một "quy trình" từ trên cao, bạn có thể xây dựng một nhiệm vụ cơ sở, mỗi người một người.

Dựa trên câu trả lời của gbjbaanb.

Điều quan trọng ở đây là bạn nên điều chỉnh quy trình kiểm soát phiên bản với bất kỳ quy trình hiện có nào tồn tại và chỉ ra cách nó tiết kiệm phần còn lại của nỗ lực nhóm.

Cá nhân tôi cũng thích Mercurial nhưng tôi không nhất thiết muốn sử dụng nó cho những người không quen kiểm soát phiên bản vì nó khó hiểu hơn một chút so với hệ thống kiểm soát phiên bản khóa dựa trên máy chủ cũ. Điều đó nói rằng nếu đó là một trang web greenfields thực sự, tốt nhất nên đi toàn bộ con lợn, bỏ qua những năm 80 và 90 và đi với Mercurial. Tôi cũng sẽ xem xét một số nội dung trong vòng đời phần mềm của bên thứ 3 được xây dựng xung quanh Mercurial - Tôi chắc chắn có một cái tên nhưng tên của nó thoát khỏi tôi;)

Tôi đoán rằng bạn làm việc cho một công ty nhỏ & bạn còn khá mới với nhóm nên có thể là một người khó bán - đặc biệt là nếu phần còn lại của nhóm cố thủ và có sự tin tưởng của ban quản lý. Có thể là tốt nhất để cho họ nhét thứ gì đó xấu lên sau đó đến giải cứu. Điều đó không có nghĩa là phá hoại, chỉ chờ đợi điều không thể tránh khỏi.