Sự khác biệt giữa ba điều khoản này là gì? Trường đại học của tôi cung cấp các định nghĩa sau:

Tích hợp liên tục về cơ bản chỉ có nghĩa là các bản sao làm việc của nhà phát triển được đồng bộ hóa với dòng chính được chia sẻ nhiều lần trong ngày.

Giao hàng liên tục được mô tả là sự phát triển hợp lý của tích hợp liên tục: Luôn có thể đưa sản phẩm vào sản xuất!

Triển khai liên tục được mô tả là bước tiếp theo hợp lý sau khi phân phối liên tục: Tự động triển khai sản phẩm vào sản xuất bất cứ khi nào nó vượt qua QA!

Họ cũng đưa ra một cảnh báo: Đôi khi thuật ngữ "Triển khai liên tục" cũng được sử dụng nếu bạn có thể liên tục triển khai vào hệ thống thử nghiệm.

Tất cả điều này làm tôi bối rối. Bất kỳ giải thích nào chi tiết hơn một chút (hoặc đi kèm với một ví dụ) đều được đánh giá cao!

Hội nhập liên tục

Tôi đồng ý với định nghĩa của trường đại học của bạn. Tích hợp liên tục là một chiến lược để làm thế nào một nhà phát triển có thể tích hợp mã vào dòng chính liên tục - trái ngược với thường xuyên.

Bạn có thể cho rằng đó chỉ là một chiến lược phân nhánh trong hệ thống kiểm soát phiên bản của bạn.

Nó phải làm với kích thước của các nhiệm vụ bạn giao cho nhà phát triển; Nếu một nhiệm vụ được ước tính mất 4-5 ngày, thì nhà phát triển sẽ không có ý định cung cấp bất cứ điều gì trong 4-5 ngày tới, bởi vì anh ta chưa hoàn thành bất cứ điều gì - chưa.

Vì vậy, vấn đề kích thước:

small task = continuous integration
big task   = frequent integration

Kích thước nhiệm vụ lý tưởng không lớn hơn một ngày làm việc. Bằng cách này, một nhà phát triển đương nhiên sẽ có ít nhất một tích hợp mỗi ngày.

Giao hàng liên tục

Về cơ bản có ba trường trong Giao hàng liên tục:

Giao hàng liên tục là sự mở rộng tự nhiên của Tích hợp liên tục

Ngôi trường này, nhìn vào loạt chữ ký của Addison-Wesley "Martin Fowler" và đưa ra giả định rằng kể từ khi phát hành năm 2007 được gọi là "Tích hợp liên tục" và phiên bản tiếp theo vào năm 2011 được gọi là "Giao hàng liên tục" , có lẽ chúng là tập 1 + 2 của cùng một ý tưởng khái niệm phải làm với một cái gì đó liên tục .

Giao hàng liên tục phải làm với Phát triển phần mềm Agile

Ngôi trường này lấy ý tưởng rằng Giao hàng liên tục là tất cả về khả năng hỗ trợ các nguyên tắc trong phong trào nhanh nhẹn, không chỉ là một ý tưởng khái niệm hay một lá thư về ý định mà còn trong thực tế - trong cuộc sống thực.

Lấy bù theo nguyên tắc đầu tiên trong Tuyên ngôn Agile trong đó thuật ngữ "giao hàng liên tục" thực sự được sử dụng lần đầu tiên:

Ưu tiên cao nhất của chúng tôi là làm hài lòng khách hàng thông qua việc cung cấp phần mềm có giá trị sớm và liên tục.

Trường này tuyên bố rằng "Giao hàng liên tục" là một mô hình bao gồm mọi thứ cần thiết để thực hiện xác minh tự động về "định nghĩa hoàn thành" của bạn .

Trường này chấp nhận rằng "Giao hàng liên tục" và từ buzz hay megatrend "DevOps" là mặt trái của cùng một đồng tiền, theo nghĩa là cả hai đều cố gắng nắm lấy hoặc gói gọn mô hình hoặc cách tiếp cận mới này chứ không chỉ là một kỹ thuật.

Giao hàng liên tục là từ đồng nghĩa với Triển khai liên tục

Trường thứ ba ủng hộ rằng Triển khai liên tục và phân phối liên tục có thể được sử dụng thay thế cho nhau để có nghĩa tương tự.

