Xin chào mọi người,
Chúng ta đã quá lâu không gặp lại nhau rồi đúng không?
Như đã nói từ kì trước, để tiếp tục series "Gitlab CI/CD cho người mới bắt đầu", thì ở bài này mình sẽ viết về cách set-up local gitlab runner, cụ thể hơn, chúng ta sẽ setting 1 runner qua Docker.
Tại sao lại là Docker chứ không phải là trên Window hay MacOS? Mình chọn Docker vì nó đơn giản với những người mới, cộng với tính linh động của nó trên nhiều môi trường khác nhau.
Vì vậy, nên để có thể tiếp tục với tutorial này thì việc đầu tiên bạn cần làm là có docker ở trên máy của mình.
(Bạn có thể xem hướng dẫn tải và cài đặt tại đây)
Nếu bạn đã cài đặt thành công Docker trên máy, thì chúng ta sẽ bắt đầu vào phần chính ngay thôi.
Về cơ bản thì việc khởi tạo và chạy runner qua Docker này sẽ trải qua 2 bước:
(Chi tiết có thể xem tại đây)
The most powerful tool we have as developers is automation.
Scott Hanselman
Overview
Tiếp tục với series triển khai CD cho iOS, hôm nay chúng ta sẽ tìm hiểu cách chạy CD để đẩy một ứng dụng lên App Store Connect một cách tự động.
Có rất nhiều doanh nghiệp, dự án chọn App Store Connect & TestFlight làm nền tảng để Test sản phẩm, đăc biệt với các sản phẩm gần thời điểm lên App Store. Thêm một sự tiện lợi nữa đến từ TestFlight, khi có phiên bản mới được upload lên sẽ có thông báo về cho các thiết bị cài đặt TestFlight. Vậy nếu triển khai CD để tự động đưa ứng dụng lên App Store Connect, ta cũng sẽ có một hệ thống thông báo tự động khi quá trình hoàn tất mà không cần triển khai thêm gì.
Quan trọng: Để sử dụng được phương thức này ta cần chú ý một số điểm sau:
Tạo sẵn App trên App Store Connect với đúng bundle id
Bản build sau bắt buộc phải có version/build number lớn hơn version/build number của bản trước đó
Distribute và Upload IPA sử dụng Command Line
Sẽ không có nhiều khác biệt giữa phương thức Archive và Export của phiên bản App Store với các phiên bản khác, ta vẫn sẽ sử dụng các câu lệnh cũ, tuy nhiên phần export sẽ không cần tham số -exportPath:
Cần thêm có key destination với value upload để cấu hình việc tự động upload ipa thay vì export file.
Cấu hình .gitlab-ci.yml cho GitlabCI
Với phương thức này, ta chỉ cần đơn giản cấu hình file .gitlab-ci.yml như sau:
stages:
- deploy
deploy_appstore:
stage: deploy
script:
- echo 'Hello bitches, welcome to lazy boys world!'
- echo 'Just commit code, serve yourself a cup of coffee. Let gitlab build your app!'
- xcodebuild archive -archivePath "cicd-test" -scheme cicd-test
- xcodebuild -exportArchive -archivePath "cicd-test.xcarchive" -exportPath "ipa" -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates
tags:
- main
Kết quả log của Job khi upload thành công trên Gitlab sẽ trông như sau
Log của quá trình upload App lên App Store Connect
Như vậy là đã hoàn thành việc cấu hình CD upload ứng dụng lên App Store Connect. Ở bài viết tiếp theo, chúng ta sẽ cùng tìm hiểu cách triển khai CD cho ứng dụng iOS theo phương thức OTA với các Website đang Deploy trên AWS S3 😀
Một ngày đẹp trời, anh ấy nhận được một cái mail giới thiệu anh là chuyên gia về tài khoản Apple… đó chính ngày định mệnh mở ra con đường Enterprise. Many thanks anh Vũ Béo, người nhanh tay mang ánh sáng về và đặt những bước chân đầu tiên.
Sam
Overview
DeployGate hỗ trợ rất nhiều chế độ Distribution, tuy nhiên để tạo ra sự đa dạng cho series, ở bài viết này chúng ta sẽ sử dụng Enterprise (In house) kết hợp với DeployGate để tạo thành một quy trình CD.
Nói thêm một chút về DeployGate, đây là một nền tảng hỗ trợ phân phối ứng dụng di động (iOS & Android). Người dùng có thể upload app package (ipa & apk) lên và chia sẻ link cài đặt cho người khác. Sử dụng DeployGate, Tester sẽ không cần phải cài đặt ứng dụng trực tiếp với ipa hay apk file, và cũng không cần sử dụng Window hoặc MacOS để cài đặt. DeployGate cũng giảm bớt sự phụ thuộc của người dùng trong quá trình test vào Test Flight khi thời gian process một số ứng dụng có thể lên tới hàng chục giờ đồng hồ.
Bài viết sẽ gồm có 3 phẩn:
Distribute IPA sử dụng Command Line
Cấu hình DeployGate để upload IPA bằng Command Line
Cấu hình file .gitlab-ci.yml cho GitlabCI
Distribute IPA sử dụng Command Line
Bước đầu tiên của quá trình vẫn là tạo ra được file IPA để upload lên Deploy Gate. Như ở bài trước đã hướng dẫn, ta sẽ sử dụng các câu lệnh sau để thực hiện tạo ra file IPA.
Sau khi export xong, chúng ta sẽ có một file IPA với đường dẫn tương đối so với vị trí của runner như sau:
ipa/cicd-test.ipa
Việc tiếp theo sẽ là upload file IPA lên DeployGate.
Cấu hình DeployGate để upload IPA bằng Command Line
Đầu tiên chúng ta cần upload ít nhất một bản IPA lên Deploy Gate, sau đó bật Distribution lên bằng cách ấn vào nút Add a link for sharing trong ảnh sau:
Ấn vào button [+ Add a link for sharing] phía bên phải
Sau đó, trang web sẽ điều hướng đến Distribution Page, đừng hoảng, ta chỉ cần copy đường dẫn của trang đó là được. Đường dẫn sẽ có dạng như sau:
Response trả về sẽ có dạng Json như sau, nếu error = false thì tức là quá trình upload thành công.
Response trả về của Curl upload IPA lên Deploy Gate
Refresh lại Dashboard của app ta sẽ thấy có một bản build mới được upload lên với message “New distribution” như ảnh sau:
Bản build đã lên với message đi kèm
Tiếp tục qua trang Update Distribution, ta sẽ thấy bản build mới upload sẽ tự động được cập nhật thành phiên bản được phân phối với Release Notes là “Release Note”.
Bản build vừa upload được tự động phân phối với Release Note mới
Như vậy là ta đã hoàn thành việc upload và cập nhật bản build trên Deploy Gate một cách tự động. Tiếp đến là cấu hình các câu lệnh trên vào file .gitlab-ci.yml.
Cấu hình .gitlab-ci.yml cho GitlabCI
Rồi, lại tới công chuyện tiếp! Đầu tiên ta cần ném các thông tin Key của Deploy Gate vào mục Variables thay vì setting cứng trong file.
Luôn đặt các thông tin key, môi trường vào Variables
Tiếp đến, nội dung của file .gitlab-ci.yml cơ bản sẽ như sau:
stages:
- build
build_project:
stage: build
script:
- echo 'Hello bitches, welcome to lazy boys world!'
- echo 'Just commit code, serve yourself a cup of coffee. Let gitlab build your app!'
- xcodebuild archive -archivePath "cicd-test" -scheme cicd-test
- xcodebuild -exportArchive -archivePath "cicd-test.xcarchive" -exportPath "ipa" -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates
- Curl -H "Authorization: token ${API_KEY}" -F "file=@ipa/cicd-test.ipa" -F "message=New distribution" -F "distribution_key=${DISTRIBUTION_KEY}" -F "release_note=Release Note" "${USER_API_HOST}"
tags:
- main
Vậy là xong, sau khi code được commit/merge vào main, GitlabCI sẽ tự động chạy Jobs build IPA và đẩy lên DeployGate. Hẹn gặp lại các bạn ở bài viết tiếp theo!
P/S: Sẽ rất tiện lợi nếu có thể cấu hình để tuỳ chỉnh Upload Message, Release Note để ghi các thay đổi cho Tester hay thông báo khi có bản build mới lên Deploy Gate. Nên mình sẽ dành riêng một bài trong series để hướng dẫn cách cấu hình các tuỳ chỉnh này.
Ngày đông giá rét, thay vì ngồi dài cổ đợi ae commit code lên để build cho Tester. Bạn có thể đơn giản add Tester vào Gitlab, cài một con CD Artifact đơn giản và ném vào mặt nó phần việc nhàm chán kia. Còn bạn có thể nhàn nhã mò ra Highlands, nhâm nhi cốc cafe nóng và xem cơm chó của ngày Noel buồn…
Sam, gửi Cương Good, Anh Mẹc và Very Good Team
Overview
Tiếp tục với series CI/CD cho iOS, hôm nay chúng ta sẽ chuyển sang chuyên mục CD với phương thức Deploy đơn giản nhất – GitlabCI Artifact.
Vì đây là bài viết đầu tiên liên quan đến CD, chúng ta sẽ cần đề cập đến phương thức Archive và Distribute ứng dụng sử dụng command line.
Distribute IPA sử dụng Command Line
Để triển khai CD, mọi công việc đều phải thực hiện thông qua Shell Command, do đó từ các công việc Build, Test, Archive hay Distribute IPA đều phải thực hiện bằng các câu lệnh. Rất may, Apple cung cấp sẵn một bộ Command Line Tools được tích hợp kèm với Xcode, ta có thể sử dụng ngay khi máy đã cài đặt Xcode. Các bạn có thể tham khảo hướng dẫn các command tại đây.
Đầu tiên, chúng ta sẽ cài đặt setting project sang Automatic Signing, đảm bảo thiết bị chạy runner đã đăng nhập tài khoản hợp lệ và build thành công App bằng Xcode.
Setting Automatically trong Xcode
Sau khi thành công, ta sẽ thử build project bằng câu lệnh với cú pháp:
xcodebuild build -scheme cicd-test
Với tham số -scheme là chỉ định scheme/target để build.
Build thành công Project trên Terminal
Sau khi thành công, chứng tỏ là project đã được setting đúng cách, chúng ta sẽ thực hiện archive App bằng câu lệnh sau:
Với tham số -archivePath chỉ định tên và đường dẫn export ra .xcarchive file.
Sau khi chạy xong, chúng ta sẽ thấy có một file được export ra với tên cicd-test.xcarchive trông như ảnh sau:
Output của quá trình archive app
Sau khi đã có .xcarchive file, chúng ta cần thực hiện export ra IPA file. Để export được IPA file, chúng ta cần một file ExportOptions.plist, ở đây chúng ta sẽ export bằng chế độ adhoc, file sẽ có nội dung như sau:
-exportPath: Chỉ định thư mục sẽ export ra file IPA
–exportOptionsPlist: Chỉ định file chưa các config export
-allowProvisioningUpdates: Cần phải có nếu Project setting chế độ Automatic Signing. Không cần sử dụng nếu setting manual signing.
Sau khi export xong, chúng ta sẽ nhận được file IPA ở thư mục như hình sau:
Vị trí file IPA được export ra
Như vậy là ta đã tạo xong file IPA, tiếp đến sẽ là setting với GitlabCI
Cấu hình .gitlab-ci.yml cho GitlabCI
Rồi tới công chuyện, giờ chúng ta chỉ cần chuyển toàn bộ các câu lệnh ở trên vào phần script của file .gitlab-ci.yml và cấu hình để GitlabCI nhận file IPA làm Artifact là xong.
File .gitlab-ci.yml cơ bản sẽ có nội dung như sau:
stages:
- build
build_project:
stage: build
script:
- echo 'Hello bitches, welcome to lazy boys world!'
- echo 'Just commit code, serve yourself a cup of coffee. Let gitlab build your app!'
- xcodebuild archive -archivePath "cicd-test" -scheme cicd-test
- xcodebuild -exportArchive -archivePath "cicd-test.xcarchive" -exportPath "ipa" -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates
tags:
- main
artifacts:
paths:
- ipa/cicd-test.ipa
Sau đó, hãy commit các thay đổi lên và chờ đợi thành quả!
Thành quả của quá trình là đây
Như bạn thấy trong ảnh trên, phía bên phải của Jobs Detail sẽ có một section để tải về Job Artifacts chứa file IPA có thể cài được. Ở đây, ta chỉ cần ấn nút Download IPA thực hiện cài đặt ứng dụng vào điện thoại.
Như vậy là ta đã hoàn thành cấu hình CD đơn giản cho iOS với GitlabCI Artifact. Hẹn gặp các bạn ở bài viết tiếp theo.
Chắc hẳn mọi người đã từng nghe tới CI-CD, rồi thắc mắc không biết nó là gì và chúng ta có thể làm gì với nó? Mình cũng như vậy, thắc mắc ấy đưa mình đến việc viết chuỗi bài này để chia sẻ về những gì mình đã học được về CI-CD.
Trong bài này thì mình sẽ tập trung vào CI, cũng như cách config file .gitlab-ci.yml và chạy trên share runner của gitlab.
I. Vậy CI-CD là gì?
CI (Coutinous Integration) – tích hợp liên tục, là quá trình mà code của chúng ta được build và test trước khi tích hợp vào nhánh chính.
CD (Continous Delivery) – truyền tải liên tục, là quá trình mà code được triển khai lên môi trường như development hoặc production, và nó diễn ra ngay sau CI
II. Triển khai CI như thế nào?
1. Thành phần
Để có thể triển khai được CI thì trước hết, chúng ta cần biết về 2 thành phần chính cấu thành nên nó. Đó là file gitlab-ci.yml và gitlab runner.
Mọi người có thể hiểu nôm na nếu gitlab runner như một anh tài xế mà bạn thuê, anh ta rất nhiệt tình, sẵn sàng lái xe đi bất cứ nơi đâu thay cho bạn, nhưng khổ nỗi anh lại không biết đường. Hmm… Làm sao bây giờ? File gitlab-ci.yml lúc ấy xuất hiện như một tấm bản đồ vạn năng.
File này sẽ được gitlab tự động nhận diện khi bạn commit code lên từ local, và sẽ cấp cho bạn một anh "tài xế" shared runner để đi làm những việc bạn đã vạch sẵn ở trong gitlab-ci.yml.
Lưu ý:
Mặc định, gitlab có một số share runner mà người dùng có thể dùng ngay lập tức. Vì vậy, đối với một project vừa và nhỏ, số lượng job cho runner còn ít, thì bạn có thể tận dụng luôn những runner đã có sẵn này. Nhưng với một project lớn hơn, khi mà số lượng cũng như tần suất chạy job ngày càng tăng lên, thì chúng ta nên config riêng một gitlab-runner trên server của mình.
2. Template
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job:
stage: test
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job:
stage: test
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job:
stage: deploy
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
Templete cho một file gitlab-ci.yml
Chúng ta sẽ cùng nhau đi qua một lượt xem nó có ý nghĩa gì nhé!
Đầu tiên là stages: đây sẽ là khi chúng ta định nghĩa ra các giai đoạn mà trong pipeline, hay nói cách khác là các job mà runner sẽ phải thực hiện. Như đa số project, workflow sẽ bao gồm 3 giai đoạn, đầu tiên chúng ta sẽ tạo ra một bản build của project, tiếp sau đó sẽ test, và khi đã qua được các bước trên thì sẽ deploy lên môi trường development, staging hay production.
stages:
- build
- test
- deploy
Tiếp theo, chúng ta sẽ đi cụ thể tới các build stage nha (Các giai đoạn sau cũng tương tự).
build-job là tên của job, cái này các bạn có thể tự thay đổi theo ý mình nhé.
stage chỉ ra job này đang nằm trong giai đoạn nào trong 3 stages mà chúng ta đã định nghĩa trước ở trên.
script là những câu lệnh mà chúng ta sẽ chạy trong job này.
Ngoài ra thì còn rất nhiều những thông tin config khác mà các bạn có thể tìm ở đây nha!
Và như bạn đã thấy ở templete trên, thì một pipeline có thể có nhiều giai đoạn và một giai đoạn có thể chứa nhiều job khác nhau và các job đó có thể được thực hiện song song.
3. Ví dụ
Mình sẽ lấy ví dụ từ bẳng việc check lint của một project nodejs nha!
Bước 1: Chúng ta sẽ phải cài đặt eslint và babel-eslint cho project của mình.
npm install eslint babel-eslint --dev
Bước 2: Tạo file .eslintrc để config lint rule mà mình muốn:
Bước 3: Thêm script cho việc check lỗi và fix lỗi lint trong file package.json
Trong dấu "{}" ở câu lệnh lint là các folder mà mình muốn check lint, các bạn có thể để folder khác cho phù hợp với project của mình nhé!
Bước 4: Chạy lần lượt hai câu script trên và đẩy code lên git.
Bước này là để trước khi các bạn check xem những nhánh phụ merge vào có đúng theo rule lint mình đã định nghĩa không, thì nhánh chính của mình đã thỏa mãn những rule đó từ trước.
image: dùng base image là node:12.18-alpine để tạo một node instance chạy các câu lệnh mình định nghĩa ở phần script
only và refs: giới hạn việc chạy job này chỉ khi có merge request
Bước 6: Tách nhánh mới, đẩy lại code lên gitlab và tạo merge request
Đây là ở merge request trước khi chúng ta đẩy file gitlab-ci.yml lên remote repo
Sau khi đẩy file gitlab-ci.yml lên
Bây giờ nếu như mọi người thấy biểu tượng pipeline running như hình 2 ở trên là mình đã thành công rồi nha!
Từ bây giờ mỗi khi bạn đẩy code mới lên remote repository thì gitlab runner sẽ tự động chạy test lint cho chúng ta!
Nếu thích bài viêt này thì các bạn nhớ like and và share để ủng hộ mình có động lực viết phần tiếp theo về gitlab runner và CD nha <3
P/s: Đây là bài viết đầu của mình nên không thể tránh khỏi những thiếu sót, có gì mong được mọi người bỏ qua và góp ý cho mình nha!
Cảm ơn mọi người nhiều <3
Tiếp tục với series CI/CD cho iOS, hôm nay chúng ta sẽ triển khai CI với hai nền tảng kiểm tra source code rất nổi tiếng là SonarQube và Blackduck.
Triển khai CI với Blackduck
Khác với SonarQube, Blackduck không đánh giá chất lượng mà giúp chúng ta quản trị open source code và source code từ các thư viện được thêm vào. Giúp chúng ta đánh giá và quản lý được các rủi ro về bản quyền, bảo mật khi sử dụng source code có sẵn trên mạng cũng như lưu hành trong cộng đồng.
Do Blackduck không có Server public như Sonar, nên mình sẽ giả định chúng ta có một Server Blackduck được đặt tại địa chỉ sau:
Sau khi truy cập vào, chúng ta sẽ thấy danh sách các project đã có ở Dashboard. Ở đây mình đã tạo sẵn một Project W95.CICD, nếu muốn tạo mới chúng ta sẽ ấn nút Create Project ở góc trên bên phải.
Dashboard của Blackduck
Cũng giống như Sonar, để có thể đồng bộ các dữ liệu Scan chúng ta cần có một Token. Để tạo Blackduck Token, chúng ta sẽ vào màn hình quản lý Access Tokens như sau:
Ấn vào Profile ở góc trên bên phải, chọn My Access Tokens
Sau khi chuyển đến màn hình quản lý Access Token, chúng ta ấn Create New Access Token và điền thông tin.
Màn hình quản lý Access Tokens
Nhập thông tin và ấn Create
Sau khi có token, chúng ta sẽ lưu lại để sử dụng sau này. Lưu ý, token sẽ không hiển thị lại lần thứ 2 nên hãy copy và lưu lại ngay và luôn nhé. Ví dụ mình sẽ lưu lại token lại dưới đây:
YWJmYzc5MDMS05N2VjLWFkNGE4ZMS05N2VjLWFkNGE4Z--=/
Đối với Blackduck, chúng ta cũng sử dụng gần giống như Sonar nhưng thay vì CLI, chúng ta sẽ sử dụng Java Archive, vì vậy hãy đảm bảo bạn đã cài Java trong thiết bị Runner nhé.
Tải về phiên bản .jar mới nhất của blackduck ở đây
Sau khi tải xong, chúng ta sẽ giải nén và lưu và một thư mục trong thiết bị Runner, ở đây mình sẽ lưu ở địa chỉ sau:
Vậy là xong, mỗi khi có commit/merge lên nhánh cicd (hãy thay bằng master/main/develop) thì hệ thống sẽ tự động scan source code và gửi kết quả lên Server.
Quên mất, còn một bước cuối cùng nữa là bạn có thể che đi các thông tin nhạy cảm trong file cấu hình .gitlab-ci.yml, đề phòng trong trường hợp file cấu hình bị rò rỉ, các thông tin về Server Blackduck cũng như Token cũng sẽ không bị ảnh hưởng. Để làm việc này chúng ta sẽ cấu hình một số thông tin sau vào biến môi trường của Gitlab-CI
Rồi xong, tới công chuyện luôn!! Như vậy là chúng ta đã hoàn thành cấu hình CI với Blackduck để scan các lỗi hổng bảo mật, bản quyền. Mặc dù liên quan đến CI còn rất nhiều section như Coverity, Build & Compile nhưng mình xin phép tạm dừng hạng mục CI và chuyển sang CD. Rất mong được các bạn ủng hộ.
Tiếp tục với series CI/CD cho iOS, hôm nay chúng ta sẽ triển khai CI với hai nền tảng kiểm tra source code rất nổi tiếng là SonarQube và Blackduck.
Triển khai CI với SonarQube
Đôi chút về SonarQube, đây là một nền tảng mã nguồn mở sử dụng để kiểm tra chất lượng của source code, đánh giá các lỗi ở nhiều mức độ và tiêu chí khác nhau. Mục đích cuối cùng là để thống kê và cải thiện chất lượng của source code theo mọi mặt cũng như giúp lập trình viên đánh giá chất lượng của chính mình. Vì vậy, việc sử dụng SonarQube để hỗ trợ quá trình phát triển, nâng cao chất lượng source code luôn được các doanh nghiệp lớn áp dụng.
Chúng ta sẽ thực hiện CI với SonarQube server ở địa chỉ sau: https://sonarcloud.io, bạn có thể sử dụng tài khoản GitLab của mình để đăng nhập và tạo project ở đây. Sau một vài bước đăng nhập, tạo organization và chọn plan thì chúng ta sẽ đến với step đầu tiên.
Đối với một số trường hợp có Server riêng để host SonarQube, các bạn hãy truy cập host và sử dụng tài khoản/mật khẩu được cung cấp bởi admin.
Cấu hình SonarQube
Việc đầu tiên, chúng ta sẽ cần tạo một project, ở đây mình sẽ tạo một project như hình sau:
Điền Project Key và Display name sau đó ấn Set Up
Trong một số trường hợp, bước config tạo Project sẽ do admin tạo, các bạn chỉ cần đăng nhập là xem được các project mình được phân quyền.
Sau khi ấn Set Up, chúng ta sẽ được suggest 3 lựa chọn, ở đây mình sẽ chọn Manually để có thể sử dụng ở nhiều nền tảng khác nhau (Không chỉ riêng GitLab-CI).
Lựa chọn Manually
Tiếp đó chúng ta sẽ chọn các lựa chọn như hình sau:
Chọn Other(…) -> macOS
Tiếp đó chúng ta ấn Download để tải CLI của SonarQube về, giải nén và lưu vào một thư mục trong thiết bị runner. Giả sử mình sẽ lưu ở địa chỉ sau:
/Users/jena/Projects/sonar-scanner/bin
Mình sẽ thêm thư mục bin vào trong PATH của macOS bằng câu lệnh sau
Sau đó, bạn có thể chạy lệnh sau để kiểm tra xem cli đã được nhận vào PATH chưa. Sẽ có một số lỗi yêu cầu cấp quyền để chạy CLI, bạn hãy vào System Preference -> Security & Privacy -> Tab General -> Allow Anyway tất cả
sonar-scanner -v
Sau khi cli được add vào PATH, bạn có thể chạy bằng lệnh sonar-scanner
Tiếp đó, chúng ta sẽ vào GitLab và cài đặt biến môi trường SONAR_TOKEN như hình sau
Tiếp đó, chúng ta sẽ cấu hình CI ở file .gitlab-ci.yml như sau, phần script sẽ được gen cùng với SONAR_TOKEN, các bạn chỉ cần copy và paster vào là được:
Sau khi commit file .gitlab-ci.yml lên branch cicd, chúng ta sẽ có kết quả như sau:
Job Sonar Scanner chạy thành công với log như trênMàn hình thống kê trên SonarCloud.io cũng sẽ hiển thị các thông số của source code
Theo như ảnh trên, Quality Gate đang đánh giá Passed tức là source code đạt chất lượng, nhưng thật ra mình scan Starter Project của iOS nên mới không có lỗi, còn code của mình thì lắm lỗi lắm :p
Như vậy là chúng ta đã hoàn thành bước cấu hình CI sử dụng SonarQube cho một project iOS. Mỗi khi có commit, merge hay sự thay đổi trên branch cicd (bạn sẽ đổi thành master/develop/main) thì hệ thống sẽ tự động chạy CI và đẩy thống kê lên Sonar server. Chúng ta chỉ cần lên đó, tracking các thông số và sửa các lỗi bị cảnh báo là được.
Do bài viết hơi dài, nên mình sẽ để phần Blackduck sang bài viết sau. Cảm ơn các bạn đã đọc!
Hưởng ứng theo tinh thần của Editor team, mình đóng góp Series này để hưởng ứng Technopedia, không nhằm mục đích dự thi. Mong rằng các kinh nghiệm của mình sẽ giúp ích được cho cộng đồng trong lĩnh vực liên quan.
Sam
Để triển khai CI/CD cho một sản phẩm iOS có rất nhiều lựa chọn, chúng ta có thể sử dụng GitLab-CI, Xcode Server, Fastlane, Jenkins, Microsoft App Center, Circle CI, … Ở phạm vi bài viết này, chúng ta sẽ đề cập đến một nền tảng được tích hợp với GitLab: GitLab-CI
Việc triển khai CI/CD cho một dự án iOS Swift bao gồm một số phần sau:
Triển khai CI với SwiftLint
Triển khai CI với SonarQube, Blackduck
Triển khai CD đơn giản với Gitlab-CI Artifact
Triển khai CD In-house với DeployGate.
Triển khai CD OTA Inhouse trên Website với AWS S3 (Static Website Hosting)
Triển khai CD với Appstore Connect
…
Cài đặt và khởi tạo Runner
Đầu tiên, các chúng ta cần cài đặt và khởi tạo Runner cho Gitlab Repo. Mình có viết một bải hướng dẫn ở đây Chú ý: Sau khi đăng ký runner, nhưng các job vẫn chạy trên container mặc định của GitLab-CI thì hãy chạy các lệnh sau:
gitlab-runner install
gitlab-runner start
gitlab-runner status
1. Triển khai CI với SwiftLint
Đầu tiên, chúng ta sẽ đi đến việc cấu hình CI sử dụng SwiftLint để phân tích chất lượng source code.
Tốt nhất chúng ta sẽ cài đặt và sử dụng Swiftlint tách biệt với source code của dự án như sau
brew install swiftlint
Sau khi cài đặt Swiftlint, ta có thể test bằng cách di chuyển vào thư mục root của source code và chạy lệnh
swiftlint
Kết quả lint source code sẽ hiển thị như sau, ví dụ ở đây ta có 16 lỗi.
Sau đó, chúng ta cấu hình file .gitlab-ci.yml để chạy lint trên branch cicd như sau:
Kết quả khi commit code lên branch cicd, chúng ta sẽ có kết quả log như sau:
Mặc định Swiftlint job sẽ trả về kết quả thành công exit 0
Ở đây chúng ta thấy, hệ thống đã phát hiện được 16 lỗi ở 3 files code. Tuy nhiên, job vẫn success và các merge request vẫn được phép tiếp tục vì Swiftlint vẫn trả về success thay vì error. Đây là một rủi ro, và để ép chặt các thành viên phải fix hết các lỗi Swiftlint trước khi được merge code, ta sẽ thêm tham số vào script như sau:
script:
- swiftlint --strict
Kết quả thu được, hệ thống scan code và trả về lỗi nếu swiftlint chưa được fix hết.
Swiftlint job sẽ trả về lỗi exit 1 khi sử dụng tham số –strict
Trong trường hợp chúng ta muốn “dễ dãi”, cho phép merge code trong trường hợp các lỗi swiftlint vẫn còn hoặc muốn job trả về thành công để tiếp tục các job tiếp theo, ta sẽ cấu hình thêm một chút như sau:
