Khi nào cần đánh giá mã khi thực hiện tích hợp liên tục?

Chúng tôi đang cố gắng chuyển sang môi trường tích hợp liên tục nhưng không chắc chắn khi nào cần thực hiện đánh giá mã. Từ những gì tôi đã đọc về tích hợp liên tục, chúng ta nên cố gắng kiểm tra mã thường xuyên nhiều lần trong ngày. Tôi giả sử, điều này thậm chí có nghĩa là cho các tính năng chưa hoàn thành.

Vì vậy, câu hỏi là, khi nào chúng ta thực hiện đánh giá mã?

Chúng tôi không thể làm điều đó trước khi chúng tôi kiểm tra mã, vì điều đó sẽ làm chậm quá trình chúng tôi sẽ không thể thực hiện đăng ký hàng ngày, chứ đừng nói đến nhiều lần đăng ký mỗi ngày.

Ngoài ra, nếu mã chúng tôi đang kiểm tra chỉ biên dịch nhưng không hoàn thành tính năng, thì việc đánh giá mã là vô nghĩa, vì hầu hết các đánh giá mã được thực hiện tốt nhất khi tính năng được hoàn tất. Điều này có nghĩa là chúng ta nên thực hiện đánh giá mã khi một tính năng được hoàn thành, nhưng mã chưa được xem xét đó sẽ được đưa vào kho lưu trữ?

IMO, bạn nên xem lại mã trước khi nó được xuất bản thành dòng chính để dòng chính chỉ có mã chất lượng cao nhất.

OTOH, một điểm tốt có thể được đưa ra là 'tại sao phải xem xét lại nếu tự động hóa thử nghiệm CI không chạy trên nó?', Vì vậy có lẽ tốt nhất là cung cấp cho các nhà phát triển mỗi nhánh riêng mà máy chủ CI sẽ xây dựng và thử nghiệm cho họ . Bằng cách đó, trước tiên họ cam kết và đẩy tới đó, sau đó một khi nó vượt qua được xem xét, sau đó hợp nhất vào tuyến chính (nơi nó sẽ chạy một lần nữa qua máy chủ CI).

Bạn chắc chắn nên xem lại mã không đầy đủ tính năng để đảm bảo rằng giàn giáo cho các tính năng trong tương lai được đặt ra, hoặc ít nhất là không có gì được đưa vào để ngăn các tính năng trong tương lai được triển khai.

Ngoài ra, lưu ý rằng các đánh giá mã không cần phải chậm hoặc đồng bộ - một công cụ như gerrit hoặc bảng đánh giá hoặc tương tự có thể làm cho chúng không đồng bộ và khá đau.

(Tiết lộ đầy đủ: Tôi đã từng làm việc cho SmartBear, nhà sản xuất Code Collaborator, một công cụ đánh giá mã)

Thiết lập lập trình cặp?

Tất cả các mã được xem xét vì nó đang được gõ mà không mở rộng quy trình hoặc giới thiệu một bước khác.

Đây là trích xuất từ ​​tác giả giao hàng liên tục:

Jez Humble viết như:

Tôi hiện đang viết một bài blog về chủ đề này. Câu trả lời ngắn gọn là đây:

• Cách tốt nhất để xem lại mã là thông qua lập trình cặp
• Thật là một ý tưởng tồi khi kết hợp cổng với đường chính - ví dụ, bằng cách tạo một nhánh riêng - trên một quy trình đánh giá chính thức. Điều này ức chế sự tích hợp liên tục (cách tốt nhất để giảm nguy cơ thay đổi xấu, đó là điều bạn đang thực sự hướng tới để đạt được).
• Tôi nghĩ Gerrit là một công cụ tuyệt vời, nhưng nó nên được sử dụng sau khi đăng ký (thực tế nó được thiết kế như thế nào). Một phần công việc của các nhà phát triển cao cấp là xem xét tất cả các đăng ký. Họ có thể, ví dụ, đăng ký một nguồn cấp dữ liệu.

Tóm lại: mã xem lại là tốt. Rất tốt, chúng ta nên thực hiện liên tục, thông qua lập trình cặp và xem xét các cam kết. Nếu một nhà phát triển cấp cao tìm thấy một cam kết xấu, cô ấy nên kết hợp với người đã cam kết để giúp họ khắc phục vấn đề.

Gating hợp nhất với dòng chính trên một đánh giá chính thức là xấu, và tạo các nhánh để làm như vậy là thêm xấu, vì lý do tương tự rằng các nhánh tính năng là xấu.

Cảm ơn,

Jez.

liên kết ban đầu là: https://groups.google.com/forum/#!msg/continuptdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

Tôi không biết liệu đó có phải là cách tốt nhất để làm điều đó không ... nhưng tôi sẽ giải thích cách chúng tôi làm điều đó. Một hoặc nhiều nhà phát triển làm việc trên một nhánh nhất định và cam kết mã của họ thường xuyên nhất có thể để tránh lãng phí thời gian vào việc hợp nhất sẽ không xảy ra nếu không. Chỉ khi mã sẵn sàng, nó được cam kết vào đầu. Bây giờ đó là cho các cam kết và chi nhánh / đầu điều.

Đối với đánh giá mã, chúng tôi sử dụng Sonar làm công cụ tích hợp liên tục của chúng tôi (và Maven / Jenkins để tương tác với Sonar) để cung cấp cho chúng tôi kết quả kiểm tra mới, bảo hiểm mã và xem xét mã tự động mỗi sáng (việc xây dựng được thực hiện hàng đêm) để chúng tôi các nhà phát triển có thể dành tối đa một giờ mỗi sáng để khắc phục sự cố / mùi mã của họ. Mỗi nhà phát triển chịu trách nhiệm (tự hào quá!) Cho tính năng mà anh ta đang viết. Bây giờ, đó là đánh giá mã tự động, rất tốt để tìm ra các vấn đề kỹ thuật / kiến ​​trúc tiềm năng, nhưng điều quan trọng hơn là kiểm tra xem các tính năng mới được triển khai này có đang làm những gì doanh nghiệp muốn chúng làm hay không.

Và để làm điều đó, có hai điều: kiểm tra tích hợp và đánh giá mã ngang hàng. Kiểm thử tích hợp giúp tự tin hợp lý rằng mã mới không phá vỡ mã hiện có. Đối với đánh giá mã ngang hàng, chúng tôi sẽ thực hiện vào các buổi chiều thứ sáu, đó là thời gian thoải mái hơn để làm điều đó :-) Mỗi ​​nhà phát triển được chỉ định cho một chi nhánh mà anh ta không làm việc, phải mất một thời gian để đọc các yêu cầu của tính năng mới đầu tiên, và sau đó kiểm tra những gì đã được thực hiện. Công việc quan trọng nhất của anh ta là đảm bảo rằng mã mới hoạt động như mong đợi được đưa ra các yêu cầu, không phá vỡ "quy tắc" của chúng ta (sử dụng đối tượng này cho điều đó, chứ không phải mã đó), dễ đọc và cho phép mở rộng dễ dàng.

Vì vậy, chúng tôi có hai đánh giá mã, một tự động và một "con người" và chúng tôi cố gắng tránh đưa mã chưa được xem xét vào nhánh CHÍNH. Bây giờ ... đôi khi điều đó xảy ra vì nhiều lý do, chúng ta không hoàn hảo, nhưng chúng tôi cố gắng giữ cân bằng hợp lý giữa chất lượng và chi phí (thời gian!)

@pjz cũng cung cấp một câu trả lời hay và anh ấy đề cập đến các công cụ đánh giá mã. Tôi đã từng sử dụng bất kỳ, vì vậy tôi không thể nói bất cứ điều gì về điều đó ... mặc dù trước đây tôi đã bị cám dỗ để làm việc với Crucible vì chúng tôi đã sử dụng JIRA .

Tôi nghĩ khái niệm chính sẽ giúp ích cho khu vực "Dàn dựng".

Có, bạn không muốn kiểm tra mã bị hỏng. Nhưng bạn cũng nên kiểm tra mã thường xuyên. Liệu điều này ngụ ý sự hoàn hảo? ;) Không. Chỉ cần sử dụng nhiều khu vực và DVCS như git.
Bằng cách này, bạn thực hiện các thay đổi (cục bộ) và cam kết chúng thường xuyên khi bạn kiểm tra và phát triển cho đến khi các bài kiểm tra vượt qua. Sau đó, bạn đẩy đến một khu vực để xem xét mã.

Sau đó, bạn nên chuyển từ Phân đoạn sang các nỗ lực QA khác như kiểm tra trình duyệt và kiểm tra người dùng. Cuối cùng bạn có thể đi đến một khu vực kiểm tra khối lượng, sau đó cuối cùng là sản xuất.

Ngoài ra còn có các quy trình công việc trong đó như mọi người làm việc trong chi nhánh chính hoặc sử dụng các chi nhánh riêng lẻ cho tất cả các nỗ lực.

Tích hợp liên tục chính nó cũng có thể xảy ra ở nhiều cấp độ. Nó có thể là cục bộ đối với máy của nhà phát triển 'cho đến khi các thử nghiệm vượt qua' và nó cũng có thể nằm trong khu vực tổ chức và qa khi mã đi đến chúng.

Xem lại mã decouple và tích hợp liên tục!

Tại sao bạn kết hợp chúng?

Chúng tôi sử dụng luồng git cho các kho lưu trữ của chúng tôi và chúng tôi thực hiện đánh giá mã của mình khi hợp nhất vào nhánh phát triển.

Bất cứ điều gì trong phát triển là hoàn thành, có thể triển khai và mã được xem xét.

Chúng tôi cũng có CI được thiết lập cho các chi nhánh phát triển và làm chủ của chúng tôi.

Tôi thực sự thực sự thực sự nghĩ rằng bạn sẽ cần một DVCS (ví dụ như đồng bóng, git) để làm điều này một cách tự nhiên. Với CVCS, bạn sẽ cần một chi nhánh và hy vọng bất cứ vị thần nào bạn có không có địa ngục hợp nhất.

Nếu bạn sử dụng DVCS, bạn có thể xếp lớp quy trình tích hợp để mã đã được xem xét trước khi đến máy chủ CI. Nếu bạn không có DVCS, mã sẽ đến máy chủ CI của bạn trước khi được xem xét trừ khi người đánh giá mã xem lại mã trên mỗi máy của nhà phát triển trước khi họ gửi thay đổi.

Cách đầu tiên để làm điều đó, đặc biệt nếu bạn không có phần mềm quản lý kho lưu trữ có thể giúp xuất bản các kho lưu trữ cá nhân (ví dụ: bitbucket, github, rhodecode), là có vai trò tích hợp phân cấp. Trong các sơ đồ sau, bạn có thể yêu cầu các trung úy xem xét công việc của các nhà phát triển và có nhà độc tài làm nhà tích hợp chính xem xét cách các trung úy sáp nhập công việc.

Một cách khác để làm điều đó nếu bạn có phần mềm quản lý kho lưu trữ, là sử dụng quy trình làm việc như sau:

Phần mềm quản lý kho lưu trữ thường giúp phát ra thông báo khi có hoạt động trong kho (ví dụ email, rss) cũng như cho phép yêu cầu kéo . Đánh giá mã có thể xảy ra một cách hữu cơ trong các yêu cầu kéo, vì các yêu cầu kéo thường khiến mọi người tham gia vào các cuộc hội thoại để tích hợp mã. Lấy yêu cầu kéo công khai này làm ví dụ. Trình quản lý tích hợp thực sự không thể cho phép mã đến kho lưu trữ may mắn (còn gọi là "kho lưu trữ trung tâm") nếu mã cần được sửa.

Quan trọng nhất, với DVCS bạn vẫn có thể hỗ trợ quy trình làm việc tập trung, bạn không cần phải có một quy trình công việc tuyệt vời khác nếu bạn không muốn ... nhưng với DVCS, bạn có thể tách kho lưu trữ phát triển trung tâm khỏi CI máy chủ và cung cấp cho ai đó quyền đẩy các thay đổi từ repo dev sang repo CI sau khi phiên đánh giá mã được thực hiện .

