タグ付けされた質問 「continuous-integration」

ソフトウェアエンジニアリングでは、継続的インテグレーション（CI）により、ソフトウェア製品全体の継続的な構築と自動テストが頻繁に実行されます。少なくとも1日に1回、多くの場合1日に数回、時にはバージョン管理システムにチェックインするたびに頻繁に。

8
CIツールでプロセスを実行するのは合理的ですか？
私の会社では、さまざまなcronジョブ（複数のシステム上）の泥沼があり、長年の適切な開発とその後の怠慢の結果として、ビジネスを機能させるプロセスを手動で開始しています。 いつか、明らかな理由から、より集中化されたソリューションを考え出す必要があります。 私たちが蹴っているのは、継続的インテグレーションソフトウェア（Jenkins）を使用してこれらのプロセスを実行することです。 私の質問は、他の企業がこれを行っているのですか？これは一般的に受け入れられている慣行ですか？これは、名前に暗黙的に含まれるCIツールの定義と矛盾しませんか？他のオプションはありますか？ 注：https : //wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins Jenkinsは、「cronジョブやprocmailジョブなどの外部で実行されるジョブの実行の監視」に焦点を当てていると主張しています。これがまさに私が話していることであるかどうかはわかりません。
7
ビルドがほとんど常に壊れているときに効率を維持する方法
私は同じソースコードを共有し、継続的に統合されている中規模のチームで働いていますが、私たち全員が同じブランチで作業しなければならないため、ビルドはほとんど常に壊れています。 また、壊れたビルドを軽減するために最近導入されたルールもあります。これは、ビルド中は誰もチェックインできないことを示しています。 そうは言っても、1日の間に誰もがチェックインできる10〜15分のウィンドウを持っています。 チームが成長するにつれて、チェックインの機会の窓はさらに小さくなります。そのため、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更が何も破壊しないことを保証するのがさらに難しくなります。悪循環を見ることができます。 このような環境で私が効果的に仕事を続けられるようにするために何をお勧めできますか。また、私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。
4
バージョン管理にgithub、ブランチ、自動リリースを使用する方法は？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 今まで、Git / Githubの基本的な概念のほとんどを理解していましたが、全体像を理解するのはまだ困難です。 これらは私がこれまでに何とか作業を始めたものです。 コミットをプッシュする ブランチで作業する Githubを継続的な統合システムであるTravis CIと統合する Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースをGithubのリリースとしてZIPとしてリリースします。 しかし、私はこれまでにプロジェクトのアルファ版またはベータ版にしか取り組んでいなかったため、実際にバージョン付きリリースを見たことはありません。 したがって、バージョン管理、個別のバージョンの維持、バージョンの修正プログラムなどについて詳しく知りたいと思います。 次のことが起こるようにするにはどうすればよいですか： 私のプロジェクトの異なるバージョン、たとえばバージョン1.1.0と2.0.0を持っている バージョンの修正プログラムをプッシュしたり、バージョンを1.1.1や2.0.1に変更したりすることができます。 継続的統合システムがコミット時にそのバージョンを自動的にビルドし、成功した場合は、その特定のバージョンのリリースを公開します。 私は次のオプションの間で疑っています： バージョンごとにタグを使用する必要がありますか？もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか？ バージョンごとにブランチを作成する必要がありますか？もしそうなら、それはたくさんのブランチを作成しませんか（1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます） バージョン番号はどのように指定しますか？バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか？この場合、それが重要であれば、Javaプロジェクトになります。
4
インタープリター言語にCIを使用するにはどうすればよいですか？
これまでに継続的インテグレーションシステム（CI）を使用したことがありません。私は主にMATLAB、PythonまたはPHPでコーディングします。これらのどちらにもビルドステップがなく、CIがどのように作業に使用できるかわかりません。大企業の大規模プロジェクトの友人から、言葉は関係ないと言われました。 ビルドステップがない場合、CIがどのように役立つかわかりません。CIは、単体テストを実行するテスト環境と考えることができます。何か不足していますか？
6
科学ソフトウェアの継続的統合
私はソフトウェアエンジニアではありません。私は地球科学の分野で博士課程の学生です。 ほぼ2年前、科学ソフトウェアのプログラミングを開始しました。継続的インテグレーション（CI）を使用したことはありません。主に、最初はそれが存在することを知らず、このソフトウェアに取り組んでいるのは私だけだったからです。 現在、ソフトウェアのベースが実行されているため、他の人がそれに興味を持ち始め、ソフトウェアに貢献したいと考えています。計画では、他の大学の他の人がコアソフトウェアへの追加を実装しています。（バグが発生する可能性があります）。さらに、ソフトウェアは非常に複雑になり、テストがますます難しくなりました。また、作業を継続する予定です。 この2つの理由により、私はCIの使用についてますます考えています。私はソフトウェアエンジニアの教育を受けたことがなく、CIについて聞いたことがありません（私たちは科学者であり、プログラマーではありません）。 私はいくつかのアドバイスを得たい質問がいくつかあります： まず、ソフトウェアの動作の簡単な説明： ソフトウェアは、必要なすべての設定を含む1つの.xmlファイルによって制御されます。入力引数として.xmlファイルへのパスを渡すだけでソフトウェアを起動すると、実行され、結果を含むいくつかのファイルが作成されます。1回の実行に最大30秒かかります。 科学的なソフトウェアです。ほとんどすべての関数には複数の入力パラメーターがあり、そのタイプはほとんどが非常に複雑なクラスです。これらのクラスのインスタンスを作成するために使用される大きなカタログを持つ複数の.txtファイルがあります。 では、私の質問に行きましょう。 ユニットテスト、統合テスト、エンドツーエンドテスト？：私のソフトウェアは現在、約30.000行のコードで、数百の関数と〜80クラスです。すでに実装されている数百の関数の単体テストの作成を開始するのは、ちょっと奇妙に感じます。だから私は単にいくつかのテストケースを作成することを考えました。10〜20個の異なる.xmlファイルを準備し、ソフトウェアを実行します。これがエンドツーエンドテストと呼ばれるものだと思いますか？私は頻繁にこれを行うべきではないことを読みましたが、すでに動作するソフトウェアをお持ちの場合、それはスタートとして大丈夫ですか？または、すでに動作しているソフトウェアにCIを追加しようとするのは、単純な馬鹿げたアイデアでしょうか。 関数パラメーターを作成するのが難しい場合、単体テストをどのように作成しますか？ 私は機能を持っていると仮定double fun(vector<Class_A> a, vector<Class_B>)し、通常、私はタイプのオブジェクトを作成するために複数のテキストファイル内の最初の読み取りに必要があるだろうClass_AとしClass_B。Class_A create_dummy_object()テキストファイルを読み取らずにダミー関数を作成することを考えました。また、何らかのシリアル化の実装についても考えました。（クラスオブジェクトは複数のテキストファイルにのみ依存するため、クラスオブジェクトの作成をテストする予定はありません） 結果が大きく変動する場合のテストの書き方 私のソフトウェアは、大きなモンテカルロシミュレーションを利用し、繰り返し動作します。通常、1000回の反復があり、反復ごとに、モンテカルロシミュレーションに基づいてオブジェクトのインスタンスを500〜20.000個作成しています。1つの反復の1つの結果のみが少し異なる場合、今後の反復全体が完全に異なります。この状況にどのように対処しますか？最終結果は非常に変動するので、これはエンドツーエンドのテストに対する大きなポイントだと思いますか？ CIに関するその他のアドバイスは大歓迎です。
2
VCSにソフトウェアバージョン番号を保存することをお勧めしますか？
などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。 バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。 最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。 2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。 どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。 ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？ 現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。
9
IDEのワンクリックビルドの代わりに別のビルドツールを使用するように、一人の開発者を説得する
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 私の長年のJavaプログラミング、最近ではScalaで、Ant、Maven、Gradle、またはJava用のビルドツールを使用したことがありません。私が働いていたすべての場所に、そのすべてを処理するビルドマネージャーがいました-開発と単体テストのためにIDEでローカルにコンパイルし、ソースコードをチェックインし、必要なことをしたビルドマネージャーに通知しました共有環境用に全員のファイルをコンパイルします。 契約の合間に、私は自分で資金を提供するプロジェクトに取り組んでおり、実際にお金を稼ぐのに十分なレベルに達しつつあります。私も潜在的な投資家を揃えており、今後数週間以内にベータ版を見せることを計画しています。 しかし、ずっとIDEのビルドボタンをクリックするだけで、Jarファイルが作成され、正常に機能します。もちろん、従来の知識では、私は自分でAnt / Maven / Gradleスクリプトを作成し、IDEの代わりにそれを使用する必要があると示唆していますが、私の状況での具体的な利点は何ですか（単独で作業）？ 私はこれらのビルドツールの使用方法について読んでいますが、IDEがワンクリックで行うこと（IDEで生成されたものプロジェクトのAnt XMLは700行を超えています）。エラーが発生しやすく、時間がかかり、私の状況では不必要に見えます。学習曲線は言うまでもありません。学習曲線は、他のすべての作業から時間を奪って、製品を人々に見せるために準備します。
6
連続配信は実際にはどのように機能しますか？
継続的デリバリーは良さそうに聞こえますが、私のソフトウェア開発経験の年は、実際には機能しないことを示唆しています。 （編集：明確にするために、私は常に多くのテストを自動的に実行しています。私のチェックは、各チェックインで自信を得る方法についてです。これは完全な形式のCDであると理解しています。 。毎週（一部は正しく行われればまだCDであると考えるかもしれません）、2週間、または1か月の繰り返しです。 完全なテストカバレッジは不可能です。あなたは多くの時間を費やす必要があります-そして、時間はお金です-すべての小さなもののために。これは貴重ですが、他の方法で品質に貢献するために時間を費やすことができます。 自動的にテストするのが難しいものもあります。たとえば、GUI。Seleniumでさえ、GUIが不安定かどうかはわかりません。かさばるフィクスチャがないと、データベースアクセスをテストするのが難しく、データストレージの奇妙なコーナーケースをカバーすることさえできません。同様に、セキュリティや他の多くのもの。事実上単体テストが可能なのは、ビジネスレイヤーコードのみです。 ビジネス層でも、テスト目的で引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成に多くの時間を費やすことができますが、これは実際の実装とは異なる場合があります。 統合/機能テストは単体テストを補完しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に時間がかかります。（再初期化しないと、テスト環境に一貫性がなくなります。） リファクタリングまたはその他の変更により、多くのテストが中断されます。それらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することであれば問題ありませんが、実際には重要な情報を提供するものではなく、意味のない低レベルの実装の詳細のためにテストが中断することがよくあります。多くの場合、微調整は、テスト対象の機能を真に確認することではなく、テストの内部構造を修正することに焦点を当てています。 バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単には一致しません。
11
継続的インテグレーションシステムのベビーシッター
私のチームにおける私の役割の1つはビルドパーソンです。私は、ビルドスクリプトを維持/更新し、継続的インテグレーションサーバー上で「スムーズに」ビルドすることを確認する責任があります。私は通常、この仕事を気にしませんが、CIサーバーを常にベビーシッターしているように感じることがよくあります。 ビルドが中断した場合、作業中のストーリーを削除し、ビルドの失敗を調査する必要があるため、このジョブは時々面倒な場合があります。ビルドの失敗はチームで毎日発生します。開発者は、コミットする前にローカルでビルドしない場合があるため、CIサーバーでのテストは失敗します。この状況では、ビルドがあまりにも長く壊れないように、「悪いコミット」をした人にすぐに連絡を取りたいです。CIサーバーに、デバッグする必要のある奇妙な状態が時々（はるかに少ない頻度で）存在します。 多くの成熟したチームが継続的インテグレーションを使用していることは知っていますが、優れたプラクティスに関する資料はあまりありません。 私の問題は、継続的インテグレーションがあまり成熟していない、またはこれが単なる仕事の一部であると指摘していますか？ 従うべきいくつかの良い習慣は何ですか？成熟した継続的インテグレーションの特徴は何ですか？ 更新 いくつかのコメントに答える代わりに、代わりに更新を行います。アプリをビルドするときにビルドサーバーが実行することを正確に実行する単一のシンプルなコマンドがあります。コンパイル、すべてのユニット/統合、およびいくつかのクイックUIベースのテストを実行します。 みんなの答えを読んで、2つの大きな問題があるかもしれないと感じています。 ビルドが失敗したときにCIサーバーが十分に不平を言っていない。 開発者は、コミットが正常に実行されることを確認する責任を全員に負わないと感じています。 私のチームで物事を難しくしているのは、大規模なチーム（10人以上の開発者）がいて、仕事をしていないときでも、数人のオフショアチームメンバーがコミットしていることです。チームが大規模であり、頻繁な小さなコミットが好ましいことを確立したため、1日で実際に多くのアクティビティを行うことがあります。
9
統合テストをどのようにスケーリングしますか？
現在の製品で増加している統合テストの規模を拡大するための技術と戦略を調査しており、開発およびCIプロセスの一部として（人間的に）残ることができます。 約200以上の統合テストで、（デスクトップ開発マシン上で）完全なテスト実行を完了するために1時間のマークをすでに打っています。これは、定期的なプッシュプロセスの一部としてスイート全体を実行することを許容する開発者の能力に悪影響を及ぼしています。それは、それらをうまく作成することについて規律付けられる動機に影響しています。主要なシナリオのみを前面から背面まで統合テストし、テストを実行するたびにゼロから構築される本番環境をミラーリングする環境を使用します。 実行に時間がかかるため、テスト実行の集中度に関係なく、ひどいフィードバックループが発生し、テスト実行の終了をマシンで待機する多くの無駄なサイクルが発生します。フローと進捗、健全性、持続可能性に対するより高価な悪影響を決して気にしないでください。 この製品の速度が低下し始める前に、10倍以上の統合テストが行​​われると予想されます（実際にはわかりませんが、機能に関してはまだ始まったばかりではありません）。私たちは、数百または数千の統合テストに合理的に期待する必要があります。 明確に言うと、これがユニットテストと統合テストの議論にならないようにしようとすることです。この製品では、TDDを使用した単体テストと統合テストの両方を行っています。実際、アーキテクチャのパターンを他の領域に変更する際に重大な変更を導入する場所を検証する必要があるため、私たちが理にかなっているサービスアーキテクチャのさまざまな層で統合テストを行いますシステム。 技術スタックについて少し。現在、テストをエンドツーエンドで実行するために、（CPUとメモリを集中的に使用する）エミュレーション環境でテストしています。これは、noSqlバックエンド（ATS）の前にあるAzure REST Webサービスで構成されています。Azureデスクトップエミュレーター+ IISExpressで実行することにより、運用環境をシミュレートしています。開発マシンごとに1つのエミュレータと1つのローカルバックエンドリポジトリに制限されています。 また、同じエミュレート環境で同じテストを実行するクラウドベースのCIもあり、現在のCIプロバイダーではクラウドでのテスト実行に2倍の時間がかかります（2時間以上）。ハードウェアパフォーマンスの観点からクラウドCIプロバイダーSLAの制限に達し、テスト実行時の許容値を超えました。公平を期すために、仕様は悪くはありませんが、社内の汚いデスクトップマシンの半分の品質であることは明らかです。 テストの論理グループごとにデータストアを再構築し、テストデータをプリロードするテスト戦略を使用しています。データの整合性を包括的に保証しながら、これにより各テストに5〜15％の影響が追加されます。したがって、製品開発のこの時点では、そのテスト戦略を最適化することはほとんど得られないと考えています。 長いことと短いことです。各テストのスループットを最適化できましたが（それぞれ30％〜50％であっても）、数百のテストで近い将来に効果的にスケーリングすることはありません。1時間は今でも人間の許容範囲をはるかに超えています。それを維持するには、全体のプロセスを1桁改善する必要があります。 そのため、テスト時間を大幅に短縮するために使用できる手法と戦略を調査しています。 より少ないテストを書くことはオプションではありません。このスレッドで議論しないでください。 非常に高価ですが、より高速なハードウェアを使用することは間違いなくオプションです。 並列の別個のハードウェアでテスト/シナリオのグループを実行することも、間違いなく推奨されるオプションです。 開発中の機能とシナリオに関するテストのグループ化を作成することはもっともらしいですが、最終的には、システムが変更の影響を受けないという完全なカバレッジまたは信頼性を証明することはできません。 デスクトップエミュレーターで実行する代わりに、クラウドスケールのステージング環境で実行することは技術的に可能ですが、テスト実行に展開時間を追加し始めます（テスト実行の開始時に、〜20分ごとに展開します）。 システムのコンポーネントを独立した対数部分に分割することはある程度妥当ですが、コンポーネント間の相互作用は時間とともに増加することが予想されるため、その上で限られた燃費が期待されます。（つまり、変更は他の人に予期しない形で影響を与える可能性が高い-システムがインクリメンタルに開発されるときによく起こるように） この分野で他の人がどの戦略（およびツール）を使用しているかを知りたかった。 （他の人が特定の技術セットを使用してこの種の困難に直面している可能性があると信じる必要があります。） [更新：2016年12月16日：結果の議論のため、CI並列テストにより多くの投資をすることになりました：http : //www.mindkin.co.nz/blog/2015/12/16/16-jobs]
7
継続的インテグレーション：どの周波数ですか？
私は常に各コミットの後にビルドを開始しましたが、この新しいプロジェクトでは、アーキテクトは「15分ごとに1つのビルド」に頻度を変更するように頼みました。コミットごとに構築する」。 まず、いくつかの詳細： Objective-C（iOS 5）プロジェクト 10人の開発者 各ビルドには実際に約1分かかり、ビルドと単体テストが含まれます。 統合サーバーはMac Miniであるため、ここでは計算能力は実際には問題になりません。 JenkinsとXCodeプラグインを使用します 私の主張は、コミットするたびにビルドすれば、他の開発者を頻繁に煩わせることなく、今何が間違っているかをすぐに確認し、エラーを直接修正できるということです。さらに、この方法でテスターはUTエラーに悩まされることが少なくなります。彼の主張は、開発者は「ビルドエラー」メール（最初の壊れたビルドのみにメールを送信するように構成できるため、完全に真実ではない）であふれ、頻度が適切な場合にメトリックを実行できないというものでしたビルドの数が多すぎます。 だから、これについてあなたの意見は何ですか？
8
枝が積もらないようにする
機能がテスト用にステージングされるようになると、規模が大きくなるにつれて問題に遭遇し始めますが、すべてがテストされ、承認された新しい機能がテスト用にステージングされます。 これは、テスト済みの機能と未テストの機能の組み合わせがあるため、本番環境にほとんどプッシュできない環境を作成しています。これは一般的な問題であると確信していますが、まだ私たちにとって良いリソースが見つかりませんでした。 いくつかの詳細： BitBucketのGIT Azureへのスクリプト展開用のJenkins 私が望んでいるのは、機能が環境を移動するときに機能を分離し、準備ができているものだけをプッシュする方法です。
3
分岐は継続的な統合を中断しますか？
この記事「成功したGit分岐モデル」は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。 私はhg主に使用しますが、この議論はどのDVCSでも問題ないと主張します。 現在のワークフローは、各開発者がマスターリポジトリのクローンを作成することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。 そこで、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、アンシブルなど）でワークフローを改善したいと考えています。 実部 さて、上記のモデルはうまく機能しますが、ブランチはCIを壊す可能性があります。機能ブランチは、developmentCIとマージをスムーズにするために、オリジンと同期する必要があります（記事によると、ブランチになります）。 アリスとボブが2つの機能に取り組んでいると言います。しかし、アリスは翌日に行われます。ボブの機能には1週間かかります。Bobが完了するまでに、彼の変更は古くなっています（おそらく、Aliceは一部のクラスをリファクタリング/名前変更しています）。 1つの解決策は、毎朝、開発者がプルmaster/originして、変更があるかどうかを確認する必要があることです。Aliceがコミットした場合、Bobは自分のワークスペースにプルしてマージし、機能ブランチが最新になるようにします。 これは良い方法ですか？ これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？つまり、すべての開発者がGitHub / Bitbucketのマスターリポジトリにコミット権限を与えて、新しいブランチを作成できるようにする必要がありますか？または、これはローカルで行われますか？ 最後に、記事が提示するモデルは、ブランチがと同期していない場合、CIを破壊する必要がありorigin/masterます。ナイトリービルドを実行したいので、開発者は仕事を離れる前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？
5
単独プロジェクトで継続的統合ツールが提供する利点は何ですか？
ソロプロジェクトを行う場合-CIツールを使用してリポジトリからビルドしますか？私はチーム環境でハドソンとクルーズコントロールを使用しました。誰かがチェックインしたらすぐにビルドすることが不可欠です。 バージョン管理の価値はまだ明らかだと思いますが、ローカルマシンでビルドしたばかりで、誰もコミットしていないように、コミットするたびにビルドする必要がありますか？
9
技術的な専門知識なしで開発プロジェクトをリードする方法
私は自分のキャリア全体にわたって実践的な開発者であり、コードを扱うことが大好きです。私は常に、特定の技術に関する専門知識がほとんどまたはまったくないチームリーダーにleadしているが、特定の実装を主張しています。 今、私は見ているガラスの向こう側にいることに気づきました。私はC＃で実装されるファットクライアントの主な開発者ですが、私の専門はJava Webアプリケーションの構築です。どの言語でもデザインパターンとオブジェクト指向パラダイムを活用できることは知っていますが、コーディング標準、プロジェクトライフサイクルツール、リリース/配布手順に関しては私は迷っています。1〜2か月以内に基本を習得できることは間違いありませんが、時間とともにしか収集できない特定の経験があります。 どうすればよいですか？開発中に嫌っていたプロジェクトリーダーにならないようにするにはどうすればよいですか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.