Khi một cái gì đó đã sẵn sàng trong tay các nhà phát triển, nó sẽ được gửi ngay cho người dùng cuối, điều này trong hầu hết các trường hợp sẽ có nghĩa là nó sẽ được triển khai vào môi trường sản xuất. Do đó "Triển khai" và "Giao hàng" có nghĩa giống nhau.

Học trường nào

Trường đại học của bạn rõ ràng đã gia nhập trường đầu tiên và tuyên bố rằng chúng tôi đang đề cập đến tập 1 + 2 của cùng một ấn phẩm. Ý kiến ​​của tôi là đây là một sự lạm dụng của thuật ngữ Giao hàng liên tục.

Cá nhân tôi ủng hộ cho sự hiểu biết rằng Giao hàng liên tục có liên quan đến việc thực hiện hỗ trợ thực tế cho các ý tưởng và khái niệm được nêu trong phong trào nhanh nhẹn. Vì vậy, tôi đã tham gia vào trường học nói rằng thuật ngữ này bao trùm cả một mô hình - như "DevOps".

Trường sử dụng phân phối như một từ đồng nghĩa để triển khai hầu hết được ủng hộ bởi các nhà cung cấp công cụ tạo ra các bảng điều khiển triển khai, cố gắng có được một chút cường điệu từ việc sử dụng rộng rãi hơn thuật ngữ Giao hàng liên tục .

Triển khai liên tục

Việc tập trung vào Triển khai liên tục chủ yếu có liên quan trong các lĩnh vực nơi người dùng cuối truy cập vào các bản cập nhật phần mềm phụ thuộc vào việc cập nhật một số nguồn tập trung cho thông tin này và ở đó nguồn tập trung này không phải lúc nào cũng dễ dàng cập nhật vì nó nguyên khối hoặc có (quá) kết hợp cao theo bản chất (web, SOA, cơ sở dữ liệu, v.v.).

Đối với nhiều miền sản xuất phần mềm không có nguồn thông tin tập trung (thiết bị, sản phẩm tiêu dùng, cài đặt máy khách, v.v.) hoặc nơi dễ dàng cập nhật nguồn thông tin (kho lưu trữ hệ thống quản lý nhân tạo, kho lưu trữ nguồn mở, v.v. ), hầu như không có sự cường điệu nào về thuật ngữ Triển khai liên tục cả. Họ chỉ triển khai; nó không phải là một vấn đề lớn - nó không phải là một nỗi đau đòi hỏi sự tập trung đặc biệt.

Thực tế là Triển khai liên tục không phải là điều gì đó thú vị chung cho mọi người cũng là một lập luận cho rằng trường tuyên bố rằng "giao hàng" và "triển khai" là những từ đồng nghĩa sai. Bởi vì Phân phối liên tục thực sự có ý nghĩa hoàn toàn tốt đối với mọi người - ngay cả khi bạn đang thực hiện phần mềm nhúng trong thiết bị hoặc phát hành plugin Nguồn mở cho khung.

Định nghĩa của trường đại học của bạn rằng Triển khai liên tục là một bước tiếp theo tự nhiên của Giao hàng liên tục mặc nhiên cho rằng mọi giao hàng được QA'ed nên cung cấp cho người dùng cuối ngay lập tức, gần với định nghĩa mà bộ lạc của tôi sử dụng để mô tả thuật ngữ "Continous Phát hành ", đến lượt nó, là một khái niệm khác không có ý nghĩa chung đối với mọi người.

Một bản phát hành có thể là một điều rất chiến lược hoặc chính trị và không có lý do gì để cho rằng mọi người đều muốn làm điều này mọi lúc (trừ khi họ là một cửa hàng sách trực tuyến thuộc loại dịch vụ phát trực tuyến của công ty). Tuy nhiên, các công ty không mù quáng phát hành mọi thứ mọi lúc có thể có bất kỳ lý do nào khiến họ muốn trở thành bậc thầy về triển khai, vì vậy họ cũng thực hiện Triển khai liên tục . Không phải phát hành vào sản xuất, mà là các ứng cử viên phát hành cho các môi trường giống như sản xuất .

Một lần nữa tôi tin rằng trường đại học của bạn đã nhận sai. Họ đang nhầm "Triển khai liên tục" cho "Phát hành liên tục".

Triển khai liên tục chỉ đơn giản là kỷ luật liên tục có thể chuyển kết quả của quá trình phát triển sang môi trường giống như sản xuất, nơi thử nghiệm chức năng có thể được thực hiện ở quy mô đầy đủ.

Cốt truyện giao hàng liên tục

Trong ảnh tất cả trở nên sống động:

Quá trình tích hợp liên tục là hai hành động đầu tiên trong sơ đồ chuyển trạng thái. mà - nếu thành công - sẽ khởi động đường ống phân phối liên tục thực hiện định nghĩa hoàn thành . Triển khai chỉ là một trong nhiều hành động sẽ phải được thực hiện liên tục trong đường ống này. Lý tưởng nhất là quy trình được tự động hóa từ điểm mà nhà phát triển cam kết với VCS đến điểm mà đường ống đã xác nhận rằng chúng tôi có một ứng cử viên phát hành hợp lệ.

Cả câu hỏi và câu trả lời đều không phù hợp với cách nghĩ đơn giản của tôi về nó. Tôi là một nhà tư vấn và đã đồng bộ hóa các định nghĩa này với một số nhóm Dev và người DevOps, nhưng tôi tò mò về cách nó phù hợp với ngành công nghiệp nói chung:

Về cơ bản, tôi nghĩ về việc thực hành nhanh nhẹn của việc giao hàng liên tục như một sự liên tục:

Không liên tục (mọi thứ thủ công) 0% ----> 100% phân phối giá trị liên tục (mọi thứ tự động)

Các bước để giao hàng liên tục:

Số không. Không có gì là tự động khi các nhà phát triển đăng ký mã ... Bạn thật may mắn nếu họ đã biên dịch, chạy hoặc thực hiện bất kỳ thử nghiệm nào trước khi đăng ký.

1. Xây dựng liên tục: xây dựng tự động trên mỗi lần đăng ký, đây là bước đầu tiên, nhưng không có gì để chứng minh sự tích hợp chức năng của mã mới.

2. Tích hợp liên tục (CI): xây dựng và thực hiện tự động ít nhất các thử nghiệm đơn vị để chứng minh tích hợp mã mới với mã hiện có, nhưng tốt nhất là thử nghiệm tích hợp (đầu cuối).

3. Triển khai liên tục (CD): triển khai tự động khi mã ít nhất chuyển CI vào môi trường thử nghiệm, tốt nhất là vào môi trường cao hơn khi chất lượng được chứng minh thông qua CI hoặc bằng cách đánh dấu môi trường thấp hơn là PASSED sau khi kiểm tra thủ công. IE, thử nghiệm có thể là thủ công trong một số trường hợp, nhưng việc quảng bá sang môi trường tiếp theo là tự động.

4. Giao hàng liên tục: xuất bản tự động và phát hành hệ thống vào sản xuất. Đây là CD được sản xuất cộng với bất kỳ thay đổi cấu hình nào khác như thiết lập để thử nghiệm A / B, thông báo cho người dùng các tính năng mới, thông báo hỗ trợ phiên bản mới và thay đổi ghi chú, v.v.

