Tag: CICD

Triển khai CI/CD cho iOS – SwiftLint
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:
1. Triển khai CI với SwiftLint
2. Triển khai CI với SonarQube, Blackduck
3. Triển khai CD đơn giản với Gitlab-CI Artifact
4. Triển khai CD In-house với DeployGate.
5. Triển khai CD OTA Inhouse trên Website với AWS S3 (Static Website Hosting)
6. Triển khai CD với Appstore Connect
7. …
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:
```
stages:
  - Lint
lint-source:
  stage: Lint
  only:
      - cicd
  script:
    - swiftlint
```
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:
```
stages:
  - Lint
lint-source:
  stage: Lint
  allow_failure: true
  only:
    - cicd
  script:
    - swiftlint --strict
```
Các job fail khi cấu hình allow_failure = true

Khi ấy, các job phía sau vẫn sẽ được thực hiện, merge request vẫn sẽ được approve nhưng với thông báo Warning đáng chú ý hơn.

Như vậy là đã hoàn thành công đoạn triển khai CI với Swiftlint, ở bài viết tiếp theo, mình sẽ hướng dẫn các bạn triển khai CI với SonarQube, Blackduck

Authors

LinhNB1
August 4, 2021
Triển khai Continuous Delivery cho dự án Serverless Backend với Gitlab-CI và AWS Lambda Function
Article overview

Giả sử chúng ta phát triển một sản phẩm Serverless Backend với AWS Lambda Function và mong muốn áp dụng CD để tự động hoá công việc deploy lên Cloud.
Bài viết áp dụng cho cấu trúc hệ thống git với mỗi một Function sẽ có một branch phát triển riêng. Ví dụ source code cho Function authentication sẽ được lưu ở branch master-authentication.

Tổng quan về các công nghệ sử dụng:
- NodeJS
- Gitlab-CI
- AWS Lambda Function, AWS CLI
- Môi trường MacOS, Linux
Table of contents

Chúng ta cần một số bước sau:
- Liên kết và khởi tạo Runner với Gitlab repository
- Cài đặt và cấu hình môi trường tại thiết bị chạy service runner.
- Cấu hình các job CI/CD với .gitlab-ci.xml và Gitlab-CI.
Cài đặt và cấu hình môi trường tại thiết bị chạy service runner

Đầu tiên, chúng ta cần cài đặt AWS CLI.
Sau khi cài đặt xong, ta thực hiện config với thông tin của AWS User có quyền deploy lên AWS S3 với câu lệnh sau:
```
$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json
```
Cấu hình các job CI/CD với gitlab-ci.xml và Gitlab-CI

Đầu tiên, để có thể update code lên AWS Lambda chúng ta sẽ sử dụng command aws lambda update-function-code.

Command hỗ trợ tham số –zip-file để upload source code dưới dạng .zip file, nên việc đầu tiên chúng ta cần làm là zip source code lại.
zip -r deploy.zip .
Sau khi zip xong, ta thực hiện deploy zip file lên AWS Lambda bằng câu lệnh sau:
```
aws lambda update-function-code --function-name authentication --zip-file fileb://deploy.zip
```
Với authentication là tên của Lambda Function, deploy.zip là tên file zip cần đẩy lên.

Ta sẽ setting command cho package.json như sau:
```
"scripts": {
    "deploy": "zip -r deploy.zip . && aws lambda update-function-code --function-name authentication --zip-file fileb://deploy.zip"
}
```
Tiếp đó, ta sẽ cấu hình .gitlab-ci.yml để hệ thống tự động deploy khi có thay đổi trên nhánh master-authentication.
```
stages:
  - Deployment
deploy:
  stage: Deployment
  before_script: []
  only:
      - master-authentication
  allow_failure: true
  script:
    - yarn install --production 
    - yarn deploy
```
Sau đó merge code vào master-authentication, và hưởng thành quả. Từ giờ các bạn không cần phải deploy bằng tay nữa rồi, chúc các bạn may mắn.

Authors

ThangPV12
August 2, 2021