Adding Continuous Integration to a Swift project

Bài đăng này đã không được cập nhật trong 6 năm

Sử dụng phương pháp CI giúp cho hệ thống luôn đảm bảo là build được và chạy đúng (do phải pass qua toàn bộ test case). Mặt khác các công đoạn test sẽ được hệ thống CI server thực hiện tự dộng giúp cho ta có thể dễ dàng biết được tình trạng của một branch, một commit nào đó và không cần lấy source về test thử. Do đó tốc độ phát triển được tăng lên. Đây cũng là lý do mà nhiều team phát triển theo mô hình Agile lựa chọn phương pháp này. Trong bài viết này, chúng ta hãy cùng xem cách chúng ta có thể sử dụng CI để thiết lập một worflow trôi chảy và tốt đẹp cho team của bạn trong một dự án Swift. CI được thực hiện trên một server tách biệt với máy của các thành viên. Nó giúp thêm một lớp đảm bảo chất lượng và đảm bảo dự án được build trên một “clean” setup.

The most common options for CI solutions

Đây là những giải pháp được sử dụng phổ biến nhất để chạy một máy chủ CI được sử dụng cho các dự án Swift ngày hôm nay:

Travis CI, một giải pháp cloud-based cung cấp cho bạn một máy ảo để build code của bạn. Bạn chọn môi trường và sau đó chạy các build command sử dụng các công cụ như xcodebuild, swift build, hoặc fastlane. Nó miễn phí cho các dự án mã nguồn mở, và cũng có một số mức thanh toán cho các mã nguồn đóng.
Circle CI, tương tự như Travis trong đó họ cũng cung cấp một máy ảo cloud-base để bạn build và cung cấp cho bạn khả năng sử dụng command line nơi bạn có thể chạy các công cụ build của bạn. Tuy nhiên, nó không phải là miễn phí cho các dự án mã nguồn mở (trừ khi bạn chỉ xây dựng trên Linux) - nhưng họ cung cấp một thử nghiệm miễn phí trong 2 tuần.
Buddy Build, có cách tiếp cận khác nhau so với Travis & Circle, vì họ không đòi hỏi bạn phải chạy bất kỳ build command nào bằng tay và thay vào đó dự án của bạn được tự động build dựa trên cấu trúc của nó. Giống như Travis, nó miễn phí cho mã nguồn mở.
Jenkins, nếu bạn là người thích tự xây dựng mọi thứ, Jenkins thường là con đường để đi. Về cơ bản nó là một gói phần mềm bạn cài đặt trên phần cứng của bạn. Nó cung cấp cho bạn một máy chủ CI mà bạn có thể tự cấu hình.
Xcode Server / Bots là cách chính thức của Apple để làm CI cho dự án Swift và Objective-C. Nó cung cấp một số tích hợp với Xcode, và có một giao diện đẹp.

Picking the right solution

Vì gần như tất cả các giải pháp đã đề cập ở trên đều có mức miễn phí, do đó, trước khi đầu tư đầy đủ vào bất kỳ giải pháp nào đó - bạn luôn có thể thử một số trong số họ ra để xem một giải pháp nào phù hợp nhất với dự án của mình. Tuy nhiên, tôi muốn cung cấp một hướng dẫn nhanh để thiết lập một số các giải pháp này - vì thế cho mục đích của bài viết này tôi sẽ tập trung vào Travis và Buddy Build. Nó rất thú vị khi so sánh, bởi vì Travis và Buddy Build có cách tiếp cận rất khác nhau, và dễ dàng thiết lập. Ta sẽ đi sâu hơn ở phần tiếp theo.

Travis

Giống như đề cập ở trên, Travis cung cấp cho bạn command line để chạy các công cụ build của bạn. Cấu hình được thực hiện thông qua file .travis.yml. đặt trong repository của bạn, và khi bạn đăng ký và kích hoạt nó cho dự án của mình nó sẽ tự động lấy bất kỳ file .yml nào và chạy CI dựa trên nó. Dưới đây là một ví dụ về một tệp .travis.yml đơn giản sử dụng xcodebuild để build và test một dự án iOS:

