Harness Blog

この記事では、Source Code Manager（SCM）について、SCMの重要性、DevOpsでの使い方、そしてHarnessが開発者の仕事を楽にするためGitHubとBitbucketを活用していることについて説明します。

この記事では、DevOpsにおけるソースコード管理（SCM）と、Harnessがどのようにそれを支援するかについて説明します。

CI/CDとフィーチャーフラグは、バットマンとロビンのような関係です。単独でも強く、力を合わせれば向かうところ敵なしです。統合パイプラインの価値について見ていきましょう。

ソフトウェアをより速くより安全に提供する必要性は、当然の帰結です。エンジニアリングチームは、以前より速くソフトウェアを提供し、かつシステムにそれ以上のリスクをもたらさないよう常に努めています。

社内実践の醍醐味：Harness社がHarness CDをどう使っているか紹介します。CIとCDのセットアップ、そしてなぜCDにこれほどまでに投資しているのか、その全てをご紹介します。

継続的デリバリー（CD）とは、ソフトウェア開発プロセスにおいて、あらゆる種類の変更の構築、テスト、設定、およびデプロイメントを行うことです。これには、新機能、設定変更、バグ修正、実験などが含まれます。さらに、これらは開発者のワークステーションから、複数の非本番環境を経て、最終的に組織の本番環境まで、継続的な方法で行われます。 今回は、

お待たせしました。Harness Feature FlagsでRubyをサポートします。近日公開予定です。

Rubyは長い間、多くのアーキテクチャーで主力となってきました。移植性が高いため、デスクトップアプリケーション、静的ウェブサイト、データプロセッサー、そして最近では自動化サービスの構築にも利用されています。生産性と簡便性の両方に優れているRubyをシステムに深く組み込んでいる多くのユーザーのため、Rubyのサポートは当然のことでした。

SBOMの概念は製造業から取り入れられ、目的も同じです。使われている部品を追跡することです。詳しく見ていきましょう。

ソフトウェア開発者は、オープンソースソフトウェアやサードパーティーコンポーネントに依存することがよくあります。セキュリティーを確保するために、企業はそれぞれのコンポーネントを注意深く追跡・管理しなければなりません。ソフトウェアエンジニアがこれらのコンポーネントを監視するために使用するのが、ソフトウェア部品表（Software Bill of Materials: SBOM）です。これは、あらゆるソフトウェアに存在する全ての項目と依存関係を含む、機械可読のリストです。

この度、Harnessの全モジュールの価格とプランを簡素化しました。新しい価格体系については、スクロールしてお読みください。

この度、Harnessの全モジュールの

Gitのリベース（git rebase）とマージ（git merge）は、いつどちらを使えばいいのか混乱することがあります。分かりやすくするため、それぞれの戦略が適切である事例を紹介します。

私たちの多くはGitに慣れ親しんでいて、開発者がコピーやブランチを行うなどの概念も理解しています。この記事では、Gitのリベースとマージの違いと、さまざまなシナリオに対する最適な戦略を紹介します。最近のリリースプロセスの強化やブランチ戦略の実装では、リベースを使いました。その理由も説明します。

whenディレクティブと組み込み変数を使用すれば、ユーザーは複数のパイプラインを作成して維持せずとも、同様のユースケースに対して１つのパイプラインを使うことができます。条件付き実行の全てを学びましょう。

whenディレクティブを使うと、パイプラインは与えられた条件によって、ステップやステージを実行すべきかどうかを決定することができます。

なぜ必要なのでしょうか。

Gitブランチングは、設定変更を簡単に行う方法を提供し、CI/CDパイプラインの開発、テスト、保守にかかる時間を短縮します。その方法をご覧ください。

バージョン管理システムは、ファイルのバージョンを追跡し、またブランチング、修正、テスト、そして承認とCIチェックを経てメインブランチにマージすることによって単独で変更を行うという概念をもたらしました。

フィーチャーフラグは、セキュリティーやパフォーマンスのリスクではなく、実際に組織としてのセキュリティーとパフォーマンスの姿勢を向上させるものです。その方法をご紹介します。

運用やセキュリティーに関心のある人にとって、この世で最も恐ろしいことが２つあります。

Git Syncは時間を節約し、CI/CDをより簡単にします！GitでYAMLファイルを作成/修正するだけで、新しいパイプラインを作成し、維持することができます。

DevOpsの登場により、開発とデプロイの境界線は曖昧になりました。エンジニアリングチームは、設定ファイルと継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインを作成し、維持し、使用することが求められるようになりました。ウィザードで設定ファイルを作成し、次へをクリックする従来の方法は、開発者にとって大きな手間となります。私たちは、コードを書くのと同じように設定ファイルを書きたいのです。Git Syncエクスペリエンスの主な目的は、ユーザーのCI/CD体験をコードを書くのと同じくらい簡単にすることです。

Git Syncを使って、ユーザーのために以下のような素晴らしい開発者体験を作り出したいと思いました。

PMにとって、フィーチャーフラグは定性的なフィードバックを提供し、ベータ版を管理し、実験を行うのに適しています。詳細はこちらをご覧ください。

多くのフィーチャーフラグについてのブログと同様、このブログも「フィーチャーフラグといえばXを思い浮かべる人が多いと思いますが、今日はYについてお話しします」と始まります。エンジニアリングのユースケースを取り上げることが多いので、今回はプロダクトマネジメントにおけるフィーチャーフラグの使い方について見ていきたいと思います。

技術的なレベルでは、そして機能の開発ライフサイクルの多くでは、Feature Flagsは主にエンジニアリングのためのツールです。しかし、開発プロセスの後半では、PMが主なユーザーとなることがあります。その理由と方法について見てみましょう。