Ci cd là gì
I. CI là ...?
CI là Continuous Integration. Nó là phương pháp phát triển phần mềm yêu cầu các thành viên của team tích hợp quá trình của họ thường xuyên, mỗi ngày ít tuyệt nhất một lần. Từng tích vừa lòng được "build" auto (bao bao gồm cả test) nhằm phát hiện lỗi sớm nhất có thể có thể. Cả team nhận biết rằng biện pháp tiếp cận này giảm thiểu vấn đề tích phù hợp và cho phép phát triển ứng dụng nhanh hơn. Bạn đang xem: Ci cd là gì
Một kịch phiên bản CI bắt đầu bằng việc developer commit code lên repository (github chẳng hạn). Ngẫu nhiên thay thay đổi nào cũng biến thành trigger một vòng đời CI. Các bước trong một kịch bạn dạng CI hay như sau:
Đầu tiên, developer commit code lên repo.CI server giám sát và đo lường repo và kiểm tra xem liệu có biến hóa nào bên trên repo hay là không (liên tục, chẳng hạn mỗi phút 1 lần)Ngay lúc commit xảy ra, CI vps phát hiện repo tất cả thay đổi, cho nên nó nhận code mới nhất từ repo và tiếp nối build, chạy unit và integration testCI server sẽ sinh ra các feedback với gửi đến các member của projectCI server liên tiếp chờ đổi khác ở repo
Mỗi lần developer làm chấm dứt task, họ bắt buộc chạy một private build (tức là chạy ứng dụng trên local trước), check choác cẩn thận và commit code lên repo khi vẫn thấy ổn. Bước này xảy ra tiếp tục và ở ngẫu nhiên thời điểm như thế nào trong ngày. Việc build tích hợp sẽ không xảy ra khi những biến hóa này chưa ảnh hưởng đến repo (kiểu như các bạn commit mà không được merge vậy).
Một giữa những tuyên ngôn của CI là "Build Software at Every Change". Mục đích là để tránh số đông câu hình dạng như "Ớ, phần này chạy xe trên máy em thông thường mà" Vấn đề sẽ tiến hành tìm ra sớm bằng phương pháp build thường xuyên, với để CI hoạt động hiệu trái trong project, tốt nhất có thể là developer đề nghị commit code liên tiếp hơn. Đợi hơn một ngày để commit code lên repo hoàn toàn có thể khiến việc tích thích hợp tốn thời gian và code mình dùng rất có thể không nên là code bắt đầu nhất.
A đang quản lý một dự án công trình với 25 developer với A muốn kết hợp sử dụng CI, nhưng vụ việc là làm thế nào để dev commit code tiếp tục hơn. A xem xét lại mọi vụ việc và phân biệt rằng, một vài dev không thích commit trước lúc code của họ trông thiệt "perfect", vì chưng task đó ảnh hưởng đến khá nhiều thành phần. A thấy tốt hơn không còn là anh rất có thể chia task này ra thành các task khác bé dại hơn nhằm bảo đảm hoàn thành trong 1-2 ngày, để tận dụng được kết quả sức mạnh của CI.
Túm lại, thì công dụng của việc áp dụng CI sẽ là:
Giảm thiểu khủng hoảng nhờ bài toán phát hiện tại lỗi và fix sớm, tăng quality phần mềm nhờ việc tự động hóa test với inspect (đây cũng là một trong những tiện ích của CI, code được inspect auto dựa theo config đã mua đặt, bảo vệ coding style, ví dụ điển hình một function chỉ được dài không thực sự 10 mẫu code ...)Giảm thiểu đông đảo quy trình bằng tay thủ công lặp đi lặp lại (build css, js, migrate, test...), thay vì chưng đó là build từ động, chạy chạy thử tự độngSinh ra phần mềm hoàn toàn có thể deploy ở bất kỳ thời gian, địa điểmII. Continuous Delivery

Trong lúc Continuous Integration là quá trình để build và demo tự động, thì Continuous Delivery (tạm dịch là chuyển nhượng bàn giao liên tục) lại nâng cao hơn một chút, bằng cách triển khai tất cả chuyển đổi về code (đã được build cùng test) đến môi trường testing hoặc staging. Continuous Delivery cho phép developer tự động hóa phần testing cạnh bên việc áp dụng unit test, kiểm tra ứng dụng qua các thước đo trước khi triển khai cho quý khách (production). Những bài bác test này bao hàm UI testing, load testing, integration testing, API testing... Nó tự động hoàn toàn quá trình release phần mềm.
Continuous Delivery được thực hiện bằng phương pháp sử dụng Deployment Pipeline.
Deployment Pipeline chia quy trình chuyển giao ứng dụng thành các giai đoạn. Mỗi tiến trình có mục tiêu xác minh chất lượng của các tính năng vượt trội từ một góc độ không giống nhau để kiểm định chức năng và kiêng lỗi ảnh hưởng đến tín đồ dùng. Pipeline sẽ cung cấp phản hồi cho nhóm trong việc cung cấp tính năng mới. Ở góc nhìn trừu tượng hơn, deployment pipeline là quá trình để chuyển ứng dụng từ version control đến tay tín đồ dùng. Mỗi biến đổi đến ứng dụng sẽ đi qua một quy trình phức hợp để được phát hành.
Xem thêm: Những Mẫu Truyện Tiếu Lâm Tục, Truyện Cười 18+ Siêu Tục Tĩu Bậy Bựa

