2010-02-22 98 views
14

Một nhóm các nhà phát triển mà tôi đang làm việc với việc chuyển từ VSS sang SVN khoảng nửa năm trước. Việc chuyển đổi từ CheckOut-CheckIn sang Update-Commit đã gây khó khăn cho một số người dùng. Bây giờ họ không còn bị buộc phải kiểm tra tệp của họ khi chúng được thực hiện (hoặc chính xác hơn, bây giờ không ai khác có thể thấy rằng họ đã kiểm tra tệp và yêu cầu họ kiểm tra lại để giải phóng khóa trên tập tin), nó đã xảy ra trên nhiều hơn một lần mà người dùng đã quên cam kết thay đổi của họ cho đến khi chúng được hoàn thành.Làm thế nào để khuyến khích các cam kết thường xuyên hơn cho SVN

Mặc dù hầu hết người dùng đều giỏi về Cam kết thay đổi của họ, nhưng vấn đề là đủ nghiêm trọng để đưa ra quyết định buộc người dùng phải get locks on all files in SVN before editing. Tôi thà không thấy điều này xảy ra, nhưng tôi đang thua lỗ về cách cải thiện tình hình theo một cách khác. Vì vậy, bất cứ ai có thể gợi ý cách để làm bất cứ điều nào sau đây:

  1. Theo dõi những gì người dùng file đã chỉnh sửa nhưng không có thay đổi chưa cam kết cho
  2. Khuyến khích người dùng để phù hợp hơn với Cam kết thay đổi khi chúng được thực hiện
  3. giúp kết thúc ra khỏi giáo dục người sử dụng cần thiết để mọi người quen với điều khiển phiên bản mới mô

Out-of-the-box giải pháp chào mừng (ví dụ: chương trình máy tính để bàn mà nhắc nhở người dùng cam kết nếu họ chưa don e như vậy trong một khoảng thời gian nhất định, tự động nhận được số liệu thống kê của người dùng tỷ lệ cam kết và gửi email cảnh báo nếu tần số giảm xuống dưới một ngưỡng nhất định, vv).

+4

checkin hoặc chúng ta sẽ thấy các nhà phát triển, những người sẽ checkin để thay thế bạn luôn luôn làm việc –

Trả lời

14

... người dùng đã quên cam kết thay đổi của họ cho đến khi chúng được hoàn thành.

Tôi nghĩ đây là vấn đề ngay tại đây. Làm thế nào một tính năng/sửa lỗi có thể được "hoàn thành" nếu nó không được đăng ký? Bạn có một hệ thống theo dõi vấn đề ghi lại các vấn đề nổi bật không? Bạn có một hệ thống tích hợp liên tục chạy thử nghiệm đơn vị ngay sau khi kiểm tra được thực hiện?

Nếu nhà phát triển chỉ làm việc riêng của mình mà không có trách nhiệm, thì không có gì ngạc nhiên khi bạn gặp phải vấn đề khiến mọi người hợp tác. Bạn sẽ cần một số loại giám sát (người quản lý dự án? Đội trưởng?), Người chịu trách nhiệm đảm bảo rằng các nhà phát triển cá nhân đang hợp tác với phần còn lại của nhóm phát triển.

+0

Thật không may, kiểm tra đơn vị và tích hợp liên tục vẫn đang trong giai đoạn đầu của việc áp dụng. Và ngay cả với các bài kiểm tra đơn vị, nếu người dùng quên Cam kết các bài kiểm tra đơn vị của họ cho dự án thử nghiệm, thì các bài kiểm tra vẫn có thể vượt qua với họ để quên Cam kết. –

+0

Nghiêm túc, đây là điều mà người quản lý phát triển/khách hàng tiềm năng cần phải giải quyết và thực thi. –

+1

@Yaakov Ellis, Làm thế nào về việc không có cùng một người viết mã và kiểm tra đơn vị? – Abizern

0

Đọc nhật ký cam kết và hỏi mọi người về trạng thái của họ và thời điểm họ sẽ kiểm tra các thay đổi của họ. Cam kết toàn bộ phần là tốt hơn so với cam kết như thể nó là một cách để 'cứu'.

Làm cách nào nhà phát triển có thể hoàn thành nội dung nào đó và quên kiểm tra? Quy trình phân phối sao cho người dùng chạy một bản dựng từ máy của chính nhà phát triển?

+0

