いわさです。 先日、AWS CodeBuild を GitLab (GitLab.com) のランナーとして使えるようになったというアップデートアナウンスがありました。 GitLab では CI/CD パイプラインの実行をランナー上で行います。 ランナーには GitLab がマネージドに提供する GitLab-hosted runners と、自己調達したマシン上でビルドなどを実行する self-managed runners（GitHub でいう Self Hosted Runner）があります。 セキュリティやパフォーマンスなど様々な理由から後者を採用するケースもあるのですが、例えば AWS 上に構築しようとすると仮想マシンをプロビジョニングしてランナーのインストールなどセットアップと管理が必要となります。 今回のアップデートで GitLab self-managed runners
![[アップデート] GitLab ランナーとして AWS CodeBuild を使えるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e610a6a29b2c4bb8e2cb856c3d991e5634dfe42/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-741bcce62ea7fdfa232113da6c589b88%2Ff694a222b9ca64455d93ec3eccbafe29%2Feyecatch_gitlab)
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
Tier: Free, Premium, UltimateOffering: GitLab.com, GitLab Self-Managed, GitLab Dedicated This document lists the configuration options for the GitLab .gitlab-ci.yml file. This file is where you define the CI/CD jobs that make up your pipeline. If you are already familiar with basic CI/CD concepts, try creating your own .gitlab-ci.yml file by following a tutorial that demonstrates a simple or compl
はじめにこんにちは、SHIFT の開発部門に所属している Katayama です。 Node.js のプロジェクトに限らずだが、開発をする上では少なからず何かしらの OSS のライブラリに依存する事があると思う。 今回は Node.js を例に、ライブラリを利用する際にそのライブラリのライセンスをチェックする方法についてみていきたいと思う。 結論 どうやるのか？NPM License Checkerとsimple-git-hooks、lint-stagedを利用する。 [study@localhost node-express]$ yarn add --dev license-checker simple-git-hooks lint-staged { ... "scripts": { ... "prepare": "npx simple-git-hooks" }, "lint-stage
自分のプロジェクトで Code Climate を使ってみた時の話をします。 Code Climate とは？ コードの品質とかを測れるサービス OSS なら無料で利用可能 使ってみた結果 私のコードに対して、下記のような指摘が来ました。 Function toCommandSections has 29 lines of code (exceeds 25 allowed). (toCommandSectionsメソッドが29行あるから、25行以下にしてくれ) About 1 hr to fix (1時間あれば直せる) こちらは分かりやすい指摘です。 ただ"1時間で直せる"とは誰がどういう見解で言っているのか納得行きません。 Function read has a Cognitive Complexity of 8 (exceeds 5 allowed). (readメソッドの Cogni
先日の ua-parse-js のハイジャックの件 を受けて、業務の中で毎日動かしている On-premise Renovate の cron を土日祝に停止させたいという話が上がった。 業務の合間に書く時間がちょっと捻出できそうになかったこと、加えて汎用的なコードということもあり、プライベートでも使えそうだったので一般化した範囲でコードを書いてしまって、業務で社内用に調整する形で決着させたので、せっかくなので共有しておく。 社内が基本的に CircleCI なので特化したものと、一般的に使えるものでバリエーションごとに2つのパターンを用意した。 祝日に停止させるアプローチ ひとまず今回は内製の Bot の運用のため、以下のような特徴があった。 土日の設定自体は cron で曜日指定ができるため祝日にフォーカスして良い 厳密性を重視しない ミッションクリティカルな領域の話ではない 以上を考
現在自分が担当しているプロジェクトでは、GitHub Acitionsを利用してデプロイを行っています。 npm ci を使ってパッケージのインストールが行われていましたが、 その際に node_modules をキャッシュしていて意味がない状態となっていました。 - name: Cache Node modules uses: actions/cache@v2 with: path: hoge/node_modules key: ${{ runner.os }}-node_modules-${{ hashFiles('**/package-lock.json') }} - name: Build hoge run: | npm ci npm run build working-directory: hoge これは修正せねば！ということで、調べると npm ci する際は ~/.npm
Azure Pipelinesには、アプリケーションをデプロイするためのリリースパイプラインを、GUIで作る機能がありました。 この機能は大変便利なのですが、既に「Classic」と表現されていて、徐々に消えていく運命にあります。 今からやるなら、ビルド/リリースパイプラインの定義をYAMLで作り、ソースリポジトリと一緒に管理していくのがよい、とされています。 Azure PipelinesにもYAMLを使ったビルドパイプラインを作る機能があるのですが、悲しいかな仮想マシンに対してアプリケーションをデプロイすることが、標準的な方法では準備されていませんでした。 しかし、2019年末のSprint 162で、Azure Pipelinesから仮想マシンにデプロイするための機能が入りましたので、その中身を軽く確認してみようと思います。 Classicなリリースパイプラインで使っていた「Depl
SRE で Microservices を推進している @b4b4r07 です。 メルカリでは全社 (US/UK/JP) 的に Microservices に舵を切る経営指針が打ち出されており、Microservices Platform Team では Microservices として切り出すにふさわしいサービスの再編のサポートや、新規サービスの Microservices 化のサポート、およびそのスタンダードなインフラ基盤の開発などをしています。 本記事ではその中で開発した Developer Productivity の向上につながる小さなツールを、メルカリでの Terraform の活用事例に交えてご紹介します。 メルカリでの Terraform 活用 冒頭に挙げたとおり、少しずついろいろなサービスが立ち上がり始めていますが、そのインフラとして主に GCP (GKE) が使われて
Stop re-writing pipelines! Why GitHub Actions drive the future of CI/CD The Pipeline-as-Code pattern is implemented by most CI/CD platforms today. So what could be the next evolutionary step? Based on GitHub Actions, the article outlines why open-source Pipeline-as-Code Building Blocks will take your pipelines to the next level. GitHub Actions – blog seriesPart 1: GitHub Actions CI pipeline: GitHu
こんにちは、インフラ部の id:sue445 です。 Terraformなにもわからないけどディレクトリ構成の実例を晒して人類に貢献したい - エムスリーテックブログ や Terraformのディレクトリ構成の模索 - Adwaysエンジニアブログ を読んで影響されたのでピクシブのTerraform運用事例を紹介しようと思います。 Terraformの採用理由 GitLabでのリポジトリ構成 Terraformのファイル構成 moduleがうまく使えたと思っている事例 GitLab CIでTerraformをいい感じにCIする テンプレートの使い方 ピクシブで実際に使っているテンプレートファイル このテンプレートでできること masterブランチ以外 masterブランチ このテンプレートファイルのポイント 最後に Terraformの採用理由 Terraformと同じようなプロビジョニン
はじめに 前回のブログでは、マルチアカウントにおけるIAMユーザーの設計戦略についてご紹介しました。 今回は少しテーマを変え、以前筆者がJAWS DAYS 2020で登壇させていただいたCI/CDの内容を基に、データ保護の観点からの設計~実装を取り上げたいと思います。 ※少々お硬い内容を含みますが、AWS CI/CDセキュリティを考える上で一つのポイントになるはずなので、ご興味をお持ちの方は是非お付き合いください。m(_ _)m 前回ご紹介したCI/CD内容のおさらい JAWSDAYS2020にて「金融サービス向けに理想のCI/CDを追い求めたお話」というタイトルで、筆者が担当するサービスのCI/CD設計をご紹介いたしました。 ここで、「理想」という点についてもう一度振り返ると、それは「CI/CD導入により期待すること」と、「業務特性として守らなければならないこと」の両立でした。 高アジリ
2020-07-11: Cloud Buildでの記述が誤っていたので修正しました。 はじめに 今年のゴールデンウィークは暇があり、勤務先で複数のリポジトリを使っているのが辛く感じてきていたため、monorepoについて調べてみました。monorepoについての説明やメリットについては他の記事に譲ります。 www.graat.co.jp この参考記事でmonorepoの本当の課題として挙げられている以下の4点のうち、3点目に相当する「CIで変更によって影響を受けた部分だけをビルドする方法」を調査・検討しました。 トランクベース開発は、より一段と重要になります すべてのサービスがモノレポで上手く動くわけではありません より精巧なCIセットアップが必要です あなたは大規模な変更について考える必要があります この参考記事ではnxが挙げられていますが、nxは主にJavaScriptのプロジェクトを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Use runners with AWS CodeBuild - AWS CodeBuild
https://media.amazonwebservices.com/jp/summit2015/docs/Dev-04d-Tokyo-Summit-2015.pdf
