プログラマ、チーム、チームの有効性をめぐる闘争の開発者

みなさんこんにちは。



今日は、効果的な作業の1つの非常に重要な側面である再利用について説明します。

もちろん、これはコードに関するものです。

2回、さらに3回は書きたくないルーチン。 インフラストラクチャ。プロジェクトごとに作成する必要があります。 素晴らしい、それは単に素晴らしいアイデアを表現し、他の人にそれを使わせない罪です。



はい、認めましょう-私たちは皆、「フレームワーク」を書くのが大好きです。 これは私たちの日常活動に少し勇気を加えます。



そして、ここで著者は、自分が間違っていることを理解し、状況を説明し始めます-誰もがそれが何であるかをすでに理解しています。 そして、技術とプロセスを説明する必要があります。 だから、同僚に役立つ可能性のあるコードが突然たくさんあり、簡単にアクセスできるようにするのが良いだろうという抽象的な考えだけを考えてみましょう。 また、「成熟した」プロジェクトでは多数のコピー＆ペーストコードを見つけることができ、保守性が大幅に低下するという2番目の、はるかに不快なアイデアも考慮します。 そして、そのようなプロジェクトでの仕事は、電話するのが楽しいものではありません。 そして、これで何かをする必要があります。

そして、それについて何かをすることにしました。

私たちが旅行した道はそれほど難しくないことが判明しました。他の人にそれを繰り返すことをお勧めできます。 そして、ある時点でこの道が面白くて楽しくなったので、私たちは経験を共有することにしました。

まあ、十分な序文。

したがって、今日は詳細に説明します。

1. 企業のnugetサーバーを展開する方法（ほとんどの読者がそれが何であるかを知っていると仮定して、nugetの基本を省略します）。
2. Nugetと統合された企業シンボルサーバーを展開する方法。
3. 効率的なプロセスを構築するには、1つのnugetサーバーで十分ではないのはなぜですか。
4. また、第2部のトピックについても事前に説明します。このトピックで読者が見つかった場合は、喜んで作成します。
5. SandCastleとは何で、何と一緒に食べられますか。
6. 行ったすべてを自動化するための継続的インテグレーションの構成方法。
7. （自己）組織に関するいくつかの考え。

企業のNugetサーバーを展開します。

だから、nugetは素晴らしくて楽しいです。 これは、生産性を向上させる単なる新しいツールではなく、新しいアプローチであり、新しい考え方です。 健康的な食事や朝の運動とほぼ同じくらい健康的です。 だから使用する必要があります。



企業サーバーの展開について話している場合、2つのインストールオプションがあります。

1. UIとバンズなしの簡単なテープロールアウト。 このオプションでは、MVCアプリケーションを作成し、 nugetパッケージ （再帰など）をダウンロードしてnugetサーバーをインストールするだけで十分です。
2. 2番目のオプションは、少し怠け者向けに作成されていますが、UIと便利な機能を備えています。 そのためには、 ソースをダウンロードし、同じページの指示に従ってコンパイルする必要があります。 その後、Ctrl + F5を押すと、公式テープの（ほぼ）完全なアナログが表示されます。

実際、それだけです-プロセスは非常に簡単です。 ただし、ドキュメントに記載されていないいくつかのポイントがありますが、これらは他の人にとっても役立つ可能性があります。



1. IISエクスプレス 。 localdbを使用してIIS Expressで作業するオプションは、さまざまな理由で本番用として考慮することは困難です。 そのため、新生児を完全に機能するIISサーバーに移動しました。 幸いなことに、これに問題はありません。 「Website」プロジェクトの「プロパティ」タブに移動し、「Web」セクションの「Use IIS Express」のチェックを外します。 Visual Studioは、このような変更にすぐに対応します。仮想ディレクトリを作成し、web.configの接続文字列をlocaldbからSQL expressに変更することを提案します。







2. データベースの移行 。 NugetはEntity Frameworkを使用してデータにアクセスし、データベース移行メカニズムを積極的に使用します。 展開ガイドには、ステップ4があります-スタジオでタブを開く手順について、サーベルとダンスを使用してデータベースを作成します。 実際、すべてがよりシンプルです。 コンソールを介して更新するときに移行が保存されるプロジェクトの名前を指定するだけで十分です。 そしてダンスなし：







