将其推上，并在项目的pipeline页面中观察它的失败. 这是因为它丢失了您的Heroku帐户的认证密钥. 不过，修复这个问题相当简单. 首先你需要你的Heroku API key. Get it from the 管理帐户页面，然后添加以下内容 secret variables 在你的GitLab仓库的CI/CD设置:

• HEROKU_EMAIL:您用于登录Heroku的电子邮件地址
• HEROKU_AUTH_KEY你从Heroku那里得到的钥匙

这将导致每次推送时都有一个工作的GitLab到Heroku部署. 至于发生了什么:

• 在推到主人时
  • Heroku CLI在容器中安装和验证.
  • 你的代码被推给了Heroku.
  • 在Heroku中捕获数据库的备份.
  • Migrations are run.

您已经看到，通过将所有事情自动化，您不仅节省了时间 git push，您还会在每次部署时创建数据库备份! 如果出现任何问题，您将拥有数据库的副本以进行恢复.

创建暂存环境

但是，等等，快速的问题，您的特定于生产的问题会发生什么? 如果由于开发环境与生产环境差异太大而遇到奇怪的bug怎么办? 当我运行迁移时，我曾经遇到过一些奇怪的SQLite 3和PostgreSQL问题. 具体细节我不知道，但很有可能.

我严格使用PostgreSQL进行开发, 我从来没有像这样错配数据库引擎, 并且我勤奋地监控我的堆栈是否存在潜在的不兼容性.

那是件乏味的工作，我赞赏你的自律. 就我个人而言，我太懒了. However, 你能保证所有潜在的未来开发者都能做到这一点吗, collaborators, or contributors?

Errrr— Yeah, no. You got me there. 其他人会把它搞砸. 你的观点是什么?

我的意思是，你需要一个登台环境. 这就像制作，但又不是. 登台环境是您演练部署到生产环境并尽早发现所有错误的地方. 我的登台环境通常反映生产环境, 并且我将生产数据库的副本转储到暂存部署上，以确保不会出现令人讨厌的极端情况扰乱我的迁移. 在登台环境中，您可以不再像对待小白鼠那样对待用户.

This makes sense! 我该怎么做呢?

这就是有趣的地方. I like to deploy master 直接到分级.

等等，那不是我们现在部署生产的地方吗?

是的，但现在我们要部署到暂存.

But if master 部署到登台，我们如何部署到生产?

通过使用几年前就应该做的事情:控制代码的版本并推送Git标签.

Git tags? Who uses Git tags?! 这听起来好像有很多工作要做.

It sure was, but thankfully, 我已经做了所有的工作，你可以把我的代码转储，它就能工作了.

首先，将关于暂存部署的块添加到 .gitlab-ci.yml 文件，我创建了一个新的Heroku应用程序，叫做 toptal-pipeline-staging:

…

variables:
  APPNAME_PRODUCTION: toptal-pipeline
  APPNAME_STAGING: toptal-pipeline-staging


deploy_to_staging:
  stage: deploy
  environment:
    name: staging
    url: http:// APPNAME_STAGING美元.herokuapp.com/
  script:
    - git remote add heroku http://git.heroku.com/ APPNAME_STAGING美元.git
    - Git push heroku master
    —heroku pg:backups:capture——app $APPNAME_PRODUCTION
    —heroku pg:backups:restore '——app $APPNAME_PRODUCTION '——app $APPNAME_STAGING——confirm $APPNAME_STAGING
    —Heroku运行rails db:migrate——app $APPNAME_STAGING
  only:
    - master
    - tags

...

然后更改生产块的最后一行，使其运行在语义上版本化的Git标签上，而不是主分支上:

deploy_to_production:
...
  only:
    - /^v(?'MAJOR'(?:0|(?:[1-9]\d*)))\.(?'MINOR'(?:0|(?:[1-9]\d*)))\.(?'PATCH'(?:0|(?:[1-9]\d*)))(?:-(?“预映”+ (\ [0-9A-Za-z -).[0-9A-Za-z-]+)*))?(?:\+(?“构建”(0-9A-Za-z -) + (\.[0-9A-Za-z-]+)*))?$/
    上面的semver模式改编自http://github.com/semver/semver.org/issues/59 # issuecomment - 57884619

现在运行这个将会失败，因为GitLab足够聪明，只允许“受保护的”分支访问我们的秘密变量. 要添加版本标签，请转到您的GitLab项目的存储库设置页面并添加 v* to protected tags.

让我们回顾一下现在发生的事情:

• 在推送到主服务器或推送标记的提交时
  • Heroku CLI在容器中安装和验证.
  • 你的代码被推给了Heroku.
  • 在Heroku中捕获数据库产品的备份.
  • 备份转储在您的暂存环境中.
  • 迁移在暂存数据库上运行.
• 在推入标记为提交的语义版本时
  • Heroku CLI在容器中安装和验证.
  • 你的代码被推给了Heroku.
  • 在Heroku中捕获数据库产品的备份.
  • 迁移在生产数据库上运行.

