pkgバージョン規範管理自動化の最適実践

7317 ワード
javascript node.js git
前提
バージョンとは?バージョンすなわち意味バージョン制御(Semantic versionの後、単にSem Verという)は、過去数年間にわたって発展してきたバージョン制御システムである.毎日新しいプラグイン、プラグイン、拡張とライブラリを構築していますが、共通のソフトウェア開発プロジェクトのバージョン化方法を持っています.
Sem Verのフォーマットはx.y.zです.
xはメインバージョン(Major)を表します.
yはサブバージョン(Minor)を表します.
z代表パッチ(Patch)
Sem Verはどのように働きますか?
Sem Verであなたがリリースすべきバージョンの種類を確認するのは簡単です.
バグを修正したり、修正したりすれば、パッチに分類されます.この場合は、zをアップグレードするべきです.
後方互換で新しい機能を実現すれば、yをアップグレードします.これはいわゆるセカンダリバージョンです.
一方、既存のAPIを破壊する可能性のある新しいものが実現されたら、アップグレードxが必要です.それは主要なバージョンですから.もっと知りたいなら後ろを見てください.
開始
意味化されたバージョンコントロールは応用にとって非常に重要です.もちろん、バージョンアップが重要ではないように見えますが、非常に重要なことになります.私たちが開発する過程で、またはこのような状況に遭遇したことがありますか?
  • バージョンの制御概念があいまいであるか、忘れているため、buildのアプリケーションは任意に変更されたバージョンまたは修正されたバージョンを完全に忘れている.
  • 毎回buildが終わるとバージョンを変更するのが面倒で、変更するのがおっくうです.
    • このような場面に基づいて、この自動バージョンアップ管理ツールat-versを開発しました.
    ギthub:https://github.com/zerolty/au...
    同じライブラリの比較
    アイテム
    npm-at-version
    udate-version
    at-vers
    ジート.
    サポート
    サポートしない
    サポート
    自動更新
    サポートしない
    サポート
    サポート
    更新を促す
    サポートしない
    サポートしない
    サポート
    マニュアルとaut-versの比較
    以下は私達が手動で変更する必要があります.
    次はaut-versを使用した方式です.
    持っている機能
  • [x]major、minor、patch、premajer、premainor、prepach or prerelease
    • を更新します.
  • [x]更新時に
    • の選択を提示する.
  • [x]サポートギット方式
  • []git comitの情報に基づいて、適切なバージョンを自動的に推奨する
    • .
    使用
    NodeとCliの導入方式.
    npm i auto-vers -g
    Cli
    ベースモード
    cat package.json
{
    ...
    "version": "1.0.0"
    ...
}
    auto-vers -i
    cat package.json
{
    ...
    "version": "1.0.1"
    ...
}
    確認モード
    auto-vers -i -c
    ヒントモード
    auto-vers -t
    更新したくないなら、ctrl+cを使って停止してもいいです.
    ヒントとGitのコンビネーションモード
    このオプションを使うと、あなたがバージョンを選択したら自動的にcomitを提出してくれます.
    auto-vers -t -g
    直接モードを変更
    auto-vers 1.2.0
    or
    auto-vers -v 1.2.0
    options
    auto-vers 1.0.2

Auto update version for your application
Usage: auto-vers [options]  [[...]]

Options
-v --version 
        Can update version directly.
-i --inc --increment []
        Increment a version by the specified level. Level can
        be one of: major, minor, patch, premajor, preminor
        , prepatch or prerelease. Default level is 'patch'.
        Only one version may be specified.
-e --extra []
        This is for prerelease extra data
        Such as 'beta','alpha'
-c --confirm
        Do not update the version directly, you can confirm.
        This is a safe mode.
-t --tip
        Provide choice to you. If you don't know how to update
        you can choose this option.
