ドッカーで、.NETのコア - 継続的インテグレーション（CI）を達成するためのサービスをミラーリングを使用し、アリ、アリクラウドクラウドCodepipelineコンテナ

これは、導入されたドッカーコンテナに公開ネットコアプログラムの内容を。しかし、それぞれのは、コマンドを入力するためにSSHを介してサーバにリンクされたスクリプトを実行している非常に面倒なことです。プログラマは、もっとも怠慢なされている、それは管理者の電子メールを通知するために失敗した場合、問題を解決するために、コンピュータを決して手動で解決されることができるならば、我々はテストが渡された場合、自動的に、自動的にユニットテストを実行するコードをビルドするためのコードを押すと、自動パブリッシングプログラム、より美しくそう。そして、この目標と継続的インテグレーション（CI）連続配信/展開（CD）を達成するためにそれが発明されました。CICDエリアが有名なツールです：ジェンキンスが、今回はそれを使用しないでください。あなたは、クラウドを使用する場合は、アリ、アリの雲は、すでに独自のプロセスジェンキンスサービスを構築することだけでなく、民間ドッカーミラー位置せず、同様の機能を提供し、現在、彼らは無料です。

アリクラウドCodepipelineサービス、ジェンキンスは、（実際には、私はそれはジェンキンスからコアエンジンだと思います）サービスの同様のセットです。

サービスをミラーリングアリクラウドコンテナは、鏡像倉庫で、それもプライベートでも、公共のかもしれません。

継続的インテグレーションCI

継続的インテグレーションは、トランクに統合されている（一日数回）頻繁にコードを意味します。
これは、2つの主な利点があります。

（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。

（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

継続的インテグレーションの目的は、高品質を維持しながら、製品の迅速な反復を可能にすることです。そのコア措置は、コードがトランクに統合される前に、テストの自動化を渡す必要があります。限りケースが失敗したテストがあるので、それが統合することはできません。
Martin Fowler氏は、「継続的インテグレーションは、バグを排除しませんが、彼らは非常に見つけるのは簡単で正確にするために。」と述べた
ブログルアンYifengグレート神からの抜粋を

ここでは、コンテナサービスとアリクラウドCodepipelineミラーでCICDネットコアプログラムを達成するための方法を示しています。

継続的インテグレーション

プロセス

ミラーミラーは自動的に成功を構築し、コードのプッシュ後Codepipelineのウェブフック機能によってトリガGiteeサービスを構築した後の容器の中に押し込ま

新しい.NETコアMVCプログラムを作成します。

CoreCICDTest .NETコアMVCと呼ばれる新しいプログラムを作成します。

    public class Program
    {
        public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                 .UseKestrel(options =>
                 {
                     options.Listen(IPAddress.Any, 5000);
                 });
    }

ケストレルは、ポート5000をリスニングする主な方法のプログラムを変更します。

@{
    ViewData["Title"] = "Home Page";
}


<h3>
    .NET CORE CICD TEST -- V 1.0
</h3>

ホーム/ indexビューを変更し

、それを実行し、効果、サイトが良いの.NET CORE CICD TESTを見て見る- V 1.0を

新しいプロジェクトを作成します。MSTestを

CoreCICDTest.Testsという名前のユニットテストを書くために使用されるCoreCICDTest MSTestをソリューションの新しいプロジェクトを作成します

    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
            string str = "00";

            Assert.AreEqual(str, "00");
        }
    }

それは正当なのtestMethod作り、ファイルを変更するUnitTest1 TestMethod1の方法

単体テストを実行し、すべて合格

Dockerfileファイルを追加します

FROM microsoft/dotnet:latest AS build
WORKDIR /app
COPY /. /app
RUN dotnet restore
WORKDIR /app/CoreCICDTest.Tests
RUN dotnet test CoreCICDTest.Tests.csproj
WORKDIR /app/CoreCICDTest
RUN dotnet publish -o ./out -c Release
EXPOSE 5000
ENTRYPOINT ["dotnet", "out/CoreCICDTest.dll"]

Dockerfileファイル名が接尾辞を持っていないことに注意してください、Dockerfileは、我々のコードをビルドする、自動的にドッカーコンテナでテストするために使用しました

Giteeに新しいプロジェクトを作成し、CoreCICDTestソリューションを押し上げます

無料サービスのGitのGiteeは、ローカルコードを押し上げるためにGitのプッシュコマンドを使用して、CoreCICDTestと呼ばれる新しいプロジェクトを作成します。

容器アリのクラウドサービス上や新アイテムのミラーを設定

ボタン、ポップ作成インターフェース「ミラーリポジトリを作成」をクリックします。名前空間kklldog、倉庫名を記入cicd_test