EDIT: Tôi muốn chỉ ra rằng có một sự khác biệt giữa khái niệm "giao hàng liên tục" như được tham chiếu trong nguyên tắc đầu tiên của Tuyên ngôn Agile ( http://agilemanifesto.org/principles.html ) và thực tiễn Giao hàng liên tục, dường như được tham chiếu bởi bối cảnh của câu hỏi. Nguyên tắc phân phối liên tục là phấn đấu để giảm chất thải Hàng tồn kho như được mô tả trong tư duy Lean ( http://www.miconleansixsigma.com/8-wastes.html ). Việc thực hành Giao hàng liên tục (CD) của các nhóm nhanh nhẹn đã xuất hiện trong nhiều năm kể từ khi Tuyên ngôn Agile được viết vào năm 2001. Thực hành nhanh nhẹn này trực tiếp giải quyết nguyên tắc, mặc dù chúng là những thứ khác nhau và dễ bị nhầm lẫn.

Tôi nghĩ định nghĩa amazon là đơn giản và dễ hiểu.

" Phân phối liên tục là một phương pháp phát triển phần mềm trong đó quy trình phát hành được tự động hóa. Mọi thay đổi phần mềm được tự động xây dựng, kiểm tra và triển khai vào sản xuất. Trước khi thúc đẩy sản xuất, một người, kiểm tra tự động hoặc quy tắc kinh doanh quyết định khi nào Sự thúc đẩy cuối cùng sẽ xảy ra. Mặc dù mọi thay đổi phần mềm thành công có thể được phát hành ngay lập tức vào sản xuất với việc phân phối liên tục, nhưng không phải tất cả các thay đổi cần phải được phát hành ngay lập tức.

Tích hợp liên tục là một thực tiễn phát triển phần mềm trong đó các thành viên của nhóm sử dụng hệ thống kiểm soát phiên bản và tích hợp công việc của họ thường xuyên vào cùng một vị trí, chẳng hạn như chi nhánh chính. Mỗi thay đổi được xây dựng và xác minh bằng các thử nghiệm và xác minh khác để phát hiện bất kỳ lỗi tích hợp nào nhanh nhất có thể. Tích hợp liên tục tập trung vào việc tự động xây dựng và kiểm tra mã, so với phân phối liên tục, tự động hóa toàn bộ quy trình phát hành phần mềm cho đến sản xuất . "

Vui lòng kiểm tra http://docs.aws.amazon.com/codepipeline/latest/userguide/con accept.html

Atlassian đăng một lời giải thích tốt về tích hợp liên tục so với phân phối liên tục so với triển khai liên tục .

Tóm lại:

Tích hợp liên tục - là một tự động hóa để xây dựng và thử nghiệm ứng dụng bất cứ khi nào các cam kết mới được đẩy vào chi nhánh.

Phân phối liên tục - là Tích hợp liên tục + Triển khai ứng dụng vào sản xuất bằng cách "nhấp vào nút" (Phát hành cho khách hàng thường xuyên, nhưng theo yêu cầu).

Triển khai liên tục - là Giao hàng liên tục nhưng không có sự can thiệp của con người (Phát hành cho khách hàng đang diễn ra).

Tích hợp liên tục về cơ bản chỉ có nghĩa là các bản sao làm việc của nhà phát triển được đồng bộ hóa với dòng chính được chia sẻ nhiều lần trong ngày.

Hoặc nhiều hơn vài lần mỗi ngày. Về cơ bản, bất kỳ nhiệm vụ riêng biệt nào được hoàn thành, về cơ bản. Ví dụ, xem xét một nhóm các nhà phát triển làm việc trên một ứng dụng kinh doanh. Trong nhiều môi trường, điều sau đây có thể xảy ra:

• Một hoặc hai nhà phát triển giữ các thay đổi cục bộ trong vài ngày vì "nó chưa sẵn sàng".
• Một hoặc hai nhà phát triển tạo các nhánh trong kiểm soát nguồn để họ có thể làm việc trên (các) tính năng của họ "mà không bị làm phiền bởi những thay đổi của người khác".

Những điều này có thể dẫn đến các vấn đề. Mã kém / tổ chức nhiệm vụ dẫn đến phân nhánh, phân nhánh dẫn đến sáp nhập, sáp nhập ... dẫn đến đau khổ. Tích hợp liên tục như một thực tiễn giải quyết điều này bằng cách khuyến khích mọi người làm việc từ cùng một nguồn chia sẻ. Các mục công việc riêng lẻ phải đủ riêng biệt để được hoàn thành trong một khoảng thời gian ngắn (nhiều nhất là vài giờ).

Về cơ bản, ý tưởng chung là tích hợp một thay đổi nhỏ trong một lượng nhỏ công việc. Tích hợp một thay đổi lớn là một khối lượng công việc lớn không tương xứng. Tổng hợp của công việc tích hợp là nhỏ hơn nếu được thực hiện trong các bước nhỏ không đổi. Điều này cho phép các nhà phát triển dành nhiều thời gian hơn để làm việc trên các tính năng hiển thị của doanh nghiệp thay vì chi phí quá trình phát triển.

Giao hàng liên tục được mô tả là sự phát triển hợp lý của tích hợp liên tục: Luôn có thể đưa sản phẩm vào sản xuất!

Điều này theo cùng một ý tưởng của các mục công việc rời rạc, được xác định rõ. Nếu có một cơ sở mã chủ duy nhất chỉ được điều chỉnh theo từng bước nhỏ bằng các tính năng làm việc hoàn chỉnh, đã được kiểm tra, đã biết thì cơ sở mã đó luôn ổn định. Kiểm tra tự động là chìa khóa ở đây để có thể chứng minh sự ổn định chỉ bằng cách ấn nút.

Công việc ít ổn định hơn cần được thực hiện (một lần nữa, là quá trình phát triển và cần được loại bỏ), càng thường xuyên mà codebase có thể được đẩy đến bất kỳ môi trường nào. Trong rất nhiều công ty, việc triển khai có thể là một quá trình khá mệt mỏi. Ngay cả một hoạt động tất cả các tay trên boong kéo dài một tuần. Điều này là tốn kém và không tạo ra giá trị kinh doanh. Bằng cách sử dụng các định nghĩa mục công việc tốt, kiểm tra tự động hiệu quả và tích hợp liên tục, một nhóm có thể tự động hóa việc phân phối của cơ sở mã đến bất kỳ môi trường nào.

Triển khai liên tục được mô tả là bước tiếp theo hợp lý sau khi phân phối liên tục: Tự động triển khai sản phẩm vào sản xuất bất cứ khi nào nó vượt qua QA!

Bạn sẽ hiếm khi thấy điều này xảy ra trong môi trường kinh doanh và thật vui khi gặp phải nó. Nếu codebase có thể được tự động kiểm tra và tự động triển khai vào bất kỳ môi trường cụ thể nào thì tốt, sản xuất là một môi trường như mọi môi trường khác. Vì vậy, nếu nhóm đã xây dựng đến thời điểm này thì có tiềm năng mang lại giá trị quan trọng cho doanh nghiệp bằng cách luôn có thể triển khai các bản cập nhật cho sản xuất.

Sửa lỗi được gửi đến khách hàng nhanh hơn, các tính năng mới tiếp cận thị trường nhanh hơn, các ý tưởng mới được thử nghiệm dựa trên thị trường với mức tăng nhỏ hơn để cho phép chuyển hướng ưu tiên, v.v.

Ví dụ: giả sử một công ty có một ý tưởng lớn cho một tính năng mới trong sản phẩm hoặc dịch vụ dựa trên phần mềm của họ. Họ đã thực hiện một số nghiên cứu, họ biết thị trường và họ tin rằng ý tưởng này sẽ mang lại một dòng doanh thu mới mạnh mẽ. Bây giờ hãy xem xét hai tùy chọn để cung cấp tính năng đó:

1. Dành nhiều tháng để phát triển toàn bộ trong một chi nhánh một lần. Dành nhiều tuần để tích hợp nó trở lại vào cơ sở mã chính. Dành ngày thử nghiệm nó. Hãy dành một ngày để triển khai nó. Và chỉ sau đó bắt đầu theo dõi doanh thu thực tế trong hệ thống sản xuất.
2. Thực hiện các phần nhỏ của tính năng, từng phần một. Mỗi tuần phát hành một phần mới của nó. Mỗi tuần nhận được nhiều dữ liệu hơn về doanh thu thực tế.

Trong kịch bản đầu tiên, nếu tính năng này không có hiệu ứng thị trường mong muốn thì rất nhiều tiền sẽ bị lãng phí cho thứ mà khách hàng không thực sự muốn. Trong kịch bản thứ hai, thực tế là khách hàng không muốn nó được xác định sớm hơn nhiều và phần còn lại của công việc được ưu tiên.

Cuối cùng, "những điều liên tục" này là tất cả về việc loại bỏ quá trình phát triển. Nếu dòng doanh thu của một công ty là một dịch vụ cụ thể thì lý tưởng nhất là tất cả các chi phí của họ sẽ được đưa vào dịch vụ đó. Chi phí quá trình phát triển (mã hợp nhất, kiểm tra lại các tính năng tương tự sau khi hợp nhất, các tác vụ triển khai thủ công, v.v.) không thực sự đóng góp vào giá trị của dịch vụ, vì vậy các khái niệm này tìm cách loại bỏ các chi phí đó khỏi quy trình.

Một biểu đồ có thể thay thế nhiều từ:

Thưởng thức! :-)

