Gitlab에서 Rails의 지속적인 통합/배포

이 블로그에서 우리는 필요한 절차를 통해 순서대로 Gitlab을 설정할 것이다
모든 것이 순조롭다면 Rails 구축, 테스트 및 배포를 실행합니다.
나는 rails system test과 어떻게 그것을 일하게 하는지에 특별히 관심을 기울일 것이다.
우리는 Heroku를 사용하여 우리의 무대 응용 프로그램을 배치할 것이다.

우리는 무엇을 실현할 것인가?

구축 단계

구축에는 다음이 포함됩니다.

의존항의 설치

데이터베이스 설정

자산 사전 컴파일(자산 및 웹 패키지)

테스트 단계

통합 테스트

이 단계에서, 우리는 모든 집적 테스트를 실행할 것이며, 기본적으로 방향을 바꿀 것이다
실행:bundle exec rails test

시스템 테스트

이것은 우리 CI에서 가장 감동적이고 가장 중요한 부분이다.
시스템 테스트는 대량의 사용이 필요한 복잡한 UI를 테스트하는 데 매우 유용하다
Javascript(Vue 응용 프로그램의 React) 및 외부 서비스(예: Google
Map Places)와 상호작용합니다.
시스템 테스트는 우리 응용 프로그램에서 일반 사용자처럼 입력을 클릭하고 채워서 일반 사용자를 시뮬레이션합니다.
이 단계에서 실행되는 주요 명령은 bundle exec rails test:system입니다.
이런 상황에서 상호작용의 사실은 용기에 Selenium
Chrome browser을 삽입하여 진정한 브라우저를 실행하여 우리의 전단을 얻고 테스트하는 것이다.

배치 단계

이것은 간단한 절차입니다. 우리는 응용 프로그램을 무대에 오르는 환경에 배치할 것입니다.

GITLAB-CI

Gitlab은 모든 사람에게 제공됩니다.
이것은 코드를 테스트/배치하는 방법을 정의하는 레시피입니다
그리고 이 임무에 필요한 모든 서비스
모든 지령은 .gitlab-ci에 저장되어 있으며, 우리가 환매한 루트 디렉터리에 존재한다.
이것은 우리에게 원본 코드와
우리는 계속해서 FREE을 통합한다.

어떻게 작동하는지

CI는 다음과 같은 간단한 절차를 따릅니다.

은 services에 지정된 하나 이상의 용기, 즉 .gitlab-ci을 안내합니다.

은 메인 용기에서 당신의 환매 협의를 복제합니다.

실행에 필요한 모든 스크립트

캐시 가속 CI 사용

Gitlab은 폴더와 파일을 캐시하고 다음 작업에 사용할 수 있도록 합니다.
모든 의존 항목을 다시 컴파일할 필요도, 다운로드할 필요도 없다.
우리의 예에서 모든 gems과 node_modules을 캐시하면 몇 분의 시간을 절약할 수 있습니다.

공작물 디버깅 테스트 사용

시스템 테스트가 실패했을 때 테스트는 screenshots을 temp 폴더에 저장합니다.artifacts은 이 파일들을 저장하고 작업에 연결할 수 있도록 합니다.
우리가 실패한 시스템 테스트를 디버깅하려고 할 때, 이것은 우리에게 매우 큰 도움이 될 것이다.

시작합시다.

1. 구축

컨테이너 생성 준비

구축은 용기에서 실행될 것이기 때문에 우리는 포함해야 한다
내부에 묶여 있는 모든 의존항이 필요합니다.
현대 rails 응용 프로그램에 대해 우리는 다음과 같이 포함해야 한다.

루비

노드 + 사선

일부 시스템 라이브러리

dockerfile입니다.

FROM ruby:2.4.3

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qqy && apt-get install  -qqyy yarn nodejs postgresql postgresql-contrib libpq-dev cmake