、ソースコード「ローカルリポジトリ」を選択し、[次へ]をクリックし、倉庫の作成を完了し、「ミラーリポジトリを作成」をクリックしてください

アリクラウドで新しいプロジェクトにとCodepipelineを設定

新しいプロジェクトのページにジャンプし、「新規」ボタンをクリックしてください。このインタフェースは、ジェンキンスさんと単純に同じです

项目名称填写cicd_test，这里没有.net相关的模板，囧！项目类型选择"构建一个自由风格的软件"就可以

点击下一步，填写项目基本信息，源码选择Gitee。构建类型默认是java，无所谓不用过它

点击“绑定云码账号”跳转至云码授权页面进行授权，以便阿里云可以拉取云码上的代码

进行授权后，源码管理界面就可以选择到Gitee上的项目，填写相应的分支

点击“增加构建步骤”，选择“镜像构建与发布”

在“镜像构建与发布”界面填写刚才创建的仓库信息

镜像仓库名格式为namespace/镜像仓库名。如果registry为Docker hub，拉取镜像命令为docker pull docker，则本配置项填写docker；如果 registry为阿里云Docker镜像仓库，拉取镜像命令为docker pull registry.cn-hangzhou.aliyuncs.com/acs-sample/wordpress， 则本配置项填写acs-sample/wordpress。

  Registry地址 用来配置docker registry地址，如果为空，默认使用Docker hub registry （https://index.docker.io/v1/）；如果使用阿里云registry， 请填写https://registry.cn-beijing.aliyuncs.com/v2/，其中地域（cn-beijing）根据用户实际的镜像仓库地域来修改。
  Registry证书 用来添加授权信息，请添加Registry授权类型的证书。

勾选“远程触发器”，先填写分支master，然后点击“生成”会生成触发器地址，这里好像有点小bug，有的时候这个地址不起效，如果不起效，多生成几次试试

在“构建后操作”界面填写邮件地址，用来接收邮件通知。勾选“每次不稳定的构建都发送邮件通知”

在Gitee的CoreCICDTest项目上配置WebHook

点击“管理>WebHook”菜单,进行WebHook的配置

WebHook的Url填写刚才Codepipeline里的“远程触发器”里生成的url地址；密码不填；勾选Push事件，勾选“激活”；点击“添加”按钮完成Webhook的配置。这样当我们push代码的时候，Gitee会自动给配置的url发送一次post请求，里面携带了详细的项目信息，提交信息等数据

当点击“添加”按钮后Gitee会立马往webHook配置的url地址Post一次请求，如果Codepipeline做出“Task has been scheduled to queue”的响应则说明Codepipeline开始进行自动构建了

返回Codepipeline项目列表，可以看到cicd_test项目已经构建成功了

这个时候构建的镜像也应该被推送到了容器镜像服务的cicd_test仓库里。

编写shell脚本运行容器

sudo vim publish_cicd_test.sh
输入以下内容
#!/bin/bash
sudo docker stop cicd_test
sudo docker rm cicd_test
sudo docker rmi registry-vpc.cn-shanghai.aliyuncs.com/kklldog/cicd_test
sudo docker login --username=xxx --password=xxx registry-vpc.cn-shanghai.aliyuncs.com
sudo docker pull registry-vpc.cn-shanghai.aliyuncs.com/kklldog/cicd_test:latest
sudo docker run --name cicd_test -d -p 7000:5000 -v /etc/localtime:/etc/localtime registry-vpc.cn-shanghai.aliyuncs.com/kklldog/cicd_test:latest

新建一个shell脚本命名为publish_cicd_test.sh;使用docker pull从仓库中拉取最近的镜像；使用docker run运行容器

sudo /bin/bash publish_cicd_test.sh

运行一下shell脚本

sudo docker ps -a

使用docker ps命令查看一下容器的运行状态,可以看到cicd_test容器已经运行成功了

使用浏览器访问一下对应的端口，网站已经正常运行了

Push代码触发构建

刚才的构建是我们配置Webhook的时候Gitee默认发送的一次请求，正常应该是用户使用git push命令后Gitee会发送一次请求，让我们模拟一下。

修改home/index页面，把V1.0改成V2.0
提交成功之后查看Codepipeline项目列表，等待项目构建成功之后，我们再次运行一下publis_cicd_test.sh脚本，成功之后再次使用浏览器访问一下对应的端口看看home/index是否已经变为了V2.0

可以看到home/index已经变成V2.0了，说明我们的持续集成流程跑通了

持续交付/部署

我们上面演示的过程离一开始说的push一下代码就自动构建自动发布程序就差一点点了，太晚了下次再说吧。