heroku_heroku我的新家

heroku

In the final part of his series, the author provides a retrospective of using Heroku for the very first time, detailing the new design and lessons learned.

在他的系列的最后一部分中，作者提供了第一次使用Heroku的回顾，详细介绍了新设计和获得的经验教训。

In the “Moving Away From AWS and Onto Heroku” article, I provided an introduction of the application I wanted to migrate from Amazon’s popular AWS solution to Heroku. Subsequently, the “Destination Heroku” article illustrated the establishment of a new Heroku account and focused on introducing a Java API (written in Spring Boot) connecting to a ClearDB instance within this new platform-as-a-service (PaaS) ecosystem.

在“ 远离AWS和Onto Heroku的迁移”一文中，我介绍了我想从亚马逊流行的AWS解决方案迁移到Heroku的应用程序。 随后，“ Destination Heroku ”一文说明了一个新的Heroku帐户的建立，并着重介绍了一个Java API(用Spring Boot编写)连接到这个新的平台即服务(PaaS)生态系统中的ClearDB实例。

The third article in the series (“Using Heroku for Static Web Content”) provided a manner in which static web files could also be serviced by Heroku. My primary goal with this series is to find a solution that allows me to focus my limited time on providing business solutions instead of getting up to speed with DevOps processes.

该系列的第三篇文章(“ 将Heroku用于静态Web内容 ”)提供了一种方式，Heroku也可以为静态Web文件提供服务。 本系列的主要目标是找到一个解决方案，使我可以将有限的时间集中在提供业务解决方案上，而不是跟上DevOps流程的步伐。

With everything now running in Heroku, it is time to take a step back and perform a retrospective on my new application journey.

现在一切都在Heroku中运行了，是时候退后一步，对我的新应用程序之旅进行回顾。

详细介绍新设计 (Detailing the New Design)

From an application and design perspective, there was literally no change to the application, now running 100% in Heroku:

从应用程序和设计的角度来看，该应用程序几乎没有任何更改，现在可以在Heroku中100％运行：

The image above is an identical copy of the image which was in part one of this series. My point in reporting this information is that I was able to very easily pick up my existing application in AWS S3 and AWS Elastic Beanstalk and migrate the exact source code over to Heroku.

上图是本系列第一部分的图像的相同副本。 报告此信息的目的是，我能够非常轻松地在AWS S3和AWS Elastic Beanstalk中选择我现有的应用程序，并将确切的源代码迁移到Heroku。

事情如何改变 (How Things Have Changed)

While the application was very easy to port over to Heroku, there were changes in the manner by which the application is updated and deployed now.

虽然很容易将应用程序移植到Heroku，但是现在更新和部署应用程序的方式有所变化。

Parts two and three talked about how I simply needed to execute one additional git-based command in order to deploy changes to the API and client instances running on Heroku:

第二部分和第三部分讨论了如何简单地执行一个附加的基于git的命令，以便将更改部署到在Heroku上运行的API和客户端实例：

git push Heroku

git push Heroku

Since parts two and three of the series were published, I took a few minutes to understand more about GitLab CI/CD and have introduced some very simple automations. Now, when a pull-request is merged into the master branch of my Spring Boot API repository, a .gitlab-ci.yml file similar to the one shown below is automatically executed:

自从该系列的第二部分和第三部分发布以来，我花了几分钟时间来了解有关GitLab CI / CD的更多信息，并介绍了一些非常简单的自动化技术。 现在，当请求请求合并到我的Spring Boot API存储库的master分支中时，将自动执行类似于以下所示的.gitlab-ci.yml文件：

Shell

贝壳

stages:- build- deploymaven-build:image: maven:3-jdk-8stage: buildscript: "mvn package -B -DskipTests"deploy:stage: deployimage: ruby:latestscript:- apt-get update -qy- apt-get install -y ruby-dev- gem install dpl- dpl --provider=heroku --app=$HEROKU_APP --api-key=$HEROKU_API_KEYonly:- master

