Nhà phát triển nên đợi đường ống CI hoàn thành hoặc bắt đầu tác vụ tiếp theo sau khi đẩy

Công ty của tôi đang tích hợp CI / CD, cho đến nay chúng tôi đã triển khai CI từ những gì tôi hiểu. Hiện tại khi một nhà phát triển đẩy mã đến repo git của chúng tôi, đường ống CI chạy.

Hiện tại đường ống CI của chúng tôi bao gồm xây dựng dự án và phân tích mã tĩnh để đảm bảo nó đáp ứng các tiêu chuẩn mã hóa của chúng tôi. Chúng tôi sẽ thực hiện thử nghiệm tiếp theo. Việc xây dựng và phân tích mã tĩnh mất khoảng 3 phút ngay bây giờ. Từ những gì tôi đã đọc các vấn đề sửa chữa ngay lập tức rất quan trọng đối với CI / CD. Tôi hy vọng khi chúng tôi thêm vào các bài kiểm tra đơn vị rằng đường ống có thể mất khoảng 10 phút để chạy.

Vì vậy, câu hỏi của tôi là khi nhà phát triển thực hiện yêu cầu kéo / hợp nhất, họ có nên đợi đường ống CI hoàn thành hay chỉ chuyển sang nhiệm vụ tiếp theo và quay lại để khắc phục sự cố đường ống nếu chúng tồn tại? Hay họ nên ngồi và xem đường ống chạy?

Ngồi và xem đường ống chạy?

Không, đó không phải là cách bạn làm việc hiệu quả.

Các nhà phát triển đẩy các cam kết của họ vào kho lưu trữ kiểm soát nguồn và sau đó đường ống CI / CD được kích hoạt.

Các nhà phát triển có thể đăng một yêu cầu kéo được viết tốt bất cứ lúc nào họ muốn. Thường có một dấu hiệu trực quan đại diện cho "bản dựng đang thực hiện" / "bản dựng không thành công" / "bản dựng thành công".

Thông thường, một brach có thể được hợp nhất bất cứ khi nào tất cả các tiêu chí này được đáp ứng:

• ít nhất một người phê duyệt / hoặc nhiều người được yêu cầu phê duyệt đã phê duyệt.
• một "bản dựng thành công"
• không có xung đột hợp nhất chưa được giải quyết

Nếu bất kỳ tiêu chí nào trong số những tiêu chí này không được đáp ứng, chúng cần được sửa, nhưng nhà phát triển thực hiện nó bất cứ khi nào anh ta có thời gian hoặc ưu tiên để thực hiện nhiệm vụ này.

Tôi khuyên bạn nên cố gắng hết sức để đảm bảo đường ống ít hơn 10 phút. Bạn có thể thực hiện các bài kiểm tra của mình song song để cho phép điều này. Khi jonas trả lời, sau đó họ có thể dành thời gian tạo yêu cầu kéo (trong khi đường ống đang chạy).

Chuyển đổi bối cảnh có hại cho năng suất vì vậy thay vì chọn một nhiệm vụ khác, tôi khuyên nhà phát triển nên sử dụng thời gian đó để làm bất cứ điều gì khác liên quan đến thay đổi mà anh ta đã thực hiện. Có lẽ có một số tài liệu có thể được cập nhật liên quan đến điều này. Nếu đó là một tính năng đáng chú ý, anh ta có thể tạo một gif ngắn cho biết cách làm việc với nó. Ngay cả việc nhìn vào mã của họ thay đổi một lần nữa có thể giúp họ nghĩ làm thế nào họ có thể cải thiện nó vào lần tới. Thời gian này cũng có thể được sử dụng để xem xét các nhà phát triển khác yêu cầu kéo và thay đổi mã.

Nếu họ chuyển sang phát triển một tính năng khác trong 10 phút đó thì có khả năng nó sẽ dài hơn 10 phút trước khi họ quay lại với nó và công việc sẽ trở nên kém mới mẻ trong tâm trí họ. Nếu CI thất bại, họ sẽ khó nhớ những gì có thể đã sai và sửa mã.

Ok, giả sử bạn có công cụ kiểm soát phiên bản như công cụ Git và CI Jenkins. Vì vậy, Dev tạo ra một nhánh tính năng cho một vấn đề. Bạn có một đường ống đa chức năng hoặc một quy trình công việc trong công cụ CI của bạn để phát hiện nhánh tính năng này trong lần quét tiếp theo và thực hiện các bước CI.

Vì vậy, những điều phải được đảm bảo là:

1. Trước khi tăng PR / MR, công việc CI có màu xanh. Nếu nó không có màu xanh, PR / MR không nên được nâng lên. Rõ ràng là nhà phát triển có thể thực hiện các nhiệm vụ khác và sau đó quay lại và khắc phục sự cố về nhiệm vụ này, đó là lựa chọn của họ tùy thuộc vào mức độ ưu tiên của nhiệm vụ. Bạn thậm chí có thể kiểm soát bất kỳ PR nào được nâng lên bằng cách kiểm tra các tham số CI của nó (Nếu bạn không tin tưởng nhà phát triển của mình nhiều và họ liên tục tăng PR cho các bản dựng bị hỏng)

2. Khi PR được nâng lên, người đánh giá mã sẽ xem xét và hợp nhất nếu mọi thứ đều ổn. Người đánh giá mã có thể là bất kỳ nhà phát triển khác. Trách nhiệm của anh ấy / cô ấy là xem xét mã, xem nó có nằm trong tiêu chí "Định nghĩa hoàn thành" hay không. DoD chủ yếu là một thuật ngữ nhanh nhẹn nhưng nhanh nhẹn và DevOps song hành với nhau.

3. Khi mã được hợp nhất, CI cho nhánh chính sẽ có màu xanh. Nếu không, mã phải được khôi phục và vấn đề cần được khắc phục vì nhìn chung nhánh chính cũng được triển khai vào các môi trường và không quay ngược lại có nghĩa là toàn bộ môi trường sẽ bị phá vỡ.

Rõ ràng, các hành động xây dựng bài đăng sẽ thông báo cho người đi làm rằng Hey, bạn đã phá vỡ bản dựng, vì vậy Devs có thể thực hiện các nhiệm vụ khác của mình, dù sao họ cũng sẽ nhận được email.