GitlabのCI/CD初試み

3663 ワード

初心:今日は会社のフロントエンドとテストスタッフがけんかをしました.なぜなら、テストはフロントエンドの人がBugの状態を解決したと文句を言って、結果コードが全然提出されていないのに、フロントエンドの人はテストの測定が頻繁すぎて、いくつかの環境のパッケージを打つのが不便だと文句を言っているからです.物を変えたり、頻繁に梱包したりして時間がかかります.それぞれに理由があるのは、問題を解決する方法を考えないことだ.
まあ、仕方ないですね.この問題を解決するために、GitlabのCI統合を見てみたいと思いますが、これを手に入れることができれば開発はコードだけでいいので、自動的に環境を構築します.
私も今売っています.今日は公式サイトと資料を調べて、基本的な流れを走ったばかりで、途中で時間がかかりました.ここに記録しておきます.
gitlab ci/cdクイックスタート
公式サイトによると、CIを使うには、二つのものを使えばいいです.
1プロジェクトで作成します.gitlab-ci.ymlファイル、このファイルは主にPiplinesとstagesとスクリプトを構成します.gitlab-runnerは、このファイルを実行して環境を構築します.
2 gitlab-runnerをインストールして配置して、1つのGoの書くツール、実行するために.gitlab-ci.ymlの中のスクリプト.

作成します。gitlab-ci.yml

stages:
  - deploy
 
deploy_develop:
  stage: deploy
  tags:
    - nodejs
  script:
    - echo "hello,ci/cd"
  only:
    - dev

上のファイルはpiplines(deploy)を定義し、job(deploy_develop)を定義し、devブランチのみに有効で、このjobを実行すると「hello,ci/cd」が出力されます.

二gitlab-runnerのインストールと構成


このgitlab-runnerはgitlabと1台の機械にいる必要はありません.ローカルの機械でもいいです.逆に公式も単独が一番いいと提案していますが、構築には性能を消費しなければなりません.他の業務に影響を与えなければいいです.
gitlab-runnerのインストールhttps://docs.gitlab.com/runner/install/linux-manually.html私は公式の手順に従って一歩一歩来て、システムはCentosで、もし他のシステムが上のインストール方式に従うならばshell sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64環境変数を設定する必要がある場合は、/usr/local/binをPATHに設定します.
実行可能権限の設定shell sudo chmod +x /usr/local/bin/gitlab-runner gitlab-runner shell sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash用の個別ユーザーを追加
インストールサービスと起動shell sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start

三構成gitlab-runner


gitlab-runnerをインストールした後、登録する必要があります.runnerとgitlabの間でApi通信を通じて
gitlab-runner register

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://172.18.10.22/
上のurlはgitlabのpipelinesの中のSpecific Runnersから探しに行きます

四出会った問題

  • がコードをコミットしてもトリガーされずpendingエラー:This job is stuck,because you don't have any active runners that can run this job.tagsが必要です.gitlab-runner登録時に設定された
  • の値です.
    stages:
      - deploy
     
    deploy_develop:
      stage: deploy
      tags:
        - nodejs
      script:
        - echo "hello,ci/cd"
      only:
        - dev
  • git cloneを使用してコード権限を引き出す問題に遭遇しました.gitlab-runnerをインストールするときに新しいユーザーを使用し、gitlab-runnerのインストールマシンでgit cloneコードを使用して時報権限の問題を使用しました.gitlabに対応する公開鍵をユーザに加える必要がある.ssh/ディレクトリの下
  • 以上のステップを経て、基本的なCIは完成し、以降の開発では、コードを対応するブランチに合わせるだけで、gitlab-ci.ymlの中のシナリオは构筑して、上の会社でちょうどこれを见た时感じがとてもすごいことを覚えていて、ただずっと手を出したことがなくて、今日自分で手を出して试みて印象が深いだけではなくて、感じも以前ほど神秘的ではありません.
    これは基本的なものにすぎません.次にnodejsとwebpackのフロントエンドでこれをパッケージします.これはshellスクリプトを作ってgitlab-ciに定義します.ymlの中でいいです.
    PS:ここは会社の运维を喷かなければならなくて、ふだん何もしないで、4つの运维はふだん1つのバージョンを出す以外に少しも事がなくて、その上环境に関わらず、何に関わらず、これまですべて开発して自分でやっています.オンラインの読み取り専用権限ライブラリを1つも与えないで、安全問題があると言って、オンラインのいくつかの問題は完全に調べることができません.
    そして、もっとおかしい时、オンラインのリリース版は想像できません.私たちが指定したフォルダに圧縮パッケージを作って、それから彼らがもう1台の機械を発表して、いつになったのか、こんなに原始的になっています.この時間があれば、今のツールが効率を高めることをよく研究したほうがいいです.肝心なのは私たちのリーダーもこの考えが少なく、このようなことがずっと抑えられていることです.
    今日Ciをインストールするように、gitlab-runnerは必ずgitlabのマシンにインストールしなければならないと思って、彼らに権限を開いてもらいました.結局、彼らはCiが何なのか聞いたことがなく、安全性がある可能性があるという理由で拒否しました.後に公式ドキュメントを見て、1台のマシンにいなくてもいいと言って、私たちの部門の内部のテストマシンを探してインストールしました.ああ、無言ですね.
    プログラマーの危機の大部分も自分でもたらしたもので、自分で進取したくない.その日淘汰される时、また现実の非情さを责めることができて、このすべてが自分ととても大きい関系があることを知らなければならなくて、とても幸いなことに私はまだずっと努力して、学习の习惯を维持しています.