In the example above, the GitLab CI/CD process uses a Java 8 container which includes Maven to build the Spring Boot framework which serves as the API for my application. Once built, the CI/CD process will utilize Ruby to perform the deployment to application name which matches the $HEROKU_APP variable using the API key provided in the $HEROKU_API_KEY variable.

在上面的示例中，GitLab CI / CD流程使用Java 8容器(其中包括Maven)构建Spring Boot框架，该框架用作我的应用程序的API。 构建完成后，CI / CD流程将使用Ruby使用$ HEROKU_API_KEY变量中提供的API密钥对与$ HEROKU_APP变量匹配的应用程序名称进行部署。

As a result, my work on this project is 100% feature-based now. I can follow a Git-Flow strategy, where I create a feature branch for my work. Then, when ready, I will issue a pull-request and merge my changes into the master branch. At that point (and only that point) the CI/CD pipeline will fire and push the changes to Heroku, which will deploy a new version of the API.

结果，我在这个项目上的工作现在是100％基于功能的。 我可以遵循Git-Flow策略，在其中为我的工作创建一个功能分支。 然后，准备就绪后，我将发出拉取请求并将更改合并到master分支中。 在那一点(也只有那一点)，CI / CD管道将触发并将更改推送到Heroku，后者将部署API的新版本。

The Angular client repository was also updated to include a pipeline similar to the one listed below:

Angular客户端存储库也进行了更新，以包括类似于以下所列的管道：

Shell

贝壳

image: node:8.10.0cache:paths:- node_modules/stages:- deploy_productionProduction:image: ruby:latestonly:- masterstage: deploy_productionscript:- apt-get update -qy- apt-get install -y ruby-dev- gem install dpl- dpl --provider=heroku --app=$HEROKU_APP --api-key=$HEROKU_API_KEY

For the client, there is really only a deployment stage, which also utilizes Ruby and the same variables to merge into the Heroku target repository. Once the push is complete, Heroku automatically deploys a new version of the web client.

对于客户端，实际上只有一个部署阶段，该阶段还利用Ruby和相同的变量合并到Heroku目标存储库中。 推送完成后，Heroku将自动部署Web客户端的新版本。

GitLab users: This work is actually automated if the Heroku CI functionality is enabled for your repository. For users which enable this functionality, all updates to the master branch which successfully pass the testing stage can be auto-deployed.

GitLab用户：如果为您的存储库启用了Heroku CI功能，则这项工作实际上是自动化的。 对于启用此功能的用户，可以自动部署对master分支的所有成功通过测试阶段的更新。

可支持性和可维护性 (Supportability and Maintainability)

With all of the changes in place, deployments are easy and allow me to focus on adding new features to the application. In fact, at eighteen minutes past the hour, I received a text from my mother-in-law indicating that the application was not working correctly. Within a few minutes, I stashed my changes and created Issues in GitLab and a bugfix branch (from the master repository). In this case, I needed to make a minor change to the API and the Angular client.

完成所有更改后，部署变得很容易，让我专注于为应用程序添加新功能。 实际上，在凌晨18点钟，我从婆婆那里收到一条短信，指示该应用程序无法正常运行。 几分钟后，我保存了更改，并在GitLab和一个bugfix分支(来自主存储库)中创建了Issues。 在这种情况下，我需要对API和Angular客户端进行较小的更改。

Within 15 minutes, the issue was identified, fixed, and validated using local instances of the API and the Angular client. The code for both repositories were checked in and I went ahead and created a PR, even though I am the only person working on this project. Once the branch was merged into both repositories, the CI/CD processed kicked off. Not even five minutes later, both applications in Heroku were restarted and functional.

在15分钟内，使用API​​和Angular客户端的本地实例对问题进行了识别，修复和验证。 两个仓库的代码都已签入，尽管我是从事此项目的唯一人员，但我继续创建了PR。 一旦分支合并到两个存储库中，CI / CD处理就开始了。 甚至不到五分钟后，Heroku中的两个应用程序都重新启动并开始运行。