RUN rm -rf /var/lib/apt/lists/*

가볍군!
컨테이너 구축

docker build .
Sending build context to Docker daemon  2.048kB
Step 1/6 : FROM ruby:2.6.5
2.6.5: Pulling from library/ruby
16ea0e8c8879: Pull complete
50024b0106d5: Pull complete
ff95660c6937: Pull complete
9c7d0e5c0bc2: Pull complete
29c4fb388fdf: Pull complete
069ad1aadbe0: Pull complete
e7188792d9dd: Pull complete
bae7e74440d1: Pull complete
Digest: sha256:2285f291f222e1b53d22449cc52bad2112f519bcce60248ea1c4d5e8f14c7c04
Status: Downloaded newer image for ruby:2.6.5
 ---> 2ff4e698f315
Step 2/6 : RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
 ---> Running in abb67e50af3e
Warning: apt-key output should not be parsed (stdout is not a terminal)
OK
Removing intermediate container abb67e50af3e
 ---> 461e2dd2134d
Step 3/6 : RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
 ---> Running in 414f508a391c

## Installing the NodeSource Node.js 8.x LTS Carbon repo...

.....
Processing triggers for libc-bin (2.28-10) ...
Removing intermediate container af1183021a8d
 ---> 603cab5f6952
Step 6/6 : RUN rm -rf /var/lib/apt/lists/*
 ---> Running in 53c5950a25c1
Removing intermediate container 53c5950a25c1
 ---> 42b50699301e
Successfully built 42b50699301e

표시

docker tag 42b50699301e registry.gitlab.com/[ORG]/[REPO]/[CONTAINER]:v1

이제 GitlabCI가 사용할 수 있도록 이 용기를 발표해야 합니다.Gitlab은 우리에게 용기 등록을 제공합니다!다시 무료!
그래서 우리는 이 용기를 프로젝트 등록표에 넣기만 하면 된다.
우선,gitlab 등록표에 로그인해야 합니다

docker login registry.gitlab.com
# use your gitlab credential

밀다

docker push registry.gitlab.com/[ORG]/[REPO]/[CONTAINER]:v1 # v1 is my version tag

만약 네가 ADSL의 인터넷 연결이 있다면, 업로드 속도가 매우 느리니, 너는 갈 수 있다
잠깐 자다
일단 다 밀면 우리는 다음 단계를 계속할 수 있다.

구축 스크립트

이것은gitlabci 파일의 주요 구축 부분입니다

image: "registry.gitlab.com/[ORG]/[REPO]/[CONTAINER]:v1"

variables:
  LC_ALL: C.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8
  RAILS_ENV: "test"
  POSTGRES_DB: test_db
  POSTGRES_USER: runner
  POSTGRES_PASSWORD: ""

# cache gems and node_modules for next usage
.default-cache: &default-cache
  cache:
    untracked: true
    key: my-project-key-5.2
    paths:
      - node_modules/
      - vendor/
      - public/

build:
  <<: *default-cache
  services:
    - postgres:latest
  stage: build
  script:
  - ruby -v
  - node -v
  - yarn --version
  - which ruby
  - gem install bundler  --no-ri --no-rdoc
  - bundle install  --jobs $(nproc) "${FLAGS[@]}" --path=vendor
  - yarn install
  - cp config/database.gitlab config/database.yml
  - RAILS_ENV=test bundle exec rake db:create db:schema:load
  - RAILS_ENV=test bundle exec rails assets:precompile

따라서 우리는 이전에 만든 이미지를 사용하여 구축을 주관합니다.
우리는 프로젝트에 config/database.gitlab을 추가하여 원래의 것을 대체해야 한다
데이터베이스 설정 및 사용자 정의 호스트와 인증서를postgres에 연결
GitlabCI 부트 컨테이너입니다.

  services:
    - postgres:latest

Gitlab은 이 줄을 읽을 때 데이터베이스 용기(postgress)와
이전에 정의된 변수를 사용하여 데이터베이스 설정

  POSTGRES_DB: test_db
  POSTGRES_USER: runner
  POSTGRES_PASSWORD: ""

config/database.gitlab은 레일스 응용 프로그램이 어떻게 연결되는지 알려줄 것이다
데이터베이스, 따라서 응용 프로그램이 시작되기 전에 database.yml은
사용자 정의

test:
  adapter: postgresql
  encoding: unicode
  pool: 5
  timeout: 5000
  host: postgres
  username: runner
  password: ""
  database: test_db

2. 통합 테스트 스크립트

더 이상 설명이 필요 없어요.

integration_test:
  <<: *default-cache
  stage: test
  services:
    - postgres:latest
    - redis:alpine
  script:
    - gem install bundler  --no-ri --no-rdoc
    - bundle install  --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - cp config/database.gitlab config/database.yml
    - bundle install --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - RAILS_ENV=test bundle exec rake db:create db:schema:load
    - RAILS_ENV=test bundle exec rails assets:precompile
    - bundle exec rake test

3. 시스템 테스트 스크립트

시스템 테스트를 가능한 인프라 시설로 만드는 것은 매우 흥미롭다.
테스트를 실행하려면 브라우저 (용기에서) 를 시작하고 페이지를 가져와야 합니다
rails 서버에서 왔습니다.

system_test:
  <<: *default-cache
  stage: test
  services:
    - postgres:latest
    - redis:alpine
    - selenium/standalone-chrome:latest
  script:
    - gem install bundler  --no-ri --no-rdoc
    - bundle install  --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - cp config/database.gitlab config/database.yml
    - export selenium_remote_url="http://selenium__standalone-chrome:4444/wd/hub/"
    - bundle install  --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - RAILS_ENV=test bundle exec rake db:create db:schema:load
    - RAILS_ENV=test bundle exec rails assets:precompile
    - bundle exec rake test:system
  artifacts:
    when: on_failure
    paths:
      - tmp/screenshots/

우리는 반드시 복어에게 IP이 아니라 localhost을 사용하라고 알려야 한다. 왜냐하면 여기에 브라우저가 있기 때문이다.
서버와 다른 용기에 있습니다.environment/test.rb에서 다음 행 추가

  net = Socket.ip_address_list.detect{|addr| addr.ipv4_private? }
  ip = net.nil? ? 'localhost' : net.ip_address
  config.domain = ip
  config.action_mailer.default_url_options = { :host => config.domain }

  Capybara.server_port = 8200
  Capybara.server_host = ip

우리는 시스템 테스트에서 브라우저를 제어하기 위해 chrome driver을 어디서 찾을 수 있는지 알려야 한다. application_system_test_case.rb을 업데이트해야 한다

require "test_helper"
require "socket"


def prepare_options
  driver_options = {
    desired_capabilities: {
      chromeOptions: {
        args: %w[headless disable-gpu disable-dev-shm-usage] # preserve memory & cpu consumption
      }
    }
  }

  driver_options[:url] = ENV['selenium_remote_url'] if ENV['selenium_remote_url']

  driver_options
end

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :chrome, screen_size: [1400, 1400],
            options: prepare_options
end

rails system test 캡처를 tmp/screenshots에 저장
{:class="img 응답"}
보시다시피 캡처는 작업에 저장되어 깔끔합니다!

4, 분할 배포

만약 build과 tests단계가 성공한다면, 이것은 우리의 코드를 배치할 것이다.

deploy_staging:
  stage: deploy
  variables:
    HEROKU_APP_NAME: YOUR_HEROKU_APP_NAME
  dependencies:
    - integration_test
    - system_test
  only:
    - master
  script:
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

HEROKU_API_KEY 프로젝트 설정에 저장된 안전한 위치

자세한 내용은 Gitlab variables documentation으로 이동하십시오.

결론

Gitlab은 이루 다 할 수 없는 프로젝트로 매우 좋은 곳을 제공하여 모든 것이 좋다
통합이 양호하여 인코딩 체험을 강화하였다.
마지막으로, 우리는 Google compute engine으로 이전하여 하나를 제공하기를 희망한다
더 좋은 프로젝트의 안정성과 더 적은 문제

Longue vie à Gitlab !!

건배!
이것은 완전한 Gitlab CI file입니다.