# Tôi đã cập nhật hình ảnh chính xác ...

Sự khác biệt giữa Tích hợp liên tục, Phân phối liên tục và triển khai liên tục

Tôi nghĩ rằng chúng tôi đang phân tích quá mức và có thể làm phức tạp một chút bộ từ "liên tục". Trong bối cảnh này liên tục có nghĩa là tự động hóa. Đối với các từ khác được gắn với "liên tục", hãy sử dụng ngôn ngữ tiếng Anh làm hướng dẫn dịch thuật của bạn và vui lòng không cố gắng làm phức tạp mọi thứ! Trong "xây dựng liên tục", chúng tôi tự động xây dựng (ghi / biên dịch / liên kết / v.v.) ứng dụng của chúng tôi thành thứ gì đó có thể thực thi được cho một nền tảng / container / runtime / etc cụ thể. "Tích hợp liên tục" có nghĩa là chức năng mới của bạn sẽ kiểm tra và thực hiện như dự định khi tương tác với thực thể khác. Rõ ràng, trước khi tích hợp diễn ra, việc xây dựng phải xảy ra và kiểm tra kỹ lưỡng cũng sẽ được sử dụng để xác nhận tích hợp. Vì vậy, trong "hội nhập liên tục" người ta sử dụng tự động hóa để thêm giá trị vào nhóm chức năng hiện có theo cách không làm gián đoạn tiêu cực chức năng hiện có mà tích hợp độc đáo với nó, thêm một giá trị cảm nhận cho toàn bộ. Tích hợp ngụ ý, theo định nghĩa tiếng Anh đơn thuần của nó, rằng mọi thứ diễn ra hài hòa nên trong phần nói chuyện mã của tôi, các biên dịch, liên kết, kiểm tra và chạy hoàn hảo trong toàn bộ. Bạn sẽ không gọi một cái gì đó tích hợp nếu nó thất bại sản phẩm cuối cùng, phải không?! Trong ngữ cảnh của chúng tôi, "Triển khai liên tục" đồng nghĩa với "phân phối liên tục" vì vào cuối ngày chúng tôi đã cung cấp chức năng cho khách hàng của mình. Tuy nhiên, bằng cách phân tích quá mức này, tôi có thể lập luận rằng việc triển khai là một tập hợp con của phân phối vì việc triển khai một cái gì đó không nhất thiết có nghĩa là chúng tôi đã phân phối. Chúng tôi đã triển khai mã nhưng vì chúng tôi trú ẩn ' Được truyền đạt hiệu quả đến các bên liên quan, chúng tôi đã thất bại trong việc cung cấp từ góc độ kinh doanh! Chúng tôi đã triển khai quân đội nhưng chúng tôi chưa giao nước và thực phẩm đã hứa cho thị trấn gần đó. Điều gì sẽ xảy ra nếu tôi thêm thuật ngữ "chuyển tiếp liên tục", liệu nó có giá trị riêng không? Rốt cuộc, có lẽ nó phù hợp hơn để mô tả sự chuyển động của mã thông qua các môi trường vì nó có ý nghĩa "từ / đến" nhiều hơn là triển khai hoặc phân phối chỉ có thể ngụ ý một vị trí, vĩnh viễn! Đây là những gì chúng ta nhận được nếu chúng ta không áp dụng lẽ thường. nó sẽ có giá trị riêng của nó? Rốt cuộc, có lẽ nó phù hợp hơn để mô tả sự chuyển động của mã thông qua các môi trường vì nó có ý nghĩa "từ / đến" nhiều hơn là triển khai hoặc phân phối chỉ có thể ngụ ý một vị trí, vĩnh viễn! Đây là những gì chúng ta nhận được nếu chúng ta không áp dụng lẽ thường. nó sẽ có giá trị riêng của nó? Xét cho cùng, có lẽ nó phù hợp hơn để mô tả sự chuyển động của mã qua các môi trường vì nó có ý nghĩa "từ / đến" nhiều hơn là triển khai hoặc phân phối chỉ có thể ngụ ý một vị trí, vĩnh viễn! Đây là những gì chúng ta nhận được nếu chúng ta không áp dụng lẽ thường.

