此博客文章是“在Azure上部署Spring Boot和Angular应用程序”系列文章的一部分，这里是文章的完整列表：
- Creating a Spring Boot and Angular application for Azure (1/7)
- Creating and configuring Azure Web App and MySQL to host a Spring Boot application (2/7)
- Using Azure Pipelines to build, test and deploy a Spring Boot and Angular application (3/7)
- Using Azure Application Insights with Spring Boot (4/7)
- Using Azure Application Insights with Angular (5/7)
- Configuring Azure CDN to boost Angular performance (6/7)
- Configuring Azure Redis Cache to boost Spring Boot performance (7/7)
Deploying a Spring Boot Application to Azure
There are several ways to deploy a Spring Boot application to Azure. One of the easiest way is to use the Maven Plugin for Azure App Service. For our use-case, we want to go beyond the simple "Hello, world" application, and thus we are going to set up a full CI/CD (Continuous Integration/Continuous Deployment) solution using Azure Pipelines.
与往常一样，我们在这里对预算很敏感：Azure Pipelines提供了一个慷慨的免费套餐，对于我们来说应该足够了，因此我们不应该支付任何费用。
Creating an azure-pipelines.yml file
为了使用Azure Pipelines构建和测试我们的应用程序，我们需要一个天蓝色管道文件放在我们项目的根目录。
有了JHipster，我们很幸运，我们只需要运行吉普斯特并回答几个问题，以具有非常完整的Azure Pipelines配置。
You can check the generated file on this commit.
This pipeline will build and test the application (both the Spring Boot back-end and the Angular front-end), so it is a "Continuous Integration" pipeline. If you need more informations on Azure Pipelines tasks, you should refer to the Azure Pipelines Documentation. Creating a simple Maven build is very easy, then doing more complex configurations like we do with JHipster might require a bit more time.
Deploying automatically with Azure Pipelines to Azure Web App
在上一节中，我们创建了一个天蓝色管道文件：所有测试通过后，我们将向其中添加新任务，以发布生产版本。 结果，它将不再只进行“连续集成”，而不会进行完整的“连续部署”。
打开天蓝色管道文件，并在文件末尾添加：
- script: ./mvnw package -Pprod -DskipTests
displayName: 'BUILD: creating production build'
- task: CopyFiles@2
inputs:
SourceFolder: 'target'
Contents: '*.jar'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: bugtracker
实际上，我们正在使用3个任务：
- 一个用于使用JHipster进行生产构建的工具。 请注意，在这里我们跳过了应该通过的测试。另一个用于将生成的文件JAR文件复制到存储工件的目录中。最后一个是获取该工件并将其发布的。
这将自动在Azure Pipelines中发布您的生产构建的人工制品。
警告由于Azure Web App使用了人工制品，因此应将其命名为app.jar，我们将不得不正确命名人工制品。 最简单的方法是，使用finalName您的属性pom.xml：
app
...
You can check the changes we just made to set up "Continuous Deployment" on this commit.
Push the application to GitHub and set up Azure Pipelines
如果尚未完成，则将应用程序推送到GitHub：如果您不想公开应用程序，请记住GitHub提供了免费的无限私有存储库。
Once your application is on GitHub, go to the GitHub marketplace to install and setup Azure Pipelines.
You can then log in to Azure Devops to set up your Azure Pipelines:
- 创建一个新项目。On the left-hand menu, select "Pipelines > Builds" and create a "new pipeline".选择“ GitHub”，然后选择上述步骤中刚刚创建的GitHub项目。当我们创建了一个天蓝色管道上一节中的文件，它将被自动提取，因此您只需“运行”它（使用右上角的按钮）来观看Azure Pipelines正在构建的应用程序。
由于此构建是“全栈”构建，因此它将编译，打包和测试您的所有Spring Boot和Angular代码。 您可以想象，这是一个相当复杂的过程，需要花费5分钟以上的时间才能完成。
Deploy the application to Azure Web App
一旦Azure Pipelines首次构建了您的应用程序，它将发布该项目的人工制品。 一个新的“发布”按钮将出现在右上角：单击它以创建一个新发行版。
您将在此处看到已发布的人工制品，并将能够为其添加新的“阶段”，以便将其自动部署到生产中。
创建一个新的“阶段”，然后选择“将Java App部署到Azure App Service”。 创建此阶段后，将其打开并：
- 给它起一个有意义的名字将其连接到您的Azure订阅：您将需要单击“授权”按钮并遵循授权向导将应用程序类型更改为“ Linux上的Web App”，因为这是我们在上一篇博客文章中创建的选择您的应用服务名称
然后，您需要修改在此阶段配置的2个任务：
- 删除第一个任务，即“将WAR部署到Azure App Service”，因为我们没有部署WAR。启用第二个任务，称为“将JAR部署到Azure App Service”。
You can now go to the "Pipelines > Releases" and click on the "Create release" button. This should take the previously generated artefact (made by the 天蓝色管道），并将其自动部署到您的Azure Web App实例。
您现在可以连接到您的应用程序，并在生产中使用它。 由于这是一个JHipster应用程序，因此需要记住一些提示：
- There are 2 accounts by default,
admin(with passwordadmin), anduser(with passworduser) - The database schema is managed using Liquibase, so when the application starts it automatically update the database schema. That schema was created in the previous blog post, using MySQL Workbench.
- If you ran the application in developement on your local computer, JHipster filled up your database with some dummy data using faker.js. In production mode, as you are supposed to use some real data, your database will not have this data by default.
现在，每次构建通过时，我们的应用程序都将自动部署到生产环境中，并由Azure Web Apps自动进行管理。 没有更多的生产问题，只需“ git push”就可以完成！
Start-up time considerations, and budgets
您可能已经注意到，该应用程序的启动速度有点慢，需要花费超过1分钟的时间。 我们最坏的情况是100秒，因此应该在2分钟以内结束，但这仍然是很多时间！
这里有两个原因：JHipster和硬件。 实际上，我们可以通过各种调整（主要是禁用诸如Liquibase之类的功能）使JHipster在大约三分之一的时间内启动。 性能提升可能很重要，因为这里我们处于JVM内存的极限，因此垃圾收集器正在努力工作，删除一些功能将对其有很大帮助。
然后，所选择的硬件不是很好，因为我们希望精打细算，并选择了一个“ B1”盒：第一个月免费，然后非常便宜（每月约30美元）。 这就是我们的内存太有限的原因，也是我们的CPU有限的原因。 Azure将“ ACU”（即Azure计算单元）和一个B1盒中的CPU能力计为100个ACU。
测试功能更强大的实例非常简单：在您的Azure Web App中，选择“向上扩展”，然后选择“ P2V2”实例。 升级是即时完成的！ 在具有420个ACU（比“ B1”的计算能力大4倍以上）的新硬件上，现在的启动时间仅为15秒。 当然，您可以随时缩小比例并返回到“ B1”实例。