3. セキュリティ設定 。 マニュアルには、セキュリティ設定に関するポイントは記載されていません（ 古いマニュアルに記載されていましたが）。 どうやら、すべてが無条件の管理者によって設定され、すべてが彼自身のアカウントの下でスピンすると想定されています。 そうでない場合は、次が必要です。

• a。 アプリケーションの「AppData」フォルダーに書き込み権限を付与します。 Nugetパケットがそこに追加されます。 AppPoolアプリケーションがスピンしているアカウントに権利を付与します。 ApplicationPoolIdentityが特定のアカウントではなくIIS設定にある場合、IIS_IUSRSグループに権限を付与します。
• b。 同じ原則により、SQLでデータベースにアクセスする権限を付与します。
• c。 登録後、自分に管理者と同じ役割を付与できます。 これを行うには、UIを介した標準登録の後、dbo.UserRolesテーブルにレコードを挿入し、dbo.RolesテーブルのロールのIDを確認します。 その後、アドレス "<server path> / admin"を使用すると、あらゆる種類のグッズと垣間見るブックマークレットで管理パネルにアクセスできます。

4. GalleryOwner 。 実際の設定のためにweb.configの「Gallery.GalleryOwner」アイテムを変更するのは理にかなっています。 登録中に彼から手紙が送られます。 また、このニュースレターを完全に無効にすることができます。 そして、必ず現在のSiteRootを書き留めてください。

<appSettings> <add key="Gallery.LuceneIndexLocation" value="AppData" /> <add key="Gallery.Environment" value="Development" /> <add key="Gallery.SiteRoot" value="http://your-server-name/" /> <add key="Gallery.GalleryOwner" value="%username% <%usermail%>" /> <add key="Gallery.ConfirmEmailAddresses" value="true" /> <add key="Gallery.HasWorker" value="false" /> </appSettings>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5. stats.jsファイルにgetStats関数があります 。 この記事の執筆時点では、その呼び出しによりメインページにエラーが発生していました。







その理由は、ローカルバージョンのnugetでは統計が無効になっているためです。 現時点では、クラウドバージョンのみを対象としています。



IStatisticsServiceの独自の実装を作成するか、この呼び出しを無効にすることができます。 2番目のパスを選択しました。



実際、それがすべてです。 これで、ギャラリーとパッケージを備えたnugetサーバーができました。



しかし、パッケージ（そこからのDLL）にバグが入り込んだ場合はどうでしょうか？ または、開発者は「DoStuff」機能が何をするのかを理解したいだけですか？ 明らかに、ライブラリは借方記入される必要があります。 ただし、dllのみを自由に使用できる場合はそれほど簡単ではありません。 そのため、nugetはライブラリパッケージだけでなく、 シンボルパッケージも収集できます 。

そして、独自のシンボルサーバーを構築する方法を学びます

デバッグをサポートするためのソリューションとして、 SymbolSourceを使用することにしました 。これは、 nugetと非常に良い友達であり、 デフォルトのシンボルサーバーとしてサポートするためです 。



ここでは、少し余談し、すべてがどのように機能するかを説明します。



nuget packコマンドを使用してnugetパッケージを作成する場合、「– Symbols」フラグを指定できます。 その結果、nugetは、ライブラリの標準パッケージに加えて、pdbファイルとソースコードを含むパッケージ<package_name> .symbols.nupkgを作成します。 次に、このパッケージをSymbolSourceサーバーに配置すると、pdbファイルのインデックスが作成され、プロジェクトソースが内部ディレクトリに配置されます。 次に、Visual Studioで、シンボルサーバーへのアクセスが構成され 、必要に応じて、サーバーからpdbファイルとソースがダウンロードされます。 これにより、デバッグが可能になります。



しかし、ライブラリを公開フィードに入れることを敢えてしなかったので、ソースについて言うことはありません。 原則として、SymbolSourceはプライベートフィードの作成を可能にします。 ただし、コミュニティバージョンもサポートしているため、内部サーバーを展開できます。 いくつかの理由から、私たちは最後の道を行くことにしました。