Tóm lại, đây là công cụ đơn giản để mô tả (làm nó hơi ... phức tạp hơn một chút!), Chỉ cần sử dụng thông thường, ngôn ngữ tiếng Anh và bạn sẽ ổn thôi.

Tích hợp liên tục: Việc thực hành hợp nhất công việc phát triển với nhánh chính liên tục để mã được kiểm tra thường xuyên nhất có thể để nắm bắt các vấn đề sớm.

Giao hàng liên tục: Giao mã liên tục đến một môi trường sau khi mã sẵn sàng được giao. Đây có thể là dàn dựng hoặc sản xuất. Ý tưởng là sản phẩm được giao cho cơ sở người dùng, có thể là của QA hoặc khách hàng để xem xét và kiểm tra.

Kiểm tra đơn vị trong giai đoạn Tích hợp liên tục không thể bắt được tất cả các lỗi và logic kinh doanh, đặc biệt là các vấn đề thiết kế là lý do tại sao chúng tôi cần QA hoặc môi trường dàn dựng để kiểm tra.

Triển khai liên tục: Việc triển khai hoặc phát hành mã ngay khi nó sẵn sàng. Triển khai liên tục yêu cầu tích hợp liên tục và phân phối liên tục nếu không chất lượng mã sẽ không được đảm bảo trong một bản phát hành.

