こんにちは、あるいはこんばんは。
だいたいサーバサイドのエンジニアの(@taclose)です☆
GitHub Copilotが活躍している昨今、弊社ではGitHubで更に開発効率を良くしていこうという流れで日々自動化が行われております。
今回はそんな時代だからこそ求められているGitHub Actionsについて、初心者向けにワークフロー作成の際に知っておきたいコツと教訓について紹介します。
GitHub Actionsのワークフローを読めるけど、まだ自信がないという方はぜひ参考にしてください！
「それもっと早く知っておきたかった！」「初心者がつまづきがちなポイント！」を解説します！
こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。
このプロジェクトで「PostgreSQL環境における、DB定義変更を伴う無停止リリース」にまつわる検証を進めているので、その中間報告を共有しようかと思います。
※本記事はタイトルに「概要と計画」編とあるように、通年で行う調査の前半時点の中間報告となります。
実際の検証結果については3月末に予定している後編をお待ち下さい。
初めまして！新卒1年目のmochi_proteinと申します。
CSR / SSR / SSG / ISRがどのような概念か、
架空アプリを例として、それぞれの違いを初学者向けにやさしく解説していきます！
🔖目次は以下の通りです🔖
こんにちは。SREの gumamon です！
NewRelic、Datadog、モダンな監視ツール(オブザーバビリティ)って良いですよね。弊社もKubernetes(k8s)等を利用した環境が増えてきた折、そろそろ必要になってきたのですが、NewRelic、Datadog等のクラウドサービスはランニングコストが高くなりがちです。 では内製できないかやってみよう！・・・というようなことを昨年度から取り組んでいたのですが、やっとこさ形になりましたので改めてブログで紹介させて頂こうと思います。
今回ご紹介するのは、大まかなシステムの構成と設計時の観点です。各コンポーネントの詳細や工夫できた点などについては、改めて別の記事でご紹介できればと思います。 また、「オブザーバビリティとは？」や「試行錯誤の過程」については、以前執筆した以下のブログをご参照ください。
続きを読む
経費精算システム「楽楽精算」は2009年にリリースされ、15年以上にわたり運用されてきました。 その間、基本的なシステム設計はリリース当初のまま維持されています。 しかし、年月が経つにつれ、技術トレンドやビジネス的な要求は大きく変化しましたが、現状のシステムではそれらの変化に柔軟に対応することが困難になってきています。 システムの柔軟性は低く、機能追加のたびに既存機能への影響を広範に調査する必要があり、既存の処理フローを変えることができないため、イレギュラーなテクニックが必要となることも多く、追加開発のたびに多くの手間とコストがかかるようになってきました。
すべての問題が現行システムに起因するわけではありませんが、特定のミドルウェアに強く依存した構造を持っているため、将来的な技術革新や新しいミドルウェアへの移行が困難であるという課題も抱えていました。 このような背景から、ミドルウェアに依存しない中立的なアーキテクチャが必要であり、その実現のためにリアーキテクチャに近い大規模なリファクタリングが計画されました。
その際に最も懸念されたのは、リファクタリングによる動作不具合のリスクです。 現状では、すべての動作を保証する自動テストが存在しないため、このリスクを無視することはできませんでした。 加えて、仕様書は完全には整備されておらず、初期リリース時から積み重なった変更仕様が複雑に絡み合い、システム全体の動作を統一的に把握することが困難な状況にありました。 このような状況下で、リファクタリングを成功させるためにはどのような対策が必要かが、プロジェクトの大きな課題となりました。
このプロジェクト「リファクタリングに向けた自動インテグレーションの実装」は、こうした背景を踏まえ、動作を保証するためのインテグレーションプロセスを自動化し、リファクタリングを安心して進められる環境を整備することを目指しました。
