Văn phòng Hà Nội
Công Ty Proximie Việt Nam Chi Nhánh Hà Nội
Số 226 Đường Láng, Đống Đa, Hà Nội
Gần Ngã Tư Sở · Xem bản đồ
Hotline văn phòng: 024.7304.8700
Giờ làm việc: 07:00 – 21:00 (Tất cả các ngày)
Việc xây dựng một nền tảng y tế từ nền móng và đưa nó trở thành công nghệ hiện diện rộng rãi trong các phòng mổ trên toàn thế giới đòi hỏi đội ngũ phát triển của chúng tôi phải phát hiện vấn đề sớm, phản ứng nhanh và thực hiện thay đổi kịp thời để xử lý sự cố — gần như trong chớp mắt. Khả năng thích ứng, sáng tạo và linh hoạt của đội ngũ phát triển Proximie giúp họ đối mặt trực diện với cả những thách thức đã thấy trước lẫn bất ngờ. Sau một bản cập nhật gần đây của Apple đối với Xcode — môi trường phát triển tích hợp (IDE) của Apple dành cho việc xây dựng ứng dụng — cùng một bản nâng cấp lớn của iOS, hàng loạt thách thức đặc thù đã làm gián đoạn hạ tầng CI của đội ngũ (Continuous Integration là phương pháp tự động hóa việc tích hợp các thay đổi mã nguồn từ nhiều người đóng góp vào một dự án phần mềm duy nhất). Trong nghiên cứu tình huống được Proximie công khai mã nguồn này, May Chehab và Hamza Jadid từ đội ngũ phát triển chia sẻ cách nhóm đã xử lý chuyên nghiệp những khó khăn sau khi chuyển sang XCode 16.
Là một đội ngũ phát triển iOS, chúng tôi không xa lạ với những thách thức đi kèm các phiên bản XCode và iOS mới. Apple thường xuyên phát hành bản cập nhật Xcode song song với các phiên bản iOS lớn, mang đến nhiều tính năng và cải tiến hấp dẫn. Tuy nhiên, những bản cập nhật này cũng thường chứa các thay đổi có thể làm gián đoạn quy trình hiện tại, đặc biệt là các pipeline CI.
Trong trường hợp của chúng tôi, việc chuyển sang XCode 16 và nâng cấp device farm tạo ra một thách thức đặc biệt. Dù đã dự đoán sẽ cần điều chỉnh hạ tầng CI, một vấn đề quan trọng vẫn khiến chúng tôi bất ngờ: một số chức năng trong xcresultparser — công cụ chúng tôi dựa vào để xử lý kết quả kiểm thử — đã bị ngừng hỗ trợ. Chúng tôi dùng công cụ này để trích xuất dữ liệu kết quả kiểm thử từ định dạng .xcresult của XCode rồi chuyển sang XML. Định dạng XML này rất quan trọng vì tương thích với một công cụ khác trong pipeline CI. Sau khi trích xuất dữ liệu, chúng tôi tải nó lên GitHub Actions và dùng một GitHub Action tên dorny/test-reporter. Action này nhận dữ liệu JUnit XML và tạo một báo cáo trực quan, dễ đọc, tóm tắt kết quả kiểm thử và cho biết các test nào thành công hoặc thất bại.
Sau khi các chức năng đó bị ngừng hỗ trợ, chúng tôi cần chuyển sang một công cụ mới để trích xuất dữ liệu kết quả kiểm thử từ định dạng .xcresult của XCode. Đồng thời, chúng tôi cũng phải chọn một GitHub Action mới tương thích với công cụ đó.
Chúng tôi bắt đầu tìm hiểu các công cụ khác nhưng không công cụ nào thực sự phù hợp với nhu cầu. Vì vậy, trong ‘rocket time’ của đội ngũ (các công ty khác thường gọi là thời gian đổi mới), chúng tôi bắt đầu tự xây dựng công cụ của riêng mình.
Khi mở tệp .xcresult, chúng tôi phát hiện một cơ sở dữ liệu SQLite chứa kết quả kiểm thử chi tiết đến mức rất sâu. Sau khi chạy công cụ trực quan hóa schema trên cơ sở dữ liệu, chúng tôi có thể hiểu cấu trúc dữ liệu, viết truy vấn phù hợp và — thế là — lấy được kết quả kiểm thử ngay trong pipeline của mình.
Chúng tôi gặp đúng tình huống kinh điển ‘chạy trên máy tôi thì được’: bundle .xcresult có chứa cơ sở dữ liệu của lần chạy kiểm thử, nhưng khi đưa công cụ vào CI thì lại không tìm thấy cơ sở dữ liệu đó.
Chúng tôi phát hiện tệp cơ sở dữ liệu chỉ có thể truy cập sau khi bundle .xcresult được mở thủ công bằng XCode. Khi đã mở, chúng tôi có thể truy cập cơ sở dữ liệu và truy vấn thành công.
Để tự động hóa quy trình này, ban đầu chúng tôi thêm một bước vào CI để mở bundle .xcresult bằng XCode, chạy truy vấn SQL lấy dữ liệu rồi đóng XCode sau khi hoàn tất. Tuy nhiên, cách làm này đòi hỏi thêm nhiều hàm để quản lý vòng đời tiến trình của XCode, chẳng hạn bảo đảm ứng dụng đóng đúng cách sau khi truy xuất dữ liệu, khiến hệ thống phức tạp một cách không cần thiết.
Để đơn giản hóa quy trình, chúng tôi sử dụng công cụ xcrun tích hợp sẵn, cho phép truy cập cơ sở dữ liệu mà không cần mở XCode thủ công. Cách này loại bỏ sự phụ thuộc vào giao diện XCode và giảm đáng kể chi phí xử lý để truy cập cơ sở dữ liệu kết quả kiểm thử.
Sau khi truy cập được cơ sở dữ liệu, việc hiểu cấu trúc và trích xuất dữ liệu có ý nghĩa lại trở thành một thách thức lớn.
Cơ sở dữ liệu rất phức tạp, có nhiều bảng và các mối quan hệ chằng chịt. Nó chứa lượng dữ liệu lớn, trong đó phần lớn không liên quan trực tiếp đến nhu cầu trước mắt, khiến việc xác định đúng thông tin cần thiết trở nên khó khăn.
Quá trình này đòi hỏi hiểu sâu schema cơ sở dữ liệu, xây dựng truy vấn cẩn thận và dành nhiều thời gian để xác minh quan hệ giữa các bảng nhằm bảo đảm độ chính xác.
Công cụ yêu cầu các đầu vào sau:
Ví dụ, lệnh ở trên tạo một tệp tên result.md trong thư mục của bạn, chứa báo cáo Markdown chỉ về các test thất bại. Với mỗi test thất bại, báo cáo bao gồm nguyên nhân, tệp và dòng mã nơi sự cố xảy ra, thời lượng của test và số lần test thất bại nếu nó được cấu hình để chạy nhiều lần.
Nhưng tại sao phải dừng ở đó? Khi đã có toàn bộ dữ liệu cần thiết về kết quả kiểm thử, chúng tôi có thể cải thiện quy trình phản hồi hơn nữa.
Chúng tôi thiết kế công cụ dựa trên template engine Handlebars để tạo đầu ra; nhờ vậy sẽ không bao giờ bị giới hạn vào một định dạng cụ thể.
Hiện tại, cho các nhu cầu của mình, chúng tôi đã tạo hai template. Template đầu tiên là Markdown để dùng trong phần tổng kết CI. Vì sử dụng GitHub Actions, chúng tôi có thể đưa đầu ra vào $GITHUB_STEP_SUMMARY và kết quả sẽ xuất hiện trong tab Summary.
Template thứ hai dành cho Slack và sử dụng Slack Builder Kit.
Bạn có thể cài đặt công cụ bằng cargo hoặc brew.
Khả năng đọc trực tiếp từ cơ sở dữ liệu SQLite mang lại thông tin tùy biến và giúp hiểu dữ liệu sâu hơn. Việc sử dụng template cũng cải thiện trải nghiệm trực quan hóa bằng cách cho phép điều chỉnh cách hiển thị dữ liệu và tích hợp CI dễ dàng. Chẳng hạn, kết quả có thể được gửi tới các nền tảng như Discord hoặc báo cáo trực tiếp trong GitLab. Và những tính năng mới sắp tới sẽ còn làm công cụ trở nên đặc biệt hơn.
Chúng tôi đang xem xét triển khai các tính năng sau:
Sau khi vượt qua tất cả những thách thức này, chúng tôi đã đưa công cụ thành mã nguồn mở!
x-result-analyzer được xây dựng để giải quyết vấn đề của chính chúng tôi, và qua cộng đồng trực tuyến chúng tôi nhận thấy nhiều người cũng đang gặp khó khăn tương tự. Vì vậy, chúng tôi đã mở mã nguồn công cụ như một cách đóng góp trở lại cho cộng đồng.
Nếu bạn gặp vấn đề với công cụ hoặc có đề xuất tính năng, chúng tôi luôn hoan nghênh issue và pull request!