Triển khai liên tục ~ ~ Tích hợp liên tục + Giao hàng liên tục

Hội nhập liên tục

• Tự động (xây dựng kiểm tra in + kiểm tra đơn vị)

Giao hàng liên tục

• Hội nhập liên tục
• Tự động (triển khai để kiểm tra môi trường + kiểm tra tải + kiểm tra tích hợp)
• Hướng dẫn sử dụng (triển khai đến sản xuất)

Triển khai liên tục

• Giao hàng liên tục nhưng tự động (triển khai đến sản xuất)

CI / CD là một hành trình. Không phải là một điểm đến.

Những giai đoạn này là những gợi ý. Bạn có thể điều chỉnh các giai đoạn dựa trên nhu cầu kinh doanh của bạn. Một số giai đoạn có thể được lặp lại cho nhiều loại thử nghiệm, bảo mật và hiệu suất. Tùy thuộc vào mức độ phức tạp của dự án và cấu trúc các nhóm của bạn, một số giai đoạn có thể được lặp lại nhiều lần ở các cấp độ khác nhau. Ví dụ, sản phẩm cuối cùng của một nhóm có thể trở thành một phụ thuộc trong dự án của nhóm tiếp theo. Điều này có nghĩa là sản phẩm cuối cùng của đội đầu tiên sau đó được dàn dựng như một vật phẩm trong dự án của đội tiếp theo.

Chú thích:

Thực hành tích hợp liên tục và phân phối liên tục trên AWS

Nguồn: https://thenuclegeek.com/2020/01/21/continupt-integration-vs-continupt-delivery-vs-continupt-deployment/

Tích hợp liên tục là gì Tích hợp liên tục là một quá trình hoặc thực tiễn phát triển của xây dựng tự động và kiểm tra tự động, tức là Nhà phát triển được yêu cầu cam kết mã của mình nhiều lần vào kho lưu trữ được chia sẻ trong đó mỗi tích hợp được xác minh bằng xây dựng và kiểm tra tự động.

Nếu việc xây dựng thất bại / thành công, nó được thông báo cho nhà phát triển và sau đó anh ta có thể thực hiện các hành động liên quan.

Phân phối liên tục là gì Phân phối liên tục là thực tế nơi chúng tôi giữ mã của chúng tôi có thể triển khai tại bất kỳ thời điểm nào đã vượt qua tất cả các thử nghiệm và có tất cả các cấu hình cần thiết để đẩy mã vào sản xuất nhưng chưa được triển khai.

Triển khai liên tục là gì Với sự giúp đỡ của CI, chúng tôi đã tạo ra bản dựng cho ứng dụng của mình và sẵn sàng đẩy mạnh sản xuất. Trong bước này, bản dựng của chúng tôi đã sẵn sàng và với CD, chúng tôi có thể triển khai ứng dụng của mình trực tiếp vào môi trường QA và nếu mọi thứ suôn sẻ, chúng tôi có thể triển khai bản dựng tương tự để sản xuất.

Về cơ bản, triển khai liên tục là một bước xa hơn so với giao hàng liên tục. Với thực tiễn này, mọi thay đổi vượt qua tất cả các giai đoạn của đường ống sản xuất của bạn sẽ được phát hành cho khách hàng của bạn.

