githubリポジトリの目に見えない友人

Githubは、ほぼすべての開発者の生活にしっかりと入った不可欠なツールです。



私たちの多くは絶えずそれを使用していますが、GitHubと緊密に統合され、その機能を拡張する多数のサードパーティ（および無料）サービスおよびツールがあることを誰もが知っているわけではありません。



この記事では、主にnpmインフラストラクチャで動作するツールに焦点を当てます。 githubと統合するサービスの完全なリストは、 github integrationsディレクトリページにあります。

今日の問題：

• 継続的インテグレーションの構成c travis ci
• カバーオールを使用してテストカバレッジレポートを設定する
• davidを使用して依存関係の状態を監視する
• greenkeeperを使用して自動依存関係更新を設定する
• commitizenによるコミットメッセージの改善
• 従来の変更ログを使用して変更ログとリリースノートを生成する
• zubeを使用したタスクの管理

レビューされたサービスのほとんどは、プロジェクトページに追加できる情報バッジを提供します。 バッジについて言及するたびに同じ画像が表示されないように、記事の冒頭で一度表示します。







また、いくつかのスクリプトを記述する必要があります。 これを行うには、nuntスクリプトを使用して、うなり声や口論などのツールを回避するため、特定のコレクターを知る必要はありません。







説明したサービスの実際の使用例は、 e2e4ライブラリのリポジトリ（単純なオプション）または角度グリッドの直角ライブラリ（より興味深いオプション）にあります。

継続的インテグレーションの構成c travis ci

明白なことから始めましょう-すべてのプロジェクトには継続的な統合が必要です。 これでtravis ciが私たちを助ける準備ができました。



travisでのビルドのセットアップは非常に簡単で、次の手順で構成されています。

1. githubアカウントを使用してtravisにログインします。
2. 設定ページで、travisが監視するリポジトリを指定します。
3. ファイル「.travis.yml」をリポジトリのルートディレクトリに追加します。これは、ビルドを起動するための環境設定とコマンドを示しています。

たとえば、次のように：

language: node_js node_js: - "6" script: - npm run ci
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、nodejsバージョン6の環境が必要であることをtravisに伝えます。



ビルドプロセスは、package.jsonファイルの「scripts」セクションから「ci」というスクリプトを実行する1つのnpmコマンドで構成されます。



私たちの場合、このコマンドは、プロジェクトをtslintでリントし 、 typescriptでビルドし、 karmaでテストを実行します。 詳細に興味がある場合は、 githubのpackage.jsonで詳細を確認できます。



また、ビルドコマンドで「npm install」を指定しなかったことにも注意してください。 Travis自身は、npmを使用して依存関係をインストールする必要があることを理解して実行します。



さらに、糸を使用する場合、travisはこれを理解し、 糸をインストールし、それを使用して依存関係をインストールします。



Travisには、不必要なアクションから私たちを救うようなテンプレートがたくさんあります。



次に、「。travis.yml」ファイルのプッシュを実行します。その後、最初のビルドが実行されます。 ビルドプロセスは、travisページでリアルタイムに確認できます。

他に何

• より複雑なシナリオや他のプラットフォームに興味がある場合は、 travisのドキュメントをご覧になることをお勧めします。 ドキュメントの品質は印象的です。
• ビルドが失敗した場合、travisはgithubアカウントで指定されたメールアドレスにこれについて書き込みます。 スラックとの統合を構成することもできます。
• タグを作成するとき、travisはビルドが成功した場合にも結果を報告します。
• コミットに加えて、travisはプルリクエストごとにビルドを実行します。 ビルドが完了すると、結果に関する情報がプルリクエストページに表示されます。 マージの実行後、travisはビルドを再度実行し、プルリクエストページで結果を再度報告します。