Using Heroku, I was able to resolve the issue and deploy a fix in less than twenty minutes. During that time, I focused on development and standard git usage. Zero time was spent trying to understand and remember DevOps-related items which have nothing to do with providing features and support for my application owner.

使用Heroku，我能够在不到二十分钟的时间内解决问题并部署了修复程序。 在这段时间里，我专注于开发和标准git的用法。 花了零时间来理解和记住与DevOps相关的项目，这些项目与为我的应用程序所有者提供功能和支持无关。

Of course, another option would be to revert to an earlier deployment of the services. Heroku provides an impressive manner by which a hosted application can be rolled back to a prior state. In fact, it is as easy as clicking a link in the application:

当然，另一种选择是恢复服务的早期部署。 Heroku提供了一种令人印象深刻的方式，通过它可以将托管应用程序回滚到先前的状态。 实际上，这就像单击应用程序中的链接一样简单：

In the screenshot below, clicking the “Roll back to here” link will initiate the process of reverting the service to a prior state.

在下面的屏幕快照中，单击“回滚到此处”链接将启动将服务恢复到先前状态的过程。

Using the CLI, the “heroku releases” command provides a summary of deployments:

使用CLI，“ heroku版本”命令提供了部署摘要：

Shell

贝壳

$ heroku releases=== amhs Releases - Current: v12v12  Deploy 1somekey johnjvester@gmail.com  2020/05/24 14:34:51 -0400v11  Deploy 2somekey johnjvester@gmail.com  2020/05/23 15:21:56 -0400

Now, if I wish to roll back to v11, I simply execute the following command:

现在，如果我想回滚到v11，我只需执行以下命令：

heroku rollback v11

heroku rollback v11

As always, rolling back should be reserved to rare cases and not be considered a permanent solution.

与往常一样，回滚应保留在极少数情况下，而不应视为永久解决方案。

成本差异 (Cost Differences)

When I finished part three of this series, I was confident that Heroku was going to be my destination for this application. In order to save costs, I decided to shut down my Elastic Beanstalk instance and set the maximum instances to zero. My thinking is that I would incur zero costs, since the application was not running. Turns out, my assumption was incorrect, and I ended up getting an invoice for $18.49, which covers the database cost and charges related to keeping the Elastic Beanstalk instance available. There were also small charges for AWS S3. Again, time was required in order to understand a far more complex billing structure than I really need … or have time to worry about.

当我完成本系列的第三部分时，我确信Heroku将成为该应用程序的目标。 为了节省成本，我决定关闭我的Elastic Beanstalk实例并将最大实例数设置为零。 我的想法是，由于该应用程序未运行，因此我将产生零成本。 原来，我的假设是不正确的，最终我得到一张18.49美元的发票，其中包括数据库成本和与保持Elastic Beanstalk实例相关的费用。 AWS S3也收取少量费用。 再次，需要时间来理解比我真正需要的复杂得多的计费结构……或者有时间担心。

On the Heroku side, I decided to upgrade to the Hobby plan for both applications. The $14 a month that I expect to pay is a 40% savings over my standard charges from AWS. I don’t have to worry about the database right now, since the usage is really low and all of the historical data in the application only accounts for 6% of the database size for the Ignite option. Nothing to worry about there at this point.

在Heroku方面，我决定针对这两种应用程序升级到Hobby计划。 我希望每月支付14美元，这比我从AWS收取的标准费用节省了40％。 我现在不必担心数据库，因为使用率确实很低，并且应用程序中的所有历史数据仅占Ignite选项数据库大小的6％。 此时，无需担心。

I opted to use the Hobby plan primarily to avoid my mother-in-law having to wait for the system to spin up. She only uses the application a few days per month, so I am certain every time she attempts to access the system, she would have to wait. Tip from experience, it is never a good thing to make your mother-in-law wait. :)

我选择使用Hobby计划主要是为了避免我的岳母不得不等待系统启动。 她每个月仅使用几天时间，因此我确定每次尝试访问系统时都必须等待。 经验提示，让婆婆等待永远不是一件好事。 :)

I also enjoy the application metrics that are displayed starting with the Hobby plan:

我还喜欢从Hobby计划开始显示的应用程序指标：

Having insight into the current response time and basic usage levels is all I really need for my application.

我对应用程序的真正需求是了解当前的响应时间和基本用法级别。

On the database side, the (free) Ignite MySQL ClearDB instance provides a basic dashboard that also meets my needs:

在数据库方面，(免费的)Ignite MySQL ClearDB实例提供了一个基本的仪表板，也可以满足我的需求：

heroku-buildpack-static (heroku-buildpack-static)

While the Node.js approach is working quite well for me, I wanted to bring up the heroku-buildpack-static project, which is designed for single page static web applications similar to my Angular client. To read more about this pretty cool project, Terence Lee created a getting started document.

尽管Node.js方法对我来说效果很好，但我想提出一个heroku-buildpack-static项目，该项目专为类似于Angular客户端的单页静态Web应用程序而设计。 要阅读有关这个​​非常酷的项目的更多信息， Terence Lee创建了一个入门文档 。

Had I found this project earlier on my journey, I would have considered using this approach. While the buildpack is experimental and not a product by the Heroku team, I feel like the stability is certainly at a level by which I would trust for my application.

如果我在旅​​途中较早地找到了这个项目，我会考虑使用这种方法。 尽管buildpack是试验性的，而不是Heroku团队的产品，但我认为稳定性肯定处于我可以信赖的应用程序的水平上。

结论 (Conclusion)

While in college, I met a guy named Stacy. At the time, we both were serious about establishing a professional position in the music industry. However, fate had a different journey for us. I ended up working in Information Technology, and Stacy returned to college to become a dentist. Fast forward thirty years and we are both established in our careers. We still talk when time allows.

在大学期间，我遇到了一个叫Stacy的家伙。 当时，我们俩都很认真地致力于在音乐行业中建立专业地位。 然而，命运对我们来说是另外一段旅程。 我结束了在信息技术领域的工作，Stacy回到大学成为一名牙医。 快进三十年了，我们俩都建立了自己的事业。 如果时间允许，我们仍然会谈。

My point in bringing up Stacy is that he always gives his time to his friends and family. This extends beyond dental care, spanning a wide range of assistance that he has provided over the years. In fact, it was his inspiration which led me to want to use my skills and abilities to provide a better application experience for my mother-in-law. While she may not understand everything involved with providing her an improved way to do business, she is grateful for my assistance.

我提起Stacy的目的是，他总是将时间分配给他的朋友和家人。 这超出了牙科保健的范围，涵盖了他多年来提供的广泛援助。 实际上，正是他的灵感使我想利用自己的技能和能力为婆婆提供更好的申请经验。 尽管她可能不了解为她提供改善的经商方式所涉及的一切，但她感谢我的帮助。

At the same time, I feel like the team at Heroku has a similar mission as Stacy and myself. They use their expertise to provide a platform where developers can quickly establish an application. Once in place, supporting and enhancing the application is as simple as checking in the code itself. Truly, this approach has provided exactly what I needed.

同时，我觉得Heroku团队的任务与Stacy和我本人相似。 他们利用自己的专业知识来提供一个平台，开发人员可以在其中快速建立应用程序。 一旦就位，支持和增强应用程序就像检入代码本身一样简单。 确实，这种方法完全满足了我的需求。

Regardless of what we do in life, it is important to remain focused. One way to remain focused is to remove competing priorities. With AWS, I felt like I needed to continue to understand aspects of their ecosystem, which really did not lead to new features for my application. With Heroku, my entire time can be spent providing value to my customer.

无论我们在生活中做什么，保持专注都是很重要的。 保持专注的一种方法是消除相互竞争的优先事项。 使用AWS，我觉得我需要继续了解他们的生态系统的各个方面，这实际上并没有为我的应用程序带来新功能。 使用Heroku，我可以将全部时间用于为客户提供价值。

Have a really great day!

祝您有美好的一天！

翻译自: https://levelup.gitconnected.com/heroku-my-new-home-f8ecfbc33886

heroku