Triển khai liên tục là sự kết hợp giữa Quản lý cấu hình và Container hóa.

Quản lý cấu hình: CM là tất cả về việc duy trì cấu hình của máy chủ sẽ tương thích với yêu cầu ứng dụng.

Containerization : Containerization là một tập hợp các loại phí sẽ duy trì tính nhất quán trên toàn môi trường.

Nguồn Img: https://www.atlassian.com/

DevOps là sự kết hợp của 3C - liên tục , giao tiếp , hợp tác và điều này dẫn đến sự tập trung hàng đầu trong các ngành công nghiệp khác nhau.

Trong một thế giới thiết bị được kết nối IoT, nhiều tính năng scrum như chủ sở hữu sản phẩm, web, thiết bị di động và QA hoạt động một cách nhanh nhẹn trong một chu kỳ scrum để cung cấp sản phẩm cho khách hàng cuối.

Tích hợp liên tục: Nhiều tính năng scrum hoạt động đồng thời ở nhiều điểm cuối

Giao hàng liên tục: Với việc tích hợp và triển khai, việc giao sản phẩm cho nhiều khách hàng sẽ được xử lý cùng một lúc.

Triển khai liên tục: nhiều sản phẩm được triển khai cho nhiều khách hàng tại nhiều nền tảng.

Theo dõi điều này để biết DevOps kích hoạt thế giới kết nối IoT như thế nào: https://youtu.be/nAfZt2t4HqA

Từ những gì tôi đã học được với Alex Cowan trong khóa học Giao hàng & DevOps liên tục , CI và CD là một phần của một chuỗi sản phẩm bao gồm thời gian nó đi từ Quan sát đến Sản phẩm được phát hành.

Từ Quan sát đến Thiết kế, mục tiêu là để có được những ý tưởng có thể kiểm tra chất lượng cao. Phần này của quá trình được coi là Thiết kế liên tục .

Điều gì xảy ra sau đó, khi chúng tôi đi từ Quy tắc trở đi, nó được coi là khả năng Giao hàng liên tục với mục đích là thực hiện ý tưởng và phát hành cho khách hàng rất nhanh (bạn có thể đọc cuốn sách Giao hàng liên tục của Jez Humble : Phát hành phần mềm đáng tin cậy thông qua Build, Test, và triển khai tự động hóa để biết thêm chi tiết). Các đường ống sau đây giải thích các bước tích hợp liên tục (CI) và phân phối liên tục (CD) bao gồm.

Tích hợp liên tục , như Mattias Petter Johansson giải thích ,

là khi một nhóm phần mềm có thói quen thực hiện nhiều lần hợp nhất mỗi ngày và họ có một hệ thống xác minh tự động để kiểm tra các sự hợp nhất đó cho các vấn đề.

(bạn có thể xem hai video sau để có cái nhìn tổng quan hơn về mặt thực tế khi sử dụng CircleCI - Bắt đầu với CircleCI - Tích hợp liên tục P2 và Chạy CircleCI theo yêu cầu kéo ).

Người ta có thể chỉ định đường ống CI / CD như sau, đi từ Mã mới đến Sản phẩm được phát hành.

Ba bước đầu tiên phải thực hiện với Thử nghiệm, mở rộng ranh giới của những gì đang được thử nghiệm.

Mặt khác, Triển khai liên tục là tự động xử lý Triển khai. Vì vậy, bất kỳ cam kết mã nào vượt qua giai đoạn thử nghiệm tự động sẽ tự động được đưa vào sản xuất.

Lưu ý : Đây không nhất thiết là đường ống của bạn sẽ trông như thế nào, nhưng chúng có thể đóng vai trò tham khảo.

hãy để nó ngắn gọn:

CI: Một thực hành phát triển phần mềm trong đó các thành viên của nhóm tích hợp công việc của họ ít nhất là hàng ngày. Mỗi tích hợp được xác minh bằng bản dựng tự động (bao gồm các bài kiểm tra) để phát hiện lỗi nhanh nhất có thể. CD: CD Xây dựng trên CI, nơi bạn xây dựng phần mềm theo cách mà phần mềm có thể được phát hành để sản xuất bất cứ lúc nào.