PS: Tín dụng cho hình ảnh đi đến git-scm.com

Tại sao không có nhiều hơn một kho lưu trữ? Một cho công việc "hàng ngày", lái máy chủ tích hợp liên tục, chạy tất cả các bài kiểm tra đơn vị & kiểm tra tích hợp để có được vòng phản hồi chặt chẽ và một cho công việc "ổn định", trong đó các cam kết ít thường xuyên hơn, nhưng phải qua kiểm tra.

Tùy thuộc vào đường dẫn thay đổi khi chúng di chuyển qua hệ thống, đây có thể là một giải pháp phức tạp và có thể hoạt động tốt nhất khi sử dụng các công cụ như Git hoặc Mercurial Queues, (báo trước: Tôi đã không sử dụng khi tức giận) nhưng rất nhiều tổ chức làm một cái gì đó tương tự.

Điều này có nghĩa là chúng ta nên thực hiện đánh giá mã khi một tính năng được hoàn thành, nhưng mã chưa được xem xét đó sẽ được đưa vào kho lưu trữ?

Vâng, trên đây là cách tôi đã thấy nó được thực hiện trong ít nhất ba dự án được sử dụng tích hợp liên tục và theo hồi ức của tôi, nó hoạt động như một cơ duyên. Thực tiễn này được gọi là đánh giá mã sau cam kết - tìm kiếm trên web cho cụm từ này nếu bạn quan tâm đến chi tiết.

• ^{Mặt khác, trường hợp duy nhất khi tôi tham gia dự án cố gắng "kết hôn" với các đánh giá mã cam kết trước với CI hóa ra khá đau đớn. Vâng, khi mọi thứ diễn ra suôn sẻ 100%, mọi chuyện vẫn ổn - nhưng ngay cả những gián đoạn không thường xuyên (như khi các nhà đánh giá chính và dự phòng đều không có mặt trong vài giờ) đã gây căng thẳng đáng chú ý. Tôi cũng nhận thấy rằng tinh thần đồng đội có phần bị ảnh hưởng - có quá nhiều xung đột.}

Đầu tiên, chúng ta nên làm rõ khái niệm "tích hợp liên tục". Trong các phương pháp phát triển truyền thống, tích hợp liên tục có nghĩa là chúng ta có thể tích hợp và xây dựng kho lưu trữ mã nguồn hàng ngày, điều này sẽ tránh được những cạm bẫy của "địa ngục tích hợp". Các đánh giá mã luôn nằm trong khoảng thời gian Kiểm tra mã hóa và Đơn vị. Chúng tôi phải đảm bảo mã hợp nhất để chi nhánh có thể biên dịch mà không có lỗi. Rất hiếm khi có các phần của tính năng hợp nhất với nhánh vì khó xử lý sự kết hợp của các lỗi giao diện và biên dịch.

Tích hợp liên tục là phổ biến trong quá trình lập trình cực đoan. Phát triển dựa trên thử nghiệm bổ sung lập trình Cặp, là một phần thực tế của quy trình xem xét mã, giúp tích hợp liên tục dễ thực hiện. Bản thân lập trình cực đoan là một quá trình xem xét và tích hợp mã liên tục. Các đánh giá mã tồn tại ở khắp mọi nơi.

Trong một số cộng đồng nguồn mở, các đánh giá mã được thực thi ngay trước khi mã hợp nhất với chi nhánh. Luôn luôn là những người có kinh nghiệm nhất trong nhóm này thực hiện đánh giá mã và quyết định xem mã có thể hợp nhất với nhánh chính hay không. Theo cách này, thời gian tích hợp liên tục dài hơn một chút nhưng chất lượng mã tốt hơn một chút.

Quay trở lại câu hỏi. Không có câu trả lời chuẩn cho thời điểm thực hiện đánh giá mã, và nó phụ thuộc vào quá trình phát triển ban đầu của bạn và việc triển khai thực tế tích hợp liên tục của bạn.