Test automation (Part I)
Phần mềm đang là lĩnh vực “hot” hiện nay, nó hiện diện khắp nơi trong cuộc sống và phát triển với tốc độ chóng mặt. Sự phát triển không ngừng của phần mềm đã đặt ra những thách thức không nhỏ với các lập trình viên cùng với những quy trình phần mềm truyền thống. Làm thế nào để phát ...
Phần mềm đang là lĩnh vực “hot” hiện nay, nó hiện diện khắp nơi trong cuộc sống và phát triển với tốc độ chóng mặt. Sự phát triển không ngừng của phần mềm đã đặt ra những thách thức không nhỏ với các lập trình viên cùng với những quy trình phần mềm truyền thống. Làm thế nào để phát triển phần mềm với một cách liên tục, mượt mà trong khi vẫn đảm bảo chất lượng sản phẩm là một yêu cầu cấp thiết. Sự ra đời của Test automation - Continuous Integration/Continuous Development/Continuous Delivery (CI-CD) là một phần của giải pháp
Các thuật ngữ liên quan ở đây là “Continuous Integration” và “Continuous Deployment” được viết tắt là CI/CD. Ban đầu Continuous Integration (Tích hợp liên tục) có nghĩa là bạn chạy “integration tests” mỗi khi code thay đổi; trong khi Continuous Delivery (Phát hành liên tục) nghĩa là bạn tự động phát hành mọi sự thay đổi mà qua được các test. Tuy nhiên gần đây thuật ngữ CI/CD được sử dụng với một nghĩa rộng hơn để diễn tả mọi thứ liên quan đến “automation of the pipeline” từ khi một lập trình viên thêm một thay đổi vào một central repository đến khi đoạn code nằm ở production.
Continuous Integration (CI)
- Là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. nhằm liên tục tích hợp phần tăng trưởng được tạo ra vào sản phẩm giúp kiểm soát tình hình thông qua thực hiện kiểm thử (đặc biệt là integration test, regession test) để đảm bảo code của toàn dự án luôn build được, luôn chạy đúng (Pass toàn bộ các test case) và khiến sản phẩm đạt sự ổn định. Đây là một kỹ thuật / công cụ được thực hiện trong giai đoạn phát triển (development).
Continuous Delivery (CD)
- Giống như CI là một tập hợp những kỹ thuật / công cụ đảm bảo việc triển khai (deployment) được thành công bằng việc liên tục chuyển giao (delivery) những phần tích hợp lên môi trường staging (thường là rất giống với môi trường production). Bằng việc liên tục kiểm thử trong môi trường staging, phần mềm đảm bảo đủ chất lượng để deploy qua production; những deployable artifact này vẫn chỉ tồn tại trên staging và không được deploy tự động qua production.
Continuous Deployment (CD)
- Đúng như tên gọi, là một tập hợp những kỹ thuật / công cụ đảm bảo việc tự động hoá toàn bộ quá trình từ development đến production. Continuous Deployment được coi là bước phát triển của Continuous Delivery, hoàn tất giai đoạn chuyển giao đến người dùng cuối.
Continuous Delivery hay Continuous Deployment?
- Tóm lại là Continuous Delivery và Continuous Deployment khác gì nhau? Rất nhiều người vẫn bị nhập nhằng giữa 2 nguyên tắc này. Lý do là: nếu staging là môi trường giống với production, thì khi đã làm được Continuous Delivery thì đương nhiên chúng ta cũng làm được Continuous Deployment (đều là deploy qua 1 môi trường, vậy thôi). Đúng! Về mặt kỹ thuật là như vậy. Vì vậy, những công cụ như Pupet, Octopus, Ansible, Drone… đều được sử dụng cho CD (còn ai hiểu CD là gì thì tuỳ ngữ cảnh, deploy tới staging thì là Delivery, deploy tới production thì là Deployment). Nhưng công cụ không phải thứ quan trọng nhất.
- Thứ nhất, staging không phải production. Dù chỉ cần 1 cấu hình đơn giản là artifact được deploy qua bất cứ đâu. Nhưng chúng ta có đủ “tự tin” để việc deploy qua production được thực hiện tự động?
- Thứ hai, staging vẫn không phải là production. Production luôn cần ổn định và mong muốn zero-down-time, staging thì không cần thiết.
- Và với những single-user-app như ứng dụng chạy trên PC, mobile… thì khá dễ dàng hơn, tôi không bàn tới. Với web app, chúng ta thường dè dặt trong việc triển khai Continuous Deployment vì những lý do trên.
Tổng quan thì CI/CD thường gồm các bước sau:
- Commit: Khi lập trình viên hoàn thành một thay đổi thì anh ta sẽ commit thay đổi đó vào một source code repository
- Build: Thay đổi được lấy ra từ repository và sau đó phần mềm được build để có thể chạy trên máy tính. Bước này phụ thuộc vào ngôn ngữ nào được dùng, đối với các ngôn ngữ phiên dịch (interpreted languages) thì bước này có thể được loại bỏ.
- Automated tests: Đây là phần chính của CI/CD. Các thay đổi được test ở nhiều góc độ để đảm bảo nó hoạt động và không làm hại đến những phần khác.
- Deploy: Phiên bản đã được build sẽ được đưa lên production.
Kết luận
- Càng phát triển thì mức độ tự động hóa cho quy trình phát triển phần mềm phải đạt mức cao nhất. Mức cao nhất ở thời điểm hiện tại của tự động hoá là một commit đơn lẻ từ một lập trình viên sẽ được tự động chuyển thành một update lên production sau vài giờ.
- Có một số công cụ dành cho việc tự động hoá CI/CD, bao gồm các giải pháp tích hợp sẵn như Cloudbees và Atlassian Bamboo và công cụ(source) riêng lẻ như Jenkins, Travis CI và Teamcity.
- Ở bài này tôi đã tổng quan đôi chút về khái niệm CI/CD, hi vọng nó sẽ giúp một số bạn mới tìm hiểu sẽ có thêm thông tin hữu ích về nó. Ở phần tiếp theo tôi sẽ giới thiệu, cách triển khai của một số công cụ như: Jenkins hay Travis CI để chúng ta có thể áp dụng ngay vào source của mình.
- Bài viết này được tổng hợp và dịch từ một số nguồn. Có thể chưa được chi tiết nên mong mọi người sẽ góp ý thêm.
Nguồn:
- https://www.martinfowler.com/articles/continuousIntegration.html
- https://www.ibm.com/developerworks/vn/library/rational/201301/continuous-integration-agile-development/continuous-integration-agile-development-pdf.pdf
- https://techmaster.vn/posts/33895/devops
- https://dammecode.wordpress.com/2017/02/13/cicd/