Reading nhật ký cam kết hoạt động theo lý thuyết, nhưng khó thực hiện thủ công. Một số loại phương pháp tự động sẽ được ưu tiên.Quá trình giao hàng có thể liên quan đến người dùng thứ ba Cập nhật từ SVN và sau đó tải lên các thay đổi. Thật không may, vẫn còn một cách để đi với Unit Testing, vì vậy không có cách nào để tự động kiểm tra tất cả các thay đổi đã được bao gồm (và thậm chí nếu có, cùng một vấn đề quên để Commit bài kiểm tra đơn vị mới sẽ tồn tại là tốt). –

6

Bạn có sử dụng bất kỳ loại phần mềm theo dõi lỗi/tính năng nào không?
Bạn có thể yêu cầu họ bao gồm số sửa đổi khi họ đánh dấu vào công việc đã hoàn thành.

+0

Sử dụng FogBugz để theo dõi lỗi và phần mềm tự trồng để theo dõi tác vụ trên các dự án mới. –

+0

+1 và cũng định cấu hình trình theo dõi lỗi để yêu cầu một số QA, ví dụ: đánh giá mã hoặc đánh giá kiểm tra. Đó là một ý tưởng tốt anyway và nó chắc chắn buộc mọi người phải cam kết! – MarkJ

5

Tôi nghĩ rằng vấn đề bạn có thực sự là thiếu một hệ thống xây dựng contigous combinet với một theo dõi lỗi/tính năng/thay đổi. Với hệ thống theo dõi lỗi và xây dựng liên tục, nhà phát triển có thể yêu cầu 'hoàn thành' chỉ sau khi các thay đổi của anh ấy được thực hiện cho bản dựng tự động và bản phát hành chứa các thay đổi được xây dựng, vượt qua các kiểm tra xác thực xây dựng và được thả vào vị trí thả thả. Vì cách duy nhất để thay đổi 'thực hiện' nó thành một bản dựng là để kiểm tra (có thể đảo ngược tích hợp nhánh tính năng vào nhánh/thân chính), các dev sẽ phải kiểm tra, nếu không chúng sẽ không bao giờ kết thúc bất cứ thứ gì .

2

Trong một nhóm phát triển nhỏ, tôi đã nhìn thấy một email hàng ngày được gửi đến nhóm 'danh sách gửi thư hiển thị tóm tắt các đăng ký từ ngày trước đó và' cuộc đua ngựa 'không chính thức hiển thị số lượng đăng ký, tổng số dòng, v.v. trong vòng 30 ngày qua sẽ hữu ích. Rõ ràng bạn không thể sử dụng số lượng đăng ký như bất kỳ loại chỉ số hiệu suất nào, nhưng nó vẫn vui vẻ và giữ quyền kiểm soát nguồn trên tâm trí mọi người. "Này, Joe vừa mới đưa tôi vào tháng này, chờ đã, tôi chưa bao giờ kiểm tra mã đó hôm qua".

Điều này cũng có những lợi thế khác khi mọi người đến vào buổi sáng và đọc nó trên cofee của họ hoặc bất cứ điều gì nó giữ những gì người khác đang làm trong tâm trí nhà phát triển. Khi chúng tôi nhận được 'đóng băng mã' và sắp phát hành, chúng tôi thực sự thay đổi email chỉ từ một bản tóm tắt checkin, để bao gồm 'diffs' thực tế để mỗi dòng mã được nhiều mắt ngay lập tức.

+0

Bạn có biết bất kỳ công cụ tự động nào có thể tạo email như vậy không? –

+0

Xin lỗi, tôi tin rằng một trong những nhà phát triển của chúng tôi đã viết kịch bản email của chúng tôi một đêm để giải trí và nó vừa mới bắt đầu. – bdk

+0

Nếu nhà phát triển bỏ qua kiểm soát nguồn, nhà phát triển đó cũng có khả năng bỏ qua thông điệp email hàng ngày không? –

1

Thông thường, điều khuyến khích các nhà phát triển cam kết thường xuyên là tự bảo quản. Khi cập nhật trở nên khó khăn đối với họ vì xung đột hợp nhất và họ phát hiện ra rằng vấn đề được giảm bớt bằng cách đẩy các thay đổi của họ, họ sẽ cam kết thường xuyên hơn.