そして、冒険が始まりました...

著者によると、シンボルサーバーを展開するタスクは、nugetフィードを展開するのとほとんど同じくらい簡単です。MVCアプリケーションを作成し、 nugetパッケージをダウンロードし、「App_Data」フォルダーと「Data」フォルダーに権限を与えます。



そうそう、1つの追加要件があります。Windows用デバッグツールをインストールし、web.configにそれらのパスを記述する必要があります。

 <appSettings> <add key="SrcSrvPath" value="C:\Program Files\Debugging Tools for Windows (x64)\srcsrv" /> </appSettings>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これは私たちがやったことです。SymbolServerのバージョン1.3.2をダウンロードし、インストール、構成、マジックスクリーンを見ました。







診断が開始されました-すべて順調です。 指示に従ってVisual Studioをセットアップします 。

しかし、デバッグは機能しません...

問題はすぐに見つかりました-シンボルパッケージを読み込むときに、サービスはソースコードを「データ」ディレクトリに保存しませんでした。 しばらくIISの設定をいじっていたため、問題が異なることに気付き、デバッグを開始しました。

まさに。 SymbolSourceサーバーを使用したSymbolSourceサーバーのデバッグ。

問題の原因も非常に迅速に発見され、最初はおかしくさえ思えました。 ManagedSourceExtractorクラスにはIsTemporaryCompilerFileメソッドがあります。このメソッドは、名前が示すように、特定のファイルが一時的なコンパイラファイルかどうかのサインを返します。 そして、この方法では、論理否定の余分な演算子がありました。 つまり、このメソッドは、それ以外のファイルはテンポファイルであると報告しました。 そのため、1つの余分な文字がサーバー全体を破壊しました。



さて、あなたは何ができますか...彼らは笑い、 ソースコードを分岐し、それを修正し、プルリクエストをするために集まりました。 そしてここで、同様のリクエストがすでに存在し、長い間作成されていることがわかります。 はい。パッケージバージョン1.3.2はすでに2か月間リリースされていますが、修正を含むパッケージのバージョンはまだリリースされていません。 今、これはそれほど面白くありませんでした。 より正確には、まったく面白くない。



しばらくの間、このサーバーを使用するか、別のサーバーを探すかについても考えました。 しかし、使用の以前の肯定的な経験...そして、nuget開発者はそれをデフォルトのサーバーにしました。 また、パッケージバージョン1.3.1は正常に機能します。 その結果、修正されたソースですべてを実行することにしました。 これを行うために、ローカルアセンブリ中に変換が実行されないため、「Web.config.transform」から「Web.config」に設定を追加コピーしました。

 <location path="WinDbg/pdbsrc"> <system.webServer> <handlers> <clear /> <add name="Deny" verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" /> <add name="Allow" verb="GET,HEAD" path="*" type="System.Web.StaticFileHandler" /> </handlers> <security> <requestFiltering> <fileExtensions allowUnlisted="true"> <clear /> </fileExtensions> </requestFiltering> </security> </system.webServer> </location>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで準備が整い、正常に機能するようになりました。 そして、それについて考える時間です

1つのnuget-serverが効果的なプロセスを構築するのに十分ではない理由（ベータ）。

そして、それは非常に単純な理由で十分ではありません：nugetは、現状では、会社全体が利用できるサーバーです。



これは、不安定になることがあるパッケージをそこに入れることができないことを意味します。 しかし、最終プロジェクトの開発でナゲットに配置されたアセンブリの変更が必要な場合、すぐに動作するように変更を加えるには、「バグのないコードを書く」カテゴリのタスクを実行します。



1台のサーバーで何らかの方法で作業するためのさまざまなトリックとスクワットがあります。 たとえば、dllを最終プロジェクトの「packages」フォルダー内のハンドルに置き換え、すべての準備が整ったときにのみnugetに公開します。 しかし、私たちはこれをすべて、人生を楽にするために行っています。 そのため、この問題にさらに詳しく取り組むことにしました。 少し考えた後、私たちは何かを思いつきました。



