Tôi đang nghiên cứu một cách tiếp cận để hiểu rõ hơn cách thức quy trình tích hợp liên tục phù hợp hơn trong một công ty phát triển phần mềm với phương pháp scrum.
Tôi đang nghĩ một cái gì đó như thế này:
Đó sẽ là một quy trình công việc tốt đẹp?
Quy trình tốt để phát triển phần mềm với scrum và tích hợp liên tục
Câu trả lời:
Bạn đang ở đây, nhưng tôi sẽ mở rộng sơ đồ của bạn một chút:
Về cơ bản (nếu kiểm soát phiên bản của bạn sẽ cho phép nó, tức là nếu bạn đang sử dụng hg / git), bạn muốn mỗi cặp nhà phát triển / nhà phát triển có nhánh "cá nhân" của riêng họ, chứa một câu chuyện người dùng duy nhất họ đang làm việc. Khi họ hoàn thành tính năng, họ cần đẩy vào một nhánh trung tâm, nhánh "Phát hành". Tại thời điểm này, bạn muốn nhà phát triển có được một chi nhánh mới, cho việc tiếp theo họ cần làm việc. Nhánh tính năng ban đầu phải được giữ nguyên trạng, vì vậy mọi thay đổi cần được thực hiện đối với nó có thể được thực hiện riêng rẽ (điều này không phải lúc nào cũng có thể áp dụng, nhưng đó là điểm khởi đầu tốt). Trước khi một nhà phát triển trở lại làm việc trên một nhánh tính năng cũ, bạn nên kéo vào nhánh phát hành mới nhất, để tránh các vấn đề hợp nhất kỳ lạ.
Tại thời điểm này, chúng tôi đã có một ứng cử viên phát hành có thể dưới dạng chi nhánh "Phát hành" và chúng tôi đã sẵn sàng để chạy quy trình CI của chúng tôi (trên chi nhánh đó, rõ ràng bạn có thể làm điều này trên mỗi chi nhánh nhà phát triển, nhưng đây là khá hiếm trong các nhóm phát triển lớn hơn tại đó làm tắc nghẽn máy chủ CI). Đây có thể là một quá trình liên tục (đây là trường hợp lý tưởng, CI nên chạy bất cứ khi nào chi nhánh "Phát hành" được thay đổi) hoặc có thể là hàng đêm.
Tại thời điểm này, bạn sẽ muốn chạy một bản dựng và lấy một vật phẩm xây dựng khả thi từ máy chủ CI (nghĩa là thứ gì đó bạn có thể triển khai một cách khả thi). Bạn có thể bỏ qua bước này nếu bạn đang sử dụng ngôn ngữ động! Khi bạn đã được xây dựng, bạn sẽ muốn chạy Bài kiểm tra đơn vị của mình, vì chúng là nền tảng của tất cả các bài kiểm tra tự động trong hệ thống; họ có thể sẽ nhanh chóng (điều này tốt, vì toàn bộ quan điểm của CI là rút ngắn vòng phản hồi giữa phát triển và thử nghiệm) và họ không cần phải triển khai. Nếu chúng vượt qua, bạn sẽ muốn tự động triển khai ứng dụng của mình đến máy chủ thử nghiệm (nếu có thể) và chạy bất kỳ thử nghiệm tích hợp nào bạn có sẵn. Các thử nghiệm tích hợp có thể là các thử nghiệm UI tự động, thử nghiệm BDD hoặc thử nghiệm tích hợp tiêu chuẩn bằng cách sử dụng khung Kiểm tra đơn vị (nghĩa là "đơn vị"
Đến thời điểm này, bạn nên có một chỉ dẫn khá toàn diện về việc liệu bản dựng có khả thi hay không. Bước cuối cùng tôi thường thiết lập với nhánh "Phát hành" là để nó tự động triển khai ứng viên phát hành đến máy chủ thử nghiệm, vì vậy bộ phận QA của bạn có thể thực hiện các thử nghiệm khói thủ công (điều này thường được thực hiện hàng đêm thay vì mỗi lần kiểm tra để tránh làm hỏng một chu kỳ kiểm tra). Điều này chỉ đưa ra một dấu hiệu nhanh chóng của con người về việc bản dựng có thực sự phù hợp để phát hành trực tiếp hay không, vì nó khá dễ bỏ sót nếu gói thử nghiệm của bạn không toàn diện và thậm chí với độ bao phủ thử nghiệm 100%, bạn có thể dễ dàng bỏ lỡ thứ gì đó mà bạn có thể 't (không nên) tự động kiểm tra (chẳng hạn như hình ảnh được căn chỉnh sai hoặc lỗi chính tả).
Đây thực sự là sự kết hợp giữa Tích hợp liên tục và Triển khai liên tục, nhưng cho rằng trọng tâm của Agile là mã hóa tinh gọn và thử nghiệm tự động như một quy trình hạng nhất, bạn muốn hướng tới một cách tiếp cận toàn diện nhất có thể.
Quá trình tôi đã vạch ra là một kịch bản trường hợp lý tưởng, có nhiều lý do khiến bạn có thể từ bỏ các phần của nó (ví dụ: các nhánh nhà phát triển đơn giản là không khả thi trong SVN), nhưng bạn muốn nhắm đến nó càng nhiều càng tốt .
Về cách chu trình chạy nước rút Scrum phù hợp với điều này, lý tưởng nhất là bạn muốn các bản phát hành của mình diễn ra thường xuyên nhất có thể và không để chúng cho đến khi kết thúc nước rút, như nhận được phản hồi nhanh về việc liệu một tính năng (và xây dựng toàn bộ ) khả thi cho việc chuyển sang sản xuất là một kỹ thuật chính để rút ngắn vòng phản hồi của bạn cho Chủ sở hữu sản phẩm của bạn.
1
Tôi đồng ý với rất nhiều điều bạn nói, nhưng tôi (cá nhân) sẽ cố gắng khuyến khích mọi người cùng làm trong bất cứ khi nào có thể.
—
William Payne
@WilliamPayne Thực tế, nếu bạn đang sử dụng DVCS, mọi người sẽ không bao giờ ở cùng một chi nhánh (trừ khi họ thực sự làm việc trên cùng một máy), vì bạn "phân nhánh" mỗi khi bạn sao chép. "Nhánh" tương đương với những gì bạn có trong một VCS tiêu chuẩn là nhánh hợp nhất mà bạn sẽ có trên mỗi tính năng (vì vậy Dev B và Dev C có thể hoạt động trên các nhánh của Chi nhánh C sau đó đăng ký vào Chi nhánh C khi chúng được thực hiện, nếu cả hai đều làm việc trên tính năng C). Lợi ích của việc có nhiều chi nhánh là tốn ít thời gian hơn để khắc phục các sự cố hợp nhất, vì việc hợp nhất trong HG / Git gần như không gây đau đớn, nhưng cuộc đua đẩy / kéo thì không.
—
Ed James
Có nguy cơ biến điều này thành một cuộc chiến rực lửa, tôi tin rằng các vấn đề do xung đột hợp nhất thường được phóng đại (mặc dù tôi thừa nhận rằng chúng tồn tại). Hơn nữa, tôi tin rằng việc chuyển sang các công cụ DVCS (mặc dù được bảo đảm bởi các cân nhắc khác) không nên được biện minh hoàn toàn trên cơ sở tránh xung đột hợp nhất - Trong bất kỳ điều gì khác ngoài nỗ lực phát triển cộng đồng / mở, đây là những triệu chứng của giao tiếp và phối hợp kém trong nhóm phát triển. Chuyển sang DVCS chỉ che giấu một vấn đề sâu sắc và quan trọng hơn với giao tiếp nhóm.
—
William Payne
Tôi vẫn tin tưởng mạnh mẽ vào sự cần thiết của một repo "hàng ngày" (thân cây) mà các nhà phát triển cam kết khi họ làm việc. Tích hợp công việc của bạn liên tục là những gì tích hợp liên tục, sau tất cả. Đối với tôi, phân nhánh là thứ được thực hiện như là phương sách cuối cùng - không phải vì nguy cơ xung đột hợp nhất, mà vì các nhà phát triển lỏng lẻo theo dõi những gì người kia đang làm và bắt đầu làm việc trong silo. Đó là về tinh thần đồng đội, giao tiếp và con người, không phải là những hạn chế của các công cụ mà chúng tôi sử dụng. Để thực hiện tích hợp liên tục, bạn cần liên lạc liên tục, việc phân nhánh không hỗ trợ.
—
William Payne
@WilliamPayne Tôi sẽ không tranh luận về giá trị tương đối của DVCS so với VCS với bạn (ít nhất là không thông qua các bình luận), có những lợi ích đáng kể khi sử dụng DVCS nếu bạn có được quy trình làm việc phù hợp, trong khi với quy trình làm việc truyền thống hơn VCS sẽ làm một công việc sterling (theo kinh nghiệm của tôi). Tuy nhiên, tôi sẽ nói với bạn rằng kể từ khi chuyển sang DVCS, nhóm của tôi đã trải qua vòng quay phát triển nhanh hơn đáng kể và triển khai mạnh mẽ hơn. Địa ngục hợp nhất cuối dự án mà nhiều người vẫn trải nghiệm cho đến ngày nay đã gần như bị loại bỏ hoàn toàn khỏi quá trình phát triển của chúng tôi.
—
Ed James
Về mặt khái niệm thì có. Một sơ đồ không nắm bắt được nhiều điểm quan trọng mặc dù như:
- kiểm tra đơn vị
- cam kết gia tăng
- dàn dựng được triển khai thường xuyên, sản xuất thường không.
Bạn có thể muốn vẽ một hệ thống rộng hơn cho sơ đồ. Tôi sẽ xem xét thêm các yếu tố sau:
Hiển thị đầu vào của bạn cho hệ thống, được cung cấp cho các nhà phát triển. Gọi họ là yêu cầu, sửa lỗi, câu chuyện, hoặc bất cứ điều gì. Nhưng hiện tại quy trình làm việc của bạn giả định người xem biết cách chèn những đầu vào đó.
Hiển thị các điểm kiểm soát dọc theo quy trình làm việc. Ai / cái gì quyết định khi thay đổi được cho phép vào thân cây / chính / nhánh phát hành / vv ...? Những loại tiền mã hóa / dự án nào được xây dựng trên CIS? Có một điểm kiểm tra để xem nếu bản dựng bị hỏng? Ai phát hành từ CIS để dàn dựng / sản xuất?
Liên quan đến các điểm kiểm soát là xác định phương pháp phân nhánh của bạn là gì và làm thế nào nó phù hợp với quy trình công việc này.
Có đội thử không? Khi nào họ tham gia hoặc thông báo? Có kiểm tra tự động đang được thực hiện trên CIS? Làm thế nào là phá vỡ được đưa trở lại vào hệ thống?
Xem xét cách bạn sẽ ánh xạ luồng công việc này vào một sơ đồ truyền thống với các điểm quyết định và đầu vào. Bạn đã nắm bắt được tất cả các điểm tiếp xúc cấp cao cần thiết để mô tả đầy đủ quy trình làm việc của mình chưa?
Câu hỏi ban đầu của bạn là cố gắng so sánh, tôi nghĩ vậy, nhưng tôi không chắc chắn về khía cạnh nào bạn đang cố gắng so sánh. Tích hợp liên tục có các điểm quyết định giống như các mô hình SDLC khác, nhưng chúng có thể ở các điểm khác nhau trong quy trình.
Tôi sử dụng thuật ngữ "Tự động hóa phát triển" để bao gồm tất cả các hoạt động xây dựng, tạo tài liệu, kiểm tra, đo lường hiệu suất và triển khai tự động.
Do đó, một "máy chủ tự động hóa phát triển" có một khoản tiền tương tự, nhưng có phần rộng hơn so với một máy chủ tích hợp liên tục.
Tôi thích sử dụng các tập lệnh tự động hóa phát triển được điều khiển bởi các hook post-commit cho phép cả nhánh riêng và thân phát triển trung tâm được tự động hóa mà không yêu cầu cấu hình bổ sung trên máy chủ CI. (Điều này ngăn cấm việc sử dụng hầu hết các GUI máy chủ CI ngoài luồng mà tôi biết).
Kịch bản sau cam kết xác định hoạt động tự động hóa nào sẽ chạy dựa trên nội dung của chính chi nhánh; bằng cách đọc tệp cấu hình sau cam kết ở một vị trí cố định trong nhánh hoặc bằng cách phát hiện một từ cụ thể (tôi sử dụng / auto /) làm thành phần của đường dẫn đến nhánh trong kho lưu trữ (với Svn)).
(Điều này dễ cài đặt với Svn hơn Hg).
Cách tiếp cận này cho phép nhóm phát triển linh hoạt hơn về cách họ tổ chức quy trình công việc của họ, cho phép CI hỗ trợ phát triển trên các chi nhánh với chi phí quản trị tối thiểu (gần bằng 0).
Có một loạt bài viết hay về tích hợp liên tục trên asp.net mà bạn có thể thấy hữu ích, nó bao gồm khá nhiều nền tảng và quy trình công việc phù hợp với những gì bạn trông giống như sau khi làm.
Sơ đồ của bạn không đề cập đến công việc được thực hiện bởi máy chủ CI (kiểm tra đơn vị, độ bao phủ mã và các số liệu khác, kiểm tra tích hợp hoặc xây dựng hàng đêm), nhưng tôi cho rằng tất cả được bao phủ trong giai đoạn "Máy chủ tích hợp liên tục". Tôi không rõ tại sao hộp CI sẽ được đẩy trở lại kho lưu trữ trung tâm? Rõ ràng là nó cần lấy mã nhưng tại sao nó lại cần gửi lại?
CI là một trong những thực tiễn được đề xuất bởi các ngành khác nhau, nó không phải là duy nhất đối với scrum (hoặc XP) nhưng thực tế tôi sẽ nói rằng lợi ích của nó có sẵn cho bất kỳ dòng chảy nào ngay cả khi không nhanh nhẹn như thác nước (có thể là ướt-agile?) . Đối với tôi, lợi ích chính là vòng phản hồi chặt chẽ, bạn biết khá nhanh liệu mã bạn vừa cam kết có hoạt động với phần còn lại của cơ sở mã hay không. Nếu bạn đang làm việc trong giai đoạn nước rút và có các hoạt động độc lập hàng ngày thì có thể tham khảo trạng thái hoặc số liệu từ đêm qua được xây dựng trong máy chủ CI chắc chắn là một điểm cộng và giúp mọi người tập trung. Nếu chủ sở hữu sản phẩm của bạn có thể thấy trạng thái của bản dựng - một màn hình lớn trong khu vực được chia sẻ hiển thị trạng thái của các dự án xây dựng của bạn - thì bạn đã thực sự thắt chặt vòng lặp phản hồi đó. Nếu nhóm phát triển của bạn cam kết thường xuyên (hơn một lần một ngày và lý tưởng hơn một lần một giờ) thì khả năng bạn sẽ gặp phải vấn đề tích hợp mất nhiều thời gian để giải quyết, nhưng nếu họ làm rõ thì tất cả và bạn có thể thực hiện bất kỳ biện pháp nào bạn cần, mọi người dừng lại để đối phó với bản dựng bị hỏng chẳng hạn. Trong thực tế, có lẽ bạn sẽ không gặp phải nhiều bản dựng thất bại, mất hơn một vài phút để tìm hiểu xem bạn có tích hợp thường xuyên không.
Tùy thuộc vào tài nguyên / mạng của bạn, bạn có thể muốn xem xét thêm các máy chủ cuối khác nhau. Chúng tôi có một bản dựng CI được kích hoạt bởi một cam kết với repo và giả sử rằng bản dựng và vượt qua tất cả các thử nghiệm của nó sau đó nó được triển khai cho máy chủ phát triển để các nhà phát triển có thể đảm bảo rằng nó chơi độc đáo (bạn có thể bao gồm selenium hoặc các thử nghiệm UI khác ở đây không? ). Mặc dù vậy, không phải mọi cam kết đều là bản dựng ổn định, vì vậy, để kích hoạt bản dựng cho máy chủ dàn, chúng tôi phải gắn thẻ sửa đổi (chúng tôi sử dụng đồng bóng) mà chúng tôi muốn được xây dựng và triển khai, một lần nữa, tất cả đều được tự động hóa và được kích hoạt chỉ bằng cách cam kết với một cụ thể nhãn. Để đi đến sản xuất là một quá trình thủ công; bạn có thể để nó đơn giản như việc buộc một bản dựng lừa là biết bản sửa đổi / bản dựng nào bạn muốn sử dụng, nhưng nếu bạn gắn thẻ sửa đổi một cách thích hợp thì máy chủ CI có thể kiểm tra phiên bản chính xác và làm bất cứ điều gì cần thiết. Bạn có thể đang sử dụng MS Deployment để đồng bộ hóa các thay đổi với (các) máy chủ sản xuất hoặc để đóng gói và đặt zip ở nơi nào đó sẵn sàng để quản trị viên triển khai thủ công ... điều này phụ thuộc vào mức độ bạn cảm thấy thoải mái với điều đó.
Cũng như đi lên một phiên bản, bạn cũng nên xem xét cách bạn có thể đối phó với thất bại và đi xuống một phiên bản. Hy vọng điều đó sẽ không xảy ra nhưng có thể có một số thay đổi đối với máy chủ của bạn, điều đó có nghĩa là những gì hoạt động trên UAT không hoạt động trong sản xuất, vì vậy bạn phát hành phiên bản được phê duyệt của mình và nó thất bại ... bạn luôn có thể thực hiện phương pháp mà bạn xác định lỗi, thêm một số mã, cam kết, kiểm tra, triển khai vào sản xuất để sửa nó ... hoặc bạn có thể bọc một số thử nghiệm tiếp theo xung quanh bản phát hành tự động của bạn để sản xuất và nếu nó thất bại thì nó sẽ tự động quay trở lại.
CruiseControl.Net sử dụng xml để định cấu hình các bản dựng, TeamCity sử dụng trình hướng dẫn, nếu bạn muốn tránh các chuyên gia trong nhóm của mình thì sự phức tạp của các cấu hình xml có thể là điều cần lưu ý.
Đầu tiên, một cảnh báo: Scrum là một phương pháp khá nghiêm ngặt. Tôi đã làm việc cho một vài tổ chức đã cố gắng sử dụng Scrum hoặc các cách tiếp cận giống như Scrum nhưng cả hai đều không thực sự sử dụng toàn bộ kỷ luật. Từ kinh nghiệm của mình, tôi là một người đam mê Agile, nhưng là một người hoài nghi Scrum (miễn cưỡng).
Theo tôi hiểu, Scrum và các phương thức Agile khác có hai mục tiêu chính:
- Đầu tiên là cung cấp một cơ chế rõ ràng để quản lý rủi ro và phát hiện rủi ro liên tục.
- Thứ hai là cung cấp một cơ chế có cấu trúc để liên lạc với các bên liên quan, phát hiện yêu cầu và quản lý yêu cầu.
Mục tiêu đầu tiên (quản lý rủi ro) đạt được thông qua phát triển lặp lại; mắc lỗi và học bài học nhanh chóng, cho phép nhóm xây dựng sự hiểu biết và khả năng trí tuệ để giảm thiểu rủi ro và hướng tới một giải pháp giảm thiểu rủi ro với giải pháp "khắc khổ" có rủi ro thấp đã có trong túi.
Tự động hóa phát triển, bao gồm tích hợp liên tục, là yếu tố quan trọng nhất trong thành công của phương pháp này. Phát hiện rủi ro & Học bài học phải nhanh, không ma sát và không có các yếu tố xã hội gây nhiễu. (Mọi người học NHIỀU nhanh hơn khi đó là một cỗ máy nói với họ rằng họ sai chứ không phải là một con người khác - bản ngã chỉ có được trong cách học).
Như bạn có thể nói - tôi cũng là một fan hâm mộ của sự phát triển dựa trên thử nghiệm. :-)
Mục tiêu thứ hai ít liên quan đến tự động hóa phát triển và nhiều thứ khác liên quan đến Nhân tố con người. Khó thực hiện hơn vì nó đòi hỏi phải mua từ mặt trước của doanh nghiệp, những người không có khả năng nhìn thấy sự cần thiết cho hình thức.
Tự động hóa phát triển có thể có một vai trò ở đây, trong đó tài liệu được tạo tự động và báo cáo tiến độ có thể được sử dụng để giữ cho các bên liên quan bên ngoài nhóm phát triển được cập nhật liên tục với tiến trình và bộ tản nhiệt thông tin hiển thị trạng thái xây dựng và bộ kiểm tra chuyển / thất bại có thể được sử dụng để truyền đạt tiến trình về phát triển tính năng, giúp (hy vọng) hỗ trợ việc áp dụng quy trình truyền thông Scrum.
Vì vậy, tóm lại:
Sơ đồ mà bạn đã sử dụng để minh họa câu hỏi của mình chỉ nắm bắt một phần của quy trình. Nếu bạn muốn nghiên cứu nhanh / scrum và CI, tôi sẽ cho rằng điều quan trọng là phải xem xét các khía cạnh xã hội và con người rộng lớn hơn của quá trình.
Tôi phải kết thúc bằng cách đập cùng một cái trống mà tôi luôn làm. Nếu bạn đang cố gắng thực hiện một quy trình nhanh trong một dự án trong thế giới thực, dự đoán tốt nhất về cơ hội thành công của bạn là mức độ tự động hóa đã được triển khai; nó làm giảm ma sát, tăng vận tốc và mở đường đến thành công.