你现在感到强大了吗? I feel powerful. I remember, 我第一次来这么远的地方, 我打电话给我的妻子，详细地解释了整个管道. 她甚至不懂技术. 我对自己印象深刻，你也应该如此! 干得好，走了这么远!

Testing Every Push

But there’s more, 反正电脑也在帮你做事, 它还可以运行所有您懒得做的事情:测试, linting errors, 你想做什么都可以, 如果其中任何一个失败了, 他们不会继续部署.

我喜欢在我的管道中使用它，它使我的代码审查变得有趣. 如果一个合并请求通过了我所有的代码检查，它就值得被审查.

Add a test block:

test:
  stage: test
  variables:
    POSTGRES_USER:测试
    POSTGRES_PASSSWORD: test-password
    POSTGRES_DB: test
    DATABASE_URL: postgres: / / $ {POSTGRES_USER}: $ {POSTGRES_PASSSWORD} @postgres / $ {POSTGRES_DB}
    RAILS_ENV: test
  services:
    - postgres:alpine
  before_script:
    - curl - sl http://deb.nodesource.com/setup_8.x | bash
    - apt-get update -qq && 安装libpq-dev
    - curl -o- l http://yarnpkg.com/install.sh | bash
    - source ~/.bashrc
    - yarn
    安装打包器——no-ri——no-rdoc
    - bundle install -j $(nproc)——path vendor
    - bundle exec rake db:setup RAILS_ENV=test . exe
  script:
    - bundle exec rake规格
    - bundle exexrubocop

让我们回顾一下现在发生的事情:

• 在每次推送或合并请求时
  • Ruby和Node设置在一个容器中.
  • 安装依赖项.
  • The app is tested.
• 在推送到master或推送标记的提交时， 前提是所有的测试都通过了
  • Heroku CLI在容器中安装和验证.
  • 你的代码被推给了Heroku.
  • 在Heroku中捕获数据库产品的备份.
  • 备份转储在您的暂存环境中.
  • 迁移在暂存数据库上运行.
• 在推入标记为commit的语义版本时， 前提是所有的测试都通过了
  • Heroku CLI在容器中安装和验证.
  • 你的代码被推给了Heroku.
  • 在Heroku中捕获数据库产品的备份.
  • 迁移在生产数据库上运行.

退后一步，惊叹于你已经完成的自动化水平. 从现在开始，您所要做的就是编写代码并推送. 如果你喜欢，可以在阶段阶段手动测试你的应用, 当你有足够的信心把它推向世界, 用语义版本标记它!

自动语义版本控制

是啊，很完美，但还是少了点什么. 我不喜欢查找应用程序的最新版本并明确标记它. 这需要多个命令，让我分心几秒钟.

Okay, dude, stop! That’s enough. 你现在只是过度设计了. 它很有效，很聪明，不要因为做得过火而毁了一件好事.

好吧，我这么做是有充分理由的.

Pray, enlighten me.

我曾经和你一样. 我对这个安排很满意，但后来我搞砸了. git tag 按字母顺序列出标签， v0.0.11 is above v0.0.2. 我曾经不小心标记了一个版本，并在六个版本中继续这样做，直到我发现自己的错误. 那时我决定把这个也自动化.

Here we go again

好了，谢天谢地，我们有npm的强大功能，所以我找到了一个合适的包:Run Yarn添加——dev标准版本 并添加以下内容到您的 package.json file:

  "scripts": {
    “释放”:“标准版”,
    “major”:“纱线释放-释放-作为主要”，
    “minor”:“纱线放行——放行——作为minor”，
    "patch": "纱线释放-释放-作为补丁"
  },

现在您需要做最后一件事，将Git配置为默认推送标签. 现在，你需要逃跑 git push --tags 把标签往上推，但是会自动地定期这样做 git push 就像跑步一样简单吗 Git配置——全局推送.followTags true.

要使用你的新管道，当你想要创建一个发布运行时:

• yarn patch for patch releases
• yarn minor for minor releases
• yarn major for major releases

如果你不确定“专业”这个词是什么,” “minor,” and “patch” mean, 更多信息请访问 语义版本控制站点.

现在您终于完成了您的管道，让我们回顾一下如何使用它!

• Write code.
• 提交并推送它进行测试，并将其部署到登台.
• Use yarn patch 标记补丁发布.
• git push 将其推向生产环境.

总结和进一步步骤

我只是触及了CI/CD管道的表面. 这是一个相当简单的例子. 通过将Heroku与Kubernetes交换，您可以做更多的事情. 如果您决定使用GitLab CI，请阅读 yaml docs 因为通过在部署之间缓存文件或保存工件，您可以做更多的事情!

您可以对该管道进行的另一个巨大更改是引入外部触发器来运行语义版本控制和发布. Currently, ChatOps 是他们付费计划的一部分，我希望他们把它发布到免费计划中. 但想象一下，通过一个Slack命令就能触发下一个图像!

Eventually, 当您的应用程序开始变得复杂并需要系统级依赖时, 您可能需要使用容器. 当这种情况发生时，请查看我们的指南: Docker入门:简化Devops .

这个示例应用程序确实是实时的，您可以找到它的源代码 here.