Có một quan niệm nữa là Continuos Deployment, với hai khái niệm này thường xuất xắc bị lầm lẫn với nhau. Giả dụ Continuous Delivery là xúc tiến code lên môi trường xung quanh staging, và deploy bằng tay lên môi trường xung quanh production, thì Continuous Deployment (cũng viết tắt là CD ) lại là kỹ thuật để triển khai code lên môi trường thiên nhiên production một phương pháp tự động, cùng cũng đề nghị là kim chỉ nam của phần lớn công ty.
Về cơ phiên bản thì môi trường xung quanh staging là môi trường giống với production, nên đã làm cho Continous Delivery được thì cũng làm cho Continous Deployment được. Tuy nhiên, thực tế lại không dễ ợt như vậy. Lý do trước tiên là bạn có thể deploy tự động hóa lên staging, mà lại liệu chúng ta có dám deploy tự động hóa với production, cho dù là mọi thông số kỹ thuật đều tương đương nhau thì thực tiễn staging với production server vẫn luôn là hai server riêng biệt, và vì vậy không thể bảo vệ mọi sản phẩm công nghệ chạy đúng bên trên staging sẽ chạy đúng trên production, vậy cho nên deploy lên production thường phải làm bằng tay thủ công để chắc chắn là là các bước build, demo được triển khai chính xác. Lý do thứ hai đơn giản dễ dàng hơn, đó là rất khó để test auto hoàn toàn, và vì thế khó mà tự động hóa deploy được.
Dù Continous Deployment có thể không cân xứng với đều công ty, tuy nhiên Continuous Delivery thì tuyệt đối hoàn hảo là yêu cầu cho việc triển khai triết lý DevOps. Chỉ lúc code được chuyển nhượng bàn giao liên tục, họ mới rất có thể tự tin rằng những chuyển đổi từ code sẽ ship hàng cho quý khách hàng sau chỉ vài phút với một nút ấn.

III. DevOps
DevOps là phối hợp của Development và Operations, thuật ngữ này xuất hiện thêm năm 2009, là sự phối kết hợp của triết lý văn hóa, thực tiễn và đầy đủ công cụ nhằm mục đích tăng tốc độ chuyển giao áp dụng và dịch vụ thương mại của tổ chức: phát triển và cải tiến sản phẩm nhanh hơn những tổ chức sử dụng quá trình phát triển phần mềm và quản lý cơ sở hạ tầng truyền thống. Tốc độ này cho phép các tổ chức giao hàng khách hàng tốt hơn và cạnh tranh hiệu quả hơn trên thị trường.

DevOps khuyến khích toàn bộ thành viên vượt qua ngăn cản (từ góc độ nghề nghiệp, siêng môn, thành phần khác nhau ...) và tạo thành một môi trường mà làm việc đó những người dân tạo ra phần mềm và những người dân hỗ trợ buổi giao lưu của phần mềm thao tác làm việc cùng nhau vào một mọt liên kết ngặt nghèo và hài hòa, vì công dụng chung của tập thể.
Về khía cạnh khái niệm, CD cùng DevOps là hai vật dụng khác nhau, mặc dù chúng có ý nghĩa tương từ nhau, là tập trung vào những chuyển đổi nhỏ, gấp rút có giá bán trị với người dùng. CD là bí quyết tiếp cận để tự động chuyển giao, triệu tập vào việc develop, build, test, delivery thành phầm nhanh chóng. Còn DevOps có phạm vi rộng hơn, cùng nó không hẳn công cụ, chẳng yêu cầu kỹ thuật, nó là 1 thứ "văn hóa". Công ty rất có thể thực hiện tại triết lý DevOps cơ mà không cần setup CD, cùng ngược lại, setup CD mà không cần thiết phải sử dụng triết lý DevOps lên tổ chức. Mà lại để giành được thành công và hiệu quả, cực tốt là sử dụng phối hợp cả hai: CD với DevOps. DevOps và Continuous Delivery chính là tương lai của cải tiến và phát triển phần mềm.
Về DevOps thì bên trên ingamemobi.com cũng đều có một series bài viết, phần đông người rất có thể search để tìm hiểu thêm.