なぜそれが必要ですか
では、なぜライブラリを作成する必要があるのでしょうか、それとも、特定のケースではNPMパッケージを作成する必要があるのでしょうか？
- プロジェクト間でコードを再利用します。
それはすべて、プロジェクトにフォルダー/ツールを作成する習慣に気づいたという事実から始まりました。 また、新しいプロジェクトに切り替えるときは、このフォルダーの大部分も持ち歩きます。 そして、私は自分自身に質問をしました。コピーペーストの代わりにNPMパッケージを作成し、それをプロジェクトに接続してみませんか？ - 異なるライフサイクル。 アプリケーションの1つに、依存関係として、コンポーネントの大規模な企業アセンブリがありました。 1つのコンポーネントのみが更新された場合でも、完全に更新することしかできませんでした。 他のコンポーネントの変更は何かを壊す可能性があり、必ずしもそれを再テストするのに十分な推定時間があるわけではありません。 このモデルは非常に不便です。 各パッケージがその目的または関連する目標の小さなセットを提供するとき、それらは本当に必要なときにすでに更新することができます。 また、次のバージョンのパッケージは、「for the company」ではなく、何らかの変更がある場合にのみリリースされます。
- 主要なビジネスロジックからマイナーコードを分離します。 DDDにはドメインの蒸留の原理があり、メインドメインに属さないコードを識別し、それらからコードを分離する必要があります。 そして、このコードを別のプロジェクトに取り込むよりも、どのように分離するのがよいでしょうか。
ちなみに、ドメインの蒸留はSRPの原理と非常によく似ていますが、レベルが異なります。 - 独自のコードカバレッジ。 私が参加したプロジェクトの1つでは、コードカバレッジは約30％でした。 そして、私がそれから取り出したライブラリは、約100％のカバレッジを持っています。 プロジェクトは、カバレッジの割合を失いましたが、削除前はレッドゾーンにあったため、残りました。 そして、ほぼ1年と4つのメジャーバージョンの後、ライブラリには今日までこのようなうらやましい指標があります。
- オープンソース ビジネスロジックを含まないコードは、プロジェクトから分離する最初の候補であるため、オープンにすることができます。
「高価な」新しいライブラリを起動します
このような問題があります。ライブラリを作成するには、その下にgitリポジトリを取得するだけでは不十分です。 また、プロジェクトを組み立て、静的検証（lint）およびテストを実行できるようにタスクを構成する必要があります。 また、テストに加えて、コードカバレッジを収集することをお勧めします。 さらに、毎回手動でパッケージを公開する必要があります。 そして、まだreadmeを書く必要があります。 それは私がreadmeで助けることができないだけです。
それでは、これらすべての退屈で面白くないタスクで何ができるでしょうか？
最初のステップ：シード
シードプロジェクトを作成することから始めました。 これは一種のスターターキットで、コードを別のパッケージに入れるための最初のプロジェクトと同じ構造でした。 1つのアクションでパッケージカバレッジをビルド、テスト、および収集するgulpタスクとスクリプトを作成しました。 次に、別のプロジェクトを作成するために、シードを新しいフォルダーにクローンし、GitHubで新しく作成されたリポジトリを指すように元を変更する必要がありました（その後、GitHubを使用しました）。
プロジェクトを作成するこの方法には、別の利点があります。 現在、プロジェクトの構築またはテストに関する変更は、シードプロジェクトで一度行われています。 これらの変更をコピーして貼り付ける必要はなくなりました。 代わりに、最終プロジェクトでは、次に作業する必要があるときに、シードと呼ばれる2つ目のリモートを作成し、そこからこれらの変更を取得します。
そしてそれはしばらくの間私のために働いた。 複数の開発者が参加するプロジェクトでシードを使用するまで。 最後のマスターを取得し、ビルドして公開するという3段階の手順を作成しました。 そして、ある時点で、開発者の1人が何らかの理由で最初のステップと3番目のステップを完了しました。 これはどのように可能ですか？
2番目のステップ：自動公開
それは単一の間違いであったという事実にもかかわらず、出版のような手作業は退屈です。 したがって、それを自動化する必要があると思いました。 さらに、赤いコミットがマスターに入らないようにするためにCIが必要でした。 最初はTravis CIを使用してみましたが、次の制限に遭遇しました。 彼は、マスターでのプルリクエストはマスターでのコミットと同等であると考えています。 そして、私は別のことをしなければなりませんでした。
同僚の1人が、GitLabとそのCI、およびそこで働きたいすべてのものに注意を払うように勧めました。
プロジェクトを操作する次のプロセスを作成しました。これは、バグの修正、新しい機能の追加、または新しいバージョンの作成が必要なときに使用されます。
- マスターからブランチを作成します。 コードを書いてテストします。
- マージリクエストを作成します。
- GitLab CIは自動的にノードでテストを実行します：最新のコンテナー
- リクエストはコードレビューに合格します。
- リクエストが凍結されると、GitLabは2番目のスクリプトセットを実行します。 このセットは、バージョン番号を持つコミットのタグを作成します。 バージョン番号はpackage.jsonから取得され、手動で増加された場合はそうではない場合、最新の公開バージョンが取得されて自動インクリメントされます。
- スクリプトはプロジェクトをビルドし、テストを再度実行します。
- 最後の手順では、バージョンタグがリポジトリに送信され、パッケージがNPMに公開されます。
したがって、タグで示されるバージョンは、このコミットから発行されたパッケージのバージョンと常に一致します。 これらの操作を機能させるには、GitLabプロジェクトのリポジトリとNPMへのアクセスキーを使用して環境変数を指定する必要があります。
最終ステップ：すべてを自動化する
この時点で、私はすでに多くの自動化を行っていますが、プロジェクトを作成するための多くの手動アクションがまだありました。 もちろん、アクションはプロジェクトごとに1回実行され、各バージョンでは実行されなかったため、これはいずれにせよ既に進行中です。 しかし、それでも命令は11ステップで構成されていました。 そして、私自身は、これらの措置を講じることによって数回間違えられました。 それから私は自動化を始めたので、これを終わらせる必要があると決めました。
この完全な自動化が機能するためには、コンピューターの.sshフォルダーに3つのファイルが必要です。 id_rsa秘密鍵はすでにそこに保存されているため、このフォルダは非常に保護されていると思いました。 このファイルは、GitLab CIがタグをリポジトリに渡すためにも使用されます。
2つ目のファイルは「gitlab」で、GitLab APIへのアクセスキーが含まれています。 3番目のファイルは「npm」で、パッケージを公開するためのアクセスキーです。
そして、魔法が始まります。 新しいパッケージを作成するために必要なのは、シードフォルダで1つのコマンド「gulp startNewLib -n [npmName] / [libName]」を実行することだけです。 パッケージが作成され、開発と自動公開の準備ができました。
たとえば、パッケージ「vlr / validation」はこの方法で作成されました。
このコマンドは次のことを行います。
- GitLabでプロジェクトを作成します
- コマンドを実行しているフォルダーの隣のローカルフォルダーにシードをクローンします。
- 起源をステップ1で作成されたプロジェクトに変更します
- マスターブランチをプッシュする
- .sshフォルダー内のファイルからプロジェクトの環境変数を作成します
- firstImplementationブランチを作成します
- package.jsonのライブラリの名前を変更し、ブランチをコミットしてプッシュします
この後に必要なのは、そこにコードを入れてマージ要求を作成することです。
その結果、ある種のコードを別のプロジェクトに配置することが決定されてから最初のバージョンが公開されるまで、約5分かかります。 それらのうち4つは2つのGitLabCIパイプラインを占有し、1分で上記のコマンドを起動し、コードをドラッグアンドドロップし、GitLabインターフェイスのボタンを押してリクエストを作成し、保留します。
いくつかの制限があります：GitLab名はnpmの名前と一致する必要があります。 それでも、このコマンドは、シードプロジェクトの他の機能とは異なり、Windowsでのみ機能します。
このシードプロジェクトに興味がある場合は、次のリンクで学習できます。