Nghe có vẻ như có điều gì đó sai về cơ bản. Nhà phát triển của bạn nhận được những thay đổi của họ như thế nào trong sản phẩm được phát hành mà không phải trải qua VCS? Bạn nên đóng cửa sau.

+1

"Nhà phát triển của bạn nhận được những thay đổi của họ như thế nào trong sản phẩm được phát hành mà không phải trải qua VCS" - Đó là vấn đề. Trong một số ít trường hợp mã đã không được phát hành khi nó cần phải có được. Tôi đang cố gắng tìm ra cách để đóng cửa sau đó ngay bây giờ. –

6

Nếu bạn sử dụng VSS trước đây, bạn có thể làm việc trong Visual Studio. AnkhSVN có cửa sổ thay đổi đang chờ xử lý, chẳng hạn như cửa sổ trong TFS và VSS. Toolwindow này tự động hiển thị những tập tin được sửa đổi cục bộ trong giải pháp của bạn.

Sử dụng cửa sổ thay đổi đang chờ xử lý này cho các thay đổi của bạn giúp dễ dàng thực hiện các thay đổi nhỏ/hợp lý và cam kết những thay đổi đó sớm thay vì sau này.

[Xem ảnh chụp màn hình này của một phiên bản AnkhSVN cũ]

+0

Tương tự như vậy, trong Eclipse, các tệp có các thay đổi cục bộ được đánh dấu trong Package Explorer với một biểu tượng nhỏ cho biết trạng thái của tệp đó là wrvn svn. (xi lanh vàng = không có thay đổi cục bộ kể từ lần cập nhật cuối cùng, sao màu nâu = sửa đổi, màu xanh dương '+' = được thêm vào, v.v.). Nếu bạn có cái nhìn đó mở ra mọi lúc, bạn quen với việc nhìn thấy nó và tất cả các xi-lanh vàng có nghĩa là "Mọi thứ tôi đã làm đều đã được cam kết". – MatrixFrog

4

Nhận một máy tự động xây dựng (hoặc ở một người chuyên Ít nhất làm xây dựng), và chỉ triển khai từ máy đó. Sau đó, mã của bạn không được triển khai cho đến khi bạn cam kết, và nó giúp đảm bảo rằng không có gì bị bỏ sót khỏi kho lưu trữ.

Ngoài ra, có ít nhất một vài thành viên của nhóm cam kết sớm và thường khuyến khích những người khác theo kịp, vì người bắt đầu chậm phải đối phó với nhiều xung đột hợp nhất địa phương hơn.

0

Trình theo dõi lỗi/tính năng phong nha sẽ cho phép bạn thêm số lỗi khi bạn cam kết thay đổi của mình. Ví dụ, nếu tôi đang chạy Redmine, tôi có thể cam kết với "Fixes # 323" ở đâu đó trong thông báo cam kết lật đổ của tôi và nó sẽ tự động đóng lỗi/tác vụ 323. Thiết lập của nó rất dễ dàng; bạn chỉ cần nói với Redmine nơi kho lưu trữ được yêu cầu.

Bằng cách này bạn có thể thấy những thay đổi nào đã được thực hiện đối với từng lỗi và các lỗi không có cam kết sẽ được mở (trừ khi đóng thủ công). Bạn có thể gán lỗi cho các cột mốc quan trọng và trước khi phát hành mốc quan trọng, hãy xem xét các cam kết chống lại lỗi này.

Trac cũng thực hiện việc này cũng như nhiều thứ khác.

+0

Vấn đề ở đây không liên quan nhiều đến Cam kết với các nhiệm vụ. Nó là để đảm bảo rằng mọi người đang cam kết tất cả mọi thứ. –

+1

Tôi nghĩ ý tưởng là bạn nói "Bạn đã sửa lỗi đó chưa?" và nếu nhà phát triển nói "Vâng nhưng tôi chưa cam kết" thì nó được coi là "chưa được sửa" " – MatrixFrog

+0

Hiệp hội được thiết kế để đảm bảo mọi người cam kết mọi thứ. Ý tưởng được rằng nếu bạn lấy một nhiệm vụ từ một trang web, cách dễ nhất để nói rằng nhiệm vụ được thực hiện là thêm "Fixes # 323" vào nhận xét cam kết, loại bảo đảm có một cam kết. –

1

Tự động xây dựng và triển khai của bạn, và làm cho nó là một phần của quá trình đó không có gì là "thực hiện" cho đến khi nó được thử nghiệm trên máy chủ thử nghiệm