以下は、テストと理解のみを行っているプロセスのベータ版です。 したがって、コメントで読者の意見を聞くのは素晴らしいことです。



そのため、3つのナゲットテープを用意することにしました。

1. ローカルフィード 。 実際、これは単なるネットワークフォルダーです（Visual Studioでは、ソースを構成するときに、サーバーアドレスだけでなく、フォルダーへのUNCパスも指定できます）。 VCSでコミットするたびに、このテープにパケットが収集されます。 再利用可能なソースコードの開発者以外は、このテープを構成しません。
2. テストフィード 。 この役割は、SymbolSourceサーバーに論理的に当てはまります。SymbolSourceサーバーには、パッケージ用の独自のフィード（ギャラリーではなくフィード）があり、シンボルパッケージの公開時に通常のnugetパッケージが自動的に配置されます。 このフィードへの公開は、基本コードへの変更が完了し、使用を開始できるときに実行されます。 会社のすべての開発者と、最終製品のテストバージョンを収集するビルドマシンには、このテープのソースがあります。
3. リリースパッケージサーバー 。 このサーバーは、この記事の冒頭で展開したもので、UIやその他の便利な機能を備えています。 最も重要なパンは、ApiKeyの要件です。 ローカルテープは、SymbolSourceテープと同様にそれを必要としません（より正確には、SymbolSourceは必要ですが、検証はしません）。 そして、それらは必要ありません。 ここではすべてがより深刻であるため、誰もが公開できないようにすることは理にかなっています。 そして、誰かができれば、それが誰であるかは明らかです。 このサーバーでの公開は、基本コードが単独でテストされ、最終製品を使用してテストされた場合にのみ行われます。 すべての開発者向けにこのサーバー上でソースが構成され、最終製品のテストバージョンを組み立てるマシンを構築し、最終製品のリリースバージョンを組み立てるマシンを構築します。

一方では、最終製品のリリースバージョンをビルドするビルドマシンは、テストバージョンのパッケージを参照する場合、プロジェクトをアセンブルすることはありません。



一方、Visual Studioの[パッケージソース]設定で指定されたサーバーの順序（[ツール]、[ライブラリパッケージマネージャー]、[パッケージマネージャー設定]）で、パッケージのダウンロードの優先順位が設定されます。 したがって、たとえば、基本コードの開発者は3つのフィードすべてにアクセスでき、設定の順序はリリースフィード、テストフィード、ローカルフィードとして設定されます。



Visual Studioでは、次のようになります。







ところで、これは、ローカルサーバーの展開を支持する議論が非常に重要になる場所です。ローカルネットワーク上で作業するとき、インターネットアクセスからの独立性と高速化です。



「サーバーの1つがクラッシュした場合はどうなりますか？」と尋ねます。 まあ、それは問題ではありません。 結局のところ、「フレームワーク」の構築プロセスはすべてのテープのプロセスです。 つまり、パッケージバージョン1.2.3.4がリリースと宣言されている場合、3つのテープすべてに存在します。 また、たとえば、開発者は常にアクセスできます。



一方で、そのようなプロセスは非常に単純ではありませんが、一方で非常に自然であることが判明したため、その複雑さを頻繁に考える必要はありません-それは標準のワークフローに当てはまります。



まあ、よく考えた。 これで、テクノロジーに戻り、プロセス全体を自動化する継続的インテグレーションについて考えることができます。

しかし、この記事はすでに注目を集めています。

したがって、私たちは別れを告げ、第2部のためにいくつかの資料を残します。 そして、ここで読者に尋ねたいと思います。 トピックがあなたにとって興味深いと思われる場合は、コメントを残してください。 彼らは私たちが2番目の部分をより有用で有益なものにするのを助け、また彼女にできるだけ早くそれをリリースするように動機づけます。



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



UPD：通常、記事が追加された翌日、 SymbolSource.Server.Basicパッケージの更新 （バージョン1.3.3）がリリースされました。このリリースでは、シンボルサーバーの展開に関するセクションで説明したバグが修正されました。