Với nhóm phát triển ứng dụng di động ngày càng lớn và các bản phát hành hàng tuần, việc có một quy trình CI đáng tin cậy là điều cần thiết. Chúng tôi cần có khả năng xây dựng, kiểm thử ứng dụng và triển khai chúng lên App Store và Google Play Store. Chúng tôi cũng duy trì các phiên bản xem trước nội bộ để kiểm thử các tính năng mới nhất.
Tìm hiểu cách chúng tôi sử dụng ClickUp, Fastlane và GitHub Actions để tự động hóa quy trình Tích hợp Liên tục (CI) và Phát hành Liên tục (CD).
Cuộc đời của một lỗi 🐜
Hãy bắt đầu bằng cách nhanh chóng điểm qua quy trình quản lý và khắc phục lỗi của chúng tôi.
- Một lỗi (hoặc yêu cầu tính năng) được báo cáo và một công việc được tạo trong ClickUp.
- Công việc được giao cho một nhà phát triển và được cố định trong một yêu cầu kéo (PR) đối với nhánh staging.
- Quá trình CI thực hiện tất cả các bài kiểm tra, xây dựng ứng dụng, triển khai bản xem trước web và tải lên tất cả dữ liệu lên nhiệm vụ ClickUp.
- Nhóm Kiểm thử Chất lượng (QA) của chúng tôi xác minh bản sửa lỗi và nếu nó đạt yêu cầu, công việc sẽ được đánh dấu là hoàn thành.
- Yêu cầu kéo (PR) được hợp nhất vào môi trường staging một cách tự động.
- Nhánh staging được xây dựng và triển khai lên môi trường TestFlight nội bộ của chúng tôi.
- Mỗi thứ Tư, một nhánh phát hành được tạo ra, xây dựng và kiểm thử.
- Vào thứ Sáu, chúng tôi tạo một bản phát hành trên GitHub và hệ thống CI sẽ triển khai bản phát hành đó lên App Store và Play Store.
Một nhiệm vụ ClickUp chứa tất cả thông tin về lỗi. Chúng tôi sử dụng các trạng thái tùy chỉnh như "Đang tiến độ" hoặc "Kiểm tra mã" để theo dõi lỗi. Các quy trình CI tự động thay đổi trạng thái. Các Trường Tùy chỉnh chứa thông tin bổ sung như ai đã báo cáo lỗi, ai đang xử lý nó, khi nào nó sẽ được phát hành, v.v.
Quy trình làm việc với PR 📜
Hai bước đầu tiên được nêu trên thực ra không liên quan đến CI, nhưng bước thứ ba thì khá thú vị…
Quy trình phát triển của chúng tôi được thực thi cho mọi yêu cầu kéo (PR). Nó kiểm tra các quy tắc linting, định dạng và chạy tất cả các bài kiểm tra trước khi bắt đầu xây dựng các gói ứng dụng Android và iOS.
Khi quá trình xây dựng thành công, CI sẽ đăng một thông báo trong công việc liên kết. Các kỹ sư QA có thể truy cập vào PR, tải xuống các tệp tin xây dựng hoặc sử dụng bản xem trước trực tuyến.
Thông báo CI tự động được đăng trong nhiệm vụ ClickUp liên kết sau khi quá trình xây dựng thành công.
Cài đặt Flutter trên máy chạy CI 🛠
Chúng tôi sử dụng GitHub Action subosito/flutter-action để cài đặt Flutter trên CI. Theo mặc định, nó sẽ cài đặt phiên bản Flutter ổn định mới nhất. Để tránh làm gián đoạn quy trình CI khi có phiên bản Flutter mới được phát hành, bạn nên chỉ định phiên bản một cách thủ công.
Nếu bạn có nhiều quy trình làm việc, tốt nhất nên lưu phiên bản Flutter trong một tệp. Chúng tôi sử dụng biến môi trường FLUTTER_VERSION ở thư mục gốc của kho lưu trữ.
Một giải pháp đơn giản khác là lưu trữ phiên bản Flutter dưới dạng bí mật GitHub và truy cập nó bằng cách sử dụng {{ secrets. FLUTER_VERSION }}.
Xem trước trên web 🕸
Nhờ khả năng chạy trên web của Flutter, chúng tôi có thể tạo bản xem trước web đầy đủ chức năng cho các Yêu cầu Hợp nhất (pull requests). Sử dụng gói device_preview, kích thước và cài đặt thiết bị có thể được điều chỉnh.
Bản xem trước đã chứng minh là rất hữu ích và không chỉ được sử dụng bởi nhóm Kiểm thử Chất lượng (QA) của chúng tôi. Các nhà thiết kế và Quản lý Sản phẩm cũng thích nó để nhanh chóng thử nghiệm các tính năng mới.
qua Flutter
Cách tạo bản xem trước trang web 🐶
Để bắt đầu, hãy đảm bảo ứng dụng của bạn tương thích với Flutter web—không phải tất cả các API đều được hỗ trợ.
Trong ứng dụng của chúng tôi, ví dụ, chúng tôi cần tắt thông báo đẩy và web sockets.
Quy trình làm việc mẫu này tạo bản xem trước web cho ứng dụng Flutter của bạn và tải nó lên một thùng S3. Chúng tôi sử dụng biến môi trường ENABLE_DEVICE_PREVIEW để vô hiệu hóa tính năng device_preview trong môi trường sản xuất.
Bước Fix base href là cần thiết vì bản xem trước sẽ không nằm ở gốc của bucket.
Và một số mã để kích hoạt điều kiện cho device_preview.
Biến môi trường là một công cụ mạnh mẽ và cho phép thuật toán tree shaking của Flutter loại bỏ mã gỡ lỗi trong các bản dựng phát hành.
Fastlane 💨
Fastlane giúp đơn giản hóa việc xây dựng, ký kết và triển khai ứng dụng Flutter. Nó quản lý các chứng chỉ, hồ sơ cấp phép và các cài đặt khác của chúng tôi. Chúng tôi sử dụng GitHub secrets để lưu trữ mật khẩu và token một cách bảo mật.
Các hành động hữu ích trong Fastlane:
- fastlane match để tạo và lưu trữ các khóa và cấu hình iOS trong kho lưu trữ GitHub.
- build_app để phát triển ứng dụng iOS và Android.
- Tải lên TestFlight và triển khai bản dựng iOS.
- upload_to_play_store để triển khai các bản dựng Android.
Mẫu bản dựng phát triển iOS 🍏
Đừng quên setup_ci, nó sẽ giúp bạn tránh những lỗi kỳ lạ 👾. Tìm hiểu thêm về Fastlane cho ứng dụng Flutter.
Ký tên ứng dụng Android 🔒
Cách đơn giản nhất để ký các bản dựng phát hành Android một cách bảo mật là lưu trữ các token dưới dạng bí mật GitHub và sử dụng biến môi trường cùng với khóa tạm thời. JKS được tạo bởi CI:
Chúng tôi lưu trữ khóa .jks dưới dạng chuỗi mã hóa base64 trong GitHub Secrets và giải mã nó trong workflow:
Quy trình phát hành và sản xuất 🚀
Quy trình làm việc trước khi phát hành được áp dụng cho các nhánh bắt đầu bằng release/v. Quy trình này loại bỏ toàn bộ mã gỡ lỗi và mã nội bộ để đảm bảo chúng ta kiểm thử cùng một mã sẽ được phát hành.
Ngoài ra, quy trình làm việc trước khi phát hành sẽ đăng lên các kênh Slack khác nhau để thông báo cho nhóm QA và nhóm tiếp thị về một bản phát hành mới thông qua các webhook đến.
Sau khi mọi thứ được kiểm thử kỹ lưỡng, chúng tôi tạo một bản phát hành trên GitHub để kích hoạt quy trình làm việc sản xuất. Quy trình này sẽ xây dựng và ký ứng dụng bằng chứng chỉ sản xuất, sau đó gửi nó đến App Store.
Thêm mẹo hay cho quy trình CI của bạn 🦾
Nếu bạn sử dụng trigger đẩy cho GitHub Actions, bạn có thể gặp vấn đề nếu có nhiều lần đẩy vào cùng một nhánh trong thời gian ngắn. Hơn một đối tượng/kỳ/phiên bản của workflow sẽ bắt đầu và tiêu tốn thời gian xây dựng hoặc gây ra các vấn đề khác.
- Chúng tôi khuyến nghị sử dụng hành động hủy quy trình làm việc (Cancel Workflow Action) để hủy tất cả các đối tượng/kỳ/phiên bản trước đó của quy trình làm việc.
- Nếu bạn đang tìm kiếm một giải pháp đơn giản và dễ duy trì để tạo số phiên bản xây dựng theo thứ tự, hãy thử công cụ Build Number Generator. Bạn cũng có thể sử dụng GITHUB_RUN_ID nhưng nó không thể tùy chỉnh.
- Truy cập ứng dụng ClickUp GitHub để xem các nhánh, commit và trạng thái GitHub ngay trong các nhiệm vụ ClickUp của bạn. Sử dụng ClickUp Automations hoặc API công khai của ClickUp cho các nhiệm vụ tự động hóa nâng cao.
Tóm tắt 🍩
Xây dựng CI là một quá trình thú vị. Việc bắt đầu rất đơn giản và bạn có thể phát triển nó theo thời gian. CI của chúng tôi tuân theo một trong những Giá trị cốt lõi của ClickUp: Tiến độ hướng tới sự hoàn hảo. Chúng tôi liên tục cải tiến CI để hỗ trợ các nhóm QA và kỹ thuật.
Sự kết hợp giữa ClickUp, GitHub Actions và Fastlane rất mạnh mẽ và cho phép xây dựng một quy trình CI/CD linh hoạt và hoàn toàn được tự động hóa trong vòng chưa đầy một giờ. Hãy thử ngay!
Chúng tôi có rất nhiều chủ đề thú vị đang được chuẩn bị, vì vậy hãy thường xuyên ghé thăm blog Kỹ thuật ClickUp! 🦄