language: objective-c
osx_image: xcode9
script:
    - xcodebuild clean test -project MyApp.xcodeproj -scheme MyApp -destination "platform=iOS Simulator,name=iPhone 7,OS=10.3" CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO ONLY_ACTIVE_ARCH=NO -quiet

Ta sẽ cùng phân tich đoạn code trên Clean test sẽ lệnh cho xcodebuild clean dự án trước hết, sau đó build nó và chạy các test của nó

project MyApp.xcodeproj là nơi chúng tôi cung cấp đường dẫn tới dự án Xcode của bạn (nếu bạn đang sử dụng CocoaPods, bạn sẽ sử dụng Workspace của dự án và cung cấp nó bằng cách sử dụng -workspace MyApp.xcworkspace).
scheme MyApp là scheme mà bạn muốn build và test. Đảm bảo rằng bạn đã chia sẻ scheme bằng cách chọn “share” box trong dialog “Manage schemes” trong Xcode, để cho scheme có thể truy cập vào CI.
Đối số -destination và chuỗi sau đó cho Xcode biết được chúng ta muốn build trên nền tảng nào. Trong trường hợp này, chúng ta chọn iPhone 7 simulator chạy iOS 10.3.
CODE_SIGN_IDENTITY="" and CODE_SIGNING_REQUIRED=NO cho phép chúng ta override code signing settings mà chúng ta thiết lập trong Xcode. Điều này rất hữu ích, vì nó cho phép CI server build và test không cần code signing, trong khi vẫn không chỉnh sửa dự án của chúng ta.
ONLY_ACTIVE_ARCH=NO đảm bảo rằng chúng ta build cho tất cả các architectures, không chỉ là simulator iOS. Điều này đảm bảo rằng chúng ta không có bất kỳ architectural-specific build errors nào trong dự án của chúng ta.
Cuối cùng –quiet giảm super-verbose output của xcodebuild để chỉ bao gồm warning và error. Điều này là rất hữu ích khi bạn cần phải khai thác vào output của bất kỳ build log để debug. Tất nhiên có những lựa chọn thay thế thay cho việc sử dụng xcodebuild trực tiếp, như sử dụng xctool hoặc fastlane ( cả hai đều được cài đặt sẵn trên bất kỳ Travis macOS VM nào. Trong trường hợp fastlane bạn chỉ đơn giản thực thi các lệnh định nghĩa trong Fastfile của bạn, tạo file .travis.yml tương tự như dưới đây:

language: objective-c
osx_image: xcode9
script:
    - fastlane MyTestLane

Mặc dù Travis yêu cầu bạn thiết lập mọi thứ bằng tay, và có thể đôi khi không ổn định và chậm chạp nhưng nó được sử dụng rộng rãi trong cộng đồng, có nghĩa là bạn dễ dàng nhận được nhiều trợ giúp hơn.

BuddyBuild

Giống như đã đề cập trong tổng quan ở trên, BuddyBuild dựa vào suy luận thay vì yêu cầu bạn setup bất kỳ file nào trong repo của bạn. Đối với ứng dụng iOS, không có nhiều hướng dẫn cần thiết để bắt đầu với BuddyBuild. Giao diện người dùng của nó sẽ hướng dẫn bạn những thông tin cần thiết. Bạn cũng có thể tìm hiểu sâu hơn và tùy chỉnh mọi thứ bằng build script của riêng bạn. Dưới đây là ví dụ setup Swift Package Manager-based project sử dụng BuddyBuild

1. Generate an Xcode project post clone:

Để làm được điều đó, BuddyBuild cần một Xcode project. Nhưng khi sử dụng Swift Package Manager, bạn không nên giữ một Xcode project trong repo của mình, và thay vào đó ad-hoc generate nó khi cần thiết, bạn có thể xem ở ví dụ dưới đây. Thêm tệp buddybuild_postclone.sh vào repo của bạn, với các nội dung sau:

#!/usr/bin/env bash

swift package generate-xcodeproj

Đoạn script trên sẽ được run khi repo của bạn được clone, trước khi bắt đầu build.

2. Run your tests post build

BuddyBuild sẽ tự động build project của bạn nhưng nó run test khi Swift Package Manager được sử dụng. Vì vậy, chúng ta sẽ cần phải làm điều đó bằng tay. Thêm một tệp buddybuild_postbuild.sh vào repo của bạn, với các nội dung sau: