Mở đầu Đặt vấn dé và trình bày sơ lược về mục dich, đối tượng, phạm vi nghiên cứu va những đóng góp của đề tài. Chương 2 - Cé sở lý thuyết Trình bày và giải thích các cơ sở lý thuyết, định nghĩa và giải thích nguyên tắc hoạt động của DevOps, DevSecOps và các công nghệ được nhóm tác giả sử dụng trong đề tài như: Tích hợp và triển khai liên lục, công nghệ container hóa, hệ thống quản lý phiên bản mã nguồn và bảo mật quy trình phát triển phần mềm, cùng với các công cụ như: Jenkins, Gitlab, Rancher, SonarQube, Kubei, ELK Stack,. Bên cạnh đó, trình bày về tình hình nghiên cứu của DevOps và DevSecOps ở trong và ngoài nước. Chương 3 - Phân tích và thiết kế hệ thống Tién hành phân tích và thiết kế sơ đồ hệ thống, trình bày về luồng xử ly (workflow) của hệ thống.
Giải thích các thành phần và cách hoạt động của hệ thống mà nhóm nghiên cứu: Thực hiện tích hợp và triển khai liên tục quy trình phát triển ứng dụng web bằng việc kết hợp Jenkins và Gitlab, triển khai ứng dụng web trên nền tảng Kubernetes, kiểm tra tính bảo mật của mã nguồn, container Kubernetes và ứng dụng web đã được triển khai với các công cụ được tích hợp vào hệ thống, quan lý quá trình hoạt động của toàn bộ hệ thống. Chương 4 - Triển khai hệ thống và đánh giá kết quả Trinh bày các thông tin phần cứng của hệ thống, các kịch bản thử nghiệm hệ thống thông qua việc mô phỏng các dự án thực tế. Từ đó, đánh giá ưu điểm và hạn chế của hệ thống đã triển khai. Chương 5 - Kết luận và hướng phát triển Tổng kết các nội dung đã nghiên cứu trong dé tài.
Từ đó đề xuất các hướng phát triển của đề tài có thể tiếp tục thực hiện trong tương lai. Chương 2 CƠ SỞ LÝ THUYET 2.1 Các mô hình phát triển phần mềm truyền thống Sự phát triển nhanh chóng của thị trường phát triển phần mềm đã và đang đặt ra những thách thức cho việc xây dựng một quy trình phát triển phần mềm nhanh chóng và mang lại hiệu quả cao nhất. Những mô hình phát triển phần mềm cũ không đáp ứng được yêu cầu của thị trường đang dan bị thay thế bởi những mô hình mới phù hợp hơn.1 Waterfall Mô hình phát triển phần mềm thác nước (Waterfall) được nhắc đến lần đầu tiên vào năm 1970 trong một bài báo của Winston W. Trong bài báo này, đây là một mô hình phát triển phần mềm khả thi, hạn chế những rủi ro trong quá trình phát triển phần mềm và cung cấp được các sản phẩm theo yêu cầu.
Tuy nhiên, Winston W. Royce không sử dụng thuật ngữ waterfall để gọi tên mô hình lúc này [7]. Mô hình Waterfall là quá trình phát triển phần mềm tuần tự, các bước để phát triển phan mềm được tiền hành tuần tự từ trên xuống dưới, tương tự như dòng chảy của một thác nước. Mô hình này mô tả các giai đoạn phải được thực hiện để phát triển thành công một phần mềm [8].
Các giai đoạn của mô hình Waterfall được thể hiện trong hình 2.1: Các giai đoạn của mô hình Waterfall. Trong mô hình Waterfall, giai đoạn phía sau chỉ có thể được tiến hành khi giai đoạn trước nó hoàn thành. Tuy nhiên, trong một số mô hình Waterfall đã được sửa đổi thì nếu phát hiện sai sót xảy ra 6 giai đoạn sau mà nguyên nhân gây ra nó nằm ở giai đoạn trước đó thì có thể quay lại giai đoạn trước đó để sửa đối cho phù hợp. Day là mô hình tiêu chuẩn để phát triển phần mềm.2 Agile Vào khoảng những năm 1990, sự thiéu linh hoạt trong mô hình Waterfall đã dẫn đến sự thất bại của một số dự án phát triển phần mềm sử dụng mô hình này.
Với sự phát triển ngày càng nhanh chóng của thị trường phát triển phần mềm thì việc làm sao đưa sản phẩm đến tay người tiêu dùng càng nhanh càng tốt ngày càng được chú trọng. Nhưng mô hình Waterfall lại không đáp ứng được điều này cho nên đã dẫn đến sự ra đời của mô hình phát triển phần mềm linh hoạt (Agile) [9]. Mô hình Agile thực chất là một tập hợp các nguyên lý, kỹ thuật dành cho phát triển phần mềm tập trung vào khả năng đáp ứng được những thay đổi khi có yêu cau [1]. “Tuyên ngôn Agile [10] được xuất bản năm 2001 đã hệ thống hóa các nguyên tắc của mô hình này.
Một trong số các nguyên tắc trong Tuyên ngôn Agile nói rang: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Nguyên tắc này có thé được hiểu là: "Uw tiên cao nhất của chúng tôi là lam hài lòng khách hàng thông qua việc phân phối sớm và liên tục các phần mém có giá trị. So với mô hình Waterfall truyền thống, mô hình Agile lấy lặp đi lặp lại quy trình phát triển làm cơ sở và tập trung vào con người. Các quy trình Agile kết hợp sự lặp lại và phản hồi liên tục để điều chỉnh và cung cấp thành công hệ thống phần mềm đáp ứng nhu cầu của khách hàng. Scrum Đầu những năm 1990, mô hình phát triển phần mềm Scrum được sử dụng để quản lý quá trình phát triển những sản phẩm phức tạp hay những dự án lớn.
Mô hình Scrum cho phép sử dụng nhiều quy trình và kỹ thuật khác nhau để con người có thể xác định các van dé đang diễn ra và đưa ra giải pháp phù hợp, đảm bảo được năng suất và chất lượng sản phẩm tốt nhất để đưa đến tay khách hàng. 'Vào năm 2002, một quyển sách mang tên "Agile Software Development with Scrum" [11] mô tả chỉ tiết về Scrum đã được xuất bản. Mô hình phát triển phần mềm Scrum được minh họa trong hình 2. 10 Product Backlog Sprint Backlog vong lap Cac phần tăng trưởng có thể chuyển giao.2: Mô hình Scrum.
Mô hình Scrum chia toàn bộ dự án thành các quá trình nhỏ hơn kéo dài từ 2-4 tuần. Quá trình nhỏ này được lặp đi lặp lại và được gọi là Sprint. Sprint là thành phần quan trọng nhất của mô hình Serum. Một Sprint mới sẽ được bắt đầu ngay khi Sprint trước đó kết thúc [12].
Day là sự khác biệt cơ bản giữa mô hình Scrum và mô hình Waterfall.4 Lean Quy trình phát triển phần mềm tinh gon (Lean) là quy trình ứng dung các nguyên tắc sản xuất tinh gọn của Hệ thóng sản xuất Toyota - Toyota Production System [13] vào lĩnh vực phát triển phần mềm. Phát triển phần mềm Lean bao gồm bay nguyên tắc chính được trình bay chỉ tiết trong quyến sách "Lean software development: an agile toolkit” [L4] xuất bản năm 2003: * Hạn chế lãng phí * Nâng cao kiến thức * Quyết định càng muộn càng tốt 11 * Cung cấp càng nhanh càng tốt Trao quyền quyết định cho nhóm phát triển Xây dựng chất lượng sản phẩm Có cái nhìn bao quát toàn bộ Cốt lõi của quy trình phát triển phần mềm tinh gọn là hạn chế sự lãng phí - những yêu tố làm ảnh hưởng đến lợi nhuận thu được từ khách hàng - một cách tối đa. Quy trình phát triển phần mềm Lean tập trung vào cách sử dụng CNTT để tạo ra các giá trị cho khách hàng chứ không tập trung vào quy trình phát triển phần mềm [15]. Lean là sự tổng hợp của một hệ thống các nguyên tắc và triết lý dùng để xây dựng hệ thống phần mềm cho khách hàng.2 Mô hình DevOps 2.1 Nguồn gốc hình thành Mặc dù các phương pháp phát triển phần mềm Agile ngày càng trở nên phổ biến, nhưng nhiều công ty và tổ chức nhận thấy rằng họ không thể phát hành các sản phẩm thường xuyên hơn, nguyên nhân là do nhóm vận hành phần mềm (nhóm thực hiện việc điều phối, phát hành phần mềm trong công ty) không thể làm việc nhịp nhàng với nhóm phát triển sản phẩm, tạo ra một "nit that cổchai" trong quá trình phát triển sản phẩm [16].
Với cách làm việc truyền thống, nhóm phát triển làm việc riêng và nhóm vận hành phần mềm làm việc riêng, họ sẽ có mục tiêu công việc khác nhau. Nếu như mục tiêu của nhóm phát triển là xây dựng các tính năng (function) đúng với yêu cầu (requirement) và phát hành (release) cho khách hàng càng nhanh càng tốt thì mục tiêu 12 của nhóm vận hành phần mềm là tạo ra một hệ thống ổn định. Trong một hoàn cảnh nào đó, hai mục tiêu này sẽ đối lập nhau, và các nhóm thì chỉ quan tâm đến công việc của mình, dẫn đến sản phẩm dễ xảy ra vấn dé làm kéo dài thời gian phát triển và làm khách hàng không hài lòng. Vì thé, DevOps được sinh ra với ý tưởng là kết hợp Dev và Ops để thực hiện một mục tiêu chung là “Speed and Stability” - tốc độ và 6n định.
Phong trào DevOps bắt đầu hình thành trong khoảng thời gian từ năm 2007 đến năm 2008, khi các công ty và cộng đồng phát triển phần mềm nhận ra những vấn đề có hậu quả nghiêm trong trong quá trình phát triền phần mềm. Năm 2009, tại hội nghị Velocity, hai kỹ sư của Flickr là John Allspaw và Paul Hammond đã có một bài thuyết trình nổi tiếng với tiêu đề "/0 Deploys per Day: Dev and Ops Cooperation at Flickr" [L7]. Trong bài thuyết trình này, Allspaw và Hammond đã thể hiện được các mâu thuẫn và tranh cãi giữa nhóm phát triển và nhóm vận hành. Bài thuyết trình của họ cho thấy cách hợp lý nhất để quy trình phát triển phần mềm đáp ứng được nhu cầu ngày càng cao của thị trường là thực hiện các hoạt động phát triển và vận hành ứng dụng một cách liền mạch, minh bạch và được tích hợp hoàn toàn với nhau.
Cũng trong năm này, được truyền cảm hứng sau khi xem bài thuyết trình của Allspaw và Hammond, Patrick Debois đã tổ chức hội nghị mang tên "DevOpsDay" tại Bỉ [18]. Từ đó, thuật ngữ DevOps đã chính thức được sử dụng.3: Sự hình thành DevOps. Thuật ngữ DevOps được tao ra từ sự kết hợp của hai từ "Development (Dev)" và "Operations (Ops)". DevOps mở rộng các nguyên tắc Agile và nhắn mạnh sự hợp tác và trao đổi thông tin của các kỹ sư phát triển phần mềm (Dev - Developer - Development) và bộ phận vận hành (Ops - Operator - Operations) bao gồm kỹ sư hệ thống, kỹ sư bao mật, kỹ sư mạng, kỹ sư hạ tang,.
khi làm việc cùng nhau để tự động hóa quá trình chuyển giao sản phẩm phần mềm, nhằm mục đích rút ngắn vòng đời phát triển phần mềm (SDLC). Với các dự án có kiến trúc phức tạp và quy mô lớn, việc thay đổi hay bổ sung các tính năng mới mang đến nhiều tác động đến chất lượng phần mềm và được thực hiện lặp đi lặp lại để cải thiện chất lượng phần mềm.