Phần 1: Web/Android
Ghi: bài viết này là bản dịch sang tiếng Nga của bài viết gốc Tuy nhiên, tất cả các hình ảnh minh họa, liên kết, trích dẫn và thuật ngữ đều được giữ nguyên bằng ngôn ngữ gốc để tránh làm sai lệch ý nghĩa khi dịch sang tiếng Nga. Chúc các bạn học tập vui vẻ!
Hiện tại, chuyên ngành DevOps là một trong những chuyên ngành có nhu cầu cao nhất trong ngành CNTT. Nếu bạn mở các trang tìm kiếm việc làm phổ biến và lọc theo mức lương, bạn sẽ thấy các công việc liên quan đến DevOps nằm ở đầu danh sách. Tuy nhiên, điều quan trọng là phải hiểu rằng điều này chủ yếu đề cập đến vị trí 'Cấp cao', ngụ ý rằng ứng viên có trình độ kỹ năng, kiến thức cao về công nghệ và công cụ. Điều này cũng đi kèm với mức độ trách nhiệm cao liên quan đến hoạt động sản xuất không bị gián đoạn. Tuy nhiên, chúng tôi bắt đầu quên DevOps là gì. Ban đầu, đó không phải là một cá nhân hay bộ phận cụ thể nào cả. Nếu tìm định nghĩa cho thuật ngữ này, chúng ta sẽ tìm thấy nhiều danh từ hay và đúng như phương pháp luận, thực tiễn, triết học văn hóa, nhóm khái niệm, v.v.
Chuyên môn của tôi là kỹ sư tự động hóa thử nghiệm (kỹ sư tự động hóa QA), nhưng tôi tin rằng nó không nên chỉ gắn với việc viết các bài kiểm tra tự động hoặc phát triển kiến trúc khung kiểm tra. Năm 2020, kiến thức về cơ sở hạ tầng tự động hóa cũng rất cần thiết. Điều này cho phép bạn tự tổ chức quy trình tự động hóa, từ chạy thử nghiệm đến cung cấp kết quả cho tất cả các bên liên quan theo mục tiêu của bạn. Do đó, kỹ năng DevOps là điều bắt buộc để hoàn thành công việc. Và tất cả điều này đều tốt, nhưng thật không may, có một vấn đề (spoiler: bài viết này cố gắng đơn giản hóa vấn đề này). Vấn đề là DevOps rất khó. Và điều này là hiển nhiên, bởi vì các công ty sẽ không trả nhiều tiền cho những việc dễ làm... Trong thế giới DevOps, có một số lượng lớn các công cụ, thuật ngữ và phương pháp thực hành cần phải thành thạo. Điều này đặc biệt khó khăn khi mới bắt đầu sự nghiệp và phụ thuộc vào kinh nghiệm kỹ thuật tích lũy được.
Nguồn:
Ở đây chúng ta có thể sẽ kết thúc với phần giới thiệu và tập trung vào mục đích của bài viết này.
Bài báo này viết về vấn đề gì vậy?
Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm xây dựng cơ sở hạ tầng tự động hóa thử nghiệm. Có rất nhiều nguồn thông tin trên Internet về các công cụ khác nhau và cách sử dụng chúng, nhưng tôi muốn xem xét chúng hoàn toàn trong bối cảnh tự động hóa. Tôi tin rằng nhiều kỹ sư tự động hóa đã quen với tình huống không ai ngoại trừ bạn chạy các thử nghiệm đã phát triển hoặc quan tâm đến việc duy trì chúng. Kết quả là các bài kiểm tra trở nên lỗi thời và bạn phải mất thời gian cập nhật chúng. Một lần nữa, khi bắt đầu sự nghiệp, đây có thể là một nhiệm vụ khá khó khăn: quyết định một cách khôn ngoan công cụ nào sẽ giúp loại bỏ một vấn đề nhất định, cách chọn, định cấu hình và duy trì chúng. Một số người thử nghiệm tìm đến DevOps (con người) để được trợ giúp và thành thật mà nói, phương pháp này có hiệu quả. Trong nhiều trường hợp, đây có thể là lựa chọn duy nhất vì chúng tôi không có khả năng hiển thị tất cả các phần phụ thuộc. Nhưng như chúng ta biết, DevOps là những người rất bận rộn, vì họ phải suy nghĩ về toàn bộ cơ sở hạ tầng, việc triển khai, giám sát, dịch vụ vi mô và các nhiệm vụ tương tự khác tùy thuộc vào tổ chức/nhóm. Như thường lệ, tự động hóa không phải là ưu tiên hàng đầu. Trong trường hợp như vậy, chúng ta phải cố gắng làm mọi thứ có thể từ đầu đến cuối. Điều này sẽ giảm bớt sự phụ thuộc, tăng tốc quy trình làm việc, cải thiện kỹ năng của chúng tôi và cho phép chúng tôi nhìn thấy bức tranh toàn cảnh hơn về những gì đang xảy ra.
Bài viết trình bày các công cụ phổ biến, phổ biến nhất và hướng dẫn cách sử dụng chúng để xây dựng cơ sở hạ tầng tự động hóa từng bước. Mỗi nhóm được đại diện bởi các công cụ đã được thử nghiệm thông qua kinh nghiệm cá nhân. Nhưng điều đó không có nghĩa là bạn phải sử dụng điều tương tự. Bản thân các công cụ không quan trọng, chúng xuất hiện và trở nên lỗi thời. Nhiệm vụ kỹ thuật của chúng tôi là hiểu các nguyên tắc cơ bản: tại sao chúng tôi cần nhóm công cụ này và những vấn đề công việc nào chúng tôi có thể giải quyết với sự trợ giúp của chúng. Đó là lý do tại sao ở cuối mỗi phần, tôi để lại liên kết đến các công cụ tương tự có thể được sử dụng trong tổ chức của bạn.
Những gì không có trong bài viết này
Tôi nhắc lại một lần nữa rằng bài viết không nói về các công cụ cụ thể nên sẽ không có phần chèn mã nào từ tài liệu và mô tả các lệnh cụ thể. Nhưng cuối mỗi phần tôi đều để lại link nghiên cứu chi tiết.
Điều này được thực hiện bởi vì:
- tài liệu này rất dễ tìm thấy ở nhiều nguồn khác nhau (tài liệu, sách, khóa học video);
- nếu bắt đầu đi sâu hơn, chúng ta sẽ phải viết 10, 20, 30 phần của bài viết này (trong khi kế hoạch là 2-3);
- Tôi chỉ không muốn lãng phí thời gian của bạn vì bạn có thể muốn sử dụng các công cụ khác để đạt được mục tiêu tương tự.
Tập luyện
Tôi thực sự mong muốn tài liệu này hữu ích cho mọi độc giả chứ không chỉ đọc rồi quên. Trong bất kỳ nghiên cứu nào, thực hành là một thành phần rất quan trọng. Đối với điều này tôi đã chuẩn bị. Ngoài ra còn có bài tập về nhà đang chờ bạn để đảm bảo rằng bạn không vô tâm sao chép các dòng lệnh bạn đang thực thi.
kế hoạch
Bước
Công nghệ
CÔNG CỤ
1
Chạy cục bộ (chuẩn bị thử nghiệm demo web / android và chạy cục bộ)
Node.js, Selenium, Appium
2
Hệ thống kiểm soát phiên bản
đi
3
container hóa
Docker, lưới Selenium, Selenoid (Web, Android)
4
CI/CD
CI Gitlab
5
Nền tảng đám mây
Google Cloud Platform
6
Dàn nhạc
Kubernetes
7
Cơ sở hạ tầng dưới dạng mã (IaC)
Địa hình, Ansible
Cấu trúc từng phần
Để giữ cho câu chuyện rõ ràng, mỗi phần được mô tả theo dàn ý sau:
- mô tả ngắn gọn về công nghệ,
- giá trị cho cơ sở hạ tầng tự động hóa,
- minh họa hiện trạng cơ sở hạ tầng,
- liên kết để nghiên cứu,
- công cụ tương tự.
1. Chạy thử nghiệm cục bộ
Mô tả ngắn gọn về công nghệ
Đây chỉ là bước chuẩn bị để chạy thử nghiệm demo cục bộ và xác minh rằng chúng vượt qua. Trong phần thực tế, Node.js được sử dụng, nhưng ngôn ngữ lập trình và nền tảng cũng không quan trọng và bạn có thể sử dụng những ngôn ngữ được sử dụng trong công ty của mình.
Tuy nhiên, với tư cách là công cụ tự động hóa, tôi khuyên bạn nên sử dụng Selenium WebDriver cho nền tảng web và Appium cho nền tảng Android, vì trong các bước tiếp theo, chúng tôi sẽ sử dụng hình ảnh Docker được điều chỉnh để hoạt động cụ thể với các công cụ này. Hơn nữa, đề cập đến yêu cầu công việc, những công cụ này đang có nhu cầu cao nhất trên thị trường.
Như bạn có thể đã nhận thấy, chúng tôi chỉ xem xét các bài kiểm tra trên web và Android. Thật không may, iOS lại là một câu chuyện hoàn toàn khác (cảm ơn Apple). Tôi dự định giới thiệu các giải pháp và thực tiễn liên quan đến iOS trong các phần sắp tới.
Giá trị cho cơ sở hạ tầng tự động hóa
Từ góc độ cơ sở hạ tầng, việc chạy cục bộ không mang lại bất kỳ giá trị nào. Bạn chỉ kiểm tra xem các bài kiểm tra có chạy trên máy cục bộ trong trình duyệt và trình mô phỏng cục bộ hay không. Nhưng trong mọi trường hợp, đây là điểm khởi đầu cần thiết.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá
Công cụ tương tự
- bất kỳ ngôn ngữ lập trình nào bạn thích kết hợp với các bài kiểm tra Selenium/Appium;
- bất kỳ bài kiểm tra nào;
- bất kỳ người chạy thử nghiệm nào.
2. Hệ thống kiểm soát phiên bản (Git)
Mô tả ngắn gọn về công nghệ
Sẽ không phải là một tiết lộ lớn đối với bất kỳ ai nếu tôi nói rằng kiểm soát phiên bản là một phần cực kỳ quan trọng trong quá trình phát triển, cả trong một nhóm và cá nhân. Dựa trên nhiều nguồn khác nhau, có thể nói rằng Git là đại diện phổ biến nhất. Hệ thống kiểm soát phiên bản mang lại nhiều lợi ích, chẳng hạn như chia sẻ mã, lưu trữ phiên bản, khôi phục về các nhánh trước đó, theo dõi lịch sử dự án và sao lưu. Chúng ta sẽ không thảo luận chi tiết từng điểm vì tôi chắc chắn rằng bạn rất quen thuộc với nó và sử dụng nó trong công việc hàng ngày. Nhưng nếu đột nhiên không, thì tôi khuyên bạn nên tạm dừng đọc bài viết này và lấp đầy khoảng trống này càng sớm càng tốt.
Giá trị cho cơ sở hạ tầng tự động hóa
Và ở đây bạn có thể đặt một câu hỏi hợp lý: “Tại sao anh ấy lại nói với chúng tôi về Git? Mọi người đều biết điều này và sử dụng nó cho cả mã phát triển và mã kiểm tra tự động.” Bạn sẽ hoàn toàn đúng, nhưng trong bài viết này chúng ta đang nói về cơ sở hạ tầng và phần này đóng vai trò là bản xem trước cho phần 7: “Cơ sở hạ tầng dưới dạng mã (IaC)”. Đối với chúng tôi, điều này có nghĩa là toàn bộ cơ sở hạ tầng, bao gồm cả thử nghiệm, được mô tả dưới dạng mã, vì vậy chúng tôi cũng có thể áp dụng hệ thống tạo phiên bản cho nó và nhận được các lợi ích tương tự như đối với mã phát triển và tự động hóa.
Chúng ta sẽ xem xét IaC chi tiết hơn ở Bước 7, nhưng ngay cả bây giờ bạn vẫn có thể bắt đầu sử dụng Git cục bộ bằng cách tạo một kho lưu trữ cục bộ. Bức tranh lớn sẽ được mở rộng khi chúng ta thêm kho lưu trữ từ xa vào cơ sở hạ tầng.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá
Công cụ tương tự
3. Container hóa (Docker)
Mô tả ngắn gọn về công nghệ
Để chứng minh việc container hóa đã thay đổi luật chơi như thế nào, chúng ta hãy quay ngược thời gian về vài thập kỷ. Hồi đó, người ta mua và sử dụng máy chủ để chạy ứng dụng. Nhưng trong hầu hết các trường hợp, nguồn lực khởi động cần thiết không được biết trước. Kết quả là, các công ty đã chi tiền để mua các máy chủ mạnh mẽ, đắt tiền nhưng một phần công suất này vẫn chưa được tận dụng hết.
Giai đoạn phát triển tiếp theo là máy ảo (VM), giải quyết vấn đề lãng phí tiền vào các tài nguyên không được sử dụng. Công nghệ này cho phép chạy các ứng dụng độc lập với nhau trong cùng một máy chủ, phân bổ không gian hoàn toàn biệt lập. Nhưng thật không may, bất kỳ công nghệ nào cũng có nhược điểm của nó. Việc chạy VM yêu cầu một hệ điều hành đầy đủ, tiêu tốn CPU, RAM, bộ nhớ và tùy thuộc vào hệ điều hành, cần phải tính đến chi phí giấy phép. Những yếu tố này ảnh hưởng đến tốc độ tải và gây khó khăn cho việc di chuyển.
Và bây giờ chúng ta đến với việc container hóa. Một lần nữa, công nghệ này giải quyết được vấn đề trước đó, vì các container không sử dụng hệ điều hành đầy đủ, giúp giải phóng một lượng lớn tài nguyên và cung cấp giải pháp nhanh chóng và linh hoạt cho tính di động.
Tất nhiên, công nghệ container hóa không có gì mới và được giới thiệu lần đầu tiên vào cuối những năm 70. Vào thời đó, rất nhiều nghiên cứu, phát triển và nỗ lực đã được thực hiện. Nhưng chính Docker đã điều chỉnh công nghệ này và giúp đại chúng dễ dàng tiếp cận nó. Ngày nay, khi chúng ta nói về container, trong hầu hết các trường hợp, chúng ta đều muốn nói đến Docker. Khi chúng ta nói về vùng chứa Docker, chúng tôi muốn nói đến vùng chứa Linux. Chúng ta có thể sử dụng hệ thống Windows và macOS để chạy các thùng chứa, nhưng điều quan trọng là phải hiểu rằng trong trường hợp này, một lớp bổ sung sẽ xuất hiện. Ví dụ: Docker trên Mac âm thầm chạy các container bên trong máy ảo Linux nhẹ. Chúng ta sẽ quay lại chủ đề này khi thảo luận về việc chạy trình mô phỏng Android bên trong vùng chứa, vì vậy ở đây có một sắc thái rất quan trọng cần được thảo luận chi tiết hơn.
Giá trị cho cơ sở hạ tầng tự động hóa
Chúng tôi phát hiện ra rằng việc container hóa và Docker rất tuyệt vời. Hãy xem xét điều này trong bối cảnh tự động hóa, bởi vì mọi công cụ hoặc công nghệ đều cần giải quyết một vấn đề. Hãy để chúng tôi phác thảo các vấn đề rõ ràng về tự động hóa thử nghiệm trong bối cảnh thử nghiệm giao diện người dùng:
- một số lượng lớn các phụ thuộc khi cài đặt Selenium và đặc biệt là Appium;
- vấn đề tương thích giữa các phiên bản trình duyệt, trình mô phỏng và trình điều khiển;
- thiếu không gian biệt lập cho trình duyệt/trình mô phỏng, điều này đặc biệt quan trọng khi chạy song song;
- khó quản lý và bảo trì nếu bạn cần chạy 10, 50, 100 hoặc thậm chí 1000 trình duyệt cùng một lúc.
Nhưng vì Selenium là công cụ tự động hóa phổ biến nhất và Docker là công cụ container hóa phổ biến nhất nên không có gì ngạc nhiên khi ai đó đã cố gắng kết hợp chúng để tạo ra một công cụ mạnh mẽ nhằm giải quyết các vấn đề nêu trên. Hãy xem xét các giải pháp như vậy chi tiết hơn.
Lưới Selenium trong docker
Công cụ này phổ biến nhất trong thế giới Selenium để chạy nhiều trình duyệt trên nhiều máy và quản lý chúng từ một trung tâm. Để bắt đầu, bạn cần đăng ký ít nhất 2 phần: Hub và Node(s). Hub là nút trung tâm nhận tất cả các yêu cầu từ các thử nghiệm và phân phối chúng đến các Nút thích hợp. Đối với mỗi Nút, chúng ta có thể định cấu hình một cấu hình cụ thể, chẳng hạn bằng cách chỉ định trình duyệt mong muốn và phiên bản của nó. Tuy nhiên, chúng ta vẫn cần tự mình chăm sóc các trình điều khiển trình duyệt tương thích và cài đặt chúng trên các Nút mong muốn. Vì lý do này, lưới Selenium không được sử dụng ở dạng thuần túy, ngoại trừ khi chúng ta cần làm việc với các trình duyệt không thể cài đặt trên HĐH Linux. Đối với tất cả các trường hợp khác, một giải pháp chính xác và linh hoạt đáng kể sẽ là sử dụng hình ảnh Docker để chạy Hub và Nút lưới Selenium. Cách tiếp cận này giúp đơn giản hóa đáng kể việc quản lý nút, vì chúng tôi có thể chọn hình ảnh mình cần với các phiên bản trình duyệt và trình điều khiển tương thích đã được cài đặt.
Bất chấp những đánh giá tiêu cực về tính ổn định, đặc biệt là khi chạy song song một số lượng lớn Nút, lưới Selenium vẫn là công cụ phổ biến nhất để chạy song song các thử nghiệm Selenium. Điều quan trọng cần lưu ý là các cải tiến và sửa đổi khác nhau của công cụ này liên tục xuất hiện trong nguồn mở, giúp giải quyết các tắc nghẽn khác nhau.
Selenoid cho Web
Công cụ này là một bước đột phá trong thế giới Selenium vì nó hoạt động ngay lập tức và giúp cuộc sống của nhiều kỹ sư tự động hóa trở nên dễ dàng hơn nhiều. Trước hết, đây không phải là một sửa đổi khác của lưới Selenium. Thay vào đó, các nhà phát triển đã tạo ra một phiên bản hoàn toàn mới của Selenium Hub ở Golang, kết hợp với hình ảnh Docker nhẹ cho nhiều trình duyệt khác nhau, đã tạo động lực cho sự phát triển của tự động hóa thử nghiệm. Hơn nữa, trong trường hợp của Selenium Grid, chúng ta phải xác định trước tất cả các trình duyệt được yêu cầu và phiên bản của chúng, điều này không thành vấn đề khi chỉ làm việc với một trình duyệt. Nhưng khi nói đến nhiều trình duyệt được hỗ trợ, Selenoid là giải pháp số một nhờ tính năng “trình duyệt theo yêu cầu”. Tất cả những gì chúng tôi yêu cầu là tải xuống trước các hình ảnh cần thiết bằng trình duyệt và cập nhật tệp cấu hình mà Selenoid tương tác. Sau khi Selenoid nhận được yêu cầu từ các cuộc kiểm tra, nó sẽ tự động khởi chạy vùng chứa mong muốn với trình duyệt mong muốn. Khi quá trình thử nghiệm hoàn tất, Selenoid sẽ gỡ bỏ vùng chứa, từ đó giải phóng tài nguyên cho các yêu cầu trong tương lai. Cách tiếp cận này loại bỏ hoàn toàn vấn đề nổi tiếng về 'suy thoái nút' mà chúng ta thường gặp phải trong lưới Selenium.
Nhưng than ôi, Selenoid vẫn không phải là viên đạn bạc. Chúng tôi đã có tính năng 'trình duyệt theo yêu cầu' nhưng tính năng 'tài nguyên theo yêu cầu' vẫn chưa khả dụng. Để sử dụng Selenoid, chúng ta phải triển khai nó trên phần cứng vật lý hoặc trên VM, nghĩa là chúng ta phải biết trước cần phân bổ bao nhiêu tài nguyên. Tôi đoán đây không phải là vấn đề đối với các dự án nhỏ chạy song song 10, 20 hoặc thậm chí 30 trình duyệt. Nhưng nếu chúng ta cần 100, 500, 1000 và hơn thế nữa thì sao? Thật vô nghĩa khi phải duy trì và trả tiền cho nhiều tài nguyên như vậy mọi lúc. Trong phần 5 và 6 của bài viết này, chúng ta sẽ thảo luận về các giải pháp cho phép bạn mở rộng quy mô, từ đó giảm đáng kể chi phí của công ty.
Selenoid cho Android
Sau thành công của Selenoid với tư cách là một công cụ tự động hóa web, mọi người muốn một thứ gì đó tương tự dành cho Android. Và điều đó đã xảy ra - Selenoid được phát hành với sự hỗ trợ của Android. Từ quan điểm của người dùng cấp cao, nguyên tắc hoạt động tương tự như tự động hóa web. Điểm khác biệt duy nhất là thay vì các vùng chứa trình duyệt, Selenoid chạy các vùng chứa trình mô phỏng Android. Theo tôi, đây hiện là công cụ miễn phí mạnh mẽ nhất để chạy song song các thử nghiệm Android.
Tôi thực sự không muốn nói về những khía cạnh tiêu cực của công cụ này, vì tôi thực sự thích nó. Tuy nhiên, vẫn có những nhược điểm tương tự áp dụng cho tự động hóa web và liên quan đến việc mở rộng quy mô. Ngoài ra, chúng ta cần nói về một hạn chế nữa có thể gây ngạc nhiên nếu chúng ta thiết lập công cụ này lần đầu tiên. Để chạy hình ảnh Android, chúng ta cần một máy vật lý hoặc VM có hỗ trợ ảo hóa lồng nhau. Trong hướng dẫn cách thực hiện, tôi trình bày cách kích hoạt tính năng này trên máy ảo Linux. Tuy nhiên, nếu bạn là người dùng macOS và muốn triển khai Selenoid cục bộ thì điều này sẽ không thể chạy thử nghiệm Android. Nhưng bạn luôn có thể chạy máy ảo Linux cục bộ với cấu hình 'ảo hóa lồng nhau' và triển khai Selenoid bên trong.
Minh họa hiện trạng cơ sở hạ tầng
Trong khuôn khổ bài viết này, chúng tôi sẽ bổ sung thêm 2 công cụ để minh họa cơ sở hạ tầng. Đây là lưới Selenium dành cho thử nghiệm web và Selenoid dành cho thử nghiệm Android. Trong hướng dẫn GitHub, tôi cũng sẽ chỉ cho bạn cách sử dụng Selenoid để chạy thử nghiệm web.
Liên kết để khám phá
Công cụ tương tự
- Có các công cụ container hóa khác, nhưng Docker là công cụ phổ biến nhất. Nếu bạn muốn thử cách khác, hãy nhớ rằng các công cụ mà chúng tôi đã đề cập để chạy song song các thử nghiệm Selenium sẽ không hoạt động ngay lập tức.
- Như đã nói, có nhiều sửa đổi của lưới Selenium, ví dụ:.
4.CI/CD
Mô tả ngắn gọn về công nghệ
Việc thực hành tích hợp liên tục khá phổ biến trong quá trình phát triển và ngang bằng với các hệ thống kiểm soát phiên bản. Mặc dù vậy, tôi cảm thấy có sự nhầm lẫn trong thuật ngữ. Trong đoạn này tôi muốn mô tả 3 sửa đổi của công nghệ này theo quan điểm của tôi. Trên internet, bạn sẽ tìm thấy nhiều bài viết có cách hiểu khác nhau và việc bạn có quan điểm khác nhau là điều hoàn toàn bình thường. Điều quan trọng nhất là bạn ở cùng quan điểm với đồng nghiệp của mình.
Vì vậy, có 3 thuật ngữ: CI - Tích hợp liên tục, CD - Phân phối liên tục và lại CD - Triển khai liên tục. (Dưới đây tôi sẽ sử dụng các thuật ngữ này bằng tiếng Anh). Mỗi sửa đổi sẽ thêm một số bước bổ sung vào quy trình phát triển của bạn. Nhưng từ liên tục (tiếp) là điều quan trọng nhất. Trong ngữ cảnh này, chúng tôi muốn nói đến điều gì đó xảy ra từ đầu đến cuối mà không bị gián đoạn hoặc can thiệp thủ công. Hãy nhìn vào CI & CD và CD trong bối cảnh này.
- Hội nhập liên tục đây là bước đầu tiên của quá trình tiến hóa. Sau khi gửi mã mới đến máy chủ, chúng tôi mong nhận được phản hồi nhanh chóng rằng những thay đổi của chúng tôi vẫn ổn. Thông thường, CI bao gồm việc chạy các công cụ phân tích mã tĩnh và kiểm tra API đơn vị/nội bộ. Điều này cho phép chúng tôi lấy thông tin về mã của mình trong vòng vài giây/phút.
- Giao hàng liên tục là bước nâng cao hơn nơi chúng tôi chạy thử nghiệm tích hợp/giao diện người dùng. Tuy nhiên, ở giai đoạn này chúng ta không nhận được kết quả nhanh chóng như với CI. Đầu tiên, những loại bài kiểm tra này mất nhiều thời gian hơn để hoàn thành. Thứ hai, trước khi khởi chạy, chúng tôi phải triển khai các thay đổi của mình đối với môi trường thử nghiệm/dàn dựng. Hơn nữa, nếu chúng ta đang nói về phát triển thiết bị di động, thì một bước bổ sung sẽ xuất hiện để tạo bản dựng ứng dụng của chúng ta.
- Triển khai liên tục giả định rằng chúng tôi tự động đưa ra các thay đổi trong quá trình sản xuất nếu tất cả các thử nghiệm chấp nhận đã được vượt qua ở các giai đoạn trước. Ngoài ra, sau giai đoạn phát hành, bạn có thể định cấu hình các giai đoạn khác nhau, chẳng hạn như chạy thử nghiệm khói trong quá trình sản xuất và thu thập số liệu quan tâm. Triển khai liên tục chỉ có thể thực hiện được khi có phạm vi bao phủ tốt bằng các thử nghiệm tự động. Nếu cần có bất kỳ sự can thiệp thủ công nào, bao gồm cả việc kiểm tra, thì việc này không còn nữa liên tiếp (tiếp diễn). Sau đó, chúng tôi có thể nói rằng quy trình của chúng tôi chỉ tuân thủ thông lệ Phân phối liên tục.
Giá trị cho cơ sở hạ tầng tự động hóa
Trong phần này, tôi nên làm rõ rằng khi chúng ta nói về kiểm thử giao diện người dùng toàn diện, điều đó có nghĩa là chúng ta nên triển khai các thay đổi và dịch vụ liên quan của mình vào môi trường kiểm thử. Tích hợp liên tục - quy trình này không thể áp dụng cho nhiệm vụ này và chúng tôi phải quan tâm đến việc triển khai ít nhất các phương pháp Phân phối liên tục. Triển khai liên tục cũng có ý nghĩa trong bối cảnh kiểm thử giao diện người dùng nếu chúng ta định chạy chúng trong sản xuất.
Và trước khi chúng ta xem hình minh họa về sự thay đổi kiến trúc, tôi muốn nói vài lời về GitLab CI. Không giống như các công cụ CI/CD khác, GitLab cung cấp kho lưu trữ từ xa và nhiều tính năng bổ sung khác. Vì vậy, GitLab còn hơn cả CI. Nó bao gồm quản lý mã nguồn, quản lý Agile, quy trình CI/CD, công cụ ghi nhật ký và thu thập số liệu ngay lập tức. Kiến trúc GitLab bao gồm Gitlab CI/CD và GitLab Runner. Đây là một mô tả ngắn từ trang web chính thức:
Gitlab CI/CD là một ứng dụng web có API lưu trữ trạng thái của nó trong cơ sở dữ liệu, quản lý các dự án/bản dựng và cung cấp giao diện người dùng. GitLab Runner là một ứng dụng xử lý các bản dựng. Nó có thể được triển khai riêng và hoạt động với GitLab CI/CD thông qua API. Để chạy thử nghiệm, bạn cần cả phiên bản Gitlab và Runner.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá
Công cụ tương tự
- Và nhiều người khác
5. Nền tảng đám mây
Mô tả ngắn gọn về công nghệ
Trong phần này chúng ta sẽ nói về một xu hướng phổ biến được gọi là 'đám mây công cộng'. Bất chấp những lợi ích to lớn mà công nghệ ảo hóa và container hóa được mô tả ở trên mang lại, chúng ta vẫn cần tài nguyên máy tính. Các công ty mua máy chủ đắt tiền hoặc thuê trung tâm dữ liệu, nhưng trong trường hợp này cần phải tính toán (đôi khi không thực tế) về số lượng tài nguyên chúng ta sẽ cần, liệu chúng ta có sử dụng chúng 24/7 hay không và cho mục đích gì. Ví dụ: sản xuất yêu cầu máy chủ chạy XNUMX/XNUMX, nhưng chúng ta có cần các tài nguyên tương tự để thử nghiệm ngoài giờ làm việc không? Nó cũng phụ thuộc vào loại thử nghiệm đang được thực hiện. Một ví dụ là các bài kiểm tra tải/căng thẳng mà chúng tôi dự định thực hiện ngoài giờ làm việc để có kết quả vào ngày hôm sau. Nhưng chắc chắn tính khả dụng của máy chủ XNUMX/XNUMX là không cần thiết đối với các thử nghiệm tự động từ đầu đến cuối và đặc biệt là không dành cho môi trường thử nghiệm thủ công. Đối với những tình huống như vậy, sẽ là điều tốt nếu bạn có được nhiều tài nguyên cần thiết theo yêu cầu, sử dụng chúng và ngừng thanh toán khi không còn cần thiết nữa. Hơn nữa, sẽ thật tuyệt nếu nhận được chúng ngay lập tức bằng cách thực hiện vài cú click chuột hoặc chạy một vài tập lệnh. Đây là mục đích mà các đám mây công cộng được sử dụng. Chúng ta hãy nhìn vào định nghĩa:
“Đám mây công cộng được định nghĩa là các dịch vụ điện toán được cung cấp bởi các nhà cung cấp bên thứ ba qua Internet công cộng, cung cấp chúng cho bất kỳ ai muốn sử dụng hoặc mua chúng. Chúng có thể miễn phí hoặc được bán theo yêu cầu, cho phép khách hàng chỉ trả tiền cho mỗi lần sử dụng cho chu kỳ CPU, dung lượng lưu trữ hoặc băng thông mà họ tiêu thụ."
Có ý kiến cho rằng đám mây công cộng đắt tiền. Nhưng ý tưởng chính của họ là giảm chi phí công ty. Như đã đề cập trước đó, đám mây công cộng cho phép bạn nhận tài nguyên theo yêu cầu và chỉ trả tiền cho thời gian bạn sử dụng chúng. Ngoài ra, đôi khi chúng ta quên rằng nhân viên được trả lương và các chuyên gia cũng là một nguồn lực đắt giá. Cần phải tính đến việc đám mây công cộng giúp việc hỗ trợ cơ sở hạ tầng dễ dàng hơn nhiều, điều này cho phép các kỹ sư tập trung vào các nhiệm vụ quan trọng hơn.
Giá trị cho cơ sở hạ tầng tự động hóa
Chúng tôi cần những tài nguyên cụ thể nào để kiểm thử giao diện người dùng toàn diện? Về cơ bản đây là các máy hoặc cụm ảo (chúng ta sẽ nói về Kubernetes trong phần tiếp theo) để chạy trình duyệt và trình mô phỏng. Chúng ta càng muốn chạy nhiều trình duyệt và trình giả lập thì càng cần nhiều CPU và bộ nhớ và chúng ta càng phải trả nhiều tiền hơn cho nó. Do đó, các đám mây công cộng trong bối cảnh tự động hóa thử nghiệm cho phép chúng tôi chạy một số lượng lớn (100, 200, 1000...) trình duyệt/trình mô phỏng theo yêu cầu, nhận kết quả thử nghiệm nhanh nhất có thể và ngừng trả tiền cho những thứ tiêu tốn nhiều tài nguyên như vậy. quyền lực.
Các nhà cung cấp đám mây phổ biến nhất là Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Hướng dẫn cách thực hiện cung cấp các ví dụ về cách sử dụng GCP, nhưng nói chung việc bạn sử dụng gì cho các tác vụ tự động hóa không quan trọng. Tất cả đều cung cấp chức năng gần như giống nhau. Thông thường, để chọn nhà cung cấp, ban quản lý tập trung vào cơ sở hạ tầng tổng thể và các yêu cầu kinh doanh của công ty, điều này nằm ngoài phạm vi của bài viết này. Đối với các kỹ sư tự động hóa, sẽ thú vị hơn khi so sánh việc sử dụng các nhà cung cấp đám mây với việc sử dụng các nền tảng đám mây dành riêng cho mục đích thử nghiệm, chẳng hạn như Sauce Labs, BrowserStack, BitBar, v.v. Vậy chúng ta cũng hãy làm điều đó nhé! Theo tôi, Sauce Labs là trang trại thử nghiệm đám mây nổi tiếng nhất, đó là lý do tại sao tôi sử dụng nó để so sánh.
GCP vs Sauce Labs cho mục đích tự động hóa:
Hãy tưởng tượng rằng chúng ta cần chạy đồng thời 8 thử nghiệm web và 8 thử nghiệm Android. Để làm điều này, chúng tôi sẽ sử dụng GCP và chạy 2 máy ảo với Selenoid. Trong lần đầu tiên, chúng tôi sẽ nâng cao 8 vùng chứa bằng trình duyệt. Ngày thứ hai có 8 thùng chứa trình giả lập. Chúng ta hãy xem giá cả:
Để chạy một vùng chứa với Chrome, chúng tôi cần n1-tiêu chuẩn-1 xe hơi. Trong trường hợp của Android, nó sẽ là n1-tiêu chuẩn-4 cho một trình giả lập. Trên thực tế, một cách linh hoạt hơn và rẻ hơn là đặt các giá trị người dùng cụ thể cho CPU/Bộ nhớ, nhưng hiện tại, điều này không quan trọng để so sánh với Sauce Labs.
Và đây là mức phí sử dụng Sauce Labs:
Tôi tin rằng bạn đã nhận thấy sự khác biệt, nhưng tôi vẫn sẽ cung cấp một bảng tính toán cho nhiệm vụ của chúng ta:
Nguồn lực cần thiết
hàng tháng
Giờ làm việc(8 giờ sáng - 8 giờ tối)
Giờ làm việc+ Được ưu tiên
GCP cho Web
n1-tiêu chuẩn-1 x 8 = n1-tiêu chuẩn-8
$194.18
23 ngày * 12 giờ * 0.38 = 104.88 USD
23 ngày * 12 giờ * 0.08 = 22.08 USD
Phòng thí nghiệm nước sốt cho web
Thử nghiệm song song Virtual Cloud8
$1.559
-
-
GCP cho Android
n1-tiêu chuẩn-4 x 8: n1-tiêu chuẩn-16
$776.72
23 ngày * 12 giờ * 1.52 = 419.52 USD
23 ngày * 12 giờ * 0.32 = 88.32 USD
Phòng thí nghiệm nước sốt cho Android
Thử nghiệm song song trên Real Device Cloud 8
$1.999
-
-
Như bạn có thể thấy, sự khác biệt về chi phí là rất lớn, đặc biệt nếu bạn chỉ chạy thử nghiệm trong khoảng thời gian làm việc XNUMX giờ. Nhưng bạn có thể cắt giảm chi phí hơn nữa nếu bạn sử dụng máy móc có sẵn. Nó là gì?
Máy ảo có thể mua trước là một phiên bản mà bạn có thể tạo và chạy với mức giá thấp hơn nhiều so với các phiên bản thông thường. Tuy nhiên, Công cụ tính toán có thể chấm dứt (ưu tiên) các trường hợp này nếu nó yêu cầu quyền truy cập vào các tài nguyên đó cho các tác vụ khác. Các phiên bản được ưu tiên sử dụng có dung lượng vượt quá của Công cụ Điện toán nên tính khả dụng của chúng thay đổi tùy theo mức sử dụng.
Nếu ứng dụng của bạn có khả năng chịu lỗi và có thể chịu được các trường hợp ưu tiên phiên bản có thể xảy ra thì các phiên bản ưu tiên có thể giảm đáng kể chi phí Công cụ Điện toán của bạn. Ví dụ: công việc xử lý hàng loạt có thể chạy trên các phiên bản được ưu tiên trước. Nếu một số trường hợp đó chấm dứt trong quá trình xử lý, công việc sẽ chậm lại nhưng không dừng hoàn toàn. Các phiên bản được ưu tiên hoàn thành nhiệm vụ xử lý hàng loạt của bạn mà không cần đặt thêm khối lượng công việc lên các phiên bản hiện có của bạn và không yêu cầu bạn phải trả toàn bộ giá cho các phiên bản thông thường bổ sung.
Và nó vẫn chưa kết thúc! Trên thực tế, tôi chắc chắn rằng không ai chạy thử nghiệm suốt 12 giờ mà không nghỉ ngơi. Và nếu vậy thì bạn có thể tự động khởi động và dừng các máy ảo khi không cần thiết. Thời gian sử dụng thực tế có thể giảm xuống còn 6 giờ mỗi ngày. Sau đó, khoản thanh toán trong bối cảnh nhiệm vụ của chúng tôi sẽ giảm xuống còn 11 USD mỗi tháng cho 8 trình duyệt. Điều này thật tuyệt vời phải không? Nhưng với các máy có quyền ưu tiên trước, chúng ta phải cẩn thận và chuẩn bị cho sự gián đoạn và mất ổn định, mặc dù những tình huống này có thể được cung cấp và xử lý trong phần mềm. Nó đáng giá!
Nhưng không có nghĩa là tôi đang nói 'không bao giờ sử dụng trang trại thử nghiệm trên đám mây'. Họ có một số lợi thế. Trước hết, đây không chỉ là một máy ảo mà còn là một giải pháp tự động hóa thử nghiệm hoàn chỉnh với một bộ chức năng sẵn có: truy cập từ xa, nhật ký, ảnh chụp màn hình, quay video, nhiều trình duyệt và thiết bị di động vật lý khác nhau. Trong nhiều tình huống, đây có thể là một sự thay thế sang trọng cần thiết. Nền tảng thử nghiệm đặc biệt hữu ích cho việc tự động hóa iOS, khi các đám mây công cộng chỉ có thể cung cấp hệ thống Linux/Windows. Nhưng chúng ta sẽ nói về iOS trong các bài viết sau. Tôi khuyên bạn nên luôn xem xét tình hình và bắt đầu từ các nhiệm vụ: trong một số trường hợp, việc sử dụng các đám mây công cộng sẽ rẻ hơn và hiệu quả hơn, còn trong những trường hợp khác, nền tảng thử nghiệm chắc chắn xứng đáng với số tiền bỏ ra.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá
Công cụ tương tự:
6. Hòa âm
Mô tả ngắn gọn về công nghệ
Tôi có tin tốt – chúng ta đã gần kết thúc bài viết! Hiện tại, cơ sở hạ tầng tự động hóa của chúng tôi bao gồm các thử nghiệm web và Android mà chúng tôi chạy song song thông qua GitLab CI, sử dụng các công cụ hỗ trợ Docker: lưới Selenium và Selenoid. Hơn nữa, chúng tôi sử dụng các máy ảo được tạo thông qua GCP để lưu trữ các vùng chứa bằng trình duyệt và trình mô phỏng. Để giảm chi phí, chúng tôi chỉ khởi động các máy ảo này theo yêu cầu và dừng chúng khi không tiến hành thử nghiệm. Có điều gì khác có thể cải thiện cơ sở hạ tầng của chúng tôi không? Câu trả lời là có! Gặp gỡ Kubernetes (K8s)!
Trước tiên, hãy xem các từ phối hợp, cụm và Kubernetes có liên quan với nhau như thế nào. Ở mức độ cao, điều phối là hệ thống triển khai và quản lý các ứng dụng. Để tự động hóa thử nghiệm, các ứng dụng được đóng gói như vậy là lưới Selenium và Selenoid. Docker và K8 bổ sung cho nhau. Cái đầu tiên được sử dụng để triển khai ứng dụng, cái thứ hai để điều phối. Đổi lại, K8s là một cụm. Nhiệm vụ của cụm là sử dụng VM làm Nút, cho phép bạn cài đặt nhiều chức năng, chương trình và dịch vụ khác nhau trong một máy chủ (cụm). Nếu bất kỳ Nút nào bị lỗi, các Nút khác sẽ tiếp tục hoạt động, điều này đảm bảo ứng dụng của chúng tôi hoạt động không bị gián đoạn. Ngoài ra, K8 còn có chức năng quan trọng liên quan đến việc mở rộng quy mô, nhờ đó chúng tôi tự động có được lượng tài nguyên tối ưu dựa trên tải và giới hạn đã đặt.
Trên thực tế, việc triển khai Kubernetes theo cách thủ công từ đầu không phải là một nhiệm vụ tầm thường. Tôi sẽ để lại liên kết đến hướng dẫn cách làm nổi tiếng "Kubernetes The Hard Way" và nếu quan tâm, bạn có thể thực hành nó. Nhưng may mắn thay, có những phương pháp và công cụ thay thế. Cách dễ nhất là sử dụng Google Kubernetes Engine (GKE) trong GCP, điều này sẽ cho phép bạn có được một cụm được tạo sẵn chỉ sau vài cú nhấp chuột. Tôi khuyên bạn nên sử dụng phương pháp này để bắt đầu học vì nó sẽ cho phép bạn tập trung vào việc học cách sử dụng K8 cho các tác vụ của mình thay vì tìm hiểu cách tích hợp các thành phần bên trong với nhau.
Giá trị cho cơ sở hạ tầng tự động hóa
Chúng ta hãy cùng điểm qua một vài tính năng quan trọng mà K8s cung cấp:
- triển khai ứng dụng: sử dụng cụm nhiều nút thay vì VM;
- mở rộng quy mô động: giảm chi phí tài nguyên chỉ được sử dụng theo yêu cầu;
- tự phục hồi: tự động phục hồi các nhóm (do đó các thùng chứa cũng được khôi phục);
- triển khai các bản cập nhật và khôi phục các thay đổi mà không có thời gian ngừng hoạt động: việc cập nhật các công cụ, trình duyệt và trình mô phỏng không làm gián đoạn công việc của người dùng hiện tại
Nhưng K8s vẫn không phải là viên đạn bạc. Để hiểu tất cả những ưu điểm và hạn chế trong bối cảnh của các công cụ mà chúng tôi đang xem xét (Lưới Selenium, Selenoid), chúng tôi sẽ thảo luận ngắn gọn về cấu trúc của K8. Cụm chứa hai loại Nút: Nút chính và Nút công nhân. Master Nodes chịu trách nhiệm về các quyết định quản lý, triển khai và lập kế hoạch. Các nút công nhân là nơi các ứng dụng được khởi chạy. Các nút cũng chứa môi trường thời gian chạy vùng chứa. Trong trường hợp của chúng tôi, đây là Docker, chịu trách nhiệm về các hoạt động liên quan đến container. Nhưng cũng có những giải pháp thay thế, ví dụ. Điều quan trọng là phải hiểu rằng việc chia tỷ lệ hoặc tự phục hồi không áp dụng trực tiếp cho vùng chứa. Điều này được thực hiện bằng cách thêm/giảm số lượng nhóm, lần lượt chứa các thùng chứa (thường là một thùng cho mỗi nhóm, nhưng tùy thuộc vào nhiệm vụ, có thể có nhiều thùng hơn). Hệ thống phân cấp cấp cao bao gồm các nút công nhân, bên trong có các nhóm, bên trong các thùng chứa được nâng lên.
Tính năng chia tỷ lệ là chìa khóa và có thể được áp dụng cho cả hai nút trong nhóm nút cụm và các nhóm trong một nút. Có 2 loại tỷ lệ áp dụng cho cả nút và nhóm. Loại đầu tiên là theo chiều ngang - việc chia tỷ lệ xảy ra bằng cách tăng số lượng nút/nhóm. Loại này được ưa chuộng hơn. Loại thứ hai, tương ứng, theo chiều dọc. Việc chia tỷ lệ được thực hiện bằng cách tăng kích thước của các nút/nhóm chứ không phải số lượng của chúng.
Bây giờ hãy xem xét các công cụ của chúng tôi trong bối cảnh của các thuật ngữ trên.
Lưới selen
Như đã đề cập trước đó, lưới Selenium là một công cụ rất phổ biến và không có gì ngạc nhiên khi nó được đưa vào container. Do đó, không có gì ngạc nhiên khi lưới Selenium có thể được triển khai trong K8. Bạn có thể tìm thấy ví dụ về cách thực hiện việc này trong kho lưu trữ chính thức của K8s. Như thường lệ, tôi đính kèm link ở cuối phần. Ngoài ra, hướng dẫn cách thực hiện chỉ ra cách thực hiện việc này trong Terraform. Ngoài ra còn có hướng dẫn về cách tăng số lượng nhóm chứa vùng chứa trình duyệt. Nhưng chức năng tự động chia tỷ lệ trong bối cảnh của K8 vẫn chưa phải là một nhiệm vụ hoàn toàn rõ ràng. Khi bắt đầu học, tôi không tìm thấy bất kỳ hướng dẫn hay khuyến nghị thực tế nào. Sau một số nghiên cứu và thử nghiệm với sự hỗ trợ của nhóm DevOps, chúng tôi đã chọn phương pháp nâng cao các vùng chứa với các trình duyệt cần thiết bên trong một nhóm, nằm bên trong một nút công nhân. Phương pháp này cho phép chúng ta áp dụng chiến lược chia tỷ lệ theo chiều ngang của các nút bằng cách tăng số lượng của chúng. Tôi hy vọng rằng điều này sẽ thay đổi trong tương lai và chúng ta sẽ thấy ngày càng nhiều mô tả về các phương pháp tiếp cận tốt hơn và các giải pháp có sẵn, đặc biệt là sau khi phát hành Selenium Grid 4 với kiến trúc bên trong đã thay đổi.
điện từ:
Việc triển khai Selenoid trong K8 hiện là nỗi thất vọng lớn nhất. Chúng không tương thích. Về lý thuyết, chúng ta có thể nâng một vùng chứa Selenoid bên trong một nhóm, nhưng khi Selenoid bắt đầu khởi chạy các vùng chứa bằng trình duyệt, chúng vẫn sẽ ở trong cùng một nhóm. Điều này khiến cho việc mở rộng quy mô là không thể và do đó, công việc của Selenoid bên trong một cụm sẽ không khác với công việc bên trong máy ảo. Kết thúc câu chuyện.
mặt trăng:
Biết được nút thắt này khi làm việc với Selenoid, các nhà phát triển đã phát hành một công cụ mạnh mẽ hơn có tên Moon. Công cụ này ban đầu được thiết kế để hoạt động với Kubernetes và do đó, tính năng tự động điều chỉnh quy mô có thể và nên được sử dụng. Hơn nữa, tôi có thể nói rằng vào thời điểm hiện tại đơn một công cụ trong thế giới Selenium, có hỗ trợ cụm K8 nguyên gốc (không còn khả dụng nữa, hãy xem công cụ tiếp theo ). Các tính năng chính của Moon cung cấp hỗ trợ này là:
Hoàn toàn không quốc tịch. Selenoid lưu trữ thông tin trong bộ nhớ về các phiên trình duyệt hiện đang chạy. Nếu vì lý do nào đó mà quá trình của nó gặp sự cố — thì tất cả các phiên đang chạy sẽ bị mất. Ngược lại, Mặt trăng không có trạng thái bên trong và có thể được nhân rộng trên các trung tâm dữ liệu. Phiên trình duyệt vẫn tồn tại ngay cả khi một hoặc nhiều bản sao bị hỏng.
Vì vậy, Moon là một giải pháp tuyệt vời, nhưng có một vấn đề: nó không miễn phí. Giá cả phụ thuộc vào số buổi. Bạn chỉ có thể chạy 0-4 phiên miễn phí, điều này không đặc biệt hữu ích. Tuy nhiên, bắt đầu từ buổi thứ năm, bạn sẽ phải trả 5 USD cho mỗi buổi. Tình hình có thể khác nhau giữa các công ty, nhưng trong trường hợp của chúng tôi, việc sử dụng Moon là vô nghĩa. Như tôi đã mô tả ở trên, chúng ta có thể chạy máy ảo với Selenium Grid theo yêu cầu hoặc tăng số lượng Nút trong cụm. Đối với khoảng một quy trình, chúng tôi khởi chạy 500 trình duyệt và dừng tất cả tài nguyên sau khi hoàn tất thử nghiệm. Nếu sử dụng Moon, chúng tôi sẽ phải trả thêm 500 x 5 = 2500 USD mỗi tháng, bất kể tần suất chạy thử nghiệm của chúng tôi như thế nào. Một lần nữa, tôi không nói không sử dụng Moon. Đối với nhiệm vụ của bạn, đây có thể là một giải pháp không thể thiếu, chẳng hạn như nếu bạn có nhiều dự án/nhóm trong tổ chức của mình và bạn cần một cụm chung lớn cho mọi người. Như mọi khi, tôi để lại một liên kết ở cuối và khuyên bạn nên thực hiện tất cả các phép tính cần thiết trong bối cảnh nhiệm vụ của mình.
Callisto: (Chú ý! Điều này không có trong bài viết gốc và chỉ có trong bản dịch tiếng Nga)
Như tôi đã nói, Selenium là một công cụ rất phổ biến và lĩnh vực CNTT đang phát triển rất nhanh. Trong khi tôi đang dịch thuật, một công cụ mới đầy hứa hẹn có tên Callisto đã xuất hiện trên web (xin chào Cypress và những kẻ giết Selenium khác). Nó hoạt động nguyên bản với K8 và cho phép bạn chạy các thùng chứa Selenoid trong các nhóm, được phân phối trên các Nút. Mọi thứ đều hoạt động ngay lập tức, bao gồm cả tính năng tự động điều chỉnh tỷ lệ. Tuyệt vời, nhưng cần phải được thử nghiệm. Tôi đã triển khai được công cụ này và chạy một số thử nghiệm. Nhưng còn quá sớm để đưa ra kết luận, sau khi nhận được kết quả trên một chặng đường dài, có lẽ mình sẽ đánh giá ở những bài viết sau. Hiện tại tôi chỉ để lại các liên kết cho nghiên cứu độc lập.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá
Công cụ tương tự
7. Cơ sở hạ tầng dưới dạng mã (IaC)
Mô tả ngắn gọn về công nghệ
Và bây giờ chúng ta đến phần cuối cùng. Thông thường, công nghệ này và các nhiệm vụ liên quan không phải là trách nhiệm của kỹ sư tự động hóa. Và có những lý do cho việc này. Thứ nhất, trong nhiều tổ chức, các vấn đề về cơ sở hạ tầng nằm dưới sự kiểm soát của bộ phận DevOps và các nhóm phát triển không thực sự quan tâm đến điều gì khiến quy trình hoạt động và mọi thứ kết nối với nó cần được hỗ trợ như thế nào. Thứ hai, hãy thành thật mà nói, việc áp dụng Cơ sở hạ tầng dưới dạng Mã (IaC) vẫn chưa được áp dụng ở nhiều công ty. Nhưng nó chắc chắn đã trở thành một xu hướng phổ biến và điều quan trọng là bạn phải cố gắng tham gia vào các quy trình, cách tiếp cận và công cụ liên quan đến nó. Hoặc ít nhất là luôn cập nhật.
Hãy bắt đầu với động lực sử dụng phương pháp này. Chúng ta đã thảo luận rằng để chạy thử nghiệm trong GitlabCI, chúng ta sẽ cần tối thiểu tài nguyên để chạy Gitlab Runner. Và để chạy các vùng chứa với trình duyệt/trình mô phỏng, chúng ta cần đặt trước một máy ảo hoặc cụm. Ngoài tài nguyên thử nghiệm, chúng tôi cần một lượng năng lực đáng kể để hỗ trợ phát triển, dàn dựng, môi trường sản xuất, bao gồm cơ sở dữ liệu, lịch trình tự động, cấu hình mạng, cân bằng tải, quyền người dùng, v.v. Vấn đề mấu chốt là nỗ lực cần thiết để hỗ trợ tất cả. Có một số cách chúng tôi có thể thực hiện thay đổi và triển khai các bản cập nhật. Ví dụ: trong ngữ cảnh của GCP, chúng ta có thể sử dụng bảng điều khiển UI trong trình duyệt và thực hiện tất cả hành động bằng cách nhấp vào nút. Một cách khác là sử dụng lệnh gọi API để tương tác với các thực thể đám mây hoặc sử dụng tiện ích dòng lệnh gcloud để thực hiện các thao tác mong muốn. Nhưng với một số lượng thực sự lớn các thực thể và thành phần cơ sở hạ tầng khác nhau, việc thực hiện tất cả các hoạt động theo cách thủ công trở nên khó khăn hoặc thậm chí không thể. Hơn nữa, tất cả các hành động thủ công này đều không thể kiểm soát được. Chúng tôi không thể gửi chúng để xem xét trước khi thực thi, sử dụng hệ thống kiểm soát phiên bản và nhanh chóng khôi phục các thay đổi dẫn đến sự cố. Để giải quyết những vấn đề như vậy, các kỹ sư đã tạo và tạo các tập lệnh bash/shell tự động, không tốt hơn nhiều so với các phương pháp trước đó vì chúng không dễ đọc, hiểu, duy trì và sửa đổi nhanh chóng theo kiểu thủ tục.
Trong bài viết này và hướng dẫn cách thực hiện, tôi sử dụng 2 công cụ liên quan đến thực hành IaC. Đây là Terraform và Ansible. Một số người tin rằng việc sử dụng chúng cùng lúc là vô nghĩa vì chức năng của chúng tương tự nhau và chúng có thể thay thế cho nhau. Nhưng thực tế là ban đầu họ được giao những nhiệm vụ hoàn toàn khác nhau. Và thực tế là các công cụ này sẽ bổ sung cho nhau đã được xác nhận tại buổi thuyết trình chung của các nhà phát triển đại diện cho HashiCorp và RedHat. Sự khác biệt về mặt khái niệm là Terraform là một công cụ cung cấp để tự quản lý các máy chủ. Trong khi Ansible là một công cụ quản lý cấu hình có nhiệm vụ cài đặt, cấu hình và quản lý phần mềm trên các máy chủ này.
Một đặc điểm khác biệt chính của những công cụ này là phong cách viết mã. Không giống như bash và Ansible, Terraform sử dụng kiểu khai báo dựa trên mô tả về trạng thái kết thúc mong muốn đạt được khi thực thi. Ví dụ: nếu chúng ta định tạo 10 máy ảo và áp dụng các thay đổi thông qua Terraform thì chúng ta sẽ nhận được 10 máy ảo. Nếu chúng tôi chạy lại tập lệnh, sẽ không có gì xảy ra vì chúng tôi đã có 10 máy ảo và Terraform biết về điều này vì nó lưu trữ trạng thái hiện tại của cơ sở hạ tầng trong một tệp trạng thái. Nhưng Ansible sử dụng cách tiếp cận theo thủ tục và nếu bạn yêu cầu nó tạo 10 máy ảo thì trong lần khởi chạy đầu tiên, chúng tôi sẽ nhận được 10 máy ảo, tương tự như Terraform. Nhưng sau khi khởi động lại, chúng ta sẽ có 20 VM. Đây là sự khác biệt quan trọng. Theo kiểu thủ tục, chúng tôi không lưu trữ trạng thái hiện tại và chỉ mô tả trình tự các bước phải được thực hiện. Tất nhiên, chúng ta có thể xử lý các tình huống khác nhau, thêm một số kiểm tra về sự tồn tại của tài nguyên và trạng thái hiện tại, nhưng chẳng ích gì khi lãng phí thời gian và nỗ lực kiểm soát logic này. Ngoài ra, điều này còn làm tăng nguy cơ mắc sai lầm.
Tóm tắt tất cả những điều trên, chúng ta có thể kết luận rằng Terraform và ký hiệu khai báo là một công cụ phù hợp hơn để cung cấp máy chủ. Nhưng tốt hơn hết bạn nên giao công việc quản lý cấu hình cho Ansible. Ngoài vấn đề đó ra, chúng ta hãy xem xét các trường hợp sử dụng trong bối cảnh tự động hóa.
Giá trị cho cơ sở hạ tầng tự động hóa
Điều quan trọng duy nhất cần hiểu ở đây là cơ sở hạ tầng tự động hóa thử nghiệm phải được coi là một phần của toàn bộ cơ sở hạ tầng của công ty. Điều này có nghĩa là tất cả các biện pháp thực hành IaC phải được áp dụng trên toàn cầu đối với các nguồn lực của toàn bộ tổ chức. Ai chịu trách nhiệm cho việc này phụ thuộc vào quy trình của bạn. Nhóm DevOps có nhiều kinh nghiệm hơn trong những vấn đề này, họ nhìn thấy bức tranh toàn cảnh về những gì đang xảy ra. Tuy nhiên, các kỹ sư QA tham gia nhiều hơn vào quá trình tự động hóa tòa nhà và cấu trúc của đường ống, điều này cho phép họ nhìn rõ hơn tất cả các thay đổi cần thiết và cơ hội cải tiến. Lựa chọn tốt nhất là cùng nhau làm việc, trao đổi kiến thức, ý tưởng để đạt được kết quả như mong đợi.
Dưới đây là một số ví dụ về việc sử dụng Terraform và Ansible trong bối cảnh tự động hóa thử nghiệm và các công cụ mà chúng ta đã thảo luận trước đây:
1. Mô tả các đặc điểm và tham số cần thiết của VM và cluster sử dụng Terraform.
2. Sử dụng Ansible, cài đặt các công cụ cần thiết để thử nghiệm: docker, Selenoid, Selenium Grid và tải xuống các phiên bản trình duyệt/trình giả lập cần thiết.
3. Sử dụng Terraform, mô tả các đặc điểm của VM mà GitLab Runner sẽ được khởi chạy.
4. Cài đặt GitLab Runner và các công cụ đi kèm cần thiết bằng Ansible, thiết lập cài đặt và cấu hình.
Minh họa hiện trạng cơ sở hạ tầng
Liên kết để khám phá:
Công cụ tương tự
Hãy tóm tắt nó lại!
Bước
Công nghệ
CÔNG CỤ
Giá trị cho cơ sở hạ tầng tự động hóa
1
Chạy cục bộ
Node.js, Selenium, Appium
- Các công cụ phổ biến nhất cho web và di động
- Hỗ trợ nhiều ngôn ngữ và nền tảng (bao gồm Node.js)
2
Hệ thống kiểm soát phiên bản
đi
- Lợi ích tương tự với mã phát triển
3
container hóa
Docker, lưới Selenium, Selenoid (Web, Android)
- Chạy thử nghiệm song song
- Môi trường biệt lập
- Nâng cấp phiên bản đơn giản, linh hoạt
- Tự động dừng các tài nguyên không sử dụng
- Dễ dàng thiết lập
4
CI/CD
CI Gitlab
- Kiểm tra một phần của đường ống
- Phản hồi nhanh
- Tầm nhìn cho toàn bộ công ty/nhóm
5
Nền tảng đám mây
Google Cloud Platform
- Tài nguyên theo yêu cầu (chúng tôi chỉ thanh toán khi cần)
- Dễ dàng quản lý và cập nhật
- Khả năng hiển thị và kiểm soát tất cả các tài nguyên
6
Dàn nhạc
Kubernetes
Trong bối cảnh các vùng chứa có trình duyệt/trình mô phỏng bên trong nhóm:
- Chia tỷ lệ/tự động chia tỷ lệ
- Tự chữa bệnh
- Cập nhật và khôi phục mà không bị gián đoạn
7
Cơ sở hạ tầng dưới dạng mã (IaC)
Địa hình, Ansible
- Lợi ích tương tự với cơ sở hạ tầng phát triển
- Tất cả lợi ích của việc lập phiên bản mã
- Dễ dàng thực hiện thay đổi và bảo trì
- Hoàn toàn tự động
Sơ đồ bản đồ tư duy: sự phát triển của cơ sở hạ tầng
bước 1: Địa phương
bước 2: VCS
bước 3: Container hóa
bước 4: CI/CD
bước 5: Nền tảng đám mây
Bước 6: Dàn nhạc
bước 7: IaC
Cái gì tiếp theo?
Vì vậy, đây là phần cuối của bài viết. Nhưng để kết luận, tôi muốn thiết lập một số thỏa thuận với bạn.
Từ phía bạn
Như mình đã nói lúc đầu, mình mong muốn bài viết có tính ứng dụng thực tế và giúp các bạn áp dụng những kiến thức thu được vào công việc thực tế. Tôi thêm lại.
Nhưng ngay cả sau đó, đừng dừng lại, hãy thực hành, nghiên cứu các liên kết và sách có liên quan, tìm hiểu cách nó hoạt động trong công ty của bạn, tìm những chỗ có thể cải thiện và tham gia vào nó. Chúc may mắn!
Từ phía tôi
Từ tiêu đề bạn có thể thấy rằng đây chỉ là phần đầu tiên. Mặc dù thực tế là nó khá lớn nhưng các chủ đề quan trọng vẫn chưa được đề cập ở đây. Trong phần thứ hai, tôi dự định xem xét cơ sở hạ tầng tự động hóa trong bối cảnh iOS. Do những hạn chế của Apple về việc chỉ chạy trình mô phỏng iOS trên hệ thống macOS, phạm vi giải pháp của chúng tôi bị thu hẹp. Ví dụ: chúng tôi không thể sử dụng Docker để chạy trình mô phỏng hoặc đám mây công cộng để chạy máy ảo. Nhưng điều này không có nghĩa là không có lựa chọn thay thế nào khác. Tôi sẽ cố gắng cập nhật cho bạn các giải pháp tiên tiến và công cụ hiện đại!
Ngoài ra, tôi chưa đề cập đến các chủ đề khá lớn liên quan đến giám sát. Trong Phần 3, tôi sẽ xem xét các công cụ giám sát cơ sở hạ tầng phổ biến nhất cũng như những dữ liệu và số liệu cần xem xét.
Và cuối cùng. Trong tương lai, tôi dự định phát hành một khóa học video về xây dựng cơ sở hạ tầng thử nghiệm và các công cụ phổ biến. Hiện nay trên Internet có khá nhiều khóa học và bài giảng về DevOps nhưng tất cả tài liệu đều được trình bày trong bối cảnh phát triển chứ không phải tự động hóa thử nghiệm. Về vấn đề này, tôi thực sự cần phản hồi về việc liệu một khóa học như vậy có thú vị và có giá trị đối với cộng đồng những người thử nghiệm và kỹ sư tự động hóa hay không. Cảm ơn bạn trước!
Nguồn: www.habr.com