• ビルドの現在のステータスを表示する特別なバッジをreadmeファイルに追加できます。 組み合わせて、これはtravisの最新ビルドに関する情報へのリンクです。 バッジを使用すると、ビルドですべてが正常であることをコミュニティに示すことができます。 またはすべてが悪いです。 2番目のケースでは、このようなバッジは、状況を可能な限り迅速に修正するよう動機付けられます。
• 公開リポジトリの場合、ビルドに関する情報は誰でも利用できます。 彼らはこれのためにtravisにログインする必要さえありません。
• そして最後。 履歴からビルドを削除することはできません。 できる最大のことは、ログビルドを削除することです。 たとえば、その中の機密情報を「明らかにした」場合。 しかし、ビルド自体は永遠に歴史に残るでしょう。

カバーオールを使用してテストカバレッジレポートを設定する

次のサービスはカバーオールです。



一般的な考え方は、テストを実行すると、lcov形式のカバレッジレポートを生成し、分析のためにカバーオールサービスに送信することです。 サービスはそれを処理し、次の機能を提供します。

• READMEにテストカバレッジ率のバッジを追加できます。 だから、あなたはあなたのコミュニティにあなたが真剣にすべてを持っていることを伝えます。
• プルリクエストを作成するとき、カバーオールはテストカバレッジがプルリクエストにどのように変化したかに関する情報を追加します。

• テストのカバレッジ範囲の制限を設定できます。 また、プルリクエストの変更によりカバレッジの割合が指定された値を下回ると、プルリクエストのチェックは失敗します。
• このサービスは、travisなどのci-servicesと統合され、ビルド履歴を保存し、ビルドからビルドまでのテストカバレッジのダイナミクスを見ることができます。 たとえば、直角ライブラリのレポートは次のとおりです。

カバーオールをプロジェクトに接続するには、次の手順を実行する必要があります。

1. githubアカウントを使用してカバーオールにログインします。
2. 情報の収集を有効にするリポジトリを選択します。
3. coveralls npmパッケージをリポジトリにインストールします。
4. テスト実行中にカバレッジレポートの生成を構成します。
   
   

   カバレッジレポートの生成方法は詳細に検討しません。テストの作成対象、使用するツール、テストの実行方法にすべて依存するためです。 さらに、たとえば、typescriptの場合、カバレッジレポート生成ツールはありません。これは、実行されるのはtypescriptではなくjavascriptであるためです。 また、タイプスクリプトコードのカバレッジを正確に表示する場合は、jsコードのカバレッジに関するレポートをタイプスクリプトコードに再マッピングするためのツールが必要になります。 これはすべて不必要な特異性であり、この記事では避けようとします。 githubのcoveralls npmパッケージページから可能なオプションの調査を開始できます。

   
   
   
   
   
