ターミナル環境の見直し 2022年末
前回の大改修から5, 6年は経過し、その間ツギハギメンテを繰り返していてだいぶ負債だらけになってきたので一掃する。 結果 こんな感じになった。 端末を良い感じにすると操作効率向上だけでなく、常に端末で作業したくなるし意味もなく毎日カラースキームを変えたり意味もなくpopupを起動したり意味もなく端末を眺めてそれだけでニヤニヤできるぞ。 構成・コンセプト 以前までは見た目を派手にせずプレーンにしていたが、今回はこってり味にする。 あまり頑張りすぎない(大事) 頑張りすぎる(深いところに手を出す)と、plugin公式の改善などですぐにメンテが必要になるので。 環境/見直し対象はMac OS X, Alacritty, tmux, zsh, neovim。 neovimの見直しについてはまた別途。本稿ではそれ以外について記述。 シェルは10年以上zshを使っていて、慣れすぎていて変えられない。
CI設定ファイル「.gitlab-ci.yml」の肥大化を防げ エンジニア1年生が“yaml地獄"から抜け出すためにやったこと
技術とノウハウを武器に、膨大かつ複雑なデータの「検索」「分析」「可視化」といった課題を解決するフォルシア株式会社が「FORCIA Meetup #2」を開催しました。2回目の今回のテーマは「2020年度にエンジニアが取り組んだこと」。六車氏は、CI/CDの整備について発表しました。 管理ツールとして「GitLab」CI/CDツールとして「GitLab CI/CDツール」を利用 六車光貴氏（以下、六車）：六車が『エンジニア1年目の貢献：CI整備を中心に』というタイトルで発表します。まず自己紹介です。六車光貴と申します。ちょっと変わった名前ですが、四国の香川県出身で、香川県だと小学校のクラスに1人はいる名前です。 フォルシアには2020年4月に新卒で入社して、ソフトウェアエンジニアとして働いています。主に大手旅行代理店のサイトの構築をTypeScript、Node.js、React、Next、
テストでlocalstack利用時に起動時のPort待受が完了するまで待機するようにしてみた | DevelopersIO
LocalStackを使ったテスト時に確実にPortが受け付けるまで待機するようにしつつ、テストコード上ではlocalstackの存在を意識する必要がなくなるようにしてみました。 AWSへのアクセスが必要なコードのテスト用途にlocalstackを利用していると、幾つかの課題が出てきます。 localstackを導入していない環境ではエラーになる localstackの起動が完了する前にテストを実行してエラーになる Actions等のCI環境で起動が完了する前にテストが走ってエラーになる 他にも懸念事項はあるかもしれませんが、今回は上記3点についてとった対策について書いてみます。 テストコード内でlocalstackの起動判定を入れる localstackが起動していない場合にエラー扱いとしないために、HTTPリクエストを受付なければskipさせる方法でやってみます。 import req
secretlintが見つけた機密情報をマスクできるようになりました
secretlintは、ソースコードなどから機密情報を見つけて報告するLintツールです。 Gitのpre-commitにhookしてAWSやGitHubなどのトークンのコミットを防止したり、CIで不必要にハードコードされたアクセストークンが入らないようにチェックできます。 SecretlintでAPIトークンや秘密鍵などのコミットを防止する | Web Scratch secretlint を使って機密情報を git commit できない環境を作る | DevelopersIO secretlint 3.3.0では--maskSecretsというオプションをサポートして、見つけた機密情報を報告するときにマスクした値を表示できるようになりました。 Release v3.3.0 · secretlint/secretlint たとえば、次の例は、secretlintで AWS Secret
ようこそdotfilesの世界へ - Qiita
はじめに 少し前から話題になっているが、日本の労働生産性はG7で最も低いらしい。 日本生産性本部資料より https://www.jpc-net.jp/intl_comparison/intl_comparison_2018_press.pdf 日本は人口減少に突入していることもあって、「作業の効率化」や「自動化・省力化」をいうフレーズをあらゆる業種で聞くようになった。 ITエンジニアは、あらゆる職業の中でも最も効率化、自動化をして生産性を高められるといっても過言ではないだろう。プログラマの三大美徳(「怠惰」「短気」「傲慢」)にもあるように、同じことを何度もやらない、楽をするためにがんばるという生産性を意識した感性が重要視されているからだ。 生産性を高めることで、勉強する時間が作れたり、新しいことを経験したりするなどしてさらにスキルアップができ、さらに生産性が上がるという好循環を作り出すこ
GitLab CI/CD から GitHub Actions への移行 - GitHub Enterprise Server 3.1 Docs
はじめに GitLab CI/CD と GitHub Actions は、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 GitLab CI/CD と GitHub Actions は、ワークフローの設定において似ているところがあります。 ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。 ワークフローには1つ以上のジョブが含まれます。 ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。 ジョブは、マネージドマシンまたはセルフホストマシンのいずれかで実行できます。 いくつかの違いがありますので、このガイドでは、ワークフローを GitHub Actions に移行できるようにする際の重要な違いを説明します。 ジョブ GitLab CI/CD のジョブは、GitHub Actions のジョブと非常
GitLab CIで指定ブランチのマージリクエスト作成時（マージ前）にパイプラインを動かす方法 - Qiita
共用開発／ステージング／本番と環境を使い分けているのですが、共用開発まではデバッグビルドのためスルーされていたエラーがステージングへのデプロイ時の本番ビルドでエラーとなってデプロイに失敗するということが多々ありまして。（使ってない変数が存在する等。。。） そんなしょうもないエラーを解決するためにまたローカル環境からやり直すのは時間の無駄だな～。もっと早い段階で潰したいな～。と思って調べてみたら、指定ブランチのマージリクエスト作成時にパイプラインを動かす方法があったので試してみました。 〇環境 ローカル環境（feature/～ブランチ） 共用開発環境（developブランチ） ステージング環境（stagingブランチ） ※HEROKU 本番環境（masterブランチ） ※HEROKU プロジェクト構成 Node.js＋Angular＋Express.js 〇マージリクエスト作成時に
GitLab CIを四倍速にした話 - astamuse Lab
chotaroです。豊洲PITでたくさんの人と頭の中のOMOIDEを共有してから一週間、興奮冷めやらぬ日々です。 astamuse lab年内最後の記事になります！ さて先日、ICPチームで利用しているGitLab CIの実行時間を4分の1にしました。 一度CIを動かすと1時間強待ちが発生する状況になっていたため、改善が急務でした。改善の結果と、どんなことをしたか自分の備忘も兼ねて書いておこうと思います。 悩める人の参考になれば嬉しいです。 before/after 10月に改善を実施したので、9月と11月の比較になります。 月 pipeline実行回数 合計実行時間(時間[分]) 平均実行時間 9月 164回 114時間[6880分] 0:41:57 11月 106回 15時間[945分] 0:08:55 1回のpipelineにかかる時間がなんと4分の1以下になりました(๑•̀ㅂ•́)
CodemagicでiOSのネイティブアプリをCIに載せる | DevelopersIO
Flutter専門のCI/CDサービス Codemagicでネイティブアプリのビルドやテストが行えるそうなので試してみました。 Flutter専門のCI/CDサービスとして開始されたCodemagicはアップデートによりネイティブアプリでも同等に扱えるようになりました。この記事ではcodemagic.yamlファイルを使ったネイティブアプリのCI/CD設定方法を説明します。 GUIで直接AndroidやiOSのネイティブアプリをビルドすることはできませんが、ネイティブアプリをビルドするためにcodemagic.yamlを使って簡単に設定することができます。 導入 Codemagic - CI/CD for Flutter and mobile app projectsにログインします。 Applications overviewで任意のプロジェクトを選択（ここではネイティブのiOSアプリの
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
GitHubは普通の会社とどう違うのか？ リリースマネージャーがいない（いる必要がない） 週次のデプロイセットもありません（この週にこれだけの機能をまとめてリリースとかがない） 開発者とデザイナーは、早く提供できるように自分たちでデプロイする（できる）作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Autoscaling GitLab CI on AWS Fargate | GitLab
CI/CD YAML syntax reference | GitLab
rjとtとjqコマンドでHTTPレスポンスを試験する - ゆーすけべー日記
10 GitHub Actions resources to bookmark from the basics to CI/CD
GitLab CI - Trivy
trivy/contrib/Trivy.gitlab-ci.yml at main · aquasecurity/trivy
Files · master · GitLab.org / cloud-deploy · GitLab
GitLabとAWS CodePipelineを使ってAWS ECS/FargateのCI/CD - KeisukeYamashita
Run your CI/CD jobs in Docker containers | GitLab
Test and deploy Laravel applications with GitLab CI/CD and Envoy | GitLab