理論上の最初から1
DevOpsチームは何ですか？
それは広くDevOpsチームのコンセプトを受け入れてきたとして、近年では、企業は徐々にプロセスで一見繰り返し手作業から自動化プロセスは、すべてのことが多いラインで、特にインターネットに接続している開発者には、労働生産性を向上させるために非常に重要であったことに気づきました、最大の課題は、歩行テストおよび変更やバグの需要はありませんが、リリースプロセスの標準化されていないので、結果は未知の追加のワークロードが知られている他の問題の原因や鉛によって引き起こされるターゲット環境の構成エラーに掲載されます。 、リリースプロセスの生産環境を作ることはスムーズに常に存在ではありません。
DevOpsチームは、包括的な自動監視を行うために（統合、テスト、展開、およびリリースのインフラストラクチャ管理への）ソフトウェアを構築するのすべての側面のための強力な支持者によって特徴付けられる統一ソフトウェア開発とソフトウェア運用・保守の統合に取り組んでいます。目標は、ソフトウェア開発サイクルを短縮し、展開、周波数、より信頼性の高い出版物を改善し、ビジネス目標と一致することです。
実際の運用では、多くの企業、開発者、および運用・保守のための明確な境界は存在せず、運用・保守及び分離の開発の仕事の責任は、それが意味するものではありません場合でも、両側のキャリア開発は異なります。実際には、実際の運用、開発、および運用・保守担当者はまだ同じツール、統一されたプロセス、一貫した経営理念、プロセスの最適化と管理手法やツールの一連の実装を使用します。
継続的インテグレーションと連続配信とは何ですか？
継続的インテグレーション（継続的インテグレーション）と連続配信（連続配信）も、最も基本的なDevOpsチームの両方の企業の開発と配信の活動です。
アジャイルプロジェクト管理の考え方から継続的インテグレーション、コアチームメンバーが頻繁に自分の仕事を統合する必要があり、通常は一日一回の統合を必要とするが、もちろん、あなたも一日に複数回を統合するチームメンバーに依頼することができます。各統合後は、できるだけ早くビジネスプロセス管理を可能にする、自動的に継続的インテグレーションツールを使用して検証し、統合の結果（例えば、コンパイル、ユニットテスト、統合テスト、システムテストなど）自動ビルドツールで実行される未知のを発見対象問題。従来のソフトウェア・デリバリーでは、バックログは、すべての質問は全部、あるいはUAT（ユーザー受け入れテスト）リンクは、そのテスト時間がソフトウェアを伸長していることを、ソフトウェアが問題でも顧客になることができるようにお客様のサイトへの流入になり、システムをテストするかもしれません例には、マウスを発生しています。
実際には、一見単純な統合は、それは単純ではない、彼はビジネス管理プロセスの鉄の法則である必要があり、唯一厳密に常に使用可能な状態でソフトウェアことを確認するために、強制、それ以外の場合は、配信プロセスのいわゆる進歩が完了したことを意味何パーセント、ただ漠然としたエア・インタフェース・方言。
連続配信と不可分しばしば継続的インテグレーション、先生ジョー梁は「連続配信」の本を翻訳し、作者ジェズハンバーは言った：連続配信は持続可能な方法で、と言うことです能力、高速かつ安全です（特徴、構成、欠陥および試験を含む）コードの変更は、ユーザーが使用できるように、本番環境にデプロイ。この本の著者はまた、その本の最後の章である：それは（連続配信が）ちょうど新しいソフトウェアの配信方法論ではなく、また、ソフトウェア事業に依存して、また新しいパラダイムです。
連続配信と連続展開が、前者は、多くの場合、アクセスすることができるように、利用者の目の前にプッシュ環境を指し、それらを使用し、異なる、実際には、似たように見えることがあり、あなただけのターゲットコンピュータにインストールするパッケージを展開し、ユーザーはまたしてもよいですこれは、直接使用することはできません。
インターネット指向のソフトウェア企業は、多くの場合、過去数年間で持っているために、継続的インテグレーション/持続送達プロセスの完全なセットを確立していますが、企業の急速な発展で、いくつかのために、まだ比較的知られています過去の事業の急速な発展の後ろに依存することによって、主として人的・物的資源の睡眠は、それが企業の発展のニーズを満たすことができる会社の出力を確保するのに十分であるが、時に開発チーム企業の事業開発ニーズの大きさ、作業の重複に追いつくことができず、一見価値のない待機期間、試験後のタスクのバックログは、効果的に達成するためのソフトウェアの機能を測定することはできません、本質的には、更なる増加で経営管理のコストを発生します。
どこでシステムの方法論を得ることができますか？
、我々はまた、それにしたい人のための、完全なレビューしたコンテンツのすべての面でできるだけ試みたが、開発者のための手順を操作してボックスを提供するために努力していているオンライン情報のための完全な環境を構築する必要がある開発者のための知識学習システムの開発者やDevOpsチームの連続配信エリアは、あなたが実際には、あなたが本を見なければならない、環境を取るに満足していません。
継続的インテグレーションと優れた作品を多数の連続送達の分野では、と私は先生がブティックと呼ばれるジョー・ビーム「連続配信2.0」からうまくいくと思う、先生ジョー梁は彼のキャリアの中で蓄積された経験豊かな業界の専門家であり、製品開発におけるフィールド内の関連する豊富な経験、彼はまた、個人的に多くの企業の継続的な配信プロセスの最適化に関与し、これらの経験は、より包括的な視点の連続配信から問題を分析して、彼ができました。多くの導入を直接使用する管理方法は、本書で使用することができ、プロジェクトのケーススタディでは、ツールは、違いを確認するために、この地域の開発者の需要があるように思考の多くをもたらすことができます。
同社は、本質的に継続的インテグレーション企業/連続配信の実践であるためには、このツールは、完全なコアの難易度、プロジェクト管理の迅速な思考の使用方法の難しまだ嘘、きめの細かいタスク分割ソフトウェアを構築し、単一のタスクを実行することはできませんより良いテスト、TDDはおそらく良いモデルであるが、それは前方に落下しないTDDになります基本的なスキルの開発者のための高い要件を、置いてもよいです。
素早く製品の需要を確認するには？、すばやく設置によるモデルの検証例えば「連続配信2.0」における一連の方法、窓を飾るために6つの方法、特性の最小の実現可能な方法で、DC、指向検索、かかしの法則,,最小実行可能な製品の方法を、提案しました要件からのソフトウェア実装にプロセス全体を改善し、企業のために多くの利便性をもたらすことができます。
開発段階において、分岐Gitのソースコード管理ツールの美しさブランチのスイッチング特性を採用技術の特性であってもよいし、一緒に有機結合およびコードの需要は、需要から、プロジェクト管理ツールに依存しながら=「=実現「これ、二重保険の検証要件を提供する、完全な閉ループを公開、劉さんに私の最初の先生のスイッチング特性」チーターアクション - 「アジャイルの変換を参照してくださいする本は、ソフトスイッチの形で、避けるために完成未開発ライン上の進歩は、巨大なリスクを引き起こし、そしてここで本も、この方法を述べました。同じ特性は、私がしようとします投稿、.NETアセンブリのブランチで使用することができます。
待機期間を短縮する方法については、筆者に述べた方法は次のとおりです。
1は、「プル」の行は、容量の処理のボトルネックを拡大することにより、保持されている場合は迅速に、よりニーズに届けるように、例えば、一緒に価値の流れを作るを通じて、このアプローチは、一時的に処理能力の側面を改善するために、チームを確保することができるように思われます出力が、明らかではない良好な尺度は、より合理的な尺度は、刺激要求を下流側から上流側に下流上流の生産能力の処理能力に応じて決定されるべきです。この作業では、粒子サイズ、より均一な需要を必要とする、需要は、同様の小さな作業負荷需要ので、開発プロセススムーズに行うことは容易でより客観的に分割されています。
2、自助のタスク：他の人がブロックされたときに関連するタスクの完了が発生し、特定のミッションクリティカルな障害物を避けるように同期させることができるように、チームは特定の汎用的なスキルを知っているようであり、全体のプロセスを遅らせます。
ここで私はあまりにも本の本質を説明しませんが、1、お金のための絶対値で始めることができます興味を持っています。
2、全体のプロセスやデプロイメント環境
次に、私はこの記事の件名を入力します、私は最初の継続的インテグレーション/管理プロセスを提供し続け、単純なエンタープライズ・クラスを構築し、その後、実現のプロセスの流れは、より詳細な紹介を行いました。
フローチャート
[画像]（
）
このプロセスでは、マスター/ DEVの使用パターンを分岐します。
図1は、コードエディタ、静的コードスキャニング、自動化されたユニット・テスト・プロセスの後に提出コードDEV分岐ため、スルー実行した後、プル要求によりマスターブランチに提示テストコードとによってテストコードを、そこテスターレビューとコード検査担当者が合併します。
2、コードのテスターは、コードによって確認された分岐コードレビュー担当者マスターコードレビューで確認のために提出され、解放生成するためのパケットを生成DEV。
コンポーネントの指示に従ってと
インストールするための処理では、以下のツール。
1、OpenJDKのインストール
2、インストールと関連したプラグジェンキンス
3、インストールPostgresDb
4、インストールSonarQube
5、インストールdotnetsdk3.1
6、gitのインストール
7、パッケージ管理を実現するために、Windowsのバージョン用のネクサスパッケージマネージャをインストールします。
8、零細企業の催促の手紙のためにQyと微信通知またはHTTPリクエストをインストールします。
まあ、設置環境が導入されていません。。
インストール（追補）
ジェンキンスバージョン2.190.3をインストール項1は、OpenJDKのバージョンopenjdk12.0をインストールしました。ジェンキンスとOpenJDKのをインストールした後、環境変数を設定する必要があります。
2、SonarQubeは、バージョン7.9.1をインストールしていない、公式サイトの指示に従って、推奨するデータベースが含まれます：7.9.1でのSQLServer \オラクル\ postgresdbを、以降では、もはや推奨mysqlのです。
3、組み込みメモリデータベースに基づいてSonarQubeデフォルトH2データベースは、テスト環境で使用することができますが、本番環境では推奨されません。
sonarqubeをインストールした後5、およびデータベースは、データベース・コンフィギュレーション・アドレスsonarqube / confに/ sonar.propertiesファイル、およびsonarqubeサービスの再起動を変更する必要があります。
[画像]（ 
）
Windowsシステムでは、SonarQubeサービスをインストールするsonarqube-XXX \ binに\ WINDOWS-x86-64のフォルダInstallNTService.batをクリックして、StartNTService.batはSonarQubeアプリケーションサービスを開始するために使用されます。データベースの構成が失敗した場合、SonarQubeは起動に失敗し、次のエラーが求められます。
[ソナー-1510653879773]輸送層上にキャッチ例外[[ID：0x346b46fb、/127.0.0.1:59330 => /127.0.0.1:9001]、接続閉鎖
にjava.io.IOExceptionを：アン既存の接続を強制的に遠隔によって閉じられましたホスト
図6に示すように、自作のパッケージソースNugetマネージャので、ビルドが行われ、エラーが表示され、ジェンキンス用途
ジェンキンスプロジェクトタイプ
在jenkins中提供了自由风格、单流水线、多分支流水线、多配置项目等不同类型的项目，可以根据实际情况进行取舍，在本人的尝试过程中，分别总结了三种不同类型的项目可适用的场景：
自由风格项目
操作流程简单，无需配置groovy脚本，即可简单的完成项目的自动化构建。
在自由风格模式的项目中，实现代码编译的过程主要在构建窗口中，主要使用dotnet -相关命令来完成。包括：
1、dotnet restore 还原依赖包。
2、dotnet build 编译
3、dotnet publish -o ./bin/release 发布到指定目录下。
4、如果需要使用sonarqube来进行静态代码检查，需要在服务器上安装dotnet-sonarscanner组件，这个组件是基于.net core构建的静态代码检查组件，安装的命令为：
dotnet tool install --global dotnet-sonarscanner --version 4.8.0；
5、如果采用.net framework 传统框架，则可以继续使用原来的SonarScanner.MSBuild.exe组件进行代码检查结果的上传。
6、如果需要在自由风格项目中使用powershell脚本，可以在jenkins=》插件管理=》可用插件中搜索powershell即可。
单流水线项目
单流水线项目：可适用于只有一个分支和一套环境需要部署时的项目构建，其发布流程需要使用groovy脚本来实现。点击查看pipeline的语法
1、在流水线项目中，都在项目文件的根目录中添加jenkinsfile文件（无扩展名）作为jenkins编译时的脚本文件，而这个文件的脚本语法采用groovy语言，并支持开发者按照脚本语言进行扩展。
2、在单流水线项目中不支持groovy的分支判断条件，支持逻辑比较简单的脚本。
3、与编译有关的结构均写在jenkinsfile中，因此jenkins的UI界面可以理解为配置与项目相关的环境变量信息。
4、可以在jenkinsfile中定义输入的参数，例如：
parameters{
string(name:'ProjectName', defaultValue: 'Enter Your ProjectName', description: 'Enter your project name here')
string(name:'Contact', defaultValue: '"@All","xxx"', description: 'Enter Your Contract')
string(name:'RepoUrl', defaultValue: 'https://xxx.com/xxx/xxx.git', description: ' gitee代码路径')
}
在jenkins界面中，可以显示成
[图片]( 
)
在具体场景下就可以通过jenkins界面传入相关参数进行编译的测试了。
多流水线项目
多分支流水线项目：使用于一个仓库下各分支不同环境需要部署时的项目构建，其发布流程也需要使用groovy脚本实现。
1、多流水线项目支持使用分支判断条件的语法，因此可以使用的场景更多。
2、其他的总体上和单分支流水线差不多，此处就不在赘述了。
以下编写了一个简单的示例，仅供参考。
pipeline{
agent any
parameters{
string(name:'Contact', defaultValue: '"@All",""', description: 'Enter Your Contract')
string(name:'RepoUrl', defaultValue: '', description: ' 代码路径')
string(name:'SonarUrl', defaultValue: 'http://xxx:9000', description: ' sonar代码路径')
}
stages {
stage('When Master') {
when {
expression {BRANCH_NAME==~/(master)/}
}
steps{
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'xxx', url: params.RepoUrl]]])
}
}
stage ("When Dev"){
when {
branch 'dev'
}
steps{ rojectName}")
}
}
stage("test"){
when{
expression{return true}
}
steps{
echo "OK"
}
}
stage('Web Dev Build') {
steps{
}
}
}
post{
success{
SendToWeChatWork("CI Task success,ProjectName is ${params.ProjectName}")
echo 'Publish Success'
}
failure{
SendToWeChatWork("CI Task Failure,ProjectName is ${params.ProjectName}")
echo 'Publish Failure'
}
}
}
def SendToWeChatWork(content) {
}多配置项目
如果组件代码需要在不同的配置、不同的环境下重复部署，其基本逻辑类似，只是配置不同，就可以使用多配置项目。
好吧，我就没有尝试了，因为我已经用了多流水线项目来实现了。在这篇示例中对多配置项目有比较详细的用法，需要可自取。
总结
将企业级持续集成的环境搭建起来本身并不难，难的是如何将整套体系与公司现有的开发流程相结合，考虑到受康威定律的影响，不同的组织对于新事物的接受程度总是不同的，原有组织或许已经习惯了基于手工拷贝再部署的模式，而目前采用这种持续集成、持续发布的模式，会出现哪些问题，我已经做好了准备了。