5. npmスクリプトを追加して、生成されたレポートをカバーオールサービスに転送します。
   
   

    "scripts": { "coveralls": "cat ./coverage/lcov.info | ./node_modules/.bin/coveralls", ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
6. travisでビルドを実行した後、追加されたスクリプトを実行します。 これを行うには、travis.ymlファイルのafter_successセクションを使用します。 これで、travis.ymlは次のようになります。
   
   

    language: node_js node_js: - "6" script: - npm run ci after_success: - npm run coveralls
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

他に何

githubに加えて、カバーオールはbitbucketと統合し、gitlabの緊急サポートを約束しました。 また、複数の継続的統合サービスおよび複数の開発プラットフォームとの統合もサポートしています。

davidを使用して依存関係の状態を監視する

david依存関係監視サービスは、この記事で説明したものの中で最も単純です。



サービスのアイデアはシンプルです。プロジェクトの依存関係の状態を示すバッジをプロジェクトページに追加します。 また、プロジェクトの依存関係分析ページへのリンクです。



davidをプロジェクトに接続するには、次のテンプレートに従ってブラウザーにアドレスを入力します。

 https://david-dm.org/< >/< >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクト内の依存関係のタイプに応じて、開いたページに「依存関係」、「依存関係」、「ピア依存関係」、および「オプションの依存関係」タブが表示されます。



各タブには、特定のタイプとバッジの依存関係のリストが含まれています。クリックすると、マークダウンまたはHTML形式でリンクをコピーし、readmeファイルまたはgithubページのプロジェクトページに配置できます。

他に何

また、マシンの依存関係を更新するのに役立つdavid cliユーティリティもあります。 確かに、組み込みのnpm期限切れコマンドおよびnpm更新コマンドと比較した場合の利点を理解できませんでした。

greenkeeperを使用して自動依存関係更新を設定する

greenkeeperサービスは 、依存関係を更新するという困難なタスクを支援するようにも設計されていますが、より高いレベルでそれを行います。 彼の仕事は、可能な限り依存関係の処理を完全に軽減することです。



greenkeeperをプロジェクトに接続するには、 githubの公開統合セクションのgreenkeeperページに移動し、必要なリポジトリにアプリケーションをインストールする必要があります。



わずか1分で、greenkeeperはプルリクエストを作成し、プロジェクトのすべての依存関係を更新し、greenkeeperのステータスを表示するreadmeバッジに追加します。



このプルリクエストをマージした場合のみ、greenkeeperはプロジェクトの監視を開始します。



さらに、依存関係の新しいバージョンが表示されると、greenkeeperはプルリクエストを作成します。これは、更新された内容の詳細な説明を提供し、可能であれば、新しいバージョンの変更のリストを提供します。 マージするだけです。







当然、greenkeeperの接続は、自動ビルドが構成されており、更新後にプロジェクトが動作状態にあることを少なくとも名目上確認するために使用できるテストがある場合にのみ意味があります。 Greenkeeperは、リポジトリにビルドとテストがあるかどうかを認識し、どちらかが検出されない場合はプルリクエストテキストに警告を書き込みます。

他に何

• プルリクエストを閉じた後、greenkeeperは作成されたブランチ自体を削除します。
• 更新された依存関係が次のバージョンを非常に迅速にリリースする場合（クイックフィックスの発行と同様）、greenkeeperは新しいブランチを作成し、元のプルリクエストへのコメントにそれについて書き込みます。
• グリーンキーパーがブランチを作成し、プルリクエストを行わずにすぐに削除することもあります。 したがって、グリーンキーパーは、パッケージで指定されたpackage.json バージョン範囲に適合する依存関係の更新がリリースされた場合に機能します。 つまり、このバージョンの依存関係は、依存関係を再インストールするときに届きます。 このようにして、Greenkeeperは、バージョン範囲に入ったバージョンでさえビルドを壊さないことをチェックし、それを実行した後、単にブランチを削除します。 エラーが発生した場合、greenkeeperは問題を作成します。
• プロジェクトの特定の依存関係をgreenkeeperで更新したくない場合は、package.jsonファイルに次のセクションを追加できます。
  
  

   "greenkeeper": { "ignore": [“”, “”, “”, “ ”, “”] }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• また、グリーンキーパーは現在ヤーンを使用していないことも知っておく必要があります。 この問題を回避する方法はありますが、それらを良いと呼ぶのは難しいです。 この件に関するすべての情報は、githubの問題に記載されています。
• そして最後の瞬間。 プロジェクトが同時に更新する必要がある複数の依存関係を使用する場合があります。 たとえば、 angularはモジュールに分割されており、プロジェクトで複数のモジュールが必要になる可能性が高くなります。 同時に、それらを更新することはすべて理にかなっています。 Greenkeeperはまだそのようなタスクに対処することができません。

commitizenによるコミットメッセージの改善

Commitizenは、意味のあるコミットメッセージの作成を支援するツールスイートです。



リポジトリに興味のある人々にとってより有益であることに加えて、commitizenの使用にはもう1つの利点があります。 生成されたコミット済みメッセージから、変更ログとリリースノートを簡単にコンパイルできます。 また、コミットの履歴を分析し、 semverの規則に準拠するために次のバージョン番号を教えてくれるユーティリティもあります。 しかし、それについては次のセクションで詳しく説明します。



そして、最も単純なものから始めます。 cz-cliをインストールします。 インストール後、「git commit」の代わりに「git cz」コマンドを使用できます。 このコマンドは、現在のコミットで正確に何を変更したかについての一連の質問をガイドするウィザードを起動し、人間が簡単に読み取ってさまざまなツールで解析できる形式でコミットメッセージを生成します。



だから：

1. commitizenをグローバルにインストールします。
   
   

    npm install commitizen -g
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. コミットしやすいリポジトリを作成します。 これを行うには、リポジトリフォルダーで次のコマンドを実行します。
   
   

    commitizen init < > --save-dev --save-exact
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

<adapter name>の代わりに、可能なアダプタの1つを指定する必要があります。 フロントエンド開発の世界で最も人気があるのは、cz-conventional-changelogです。これは、角度のあるチームが開発した次のメッセージ表記です。



このコマンドは必要な依存関係をインストールし、package.jsonファイルのdevDependenciesセクションに保存し、そこに必要な設定を書き込みます。

他に何

• コマンドラインでの作業に加えて、コードエディター用の拡張機能があります。 たとえば、 vscodeの場合 。 同じvscodeに対してターミナルで「git cz」を使用することと基本的な違いはありませんが、おそらくあなたにとってはより便利でしょう。
• git czが生成するメッセージも簡単に作成できることに注意してください。 一部の開発者はこれを行います。 ここで形式の完全な説明を見つけることができます 。
• Readmeページにバッジを追加して、リポジトリの訪問者に、コミットされた規約に従っていることを知らせることができます。

従来の変更ログを使用して変更ログとリリースノートを生成する

commitizenを有効にした後、別のオプション-変更ログとリリースノートの自動生成を設定する機能があります。



この従来のchangelogで役立ちます。

従来の変更ログは、既製のテンプレートに従って高レベルのツールを使用してリリースのリリースを構築したり、個別のツールから具体的に必要なものを組み立てたりすることができるツールのファミリー全体です。



開発者自身が、比較的高レベルのツールであるstandard-versionの使用を推奨しています。



さらに高いレベルは、 semantic-releaseです。 このツールはプッシュ変更を行い、npmでバージョンを公開します。



私たちの経験から-両方のオプションを試した後、低レベルのツールを使用することに決めました。



この選択の理由は、たとえば、標準バージョンが変更をプッシュせず、githubにリリースの説明を生成しないためです。 リリースプロセスにそのようなものを追加し、ビルドを起動するため、またはドキュメントを生成するために標準バージョンオプションを使用して構成するには、 npm versionコマンドに基づいて公開プロセスを手動で設定するのと同じくらい複雑な設定が必要です。



一方、セマンティックリリースは、プロセス全体を自動化しようとしているため、非常に統制のとれた開発アプローチをとる必要があります。 構成の複雑さは、プロセスの手動構成に匹敵​​します。 そして最後。 Semantic-releaseはnpm publishを行います。これは、npmを介して配布されたライブラリのみに使用を制限し、ライブラリだけでなくバージョンの発行も可能です。



そのため、npmバージョンに基づいてリリースプロセスを構築します。 また、バージョンnpmスクリプトを実行すると、preversionスクリプトとpostversionスクリプトがあれば実行されます。 両方を使用します。 リリースプロセスは、次の手順で構成されます。

プリバージョンフェーズ：

1. rimrafを使用して、以前のビルドの結果でディレクトリをクリアします 。
2. tslintを実行します。
3. コンパイルタイプスクリプト。
4. karmaでテストを実行します。

e2e4リポジトリを例として使用すると、これらの手順はprecommitフックで実行される手順と同じであるため、同じスクリプトを使用します。

 { "preversion": "npm run precommit", "precommit": "npm run rimraf -- esm coverage && npm run clean:src && npm run clean:tests && npm run lint && npm run build && npm run test" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フェーズバージョン：

1. githubページで公開するためのドキュメントを生成します。 私たちの場合、 これにはtypedocが使用されます。 githubページについて-最近、gh-pagesという名前のブランチを作成する必要がなくなったため、サイトとして使用されるgithub設定でプロジェクトのフォルダーを指定するだけです。 デフォルトでは、これは「docs」フォルダーです。 したがって、ドキュメントフォルダーにドキュメントを生成するだけです。
2. 生成されたドキュメントをgitに追加してコミットします。
3. changelog.mdに変更に関する情報を追加します。 このために、 従来のchangelog-cliを使用します。 パラメーターとして、ファイル名とメッセージ解析の規則を渡します。 私たちの場合、それは「角度」です。
4. コミット用の更新された変更ログを追加します。
5. package.jsonのバージョンを更新し、コミット用に追加します。 このnpmが役に立ちます。
6. バージョンのタグを生成し、必要に応じてプレリリースまたは最新のラベルを付けます。 このnpmも私たちに役立ちます。 ラベルを付けると、 semverの規則に従ってバージョン番号がわかります。

合計で、次の一連のスクリプトが取得されます。

 { "version": "npm run docs && git add -A docs && npm run changelog && git add CHANGELOG.md", "changelog": "npm run conventional-changelog -- -p angular -i CHANGELOG.md -s", "docs": "npm run rimraf -- docs && typedoc --options typedoc.json src/" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポストバージョンフェーズ：

1. 変更されたpackage.json、changelog.md、ドキュメントのプッシュを実行します。
2. 作成したタグのプッシュを実行します。
3. 変更の説明をgithubリリースに追加します。 これを行うには、従来のgithub-releaserを使用して、メッセージ表記をパラメーターとして渡します。 私たちの場合、それは「角度」です。 情報を記録するには適切なアクセス権が必要なので、従来のgithub-releaserが認証に使用するアクセストークンを生成する必要があります。 これがどのように行われるかは、プロジェクトの説明に記載されています。

バージョンのスクリプト：

 { "postversion": "git push && git push --tags && conventional-github-releaser -p angular", }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リリースプロセスの準備ができました。



次のコマンドを使用してスクリプトを実行します。

 npm version <   major/minor/patch>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

生成されたリリースノートは次のようになります。







changelog.mdの内容はほぼ同じであるため、引用しません。

他に何

• 従来のchangelogツールを使用できるのは、githubだけではありません。 従来のchangelog-cliはどのgitリポジトリでも動作しますが、従来のgithub- releaserにはgitlabで動作するための兄弟ライブラリがあります 。
• 2つの場所に同じ情報を投稿する理由を疑問に思っているかもしれません。 リリースの説明は、ユーザーが単に新しいバージョンに興味がある場合に便利です。 また、変更ログはnpmパッケージで提供され、ユーザーが既にバージョンを更新しており、重大な変更に応じてコードを調整したり、新しいライブラリ機能を使用するためにリリース情報が必要な場合に役立ちます。 また、この情報をコードエディターで直接確認すると、githubのリリースの説明よりも便利です。

zubeを使用したタスクの管理

zube.ioについてはあまり説明しません。 私たちはそれぞれタスクトラッカーを使用しましたが、zubeはそれらの多くとほとんど変わりません。



その利点の2つだけを挙げます。そのため、この記事で言及することにしました。

1. これは、githubと統合されるプロジェクト管理ツールでは珍しいオープンソースプロジェクトでは無料です。
2. zubeを使用すると、複数のgithubリポジトリのタスクを1つのプロジェクトに結合し、同時に作業できます。

これでレビューは終了です。 githubで作業するためのその他の興味深いサービスまたはツールを知っている場合は、コメントで知識を共有してください。



ご清聴ありがとうございました。



記事の表紙画像-cameronmcefeeによるBenevocats。