-g --git
        Help you make a tag.(Make you have a git repo)
    ベストな実践
    あなたが梱包したプロジェクトと同時にこのコマンドを実行するのはとても良い選択です.
    基本的な方式
    "script": {
    "build": "babel ./src --out-dir ./dist",
    "tip": "npm run build && auto-vers -t",
    "version": "npm run build && auto-vers -t -g",
}
    パッケージコマンドを作成した後、auto-vers -tに続いて、どのぐらいのバージョンにアップグレードするべきかを提示します.これはあなたにとって一定の指示意味があります.より良い地域の判断をお手伝いします.どのバージョンにアップグレードする必要がありますか?auto-vers -t -gこのコマンドはあなたが単独でバージョンをリリースするのに適しています.package.json->git comit->git pussh origgin[tagname]全体の流れを変更するために、ワンタッチでヘルプできます.
    中級の方式
    "script": {
    "build": "babel ./src --out-dir ./dist",
    "patch": "npm run build && auto-vers -i -c",
    "minor": "npm run build && auto-vers -i minor -c",
    "major": "npm run build && auto-vers -i major -c",
    "beta": "npm run build && auto-vers -i prerelease -c",
}
    この方式はこのモードを熟知している人に対して、毎回包装する必要があるのは対応するコマンドだけです.(パラメータを増やす-c --confirm、これは安全な方法でアップグレードします.アップグレードが正しいかどうかを確認してくれます.あなたにとって煩雑なステップであれば削除できます.)
    高級な方式git-hookspre-commitとpost-commitを登録していないなら、直接にあなたのgit/hooksディレクトリの下に移動できます.
    mv githook-*/*  .git/hooks/
    あなたがローカルに存在する場合は、プロジェクトの下にあるHookを、あなたのhookに手動で追加します.
    cat githook-*/pre-commit >> .git/hooks/pre-commit
    comitを提出すると、自動的に選択画面から飛び出して対応バージョンをアップグレードします.
    もっと注意してください
    なぜSem Verを選択しますか?
    規格外のバージョン番号はほとんど意味がないからです.--no-verifyアップグレード4.1.0ですか?はい、どうしてですか?なぜですか?4.2?なぜそうではないですか?5?なぜそうではないですか?4.1.1?なぜそうではないですか?4.11厳格な指導原則は、バージョン番号の意味を提供するのに役立ちます.例えば、バージョン4.1.0-aplha.0を見たら、これが最初の主要バージョンであることが分かりますが、3つのセカンダリバージョンが新たな機能をもたらしています.しかし、今回は37番目のパッチであることにも気づきます.これは多くのエラー(少ないまたは大きい)に関連することを意味します.
    また、管理依存関係にも貢献しています.1.3.37は"babel-cli": "~6.26.0",のバージョンを導入しています.babel-cliをロックします.これは比較的保守的な方法です.ルールによって、zのアップグレードは私たちのappiの大きな変化と新しい機能の導入につながることはないことが分かります.しかし、6.26.0がSemVerに従わないなら、アップグレード時に導入されました.破壊的な変化は、私たちのアプリケーションにバグが発生したり、使えなくなったりします.SemVerの仕様があるからこそ、安心してxをロックできます.y、zは自動的にアップグレードできます.zのアップグレードによって、小さなバグや詳細の改善ができます.私たちのアプリケーションを破壊しないで、既知のバグを修復することができます.
    もっとテクニック
    SemVerは何か及び自動更新の方法を知っている以上、更新時の注意事項を話してください.
    開始は0.1.0です
    SemVerを使う時に注意しなければならないのはx,yからであって、私達が想像していたようにbabel-cliからではなく、パッチから始まるのではなく、機能のセットから始まるので、プロジェクトの初稿としてバージョンは0.1.0です.
    1.0.0までは開発段階です.
    いつもあなたが新しいソフトウェアを構築する時、いつも迷いの段階があります.自分に聞きました.私はいつ正式な主要バージョンをリリースするべきですか?
    以下はこの質問に答えるためのヒントです.もしあなたのアプリケーションがすでに生産中に使用されていたり、ユーザーがそれに依存しているなら、0.0.1に達しているはずです.また、現在のAPIを破っているならば、あなたのメインバージョン番号をアップする必要があります.
    そうでなければ、0.1.0以下のバージョンは基本的に開発ブームの時期です.あなたの機能を完成するために集中してください.1.0.0の前に、どのような破壊的な機能も恐れてはいけません.1.0.0に達すると、安定します.
    プレリリースプレリリースについて
    メインバージョンを展開する前に、通常は多くのテストが必要です.
    SemVerを使用して、プリリリースはバージョンに識別子を付加することによって定義され得る.例えば、バージョン1.0.0のプリリリースは、1.0.0でありうる.そして、別のプリバージョンが必要であれば、1.0.0に変更され、同様にする.
    締め括りをつける
    上の基本的な紹介を通して、SemVerを使わなかったら、次の項目(または現在のプロジェクト)にいない理由がありません.これを使うことによって、あなたのプロジェクトのバージョンが有意義になるだけではなく、他のプロジェクトを依存項目として利用することができる人たちにも役に立ちます.多くの話をしましたが、最終的には他の人のためだけでなく、自分のためにもっと規範的に開発してもらいたいです.私が開発したこのプロジェクトはそんなに完璧ではないかもしれません.しかし、みんなの規範を高めたいです.効率的です.バグがありますので、機能上の問題があったら、遠慮なく指摘してください.
    相互リンク
    青い秋風 影のない人
    参照
    https://medium.com/fiverr-eng...
    https://www.sitepoint.com/sem...
    節流と振動防止