Giao hàng liên tục:
Phân phối liên tục là một quá trình, trong đó các thay đổi mã được tự động xây dựng, thử nghiệm và chuẩn bị cho việc phát hành sang phiên bản sản xuất.Tôi hy vọng bạn đã thích của tôi Ở đây, tôi sẽ nói về các chủ đề sau ::
- Giao hàng liên tục là gì?
- Các loại kiểm thử phần mềm
- Sự khác biệt giữa Tích hợp, Phân phối và Triển khai Liên tục
- Nhu cầu về Giao hàng liên tục là gì?
- Thực hành sử dụng Jenkins và Tomcat
Hãy để chúng tôi nhanh chóng hiểu cách hoạt động của Giao hàng liên tục.
Giao hàng liên tục là gì?
Đó là một quá trình mà bạn xây dựng phần mềm theo cách mà nó có thể được phát hành vào phiên bản sản xuất bất cứ lúc nào.Hãy xem xét sơ đồ dưới đây:
Hãy để tôi giải thích sơ đồ trên:
- Các tập lệnh xây dựng tự động sẽ phát hiện các thay đổi trong Quản lý mã nguồn (SCM) như Git.
- Khi thay đổi được phát hiện, mã nguồn sẽ được triển khai tới một máy chủ xây dựng chuyên dụng để đảm bảo quá trình xây dựng không bị lỗi và tất cả các lớp kiểm tra và kiểm tra tích hợp đang chạy tốt.
- Sau đó, ứng dụng xây dựng được triển khai trên các máy chủ thử nghiệm (máy chủ tiền sản xuất) để Kiểm tra sự chấp nhận của người dùng (UAT).
- Cuối cùng, ứng dụng được triển khai thủ công trên các máy chủ sản xuất để phát hành.
Trước khi tiếp tục, tôi sẽ giải thích công bằng cho bạn về các loại thử nghiệm khác nhau.
Các loại kiểm thử phần mềm:
Nói rộng ra, có hai loại kiểm tra:
- Kiểm tra hộp đen: Nó là một kỹ thuật kiểm thử bỏ qua cơ chế bên trong của hệ thống và tập trung vào đầu ra được tạo ra so với bất kỳ đầu vào và thực thi nào của hệ thống. Nó còn được gọi là kiểm thử chức năng. Về cơ bản, nó được sử dụng để xác thực phần mềm.
- Kiểm tra hộp trắng: là một kỹ thuật kiểm thử có tính đến cơ chế bên trong của một hệ thống. Nó còn được gọi là kiểm tra cấu trúc và kiểm tra hộp kính. Về cơ bản, nó được sử dụng để xác minh phần mềm.
Thử nghiệm hộp trắng:
Có hai loại kiểm tra, thuộc loại này.
- Kiểm tra đơn vị: Nó là thử nghiệm của một đơn vị riêng lẻ hoặc một nhóm các đơn vị liên quan. Lập trình viên thường thực hiện để kiểm tra xem đơn vị mà họ đã thực hiện có đang tạo ra đầu ra mong đợi so với đầu vào đã cho hay không.
- Thử nghiệm hội nhập: Đây là một loại thử nghiệm trong đó một nhóm các thành phầnkết hợp để tạo ra đầu ra. Ngoài ra, sự tương tác giữa phần mềm và phần cứng được kiểm tra nếu các thành phần phần mềm và phần cứng có bất kỳ mối quan hệ nào. Nó có thể nằm trong cả thử nghiệm hộp trắng và thử nghiệm hộp đen.
Kiểm tra hộp đen:
Có nhiều bài kiểm tra thuộc loại này. Tôi sẽ tập trung vàomột vài, điều quan trọng bạn cần biết để hiểu blog này:
- Kiểm tra chức năng / chấp nhận: Nó đảm bảo rằng chức năng được chỉ định được yêu cầu trong các yêu cầu hệ thống hoạt động. Nó được thực hiện để đảm bảo rằng sản phẩm được giao đáp ứng các yêu cầu và hoạt động như khách hàng mong đợi
- Thử nghiệm hệ thống: Nó đảm bảo rằng bằng cách đặt phần mềm trong các môi trường khác nhau (ví dụ: Hệ điều hành), nó vẫn hoạt động.
- Bài kiểm tra về áp lực: Nó đánh giá cách hệ thống hoạt động trong các điều kiện không thuận lợi.
- Thử nghiệm Beta: Nó được thực hiện bởi người dùng cuối, một nhóm phát triển bên ngoài hoặc phát hành công khai phiên bản trước đầy đủ của sản phẩm được gọi làbản betaphiên bản. Mục đích của thử nghiệm beta là để khắc phục các lỗi không mong muốn.
Bây giờ là thời điểm chính xác để tôi giải thích sự khác biệt giữa Tích hợp liên tục, Phân phối và Triển khai.
Sự khác biệt giữa tích hợp liên tục, phân phối và triển khai:
Nội dung trực quan đến não của cá nhân theo cách nhanh hơn và dễ hiểu hơn so với thông tin dạng văn bản. Vì vậy, tôi sẽ bắt đầu với một sơ đồ giải thích rõ ràng sự khác biệt:
Trong Tích hợp liên tục, mọi cam kết mã đều được xây dựng và thử nghiệm, nhưng không ở trong điều kiện để được phát hành. Ý tôi là ứng dụng xây dựng không được triển khai tự động trên các máy chủ thử nghiệm để xác thực nó bằng cách sử dụng các loại thử nghiệm Hộp đen khác nhau như - Thử nghiệm chấp nhận người dùng (UAT).
Trong Phân phối liên tục, ứng dụng liên tục được triển khai trên các máy chủ thử nghiệm cho UAT. Hoặc, bạn có thể nói rằng ứng dụng đã sẵn sàng để phát hành chính thức bất cứ lúc nào. Vì vậy, rõ ràng Tích hợp liên tục là cần thiết cho Phân phối liên tục.
Triển khai liên tục là bước tiếp theo sau Phân phối liên tục, nơi bạn không chỉ tạo một gói có thể triển khai, mà bạn thực sự đang triển khai nó theo cách tự động.
Hãy để tôi tóm tắt sự khác biệt bằng bảng:
| Hội nhập liên tục | Giao hàng liên tục | Triển khai liên tục |
| Tự động xây dựng cho mọi cam kết | Tự động xây dựng và UAT cho mọi cam kết | Tự động xây dựng, UAT và phát hành để sản xuất cho mọi cam kết |
| Độc lập với Phân phối Liên tục và Triển khai Liên tục | Đây là bước tiếp theo sau khi Tích hợp liên tục | nó là một bước nữa Giao hàng liên tục |
| Cuối cùng, ứng dụng không có điều kiện để phát hành sản xuất | Cuối cùng, ứng dụng đang ở trong điều kiện để được phát hành chính thức. | Ứng dụng được triển khai liên tục |
| Bao gồm thử nghiệm Hộp trắng | Bao gồm thử nghiệm Hộp đen và Hộp trắng | Nó bao gồm toàn bộ quy trình cần thiết để triển khai ứng dụng |
Nói một cách dễ hiểu, Tích hợp liên tục là một phần của cả Phân phối liên tục và Triển khai liên tục. Và Triển khai liên tục giống như Phân phối liên tục, ngoại trừ việc phát hành diễn ra tự động.
Tìm hiểu cách tạo đường ống CI / CD bằng Jenkins trên đám mây
Nhưng câu hỏi đặt ra là, liệu Tích hợp liên tục có đủ hay không.
Tại sao chúng ta cần giao hàng liên tục?
Hãy để chúng tôi hiểu điều này với một ví dụ.
Hãy tưởng tượng có 80 nhà phát triển đang làm việc trong một dự án lớn. Họ đang sử dụng đường ống Tích hợp liên tục để tạo điều kiện cho các bản dựng tự động. Chúng tôi biết rằng xây dựng cũng bao gồm Kiểm thử đơn vị. Một ngày nọ, họ quyết định triển khai bản dựng mới nhất đã vượt qua các bài kiểm tra đơn vị vào một môi trường thử nghiệm.
Đây phải là một cách tiếp cận triển khai kéo dài nhưng có kiểm soát mà các chuyên gia môi trường của họ đã thực hiện. Tuy nhiên, hệ thống dường như không hoạt động.
Điều gì có thể là nguyên nhân rõ ràng của thất bại?
Vâng, lý do đầu tiên mà hầu hết mọi người sẽ nghĩ là có một số vấn đề với cấu hình. Giống như hầu hết mọi người, ngay cả khi họ nghĩ vậy.Họ đã dành rất nhiều thời gian để cố gắng tìm ra lỗi với cấu hình của môi trường, nhưng họ không thể tìm ra vấn đề.
Một nhà phát triển nhạy bén đã áp dụng phương pháp tiếp cận thông minh:
Sau đó, một trong những Nhà phát triển cấp cao đã thử ứng dụng trên máy phát triển của mình. Nó cũng không hoạt động ở đó.
Anh ấy đã lùi lại qua các phiên bản trước đó và trước đó cho đến khi anh ấy phát hiện ra rằng hệ thống đã ngừng hoạt động ba tuần trước đó. Một lỗi nhỏ, khó hiểu đã ngăn hệ thống khởi động chính xác. Mặc dù, dự án có phạm vi kiểm tra đơn vị tốt.Mặc dù vậy, 80 nhà phát triển, những người thường chỉ chạy các bài kiểm tra hơn là bản thân ứng dụng, đã không thấy vấn đề trong ba tuần.
Báo cáo vấn đề:
Nếu không chạy Kiểm tra chấp nhận trong môi trường giống như sản xuất, họ không biết gì về việc liệu ứng dụng có đáp ứng các thông số kỹ thuật của khách hàng hay không, cũng như liệu nó có thể được triển khai và tồn tại trong thế giới thực hay không. Nếu họ muốn có phản hồi kịp thời về những chủ đề này, họ phải mở rộng phạm vi của quá trình tích hợp liên tục của họ.
Hãy để tôi tóm tắt các bài học kinh nghiệm bằng cách xem xét các vấn đề trên:
- Unit Test chỉ kiểm tra quan điểm của nhà phát triển về giải pháp cho một vấn đề. Họ chỉ có một khả năng hạn chế để chứng minh rằng ứng dụng làm những gì nó được cho là từ góc độ người dùng. Chúng không đủ đểxác định các vấn đề chức năng thực sự.
- Triển khai ứng dụng trên môi trường thử nghiệm là một quá trình phức tạp, chuyên sâu thủ công và khá dễ xảy ra lỗi.Điều này có nghĩa là mọi nỗ lực triển khai đều là một thử nghiệm mới - một quy trình thủ công, dễ xảy ra lỗi.
Giải pháp - Đường ống phân phối liên tục (Kiểm tra chấp nhận tự động):
Họ đã thực hiện Tích hợp liên tục (Phân phối liên tục) sang bước tiếp theo và giới thiệu một số Kiểm tra chấp nhận tự động, đơn giản chứng minh rằng ứng dụng đã chạy và có thể thực hiện chức năng cơ bản nhất của nó.Phần lớn các thử nghiệm đang chạy trong giai đoạn Kiểm tra chấp nhận là Kiểm tra chấp nhận chức năng.
sự khác biệt giữa html và xml
Về cơ bản, họ đã xây dựng một đường ống Phân phối liên tục, để đảm bảo rằng ứng dụng được triển khai liền mạch trên môi trường sản xuất, bằng cách đảm bảo rằng ứng dụng hoạt động tốt khi được triển khai trên máy chủ thử nghiệm là bản sao của máy chủ sản xuất.
Lý thuyết là đủ, bây giờ tôi sẽ chỉ cho bạn cách tạo một đường ống Phân phối liên tục bằng Jenkins.
Đường ống phân phối liên tục sử dụng Jenkins:
Ở đây tôi sẽ sử dụng Jenkins để tạo Đường ống phân phối liên tục, bao gồm các nhiệm vụ sau:
Các bước liên quan đến Demo:
- Tìm nạp mã từ GitHub
- Biên dịch mã nguồn
- Kiểm thử đơn vị và tạo báo cáo kiểm tra JUnit
- Đóng gói ứng dụng thành một tệp WAR và triển khai nó trên máy chủ Tomcat
Điều kiện tiên quyết:
- Máy CentOS 7
- Jenkins 2.121.1
- Docker
- Tomcat 7
Bước - 1 Biên dịch mã nguồn:
Hãy bắt đầu bằng cách tạo một dự án Freestyle trước ở Jenkins. Hãy xem xét ảnh chụp màn hình dưới đây:
Đặt tên cho dự án của bạn và chọn Dự án theo phong cách tự do:
Khi cuộn xuống, bạn sẽ tìm thấy một tùy chọn để thêm kho mã nguồn, chọn git và thêm URL của kho, trong kho đó có một tệp pom.xml mà chúng tôi sẽ sử dụng để xây dựng dự án của mình. Hãy xem xét ảnh chụp màn hình dưới đây:
Bây giờ chúng ta sẽ thêm một Trình kích hoạt xây dựng. Chọn tùy chọn SCM thăm dò, về cơ bản, chúng tôi sẽ định cấu hình Jenkins để thăm dò ý kiến trên kho lưu trữ GitHub sau mỗi 5 phút về các thay đổi trong mã. Hãy xem xét ảnh chụp màn hình dưới đây:
Trước khi tiếp tục, hãy để tôi giới thiệu cho bạn một chút về Chu trình xây dựng Maven.
Mỗi vòng đời xây dựng được xác định bởi một danh sách các giai đoạn xây dựng khác nhau, trong đó giai đoạn xây dựng đại diện cho một giai đoạn trong vòng đời.
Sau đây là danh sách các giai đoạn xây dựng:
- xác thực - xác nhận dự án là chính xác và tất cả các thông tin cần thiết đều có sẵn
- biên dịch - biên dịch mã nguồn của dự án
- kiểm tra - kiểm tra mã nguồn đã biên dịch bằng cách sử dụng khung kiểm thử đơn vị phù hợp. Các thử nghiệm này không yêu cầu mã được đóng gói hoặc triển khai
- gói - lấy mã đã biên dịch và đóng gói nó ở định dạng có thể phân phối, chẳng hạn như JAR.
- xác minh - chạy bất kỳ kiểm tra nào về kết quả của các bài kiểm tra tích hợp để đảm bảo đáp ứng các tiêu chí chất lượng
- cài đặt - cài đặt gói vào kho lưu trữ cục bộ, để sử dụng như một phần phụ thuộc trong các dự án khác cục bộ
- triển khai - được thực hiện trong môi trường xây dựng, sao chép gói cuối cùng vào kho lưu trữ từ xa để chia sẻ với các nhà phát triển và dự án khác.
Tôi có thể chạy lệnh dưới đây, để biên dịch mã nguồn, kiểm tra đơn vị và thậm chí đóng gói ứng dụng trong tệp chiến tranh:
gói sạch mvn
Bạn cũng có thể chia nhỏ công việc xây dựng của mình thành một số bước xây dựng. Điều này giúp dễ dàng tổ chức các bản dựng theo các giai đoạn riêng biệt, rõ ràng.
Vì vậy, chúng tôi sẽ bắt đầu bằng cách biên dịch mã nguồn. Trong tab xây dựng, nhấp vào gọi các mục tiêu maven cấp cao nhất và nhập lệnh dưới đây:
biên dịch
Hãy xem xét ảnh chụp màn hình dưới đây:
Thao tác này sẽ kéo mã nguồn từ kho lưu trữ GitHub và cũng sẽ biên dịch nó (Giai đoạn Biên dịch Maven).
Nhấp vào Lưu và chạy dự án.
Bây giờ, hãy nhấp vào đầu ra của bảng điều khiển để xem kết quả.
Bước - Kiểm tra đơn vị 2:
Bây giờ chúng ta sẽ tạo thêm một Dự án tự do để thử nghiệm đơn vị.
Thêm cùng một URL kho lưu trữ trong tab quản lý mã nguồn, giống như chúng ta đã làm trong công việc trước.
Bây giờ, trong tab “Buid Trigger”, hãy nhấp vào “xây dựng sau khi các dự án khác được xây dựng”. Tại đó, hãy nhập tên của dự án trước đó mà chúng tôi đang biên dịch mã nguồn và bạn có thể chọn bất kỳ tùy chọn nào dưới đây:
- Chỉ kích hoạt nếu bản dựng ổn định
- Kích hoạt ngay cả khi bản dựng không ổn định
- Kích hoạt ngay cả khi bản dựng không thành công
Tôi nghĩ các tùy chọn trên khá dễ hiểu vì vậy, hãy chọn bất kỳ tùy chọn nào. Hãy xem xét ảnh chụp màn hình dưới đây:
Trong tab Xây dựng, nhấp vào gọi các mục tiêu maven cấp cao nhất và sử dụng lệnh dưới đây:
kiểm tra
Jenkins cũng làm rất tốt việc giúp bạn hiển thị kết quả thử nghiệm và xu hướng kết quả thử nghiệm.
Tiêu chuẩn thực tế cho báo cáo thử nghiệm trong thế giới Java là một định dạng XML được JUnit sử dụng. Định dạng này cũng được sử dụng bởi nhiều công cụ kiểm tra Java khác, chẳng hạn như TestNG, Spock và Easyb. Jenkins hiểu định dạng này, vì vậy nếu bản dựng của bạn tạo ra kết quả kiểm tra JUnit XML, Jenkins có thể tạo báo cáo kiểm tra đồ họa đẹp và thống kê về kết quả kiểm tra theo thời gian, đồng thời cho phép bạn xem chi tiết về bất kỳ lỗi kiểm tra nào. Jenkins cũng theo dõi thời gian chạy thử nghiệm của bạn, cả trên toàn cầu và mỗi thử nghiệm — điều này có thể hữu ích nếu bạn cần theo dõi các vấn đề về hiệu suất.
Vì vậy, điều tiếp theo chúng ta cần làm là yêu cầu Jenkins theo dõi các bài kiểm tra đơn vị của chúng ta.
Chuyển đến phần Hành động sau xây dựng và đánh dấu vào hộp kiểm “Xuất bản báo cáo kết quả kiểm tra JUnit”. Khi Maven chạy các bài kiểm tra đơn vị trong một dự án, nó sẽ tự động tạo các báo cáo kiểm tra XML trong một thư mục được gọi là báo cáo surefire. Vì vậy, hãy nhập “** / target / surefire-report / *. Xml” vào trường “Các XML báo cáo thử nghiệm”. Hai dấu hoa thị ở đầu đường dẫn (“**”) là phương pháp hay nhất để làm cho cấu hình mạnh mẽ hơn một chút: chúng cho phép Jenkins tìm thấy thư mục đích bất kể chúng tôi đã cấu hình Jenkins như thế nào để kiểm tra mã nguồn.
** / target / chắc chắn-báo cáo / *. xml
Một lần nữa lưu nó và nhấp vào Build Now.
Bây giờ, báo cáo JUnit được ghi vào / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-report / TEST-behavior.
Trong bảng điều khiển Jenkinsbạn cũng có thể nhận thấy kết quả kiểm tra:
làm thế nào để in nhật ký cam kết git
Bước - 3 Tạo tệp WAR và triển khai trên máy chủ Tomcat:
Bây giờ, bước tiếp theo là đóng gói ứng dụng của chúng tôi trong một tệp WAR và triển khai tệp đó trên máy chủ Tomcat để kiểm tra Chấp nhận người dùng.
Tạo thêm một dự án tự do và thêm URL kho lưu trữ mã nguồn.
Sau đó, trong tab kích hoạt bản dựng, chọn bản dựng khi các dự án khác được tạo, hãy xem ảnh chụp màn hình bên dưới:
Về cơ bản, sau công việc thử nghiệm, giai đoạn triển khai sẽ tự động bắt đầu.
Trong tab xây dựng, chọn tập lệnh shell. Nhập lệnh dưới đây để đóng gói ứng dụng trong tệp WAR:
gói mvn
Bước tiếp theo là triển khai tệp WAR này cho Tomcatngười phục vụ. Trong tab “Hành động sau xây dựng”, chọn triển khai chiến tranh / tai vào vùng chứa. Tại đây, cung cấp đường dẫn đến tệp chiến tranh và cung cấp đường dẫn ngữ cảnh. Hãy xem xét ảnh chụp màn hình dưới đây:
Chọn thông tin đăng nhập Tomcat và lưu ý ảnh chụp màn hình ở trên. Ngoài ra, bạn cần cung cấp URL của máy chủ Tomcat của mình.
Để thêm thông tin đăng nhập trong Jenkins, hãy nhấp vào tùy chọn thông tin đăng nhập trên bảng điều khiển Jenkins.
Nhấp vào Hệ thống và chọn thông tin đăng nhập toàn cầu.
Sau đó, bạn sẽ tìm thấy một tùy chọn để thêm thông tin đăng nhập. Nhấp vào nó và thêm thông tin đăng nhập.
Thêm thông tin đăng nhập Tomcat, hãy xem ảnh chụp màn hình bên dưới.
Nhấp vào OK.
Bây giờ trong Cấu hình dự án của bạn, hãy thêm thông tin đăng nhập tomcat mà bạn đã chèn ở bước trước.
Nhấp vào Lưu và sau đó chọn Xây dựng ngay.
Truy cập URL tomcat của bạn, với đường dẫn ngữ cảnh, trong trường hợp của tôi là http: // localhost: 8081. Bây giờ hãy thêm đường dẫn ngữ cảnh vào cuối cùng, hãy xem xét Ảnh chụp màn hình bên dưới:
Liên kết - http: // localhost: 8081 / gof
Tôi hy vọng bạn đã hiểu ý nghĩa của đường dẫn ngữ cảnh.
Bây giờ tạo chế độ xem đường ống, hãy xem xét ảnh chụp màn hình bên dưới:
Nhấp vào biểu tượng dấu cộng, để tạo một dạng xem mới.
Định cấu hình đường ống theo cách bạn muốn, hãy xem ảnh chụp màn hình bên dưới:
Tôi không thay đổi bất cứ điều gì ngoài việc lựa chọn công việc ban đầu. Vì vậy, đường ống của tôi sẽ bắt đầu từ biên dịch. Dựa trên cách tôi đã cấu hình các công việc khác, sau khi biên dịch thử nghiệm và triển khai sẽ xảy ra.
Cuối cùng, bạn có thể kiểm tra đường ống bằng cách nhấp vào RUN. Sau mỗi năm phút, nếu có sự thay đổi trong mã nguồn, toàn bộ đường dẫn sẽ được thực thi.
Vì vậy, chúng tôi có thể liên tục triển khai ứng dụng của mình trên máy chủ thử nghiệm để kiểm tra sự chấp nhận của người dùng (UAT).
Tôi hy vọng bạn đã thích đọc bài đăng này trên Giao hàng liên tục. Nếu bạn có bất kỳ nghi ngờ nào, đừng ngại để chúng trong phần bình luận bên dưới và tôi sẽ liên hệ lại với câu trả lời sớm nhất.
Để xây dựng đường ống CI / CD, bạn cần phải thành thạo nhiều loại kỹ năng Nắm vững các kỹ năng DevOps cần thiết ngay bây giờ