diff --git a/pr-1714/.nojekyll b/pr-1714/.nojekyll new file mode 100644 index 000000000..e69de29bb diff --git a/pr-1714/101.html b/pr-1714/101.html new file mode 100644 index 000000000..314b7e9f0 --- /dev/null +++ b/pr-1714/101.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the tags/cd-101.html page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/101/index.html b/pr-1714/101/index.html new file mode 100644 index 000000000..7baca7c37 --- /dev/null +++ b/pr-1714/101/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../tags/cd-101.html page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2014.html b/pr-1714/2014.html new file mode 100644 index 000000000..1cf8d12e4 --- /dev/null +++ b/pr-1714/2014.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02.html b/pr-1714/2014/02.html new file mode 100644 index 000000000..1945c4d78 --- /dev/null +++ b/pr-1714/2014/02.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24.html b/pr-1714/2014/02/24.html new file mode 100644 index 000000000..0e50af8c8 --- /dev/null +++ b/pr-1714/2014/02/24.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/build-promotion-go.html b/pr-1714/2014/02/24/build-promotion-go.html new file mode 100644 index 000000000..3c520628d --- /dev/null +++ b/pr-1714/2014/02/24/build-promotion-go.html @@ -0,0 +1,262 @@ + + + + + + + + + + + + + + + + Build Promotion with GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Build promotion with GoCD

+

Sriram Narayan

+

+

+
+ +
+

A typical build may have to clear several hurdles before it can be considered fit for release. For example:

+ +
    +
  1. Unit tests
    2. +
  2. Static and dynamic metric thresholds (e.g. toxicity, coverage)
    3. +
  3. Packaging
    4. +
  4. Integration tests
    5. +
  5. UI tests
    6. +
  6. Performance tests
    7. +
  7. Regression tests
    8. +
  8. Deployment tests (install, uninstall, upgrade)
    9. +
  9. Manual exploratory tests
    10. +
  10. Regulatory, compliance checks
    11. +
  11. Clearance from UAT, staging
    12. +
+ +

Each of these hurdles may be viewed as a promotion level for the build (although, in practice, formal promotion levels are more coarse-grained). These promotion levels may be activated automatically (by the success of the previous level) or manually (by approved promoters). Note that these levels are very different from what is encountered in a source promotion model.

+ +

Avoid source or stream promotion models

+ +

In an earlier post, we said: "Deploy packages, not just a tag, branch or binary". With respect to promotions, we could say:

+ +

"Promote packages, not just a tag, branch/stream or binary"

+ +

Promoting at the level of source (rather than package) violates the build-once rule - one of the key principles outlined in the CD book:

+ +

"…the binaries you release should be the same binaries that have been through the rest of your deployment pipeline, so you can be sure that what you release is what you tested. Apart from the fact that nobody has tested the binaries that came from the release stream, there is also a chance that differences could be introduced in the build process, perhaps by the operations team using a different minor revision of the compiler or a different version of some dependency. Such differences can lead to bugs in production that take days to track down."

+ +

Because of this, a source/stream promotion model is fundamentally unfit for the world of continuous delivery:

+ +

"One of the objectives of the deployment pipeline is to allow frequent check-ins to mainline on large teams which may result in temporary instabilities, while still allowing you to get rock-solid releases out of the door. In this sense, the deployment pipeline is antithetical to the source promotion model. The main advantage of the deployment pipeline lies in the rapid feedback you get on the effect of every change on the fully integrated application—something that is impossible in the source promotion model."

+ +

Use your CI/CD server to manage promotions

+ +

Source based promotion models probably made more sense in a pre-CD era when the version control system was the only source of truth for the level of readiness of a codebase. Today, the CD tool is a more appropriate system of record for builds (and deployments) and their promotions. Again, the CD book backs this up:

+ +

"The other essential facility that must be provided by the tool you use to manage your deployment pipeline is the ability, for each stage, to see which builds have passed all the previous stages in the pipeline and are hence ready for the next stage. It should then be possible to choose one of these builds and press a button to have it deployed. This process is known as promotion.

+ +

Promoting builds at the press of a button is what turns the deployment pipeline into a pull system, giving everybody involved in the delivery process the ability to manage their own work"

+ +

Model your promotion process into the CD tool

+ +

In general, a build/deployment pipeline is also a promotion pipeline. GoCD's support for pipelines and stages with automatic or manual approvals makes it easy to model and visualize your promotion process into the CD value stream. A stage runs only when the previous stage has passed - this is like an automatic promotion gate. Manual stage approvals may also be used where needed.

+ +

Modeling promotion levels into the CD value stream

+ +

Modeling promotion levels (P1…P4) itno the CD value stream

+ +

GoCD 13.3

+ +

GoCD 13.3 adds more support by letting you store your packages in a first-class external package repository and yet activating different promotion levels within the tool. We now have three ways of activating a promotion level manually or automatically:

+ +
    +
  1. Stage n activating stage n+1
    2. +
  2. Pipeline X activating Pipeline Y (pipeline dependency)
    3. +
  3. Pipeline Y getting activated by the updation of a package in a package repository (package material dependency)
    4. +
+ +

There are situations when we could use either #2 or #3 above to model a promotion. The package material docs has a section on this.

+ +

Support for package material has been implemented as an extension point. Plugins written to this extension point can provide support for different types of repositories. A yum plugin is bundled along with GoCD Server 13.3. Other non-bundled package material plugins are listed here.

+ +

Happy packaging and promoting!

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/build-promotion-go/index.html b/pr-1714/2014/02/24/build-promotion-go/index.html new file mode 100644 index 000000000..5a7c01cf5 --- /dev/null +++ b/pr-1714/2014/02/24/build-promotion-go/index.html @@ -0,0 +1,262 @@ + + + + + + + + + + + + + + + + Build Promotion with GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Build promotion with GoCD

+

Sriram Narayan

+

+

+
+ +
+

A typical build may have to clear several hurdles before it can be considered fit for release. For example:

+ +
    +
  1. Unit tests
    2. +
  2. Static and dynamic metric thresholds (e.g. toxicity, coverage)
    3. +
  3. Packaging
    4. +
  4. Integration tests
    5. +
  5. UI tests
    6. +
  6. Performance tests
    7. +
  7. Regression tests
    8. +
  8. Deployment tests (install, uninstall, upgrade)
    9. +
  9. Manual exploratory tests
    10. +
  10. Regulatory, compliance checks
    11. +
  11. Clearance from UAT, staging
    12. +
+ +

Each of these hurdles may be viewed as a promotion level for the build (although, in practice, formal promotion levels are more coarse-grained). These promotion levels may be activated automatically (by the success of the previous level) or manually (by approved promoters). Note that these levels are very different from what is encountered in a source promotion model.

+ +

Avoid source or stream promotion models

+ +

In an earlier post, we said: "Deploy packages, not just a tag, branch or binary". With respect to promotions, we could say:

+ +

"Promote packages, not just a tag, branch/stream or binary"

+ +

Promoting at the level of source (rather than package) violates the build-once rule - one of the key principles outlined in the CD book:

+ +

"…the binaries you release should be the same binaries that have been through the rest of your deployment pipeline, so you can be sure that what you release is what you tested. Apart from the fact that nobody has tested the binaries that came from the release stream, there is also a chance that differences could be introduced in the build process, perhaps by the operations team using a different minor revision of the compiler or a different version of some dependency. Such differences can lead to bugs in production that take days to track down."

+ +

Because of this, a source/stream promotion model is fundamentally unfit for the world of continuous delivery:

+ +

"One of the objectives of the deployment pipeline is to allow frequent check-ins to mainline on large teams which may result in temporary instabilities, while still allowing you to get rock-solid releases out of the door. In this sense, the deployment pipeline is antithetical to the source promotion model. The main advantage of the deployment pipeline lies in the rapid feedback you get on the effect of every change on the fully integrated application—something that is impossible in the source promotion model."

+ +

Use your CI/CD server to manage promotions

+ +

Source based promotion models probably made more sense in a pre-CD era when the version control system was the only source of truth for the level of readiness of a codebase. Today, the CD tool is a more appropriate system of record for builds (and deployments) and their promotions. Again, the CD book backs this up:

+ +

"The other essential facility that must be provided by the tool you use to manage your deployment pipeline is the ability, for each stage, to see which builds have passed all the previous stages in the pipeline and are hence ready for the next stage. It should then be possible to choose one of these builds and press a button to have it deployed. This process is known as promotion.

+ +

Promoting builds at the press of a button is what turns the deployment pipeline into a pull system, giving everybody involved in the delivery process the ability to manage their own work"

+ +

Model your promotion process into the CD tool

+ +

In general, a build/deployment pipeline is also a promotion pipeline. GoCD's support for pipelines and stages with automatic or manual approvals makes it easy to model and visualize your promotion process into the CD value stream. A stage runs only when the previous stage has passed - this is like an automatic promotion gate. Manual stage approvals may also be used where needed.

+ +

Modeling promotion levels into the CD value stream

+ +

Modeling promotion levels (P1…P4) itno the CD value stream

+ +

GoCD 13.3

+ +

GoCD 13.3 adds more support by letting you store your packages in a first-class external package repository and yet activating different promotion levels within the tool. We now have three ways of activating a promotion level manually or automatically:

+ +
    +
  1. Stage n activating stage n+1
    2. +
  2. Pipeline X activating Pipeline Y (pipeline dependency)
    3. +
  3. Pipeline Y getting activated by the updation of a package in a package repository (package material dependency)
    4. +
+ +

There are situations when we could use either #2 or #3 above to model a promotion. The package material docs has a section on this.

+ +

Support for package material has been implemented as an extension point. Plugins written to this extension point can provide support for different types of repositories. A yum plugin is bundled along with GoCD Server 13.3. Other non-bundled package material plugins are listed here.

+ +

Happy packaging and promoting!

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary.html b/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary.html new file mode 100644 index 000000000..db19ea548 --- /dev/null +++ b/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary.html @@ -0,0 +1,224 @@ + + + + + + + + + + + + + + + + Deploy a package | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Deploy a package, not just a tag, branch or binary

+

Sriram Narayan

+

+

+
+ +
+

In a section called Principles and Practices of Build and Deployment Scripting, the CD book suggests to Use Your Operating System's Packaging Tools.

+ +

"Deploying a bunch of files that need to be distributed across the filesystem is very inefficient and makes maintenance—in the form of upgrades, rollbacks, and uninstalls—extremely painful. This is why packaging systems were invented."

+ +

We concur. This is a good example of cross-pollination of good ideas between development and operations. Software development teams are increasingly packaging their applications using application-specific (maven, gem, wheel, npm, cpan…) or system (rpm, deb, nuget, chocolatey…) packaging tools. Doing so has several advantages:

+ +
    +
  1. Built in versioning (e.g. rpm, deb, nuget).
    2. +
  2. Dependency management.
    3. +
  3. Distribution via standardized repository layouts, metadata and protocol.
    4. +
  4. Transactional install/upgrade/uninstall via package managers.
    5. +
  5. Managing configuration files: OS packages know how to manage files that are expected to change after installation so you don't lose your changes when you uninstall or override when you upgrade. e.g. rpm's %config macro.
    6. +
  6. File verification: Packages have built-in checksums, which can be used for verification before a package is extracted and installed.
    7. +
  7. Signature verification (e.g. rpm).
    8. +
  8. Idempotence - Issuing the same package install/upgrade/uninstall multiple times leaves the system in the same state as issuing it once.
    9. +
  9. Auditability: OS packaging tools allows you to track what package installed what file in your system (versus files appearing or being changed at will)
    10. +
  10. Traceability - what repository did a package come from? (e.g. deb)
    11. +
  11. Infrastructure automation tools like Chef, Puppet and Ansible have good support for popular package management systems. Traditionally used for provisioning servers, and environments, these tools are increasingly being used for application provisioning - more on this point in a follow-up post. +There you go - eleven good reasons to start creating packages for your components and applications and deploying from packages rather than from a tag, branch or binary.
    12. +
+ +

+ +

Thanks to Danilo Sato & Ram for their insights on this topic.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary/index.html b/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary/index.html new file mode 100644 index 000000000..511b538bd --- /dev/null +++ b/pr-1714/2014/02/24/deploy-package-not-just-tag-branch-or-binary/index.html @@ -0,0 +1,224 @@ + + + + + + + + + + + + + + + + Deploy a package | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Deploy a package, not just a tag, branch or binary

+

Sriram Narayan

+

+

+
+ +
+

In a section called Principles and Practices of Build and Deployment Scripting, the CD book suggests to Use Your Operating System's Packaging Tools.

+ +

"Deploying a bunch of files that need to be distributed across the filesystem is very inefficient and makes maintenance—in the form of upgrades, rollbacks, and uninstalls—extremely painful. This is why packaging systems were invented."

+ +

We concur. This is a good example of cross-pollination of good ideas between development and operations. Software development teams are increasingly packaging their applications using application-specific (maven, gem, wheel, npm, cpan…) or system (rpm, deb, nuget, chocolatey…) packaging tools. Doing so has several advantages:

+ +
    +
  1. Built in versioning (e.g. rpm, deb, nuget).
    2. +
  2. Dependency management.
    3. +
  3. Distribution via standardized repository layouts, metadata and protocol.
    4. +
  4. Transactional install/upgrade/uninstall via package managers.
    5. +
  5. Managing configuration files: OS packages know how to manage files that are expected to change after installation so you don't lose your changes when you uninstall or override when you upgrade. e.g. rpm's %config macro.
    6. +
  6. File verification: Packages have built-in checksums, which can be used for verification before a package is extracted and installed.
    7. +
  7. Signature verification (e.g. rpm).
    8. +
  8. Idempotence - Issuing the same package install/upgrade/uninstall multiple times leaves the system in the same state as issuing it once.
    9. +
  9. Auditability: OS packaging tools allows you to track what package installed what file in your system (versus files appearing or being changed at will)
    10. +
  10. Traceability - what repository did a package come from? (e.g. deb)
    11. +
  11. Infrastructure automation tools like Chef, Puppet and Ansible have good support for popular package management systems. Traditionally used for provisioning servers, and environments, these tools are increasingly being used for application provisioning - more on this point in a follow-up post. +There you go - eleven good reasons to start creating packages for your components and applications and deploying from packages rather than from a tag, branch or binary.
    12. +
+ +

+ +

Thanks to Danilo Sato & Ram for their insights on this topic.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/go-template-permissions.html b/pr-1714/2014/02/24/go-template-permissions.html new file mode 100644 index 000000000..308dc6c09 --- /dev/null +++ b/pr-1714/2014/02/24/go-template-permissions.html @@ -0,0 +1,214 @@ + + + + + + + + + + + + + + + + Template Permissions | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD - Template Permissions

+

GoCD Team

+

+

+
+ +
+

The GoCD System Administrator has access to all administrative functions, and has operational access to all parts of a GoCD installation, which differentiates the normal user from the admin user. Hence, this role cannot be assigned to every user in the system. This requirement demands a new set of roles in the system which is a subset of the privileges that the super admin has and at the same time does not give full fledged access to the system. Currently in GoCD, we have one such super admin role subset, which is called pipeline admin. In GoCD 13.4, we are introducing a new role into the ecosystem called "The Template Admin".

+ +

Let us consider a project which uses GoCD for CD and CI. The team has 10 team members and all are users of the GoCD system. Here all the pipelines are based on templates. Typically, only a 'GoCD System Administrator' has the privilege to edit the template. This means that every user needs to approach the super admin for all the changes that need to be made to the template, even if the change is trivial. With the introduction of this new role called template admin, the super admin can assign any user as template admin to a specific template.

+ +

Template administrators can view and edit the templates (to which they have permissions), from the template tab of the admin page. Template Administrators, will however not be able to add, delete or change permissions for a template. They will also be able to see the number of pipelines in which the template is being used, but not the details of those pipelines.To edit the permissions for a template, navigate to the "Templates" tab on the "Admin" section:

+ +

Pipeline Templates:

+ +

+ +

Then, click the "Permissions" link for the template, you want to manage permissions for:

+ +

+ +

More information on this is available in the help documentation.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/go-template-permissions/index.html b/pr-1714/2014/02/24/go-template-permissions/index.html new file mode 100644 index 000000000..1263c1aa4 --- /dev/null +++ b/pr-1714/2014/02/24/go-template-permissions/index.html @@ -0,0 +1,214 @@ + + + + + + + + + + + + + + + + Template Permissions | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD - Template Permissions

+

GoCD Team

+

+

+
+ +
+

The GoCD System Administrator has access to all administrative functions, and has operational access to all parts of a GoCD installation, which differentiates the normal user from the admin user. Hence, this role cannot be assigned to every user in the system. This requirement demands a new set of roles in the system which is a subset of the privileges that the super admin has and at the same time does not give full fledged access to the system. Currently in GoCD, we have one such super admin role subset, which is called pipeline admin. In GoCD 13.4, we are introducing a new role into the ecosystem called "The Template Admin".

+ +

Let us consider a project which uses GoCD for CD and CI. The team has 10 team members and all are users of the GoCD system. Here all the pipelines are based on templates. Typically, only a 'GoCD System Administrator' has the privilege to edit the template. This means that every user needs to approach the super admin for all the changes that need to be made to the template, even if the change is trivial. With the introduction of this new role called template admin, the super admin can assign any user as template admin to a specific template.

+ +

Template administrators can view and edit the templates (to which they have permissions), from the template tab of the admin page. Template Administrators, will however not be able to add, delete or change permissions for a template. They will also be able to see the number of pipelines in which the template is being used, but not the details of those pipelines.To edit the permissions for a template, navigate to the "Templates" tab on the "Admin" section:

+ +

Pipeline Templates:

+ +

+ +

Then, click the "Permissions" link for the template, you want to manage permissions for:

+ +

+ +

More information on this is available in the help documentation.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware.html b/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware.html new file mode 100644 index 000000000..e4b854439 --- /dev/null +++ b/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + CD with Enterprise Java Middleware | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

How to implement Continuous Delivery with enterprise java middleware?

+

Sriram Narayan

+

+

+
+ +
+

The goal of Continuous Delivery is to move your production release frequency from months to weeks or even days. This all sounds great, but is Continuous Delivery achievable in a complex enterprise IT environment running Java EE middleware such as WebLogic, WebSphere or JBoss?

+ +

In this deck, Andrew Phillips, VP Products, XebiaLabs and I examine the challenges of Continuous Delivery in a complex environment, the key drivers and benefits for moving to Continuous Delivery and simple ways to get started. We also demonstrate a Java EE delivery pipeline using Thoughtworks' GoCD and XebiaLabs' Deployit that helps you get started and addresses the challenges commonly encountered in enterprise environments.

+ + + +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/index.html b/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/index.html new file mode 100644 index 000000000..86a6d6175 --- /dev/null +++ b/pr-1714/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + CD with Enterprise Java Middleware | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

How to implement Continuous Delivery with enterprise java middleware?

+

Sriram Narayan

+

+

+
+ +
+

The goal of Continuous Delivery is to move your production release frequency from months to weeks or even days. This all sounds great, but is Continuous Delivery achievable in a complex enterprise IT environment running Java EE middleware such as WebLogic, WebSphere or JBoss?

+ +

In this deck, Andrew Phillips, VP Products, XebiaLabs and I examine the challenges of Continuous Delivery in a complex environment, the key drivers and benefits for moving to Continuous Delivery and simple ways to get started. We also demonstrate a Java EE delivery pipeline using Thoughtworks' GoCD and XebiaLabs' Deployit that helps you get started and addresses the challenges commonly encountered in enterprise environments.

+ + + +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version.html b/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version.html new file mode 100644 index 000000000..26566f36a --- /dev/null +++ b/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version.html @@ -0,0 +1,226 @@ + + + + + + + + + + + + + + + + Peg your Pipeline to a Dependency Version | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

How to peg your pipeline to a dependency version

+

Sriram Narayan

+

+

+
+ +
+

Say we have a set up like the one below. We have two pipelines – one for component-1 (C1) and another for component-2 (C2). C1 just builds off its source code in version control (VCS-1). C2 has its source in a different repository (VCS-2) and is also dependent (d3) on C1. In GoCD terminology, C1 has one upstream dependency d1 while C2 has two upstream dependencies d2 and d3.

+ +

Pipelines with upstream dependencies

+ +

Fluid dependencies

+ +

Now by default in GoCD, a pipeline gets scheduled when there is a change to any of its upstream dependencies. This behavior is referred to as a fluid dependency in the Continuous delivery book (the book refers to a paper by Alex Chaffee).

+ +
+

Chaffee's proposal is to introduce a new piece of state into the dependency graph—whether a particular upstream dependency is static, guarded, or fluid. Changes in a static upstream dependency do not trigger a new build.Changes in a fluid upstream dependency always trigger a new build.

+
+ +

Simulating static dependencies

+ +

What if we want to keep d1 and d2 fluid but make d3 static? This is a reasonable requirement if you want to peg C2 to a known good version of C1 and still let C1 keep building against its frequently changing source. This may be the case if C1 is volatile or under control of a different team or organization.

+ +

On the face of it, it may appear that GoCD cannot support pegging. But that is not the case; GoCD's pipelines are powerful and flexible building blocks. We could just introduce a "manual-gate" pipeline to achieve pegging.

+ +

Introducing a manual gate to a pipeline

+ +

"manual-gate" is a simple pipeline with one stage having a single no-op job, one upstream dependency C1, and auto-scheduling turned off (this makes d3 static rather than fluid). The manual gate doesn't trigger for every successful run of C1, it can only be manually triggered. C2 has a regular fluid dependency (d4) with manual-gate. The overall setup pegs C2 to a chosen good version of C1 while C1 is free to keep building new versions.

+ +

Rolling back

+ +

Say C2 is pegged to version 100 of C1. A week passes and C1 has progressed to 110. To get in sync with latest again, we simply trigger the manual-gate. The manual-gate itself is a no-op so it turns green and triggers C2. C2 does a fetch-ancestor-artifact to get C1 binary version 110 and proceeds to build. If the build turns green, it means we have successfully pegged C2 to version 110 of C1. What if the build fails?

+ +

We have two options. We could revert to last known good version by retriggering manual gate with version 100 of C1. Or we could keep bisecting the range between 100 and 110 to find the most recent version of C1 that works for C2.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version/index.html b/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version/index.html new file mode 100644 index 000000000..b3d8e8b21 --- /dev/null +++ b/pr-1714/2014/02/24/how-peg-your-pipeline-dependency-version/index.html @@ -0,0 +1,226 @@ + + + + + + + + + + + + + + + + Peg your Pipeline to a Dependency Version | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

How to peg your pipeline to a dependency version

+

Sriram Narayan

+

+

+
+ +
+

Say we have a set up like the one below. We have two pipelines – one for component-1 (C1) and another for component-2 (C2). C1 just builds off its source code in version control (VCS-1). C2 has its source in a different repository (VCS-2) and is also dependent (d3) on C1. In GoCD terminology, C1 has one upstream dependency d1 while C2 has two upstream dependencies d2 and d3.

+ +

Pipelines with upstream dependencies

+ +

Fluid dependencies

+ +

Now by default in GoCD, a pipeline gets scheduled when there is a change to any of its upstream dependencies. This behavior is referred to as a fluid dependency in the Continuous delivery book (the book refers to a paper by Alex Chaffee).

+ +
+

Chaffee's proposal is to introduce a new piece of state into the dependency graph—whether a particular upstream dependency is static, guarded, or fluid. Changes in a static upstream dependency do not trigger a new build.Changes in a fluid upstream dependency always trigger a new build.

+
+ +

Simulating static dependencies

+ +

What if we want to keep d1 and d2 fluid but make d3 static? This is a reasonable requirement if you want to peg C2 to a known good version of C1 and still let C1 keep building against its frequently changing source. This may be the case if C1 is volatile or under control of a different team or organization.

+ +

On the face of it, it may appear that GoCD cannot support pegging. But that is not the case; GoCD's pipelines are powerful and flexible building blocks. We could just introduce a "manual-gate" pipeline to achieve pegging.

+ +

Introducing a manual gate to a pipeline

+ +

"manual-gate" is a simple pipeline with one stage having a single no-op job, one upstream dependency C1, and auto-scheduling turned off (this makes d3 static rather than fluid). The manual gate doesn't trigger for every successful run of C1, it can only be manually triggered. C2 has a regular fluid dependency (d4) with manual-gate. The overall setup pegs C2 to a chosen good version of C1 while C1 is free to keep building new versions.

+ +

Rolling back

+ +

Say C2 is pegged to version 100 of C1. A week passes and C1 has progressed to 110. To get in sync with latest again, we simply trigger the manual-gate. The manual-gate itself is a no-op so it turns green and triggers C2. C2 does a fetch-ancestor-artifact to get C1 binary version 110 and proceeds to build. If the build turns green, it means we have successfully pegged C2 to version 110 of C1. What if the build fails?

+ +

We have two options. We could revert to last known good version by retriggering manual gate with version 100 of C1. Or we could keep bisecting the range between 100 and 110 to find the most recent version of C1 that works for C2.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/index.html b/pr-1714/2014/02/24/index.html new file mode 100644 index 000000000..c852ce44c --- /dev/null +++ b/pr-1714/2014/02/24/index.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/model-everything-fail-fast.html b/pr-1714/2014/02/24/model-everything-fail-fast.html new file mode 100644 index 000000000..53df21b4c --- /dev/null +++ b/pr-1714/2014/02/24/model-everything-fail-fast.html @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + Model everything to fail fast | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Model everything to fail fast

+

Mark Chang

+

+

+
+ +
+ +

Every time any change is introduced - application, database script, automated test, infrastructure, deployment script, configuration, etc. - the change should kick off a gauntlet of validation. The quicker you can find out if a change breaks something the better off you are and the more confidence you will have in your software. We tell the teams who want to go faster that they need to fail fast. We built GoCD to give teams the power to model and remodel a Build-Test- Release workflow so that they get super quick feedback on every change. And if something breaks, great, find it fast, fix it fast, and then run the new version through the gauntlet.

+ +

A common workflow to fail fast

+ +

Here's a generic but common Build-Test-Release workflow. Each code commit will trigger a new release candidate and run through the gauntlet, left to right. Every workflow step is tasked to find an issue with the version of the software it is building, testing or deploying.

+ +

Generic Build-Test-Release workflow

+ +

To shorten the feedback loop:

+ +
    +
  • The activities within each workflow step can run in parallel.
    • +
  • The workflow steps are sequenced to run the most important things first.
    • +
  • Four build pipelines can run in parallel.
    • +
  • Four acceptance test pipelines can run in parallel.
    • +
  • Six different test environments can run in parallel.
    • +
+ +

Know what's going on in a workflow

+ +

It's important a team has a holistic context for every release candidate. Every tool talks about "visibility" and "traceability". A tool that can easily answer these questions provides visibility and traceability:

+ +
    +
  • Which dependency or commit broke the build?
    • +
  • Who broke the build?
    • +
  • What's the difference between these 2 builds?
    • +
  • Which features and bug fixes are in this release candidate?
    • +
  • Which version of our software is running in this environment?
    • +
  • Who deployed in this environment and when?
    • +
+ +

How will modeling a workflow help a team fail fast?

+ +

Let's say a release candidate needs to pass 11 steps (gauntlet) before it can make it to an enduser. Sequence is important. The goal is to fail fast. A flat workflow will return feedback but it's slow since only one step will run at a time.

+ +

A flat workflow running one step at a time

+ +

If it turns out that a few steps can be run in parallel, you will speed up your workflow.

+ +

A workflow running few steps in parallel

+ +

Speed things up even further by increasing the amount of parallelization.

+ +

A workflow with increased paralellization

+ +

Over time you may find other areas in your Build-Test-Release workflow where you can speed up your feedback loop. This workflow will find an issue much faster than the flat one we started with.

+ +

Increasing paralellization in multiple areas

+ +

Sequencing and parallelization in GoCD

+ +

A GoCD pipeline is a building block (*). Teams using GoCD will come together and model an end-to-end Build-Test-Release workflow by chaining pipelines together. Part of this collaboration is figuring out the sequence of workflow steps and where parallelization makes sense.

+ +

Sequencing workflow steps will define priority:

+ +
    +
  • Execute the most important activities first: +
      +
    • Automated acceptance tests before performance tests.
      • +
    +
    • +
  • Execute the shortest activities first: +
      +
    • Unit tests before smoke tests.
      • +
    • Smoke tests before automated acceptance tests
      • +
    +
    • +
+ +

Parallelization will speed things up:

+ +
    +
  • Parallelize activities within a workflow step: +
      +
    • Speed up an acceptance test suite.
      • +
    +
    • +
  • Parallelize different workflow steps: +
      +
    • Run acceptance tests, performance tests and exploratory testing at the same time.
      • +
    +
    • +
+ +

We treat a workflow as a single entity

+ +

It's extremely important to us that the core behavior of a single pipeline is maintained in a workflow (chain of pipelines), no matter the model. GoCD allows teams to model as they wish and handles stuff like artifact management and if a release candidate should advance to the next step. A lot of the intelligence comes down to how GoCD manages dependencies. We're proud of this intelligence, especially the "fan-in" support. This is where GoCD really shines.

+ +
+

(*) Jez Humble and David Farley talk about a "deployment pipeline" in their book, Continuous Delivery. A core domain concept in GoCD is called a "pipeline". They are not the same thing.

+ +
    +
  • +

    The book talks about the "deployment pipeline" in a holistic sense, a pattern that can be implemented to model your path to production. They summarize a deployment pipeline as "in essence, an automated implementation of your application's build, deploy, test, and release process".

    +
    • +
  • +

    GoCD is a Continuous Delivery tool that allows teams to implement that pattern via GoCD pipelines. A GoCD pipeline is a building block. GoCD pipelines are a way to implement a deployment pipeline. The product overloads the term. On behalf of Jez, sorry!

    +
    • +
+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/model-everything-fail-fast/index.html b/pr-1714/2014/02/24/model-everything-fail-fast/index.html new file mode 100644 index 000000000..e448afe9d --- /dev/null +++ b/pr-1714/2014/02/24/model-everything-fail-fast/index.html @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + Model everything to fail fast | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Model everything to fail fast

+

Mark Chang

+

+

+
+ +
+ +

Every time any change is introduced - application, database script, automated test, infrastructure, deployment script, configuration, etc. - the change should kick off a gauntlet of validation. The quicker you can find out if a change breaks something the better off you are and the more confidence you will have in your software. We tell the teams who want to go faster that they need to fail fast. We built GoCD to give teams the power to model and remodel a Build-Test- Release workflow so that they get super quick feedback on every change. And if something breaks, great, find it fast, fix it fast, and then run the new version through the gauntlet.

+ +

A common workflow to fail fast

+ +

Here's a generic but common Build-Test-Release workflow. Each code commit will trigger a new release candidate and run through the gauntlet, left to right. Every workflow step is tasked to find an issue with the version of the software it is building, testing or deploying.

+ +

Generic Build-Test-Release workflow

+ +

To shorten the feedback loop:

+ +
    +
  • The activities within each workflow step can run in parallel.
    • +
  • The workflow steps are sequenced to run the most important things first.
    • +
  • Four build pipelines can run in parallel.
    • +
  • Four acceptance test pipelines can run in parallel.
    • +
  • Six different test environments can run in parallel.
    • +
+ +

Know what's going on in a workflow

+ +

It's important a team has a holistic context for every release candidate. Every tool talks about "visibility" and "traceability". A tool that can easily answer these questions provides visibility and traceability:

+ +
    +
  • Which dependency or commit broke the build?
    • +
  • Who broke the build?
    • +
  • What's the difference between these 2 builds?
    • +
  • Which features and bug fixes are in this release candidate?
    • +
  • Which version of our software is running in this environment?
    • +
  • Who deployed in this environment and when?
    • +
+ +

How will modeling a workflow help a team fail fast?

+ +

Let's say a release candidate needs to pass 11 steps (gauntlet) before it can make it to an enduser. Sequence is important. The goal is to fail fast. A flat workflow will return feedback but it's slow since only one step will run at a time.

+ +

A flat workflow running one step at a time

+ +

If it turns out that a few steps can be run in parallel, you will speed up your workflow.

+ +

A workflow running few steps in parallel

+ +

Speed things up even further by increasing the amount of parallelization.

+ +

A workflow with increased paralellization

+ +

Over time you may find other areas in your Build-Test-Release workflow where you can speed up your feedback loop. This workflow will find an issue much faster than the flat one we started with.

+ +

Increasing paralellization in multiple areas

+ +

Sequencing and parallelization in GoCD

+ +

A GoCD pipeline is a building block (*). Teams using GoCD will come together and model an end-to-end Build-Test-Release workflow by chaining pipelines together. Part of this collaboration is figuring out the sequence of workflow steps and where parallelization makes sense.

+ +

Sequencing workflow steps will define priority:

+ +
    +
  • Execute the most important activities first: +
      +
    • Automated acceptance tests before performance tests.
      • +
    +
    • +
  • Execute the shortest activities first: +
      +
    • Unit tests before smoke tests.
      • +
    • Smoke tests before automated acceptance tests
      • +
    +
    • +
+ +

Parallelization will speed things up:

+ +
    +
  • Parallelize activities within a workflow step: +
      +
    • Speed up an acceptance test suite.
      • +
    +
    • +
  • Parallelize different workflow steps: +
      +
    • Run acceptance tests, performance tests and exploratory testing at the same time.
      • +
    +
    • +
+ +

We treat a workflow as a single entity

+ +

It's extremely important to us that the core behavior of a single pipeline is maintained in a workflow (chain of pipelines), no matter the model. GoCD allows teams to model as they wish and handles stuff like artifact management and if a release candidate should advance to the next step. A lot of the intelligence comes down to how GoCD manages dependencies. We're proud of this intelligence, especially the "fan-in" support. This is where GoCD really shines.

+ +
+

(*) Jez Humble and David Farley talk about a "deployment pipeline" in their book, Continuous Delivery. A core domain concept in GoCD is called a "pipeline". They are not the same thing.

+ +
    +
  • +

    The book talks about the "deployment pipeline" in a holistic sense, a pattern that can be implemented to model your path to production. They summarize a deployment pipeline as "in essence, an automated implementation of your application's build, deploy, test, and release process".

    +
    • +
  • +

    GoCD is a Continuous Delivery tool that allows teams to implement that pattern via GoCD pipelines. A GoCD pipeline is a building block. GoCD pipelines are a way to implement a deployment pipeline. The product overloads the term. On behalf of Jez, sorry!

    +
    • +
+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/tracing-our-path-production.html b/pr-1714/2014/02/24/tracing-our-path-production.html new file mode 100644 index 000000000..887b0d65d --- /dev/null +++ b/pr-1714/2014/02/24/tracing-our-path-production.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + Tracing our path to production | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Tracing our path to production

+

Scott Turnquest

+

+

+
+ +
+ +

Ever since the Mingle team started working on its new cloud offering we made a conscious effort to improve our ability to continuously deliver valuable features and enhancements to our production environment. I expected that frequent deployments, tons of automation and lots of learning about Amazon's AWS would come with the territory - and it did. What I didn't expect was that I'd end up asking and answering so many questions dealing with when feature X or bug fix Y would be ready for testing and when it would be ready to be promoted to production.

+ +

With a traditional release structure all features and bug fixes are released at once, so it is an easy task to determine which features and bug fixes would be released. When we moved to a schedule that pushed new features and bug fixes into our cloud environment as soon as they were ready, we found ourselves with a new crop of questions on our hands.

+ +

Tracing features and bugs through a non-trivial build setup was not as easy as it should be

+ +
+

What features and bugs will be in tonight's deployment to production?

+
+ +
+

When can we start to dogfood this new feature in our staging environment?

+
+ +
+

That bug fix we put in, where is that in our pipelines?

+
+ +
+

Are we going to start testing it today?

+
+ +

I find myself answering or asking some variant of the questions above multiple times a day. Either because I'm eager to start testing a new fix, or because I want to help set our product managers expectations properly, or because we want to know when a customer will be happy because we've responded to their feedback, or… you get the idea.

+ +

We have multiple pipelines in our path to production. For legacy reasons we have pipelines that run tests using different browsers, databases and operating systems. We also run upgrade tests and performance tests at different frequencies based on need. Since we have a number of pipelines chained together it isn't always easy to know where a given change is in our deployment process. Consequently, it is difficult to answer questions about what features are in a given build or when a bug fix will be available for testing.

+ +

GoCD's value stream mapping feature

+ +

To answer each of the above questions, we now refer a lot to the new value stream mapping feature in GoCD. From any build we can now zoom in to find upstream and downstream pipelines and basically trace a single revision all the way through to production. Below is an example of the overview for a recent build that we are waiting to see promoted to our staging environment (called pasty).

+ +

Example of pipelines in our staging environment

+ +

The map above shows the key pipelines involved in the flow from our tests using Firefox and Oracle 11g all the way through to testing our hosting environment. Once the ‘mingle-saas' pipeline is green I know that the targeted bug fix will be ready for deployment to our dogfooding environment (called ‘pasty').

+ +

Seeing the big picture improves understanding

+

To answer our key questions easily we needed a big picture view of our pipelines. We needed to know more about our pipeline dependencies and where are artifacts are flowing. These days I find myself using the value stream map multiple times a day and I use it in conjunction with our card wall to drive conversations with our product manager around which new features and bug fixes will be included in the next deployment and when that deployment is likely to be done.

+ +

One added benefit we've gained from the value stream map is that I now have a much better understanding of the different pieces of our deployment process. This has definitely helped in conversations with the developers:

+ +
+

Developer: "We just have to wait for the GreenInstallers build to pass…"

+ +

Me: "GreenInstallers… ah yes I know exactly where that fits in the overall process so I have a good idea about when that build will be ready. Thanks."

+
+ +

I think it's safe to say that the new value stream map is my new favorite feature in GoCD.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/24/tracing-our-path-production/index.html b/pr-1714/2014/02/24/tracing-our-path-production/index.html new file mode 100644 index 000000000..d9c7f7068 --- /dev/null +++ b/pr-1714/2014/02/24/tracing-our-path-production/index.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + Tracing our path to production | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Tracing our path to production

+

Scott Turnquest

+

+

+
+ +
+ +

Ever since the Mingle team started working on its new cloud offering we made a conscious effort to improve our ability to continuously deliver valuable features and enhancements to our production environment. I expected that frequent deployments, tons of automation and lots of learning about Amazon's AWS would come with the territory - and it did. What I didn't expect was that I'd end up asking and answering so many questions dealing with when feature X or bug fix Y would be ready for testing and when it would be ready to be promoted to production.

+ +

With a traditional release structure all features and bug fixes are released at once, so it is an easy task to determine which features and bug fixes would be released. When we moved to a schedule that pushed new features and bug fixes into our cloud environment as soon as they were ready, we found ourselves with a new crop of questions on our hands.

+ +

Tracing features and bugs through a non-trivial build setup was not as easy as it should be

+ +
+

What features and bugs will be in tonight's deployment to production?

+
+ +
+

When can we start to dogfood this new feature in our staging environment?

+
+ +
+

That bug fix we put in, where is that in our pipelines?

+
+ +
+

Are we going to start testing it today?

+
+ +

I find myself answering or asking some variant of the questions above multiple times a day. Either because I'm eager to start testing a new fix, or because I want to help set our product managers expectations properly, or because we want to know when a customer will be happy because we've responded to their feedback, or… you get the idea.

+ +

We have multiple pipelines in our path to production. For legacy reasons we have pipelines that run tests using different browsers, databases and operating systems. We also run upgrade tests and performance tests at different frequencies based on need. Since we have a number of pipelines chained together it isn't always easy to know where a given change is in our deployment process. Consequently, it is difficult to answer questions about what features are in a given build or when a bug fix will be available for testing.

+ +

GoCD's value stream mapping feature

+ +

To answer each of the above questions, we now refer a lot to the new value stream mapping feature in GoCD. From any build we can now zoom in to find upstream and downstream pipelines and basically trace a single revision all the way through to production. Below is an example of the overview for a recent build that we are waiting to see promoted to our staging environment (called pasty).

+ +

Example of pipelines in our staging environment

+ +

The map above shows the key pipelines involved in the flow from our tests using Firefox and Oracle 11g all the way through to testing our hosting environment. Once the ‘mingle-saas' pipeline is green I know that the targeted bug fix will be ready for deployment to our dogfooding environment (called ‘pasty').

+ +

Seeing the big picture improves understanding

+

To answer our key questions easily we needed a big picture view of our pipelines. We needed to know more about our pipeline dependencies and where are artifacts are flowing. These days I find myself using the value stream map multiple times a day and I use it in conjunction with our card wall to drive conversations with our product manager around which new features and bug fixes will be included in the next deployment and when that deployment is likely to be done.

+ +

One added benefit we've gained from the value stream map is that I now have a much better understanding of the different pieces of our deployment process. This has definitely helped in conversations with the developers:

+ +
+

Developer: "We just have to wait for the GreenInstallers build to pass…"

+ +

Me: "GreenInstallers… ah yes I know exactly where that fits in the overall process so I have a good idea about when that build will be ready. Thanks."

+
+ +

I think it's safe to say that the new value stream map is my new favorite feature in GoCD.

+ +
This post is also cross-posted here.
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25.html b/pr-1714/2014/02/25.html new file mode 100644 index 000000000..c6b521bc2 --- /dev/null +++ b/pr-1714/2014/02/25.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 25 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25/go-is-now-open-source.html b/pr-1714/2014/02/25/go-is-now-open-source.html new file mode 100644 index 000000000..16ddeb2e6 --- /dev/null +++ b/pr-1714/2014/02/25/go-is-now-open-source.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the go-moving-to-open-source/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2014/02/25/go-is-now-open-source/index.html b/pr-1714/2014/02/25/go-is-now-open-source/index.html new file mode 100644 index 000000000..6fbd6f714 --- /dev/null +++ b/pr-1714/2014/02/25/go-is-now-open-source/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../go-moving-to-open-source/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2014/02/25/go-moving-to-open-source.html b/pr-1714/2014/02/25/go-moving-to-open-source.html new file mode 100644 index 000000000..ef3e4d94a --- /dev/null +++ b/pr-1714/2014/02/25/go-moving-to-open-source.html @@ -0,0 +1,247 @@ + + + + + + + + + + + + + + + + GoCD is Open Source | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD is converting to open source!

+

Ken Mugrage

+

+

+
+ +
+

On 25 Feb 2014 Thoughtworks announced that GoCD will soon be available under the Apache 2.0 open source license. We're really excited for the next chapter! We're working hard to get the source code updated with license information, public GoCD servers for building and testing and other things in place. It should be available in the next couple months.

+ +

You can download GoCD and use it for free right now.

+ +

We've had quite a few questions about the change. Here are a few of them…

+ +

Why the change?

+ +
    +
  • +

    It's the right thing to do for today's market

    + +
      +
    • +

      Organizations expect it. We've observed a shift where organizations' insist that the components that make up their production platform be almost exclusively open source software. While GoCD doesn't "run" in production, it does manage what is and isn't in production, and it's therefore "platform" infrastructure. (Many things drive this like the ability to contribute, ability to see the source and know how stuff works, significantly lower likelihood of security holes, etc.)

      +
      • +
    • +

      Practitioners expect it. In selling commercial GoCD we often have prospects tell us that they prefer open source software. The objection is rarely about price, rather the feeling that it's the right thing to do and the ability to make the changes that are important for their usage. Many existing customers have asked to be able to make their own modifications.

      +
      • +
    • +

      Grow the practice of continuous delivery. Several years ago, before Thoughtworks had a product division, we created something called CruiseControl for continuous integration (CI). We believe that product had a lot to do with the adoption of CI practices, and we want to enable the same kind of change for continuous delivery (CD).

      +
      • +
    +
    • +
+ +

Is Thoughtworks still working on GoCD?

+ +
    +
  • Yes! The current GoCD development team at Thoughtworks is definitely still working to enhance the product as well as help others who may wish to participate in the new open source program.
    • +
  • Thoughtworks still provides professional help There is still a 20+ year old global company that has solidly invested in GoCD providing support to organizations who desire a commercial channel. You can learn more about their offerings on Thoughtworks' website.
    • +
+ +

How will the project be run?

+ +
    +
  • +

    As a "proper" open source project. Anyone who wishes to participate in the future of GoCD is encouraged to do so. We're currently working hard on making the source code available for GoCD, and will update this site as soon as it is. You can also sign up to stay informed.

    + +
      +
    • +

      Push Access If a person makes quality contributions on a regular basis they may be nominated by the current committers to be granted push access to the GitHub repositories. When someone is nominated, the current committers will vote. The process will be the same for everyone.

      +
      • +
    • +

      Types of participation All participation is encouraged. This could mean helping out on the mailing lists, making documentation updates, fixing bugs or any of the other things involved in creating a solid software product.

      +
      • +
    +
    • +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25/go-moving-to-open-source/index.html b/pr-1714/2014/02/25/go-moving-to-open-source/index.html new file mode 100644 index 000000000..eb9bc9962 --- /dev/null +++ b/pr-1714/2014/02/25/go-moving-to-open-source/index.html @@ -0,0 +1,247 @@ + + + + + + + + + + + + + + + + GoCD is Open Source | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD is converting to open source!

+

Ken Mugrage

+

+

+
+ +
+

On 25 Feb 2014 Thoughtworks announced that GoCD will soon be available under the Apache 2.0 open source license. We're really excited for the next chapter! We're working hard to get the source code updated with license information, public GoCD servers for building and testing and other things in place. It should be available in the next couple months.

+ +

You can download GoCD and use it for free right now.

+ +

We've had quite a few questions about the change. Here are a few of them…

+ +

Why the change?

+ +
    +
  • +

    It's the right thing to do for today's market

    + +
      +
    • +

      Organizations expect it. We've observed a shift where organizations' insist that the components that make up their production platform be almost exclusively open source software. While GoCD doesn't "run" in production, it does manage what is and isn't in production, and it's therefore "platform" infrastructure. (Many things drive this like the ability to contribute, ability to see the source and know how stuff works, significantly lower likelihood of security holes, etc.)

      +
      • +
    • +

      Practitioners expect it. In selling commercial GoCD we often have prospects tell us that they prefer open source software. The objection is rarely about price, rather the feeling that it's the right thing to do and the ability to make the changes that are important for their usage. Many existing customers have asked to be able to make their own modifications.

      +
      • +
    • +

      Grow the practice of continuous delivery. Several years ago, before Thoughtworks had a product division, we created something called CruiseControl for continuous integration (CI). We believe that product had a lot to do with the adoption of CI practices, and we want to enable the same kind of change for continuous delivery (CD).

      +
      • +
    +
    • +
+ +

Is Thoughtworks still working on GoCD?

+ +
    +
  • Yes! The current GoCD development team at Thoughtworks is definitely still working to enhance the product as well as help others who may wish to participate in the new open source program.
    • +
  • Thoughtworks still provides professional help There is still a 20+ year old global company that has solidly invested in GoCD providing support to organizations who desire a commercial channel. You can learn more about their offerings on Thoughtworks' website.
    • +
+ +

How will the project be run?

+ +
    +
  • +

    As a "proper" open source project. Anyone who wishes to participate in the future of GoCD is encouraged to do so. We're currently working hard on making the source code available for GoCD, and will update this site as soon as it is. You can also sign up to stay informed.

    + +
      +
    • +

      Push Access If a person makes quality contributions on a regular basis they may be nominated by the current committers to be granted push access to the GitHub repositories. When someone is nominated, the current committers will vote. The process will be the same for everyone.

      +
      • +
    • +

      Types of participation All participation is encouraged. This could mean helping out on the mailing lists, making documentation updates, fixing bugs or any of the other things involved in creating a solid software product.

      +
      • +
    +
    • +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25/index.html b/pr-1714/2014/02/25/index.html new file mode 100644 index 000000000..43fd1a7df --- /dev/null +++ b/pr-1714/2014/02/25/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 25 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25/why-we-need-to-practice-cd.html b/pr-1714/2014/02/25/why-we-need-to-practice-cd.html new file mode 100644 index 000000000..918423c95 --- /dev/null +++ b/pr-1714/2014/02/25/why-we-need-to-practice-cd.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Why practice CD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Why we need to practice CD

+

Ken Mugrage

+

+

+
+ +
+

For many (perhaps most) people visiting this site, this may be obvious. If you're new to continuous delivery and want +to know what all the hubbub is about, this post is for you.

+ +

At my last job we did a pretty decent job at continuous integration. When a developer would make a change to the codebase, +a build would run automatically and we would know if it had passed all of the unit tests. The problem was simple; the organization was chock +full of functional silos. The automation didn't get beyond the development team.

+ +

The process (which may look familiar to you) was something like this…

+ +
    +
  1. Development team worked on code using their own automation until something was "ready" for QA.
    2. +
  2. The Development team would upload a file onto a file share where the QA team could download it.
    3. +
  3. The QA team would download the file to install on their systems, and sometimes they would even get the right file.
    4. +
  4. The file would fail to install about half the time.
    5. +
  5. Someone from the development team would go over to QA, make some changes on their box and the file would install.
    6. +
  6. The QA team would finish, put the file on a different fileshare and then IT Operations would download it.
    7. +
  7. IT Operations wouldn't know about the local change made in QA, so their deployment would fail.
    8. +
  8. IT Operations would say lots of unkind things about Dev, Dev would call IT Ops all sorts of bad names.
    9. +
+ +

repeat.

+ +

Enter the DevOps movement and continuous delivery.

+ +

Now everything should be automated, all the way from first code commit to production deployment.

+ +

Application Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

Infrastructure Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

Database Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

(you may notice a pattern here)

+ +

This is all completely oversimplified of course, but the core idea here is that everything is tested in every environment all the time. If we need to launch a new feature +we can get it into our customers hands when it's the right time for the business, not when the deployment was finally +figured out.

+ +

Releases become a non-event, maybe even boring, and that's a good thing.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/25/why-we-need-to-practice-cd/index.html b/pr-1714/2014/02/25/why-we-need-to-practice-cd/index.html new file mode 100644 index 000000000..121bfdf96 --- /dev/null +++ b/pr-1714/2014/02/25/why-we-need-to-practice-cd/index.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Why practice CD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Why we need to practice CD

+

Ken Mugrage

+

+

+
+ +
+

For many (perhaps most) people visiting this site, this may be obvious. If you're new to continuous delivery and want +to know what all the hubbub is about, this post is for you.

+ +

At my last job we did a pretty decent job at continuous integration. When a developer would make a change to the codebase, +a build would run automatically and we would know if it had passed all of the unit tests. The problem was simple; the organization was chock +full of functional silos. The automation didn't get beyond the development team.

+ +

The process (which may look familiar to you) was something like this…

+ +
    +
  1. Development team worked on code using their own automation until something was "ready" for QA.
    2. +
  2. The Development team would upload a file onto a file share where the QA team could download it.
    3. +
  3. The QA team would download the file to install on their systems, and sometimes they would even get the right file.
    4. +
  4. The file would fail to install about half the time.
    5. +
  5. Someone from the development team would go over to QA, make some changes on their box and the file would install.
    6. +
  6. The QA team would finish, put the file on a different fileshare and then IT Operations would download it.
    7. +
  7. IT Operations wouldn't know about the local change made in QA, so their deployment would fail.
    8. +
  8. IT Operations would say lots of unkind things about Dev, Dev would call IT Ops all sorts of bad names.
    9. +
+ +

repeat.

+ +

Enter the DevOps movement and continuous delivery.

+ +

Now everything should be automated, all the way from first code commit to production deployment.

+ +

Application Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

Infrastructure Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

Database Changes…

+ +
    +
  1. Someone commits code and causes CD system to automatically build and test the change.
    2. +
  2. If those tests pass, the CD system automatically promotes the code and runs the automated functional tests.
    3. +
  3. The QA department can look at any "green" build and deploy it to their environment automatically.
    4. +
  4. The IT Operations department can look at any "green" QA tested build and deploy it to their environment automatically.
    5. +
+ +

(you may notice a pattern here)

+ +

This is all completely oversimplified of course, but the core idea here is that everything is tested in every environment all the time. If we need to launch a new feature +we can get it into our customers hands when it's the right time for the business, not when the deployment was finally +figured out.

+ +

Releases become a non-event, maybe even boring, and that's a good thing.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/02/index.html b/pr-1714/2014/02/index.html new file mode 100644 index 000000000..52a69b6cc --- /dev/null +++ b/pr-1714/2014/02/index.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03.html b/pr-1714/2014/03.html new file mode 100644 index 000000000..b9d2eb107 --- /dev/null +++ b/pr-1714/2014/03.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/06.html b/pr-1714/2014/03/06.html new file mode 100644 index 000000000..c1742ed95 --- /dev/null +++ b/pr-1714/2014/03/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 6 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/06/hello-world-with-go.html b/pr-1714/2014/03/06/hello-world-with-go.html new file mode 100644 index 000000000..3b720c804 --- /dev/null +++ b/pr-1714/2014/03/06/hello-world-with-go.html @@ -0,0 +1,234 @@ + + + + + + + + + + + + + + + + Hello World with GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Hello World with GoCD

+

Ken Mugrage

+

+

+
+ +
+

In a few steps you'll see an example of a simple one stage pipeline in GoCD. This is definitely not meant to be a definitive guide, just a basic introduction to how GoCD works. It's definitely a good idea to peruse the concepts section go GoCD's help to understand some of the terms you'll see (like pipeline and stage).

+ +

I am assuming you've installed GoCD Server AND a GoCD Agent. You need both! I'm also assuming you have some source code in a version control system that you want to build.

+ +

Give it a name

+ +

Name the Pipeline

+ +

Pipelines have names, and they go into groups which are related. For example, you might have Project_1 and Project_2 in the Development pipeline group. Note that there can't be any spaces in these names.

+ +

Where is your code?

+ +

Add Materials details

+ +

GoCD has a concept of materials. This is the stuff that goes into your application. This is mostly likely in a version control system. There are other material types, but for the moment let's stick with a VCS. I have selected Subversion for this example, but GoCD also supports Git, Mercurial, Perforce and TFS.

+ +

Once you've entered your connection data, make sure to click the Check Connection button! It's not uncommon for people to have things like version control clients in their own path but not in the path of the GoCD user. This will tell you if GoCD can connect to your server.

+ +

Make it do something.

+ +

Use stages and jobs to manage work

+ +

GoCD uses stages and jobs to manage work. Make sure you check out the help doc linked above for definitions of both. Give your sample step a name, and then choose the Task Type. Go knows how to execute Ant, nAnt and Rake, by default so you'll see those called out specifically in the drop down. If you choose More you can provide any command which can be executed from the command line. This could be a shell script, batch file, maven command, chef recipe etc.

+ +

I have a very simple Java Hello World application that uses Ant. My build file is called build.xml, and I want to run the targets clean and all. You should enter whatever the valid targets are for your software.

+ +

Initial pipeline created

+ +

Paused Pipeline

+ +

We now have a very simple pipeline created. It doesn't do a whole lot (like the automated testing I'm sure you'll want) but it does do some real work. You'll note the big blue "pause" symbol at the top. This means that GoCD has your pipeline on hold while you're working on it. If you're ready to let GoCD work, just click that button to unpause.

+ +

Success!

+ +

One stage Pipeline created

+ +

And there we have it. A simple one step pipeline that will run in GoCD. Of course you'll want to add more stages to run tests and such. You'll probably also want to add more pipelines to actually deploy your software. (Note: doing everything in one long pattern is often considered an anti-pattern - see Jez Humble's article )

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/06/hello-world-with-go/index.html b/pr-1714/2014/03/06/hello-world-with-go/index.html new file mode 100644 index 000000000..c0357911f --- /dev/null +++ b/pr-1714/2014/03/06/hello-world-with-go/index.html @@ -0,0 +1,234 @@ + + + + + + + + + + + + + + + + Hello World with GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Hello World with GoCD

+

Ken Mugrage

+

+

+
+ +
+

In a few steps you'll see an example of a simple one stage pipeline in GoCD. This is definitely not meant to be a definitive guide, just a basic introduction to how GoCD works. It's definitely a good idea to peruse the concepts section go GoCD's help to understand some of the terms you'll see (like pipeline and stage).

+ +

I am assuming you've installed GoCD Server AND a GoCD Agent. You need both! I'm also assuming you have some source code in a version control system that you want to build.

+ +

Give it a name

+ +

Name the Pipeline

+ +

Pipelines have names, and they go into groups which are related. For example, you might have Project_1 and Project_2 in the Development pipeline group. Note that there can't be any spaces in these names.

+ +

Where is your code?

+ +

Add Materials details

+ +

GoCD has a concept of materials. This is the stuff that goes into your application. This is mostly likely in a version control system. There are other material types, but for the moment let's stick with a VCS. I have selected Subversion for this example, but GoCD also supports Git, Mercurial, Perforce and TFS.

+ +

Once you've entered your connection data, make sure to click the Check Connection button! It's not uncommon for people to have things like version control clients in their own path but not in the path of the GoCD user. This will tell you if GoCD can connect to your server.

+ +

Make it do something.

+ +

Use stages and jobs to manage work

+ +

GoCD uses stages and jobs to manage work. Make sure you check out the help doc linked above for definitions of both. Give your sample step a name, and then choose the Task Type. Go knows how to execute Ant, nAnt and Rake, by default so you'll see those called out specifically in the drop down. If you choose More you can provide any command which can be executed from the command line. This could be a shell script, batch file, maven command, chef recipe etc.

+ +

I have a very simple Java Hello World application that uses Ant. My build file is called build.xml, and I want to run the targets clean and all. You should enter whatever the valid targets are for your software.

+ +

Initial pipeline created

+ +

Paused Pipeline

+ +

We now have a very simple pipeline created. It doesn't do a whole lot (like the automated testing I'm sure you'll want) but it does do some real work. You'll note the big blue "pause" symbol at the top. This means that GoCD has your pipeline on hold while you're working on it. If you're ready to let GoCD work, just click that button to unpause.

+ +

Success!

+ +

One stage Pipeline created

+ +

And there we have it. A simple one step pipeline that will run in GoCD. Of course you'll want to add more stages to run tests and such. You'll probably also want to add more pipelines to actually deploy your software. (Note: doing everything in one long pattern is often considered an anti-pattern - see Jez Humble's article )

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/06/index.html b/pr-1714/2014/03/06/index.html new file mode 100644 index 000000000..e0d8faf50 --- /dev/null +++ b/pr-1714/2014/03/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 6 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/10.html b/pr-1714/2014/03/10.html new file mode 100644 index 000000000..8bcb374d8 --- /dev/null +++ b/pr-1714/2014/03/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 10 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/10/go-webinar-recording.html b/pr-1714/2014/03/10/go-webinar-recording.html new file mode 100644 index 000000000..a0f9ee03c --- /dev/null +++ b/pr-1714/2014/03/10/go-webinar-recording.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This 32 minute video is a recording of the session from 6 March, 2014.

+ +
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/10/go-webinar-recording/index.html b/pr-1714/2014/03/10/go-webinar-recording/index.html new file mode 100644 index 000000000..024381e03 --- /dev/null +++ b/pr-1714/2014/03/10/go-webinar-recording/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This 32 minute video is a recording of the session from 6 March, 2014.

+ +
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/10/index.html b/pr-1714/2014/03/10/index.html new file mode 100644 index 000000000..63f308d23 --- /dev/null +++ b/pr-1714/2014/03/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 10 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/03/index.html b/pr-1714/2014/03/index.html new file mode 100644 index 000000000..368fd5c95 --- /dev/null +++ b/pr-1714/2014/03/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04.html b/pr-1714/2014/04.html new file mode 100644 index 000000000..adc25360a --- /dev/null +++ b/pr-1714/2014/04.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24.html b/pr-1714/2014/04/24.html new file mode 100644 index 000000000..02809bf6e --- /dev/null +++ b/pr-1714/2014/04/24.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/Go_14_1_announced.html b/pr-1714/2014/04/24/Go_14_1_announced.html new file mode 100644 index 000000000..a7c80c353 --- /dev/null +++ b/pr-1714/2014/04/24/Go_14_1_announced.html @@ -0,0 +1,233 @@ + + + + + + + + + + + + + + + + Version 14.1 released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.1 Released

+

GoCD Team

+

+

+
+ +
+ +

Today we released GoCD 14.1.

+ +

New Feature

+ +

Create your own task plugins for GoCD.

+ +

GoCD supports configuring a few kinds of tasks (Nant, Ant and Rake), directly, from the configuration UI, without specifying them as a custom command. For instance, if you go to the configuration UI for a job, you'll see something like this:

+ +

Configuration UI for Task without Curl

+ +

A task plugin allows you to extend this so that you can have other tasks available here. The plugin also allows you to control the UI, as well as the data stored for this task.

+ +

For instance, you can find the source of a sample Curl plugin in GoCD's updated help documents. Assuming you have the plugin installed, you'll see that the dropdown in the job configuration UI has changed to look like this:

+ +

Configuration UI for Task with Curl

+ +
+ To use the new plugin related features of GoCD, it is required that you upgrade the agent-bootstrapper with version < 12.3. Although agent-bootstrapper version >= 12.3 is capable of handling this feature, we recommend upgrading your go-server and go-agents to the latest release. +
+ +

Source Code Updates

+ +

The way that GoCD is built and tested has been updated to make it easier for people to contribute.

+ +

Bug Fixes

+ +
    +
  • Fixed a corner case issue around job reschedule. (link)
    • +
  • Fixed issue where SVN post-commit hook was not passing along credentials. (link)
    • +
  • Fixed issue with adding users via UI with a . (dot) in the username. (link)
    • +
  • GoCD Agent handles UnknownHostException by substituting host name with a generated name. (link)
    • +
  • Task running executables in the working directory should now be prefixed with ./ (link)
    • +
+ +



+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/Go_14_1_announced/index.html b/pr-1714/2014/04/24/Go_14_1_announced/index.html new file mode 100644 index 000000000..3f5ab4469 --- /dev/null +++ b/pr-1714/2014/04/24/Go_14_1_announced/index.html @@ -0,0 +1,233 @@ + + + + + + + + + + + + + + + + Version 14.1 released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.1 Released

+

GoCD Team

+

+

+
+ +
+ +

Today we released GoCD 14.1.

+ +

New Feature

+ +

Create your own task plugins for GoCD.

+ +

GoCD supports configuring a few kinds of tasks (Nant, Ant and Rake), directly, from the configuration UI, without specifying them as a custom command. For instance, if you go to the configuration UI for a job, you'll see something like this:

+ +

Configuration UI for Task without Curl

+ +

A task plugin allows you to extend this so that you can have other tasks available here. The plugin also allows you to control the UI, as well as the data stored for this task.

+ +

For instance, you can find the source of a sample Curl plugin in GoCD's updated help documents. Assuming you have the plugin installed, you'll see that the dropdown in the job configuration UI has changed to look like this:

+ +

Configuration UI for Task with Curl

+ +
+ To use the new plugin related features of GoCD, it is required that you upgrade the agent-bootstrapper with version < 12.3. Although agent-bootstrapper version >= 12.3 is capable of handling this feature, we recommend upgrading your go-server and go-agents to the latest release. +
+ +

Source Code Updates

+ +

The way that GoCD is built and tested has been updated to make it easier for people to contribute.

+ +

Bug Fixes

+ +
    +
  • Fixed a corner case issue around job reschedule. (link)
    • +
  • Fixed issue where SVN post-commit hook was not passing along credentials. (link)
    • +
  • Fixed issue with adding users via UI with a . (dot) in the username. (link)
    • +
  • GoCD Agent handles UnknownHostException by substituting host name with a generated name. (link)
    • +
  • Task running executables in the working directory should now be prefixed with ./ (link)
    • +
+ +



+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins.html b/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins.html new file mode 100644 index 000000000..315322364 --- /dev/null +++ b/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Agent bootstrapper upgrade for task plugins | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Agent-bootstrapper upgrade to enable task plugins

+

Sachin Sudheendra

+

+

+
+ +
+

As part of GoCD 14.1, we officially announced Task plugins. Because tasks inherently are executed on an agent, we had to make few changes in the agent-bootstrapper component to allow this. Unlike the agent component which upgrades automatically to remain compatible with the server version, the agent-bootstrapper has to be manually upgraded.

+ +

Although we keep the agent-bootstrapper lean and flexible, which rarely requires changes to it, this was one situation where we had to make a change in it. As a result, GoCD Administrators will need to upgrade their agent installations (by using the go-agent installers appropriate to their go-server installation) before they can use the task-plugins in GoCD.

+ +

Note: Although agent-bootstrapper versions >= 12.3 is capable of handling this feature, we recommend upgrading your go-server and go-agents to the latest release.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins/index.html b/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins/index.html new file mode 100644 index 000000000..fa0080898 --- /dev/null +++ b/pr-1714/2014/04/24/agent-bootstrapper-upgrade-for-plugins/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Agent bootstrapper upgrade for task plugins | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Agent-bootstrapper upgrade to enable task plugins

+

Sachin Sudheendra

+

+

+
+ +
+

As part of GoCD 14.1, we officially announced Task plugins. Because tasks inherently are executed on an agent, we had to make few changes in the agent-bootstrapper component to allow this. Unlike the agent component which upgrades automatically to remain compatible with the server version, the agent-bootstrapper has to be manually upgraded.

+ +

Although we keep the agent-bootstrapper lean and flexible, which rarely requires changes to it, this was one situation where we had to make a change in it. As a result, GoCD Administrators will need to upgrade their agent installations (by using the go-agent installers appropriate to their go-server installation) before they can use the task-plugins in GoCD.

+ +

Note: Although agent-bootstrapper versions >= 12.3 is capable of handling this feature, we recommend upgrading your go-server and go-agents to the latest release.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/index.html b/pr-1714/2014/04/24/index.html new file mode 100644 index 000000000..89259d801 --- /dev/null +++ b/pr-1714/2014/04/24/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/source-code-for-go-now-available.html b/pr-1714/2014/04/24/source-code-for-go-now-available.html new file mode 100644 index 000000000..4db03e91b --- /dev/null +++ b/pr-1714/2014/04/24/source-code-for-go-now-available.html @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + Source code for GoCD now available | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Source code for GoCD now available

+

GoCD team

+

+

+
+ +
+

Source code for Go® is now available!

+ +

We're incredibly proud to announce that the source code for GoCD is now available at https://www.github.com/gocd/gocd. It's exciting to see what you, the community, will come up with to make GoCD even better.

+ +

Contributing

+ +

If you'd like to contribute to GoCD, please check out the guide which can be found at https://www.gocd.org/contribute/. As mentioned on that page, it will be necessary for you to fill out the contributor's license agreement to have your pull request accepted.

+ +

New plugin end-point available

+ +

We're also releasing GoCD 14.1, which now includes the ability to write your own custom task plugins. Is there a system you want to manage with GoCD but you'd prefer not to create command line scripts? Creating a plug-in could be a great way to extend GoCD without the need to modify the core source code. Check out the GoCD release notes for more information.

+ +

Current post-merge process

+ +

When your pull request is merged, it will be built by GoCD. We're still building out the infrastructure for the public facing GoCD servers and don't have Windows based agents live yet. Downloads for Windows will be available as normal, but we'll be running the Windows specific tests on internal Thoughtworks grids. We're sorting out licensing and hardware details to get these going, and will make sure they are available ASAP.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/24/source-code-for-go-now-available/index.html b/pr-1714/2014/04/24/source-code-for-go-now-available/index.html new file mode 100644 index 000000000..fca4fc15b --- /dev/null +++ b/pr-1714/2014/04/24/source-code-for-go-now-available/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + Source code for GoCD now available | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Source code for GoCD now available

+

GoCD team

+

+

+
+ +
+

Source code for Go® is now available!

+ +

We're incredibly proud to announce that the source code for GoCD is now available at https://www.github.com/gocd/gocd. It's exciting to see what you, the community, will come up with to make GoCD even better.

+ +

Contributing

+ +

If you'd like to contribute to GoCD, please check out the guide which can be found at https://www.gocd.org/contribute/. As mentioned on that page, it will be necessary for you to fill out the contributor's license agreement to have your pull request accepted.

+ +

New plugin end-point available

+ +

We're also releasing GoCD 14.1, which now includes the ability to write your own custom task plugins. Is there a system you want to manage with GoCD but you'd prefer not to create command line scripts? Creating a plug-in could be a great way to extend GoCD without the need to modify the core source code. Check out the GoCD release notes for more information.

+ +

Current post-merge process

+ +

When your pull request is merged, it will be built by GoCD. We're still building out the infrastructure for the public facing GoCD servers and don't have Windows based agents live yet. Downloads for Windows will be available as normal, but we'll be running the Windows specific tests on internal Thoughtworks grids. We're sorting out licensing and hardware details to get these going, and will make sure they are available ASAP.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/04/index.html b/pr-1714/2014/04/index.html new file mode 100644 index 000000000..adaa25dab --- /dev/null +++ b/pr-1714/2014/04/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05.html b/pr-1714/2014/05.html new file mode 100644 index 000000000..c9a09c84b --- /dev/null +++ b/pr-1714/2014/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05/18.html b/pr-1714/2014/05/18.html new file mode 100644 index 000000000..c23e5f74b --- /dev/null +++ b/pr-1714/2014/05/18.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 18 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05/18/index.html b/pr-1714/2014/05/18/index.html new file mode 100644 index 000000000..b7b934c44 --- /dev/null +++ b/pr-1714/2014/05/18/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 18 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05/18/manage-agents-with-docker.html b/pr-1714/2014/05/18/manage-agents-with-docker.html new file mode 100644 index 000000000..86f881893 --- /dev/null +++ b/pr-1714/2014/05/18/manage-agents-with-docker.html @@ -0,0 +1,323 @@ + + + + + + + + + + + + + + + + Using GoCD and Docker to manage agents | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Using GoCD and Docker to manage your GoCD agents

+

Ken Mugrage

+

+

+
+ +
+

[Update: As of the end of 2015, it might be better to use the GoCD Docker images available on Docker Hub as they are newer and better maintained and used by many in the GoCD community]

+ +

I'm convinced that the ability to automatically create and destroy build agents is key to having a flexible continuous delivery +setup. I'm equally convinced that this particular use case is better satisfied using very fast container technologies instead of +virtual machines. This is blog entry talks about using Docker for this challenge.

+ +

IMPORTANT It should be noted that this blog entry and code is the result of a spike. This definitely isn't production ready, +but could be useful if you're thinking about doing the same sort of thing. This will only work on Linux +machines, because Docker only works on Linux machines.

+ +

If anyone with more current programmer skills wants to fork and make it more production like, I'd be very happy to assist in any way +I can.

+ +

Setting it up

+ +
    +
  • Install Docker
    • +
  • Install GoCD server
    • +
  • +

    Install at least one GoCD agent if you want to use the pipeline - Yup, even though the whole idea here is to create and destroy +agents automatically, we have to install at least one to run the process. The server needs this to actually run the scripts.

    + + 
      Once the GoCD agent is installed, go to the Agents tab in your GoCD user interface and assign this agent a resource of "manager" if you intend to use the GoCD pipeline below.
+
    +
    • +
  • In order for GoCD (and anyone else) to run this without having to become root, you'll have to follow the instructions under +"Giving non-root access" at https://docs.docker.io/installation/ubuntulinux/. +I make absolutely no warranties for the security of following those instructions! Again, the point here (for me) was to spike out +creating agents on the fly, this is not production code.
    • +
+ +

The pieces

+ +

All of the scripts I'm using can be found at https://github.com/kmugrage/go-agent-docker. +Please feel free to clone / fork / send pull requests.

+ +
    +
  • Dockerfile
    • +
+ +

This is the file that defines how the docker image will be created. Normally you would run the docker build +program against this file, but I used a shell script so that I could call it from GoCD easier later.

+ +
    +
  • go-agent-14.1.0-18882.deb (no longer included)
    • +
+ +

Update on 22 June - The Dockerfile has been updated to use wget to download +the GoCD 14.1 agent debian installer. If you need the RPM version visit +www.gocd.org/download and change the Dockerfile to match your system.

+ +
    +
  • go-agent
    • +
+ +

You'll need to modify this file to set the IP address of your server. Just to make this more interesting, it needs to be the +IP address that Docker is aware of, so probably not the one you're used to using.

+ +

You can find this IP address using ifconfig…

+ +
ifconfig | grep -A 1 docker
+
+ +

On my system, that returns…

+ +
docker0   Link encap:Ethernet  HWaddr 56:84:7a:fe:97:99
+		  inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
+
+ +

Because that's my address, that's what you'll see in the go-agent file. As much as I might appreciate your help in supplying +agents for me, they won't be able to connect if you don't make this match your GoCD server.

+ +
    +
  • autoregister.properties
    • +
+ +

This file takes advantage of the autoregister feature in GoCD so that I don't have to manually approve the new agents. You'll +need to update the key based on the instructions at https://docs.gocd.org/current/advanced_usage/agent_auto_register.html

+ +
    +
  • build_docker_image.sh
    • +
+ +

Once you've modified the above, you're ready to build your containers. Execute this script at a command prompt.

+ +

This step could take quite a while depending on the speed of your internet connection. It has to download the base box, +add Java and a bunch of other things and then create the image you'll be using.

+ +
    +
  • start_agent_containers.sh
    • +
+ +

This shell script starts docker containers from the image. You can control how many containers get started by editing +the script itself.

+ +
    +
  • stop_agent_containers.sh
    • +
+ +

This shell script stops and removes all docker containers - WARNING: I do mean all. +If you run this on your box every single Docker container will be stopped and deleted. Did I mention this will remove +every single container on your machine?

+ +

If someone that's better with sed / awk / ? would like to modify to only remove the containers tagged with gocd/go-agent +please feel free!

+ +
    +
  • remove_agents.rb
    • +
+ +

This Ruby script removes disables and removes all agents on the GoCD server tagged with a "docker_created" +resource.

+ +
    +
  • go_config_xml_excerpt.txt
    • +
+ +

Everything above can be run from the command line just fine. Of course I wanted to have a GoCD pipeline manage all of this. +This text file shows the pipeline definition for mine. You'll need to change the github URL to point to your own. You're welcome +to use mine from above, but I removed it here just so your pipeline doesn't get executed with my GitHub changes if you don't +want it to.

+ +

Summary

+ +

It's my sincere hope that my first attempt to actually use Docker (and Ruby for that matter) will help you get something real +done. Please feel free to comment / ask questions / etc.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05/18/manage-agents-with-docker/index.html b/pr-1714/2014/05/18/manage-agents-with-docker/index.html new file mode 100644 index 000000000..ae5e955db --- /dev/null +++ b/pr-1714/2014/05/18/manage-agents-with-docker/index.html @@ -0,0 +1,323 @@ + + + + + + + + + + + + + + + + Using GoCD and Docker to manage agents | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Using GoCD and Docker to manage your GoCD agents

+

Ken Mugrage

+

+

+
+ +
+

[Update: As of the end of 2015, it might be better to use the GoCD Docker images available on Docker Hub as they are newer and better maintained and used by many in the GoCD community]

+ +

I'm convinced that the ability to automatically create and destroy build agents is key to having a flexible continuous delivery +setup. I'm equally convinced that this particular use case is better satisfied using very fast container technologies instead of +virtual machines. This is blog entry talks about using Docker for this challenge.

+ +

IMPORTANT It should be noted that this blog entry and code is the result of a spike. This definitely isn't production ready, +but could be useful if you're thinking about doing the same sort of thing. This will only work on Linux +machines, because Docker only works on Linux machines.

+ +

If anyone with more current programmer skills wants to fork and make it more production like, I'd be very happy to assist in any way +I can.

+ +

Setting it up

+ +
    +
  • Install Docker
    • +
  • Install GoCD server
    • +
  • +

    Install at least one GoCD agent if you want to use the pipeline - Yup, even though the whole idea here is to create and destroy +agents automatically, we have to install at least one to run the process. The server needs this to actually run the scripts.

    + + 
      Once the GoCD agent is installed, go to the Agents tab in your GoCD user interface and assign this agent a resource of "manager" if you intend to use the GoCD pipeline below.
+
    +
    • +
  • In order for GoCD (and anyone else) to run this without having to become root, you'll have to follow the instructions under +"Giving non-root access" at https://docs.docker.io/installation/ubuntulinux/. +I make absolutely no warranties for the security of following those instructions! Again, the point here (for me) was to spike out +creating agents on the fly, this is not production code.
    • +
+ +

The pieces

+ +

All of the scripts I'm using can be found at https://github.com/kmugrage/go-agent-docker. +Please feel free to clone / fork / send pull requests.

+ +
    +
  • Dockerfile
    • +
+ +

This is the file that defines how the docker image will be created. Normally you would run the docker build +program against this file, but I used a shell script so that I could call it from GoCD easier later.

+ +
    +
  • go-agent-14.1.0-18882.deb (no longer included)
    • +
+ +

Update on 22 June - The Dockerfile has been updated to use wget to download +the GoCD 14.1 agent debian installer. If you need the RPM version visit +www.gocd.org/download and change the Dockerfile to match your system.

+ +
    +
  • go-agent
    • +
+ +

You'll need to modify this file to set the IP address of your server. Just to make this more interesting, it needs to be the +IP address that Docker is aware of, so probably not the one you're used to using.

+ +

You can find this IP address using ifconfig…

+ +
ifconfig | grep -A 1 docker
+
+ +

On my system, that returns…

+ +
docker0   Link encap:Ethernet  HWaddr 56:84:7a:fe:97:99
+		  inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
+
+ +

Because that's my address, that's what you'll see in the go-agent file. As much as I might appreciate your help in supplying +agents for me, they won't be able to connect if you don't make this match your GoCD server.

+ +
    +
  • autoregister.properties
    • +
+ +

This file takes advantage of the autoregister feature in GoCD so that I don't have to manually approve the new agents. You'll +need to update the key based on the instructions at https://docs.gocd.org/current/advanced_usage/agent_auto_register.html

+ +
    +
  • build_docker_image.sh
    • +
+ +

Once you've modified the above, you're ready to build your containers. Execute this script at a command prompt.

+ +

This step could take quite a while depending on the speed of your internet connection. It has to download the base box, +add Java and a bunch of other things and then create the image you'll be using.

+ +
    +
  • start_agent_containers.sh
    • +
+ +

This shell script starts docker containers from the image. You can control how many containers get started by editing +the script itself.

+ +
    +
  • stop_agent_containers.sh
    • +
+ +

This shell script stops and removes all docker containers - WARNING: I do mean all. +If you run this on your box every single Docker container will be stopped and deleted. Did I mention this will remove +every single container on your machine?

+ +

If someone that's better with sed / awk / ? would like to modify to only remove the containers tagged with gocd/go-agent +please feel free!

+ +
    +
  • remove_agents.rb
    • +
+ +

This Ruby script removes disables and removes all agents on the GoCD server tagged with a "docker_created" +resource.

+ +
    +
  • go_config_xml_excerpt.txt
    • +
+ +

Everything above can be run from the command line just fine. Of course I wanted to have a GoCD pipeline manage all of this. +This text file shows the pipeline definition for mine. You'll need to change the github URL to point to your own. You're welcome +to use mine from above, but I removed it here just so your pipeline doesn't get executed with my GitHub changes if you don't +want it to.

+ +

Summary

+ +

It's my sincere hope that my first attempt to actually use Docker (and Ruby for that matter) will help you get something real +done. Please feel free to comment / ask questions / etc.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/05/index.html b/pr-1714/2014/05/index.html new file mode 100644 index 000000000..f2b0fa6df --- /dev/null +++ b/pr-1714/2014/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06.html b/pr-1714/2014/06.html new file mode 100644 index 000000000..7ed85645a --- /dev/null +++ b/pr-1714/2014/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06/05.html b/pr-1714/2014/06/05.html new file mode 100644 index 000000000..b4e027544 --- /dev/null +++ b/pr-1714/2014/06/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 5 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06/05/index.html b/pr-1714/2014/06/05/index.html new file mode 100644 index 000000000..439dd88ac --- /dev/null +++ b/pr-1714/2014/06/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 5 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06/05/using-go-cd-with-custom-certificates.html b/pr-1714/2014/06/05/using-go-cd-with-custom-certificates.html new file mode 100644 index 000000000..55d8f4541 --- /dev/null +++ b/pr-1714/2014/06/05/using-go-cd-with-custom-certificates.html @@ -0,0 +1,298 @@ + + + + + + + + + + + + + + + + Using GoCD with custom certificates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Using GoCD with custom certificates

+

Sachin Sudheendra

+

+

+
+ +
+

The following post will help you setting up GoCD to use your custom certificate instead of the self-signed certificate that GoCD ships with.

+ +

Note: This post is a copy of the one available here

+ +
+

Assumption: You have the certificate key (*.key) and an X509 certificate (*.crt).

+
+ +

Step 1: Changing passphrase of certificate key

+ +

The passphrase of the certificate key, for example site.key, should be changed to match the one we use for the keystore.

+ +
+

Note: Certificate passphrase must be set to serverKeystorepa55w0rd

+
+ +
$ mv site.key site.key.orig
+$ openssl rsa -des3 -in site.key.orig -out site.key
+Enter pass phrase for site.key.orig:
+writing RSA key
+Enter PEM pass phrase:
+Verifying - Enter PEM pass phrase:
+
+ +

Step 2: Converting your certificate (site.crt) into PKCS12 format

+ +

If you have the key and certificate, you should export them to the pkcs12 format by running

+ +
$ openssl pkcs12 -inkey site.key -in site.crt -export -out site.pkcs12
+Enter pass phrase for site.key:
+Enter Export Password:
+Verifying - Enter Export Password:
+
+ +

Step 3: Importing the PKCS12 store into the Java Keystore

+ +

Once you have the site.pkcs12 file, you would need to import this keystore into the java keystore that GoCD uses. We will use the keytool utility that ships with Java.

+ +
+

Note: Destination keystore password must be set to serverKeystorepa55w0rd

+
+ +
$ keytool -importkeystore -srckeystore site.pkcs12 -srcstoretype PKCS12 -destkeystore keystore -srcalias 1 -destalias cruise
+Enter destination keystore password: serverKeystorepa55w0rd
+Re-enter new password: serverKeystorepa55w0rd
+Enter source keystore password:
+Entry for alias 1 successfully imported.
+Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
+
+ +

Step 4: Replacing the current GoCD keystore with the newly generated one

+ +

Now that the keystore (/tmp/keystore) is created, we'll replace the one that GoCD uses with this new one.

+ +
    +
  • +

    Stop go-server

    + + 
    sudo /etc/init.d/go-server stop
+
    +
    • +
  • +

    Change user to go

    + + 
    sudo su - go
+
    +
    • +
  • +

    Change directory

    + + 
    cd /etc/go
+
    +
    • +
  • +

    Backup the current keystore

    + + 
    mv keystore keystore.original
+
    +
    • +
  • +

    Copy over the new keystore

    + + 
    cp /tmp/keystore /etc/go
+
    +
    • +
  • +

    Start go-server

    + + 
    sudo /etc/init.d/go-server start
+
    +
    • +
+ +

Post this, when you access the GoCD Server over HTTPS (https://:8154), the certificate served should be the one you added into the keystore.

+ +

References

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06/05/using-go-cd-with-custom-certificates/index.html b/pr-1714/2014/06/05/using-go-cd-with-custom-certificates/index.html new file mode 100644 index 000000000..550abb06f --- /dev/null +++ b/pr-1714/2014/06/05/using-go-cd-with-custom-certificates/index.html @@ -0,0 +1,298 @@ + + + + + + + + + + + + + + + + Using GoCD with custom certificates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Using GoCD with custom certificates

+

Sachin Sudheendra

+

+

+
+ +
+

The following post will help you setting up GoCD to use your custom certificate instead of the self-signed certificate that GoCD ships with.

+ +

Note: This post is a copy of the one available here

+ +
+

Assumption: You have the certificate key (*.key) and an X509 certificate (*.crt).

+
+ +

Step 1: Changing passphrase of certificate key

+ +

The passphrase of the certificate key, for example site.key, should be changed to match the one we use for the keystore.

+ +
+

Note: Certificate passphrase must be set to serverKeystorepa55w0rd

+
+ +
$ mv site.key site.key.orig
+$ openssl rsa -des3 -in site.key.orig -out site.key
+Enter pass phrase for site.key.orig:
+writing RSA key
+Enter PEM pass phrase:
+Verifying - Enter PEM pass phrase:
+
+ +

Step 2: Converting your certificate (site.crt) into PKCS12 format

+ +

If you have the key and certificate, you should export them to the pkcs12 format by running

+ +
$ openssl pkcs12 -inkey site.key -in site.crt -export -out site.pkcs12
+Enter pass phrase for site.key:
+Enter Export Password:
+Verifying - Enter Export Password:
+
+ +

Step 3: Importing the PKCS12 store into the Java Keystore

+ +

Once you have the site.pkcs12 file, you would need to import this keystore into the java keystore that GoCD uses. We will use the keytool utility that ships with Java.

+ +
+

Note: Destination keystore password must be set to serverKeystorepa55w0rd

+
+ +
$ keytool -importkeystore -srckeystore site.pkcs12 -srcstoretype PKCS12 -destkeystore keystore -srcalias 1 -destalias cruise
+Enter destination keystore password: serverKeystorepa55w0rd
+Re-enter new password: serverKeystorepa55w0rd
+Enter source keystore password:
+Entry for alias 1 successfully imported.
+Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
+
+ +

Step 4: Replacing the current GoCD keystore with the newly generated one

+ +

Now that the keystore (/tmp/keystore) is created, we'll replace the one that GoCD uses with this new one.

+ +
    +
  • +

    Stop go-server

    + + 
    sudo /etc/init.d/go-server stop
+
    +
    • +
  • +

    Change user to go

    + + 
    sudo su - go
+
    +
    • +
  • +

    Change directory

    + + 
    cd /etc/go
+
    +
    • +
  • +

    Backup the current keystore

    + + 
    mv keystore keystore.original
+
    +
    • +
  • +

    Copy over the new keystore

    + + 
    cp /tmp/keystore /etc/go
+
    +
    • +
  • +

    Start go-server

    + + 
    sudo /etc/init.d/go-server start
+
    +
    • +
+ +

Post this, when you access the GoCD Server over HTTPS (https://:8154), the certificate served should be the one you added into the keystore.

+ +

References

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/06/index.html b/pr-1714/2014/06/index.html new file mode 100644 index 000000000..853739063 --- /dev/null +++ b/pr-1714/2014/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07.html b/pr-1714/2014/07.html new file mode 100644 index 000000000..109119b31 --- /dev/null +++ b/pr-1714/2014/07.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/01.html b/pr-1714/2014/07/01.html new file mode 100644 index 000000000..78bf043f0 --- /dev/null +++ b/pr-1714/2014/07/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 1 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/01/What-would-help-you.html b/pr-1714/2014/07/01/What-would-help-you.html new file mode 100644 index 000000000..81a8a341e --- /dev/null +++ b/pr-1714/2014/07/01/What-would-help-you.html @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + + + What would help you get involved | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

What would help you get involved?

+

Ken Mugrage

+

+

+
+ +
+

One of my personal favorite things about open source software is the ability to get involved. Sometimes the changes made are small, and sometimes they aren't. I've found that this is reasonably easy on small or new projects, and considerably harder on larger or more mature projects.

+ +

GoCD is large and mature.

+ +

The existing GoCD team has done a few things to try to make it easier for you to get involved…

+ + + +

Are these helpful to you? What would be more helpful?

+ +

Keep in mind that involvement in an open source project doesn't imply writing code. Submitted code is great. Documentation, discussion and even evangelism are incredibly valuable as well.

+ +

Feel free to use the discussion forums below or use the mailing lists to discuss.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/01/What-would-help-you/index.html b/pr-1714/2014/07/01/What-would-help-you/index.html new file mode 100644 index 000000000..70ff9e023 --- /dev/null +++ b/pr-1714/2014/07/01/What-would-help-you/index.html @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + + + What would help you get involved | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

What would help you get involved?

+

Ken Mugrage

+

+

+
+ +
+

One of my personal favorite things about open source software is the ability to get involved. Sometimes the changes made are small, and sometimes they aren't. I've found that this is reasonably easy on small or new projects, and considerably harder on larger or more mature projects.

+ +

GoCD is large and mature.

+ +

The existing GoCD team has done a few things to try to make it easier for you to get involved…

+ + + +

Are these helpful to you? What would be more helpful?

+ +

Keep in mind that involvement in an open source project doesn't imply writing code. Submitted code is great. Documentation, discussion and even evangelism are incredibly valuable as well.

+ +

Feel free to use the discussion forums below or use the mailing lists to discuss.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/01/index.html b/pr-1714/2014/07/01/index.html new file mode 100644 index 000000000..8cc773774 --- /dev/null +++ b/pr-1714/2014/07/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 1 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/09.html b/pr-1714/2014/07/09.html new file mode 100644 index 000000000..17d37eecc --- /dev/null +++ b/pr-1714/2014/07/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/09/index.html b/pr-1714/2014/07/09/index.html new file mode 100644 index 000000000..9e531e105 --- /dev/null +++ b/pr-1714/2014/07/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/09/stopping-support-for-java-jdk-6.html b/pr-1714/2014/07/09/stopping-support-for-java-jdk-6.html new file mode 100644 index 000000000..55c986296 --- /dev/null +++ b/pr-1714/2014/07/09/stopping-support-for-java-jdk-6.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Stopping support for Java/JDK 6 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Stopping support for Java/JDK 6

+

Praveen

+

+

+
+ +
+

There was a recommendation in April 2013, that all users move their GoCD Server and GoCD Agent installations to Java 7. Oracle and OpenJDK no longer support Java 6. So it is time for GoCD to stop supporting it. 14.2.0 will be last GoCD release which will work with Java 6. Any new GoCD release beyond 14.2.0 might not work with Java 6.

+ +

If you have not already moved to Java 7, we request you to do so. Should you face any issues please do write to the community mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/09/stopping-support-for-java-jdk-6/index.html b/pr-1714/2014/07/09/stopping-support-for-java-jdk-6/index.html new file mode 100644 index 000000000..eb45e7760 --- /dev/null +++ b/pr-1714/2014/07/09/stopping-support-for-java-jdk-6/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Stopping support for Java/JDK 6 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Stopping support for Java/JDK 6

+

Praveen

+

+

+
+ +
+

There was a recommendation in April 2013, that all users move their GoCD Server and GoCD Agent installations to Java 7. Oracle and OpenJDK no longer support Java 6. So it is time for GoCD to stop supporting it. 14.2.0 will be last GoCD release which will work with Java 6. Any new GoCD release beyond 14.2.0 might not work with Java 6.

+ +

If you have not already moved to Java 7, we request you to do so. Should you face any issues please do write to the community mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/07/index.html b/pr-1714/2014/07/index.html new file mode 100644 index 000000000..893d1f24a --- /dev/null +++ b/pr-1714/2014/07/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08.html b/pr-1714/2014/08.html new file mode 100644 index 000000000..3275e300f --- /dev/null +++ b/pr-1714/2014/08.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/07.html b/pr-1714/2014/08/07.html new file mode 100644 index 000000000..2c9b36aee --- /dev/null +++ b/pr-1714/2014/08/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 7 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/07/go-webinar-recording.html b/pr-1714/2014/08/07/go-webinar-recording.html new file mode 100644 index 000000000..e6bbcf118 --- /dev/null +++ b/pr-1714/2014/08/07/go-webinar-recording.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 7 August, 2014

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/07/go-webinar-recording/index.html b/pr-1714/2014/08/07/go-webinar-recording/index.html new file mode 100644 index 000000000..063888aef --- /dev/null +++ b/pr-1714/2014/08/07/go-webinar-recording/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 7 August, 2014

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/07/index.html b/pr-1714/2014/08/07/index.html new file mode 100644 index 000000000..80696fe00 --- /dev/null +++ b/pr-1714/2014/08/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 7 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/19.html b/pr-1714/2014/08/19.html new file mode 100644 index 000000000..b8cf7183f --- /dev/null +++ b/pr-1714/2014/08/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 19 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/19/cloning-templates.html b/pr-1714/2014/08/19/cloning-templates.html new file mode 100644 index 000000000..b47346f7e --- /dev/null +++ b/pr-1714/2014/08/19/cloning-templates.html @@ -0,0 +1,269 @@ + + + + + + + + + + + + + + + + Cloning Templates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: Continuous Delivery with GoCD - Cloning Templates

+

Marius-Stefan Ciotlos

+

+

+
+ +
+

When using GO for Continuous Delivery with multiple teams where you have various security groups, you usually end up with multiple template types. Depending on your application ecosystem you might have different deployment methods depending on the application type, that have some overlapping. At the moment we don't have the ability to have Stage templates, so you need a completely new template when you have differences.

+ +

We have decided to have one deployment template separate per application / security group (Pipeline group) so we distribute maintenance, but also reduce the risk of breaking Pipelines of other teams when we change a base template. Having different templates also allows us to allocate Template Admins specific for the application / team / security group that now can manage most of the needs of a team without requiring GoCD System Admin rights.

+ +

As you don't want team to get Admin access across multiple applications but you still want them to have something to start with (a base template), we have created two Basic templates that cover basic needs for an application deployment that we "Clone" for each team. After cloning we assign an Admin from their team so they can start modifying it according to their own flavour. Cloning templates is not available in GO at the moment, so we had to find a way around it. +One contributor created a script that interacts with GO's own Configuration API to allow template cloning.

+ +

How to setup cloning in your GO server instance

+
    +
  1. Make sure you have access to https://github.com/oanastoia/go-config-management.git, otherwise you will need to clone this repository inside your infrastructure
    2. +
  2. Create a Pipeline in your GoCD server instance
    3. +
  3. Use the "Trigger with options" button to do the magic!
    4. +
+ +

Step by step setup

+

In this section I will try to cover with screenshots the steps you need to achieve the easiest to use setup

+ +

Create a new template group

+

Create a new template group for your "Administrative" tasks that you give permissions only to the persons you want to use the cloning. This will be useful if you decide to have more "configuration" type of pipelines. +In our organisation we have a "tooling" repository we use to wrap complex scripts to use in our tasks. +I will not go into detail on how to achieve this, but you can read more on how to specify permissions for pipeline groups.

+ +

Create a new pipeline within this group

+
    +
  1. You will need to create new pipeline within this group.
    2. +
  2. You will need to use Git as Material Type and under the URL, use the location of the cloning script (https://github.com/oanastoia/go-config-management.git if you have access to it, or the location where you cloned it). Use "Check Connection" to test it out.
    3. +
  3. You will need to add two Environment Variables: SOURCE_TEMPLATE and DESTINATION_TEMPLATE that have some default values
    4. +
  4. You will need to add two Secure Environment Variables: API_USER and API_PASS that contain credentials for a user that has correct permissions to use the Configuration API
    5. +
+ +

Environment Variables view

+ +

Alternative you can use the Config XML to inject your template in the group using the code below (do not forget to replace the environment variables with the right values)

+ +
<pipeline name="GoCloneTemplate">
+  <environmentvariables>
+    <variable name="SOURCE_TEMPLATE">
+      <value>Source_Template</value>
+    </variable>
+    <variable name="DESTINATION_TEMPLATE">
+      <value>Example_Clone</value>
+    </variable>
+  </environmentvariables>
+  <materials>
+    <git url="https://github.com/oanastoia/go-config-management.git" />
+  </materials>
+  <stage name="CloneTemplate">
+    <approval type="manual" />
+    <jobs>
+      <job name="clone_template">
+        <tasks>
+          <exec command="ruby">
+            <arg>TemplateClone.rb</arg>
+            <arg>clone</arg>
+            <runif status="passed" />
+          </exec>
+        </tasks>
+      </job>
+    </jobs>
+  </stage>
+</pipeline>
+
+ +

After adding the code, please add the API_USER and API_PASS Secure Environment Variables to reflect the correct user and password as seen in the above screenshot.

+ +

Trigger the pipeline with options

+

Now you can just trigger your pipeline with options and go to the Environment Variables tab to put in the right details for cloning.

+ +

Trigger Pipeline with Options +Environment Variables Tab

+ +

Enjoy!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/19/cloning-templates/index.html b/pr-1714/2014/08/19/cloning-templates/index.html new file mode 100644 index 000000000..b730d77bb --- /dev/null +++ b/pr-1714/2014/08/19/cloning-templates/index.html @@ -0,0 +1,269 @@ + + + + + + + + + + + + + + + + Cloning Templates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: Continuous Delivery with GoCD - Cloning Templates

+

Marius-Stefan Ciotlos

+

+

+
+ +
+

When using GO for Continuous Delivery with multiple teams where you have various security groups, you usually end up with multiple template types. Depending on your application ecosystem you might have different deployment methods depending on the application type, that have some overlapping. At the moment we don't have the ability to have Stage templates, so you need a completely new template when you have differences.

+ +

We have decided to have one deployment template separate per application / security group (Pipeline group) so we distribute maintenance, but also reduce the risk of breaking Pipelines of other teams when we change a base template. Having different templates also allows us to allocate Template Admins specific for the application / team / security group that now can manage most of the needs of a team without requiring GoCD System Admin rights.

+ +

As you don't want team to get Admin access across multiple applications but you still want them to have something to start with (a base template), we have created two Basic templates that cover basic needs for an application deployment that we "Clone" for each team. After cloning we assign an Admin from their team so they can start modifying it according to their own flavour. Cloning templates is not available in GO at the moment, so we had to find a way around it. +One contributor created a script that interacts with GO's own Configuration API to allow template cloning.

+ +

How to setup cloning in your GO server instance

+
    +
  1. Make sure you have access to https://github.com/oanastoia/go-config-management.git, otherwise you will need to clone this repository inside your infrastructure
    2. +
  2. Create a Pipeline in your GoCD server instance
    3. +
  3. Use the "Trigger with options" button to do the magic!
    4. +
+ +

Step by step setup

+

In this section I will try to cover with screenshots the steps you need to achieve the easiest to use setup

+ +

Create a new template group

+

Create a new template group for your "Administrative" tasks that you give permissions only to the persons you want to use the cloning. This will be useful if you decide to have more "configuration" type of pipelines. +In our organisation we have a "tooling" repository we use to wrap complex scripts to use in our tasks. +I will not go into detail on how to achieve this, but you can read more on how to specify permissions for pipeline groups.

+ +

Create a new pipeline within this group

+
    +
  1. You will need to create new pipeline within this group.
    2. +
  2. You will need to use Git as Material Type and under the URL, use the location of the cloning script (https://github.com/oanastoia/go-config-management.git if you have access to it, or the location where you cloned it). Use "Check Connection" to test it out.
    3. +
  3. You will need to add two Environment Variables: SOURCE_TEMPLATE and DESTINATION_TEMPLATE that have some default values
    4. +
  4. You will need to add two Secure Environment Variables: API_USER and API_PASS that contain credentials for a user that has correct permissions to use the Configuration API
    5. +
+ +

Environment Variables view

+ +

Alternative you can use the Config XML to inject your template in the group using the code below (do not forget to replace the environment variables with the right values)

+ +
<pipeline name="GoCloneTemplate">
+  <environmentvariables>
+    <variable name="SOURCE_TEMPLATE">
+      <value>Source_Template</value>
+    </variable>
+    <variable name="DESTINATION_TEMPLATE">
+      <value>Example_Clone</value>
+    </variable>
+  </environmentvariables>
+  <materials>
+    <git url="https://github.com/oanastoia/go-config-management.git" />
+  </materials>
+  <stage name="CloneTemplate">
+    <approval type="manual" />
+    <jobs>
+      <job name="clone_template">
+        <tasks>
+          <exec command="ruby">
+            <arg>TemplateClone.rb</arg>
+            <arg>clone</arg>
+            <runif status="passed" />
+          </exec>
+        </tasks>
+      </job>
+    </jobs>
+  </stage>
+</pipeline>
+
+ +

After adding the code, please add the API_USER and API_PASS Secure Environment Variables to reflect the correct user and password as seen in the above screenshot.

+ +

Trigger the pipeline with options

+

Now you can just trigger your pipeline with options and go to the Environment Variables tab to put in the right details for cloning.

+ +

Trigger Pipeline with Options +Environment Variables Tab

+ +

Enjoy!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/19/index.html b/pr-1714/2014/08/19/index.html new file mode 100644 index 000000000..d48f85114 --- /dev/null +++ b/pr-1714/2014/08/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 19 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/08/index.html b/pr-1714/2014/08/index.html new file mode 100644 index 000000000..755efe7c1 --- /dev/null +++ b/pr-1714/2014/08/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10.html b/pr-1714/2014/10.html new file mode 100644 index 000000000..18bf013fc --- /dev/null +++ b/pr-1714/2014/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10/09.html b/pr-1714/2014/10/09.html new file mode 100644 index 000000000..12cebecdf --- /dev/null +++ b/pr-1714/2014/10/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10/09/Distributed-Test-Execution.html b/pr-1714/2014/10/09/Distributed-Test-Execution.html new file mode 100644 index 000000000..ba7b93c97 --- /dev/null +++ b/pr-1714/2014/10/09/Distributed-Test-Execution.html @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + Distributed Test Execution with TLB | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Distributed Test Execution with GoCD + TLB

+

GoCD Team

+

+

+
+ +
+

Writing tests has finally become the norm. Consequently, running tests for every commit is central to & the most time consuming activity in any CI/CD setup. In a decent-sized production quality project you tend to have thousands of tests. That means the cycle time, i.e. the time it takes for a commit to reach deployable state (after running all unit, integration & functional tests), keeps growing.

+ +

It gets harder when teams follow XP related practices like "small commits, frequent commits" since it causes parallel builds & resource starvation.

+ +

One such example is GoCD's codebase. Just the "Common" & "Server" components of GoCD which comprises of unit & integration tests, together has ~6000 tests which will take about ~5 hours if run serially! The functional test suite is about 260+ tests with combined runtime of ~15 hours. That's close to a day & we haven't even run everything for a single commit!

+ +

Note that the number of tests is so huge that just putting in a powerful box & running test in parallel will not bring it down to acceptable limits. Also, a large number of other problems surface if you start running tests in parallel on same box (without sandboxed environment) like concurrency issues etc.

+ +

Solution [GoCD + TLB]

+ +

GoCD improves the cycle time of its own build by making test execution faster, distributing it across many agents (machines). After this "Common" + "Server" takes 20 minutes. All functional tests run in 45 minutes. Thats close to an hour! Still not ideal (a few minutes - constrained by resource availability), but better. :)

+ +

Test Load Balancer (TLB)

+ +

TLB is an open-source library which provides the ability to break up a test suite into pieces and run a part. It guarantees 'Mutual Exclusion' & 'Collective Exhaustion' properties that are essential to reliably running tests in distributed fashion.

+ +

TLB's strength lies in intelligent test distribution which is based on time, i.e. the tests will be distributed based on time they take to execute, making the jobs close to equal runs which leads to better resource utilization. It falls back on count based splitting if test times are not available. It also runs tests in 'Failed First' order, so if a test has failed in previous run it will be run before other tests which means faster feedback.

+ +

Note: As of this writing, TLB integrates with JUnit (through Ant, Maven & Buildr), RSpec (through Rake), Cucumber (through Rake), Twist (through Ant & Buildr).

+ +

Quick Setup

+ +

Download TLB

+ +

Unzip tlb-complete-0.3.2.tar.gz to tlb-complete-0.3.2:

+ +
$ cd tlb-complete-0.3.2/server
+$ chmod +x server.sh
+$ ./server.sh start
+
+ +

This should start server at https://host-ip-address:7019

+ +

Resources:

+ + + +

GoCD

+ +

GoCD is an open-source CI/CD tool. Its well known for its powerful modelling, tracing & visualization capabilities.

+ +

While TLB is doing all the distribution, GoCD does what it does best - orchestrate the parallel execution.

+ +

Run 'X' instances

+ +

Starting release 14.3 you can spawn 'x' instances of a job. So if you want to distribute your tests across 10 machines you just need to set run instance count to 10 & GoCD will spawn 10 instances of the job when scheduling.

+ +

Sample Configuration

+ +

Setup a pipeline with material (SCM) that contains your tests.

+ +

Pipeline setup with materials

+ +

Setup Job to spawn required number of instances (run instance count).

+ +

Job Settings configured for three instances

+ +

Setup TLB related environment variables at Environment / Pipeline / Stage / Job level.

+ +

Environment Variables Tab

+ +

Setup the task to consume GO_PIPELINE_NAME, GO_STAGE_NAME, GO_PIPELINE_COUNTER, GO_STAGE_COUNTER, GO_JOB_RUN_INDEX & GO_JOB_RUN_COUNT environment variables that GoCD exposes.

+ +

Tasks Tab

+ +

Upload junit xmls as test artifacts.

+ +

Artifacts Tab

+ +

Sample Pipeline Configuration

+ +
<pipeline name="maven-project">
+  <materials>
+    <git url="https://github.com/test-load-balancer/sample_projects.git" dest="sample_projects" />
+  </materials>
+  <stage name="unit-tests">
+    <jobs>
+      <job name="test-split" runInstanceCount="3">
+        <environmentvariables>
+          <variable name="TLB_BASE_URL">
+            <value>https://localhost:7019</value>
+          </variable>
+          <variable name="TLB_TMP_DIR">
+            <value>/tmp</value>
+          </variable>
+          <variable name="TLB_JOB_NAME">
+            <value>${GO_PIPELINE_NAME}-${GO_STAGE_NAME}-test-split</value>
+          </variable>
+          <variable name="TLB_JOB_VERSION">
+            <value>${GO_PIPELINE_COUNTER}-${GO_STAGE_COUNTER}</value>
+          </variable>
+          <variable name="TLB_PARTITION_NUMBER">
+            <value>${GO_JOB_RUN_INDEX}</value>
+          </variable>
+          <variable name="TLB_TOTAL_PARTITIONS">
+            <value>${GO_JOB_RUN_COUNT}</value>
+          </variable>
+        </environmentvariables>
+        <tasks>
+          <exec command="mvn" workingdir="sample_projects/maven_junit">
+            <arg>clean</arg>
+            <arg>install</arg>
+            <arg>-DskipTests</arg>
+            <runif status="passed" />
+          </exec>
+          <exec command="mvn" workingdir="sample_projects/maven_junit">
+            <arg>clean</arg>
+            <arg>test</arg>
+            <arg>-DskipTests</arg>
+            <arg>-Drun.tests.using.tlb=true</arg>
+            <runif status="passed" />
+          </exec>
+        </tasks>
+        <artifacts>
+          <test src="sample_projects/maven_junit/target/reports/*.xml" dest="test-reports" />
+        </artifacts>
+      </job>
+    </jobs>
+  </stage>
+</pipeline>
+
+ +

Other features that helps with Test Parallelization

+ +

Wait for all jobs to finish

+ +

GoCD's modeling capability gives it the ability to run jobs in parallel but wait for all of them to finish before the next Stage / downstream Pipelines are triggered.

+ +

Viewing Jobs progress in Jobs Tab

+ +

Stop the downstream flow

+ +

If any of the tests (and as a result the Job running the test) fails, the Stage is considered as failed. This causes the flow to stop as expected.

+ +

Failed Stage

+ +

Consolidated Test Report

+ +

Once all the Jobs are done running, GoCD consolidates test reports & shows the result at stage level for easy consumption.

+ +

Consolidated Reports in Tests Tab

+ +

Drill down

+ +

You can drill down at job level to know more information like 'test count', 'console output' for the Job (test) etc.

+ +

Drilled Down view of Passed Test 1 +Drilled Down view of Failed Test +Drilled Down view of Passed Test 2

+ +

Partition re-run

+ +

GoCD also provides ability to re-run a Job of a stage. This provides ability to run the partition that could have failed due to flaky test etc. The best part is, TLB runs the exact tests that it ran the last time making sure no test is missed out!

+ +

Option to Rerun Jobs +State of Rerun Tests

+ +

TLB Correctness Check

+ +

TLB provides an ability to check correctness, i.e. it will make sure all tests were run. You can configure to run this correctness check once all partitions are done executing, may be in next stage / pipeline.

+ +

Power of dynamic splitting

+ +

GoCD's one knob control to amount of parallelization means that when the number of tests increase/decrease all you will need to do is change the run instance count based on number of tests & resource availability & you are done!

+ +

–

+ +

As always, GoCD questions can be asked at go-cd.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10/09/Distributed-Test-Execution/index.html b/pr-1714/2014/10/09/Distributed-Test-Execution/index.html new file mode 100644 index 000000000..45023a5af --- /dev/null +++ b/pr-1714/2014/10/09/Distributed-Test-Execution/index.html @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + Distributed Test Execution with TLB | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Distributed Test Execution with GoCD + TLB

+

GoCD Team

+

+

+
+ +
+

Writing tests has finally become the norm. Consequently, running tests for every commit is central to & the most time consuming activity in any CI/CD setup. In a decent-sized production quality project you tend to have thousands of tests. That means the cycle time, i.e. the time it takes for a commit to reach deployable state (after running all unit, integration & functional tests), keeps growing.

+ +

It gets harder when teams follow XP related practices like "small commits, frequent commits" since it causes parallel builds & resource starvation.

+ +

One such example is GoCD's codebase. Just the "Common" & "Server" components of GoCD which comprises of unit & integration tests, together has ~6000 tests which will take about ~5 hours if run serially! The functional test suite is about 260+ tests with combined runtime of ~15 hours. That's close to a day & we haven't even run everything for a single commit!

+ +

Note that the number of tests is so huge that just putting in a powerful box & running test in parallel will not bring it down to acceptable limits. Also, a large number of other problems surface if you start running tests in parallel on same box (without sandboxed environment) like concurrency issues etc.

+ +

Solution [GoCD + TLB]

+ +

GoCD improves the cycle time of its own build by making test execution faster, distributing it across many agents (machines). After this "Common" + "Server" takes 20 minutes. All functional tests run in 45 minutes. Thats close to an hour! Still not ideal (a few minutes - constrained by resource availability), but better. :)

+ +

Test Load Balancer (TLB)

+ +

TLB is an open-source library which provides the ability to break up a test suite into pieces and run a part. It guarantees 'Mutual Exclusion' & 'Collective Exhaustion' properties that are essential to reliably running tests in distributed fashion.

+ +

TLB's strength lies in intelligent test distribution which is based on time, i.e. the tests will be distributed based on time they take to execute, making the jobs close to equal runs which leads to better resource utilization. It falls back on count based splitting if test times are not available. It also runs tests in 'Failed First' order, so if a test has failed in previous run it will be run before other tests which means faster feedback.

+ +

Note: As of this writing, TLB integrates with JUnit (through Ant, Maven & Buildr), RSpec (through Rake), Cucumber (through Rake), Twist (through Ant & Buildr).

+ +

Quick Setup

+ +

Download TLB

+ +

Unzip tlb-complete-0.3.2.tar.gz to tlb-complete-0.3.2:

+ +
$ cd tlb-complete-0.3.2/server
+$ chmod +x server.sh
+$ ./server.sh start
+
+ +

This should start server at https://host-ip-address:7019

+ +

Resources:

+ + + +

GoCD

+ +

GoCD is an open-source CI/CD tool. Its well known for its powerful modelling, tracing & visualization capabilities.

+ +

While TLB is doing all the distribution, GoCD does what it does best - orchestrate the parallel execution.

+ +

Run 'X' instances

+ +

Starting release 14.3 you can spawn 'x' instances of a job. So if you want to distribute your tests across 10 machines you just need to set run instance count to 10 & GoCD will spawn 10 instances of the job when scheduling.

+ +

Sample Configuration

+ +

Setup a pipeline with material (SCM) that contains your tests.

+ +

Pipeline setup with materials

+ +

Setup Job to spawn required number of instances (run instance count).

+ +

Job Settings configured for three instances

+ +

Setup TLB related environment variables at Environment / Pipeline / Stage / Job level.

+ +

Environment Variables Tab

+ +

Setup the task to consume GO_PIPELINE_NAME, GO_STAGE_NAME, GO_PIPELINE_COUNTER, GO_STAGE_COUNTER, GO_JOB_RUN_INDEX & GO_JOB_RUN_COUNT environment variables that GoCD exposes.

+ +

Tasks Tab

+ +

Upload junit xmls as test artifacts.

+ +

Artifacts Tab

+ +

Sample Pipeline Configuration

+ +
<pipeline name="maven-project">
+  <materials>
+    <git url="https://github.com/test-load-balancer/sample_projects.git" dest="sample_projects" />
+  </materials>
+  <stage name="unit-tests">
+    <jobs>
+      <job name="test-split" runInstanceCount="3">
+        <environmentvariables>
+          <variable name="TLB_BASE_URL">
+            <value>https://localhost:7019</value>
+          </variable>
+          <variable name="TLB_TMP_DIR">
+            <value>/tmp</value>
+          </variable>
+          <variable name="TLB_JOB_NAME">
+            <value>${GO_PIPELINE_NAME}-${GO_STAGE_NAME}-test-split</value>
+          </variable>
+          <variable name="TLB_JOB_VERSION">
+            <value>${GO_PIPELINE_COUNTER}-${GO_STAGE_COUNTER}</value>
+          </variable>
+          <variable name="TLB_PARTITION_NUMBER">
+            <value>${GO_JOB_RUN_INDEX}</value>
+          </variable>
+          <variable name="TLB_TOTAL_PARTITIONS">
+            <value>${GO_JOB_RUN_COUNT}</value>
+          </variable>
+        </environmentvariables>
+        <tasks>
+          <exec command="mvn" workingdir="sample_projects/maven_junit">
+            <arg>clean</arg>
+            <arg>install</arg>
+            <arg>-DskipTests</arg>
+            <runif status="passed" />
+          </exec>
+          <exec command="mvn" workingdir="sample_projects/maven_junit">
+            <arg>clean</arg>
+            <arg>test</arg>
+            <arg>-DskipTests</arg>
+            <arg>-Drun.tests.using.tlb=true</arg>
+            <runif status="passed" />
+          </exec>
+        </tasks>
+        <artifacts>
+          <test src="sample_projects/maven_junit/target/reports/*.xml" dest="test-reports" />
+        </artifacts>
+      </job>
+    </jobs>
+  </stage>
+</pipeline>
+
+ +

Other features that helps with Test Parallelization

+ +

Wait for all jobs to finish

+ +

GoCD's modeling capability gives it the ability to run jobs in parallel but wait for all of them to finish before the next Stage / downstream Pipelines are triggered.

+ +

Viewing Jobs progress in Jobs Tab

+ +

Stop the downstream flow

+ +

If any of the tests (and as a result the Job running the test) fails, the Stage is considered as failed. This causes the flow to stop as expected.

+ +

Failed Stage

+ +

Consolidated Test Report

+ +

Once all the Jobs are done running, GoCD consolidates test reports & shows the result at stage level for easy consumption.

+ +

Consolidated Reports in Tests Tab

+ +

Drill down

+ +

You can drill down at job level to know more information like 'test count', 'console output' for the Job (test) etc.

+ +

Drilled Down view of Passed Test 1 +Drilled Down view of Failed Test +Drilled Down view of Passed Test 2

+ +

Partition re-run

+ +

GoCD also provides ability to re-run a Job of a stage. This provides ability to run the partition that could have failed due to flaky test etc. The best part is, TLB runs the exact tests that it ran the last time making sure no test is missed out!

+ +

Option to Rerun Jobs +State of Rerun Tests

+ +

TLB Correctness Check

+ +

TLB provides an ability to check correctness, i.e. it will make sure all tests were run. You can configure to run this correctness check once all partitions are done executing, may be in next stage / pipeline.

+ +

Power of dynamic splitting

+ +

GoCD's one knob control to amount of parallelization means that when the number of tests increase/decrease all you will need to do is change the run instance count based on number of tests & resource availability & you are done!

+ +

–

+ +

As always, GoCD questions can be asked at go-cd.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10/09/Distrubuted-Test-Execution.html b/pr-1714/2014/10/09/Distrubuted-Test-Execution.html new file mode 100644 index 000000000..d062e8e61 --- /dev/null +++ b/pr-1714/2014/10/09/Distrubuted-Test-Execution.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the Distributed-Test-Execution/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2014/10/09/Distrubuted-Test-Execution/index.html b/pr-1714/2014/10/09/Distrubuted-Test-Execution/index.html new file mode 100644 index 000000000..f58180b65 --- /dev/null +++ b/pr-1714/2014/10/09/Distrubuted-Test-Execution/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../Distributed-Test-Execution/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2014/10/09/index.html b/pr-1714/2014/10/09/index.html new file mode 100644 index 000000000..a7cd8a444 --- /dev/null +++ b/pr-1714/2014/10/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/10/index.html b/pr-1714/2014/10/index.html new file mode 100644 index 000000000..572259a30 --- /dev/null +++ b/pr-1714/2014/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11.html b/pr-1714/2014/11.html new file mode 100644 index 000000000..fcb5c870e --- /dev/null +++ b/pr-1714/2014/11.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/11.html b/pr-1714/2014/11/11.html new file mode 100644 index 000000000..631ccb8f8 --- /dev/null +++ b/pr-1714/2014/11/11.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 11 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/11/Go_14_3_announced.html b/pr-1714/2014/11/11/Go_14_3_announced.html new file mode 100644 index 000000000..c1cfd4137 --- /dev/null +++ b/pr-1714/2014/11/11/Go_14_3_announced.html @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + Version 14.3 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.3 Released

+

GoCD Team

+

+

+
+ +
+

Today we released GoCD 14.3

+ +

You can download it from here. Take a look at release notes to see details.

+ +

This release saw lot of contributions from the community. A huge callout to the following contributors (not in any particular order) for their outstanding contributions :

+ +
+

@lcs777, @ciotlosm, @tusharm, @juniorz, @RikTyer, @mmb, @afoster , @sahilm, @gregoriomelo, @greenmoss , @dvarchev and Temmert.

+
+ +

(We have tried to be as accurate as possible. Sincere apologies if we missed mentioning anyone above)

+ +

We would also like to thank people who reported issues/feature requests and participated in various discussions. That list is too big to be mentioned here, but please know that all the time and energy spent by everyone in improvising GoCD is very much appreciated.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/11/Go_14_3_announced/index.html b/pr-1714/2014/11/11/Go_14_3_announced/index.html new file mode 100644 index 000000000..1171598a9 --- /dev/null +++ b/pr-1714/2014/11/11/Go_14_3_announced/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + Version 14.3 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.3 Released

+

GoCD Team

+

+

+
+ +
+

Today we released GoCD 14.3

+ +

You can download it from here. Take a look at release notes to see details.

+ +

This release saw lot of contributions from the community. A huge callout to the following contributors (not in any particular order) for their outstanding contributions :

+ +
+

@lcs777, @ciotlosm, @tusharm, @juniorz, @RikTyer, @mmb, @afoster , @sahilm, @gregoriomelo, @greenmoss , @dvarchev and Temmert.

+
+ +

(We have tried to be as accurate as possible. Sincere apologies if we missed mentioning anyone above)

+ +

We would also like to thank people who reported issues/feature requests and participated in various discussions. That list is too big to be mentioned here, but please know that all the time and energy spent by everyone in improvising GoCD is very much appreciated.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/11/index.html b/pr-1714/2014/11/11/index.html new file mode 100644 index 000000000..03e6a1564 --- /dev/null +++ b/pr-1714/2014/11/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 11 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/14.html b/pr-1714/2014/11/14.html new file mode 100644 index 000000000..a753693fd --- /dev/null +++ b/pr-1714/2014/11/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 14 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts.html b/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts.html new file mode 100644 index 000000000..ac18a36ca --- /dev/null +++ b/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + Issue with uploading compressed artifacts | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Update: Issue with uploading compressed artifacts in GoCD 14.3.0

+

GoCD Team

+

+

+
+ +
+

There was an issue reported with respect to artifact uploads in the 14.3.0 release of GoCD.

+ +

Issue

+

On GoCD server running with OpenJDK7, uploading compressed artifacts fails. The operation is reported as success in console-log on job details page but actual artifact does not get uploaded. Please note this does not affect uploading console-log itself or even a simple file as an artifact. This is an issue only with GoCD v14.3.0. Read further to know if you are affected by this defect.

+ +

Who does this affect?

+

This defect would affect you only if your GoCD Server v14.3.0 is run using OpenJDK(jdk or jre) and the agent responsible for artifact upload is using a version of java other than the one used by GoCD server.

+ +

You are unaffected by this defect if:

+ +
    +
  • +

    you use Sun/Oracle java to run GoCD Server

    +
    • +
  • +

    you have SunEC extension installed for your OpenJDK [EDIT: on your GoCD server]

    +
    • +
  • +

    Both your server and agent processes run using OpenJDK (not necessarily the same version) [EDIT: without ECC cipher suites. +As explained in "What caused this?" section, this issue occurs when java on agent supports ECC cipher suites but java on server doesnot. You should definitely run the litmus test to be sure.]

    +
    • +
+ +

Litmus test

+ +

You should run a pipeline which uploads a compressed file as an artifact to ensure you are not affected by this defect. If the artifact shows up on the artifacts tab of the job and can be successfully downloaded, you are safe from the defect.

+ +

Workaround

+

We are aware that you have been waiting to try your hands on the new APIs and several bug fixes that came out in 14.3.0. +Fortunately we have a few workarounds available to help you move ahead with the upgrade, meanwhile we would be working on finding the best possible fix for this issue. +You could go for one of the workarounds listed below:

+ +

Options:

+ +
    +
  • Install SunEC extension on your OpenJDK setup. Get sunec.jar and place it under jre/lib/ext/ folder. You must also place libsunec.so in jre/lib/amd64/ folder.
    • +
+ +

OR

+ +
    +
  • Install Oracle JRE on your GoCD server and switch to that. + For GoCD server running on Windows, this means updating the system level environment variable GO_SERVER_JAVA_HOME to oracle jre home + For Linux based installations, update /etc/default/go-server to set JAVA_HOME to oracle jre home. + For Others, set the value of system level environment variable JAVA_HOME to oracle jre home.
    • +
+ +

OR

+ +
    +
  • Install the same version of java as you have on your agent. Update java used by GoCD server to appropriate value as suggested in the previous option.
    • +
+ +

At this point restart GoCD Server. Trigger your affected pipeline to ensure the artifact got uploaded successfully. This should resolve the issue. +If the issue persists even after applying the suggested workaround, do write to the go-cd mailing list reporting the same.

+ +

What caused this?

+

I cannot speak about this without getting into some technical details.

+ +

As a part of upgrading to Rails v4, we also had to upgrade bouncycastle-bcprov library. Earlier versions of GoCD used bouncycastle-bcprov v1.40. With that the cipher suites accepted by GoCD server would always be one of SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5 or SSL_RSA_WITH_RC4_128_MD5. +GoCD 14.3.0 has moved on to use org.bouncycastle-bcprov v1.47. Bouncycastle v1.46 brought in support for ECC cipher suites. ECC cipher suites are made available by SunEC extension which is not packaged along with OpenJDK7 by default. +GoCD server is run using Jetty which uses bouncycastle crypto package (i.e. bcprov) for the handshake. At this point, instead of agreeing on the expected SSL & RSA based ciphers, one of the ECC ciphers get picked during the agent/server handshake. Jetty6 (yes, we are still using this!) does not work well with the modern cipher suites and causes issues like the one mentioned above. To tackle such scenarios, all supported ciphers suites apart from the three mentioned above are excluded from Jetty. Since, ECC cipher suites were not available on the server, they did not get excluded. However if your JVM has ECC ciphers available (by default or after applying one of the workarounds), GoCD would ensure they get excluded and make Jetty happy.

+ +

Jetty upgrade has been on the cards for a while, and that would possibly help resolve this. But that is a much involved task and hence works better as a long term solution. We need to evaluate other options as well which could fix the issue in the short term.

+ +

Many thanks to Vladimir Bormotov for reporting this issue and allowing us to use his setup to gather the required debug information.

+ +

As always, you could write to go-cd and go-cd-dev mailing lists if you have any ideas/feedback/questions.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/index.html b/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/index.html new file mode 100644 index 000000000..aeba2d8bc --- /dev/null +++ b/pr-1714/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/index.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + Issue with uploading compressed artifacts | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Update: Issue with uploading compressed artifacts in GoCD 14.3.0

+

GoCD Team

+

+

+
+ +
+

There was an issue reported with respect to artifact uploads in the 14.3.0 release of GoCD.

+ +

Issue

+

On GoCD server running with OpenJDK7, uploading compressed artifacts fails. The operation is reported as success in console-log on job details page but actual artifact does not get uploaded. Please note this does not affect uploading console-log itself or even a simple file as an artifact. This is an issue only with GoCD v14.3.0. Read further to know if you are affected by this defect.

+ +

Who does this affect?

+

This defect would affect you only if your GoCD Server v14.3.0 is run using OpenJDK(jdk or jre) and the agent responsible for artifact upload is using a version of java other than the one used by GoCD server.

+ +

You are unaffected by this defect if:

+ +
    +
  • +

    you use Sun/Oracle java to run GoCD Server

    +
    • +
  • +

    you have SunEC extension installed for your OpenJDK [EDIT: on your GoCD server]

    +
    • +
  • +

    Both your server and agent processes run using OpenJDK (not necessarily the same version) [EDIT: without ECC cipher suites. +As explained in "What caused this?" section, this issue occurs when java on agent supports ECC cipher suites but java on server doesnot. You should definitely run the litmus test to be sure.]

    +
    • +
+ +

Litmus test

+ +

You should run a pipeline which uploads a compressed file as an artifact to ensure you are not affected by this defect. If the artifact shows up on the artifacts tab of the job and can be successfully downloaded, you are safe from the defect.

+ +

Workaround

+

We are aware that you have been waiting to try your hands on the new APIs and several bug fixes that came out in 14.3.0. +Fortunately we have a few workarounds available to help you move ahead with the upgrade, meanwhile we would be working on finding the best possible fix for this issue. +You could go for one of the workarounds listed below:

+ +

Options:

+ +
    +
  • Install SunEC extension on your OpenJDK setup. Get sunec.jar and place it under jre/lib/ext/ folder. You must also place libsunec.so in jre/lib/amd64/ folder.
    • +
+ +

OR

+ +
    +
  • Install Oracle JRE on your GoCD server and switch to that. + For GoCD server running on Windows, this means updating the system level environment variable GO_SERVER_JAVA_HOME to oracle jre home + For Linux based installations, update /etc/default/go-server to set JAVA_HOME to oracle jre home. + For Others, set the value of system level environment variable JAVA_HOME to oracle jre home.
    • +
+ +

OR

+ +
    +
  • Install the same version of java as you have on your agent. Update java used by GoCD server to appropriate value as suggested in the previous option.
    • +
+ +

At this point restart GoCD Server. Trigger your affected pipeline to ensure the artifact got uploaded successfully. This should resolve the issue. +If the issue persists even after applying the suggested workaround, do write to the go-cd mailing list reporting the same.

+ +

What caused this?

+

I cannot speak about this without getting into some technical details.

+ +

As a part of upgrading to Rails v4, we also had to upgrade bouncycastle-bcprov library. Earlier versions of GoCD used bouncycastle-bcprov v1.40. With that the cipher suites accepted by GoCD server would always be one of SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5 or SSL_RSA_WITH_RC4_128_MD5. +GoCD 14.3.0 has moved on to use org.bouncycastle-bcprov v1.47. Bouncycastle v1.46 brought in support for ECC cipher suites. ECC cipher suites are made available by SunEC extension which is not packaged along with OpenJDK7 by default. +GoCD server is run using Jetty which uses bouncycastle crypto package (i.e. bcprov) for the handshake. At this point, instead of agreeing on the expected SSL & RSA based ciphers, one of the ECC ciphers get picked during the agent/server handshake. Jetty6 (yes, we are still using this!) does not work well with the modern cipher suites and causes issues like the one mentioned above. To tackle such scenarios, all supported ciphers suites apart from the three mentioned above are excluded from Jetty. Since, ECC cipher suites were not available on the server, they did not get excluded. However if your JVM has ECC ciphers available (by default or after applying one of the workarounds), GoCD would ensure they get excluded and make Jetty happy.

+ +

Jetty upgrade has been on the cards for a while, and that would possibly help resolve this. But that is a much involved task and hence works better as a long term solution. We need to evaluate other options as well which could fix the issue in the short term.

+ +

Many thanks to Vladimir Bormotov for reporting this issue and allowing us to use his setup to gather the required debug information.

+ +

As always, you could write to go-cd and go-cd-dev mailing lists if you have any ideas/feedback/questions.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/14/index.html b/pr-1714/2014/11/14/index.html new file mode 100644 index 000000000..3f74408f4 --- /dev/null +++ b/pr-1714/2014/11/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 14 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/21.html b/pr-1714/2014/11/21.html new file mode 100644 index 000000000..5aff13983 --- /dev/null +++ b/pr-1714/2014/11/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 21 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/21/go-webinar-recording.html b/pr-1714/2014/11/21/go-webinar-recording.html new file mode 100644 index 000000000..40fcd95f0 --- /dev/null +++ b/pr-1714/2014/11/21/go-webinar-recording.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with Go. This is a recording of the session from 21 November, 2014.

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/21/go-webinar-recording/index.html b/pr-1714/2014/11/21/go-webinar-recording/index.html new file mode 100644 index 000000000..d858cd8e2 --- /dev/null +++ b/pr-1714/2014/11/21/go-webinar-recording/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with Go. This is a recording of the session from 21 November, 2014.

+ + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/21/index.html b/pr-1714/2014/11/21/index.html new file mode 100644 index 000000000..5ad9185e1 --- /dev/null +++ b/pr-1714/2014/11/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 21 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/11/index.html b/pr-1714/2014/11/index.html new file mode 100644 index 000000000..c28bc8c11 --- /dev/null +++ b/pr-1714/2014/11/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12.html b/pr-1714/2014/12.html new file mode 100644 index 000000000..a555becda --- /dev/null +++ b/pr-1714/2014/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12/17.html b/pr-1714/2014/12/17.html new file mode 100644 index 000000000..fbe91746d --- /dev/null +++ b/pr-1714/2014/12/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 17 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12/17/Go_14_4_announced.html b/pr-1714/2014/12/17/Go_14_4_announced.html new file mode 100644 index 000000000..11684baeb --- /dev/null +++ b/pr-1714/2014/12/17/Go_14_4_announced.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + Version 14.4 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.4 Released

+

GoCD Team

+

+

+
+ +
+

Today we released GoCD 14.4

+ +

You can download it from here. Take a look at release notes to see details.

+ +

Sincere thanks to everyone who contributed to GoCD in form of features, ideas, issues / feature requests and much more! A special mention goes to @mythgarr, @hammerdr and to the Pivotal team: @mmb, @gajwani , @fkotsian, @bsnchan for their active contributions and support.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12/17/Go_14_4_announced/index.html b/pr-1714/2014/12/17/Go_14_4_announced/index.html new file mode 100644 index 000000000..4a51dd05b --- /dev/null +++ b/pr-1714/2014/12/17/Go_14_4_announced/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + Version 14.4 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 14.4 Released

+

GoCD Team

+

+

+
+ +
+

Today we released GoCD 14.4

+ +

You can download it from here. Take a look at release notes to see details.

+ +

Sincere thanks to everyone who contributed to GoCD in form of features, ideas, issues / feature requests and much more! A special mention goes to @mythgarr, @hammerdr and to the Pivotal team: @mmb, @gajwani , @fkotsian, @bsnchan for their active contributions and support.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12/17/index.html b/pr-1714/2014/12/17/index.html new file mode 100644 index 000000000..1d5f8ea41 --- /dev/null +++ b/pr-1714/2014/12/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 17 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/12/index.html b/pr-1714/2014/12/index.html new file mode 100644 index 000000000..76565c832 --- /dev/null +++ b/pr-1714/2014/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/index.html b/pr-1714/2014/index.html new file mode 100644 index 000000000..e95c59cee --- /dev/null +++ b/pr-1714/2014/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/page/2.html b/pr-1714/2014/page/2.html new file mode 100644 index 000000000..f577290be --- /dev/null +++ b/pr-1714/2014/page/2.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 2 of 3

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/page/2/index.html b/pr-1714/2014/page/2/index.html new file mode 100644 index 000000000..03d4ec37c --- /dev/null +++ b/pr-1714/2014/page/2/index.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 2 of 3

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/page/3.html b/pr-1714/2014/page/3.html new file mode 100644 index 000000000..95ec816d3 --- /dev/null +++ b/pr-1714/2014/page/3.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2014/page/3/index.html b/pr-1714/2014/page/3/index.html new file mode 100644 index 000000000..5312ec0f3 --- /dev/null +++ b/pr-1714/2014/page/3/index.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015.html b/pr-1714/2015.html new file mode 100644 index 000000000..be7092e33 --- /dev/null +++ b/pr-1714/2015.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04.html b/pr-1714/2015/04.html new file mode 100644 index 000000000..15eaa3a4d --- /dev/null +++ b/pr-1714/2015/04.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/23.html b/pr-1714/2015/04/23.html new file mode 100644 index 000000000..9b0b39d1a --- /dev/null +++ b/pr-1714/2015/04/23.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/23/Go_15_1_jdk7_announcement.html b/pr-1714/2015/04/23/Go_15_1_jdk7_announcement.html new file mode 100644 index 000000000..9b8149439 --- /dev/null +++ b/pr-1714/2015/04/23/Go_15_1_jdk7_announcement.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + Upgrade your Java JDK to 7+ | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

For GoCD 15.1 upgrade your Java/JDK to 7+

+

GoCD Team

+

+

+
+ +
+

GoCD has stopped support JDK 6 for some time now. But we understand that some users were using Java 6, so we continued to support it as long as we could while helping users migrate their GoCD servers and agents to Java 7.

+ +

Java 6 was declared end-of-life in February 2013, and Java 7 is scheduled to be declared end-of-life soon.

+ +

Starting with the 15.1 release of GoCD, it will only run with Java 7. Users are encouraged to upgrade to the latest release of GoCD with Java 8.

+ +

Starting with the next release, we plan on providing support for Java 8.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/23/Go_15_1_jdk7_announcement/index.html b/pr-1714/2015/04/23/Go_15_1_jdk7_announcement/index.html new file mode 100644 index 000000000..cd5ecf184 --- /dev/null +++ b/pr-1714/2015/04/23/Go_15_1_jdk7_announcement/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + + + Upgrade your Java JDK to 7+ | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

For GoCD 15.1 upgrade your Java/JDK to 7+

+

GoCD Team

+

+

+
+ +
+

GoCD has stopped support JDK 6 for some time now. But we understand that some users were using Java 6, so we continued to support it as long as we could while helping users migrate their GoCD servers and agents to Java 7.

+ +

Java 6 was declared end-of-life in February 2013, and Java 7 is scheduled to be declared end-of-life soon.

+ +

Starting with the 15.1 release of GoCD, it will only run with Java 7. Users are encouraged to upgrade to the latest release of GoCD with Java 8.

+ +

Starting with the next release, we plan on providing support for Java 8.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/23/index.html b/pr-1714/2015/04/23/index.html new file mode 100644 index 000000000..126902ed4 --- /dev/null +++ b/pr-1714/2015/04/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/27.html b/pr-1714/2015/04/27.html new file mode 100644 index 000000000..9ec2f3e7e --- /dev/null +++ b/pr-1714/2015/04/27.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 27 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/27/Feature-Branch-Support.html b/pr-1714/2015/04/27/Feature-Branch-Support.html new file mode 100644 index 000000000..f00534737 --- /dev/null +++ b/pr-1714/2015/04/27/Feature-Branch-Support.html @@ -0,0 +1,514 @@ + + + + + + + + + + + + + + + + Feature Branch Support | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Feature Branch Support

+

GoCD Team

+

+

+
+ +
+

GoCD 15.1 introduced support for writing material repository plugins, to extend the kind of source code material +repositories that GoCD works with. This resulted in community-driven plugins developed for GoCD, to implement support for +feature branches, with help from members of GoCD's core contributors. This blog post has information specifically about +GitHub Pull Request support.

+ +

Note: In this post, the terms Branch and Pull Request are used interchangeably, since a Pull Request is +essentially just a branch.

+ +

As codebases grow and teams start writing more tests, they often hit upon a challenging problem. If they have setup +their build, test and deploy pipelines as a normal team or teams working with trunk-based development would have, then +increasing the number of tests they have results in a longer time to certify a build and deploy to production.

+ +

Here is an example of a Value Stream Map from GoCD itself: See https://build.go.cd (Username: view, Password: password) itself, +where running all the tests and generating installers can take hours:

+ +
+ GoCD - Value Stream Map +
Figure 1: GoCD - Value Stream Map (Click to enlarge)
+
+ +

Due to this, it becomes critical to keep the main Value Stream green all the time. A failed build would mean all other +commits ready to go in have to wait until the failed build is fixed:

+ +
+ Failed build stops everything +
Figure 2: Failed build stops everything (Click to enlarge)
+
+ +
+ +

The root of this problem is a slow build, and sometimes that can be tackled directly. However, with the advent of +short-lived feature branches (aka, Pull Requests in GitHub land), this problem can become worse. Since feature +branches are not regularly verified before merging, merging them could itself be a little risky, and could cause the +build to fail un-necessarily.

+ +

In general, development workflows in organizations has moved to something which looks like:

+ +
Pull Request (GitHub, Gerrit etc.) / Feature Branch => Code Review => Merge => Build
+
+ +

Now, whether a feature branch based workflow is the best approach or not is hotly debated (see Martin Fowler's +article on this). Organizations who follow a feature branch based +workflow have been wanting support for it in GoCD. Historically, GoCD has advocated against feature +branches and support for it has been limited. GoCD users have come up with some innovative workarounds, like this one from Vision +Critical.

+ +

Though the GoCD core contribution team continues to be wary of long-lived feature branches, short-lived feature branches +create a window for validating changes before they are merged into the main branch. Since the majority of time spent in +a CI/CD setup tends to be in running tests, and failed builds are typically due to test failures, you could run tests on +a proposed change in a feature branch, get feedback about it and fix tests if needed, before merging it into the trunk. +Though this does not always catch integration issues (that depends on what else was merged before this one was), it +allows you to increase the chances of your main Value Stream staying green and in a deployable state for longer.

+ +

A problem with this approach though, is that every change will be tested twice (once on the feature branch and once on +the main branch after the merge) which means the effective time for a commit to reach production could be more, unless +you have more hardware (agents) to run branch builds.

+ +

The way forward

+ +

Assuming you have chosen the approach mentioned above, you can now use GoCD 15.1, with its two new extension points - SCM +end-point and the Notification +end-point, to test feature +branches before they are merged.

+ +

To use this with GitHub requires the use of two community-driven and community-supported plugins: Git Branch Poller +Plugin and the Build Status Notification +Plugin. The first one is an SCM Material plugin, and is +responsible for polling a configured repository for changes, while the second one is a Notification plugin, which is +responsible for notifying GitHub about the suitability of a Pull Request for merging.

+ +

Note: Even though this post specifically mentions GitHub only, plugins have been written to work with plain Git, +Atlassian Stash, Gerrit and more! See the GoCD community plugins +page for more information.

+ +

Quick Setup

+ + + +
+ Verify Plugins +
Figure 3: Verify Plugins (Click to enlarge)
+
+ +
    +
  • +

    Decide which parts of the value stream you want the Pull Requests to run till, and extract a template for those +pipelines, so that you can have a parallel set of pipelines to run against Pull Requests. The need to create a +separate set of pipelines is to make sure that the main build and the branch build never get interleaved, and a branch +build never gets deployed into production, by mistake.

    + +

    Your decision should be based on how much of your tests can reasonably be run for every Pull Request, and how far down + the Value Stream can a build containing those changes GoCD. For some, every test in the system needs to run before it is + deemed merge-able and for some, only unit and integration tests might be enough. It depends.

    + +

    Suppose you have a setup of three pipelines like this:

    + +
    + Example setup of 3 pipelines +
    Figure 4: Example setup (Click to enlarge)
    +
    + +

    and you decide that you want the first two pipelines to run for every Pull Request, you need to change your pipelines + to look like this:

    + +
    + Extract templates, create pipelines for PR +
    Figure 5: Extract templates, create pipelines for PR (Click to enlarge)
    +
    + +

    Based on your decision, extract templates and create the new pipelines:

    + +
    + Extract template +
    Figure 6: Extract template (Click to enlarge)
    +
    +
    • +
  • +

    In the new pipeline or pipelines that have been setup to run for every Pull Request, change the Git material to use +the GitHub material (this material is provided by the GitHub poller plugin installed earlier):

    + +
    + Add GitHub material +
    Figure 7: Add GitHub material (Click to enlarge)
    +
    + +
    + Add GitHub material - Details +
    Figure 8: Add GitHub material - Details (Click to enlarge)
    +
    + +

    Once you have setup the GitHub material for the pipeline, you can remove the Git material from that pipeline.

    +
    • +
+ +

That's it.

+ +

Results

+ +
    +
  • +

    GoCD will trigger builds for every new Pull Request and for new commits to existing Pull Requests:

    + +
    + PR triggers build +
    Figure 9: PR triggers build (Click to enlarge)
    +
    +
    • +
  • +

    GoCD will update Pull Request in GitHub with the build status:

    + +
    + GitHub PR page gets updated +
    Figure 10: GitHub PR page gets updated (Click to enlarge)
    +
    + +
    + GitHub PR listing page gets updated +
    Figure 11: GitHub PR listing page gets updated (Click to enlarge)
    +
    +
    • +
  • +

    Fan-in and Value Stream Map work as expected:

    + +
    + Fan-in and VSM work +
    Figure 12: Fan-in and VSM work (Click to enlarge)
    +
    +
    • +
+ +

Shortcomings and known issues:

+ +
    +
  • +

    If multiple branches are updated at once, the plugin provides all of them as changes and GoCD will not run the pipeline +for every change separately. GoCD currently combines multiple changes into a single pipeline run (to save time). A +feature allowing "force trigger pipeline for each change" should be able to +overcome this. This has not yet been accepted into the main GoCD codebase.

    +
    • +
  • +

    If there are multiple commits in a branch, the plugin only returns the top commit as a change. Hence only one change +shows up in the dashboard, value stream, etc. Also, since GoCD does not know about the other changes you will not be +able to manually trigger a pipeline with the other commits.

    +
    • +
  • +

    The UI is lacking in certain areas: For instance, it is not possible to add an SCM plugin material during pipeline +creation, to associate an existing SCM to a pipeline you will need to edit Config XML etc. These +will be fixed in upcoming releases.

    +
    • +
+ +

References

+ +

Some discussions on the GoCD mailing lists and on GitHub about this:

+ + + +

Sample Configuration

+ +

Here is a part of the configuration used to create the images shown above:

+ +
<scms>
+  <scm id="b7386c23-71d5-4581-8129-bba5b67638e4" name="sample-repo">
+    <pluginConfiguration id="github.pr" version="1" />
+    <configuration>
+      <property>
+        <key>url</key>
+        <value>https://github.com/srinivasupadhya/sample-repo.git</value>
+      </property>
+    </configuration>
+  </scm>
+</scms>
+<pipelines group="sample-group-master">
+  <pipeline name="sample-pipeline-master" template="sample-pipeline">
+    <materials>
+      <git url="https://github.com/srinivasupadhya/sample-repo.git" dest="sample-repo" materialName="sample-repo" />
+    </materials>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline-master" template="sample-downstream-pipeline">
+    <materials>
+      <pipeline pipelineName="sample-pipeline-master" stageName="sample-stage-2" />
+    </materials>
+  </pipeline>
+</pipelines>
+<pipelines group="sample-group-PR">
+  <pipeline name="sample-pipeline-PR" template="sample-pipeline">
+    <materials>
+      <scm ref="b7386c23-71d5-4581-8129-bba5b67638e4" dest="sample-repo" />
+    </materials>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline-PR" template="sample-downstream-pipeline">
+    <materials>
+      <pipeline pipelineName="sample-pipeline-PR" stageName="sample-stage-2" />
+    </materials>
+  </pipeline>
+</pipelines>
+<templates>
+  <pipeline name="sample-pipeline">
+    <stage name="sample-stage-1">
+      <jobs>
+        <job name="sample-job-1">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+    <stage name="sample-stage-2">
+      <jobs>
+        <job name="sample-job-2">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline">
+    <stage name="sample-stage-3">
+      <jobs>
+        <job name="sample-job-3">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+  </pipeline>
+</templates>
+
+ + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/27/Feature-Branch-Support/index.html b/pr-1714/2015/04/27/Feature-Branch-Support/index.html new file mode 100644 index 000000000..9c34c4a6e --- /dev/null +++ b/pr-1714/2015/04/27/Feature-Branch-Support/index.html @@ -0,0 +1,514 @@ + + + + + + + + + + + + + + + + Feature Branch Support | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Feature Branch Support

+

GoCD Team

+

+

+
+ +
+

GoCD 15.1 introduced support for writing material repository plugins, to extend the kind of source code material +repositories that GoCD works with. This resulted in community-driven plugins developed for GoCD, to implement support for +feature branches, with help from members of GoCD's core contributors. This blog post has information specifically about +GitHub Pull Request support.

+ +

Note: In this post, the terms Branch and Pull Request are used interchangeably, since a Pull Request is +essentially just a branch.

+ +

As codebases grow and teams start writing more tests, they often hit upon a challenging problem. If they have setup +their build, test and deploy pipelines as a normal team or teams working with trunk-based development would have, then +increasing the number of tests they have results in a longer time to certify a build and deploy to production.

+ +

Here is an example of a Value Stream Map from GoCD itself: See https://build.go.cd (Username: view, Password: password) itself, +where running all the tests and generating installers can take hours:

+ +
+ GoCD - Value Stream Map +
Figure 1: GoCD - Value Stream Map (Click to enlarge)
+
+ +

Due to this, it becomes critical to keep the main Value Stream green all the time. A failed build would mean all other +commits ready to go in have to wait until the failed build is fixed:

+ +
+ Failed build stops everything +
Figure 2: Failed build stops everything (Click to enlarge)
+
+ +
+ +

The root of this problem is a slow build, and sometimes that can be tackled directly. However, with the advent of +short-lived feature branches (aka, Pull Requests in GitHub land), this problem can become worse. Since feature +branches are not regularly verified before merging, merging them could itself be a little risky, and could cause the +build to fail un-necessarily.

+ +

In general, development workflows in organizations has moved to something which looks like:

+ +
Pull Request (GitHub, Gerrit etc.) / Feature Branch => Code Review => Merge => Build
+
+ +

Now, whether a feature branch based workflow is the best approach or not is hotly debated (see Martin Fowler's +article on this). Organizations who follow a feature branch based +workflow have been wanting support for it in GoCD. Historically, GoCD has advocated against feature +branches and support for it has been limited. GoCD users have come up with some innovative workarounds, like this one from Vision +Critical.

+ +

Though the GoCD core contribution team continues to be wary of long-lived feature branches, short-lived feature branches +create a window for validating changes before they are merged into the main branch. Since the majority of time spent in +a CI/CD setup tends to be in running tests, and failed builds are typically due to test failures, you could run tests on +a proposed change in a feature branch, get feedback about it and fix tests if needed, before merging it into the trunk. +Though this does not always catch integration issues (that depends on what else was merged before this one was), it +allows you to increase the chances of your main Value Stream staying green and in a deployable state for longer.

+ +

A problem with this approach though, is that every change will be tested twice (once on the feature branch and once on +the main branch after the merge) which means the effective time for a commit to reach production could be more, unless +you have more hardware (agents) to run branch builds.

+ +

The way forward

+ +

Assuming you have chosen the approach mentioned above, you can now use GoCD 15.1, with its two new extension points - SCM +end-point and the Notification +end-point, to test feature +branches before they are merged.

+ +

To use this with GitHub requires the use of two community-driven and community-supported plugins: Git Branch Poller +Plugin and the Build Status Notification +Plugin. The first one is an SCM Material plugin, and is +responsible for polling a configured repository for changes, while the second one is a Notification plugin, which is +responsible for notifying GitHub about the suitability of a Pull Request for merging.

+ +

Note: Even though this post specifically mentions GitHub only, plugins have been written to work with plain Git, +Atlassian Stash, Gerrit and more! See the GoCD community plugins +page for more information.

+ +

Quick Setup

+ + + +
+ Verify Plugins +
Figure 3: Verify Plugins (Click to enlarge)
+
+ +
    +
  • +

    Decide which parts of the value stream you want the Pull Requests to run till, and extract a template for those +pipelines, so that you can have a parallel set of pipelines to run against Pull Requests. The need to create a +separate set of pipelines is to make sure that the main build and the branch build never get interleaved, and a branch +build never gets deployed into production, by mistake.

    + +

    Your decision should be based on how much of your tests can reasonably be run for every Pull Request, and how far down + the Value Stream can a build containing those changes GoCD. For some, every test in the system needs to run before it is + deemed merge-able and for some, only unit and integration tests might be enough. It depends.

    + +

    Suppose you have a setup of three pipelines like this:

    + +
    + Example setup of 3 pipelines +
    Figure 4: Example setup (Click to enlarge)
    +
    + +

    and you decide that you want the first two pipelines to run for every Pull Request, you need to change your pipelines + to look like this:

    + +
    + Extract templates, create pipelines for PR +
    Figure 5: Extract templates, create pipelines for PR (Click to enlarge)
    +
    + +

    Based on your decision, extract templates and create the new pipelines:

    + +
    + Extract template +
    Figure 6: Extract template (Click to enlarge)
    +
    +
    • +
  • +

    In the new pipeline or pipelines that have been setup to run for every Pull Request, change the Git material to use +the GitHub material (this material is provided by the GitHub poller plugin installed earlier):

    + +
    + Add GitHub material +
    Figure 7: Add GitHub material (Click to enlarge)
    +
    + +
    + Add GitHub material - Details +
    Figure 8: Add GitHub material - Details (Click to enlarge)
    +
    + +

    Once you have setup the GitHub material for the pipeline, you can remove the Git material from that pipeline.

    +
    • +
+ +

That's it.

+ +

Results

+ +
    +
  • +

    GoCD will trigger builds for every new Pull Request and for new commits to existing Pull Requests:

    + +
    + PR triggers build +
    Figure 9: PR triggers build (Click to enlarge)
    +
    +
    • +
  • +

    GoCD will update Pull Request in GitHub with the build status:

    + +
    + GitHub PR page gets updated +
    Figure 10: GitHub PR page gets updated (Click to enlarge)
    +
    + +
    + GitHub PR listing page gets updated +
    Figure 11: GitHub PR listing page gets updated (Click to enlarge)
    +
    +
    • +
  • +

    Fan-in and Value Stream Map work as expected:

    + +
    + Fan-in and VSM work +
    Figure 12: Fan-in and VSM work (Click to enlarge)
    +
    +
    • +
+ +

Shortcomings and known issues:

+ +
    +
  • +

    If multiple branches are updated at once, the plugin provides all of them as changes and GoCD will not run the pipeline +for every change separately. GoCD currently combines multiple changes into a single pipeline run (to save time). A +feature allowing "force trigger pipeline for each change" should be able to +overcome this. This has not yet been accepted into the main GoCD codebase.

    +
    • +
  • +

    If there are multiple commits in a branch, the plugin only returns the top commit as a change. Hence only one change +shows up in the dashboard, value stream, etc. Also, since GoCD does not know about the other changes you will not be +able to manually trigger a pipeline with the other commits.

    +
    • +
  • +

    The UI is lacking in certain areas: For instance, it is not possible to add an SCM plugin material during pipeline +creation, to associate an existing SCM to a pipeline you will need to edit Config XML etc. These +will be fixed in upcoming releases.

    +
    • +
+ +

References

+ +

Some discussions on the GoCD mailing lists and on GitHub about this:

+ + + +

Sample Configuration

+ +

Here is a part of the configuration used to create the images shown above:

+ +
<scms>
+  <scm id="b7386c23-71d5-4581-8129-bba5b67638e4" name="sample-repo">
+    <pluginConfiguration id="github.pr" version="1" />
+    <configuration>
+      <property>
+        <key>url</key>
+        <value>https://github.com/srinivasupadhya/sample-repo.git</value>
+      </property>
+    </configuration>
+  </scm>
+</scms>
+<pipelines group="sample-group-master">
+  <pipeline name="sample-pipeline-master" template="sample-pipeline">
+    <materials>
+      <git url="https://github.com/srinivasupadhya/sample-repo.git" dest="sample-repo" materialName="sample-repo" />
+    </materials>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline-master" template="sample-downstream-pipeline">
+    <materials>
+      <pipeline pipelineName="sample-pipeline-master" stageName="sample-stage-2" />
+    </materials>
+  </pipeline>
+</pipelines>
+<pipelines group="sample-group-PR">
+  <pipeline name="sample-pipeline-PR" template="sample-pipeline">
+    <materials>
+      <scm ref="b7386c23-71d5-4581-8129-bba5b67638e4" dest="sample-repo" />
+    </materials>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline-PR" template="sample-downstream-pipeline">
+    <materials>
+      <pipeline pipelineName="sample-pipeline-PR" stageName="sample-stage-2" />
+    </materials>
+  </pipeline>
+</pipelines>
+<templates>
+  <pipeline name="sample-pipeline">
+    <stage name="sample-stage-1">
+      <jobs>
+        <job name="sample-job-1">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+    <stage name="sample-stage-2">
+      <jobs>
+        <job name="sample-job-2">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+  </pipeline>
+  <pipeline name="sample-downstream-pipeline">
+    <stage name="sample-stage-3">
+      <jobs>
+        <job name="sample-job-3">
+          <tasks>
+            <exec command="ls" />
+          </tasks>
+        </job>
+      </jobs>
+    </stage>
+  </pipeline>
+</templates>
+
+ + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/27/index.html b/pr-1714/2015/04/27/index.html new file mode 100644 index 000000000..f3fa31f7e --- /dev/null +++ b/pr-1714/2015/04/27/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 27 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/29.html b/pr-1714/2015/04/29.html new file mode 100644 index 000000000..a21eded6f --- /dev/null +++ b/pr-1714/2015/04/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/29/Go_15_1_announced.html b/pr-1714/2015/04/29/Go_15_1_announced.html new file mode 100644 index 000000000..bd87bc3a3 --- /dev/null +++ b/pr-1714/2015/04/29/Go_15_1_announced.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Version 15.1.0 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 15.1.0 Released

+

GoCD Team

+

+

+
+ +
+

We would like to announce a new release of gocd. Head over to our downloads page to get your hands on the latest and greatest. Read more about what's new in this release from our release notes.

+ +

Sincere thanks to everyone who contributed to GoCD in form of features, ideas, issues / feature requests and much more! A special mention goes to @ashwanthkumar, @alexschwartz, @sachinsudheendra, @pwen, @pamo, @bernardn, @danielsomerfield, @iliasbartolini for their active contributions and support.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/29/Go_15_1_announced/index.html b/pr-1714/2015/04/29/Go_15_1_announced/index.html new file mode 100644 index 000000000..eea9fc94b --- /dev/null +++ b/pr-1714/2015/04/29/Go_15_1_announced/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Version 15.1.0 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 15.1.0 Released

+

GoCD Team

+

+

+
+ +
+

We would like to announce a new release of gocd. Head over to our downloads page to get your hands on the latest and greatest. Read more about what's new in this release from our release notes.

+ +

Sincere thanks to everyone who contributed to GoCD in form of features, ideas, issues / feature requests and much more! A special mention goes to @ashwanthkumar, @alexschwartz, @sachinsudheendra, @pwen, @pamo, @bernardn, @danielsomerfield, @iliasbartolini for their active contributions and support.

+ +

Thanks once again!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/29/index.html b/pr-1714/2015/04/29/index.html new file mode 100644 index 000000000..f7446e47d --- /dev/null +++ b/pr-1714/2015/04/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/04/index.html b/pr-1714/2015/04/index.html new file mode 100644 index 000000000..120763957 --- /dev/null +++ b/pr-1714/2015/04/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05.html b/pr-1714/2015/05.html new file mode 100644 index 000000000..912e8c7c2 --- /dev/null +++ b/pr-1714/2015/05.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/06.html b/pr-1714/2015/05/06.html new file mode 100644 index 000000000..e47788399 --- /dev/null +++ b/pr-1714/2015/05/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 6 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/06/Getting-Started-Resources.html b/pr-1714/2015/05/06/Getting-Started-Resources.html new file mode 100644 index 000000000..0ecfd42b8 --- /dev/null +++ b/pr-1714/2015/05/06/Getting-Started-Resources.html @@ -0,0 +1,239 @@ + + + + + + + + + + + + + + + + Getting Started | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Get Started Using GoCD

+

Ken Mugrage

+

+

+
+ +
+

If you've never setup GoCD or used it at all, you should definitely start from our Help page, to get you started.

+ +

GoCD User Documentation

+ +

There are a couple sections of the user documentation that can be especially helpful to people new to GoCD.

+ +
    +
  • Setting up a new Pipeline - See how to set up your first pipeline
    • +
  • Concepts in GoCD - This covers some of the basic concepts used in GoCD. A good understanding of what Pipelines, Stages, Jobs and Tasks are will be very helpful.
    • +
  • Managing Agents - The GoCD server produces the user interface for GoCD, but it doesn't actually run your jobs. Learn how to use GoCD Agents to "do the work".
    • +
+ +

Community

+ +
    +
  • The GoCD mailing list - A great place to search for answers to questions you may have, or of course ask them if they aren't already covered.
    • +
+ +

Live Demonstrations

+ +
    +
  • Webinars - Thoughtworks presents live webinars every two weeks so that you can see GoCD in action. There are also recordings of previous webinars on our blog.
    • +
+ +

Professional Support

+ +
    +
  • Thoughtworks - The first 30 days of professional support +provided by Thoughtworks is free. You'll get access to a global support team, and tough issues can be escalated directly to the GoCD development team.
    • +
+ +

Alternative Installation

+ +
    +
  • +

    Docker Container - This is an easy way to see what GoCD does. As it +says in the description, this is not a production container. You'll also need at least one instance of the agent container

    +
    • +
  • +

    Chef Partner Cookbook - You can get started on GoCD with your Chef configurations quickly with our official partner cookbook. This cookbook will help you setup Go servers and agents in a fully automated way.

    +
    • +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/06/Getting-Started-Resources/index.html b/pr-1714/2015/05/06/Getting-Started-Resources/index.html new file mode 100644 index 000000000..b8014d955 --- /dev/null +++ b/pr-1714/2015/05/06/Getting-Started-Resources/index.html @@ -0,0 +1,239 @@ + + + + + + + + + + + + + + + + Getting Started | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Get Started Using GoCD

+

Ken Mugrage

+

+

+
+ +
+

If you've never setup GoCD or used it at all, you should definitely start from our Help page, to get you started.

+ +

GoCD User Documentation

+ +

There are a couple sections of the user documentation that can be especially helpful to people new to GoCD.

+ +
    +
  • Setting up a new Pipeline - See how to set up your first pipeline
    • +
  • Concepts in GoCD - This covers some of the basic concepts used in GoCD. A good understanding of what Pipelines, Stages, Jobs and Tasks are will be very helpful.
    • +
  • Managing Agents - The GoCD server produces the user interface for GoCD, but it doesn't actually run your jobs. Learn how to use GoCD Agents to "do the work".
    • +
+ +

Community

+ +
    +
  • The GoCD mailing list - A great place to search for answers to questions you may have, or of course ask them if they aren't already covered.
    • +
+ +

Live Demonstrations

+ +
    +
  • Webinars - Thoughtworks presents live webinars every two weeks so that you can see GoCD in action. There are also recordings of previous webinars on our blog.
    • +
+ +

Professional Support

+ +
    +
  • Thoughtworks - The first 30 days of professional support +provided by Thoughtworks is free. You'll get access to a global support team, and tough issues can be escalated directly to the GoCD development team.
    • +
+ +

Alternative Installation

+ +
    +
  • +

    Docker Container - This is an easy way to see what GoCD does. As it +says in the description, this is not a production container. You'll also need at least one instance of the agent container

    +
    • +
  • +

    Chef Partner Cookbook - You can get started on GoCD with your Chef configurations quickly with our official partner cookbook. This cookbook will help you setup Go servers and agents in a fully automated way.

    +
    • +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/06/index.html b/pr-1714/2015/05/06/index.html new file mode 100644 index 000000000..bcc41f72b --- /dev/null +++ b/pr-1714/2015/05/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 6 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/07.html b/pr-1714/2015/05/07.html new file mode 100644 index 000000000..b05affaa7 --- /dev/null +++ b/pr-1714/2015/05/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/07/go-webinar-recording.html b/pr-1714/2015/05/07/go-webinar-recording.html new file mode 100644 index 000000000..32ac03480 --- /dev/null +++ b/pr-1714/2015/05/07/go-webinar-recording.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 7 May, 2015

+ + + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/07/go-webinar-recording/index.html b/pr-1714/2015/05/07/go-webinar-recording/index.html new file mode 100644 index 000000000..f8b35b4db --- /dev/null +++ b/pr-1714/2015/05/07/go-webinar-recording/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 7 May, 2015

+ + + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/07/index.html b/pr-1714/2015/05/07/index.html new file mode 100644 index 000000000..ab38c331e --- /dev/null +++ b/pr-1714/2015/05/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/05/index.html b/pr-1714/2015/05/index.html new file mode 100644 index 000000000..511d1ff90 --- /dev/null +++ b/pr-1714/2015/05/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06.html b/pr-1714/2015/06.html new file mode 100644 index 000000000..b041b001d --- /dev/null +++ b/pr-1714/2015/06.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/13.html b/pr-1714/2015/06/13.html new file mode 100644 index 000000000..b98be8506 --- /dev/null +++ b/pr-1714/2015/06/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 13 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/13/index.html b/pr-1714/2015/06/13/index.html new file mode 100644 index 000000000..c01a6957f --- /dev/null +++ b/pr-1714/2015/06/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 13 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/13/using-windows-powershell-tasks.html b/pr-1714/2015/06/13/using-windows-powershell-tasks.html new file mode 100644 index 000000000..e83775863 --- /dev/null +++ b/pr-1714/2015/06/13/using-windows-powershell-tasks.html @@ -0,0 +1,354 @@ + + + + + + + + + + + + + + + + Using Windows PowerShell tasks | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: Using Windows PowerShell tasks

+

Pat Mc Grath

+

+

+
+ +
+

Some things to be aware of when using Windows PowerShell tasks.

+ +

GoCD Agent default installation

+ +

The default installation of a GoCD +agent will use a 32-bit JRE unless you indicate otherwise. This JRE is embedded in the GoCD agent installer.

+ +

If you want to use an alternative JRE (must satisfy GoCD's JRE requirements) after the initial installation, you can alter +the "wrapper.java.command" key's value in the [InstallDirectory]\config\wrapper-agent.conf file to point to a +different JRE. You will then need to restart the GoCD agent service to start using the alternative JRE.

+ +

The [InstallDirectory] refers to the GoCD agents installation directory which by default is "C:\Program Files (x86)\Go Agent".

+ +

Pre-requisites for running PowerShell task commands

+ +
    +
  • You can only run on Windows based agents
    • +
  • You should tag the agents if your are also using linux agents
    • +
  • You probably want to ensure your agents all have the same version of PowerShell
    • +
+ +

32-bit GoCD agent

+ +

If you are running a default GoCD agent installation then you will be running a 32-bit JRE.

+ +

The 32-bit JRE will try to run PowerShell tasks in the 32-bit version of PowerShell, even if you give the full path to +the 64-bit PowerShell executable in the task. If you need to execute a PowerShell script then you will need to alter the +execution policy as follows:

+ +
    +
  • +

    Open 32-bit version of PowerShell as an administrator: Start -> All Programs -> Accessories -> Windows Powershell -> Windows Powershell (x86) and type:

    + + 
    # Alter execution policy
+set-executionpolicy remotesigned -force
+
    +
    • +
+ +

This will allow you to run local scripts on the Windows GoCD agent box.

+ +

64-bit GoCD agent

+ +

If you are running a GoCD agent using a 64-bit JRE, it will run PowerShell tasks in the 64-bit version of PowerShell.

+ +

If you need to execute a PowerShell script, then you will need to alter the execution policy as follows:

+ +
    +
  • +

    Open 64-bit version of PowerShell as an administrator: Start -> All Programs -> Accessories -> Windows Powershell -> +Windows Powershell and type:

    + + 
    # Alter execution policy
+set-executionpolicy remotesigned -force
+
    +
    • +
+ +

This will allow you to run local scripts on the Windows GoCD agent box.

+ +

PowerShell task commands

+ +

You can configure the task as follows:

+ +
command: powershell
+arg: .\run.ps1 arg1value
+
+ +

This assumes that the run.ps1 script is in the task's working directory.

+ +

If you create the run.ps1 file with the following content you can see details of the execution context in the console log for the pipeline:

+ +
param
+(
+  [string] $arg1
+)
+write-host "Script:            " $MyInvocation.MyCommand.Path
+write-host "Pid:               " $pid
+write-host "Host.Version:      " $host.version
+write-host "Is 64-bit process: " $([Environment]::Is64BitProcess)
+write-host "Execution policy:  " $(get-executionpolicy)
+write-host "Arg1:              " $arg1
+
+ +

Propagating failures

+ +

You need to ensure that PowerShell exits with an exit code that is not 0 in the event of a failure, this needs to cater to:

+ +
    +
  • Script errors
    • +
  • External process calls that indicate failure
    • +
+ +

You will need to decide how to handle these failures and if they should indicate the PowerShell task has been successful +or not. This may mean that some script errors and external process calls failing is okay in your context.

+ +

The following script demonstrates a strategy I use where I exit with a non zero code if any script error was encountered +or an external process call fails:

+ +
set-strictmode -version latest
+$ErrorActionPreference = 'Stop'
+
+function execute-externaltool
+(
+  [string] $context,
+  [scriptblock] $actionBlock
+)
+{
+  # This function exists to check the exit code for the external tool called within the script block, so we don't have to do this for each call
+  & $actionBlock
+  if ($LastExitCode -gt 0) { throw "$context : External tool call failed" }
+}
+
+
+try
+{
+  write-host "Script:            " $MyInvocation.MyCommand.Path
+  write-host "Pid:               " $pid
+  write-host "Host.Version:      " $host.version
+  write-host "Execution policy:  " $(get-executionpolicy)
+
+  # Query a service that does not exist, sc.exe will return with a non 0 exit code
+  execute-externaltool "Query a non existent service, will return with exit code != 0" { c:\windows\system32\sc.exe query service_does_not_exist }
+}
+catch
+{
+  write-host "$pid : Error caught - $_"
+  if ($? -and (test-path variable:LastExitCode) -and ($LastExitCode -gt 0)) { exit $LastExitCode }
+  else { exit 1 }
+}
+
+ +
    +
  • This script uses a try catch block to handle all errors +
      +
    • The $? and $LastExitCode caters to both script and external process calls
      • +
    • We fall back on an exit code of 1 if we do not have an external process exit code
      • +
    +
    • +
  • This script uses an execute-externaltool function which takes a script block argument +
      +
    • The script will invoke the script block
      • +
    • It will then check for a non zero exit code (Assumes the script block just calls an external process), if so it will throw an exception.
      • +
    +
    • +
+ +

See also

+ +

PowerShell execution policy +Bypassing PowerShell execution policy +Setting execution policy directly in the registry +GoCD PowerShell runner plugin - I believe it can only be configured on Windows based GoCD servers

+ +

About the author

+ +

This is a guest post by Pat Mc Grath. You can find Pat on GitHub.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/13/using-windows-powershell-tasks/index.html b/pr-1714/2015/06/13/using-windows-powershell-tasks/index.html new file mode 100644 index 000000000..6d2934d44 --- /dev/null +++ b/pr-1714/2015/06/13/using-windows-powershell-tasks/index.html @@ -0,0 +1,354 @@ + + + + + + + + + + + + + + + + Using Windows PowerShell tasks | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: Using Windows PowerShell tasks

+

Pat Mc Grath

+

+

+
+ +
+

Some things to be aware of when using Windows PowerShell tasks.

+ +

GoCD Agent default installation

+ +

The default installation of a GoCD +agent will use a 32-bit JRE unless you indicate otherwise. This JRE is embedded in the GoCD agent installer.

+ +

If you want to use an alternative JRE (must satisfy GoCD's JRE requirements) after the initial installation, you can alter +the "wrapper.java.command" key's value in the [InstallDirectory]\config\wrapper-agent.conf file to point to a +different JRE. You will then need to restart the GoCD agent service to start using the alternative JRE.

+ +

The [InstallDirectory] refers to the GoCD agents installation directory which by default is "C:\Program Files (x86)\Go Agent".

+ +

Pre-requisites for running PowerShell task commands

+ +
    +
  • You can only run on Windows based agents
    • +
  • You should tag the agents if your are also using linux agents
    • +
  • You probably want to ensure your agents all have the same version of PowerShell
    • +
+ +

32-bit GoCD agent

+ +

If you are running a default GoCD agent installation then you will be running a 32-bit JRE.

+ +

The 32-bit JRE will try to run PowerShell tasks in the 32-bit version of PowerShell, even if you give the full path to +the 64-bit PowerShell executable in the task. If you need to execute a PowerShell script then you will need to alter the +execution policy as follows:

+ +
    +
  • +

    Open 32-bit version of PowerShell as an administrator: Start -> All Programs -> Accessories -> Windows Powershell -> Windows Powershell (x86) and type:

    + + 
    # Alter execution policy
+set-executionpolicy remotesigned -force
+
    +
    • +
+ +

This will allow you to run local scripts on the Windows GoCD agent box.

+ +

64-bit GoCD agent

+ +

If you are running a GoCD agent using a 64-bit JRE, it will run PowerShell tasks in the 64-bit version of PowerShell.

+ +

If you need to execute a PowerShell script, then you will need to alter the execution policy as follows:

+ +
    +
  • +

    Open 64-bit version of PowerShell as an administrator: Start -> All Programs -> Accessories -> Windows Powershell -> +Windows Powershell and type:

    + + 
    # Alter execution policy
+set-executionpolicy remotesigned -force
+
    +
    • +
+ +

This will allow you to run local scripts on the Windows GoCD agent box.

+ +

PowerShell task commands

+ +

You can configure the task as follows:

+ +
command: powershell
+arg: .\run.ps1 arg1value
+
+ +

This assumes that the run.ps1 script is in the task's working directory.

+ +

If you create the run.ps1 file with the following content you can see details of the execution context in the console log for the pipeline:

+ +
param
+(
+  [string] $arg1
+)
+write-host "Script:            " $MyInvocation.MyCommand.Path
+write-host "Pid:               " $pid
+write-host "Host.Version:      " $host.version
+write-host "Is 64-bit process: " $([Environment]::Is64BitProcess)
+write-host "Execution policy:  " $(get-executionpolicy)
+write-host "Arg1:              " $arg1
+
+ +

Propagating failures

+ +

You need to ensure that PowerShell exits with an exit code that is not 0 in the event of a failure, this needs to cater to:

+ +
    +
  • Script errors
    • +
  • External process calls that indicate failure
    • +
+ +

You will need to decide how to handle these failures and if they should indicate the PowerShell task has been successful +or not. This may mean that some script errors and external process calls failing is okay in your context.

+ +

The following script demonstrates a strategy I use where I exit with a non zero code if any script error was encountered +or an external process call fails:

+ +
set-strictmode -version latest
+$ErrorActionPreference = 'Stop'
+
+function execute-externaltool
+(
+  [string] $context,
+  [scriptblock] $actionBlock
+)
+{
+  # This function exists to check the exit code for the external tool called within the script block, so we don't have to do this for each call
+  & $actionBlock
+  if ($LastExitCode -gt 0) { throw "$context : External tool call failed" }
+}
+
+
+try
+{
+  write-host "Script:            " $MyInvocation.MyCommand.Path
+  write-host "Pid:               " $pid
+  write-host "Host.Version:      " $host.version
+  write-host "Execution policy:  " $(get-executionpolicy)
+
+  # Query a service that does not exist, sc.exe will return with a non 0 exit code
+  execute-externaltool "Query a non existent service, will return with exit code != 0" { c:\windows\system32\sc.exe query service_does_not_exist }
+}
+catch
+{
+  write-host "$pid : Error caught - $_"
+  if ($? -and (test-path variable:LastExitCode) -and ($LastExitCode -gt 0)) { exit $LastExitCode }
+  else { exit 1 }
+}
+
+ +
    +
  • This script uses a try catch block to handle all errors +
      +
    • The $? and $LastExitCode caters to both script and external process calls
      • +
    • We fall back on an exit code of 1 if we do not have an external process exit code
      • +
    +
    • +
  • This script uses an execute-externaltool function which takes a script block argument +
      +
    • The script will invoke the script block
      • +
    • It will then check for a non zero exit code (Assumes the script block just calls an external process), if so it will throw an exception.
      • +
    +
    • +
+ +

See also

+ +

PowerShell execution policy +Bypassing PowerShell execution policy +Setting execution policy directly in the registry +GoCD PowerShell runner plugin - I believe it can only be configured on Windows based GoCD servers

+ +

About the author

+ +

This is a guest post by Pat Mc Grath. You can find Pat on GitHub.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/17.html b/pr-1714/2015/06/17.html new file mode 100644 index 000000000..2ac921882 --- /dev/null +++ b/pr-1714/2015/06/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 17 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/17/Upcoming-API-Changes.html b/pr-1714/2015/06/17/Upcoming-API-Changes.html new file mode 100644 index 000000000..3a4dbf6cf --- /dev/null +++ b/pr-1714/2015/06/17/Upcoming-API-Changes.html @@ -0,0 +1,208 @@ + + + + + + + + + + + + + + + + Upcoming API Changes | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Upcoming API Changes

+

Ketan Padegaonkar

+

+

+
+ +
+

With the upcoming release of GoCD 15.2, we'd like to begin unifying and improving some of the existing APIs that GoCD supports.

+ +

GoCD's APIs are fairly old, have inconsistent and unpredictable content types (csv, xml, json, plain text).

+ +

Going forward, we would like to announce an ongoing effort to improve these APIs to use something that is more modern, easy to discover, learn and build API clients for.

+ +

We would be using the JSON HAL specification. Our API guidelines are published on our RFC.

+ +

This will give us the opportunity to leverage Ruby and Rails to build these APIs, which should make it easier to incrementally iterate through and improve existing APIs to bring them to parity with our new guidelines.

+ +

We welcome any feedback to improve our guidelines and contributions to improve existing APIs.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/17/Upcoming-API-Changes/index.html b/pr-1714/2015/06/17/Upcoming-API-Changes/index.html new file mode 100644 index 000000000..2daa7a9fc --- /dev/null +++ b/pr-1714/2015/06/17/Upcoming-API-Changes/index.html @@ -0,0 +1,208 @@ + + + + + + + + + + + + + + + + Upcoming API Changes | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Upcoming API Changes

+

Ketan Padegaonkar

+

+

+
+ +
+

With the upcoming release of GoCD 15.2, we'd like to begin unifying and improving some of the existing APIs that GoCD supports.

+ +

GoCD's APIs are fairly old, have inconsistent and unpredictable content types (csv, xml, json, plain text).

+ +

Going forward, we would like to announce an ongoing effort to improve these APIs to use something that is more modern, easy to discover, learn and build API clients for.

+ +

We would be using the JSON HAL specification. Our API guidelines are published on our RFC.

+ +

This will give us the opportunity to leverage Ruby and Rails to build these APIs, which should make it easier to incrementally iterate through and improve existing APIs to bring them to parity with our new guidelines.

+ +

We welcome any feedback to improve our guidelines and contributions to improve existing APIs.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/17/index.html b/pr-1714/2015/06/17/index.html new file mode 100644 index 000000000..88e2cc543 --- /dev/null +++ b/pr-1714/2015/06/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 17 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18.html b/pr-1714/2015/06/18.html new file mode 100644 index 000000000..1f4a3f7b2 --- /dev/null +++ b/pr-1714/2015/06/18.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18/authentication-end-point.html b/pr-1714/2015/06/18/authentication-end-point.html new file mode 100644 index 000000000..9bfc239af --- /dev/null +++ b/pr-1714/2015/06/18/authentication-end-point.html @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + + + Authentication end-point | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Authentication end-point

+

GoCD Team

+

+

+
+ +
+

Starting 15.2.0 GoCD Server will expose authentication end-point. What this means is GoCD users can add "custom" authentication schemes through plugins.

+ +

Examples of integrations possible:

+ +
    +
  • OAuth Login - GitHub, Google, Hotmail, Yahoo! etc.
    • +
  • Single Sign-on (SSO) - LDAP, Okta etc.
    • +
  • 2-factor authentication - SMS verification etc.
    • +
  • Custom username & password authentication
    • +
+ +

How does it work?

+ +

Below is an explanation of how GitHub OAuth Login plugin works.

+ +
    +
  • Generate OAuth token on GitHub.
    • +
+ +
+ Generate oauth token on Git Hub +
Figure 1: Generate oauth token (Click to enlarge)
+
+ +
    +
  • On plugin listing page users will see a gear icon (similar to one on the pipeline dashboard).
    • +
+ +
+ Plugin listing with gear icon +
Figure 1: Plugin listing with gear icon (Click to enlarge)
+
+ +
    +
  • Clicking on the gear icon opens a pop-up that renders "Plugin Settings".
    • +
+ +
+ Configure plugin pop-up +
Figure 2: Configure plugin pop-up (Click to enlarge)
+
+ +
    +
  • Login Page
    • +
+ +
+ Login Page with Git Hub icon +
Figure 3: Login Page with GitHub icon (Click to enlarge)
+
+ +
    +
  • Click on GitHub icon
    • +
+ +
+ Authorize Go CD Server to access Git Hub +
Figure 3: Authorize GoCD Server to access GitHub (Click to enlarge)
+
+ +
    +
  • Successful login
    • +
+ +
+ Pipeline View on successful login +
Figure 3: On successful login (Click to enlarge)
+
+ +
    +
  • Ability to Search & Add users
    • +
+ +
+ Search User screen +
Figure 3: Search User (Click to enlarge)
+
+ +

We hope plugin developers are able to use this feature to support their organizations authentication mechanism.

+ +

References:

+ + + + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18/authentication-end-point/index.html b/pr-1714/2015/06/18/authentication-end-point/index.html new file mode 100644 index 000000000..ba72f356a --- /dev/null +++ b/pr-1714/2015/06/18/authentication-end-point/index.html @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + + + Authentication end-point | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Authentication end-point

+

GoCD Team

+

+

+
+ +
+

Starting 15.2.0 GoCD Server will expose authentication end-point. What this means is GoCD users can add "custom" authentication schemes through plugins.

+ +

Examples of integrations possible:

+ +
    +
  • OAuth Login - GitHub, Google, Hotmail, Yahoo! etc.
    • +
  • Single Sign-on (SSO) - LDAP, Okta etc.
    • +
  • 2-factor authentication - SMS verification etc.
    • +
  • Custom username & password authentication
    • +
+ +

How does it work?

+ +

Below is an explanation of how GitHub OAuth Login plugin works.

+ +
    +
  • Generate OAuth token on GitHub.
    • +
+ +
+ Generate oauth token on Git Hub +
Figure 1: Generate oauth token (Click to enlarge)
+
+ +
    +
  • On plugin listing page users will see a gear icon (similar to one on the pipeline dashboard).
    • +
+ +
+ Plugin listing with gear icon +
Figure 1: Plugin listing with gear icon (Click to enlarge)
+
+ +
    +
  • Clicking on the gear icon opens a pop-up that renders "Plugin Settings".
    • +
+ +
+ Configure plugin pop-up +
Figure 2: Configure plugin pop-up (Click to enlarge)
+
+ +
    +
  • Login Page
    • +
+ +
+ Login Page with Git Hub icon +
Figure 3: Login Page with GitHub icon (Click to enlarge)
+
+ +
    +
  • Click on GitHub icon
    • +
+ +
+ Authorize Go CD Server to access Git Hub +
Figure 3: Authorize GoCD Server to access GitHub (Click to enlarge)
+
+ +
    +
  • Successful login
    • +
+ +
+ Pipeline View on successful login +
Figure 3: On successful login (Click to enlarge)
+
+ +
    +
  • Ability to Search & Add users
    • +
+ +
+ Search User screen +
Figure 3: Search User (Click to enlarge)
+
+ +

We hope plugin developers are able to use this feature to support their organizations authentication mechanism.

+ +

References:

+ + + + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18/index.html b/pr-1714/2015/06/18/index.html new file mode 100644 index 000000000..ac5850868 --- /dev/null +++ b/pr-1714/2015/06/18/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18/plugin-settings.html b/pr-1714/2015/06/18/plugin-settings.html new file mode 100644 index 000000000..dc4868735 --- /dev/null +++ b/pr-1714/2015/06/18/plugin-settings.html @@ -0,0 +1,271 @@ + + + + + + + + + + + + + + + + Plugin Settings | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Plugin Settings

+

GoCD Team

+

+

+
+ +
+

GoCD is continuously improving its plugin infrastructure. Starting 15.2.0 GoCD will support "Plugin Settings" that will allow plugins developers to accept global settings. Currently these configurations had to be supported via system properties or a file that is in specified format in a specified location, which makes it a little haphazard. With this feature all plugins will have one approach to accept plugins settings from user & access plugin settings from GoCD Server.

+ +

How does it work?

+ +
    +
  • On plugin listing page users will see a gear icon (similar to one on the pipeline dashboard) for the plugins that accept plugin settings.
    • +
+ +
+ Plugin listing with gear icon +
Figure 1: Plugin listing with gear icon (Click to enlarge)
+
+ +
    +
  • Clicking on the gear icon opens a pop-up that renders "Plugin Settings" template that is provided by the plugin.
    • +
+ +
+ Configure plugin pop-up +
Figure 2: Configure plugin pop-up (Click to enlarge)
+
+ +
    +
  • On "Save" the user inputs are validated by plugin.
    • +
+ +
+ Configure plugin pop-up with errors +
Figure 3: Configure plugin pop-up with errors (Click to enlarge)
+
+ +

We hope plugin developers are able to use this feature to provide a better experience to their users.

+ +

References:

+ + + + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/18/plugin-settings/index.html b/pr-1714/2015/06/18/plugin-settings/index.html new file mode 100644 index 000000000..eed0c558c --- /dev/null +++ b/pr-1714/2015/06/18/plugin-settings/index.html @@ -0,0 +1,271 @@ + + + + + + + + + + + + + + + + Plugin Settings | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Plugin Settings

+

GoCD Team

+

+

+
+ +
+

GoCD is continuously improving its plugin infrastructure. Starting 15.2.0 GoCD will support "Plugin Settings" that will allow plugins developers to accept global settings. Currently these configurations had to be supported via system properties or a file that is in specified format in a specified location, which makes it a little haphazard. With this feature all plugins will have one approach to accept plugins settings from user & access plugin settings from GoCD Server.

+ +

How does it work?

+ +
    +
  • On plugin listing page users will see a gear icon (similar to one on the pipeline dashboard) for the plugins that accept plugin settings.
    • +
+ +
+ Plugin listing with gear icon +
Figure 1: Plugin listing with gear icon (Click to enlarge)
+
+ +
    +
  • Clicking on the gear icon opens a pop-up that renders "Plugin Settings" template that is provided by the plugin.
    • +
+ +
+ Configure plugin pop-up +
Figure 2: Configure plugin pop-up (Click to enlarge)
+
+ +
    +
  • On "Save" the user inputs are validated by plugin.
    • +
+ +
+ Configure plugin pop-up with errors +
Figure 3: Configure plugin pop-up with errors (Click to enlarge)
+
+ +

We hope plugin developers are able to use this feature to provide a better experience to their users.

+ +

References:

+ + + + + + + +
+ +

As always, GoCD questions can be asked on the mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/23.html b/pr-1714/2015/06/23.html new file mode 100644 index 000000000..37e9cd67a --- /dev/null +++ b/pr-1714/2015/06/23.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/23/hardly-anyone-knows-cd.html b/pr-1714/2015/06/23/hardly-anyone-knows-cd.html new file mode 100644 index 000000000..419a408d5 --- /dev/null +++ b/pr-1714/2015/06/23/hardly-anyone-knows-cd.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + + + + + Hardly Anyone Knows Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Hardly Anyone Knows Continuous Delivery

+

Ken Mugrage

+

+

+
+ +
+

Those of us who work in or around teams doing continuous delivery often think it's a mainstream thing. This couldn't be further from the truth.

+ +

I work for Thoughtworks, a company that implements processes and technologies we think are good long before most. We built the first CI server with Cruise Control, and GoCD was the first purpose built Continuous Delivery server. I go to a lot of conferences and events, read a lot of blogs, talk to a lot of peers, work with a lot of partners, etc. I thought most people involved with the creation of software had a pretty good idea what CD is.

+ +

I was wrong.

+ +

I just got back from a pretty big software conference that was a bit off my normal track. They had a few DevOps sessions this year, but historically this particular conference has been more about agile methodologies. As one of the sponsors, I spent a lot of time at the booth talking to people.

+ +

The conversations in a trade show booth generally start with the visitor asking what we do (gotta work more on that so they don't have to) and me telling them that GoCD is a continuous delivery server. From there we go on to talk about what makes GoCD unique and why they should use it.

+ +

At this show, when I told people GoCD is a continuous delivery server I was met with mostly blank stares. This was a conference attended by 100% people who create software for a living. The people attending care enough about their craft to spend (or get their company to spend) a couple thousand US dollars to come. But they had no idea what Continuous Delivery really is. I probably should note, this isn't meant as a knock on that conference at all.

+ +

The lack of knowledge is a really bad thing. Not just for the GoCD CD project, but for software in general. The world runs on software. Too much of that software is bad. The practices around Continuous Delivery could make some of it better, or kill it before it gets out.

+ +

So what can we do?

+ +

Buy or borrow a copy of Continuous Delivery by Jez Humble and Dave Farley for your office. Make everyone read at least the chapters that apply to them. Yes, Jez and Dave both worked for Thoughtworks when they were writing the book. Yes, Jez was the product owner of GoCD before the book came out. No, we won't make any money off the link if you buy it. I promise this isn't bias, it's the definitive work on the subject.

+ +

Get The Phoenix Project by Gene Kim. It's a fictional novel and a bit corny at times, but people will learn a bit even if they don't mean to.

+ +

Send people that don't know about Continuous Delivery to conferences that are specific to CD and DevOps. My favorite is DevOpsDays. You don't need huge, expensive conferences where you'll have to get finance approval to attend. The next one I'm going to is 200 bucks. If they don't have one in your area create one or find someone that will. (FYI, if anyone in Seattle is interested in doing that let me know)

+ +

Take a friend who's CD impaired to a DevOps Meetup. As I'm writing this there are groups in 404 cities worldwide at that link alone. Trying to get your meetup going and struggling for content and/or speakers? Tell me, I know a few people and might be able to help.

+ +

Stop assuming everyone knows what we're talking about when we talk about CD. Many of them are smiling and nodding the same way I do when my mother talks about her flowers.

+ +

Feel free to comment with your own resource, this isn't even close to a definite list.

+ +

One last thing…

+ +

Stop telling people that the phrases DevOps and Continuous Delivery are overused. They aren't. Hardly anyone knows what Continuous Delivery is.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/23/hardly-anyone-knows-cd/index.html b/pr-1714/2015/06/23/hardly-anyone-knows-cd/index.html new file mode 100644 index 000000000..092903bf4 --- /dev/null +++ b/pr-1714/2015/06/23/hardly-anyone-knows-cd/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + + + + + Hardly Anyone Knows Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Hardly Anyone Knows Continuous Delivery

+

Ken Mugrage

+

+

+
+ +
+

Those of us who work in or around teams doing continuous delivery often think it's a mainstream thing. This couldn't be further from the truth.

+ +

I work for Thoughtworks, a company that implements processes and technologies we think are good long before most. We built the first CI server with Cruise Control, and GoCD was the first purpose built Continuous Delivery server. I go to a lot of conferences and events, read a lot of blogs, talk to a lot of peers, work with a lot of partners, etc. I thought most people involved with the creation of software had a pretty good idea what CD is.

+ +

I was wrong.

+ +

I just got back from a pretty big software conference that was a bit off my normal track. They had a few DevOps sessions this year, but historically this particular conference has been more about agile methodologies. As one of the sponsors, I spent a lot of time at the booth talking to people.

+ +

The conversations in a trade show booth generally start with the visitor asking what we do (gotta work more on that so they don't have to) and me telling them that GoCD is a continuous delivery server. From there we go on to talk about what makes GoCD unique and why they should use it.

+ +

At this show, when I told people GoCD is a continuous delivery server I was met with mostly blank stares. This was a conference attended by 100% people who create software for a living. The people attending care enough about their craft to spend (or get their company to spend) a couple thousand US dollars to come. But they had no idea what Continuous Delivery really is. I probably should note, this isn't meant as a knock on that conference at all.

+ +

The lack of knowledge is a really bad thing. Not just for the GoCD CD project, but for software in general. The world runs on software. Too much of that software is bad. The practices around Continuous Delivery could make some of it better, or kill it before it gets out.

+ +

So what can we do?

+ +

Buy or borrow a copy of Continuous Delivery by Jez Humble and Dave Farley for your office. Make everyone read at least the chapters that apply to them. Yes, Jez and Dave both worked for Thoughtworks when they were writing the book. Yes, Jez was the product owner of GoCD before the book came out. No, we won't make any money off the link if you buy it. I promise this isn't bias, it's the definitive work on the subject.

+ +

Get The Phoenix Project by Gene Kim. It's a fictional novel and a bit corny at times, but people will learn a bit even if they don't mean to.

+ +

Send people that don't know about Continuous Delivery to conferences that are specific to CD and DevOps. My favorite is DevOpsDays. You don't need huge, expensive conferences where you'll have to get finance approval to attend. The next one I'm going to is 200 bucks. If they don't have one in your area create one or find someone that will. (FYI, if anyone in Seattle is interested in doing that let me know)

+ +

Take a friend who's CD impaired to a DevOps Meetup. As I'm writing this there are groups in 404 cities worldwide at that link alone. Trying to get your meetup going and struggling for content and/or speakers? Tell me, I know a few people and might be able to help.

+ +

Stop assuming everyone knows what we're talking about when we talk about CD. Many of them are smiling and nodding the same way I do when my mother talks about her flowers.

+ +

Feel free to comment with your own resource, this isn't even close to a definite list.

+ +

One last thing…

+ +

Stop telling people that the phrases DevOps and Continuous Delivery are overused. They aren't. Hardly anyone knows what Continuous Delivery is.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/23/index.html b/pr-1714/2015/06/23/index.html new file mode 100644 index 000000000..c3f1fe72b --- /dev/null +++ b/pr-1714/2015/06/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/06/index.html b/pr-1714/2015/06/index.html new file mode 100644 index 000000000..2af8de664 --- /dev/null +++ b/pr-1714/2015/06/index.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07.html b/pr-1714/2015/07.html new file mode 100644 index 000000000..8c293aabe --- /dev/null +++ b/pr-1714/2015/07.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/07.html b/pr-1714/2015/07/07.html new file mode 100644 index 000000000..66a0b3aa2 --- /dev/null +++ b/pr-1714/2015/07/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/07/GitHub-Integration.html b/pr-1714/2015/07/07/GitHub-Integration.html new file mode 100644 index 000000000..cc97c88e2 --- /dev/null +++ b/pr-1714/2015/07/07/GitHub-Integration.html @@ -0,0 +1,276 @@ + + + + + + + + + + + + + + + + Integrating GoCD with GitHub | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Integrating GoCD with GitHub

+

GoCD Team

+

+

+
+ +
+

With the upcoming 15.2 release we're announcing some new API endpoints that will make integrating with GoCD with GitHub easier and fun.

+ +

In this blog we will show you how you can integrate GoCD with GitHub using a few plugins for profit and fun.

+ +

Login using the GitHub OAuth Plugin

+ +

This plugin allows you to login, search and add existing github users to GoCD.

+ +
+ Login Page with GitHub icon +
Login Page with GitHub icon
+
+ +
+ Search and Add User +
Search and Add User
+
+ +
+ +

Build pull requests with GitHub Pull Request Poller & GitHub Status Notifier

+ +

The combination of these plugins will help you configure GoCD such that any pull-requests that are submitted will automatically be built, and their statuses updated on the pull request on GitHub.

+ +
+ GitHub PR page gets updated +
GitHub PR page gets updated
+
+ +
+ GitHub PR listing page gets updated +
GitHub PR listing page gets updated
+
+ +
+ +

GitHub Issues Integration with Custom Project Management Setup

+ +

Any commit messages that contain references to issues or pull requests using the popular means to mention issue (#42) can is something that GoCD already understands.

+ +

To configure this, edit the pipeline material and setup a pattern and a link under "Project Management" tab.

+ +
+ GitHub Issue Tracker Integration +
GitHub Issue Tracker Integration
+
+ +

Any commit messages with issue numbers will be linked to the correct GitHub issues:

+ +
+ Comment with GitHub issue link +
Comment with GitHub issue link (build cause pop-up)
+
+ +

You can also compare pipelines and get the release notes or changelog straight out of GoCD.

+ +
+ Compare pipeline page shows comment with GitHub issue link +
Comment with GitHub issue link (compare pipeline page)
+
+ +
+ +

If you think GoCD can provide more integrations to GitHub or provide similar integrations with other tools/services please do leave a comment or ask on the mailing list.

+ +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/07/GitHub-Integration/index.html b/pr-1714/2015/07/07/GitHub-Integration/index.html new file mode 100644 index 000000000..1cf71379f --- /dev/null +++ b/pr-1714/2015/07/07/GitHub-Integration/index.html @@ -0,0 +1,276 @@ + + + + + + + + + + + + + + + + Integrating GoCD with GitHub | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Integrating GoCD with GitHub

+

GoCD Team

+

+

+
+ +
+

With the upcoming 15.2 release we're announcing some new API endpoints that will make integrating with GoCD with GitHub easier and fun.

+ +

In this blog we will show you how you can integrate GoCD with GitHub using a few plugins for profit and fun.

+ +

Login using the GitHub OAuth Plugin

+ +

This plugin allows you to login, search and add existing github users to GoCD.

+ +
+ Login Page with GitHub icon +
Login Page with GitHub icon
+
+ +
+ Search and Add User +
Search and Add User
+
+ +
+ +

Build pull requests with GitHub Pull Request Poller & GitHub Status Notifier

+ +

The combination of these plugins will help you configure GoCD such that any pull-requests that are submitted will automatically be built, and their statuses updated on the pull request on GitHub.

+ +
+ GitHub PR page gets updated +
GitHub PR page gets updated
+
+ +
+ GitHub PR listing page gets updated +
GitHub PR listing page gets updated
+
+ +
+ +

GitHub Issues Integration with Custom Project Management Setup

+ +

Any commit messages that contain references to issues or pull requests using the popular means to mention issue (#42) can is something that GoCD already understands.

+ +

To configure this, edit the pipeline material and setup a pattern and a link under "Project Management" tab.

+ +
+ GitHub Issue Tracker Integration +
GitHub Issue Tracker Integration
+
+ +

Any commit messages with issue numbers will be linked to the correct GitHub issues:

+ +
+ Comment with GitHub issue link +
Comment with GitHub issue link (build cause pop-up)
+
+ +

You can also compare pipelines and get the release notes or changelog straight out of GoCD.

+ +
+ Compare pipeline page shows comment with GitHub issue link +
Comment with GitHub issue link (compare pipeline page)
+
+ +
+ +

If you think GoCD can provide more integrations to GitHub or provide similar integrations with other tools/services please do leave a comment or ask on the mailing list.

+ +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/07/index.html b/pr-1714/2015/07/07/index.html new file mode 100644 index 000000000..71f8c5eaf --- /dev/null +++ b/pr-1714/2015/07/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/14.html b/pr-1714/2015/07/14.html new file mode 100644 index 000000000..7830fa7f2 --- /dev/null +++ b/pr-1714/2015/07/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 14 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/14/Go_15_2_announced.html b/pr-1714/2015/07/14/Go_15_2_announced.html new file mode 100644 index 000000000..69a892fe0 --- /dev/null +++ b/pr-1714/2015/07/14/Go_15_2_announced.html @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + + Version 15.2.0 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 15.2.0 Released

+

GoCD Team

+

+

+
+ +
+

We like to announce a new release of GoCD. Head over to our downloads page to get your hands on the latest and greatest. Read more about what's new in this release from our release notes.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/14/Go_15_2_announced/index.html b/pr-1714/2015/07/14/Go_15_2_announced/index.html new file mode 100644 index 000000000..480f3f192 --- /dev/null +++ b/pr-1714/2015/07/14/Go_15_2_announced/index.html @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + + Version 15.2.0 Released | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD 15.2.0 Released

+

GoCD Team

+

+

+
+ +
+

We like to announce a new release of GoCD. Head over to our downloads page to get your hands on the latest and greatest. Read more about what's new in this release from our release notes.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/14/index.html b/pr-1714/2015/07/14/index.html new file mode 100644 index 000000000..dbd34c14a --- /dev/null +++ b/pr-1714/2015/07/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 14 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/07/index.html b/pr-1714/2015/07/index.html new file mode 100644 index 000000000..ad194d46a --- /dev/null +++ b/pr-1714/2015/07/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08.html b/pr-1714/2015/08.html new file mode 100644 index 000000000..65c2e3619 --- /dev/null +++ b/pr-1714/2015/08.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/05.html b/pr-1714/2015/08/05.html new file mode 100644 index 000000000..f023186fd --- /dev/null +++ b/pr-1714/2015/08/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/05/Go-Sample-Virtualbox.html b/pr-1714/2015/08/05/Go-Sample-Virtualbox.html new file mode 100644 index 000000000..574f93d35 --- /dev/null +++ b/pr-1714/2015/08/05/Go-Sample-Virtualbox.html @@ -0,0 +1,262 @@ + + + + + + + + + + + + + + + + Sample GoCD VirtualBox based environment | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Sample GoCD Virtualbox based environment

+

Ken Mugrage

+

+

+
+ +
+

If you're interested in checking out GoCD but don't want to spend the time automating your +own system, this might be a great option for you. We've created an environment using Vagrant and Virtualbox. +Once it's up, you'll have a full GoCD installation including several example pipelines.

+ +

Note: This is an update to a blog post last year. The demo has been modified enough to warrant a new post.

+ +

The original version of this box used very simple PHP applications with some also simple tests. Neither these applications +nor the tests were "real" enough to be representative of what you're actually doing, and the need to keep the demo box self +contained made the real applications more of a distraction and source of problems than anything of real value.

+ +

This version uses Rake with empty targets and simple /bin/echo tasks instead of real deployments.

+ +

System Requirements

+ +

In order to run this you'll need Virtualbox +and Vagrant. Both of these are available for most operating +systems.

+ +

Using the box

+

To get started, open a command prompt in an empty directory and type…

+ +
+vagrant init gocd/gocd-demo +
+ +

This will create a file called Vagrantfile in your current directory.

+ +

Next, type…

+ +
+vagrant up +
+ +

Completion of this (especially the first time) will take quite a while, depending on your +bandwidth. Vagrant will be downloading the full box image (about 1GB) from Vagrantcloud +while you wait.

+ +

Note: If you have an existing GoCD installation on the same machine as this virtual machine +you may get a port conflict.

+ +

After a few minutes, you should be able to navigate to https://localhost:8153/go/pipelines on your local +machine and see the following…

+ +

Pipeline view setup

+ +

These pipelines are all related, as shown in the following value stream map screenshot…

+ +

Pipeline relation in Value Stream Map

+ +

Feel free to play around with the installation and see how everything works. You can always +reset the box to it's orginal state if you need to!

+ +

What's on the machine?

+ +

The box will be updated as new things come out, but as of this writing…

+ +
    +
  • GoCD 15.2 Server
    • +
  • GoCD 15.2 Agent
    • +
  • Pipelines which are simulated using empty Rake targets and /bin/echo commands
    • +
+ +


+ +

As always, GoCD questions can be asked at https://groups.google.com/g/go-cd

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/05/Go-Sample-Virtualbox/index.html b/pr-1714/2015/08/05/Go-Sample-Virtualbox/index.html new file mode 100644 index 000000000..b02d61fbc --- /dev/null +++ b/pr-1714/2015/08/05/Go-Sample-Virtualbox/index.html @@ -0,0 +1,262 @@ + + + + + + + + + + + + + + + + Sample GoCD VirtualBox based environment | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Sample GoCD Virtualbox based environment

+

Ken Mugrage

+

+

+
+ +
+

If you're interested in checking out GoCD but don't want to spend the time automating your +own system, this might be a great option for you. We've created an environment using Vagrant and Virtualbox. +Once it's up, you'll have a full GoCD installation including several example pipelines.

+ +

Note: This is an update to a blog post last year. The demo has been modified enough to warrant a new post.

+ +

The original version of this box used very simple PHP applications with some also simple tests. Neither these applications +nor the tests were "real" enough to be representative of what you're actually doing, and the need to keep the demo box self +contained made the real applications more of a distraction and source of problems than anything of real value.

+ +

This version uses Rake with empty targets and simple /bin/echo tasks instead of real deployments.

+ +

System Requirements

+ +

In order to run this you'll need Virtualbox +and Vagrant. Both of these are available for most operating +systems.

+ +

Using the box

+

To get started, open a command prompt in an empty directory and type…

+ +
+vagrant init gocd/gocd-demo +
+ +

This will create a file called Vagrantfile in your current directory.

+ +

Next, type…

+ +
+vagrant up +
+ +

Completion of this (especially the first time) will take quite a while, depending on your +bandwidth. Vagrant will be downloading the full box image (about 1GB) from Vagrantcloud +while you wait.

+ +

Note: If you have an existing GoCD installation on the same machine as this virtual machine +you may get a port conflict.

+ +

After a few minutes, you should be able to navigate to https://localhost:8153/go/pipelines on your local +machine and see the following…

+ +

Pipeline view setup

+ +

These pipelines are all related, as shown in the following value stream map screenshot…

+ +

Pipeline relation in Value Stream Map

+ +

Feel free to play around with the installation and see how everything works. You can always +reset the box to it's orginal state if you need to!

+ +

What's on the machine?

+ +

The box will be updated as new things come out, but as of this writing…

+ +
    +
  • GoCD 15.2 Server
    • +
  • GoCD 15.2 Agent
    • +
  • Pipelines which are simulated using empty Rake targets and /bin/echo commands
    • +
+ +


+ +

As always, GoCD questions can be asked at https://groups.google.com/g/go-cd

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/05/index.html b/pr-1714/2015/08/05/index.html new file mode 100644 index 000000000..0d717e42c --- /dev/null +++ b/pr-1714/2015/08/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/28.html b/pr-1714/2015/08/28.html new file mode 100644 index 000000000..f4723f784 --- /dev/null +++ b/pr-1714/2015/08/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/28/index.html b/pr-1714/2015/08/28/index.html new file mode 100644 index 000000000..d6d37f0da --- /dev/null +++ b/pr-1714/2015/08/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/28/pipeline-patterns.html b/pr-1714/2015/08/28/pipeline-patterns.html new file mode 100644 index 000000000..e07caabbc --- /dev/null +++ b/pr-1714/2015/08/28/pipeline-patterns.html @@ -0,0 +1,296 @@ + + + + + + + + + + + + + + + + 5 Key Deployment Pipeline Patterns | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

5 Key Deployment Pipeline Patterns

+

Ken Mugrage

+

+

+
+ +
+

Teams have been automating the build, test and deploy processes of their software for many years, but usually in a very +specific "one off" manner. This article walks through 5 key patterns to setting up a successful deployment pipeline, +including designing parallel workflows, running tests in parallel, and more.

+ +

In 2007 GoCD (then called "Cruise") introduced build pipelines to the masses. Shortly after, Jez Humble (GoCD's original +product manager) and David Farley published Continuous Delivery. With these +concepts becoming more mainstream, some patterns have emerged. There are certainly more, but these are some that +stick out.

+ +

1. Build things once

+ +

When you're taking software from initial code change to production in an automated fashion, it's important +that you deploy the exact same thing you've tested.

+ +

Once you've built a binary, you should upload that back to your CD server or artifact repository for later use.

+ +

GoCD Upload Artifacts

+ +

When you're ready to deploy to a downstream system, you should fetch and install that build artifact. This way you make +sure that you're running your functional tests on the exact thing you built and that you're going to deploy.

+ +

GoCD Fetch Artifacts

+ +

2. Run tests in parallel

+ +

Any moderately complicated application is likely to have a very large number of of automated tests. Every time someone on the +Mingle team at Thoughtworks commits some code, the application is subjected to well +over 11,000 automated tests. If the team ran those tests back to back, they would take a couple days. Of course you can't +wait a couple days before you know the state of your software.

+ +

Too often this leads to teams only running part of their tests.

+ +

What you should do is split those tests up into manageable size chunks and run them in parallel. In the case of the Mingle +team those tests run on 65 GoCD agents at the same time.

+ +

GoCD Jobs overview displaying parallel tests

+ +

Of course it's also vitally important that you're able to quickly determine what went wrong if something fails, so you +should make sure the tests results from all of the jobs can be viewed in one consolidated place.

+ +

GoCD Tests tab showing failed tests

+ +

3. Design parallel workflows

+ +

It's not uncommon for teams to practice Continuous Integration on small parts of code before "throwing it over the wall" +to someone else to put that together with other parts of the application. In these cases, it's usually OK to set up a +linear flow. The entire thing might run end to end in a just few minutes.

+ +

One of the most common mistakes when graduating from Continuous Integration (CI) to Continuous Delivery is applying the +same linear thinking. When we're automating the progression of all of the code from commit to deployment on a production system, it's very +likely that there will be a much longer running set of jobs to be done.

+ +

Take the example in the image below for example. Here we have a team who has decided to implement a manual approval for +user acceptance. We want to make it easy for the team responsible to do a one click deployment to their application, but +they may not look at it immediately. There's really no reason we can't run the automated acceptance tests while that is +going on.

+ +

GoCD Parallel Pipelines

+ +

Hopefully you noticed one other really important thing about the image above. The production pipelines have not run. If +you're doing things in parallel it's important that your Continuous Delivery system is smart about handling +dependencies. This is a screenshot from GoCD, which uses fan in/fan out dependency management to make sure the project +doesn't get deployed until both of the upstream pipelines have gone green.

+ +

4. Verify on a production-like environment

+ +

Jez Humble tells a story about developing and testing a Java application on Windows machines and then deploying it on +Solaris. The short version of the story; it didn't work.

+ +

Ideally you should be staging and testing on the same set up. If your staging and production environments are exactly the same, +you can even use them interchangeably in a blue / green deployment pattern. +It's hard to imagine a better way to be sure your software will work when you turn users loose on it.

+ +

If you're deploying to very large environments where it's just not practical to have an exact duplicate, you should still +duplicate the technology. In other words, if you your web application runs on a cluster of 1,000 machines in production, you +should verify that application on a cluster, even if it's only 2 machines.

+ +

One of the reasons people are so excited about advancements in container technology is the help they provide in this area. +If you use something like Docker to develop, test and deploy your applications you have a quite a bit more control over making +sure things always work the same way.

+ +

5. Manage your environments in a pipeline too

+ +

In many cases it's easier to break an application with a configuration change than with a bug introduced in the source code. +We've all heard the comment "it works on my machine".

+ +

All of your environments must be managed using an automated system and then verified with the same rigor you use on your +software.

+ +

In the value stream map below you'll see that changes to our environments are submitted as code to Git. From there the +Application_Environments pipeline builds our container, verifies is and then stores it on our registry. That change kicks +off the rest of our build / test / deploy pipelines in exactly the same way an application code change would.

+ +

GoCD Environment changes submitted as code

+ +

Conclusion

+ +

These are just a few keys to setting up a successful deployment pipeline. Do you have others you believe are key? Feel +free to comment below.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/28/pipeline-patterns/index.html b/pr-1714/2015/08/28/pipeline-patterns/index.html new file mode 100644 index 000000000..ca415576c --- /dev/null +++ b/pr-1714/2015/08/28/pipeline-patterns/index.html @@ -0,0 +1,296 @@ + + + + + + + + + + + + + + + + 5 Key Deployment Pipeline Patterns | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

5 Key Deployment Pipeline Patterns

+

Ken Mugrage

+

+

+
+ +
+

Teams have been automating the build, test and deploy processes of their software for many years, but usually in a very +specific "one off" manner. This article walks through 5 key patterns to setting up a successful deployment pipeline, +including designing parallel workflows, running tests in parallel, and more.

+ +

In 2007 GoCD (then called "Cruise") introduced build pipelines to the masses. Shortly after, Jez Humble (GoCD's original +product manager) and David Farley published Continuous Delivery. With these +concepts becoming more mainstream, some patterns have emerged. There are certainly more, but these are some that +stick out.

+ +

1. Build things once

+ +

When you're taking software from initial code change to production in an automated fashion, it's important +that you deploy the exact same thing you've tested.

+ +

Once you've built a binary, you should upload that back to your CD server or artifact repository for later use.

+ +

GoCD Upload Artifacts

+ +

When you're ready to deploy to a downstream system, you should fetch and install that build artifact. This way you make +sure that you're running your functional tests on the exact thing you built and that you're going to deploy.

+ +

GoCD Fetch Artifacts

+ +

2. Run tests in parallel

+ +

Any moderately complicated application is likely to have a very large number of of automated tests. Every time someone on the +Mingle team at Thoughtworks commits some code, the application is subjected to well +over 11,000 automated tests. If the team ran those tests back to back, they would take a couple days. Of course you can't +wait a couple days before you know the state of your software.

+ +

Too often this leads to teams only running part of their tests.

+ +

What you should do is split those tests up into manageable size chunks and run them in parallel. In the case of the Mingle +team those tests run on 65 GoCD agents at the same time.

+ +

GoCD Jobs overview displaying parallel tests

+ +

Of course it's also vitally important that you're able to quickly determine what went wrong if something fails, so you +should make sure the tests results from all of the jobs can be viewed in one consolidated place.

+ +

GoCD Tests tab showing failed tests

+ +

3. Design parallel workflows

+ +

It's not uncommon for teams to practice Continuous Integration on small parts of code before "throwing it over the wall" +to someone else to put that together with other parts of the application. In these cases, it's usually OK to set up a +linear flow. The entire thing might run end to end in a just few minutes.

+ +

One of the most common mistakes when graduating from Continuous Integration (CI) to Continuous Delivery is applying the +same linear thinking. When we're automating the progression of all of the code from commit to deployment on a production system, it's very +likely that there will be a much longer running set of jobs to be done.

+ +

Take the example in the image below for example. Here we have a team who has decided to implement a manual approval for +user acceptance. We want to make it easy for the team responsible to do a one click deployment to their application, but +they may not look at it immediately. There's really no reason we can't run the automated acceptance tests while that is +going on.

+ +

GoCD Parallel Pipelines

+ +

Hopefully you noticed one other really important thing about the image above. The production pipelines have not run. If +you're doing things in parallel it's important that your Continuous Delivery system is smart about handling +dependencies. This is a screenshot from GoCD, which uses fan in/fan out dependency management to make sure the project +doesn't get deployed until both of the upstream pipelines have gone green.

+ +

4. Verify on a production-like environment

+ +

Jez Humble tells a story about developing and testing a Java application on Windows machines and then deploying it on +Solaris. The short version of the story; it didn't work.

+ +

Ideally you should be staging and testing on the same set up. If your staging and production environments are exactly the same, +you can even use them interchangeably in a blue / green deployment pattern. +It's hard to imagine a better way to be sure your software will work when you turn users loose on it.

+ +

If you're deploying to very large environments where it's just not practical to have an exact duplicate, you should still +duplicate the technology. In other words, if you your web application runs on a cluster of 1,000 machines in production, you +should verify that application on a cluster, even if it's only 2 machines.

+ +

One of the reasons people are so excited about advancements in container technology is the help they provide in this area. +If you use something like Docker to develop, test and deploy your applications you have a quite a bit more control over making +sure things always work the same way.

+ +

5. Manage your environments in a pipeline too

+ +

In many cases it's easier to break an application with a configuration change than with a bug introduced in the source code. +We've all heard the comment "it works on my machine".

+ +

All of your environments must be managed using an automated system and then verified with the same rigor you use on your +software.

+ +

In the value stream map below you'll see that changes to our environments are submitted as code to Git. From there the +Application_Environments pipeline builds our container, verifies is and then stores it on our registry. That change kicks +off the rest of our build / test / deploy pipelines in exactly the same way an application code change would.

+ +

GoCD Environment changes submitted as code

+ +

Conclusion

+ +

These are just a few keys to setting up a successful deployment pipeline. Do you have others you believe are key? Feel +free to comment below.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/08/index.html b/pr-1714/2015/08/index.html new file mode 100644 index 000000000..8743fb42c --- /dev/null +++ b/pr-1714/2015/08/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09.html b/pr-1714/2015/09.html new file mode 100644 index 000000000..298167d56 --- /dev/null +++ b/pr-1714/2015/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09/01.html b/pr-1714/2015/09/01.html new file mode 100644 index 000000000..3cff5215d --- /dev/null +++ b/pr-1714/2015/09/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 1 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09/01/index.html b/pr-1714/2015/09/01/index.html new file mode 100644 index 000000000..9b87d5c22 --- /dev/null +++ b/pr-1714/2015/09/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 1 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09/01/visibility-is-opportunity.html b/pr-1714/2015/09/01/visibility-is-opportunity.html new file mode 100644 index 000000000..53e7b0cda --- /dev/null +++ b/pr-1714/2015/09/01/visibility-is-opportunity.html @@ -0,0 +1,377 @@ + + + + + + + + + + + + + + + + Visibility Is Opportunity | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Visibility Is Opportunity: stories of improving continuous integration

+

Xiao Li

+

+

+
+ +
+

Visibility can be hard, but it's worth it.

+ +

Mingle is a 9 years JRuby Rails project. +We do test-driven development and continuous integration. +We write selenium tests to test everything since Oct 2006.

+ +

For a long time, our build time was 1 to 2 hours. +We thought it was a good balance of build time and resources needed.

+ +

2014, we had about 12+K tests, including units, functionals and selenium tests. +The best build time was 1 hour ran in parallel on 46 VMs.

+ +

We ran test in parallel by Go CD jobs and TLB. +There were 46 test jobs in one Go CD stage. +Units, functionals and selenium tests were different. +So We created 3 TLB tasks to distribute them separately. +We configured TLB to distribute tests by test runtime for having similar build time.

+ +

When I looked for ideas to improve build performance, I had the following questions:

+ +
    +
  1. Where was time spending when test was running?
    2. +
  2. Were there bottlenecks in test code?
    3. +
+ +

Profiling was an obvious option, but it was challenge to profile build. +Because:

+ +
    +
  1. Profiling one test won't help. To figure out what's bottleneck for entire build, we need profile all tests running.
    2. +
  2. Profiling generates lots of data. 1 hour build on 46 VMs will generate tons of data.
    3. +
  3. We need merge/aggregate data collected from build VMs for analysis.
    4. +
+ +

It turns out, sampling profiler can be a good tool for this job. But Mingle is on Ruby 1.8. +There wasn't sampling profiler support it. +So I wrote Sampling Profiler and a data analysis web application to do the job:

+ +
    +
  1. First I ran Sampling Profiler with test on build.
    2. +
  2. Then sent all profiling call-graph data to the data analysis web application.
    3. +
  3. Data analysis web application merges same build profiling result.
    4. +
  4. Last, I built UI to navigate through profiling result.
    5. +
+ +

After I did it, test code performance improvement became straightforward. +The biggest surprise I found was test slept 1 hour on build in total. +The following code was one example:

+ +

{% highlight ruby %} +Timeout::timeout(time / 1000.0) do + # wait until given JavaScript condition is true + while get_eval(condition).downcase == "false" + sleep 1 + end +end +{% endhighlight %}

+ +

The sleep 1 code above caused build slept about 40+ minutes in total. +Changing sleep 1 to sleep 0.1 fixed problem.

+ +

Although there was no big bottleneck found, I was able to list and fix a handful small bottlenecks. +Our build time reduced to 45 minutes, and became more stable.

+ +

You're on the right track when you're improving visibility of the problem details. It can be hard. But hard work pays off.

+ +

Detail can lead you to the truth.

+ +

Recently, our build became unstable (more random failures) and longer (1 hour) again. +I got time to look into build performance again. +My teammate Jeff Norris noticed it was too slow when running selenium test on build VM. +I realized we had not paid attention to our VM performance. +Our VMs ran with 1 vertual CPU and 3.5 GB memory. +To run a selenium test, we need launch 3 processes:

+ +
    +
  1. Mingle application server for testing
    2. +
  2. Selenium proxy server
    3. +
  3. Selenium test.
    4. +
+ +

It is possible that 1 vertual CPU is not enough. +So we increased build VMs to 2 vCPU. +Build time decreased to 50 minutes. +The result was not as good as we thought. +So I compared all jobs runtime. +It turned out some selenium test jobs ran twice faster than other selenium test jobs.

+ +

As TLB balanced our selenium tests by time, we expect job runtime similar. +My first hypothesis was TLB may not work as expected. +Because tests didn't seem to be distributed well by runtime. +To verify my hypothesis, I checked out TLB source code. It was more complex than I thought. +And there is also no way to output more logs to verify it's correctness. +But Go CD has good support for APIs, so I wrote Ruby script to verify my hypothesis.

+ +

The following chart shows how the test runtime looks like on build. X-axis is job names; y-axis is job runtime.

+ +

Graph representing Acceptance Test time

+ +

Blue bars are test runtime on job. Red bars are "expected time", because TLB distributed tests by previous build test runtime. +Red bars are test runtime calculated by previous build test runtime:

+ +
Job expected runtime = sum of each test runtime in previous build
+
+ +

From this result, we can see the balance is not perfect, but OK. +Because red bars are similar high across all acceptance (selenium test) jobs.

+ +

Blue bars matched what I observed on build time. +Then I ran same script on more builds. The outputs were similar, just different jobs got longer time to run.

+ +

As Go CD random picked up build VMs to run any job, it gave me a clue that maybe its build VM performance issue. +So I wrote another script to build the following chart:

+ +

Graph displaying GoCD build agent runtime

+ +

It's clear there are some VMs are consistent slower than others. +Then Barrow Kwan found out 2 of our VMs hosts were overloaded when we increased vCPUs on our VMs. +We have set the host NOT to overload the CPU core but there was a typo in configuration. +After sorted out VM host CPU overload issue, our build time reduced to 30 minutes.

+ +

So, don't just assume, prove it with detailed data. Make details visible. It leads you to the truth.

+ +

You don't know what you don't know.

+ +

Go CD introduced "timestamps in console logs" in release 15.1. +It made build task runtime visible. +I was not pay attention to the timestamps in the console logs until recently. +The following screenshot shows an example:

+ +

Timestamps in console logs

+ +

It turns out, tlb.rb client we used has the following code:

+ +

{% highlight ruby %} +def self.get path + sleep 2 + Net::HTTP.get_response(host, path, port).body +end +{% endhighlight %}

+ +

It only sleeps 2 seconds for one call, but it is called lots of times at the end of tests ran. +After removed code sleep 2, there is almost no time spent at the end of test anymore.

+ +

Without "timestamps in console logs", it is something like following:

+ +

No timestanps in console logs

+ +

No one will notice it ever.

+ +

The benefit of fixing this problem is outstanding for our pre-commit build. +Pre-commit build is a build running a test suite before developer pushes changes to trunk repository. +Our pre-commit build runs all unit and functional tests. +The build time reduced from 18 minutes to 10 minutes with 20 processes on 3 machines.

+ +

So, use/build tools that keep information visible, +you may be surprised what you can get from it.

+ +

Conclusion

+ +

Each time we improved our CI build performance, we thought that's the best we could do. +But it was not true overtime.

+ +

We found something, but missed other parts. +So when you look into a problem, don't assume how it works. +Working for better understanding instead. +There are various ways to gain more understanding of the problem:

+ +
    +
  • Start from scratch.
    • +
  • Look from different point of view.
    • +
  • Make hypothesis and verify it.
    • +
  • Find out more details of the problem.
    • +
  • Learn from resolving similar problems.
    • +
  • …
    • +
+ +

Visibility of the problem detail supports you hunting helpful data. +Thus it gives you more opportunities to understand and solve problem.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09/01/visibility-is-opportunity/index.html b/pr-1714/2015/09/01/visibility-is-opportunity/index.html new file mode 100644 index 000000000..fb03aa3ca --- /dev/null +++ b/pr-1714/2015/09/01/visibility-is-opportunity/index.html @@ -0,0 +1,377 @@ + + + + + + + + + + + + + + + + Visibility Is Opportunity | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Visibility Is Opportunity: stories of improving continuous integration

+

Xiao Li

+

+

+
+ +
+

Visibility can be hard, but it's worth it.

+ +

Mingle is a 9 years JRuby Rails project. +We do test-driven development and continuous integration. +We write selenium tests to test everything since Oct 2006.

+ +

For a long time, our build time was 1 to 2 hours. +We thought it was a good balance of build time and resources needed.

+ +

2014, we had about 12+K tests, including units, functionals and selenium tests. +The best build time was 1 hour ran in parallel on 46 VMs.

+ +

We ran test in parallel by Go CD jobs and TLB. +There were 46 test jobs in one Go CD stage. +Units, functionals and selenium tests were different. +So We created 3 TLB tasks to distribute them separately. +We configured TLB to distribute tests by test runtime for having similar build time.

+ +

When I looked for ideas to improve build performance, I had the following questions:

+ +
    +
  1. Where was time spending when test was running?
    2. +
  2. Were there bottlenecks in test code?
    3. +
+ +

Profiling was an obvious option, but it was challenge to profile build. +Because:

+ +
    +
  1. Profiling one test won't help. To figure out what's bottleneck for entire build, we need profile all tests running.
    2. +
  2. Profiling generates lots of data. 1 hour build on 46 VMs will generate tons of data.
    3. +
  3. We need merge/aggregate data collected from build VMs for analysis.
    4. +
+ +

It turns out, sampling profiler can be a good tool for this job. But Mingle is on Ruby 1.8. +There wasn't sampling profiler support it. +So I wrote Sampling Profiler and a data analysis web application to do the job:

+ +
    +
  1. First I ran Sampling Profiler with test on build.
    2. +
  2. Then sent all profiling call-graph data to the data analysis web application.
    3. +
  3. Data analysis web application merges same build profiling result.
    4. +
  4. Last, I built UI to navigate through profiling result.
    5. +
+ +

After I did it, test code performance improvement became straightforward. +The biggest surprise I found was test slept 1 hour on build in total. +The following code was one example:

+ +

{% highlight ruby %} +Timeout::timeout(time / 1000.0) do + # wait until given JavaScript condition is true + while get_eval(condition).downcase == "false" + sleep 1 + end +end +{% endhighlight %}

+ +

The sleep 1 code above caused build slept about 40+ minutes in total. +Changing sleep 1 to sleep 0.1 fixed problem.

+ +

Although there was no big bottleneck found, I was able to list and fix a handful small bottlenecks. +Our build time reduced to 45 minutes, and became more stable.

+ +

You're on the right track when you're improving visibility of the problem details. It can be hard. But hard work pays off.

+ +

Detail can lead you to the truth.

+ +

Recently, our build became unstable (more random failures) and longer (1 hour) again. +I got time to look into build performance again. +My teammate Jeff Norris noticed it was too slow when running selenium test on build VM. +I realized we had not paid attention to our VM performance. +Our VMs ran with 1 vertual CPU and 3.5 GB memory. +To run a selenium test, we need launch 3 processes:

+ +
    +
  1. Mingle application server for testing
    2. +
  2. Selenium proxy server
    3. +
  3. Selenium test.
    4. +
+ +

It is possible that 1 vertual CPU is not enough. +So we increased build VMs to 2 vCPU. +Build time decreased to 50 minutes. +The result was not as good as we thought. +So I compared all jobs runtime. +It turned out some selenium test jobs ran twice faster than other selenium test jobs.

+ +

As TLB balanced our selenium tests by time, we expect job runtime similar. +My first hypothesis was TLB may not work as expected. +Because tests didn't seem to be distributed well by runtime. +To verify my hypothesis, I checked out TLB source code. It was more complex than I thought. +And there is also no way to output more logs to verify it's correctness. +But Go CD has good support for APIs, so I wrote Ruby script to verify my hypothesis.

+ +

The following chart shows how the test runtime looks like on build. X-axis is job names; y-axis is job runtime.

+ +

Graph representing Acceptance Test time

+ +

Blue bars are test runtime on job. Red bars are "expected time", because TLB distributed tests by previous build test runtime. +Red bars are test runtime calculated by previous build test runtime:

+ +
Job expected runtime = sum of each test runtime in previous build
+
+ +

From this result, we can see the balance is not perfect, but OK. +Because red bars are similar high across all acceptance (selenium test) jobs.

+ +

Blue bars matched what I observed on build time. +Then I ran same script on more builds. The outputs were similar, just different jobs got longer time to run.

+ +

As Go CD random picked up build VMs to run any job, it gave me a clue that maybe its build VM performance issue. +So I wrote another script to build the following chart:

+ +

Graph displaying GoCD build agent runtime

+ +

It's clear there are some VMs are consistent slower than others. +Then Barrow Kwan found out 2 of our VMs hosts were overloaded when we increased vCPUs on our VMs. +We have set the host NOT to overload the CPU core but there was a typo in configuration. +After sorted out VM host CPU overload issue, our build time reduced to 30 minutes.

+ +

So, don't just assume, prove it with detailed data. Make details visible. It leads you to the truth.

+ +

You don't know what you don't know.

+ +

Go CD introduced "timestamps in console logs" in release 15.1. +It made build task runtime visible. +I was not pay attention to the timestamps in the console logs until recently. +The following screenshot shows an example:

+ +

Timestamps in console logs

+ +

It turns out, tlb.rb client we used has the following code:

+ +

{% highlight ruby %} +def self.get path + sleep 2 + Net::HTTP.get_response(host, path, port).body +end +{% endhighlight %}

+ +

It only sleeps 2 seconds for one call, but it is called lots of times at the end of tests ran. +After removed code sleep 2, there is almost no time spent at the end of test anymore.

+ +

Without "timestamps in console logs", it is something like following:

+ +

No timestanps in console logs

+ +

No one will notice it ever.

+ +

The benefit of fixing this problem is outstanding for our pre-commit build. +Pre-commit build is a build running a test suite before developer pushes changes to trunk repository. +Our pre-commit build runs all unit and functional tests. +The build time reduced from 18 minutes to 10 minutes with 20 processes on 3 machines.

+ +

So, use/build tools that keep information visible, +you may be surprised what you can get from it.

+ +

Conclusion

+ +

Each time we improved our CI build performance, we thought that's the best we could do. +But it was not true overtime.

+ +

We found something, but missed other parts. +So when you look into a problem, don't assume how it works. +Working for better understanding instead. +There are various ways to gain more understanding of the problem:

+ +
    +
  • Start from scratch.
    • +
  • Look from different point of view.
    • +
  • Make hypothesis and verify it.
    • +
  • Find out more details of the problem.
    • +
  • Learn from resolving similar problems.
    • +
  • …
    • +
+ +

Visibility of the problem detail supports you hunting helpful data. +Thus it gives you more opportunities to understand and solve problem.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/09/index.html b/pr-1714/2015/09/index.html new file mode 100644 index 000000000..4e891c2ab --- /dev/null +++ b/pr-1714/2015/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10.html b/pr-1714/2015/10.html new file mode 100644 index 000000000..3cd87b642 --- /dev/null +++ b/pr-1714/2015/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/19.html b/pr-1714/2015/10/19.html new file mode 100644 index 000000000..bee0aeb20 --- /dev/null +++ b/pr-1714/2015/10/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 19 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit.html b/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit.html new file mode 100644 index 000000000..4e1787899 --- /dev/null +++ b/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + GoCD and Snap CI at DevOps Enterprise Summit 2015 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD and Snap CI at DevOps Enterprise Summit 2015. Showcasing Innovation in Continuous Delivery.

+

Louda Peña

+

+

+
+ +
+

SAN FRANCISCO, CA – GoCD and Snap CI, products of Thoughtworks, will join other software thought leaders in co-sponsoring the 2015 DevOps Enterprise Summit.

+ +

Taking place October 19-21, 2015 at the Hyatt Regency Hotel in San Francisco, the DevOps Enterprise Summit is the industry's leading +DevOps and Continuous Delivery event. DOES15 is the event dedicated to those bringing Lean principles into the IT value stream while building +DevOps and Continuous Delivery into their organization.

+ +
+"Thoughtworks has been at the forefront of Continuous Delivery adoption since 2010 when former ThoughtWorkers Jez Humble and David +Farley published the first book on Continuous Delivery," said Technical Evangelist Ken Mugrage. "Both GoCD and Snap CI continue that +spirit of innovation in their product design, always creating new and improved ways for customers to make their releases more reliable and +more frequent." +
+ +

Currently, Thoughtworks offers both on-premise and cloud-based Continuous Delivery solutions. GoCD is free, open-source and +specializes in advanced deployments. Snap CI is cloud-based, taking hardware out of the equation while offering a reliable feedback +loop. Deployment pipelines are at the core of both products and offer visibility to the entire team.

+ +

ABOUT GoCD

+ +
    +
  • Scales to the most complex deliveries
    • +
  • Free and open source
    • +
  • Installed locally
    • +
  • Complex dependency management
    • +
  • Manual, automatic, and timed triggers
    • +
  • Commercial support and add­ons available from Thoughtworks
    • +
+ +

ABOUT SNAP CI

+ +
    +
  • Fast set-up for straightforward releases
    • +
  • Free 1-month trial
    • +
  • Cloud hosted
    • +
  • Simple pipeline editing and modeling
    • +
  • Manual and automatic triggers
    • +
  • Free for open-source software and public repos
    • +
+ +

SOCIAL MEDIA/BLOG

+ +

@goforcd https://www.gocd.org/blog.html

+ +

@snap_ci https://blog.snap­ci.com/

+ +

ABOUT THOUGHTWORKS

+ +

Thoughtworks is a software company and community of passionate, purpose-led individuals that specialize in software consulting, +delivery and products. We think disruptively to deliver technology to address our clients' toughest challenges, all while seeking to +revolutionize the IT industry and create positive social change. We make pioneering tools for software teams who aspire to be great. Our +products help organizations continuously improve and deliver quality software for their most critical needs.

+ +

ABOUT THE DEVOPS ENTERPRISE SUMMIT (DOES15)

+ +

The DevOps Enterprise Summit is co­sponsored by Gene Kim (IT Revolution) and Electric Cloud. Now in its second year, DOES15 is +dedicated to those bringing Lean principles into the IT value stream while building DevOps and Continuous Delivery into their organization.

+ +

Press Contact: Louda Peña lbaca@thoughtworks.com

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit/index.html b/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit/index.html new file mode 100644 index 000000000..46df2714e --- /dev/null +++ b/pr-1714/2015/10/19/gocd-snap-at-devops-enterprise-summit/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + GoCD and Snap CI at DevOps Enterprise Summit 2015 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD and Snap CI at DevOps Enterprise Summit 2015. Showcasing Innovation in Continuous Delivery.

+

Louda Peña

+

+

+
+ +
+

SAN FRANCISCO, CA – GoCD and Snap CI, products of Thoughtworks, will join other software thought leaders in co-sponsoring the 2015 DevOps Enterprise Summit.

+ +

Taking place October 19-21, 2015 at the Hyatt Regency Hotel in San Francisco, the DevOps Enterprise Summit is the industry's leading +DevOps and Continuous Delivery event. DOES15 is the event dedicated to those bringing Lean principles into the IT value stream while building +DevOps and Continuous Delivery into their organization.

+ +
+"Thoughtworks has been at the forefront of Continuous Delivery adoption since 2010 when former ThoughtWorkers Jez Humble and David +Farley published the first book on Continuous Delivery," said Technical Evangelist Ken Mugrage. "Both GoCD and Snap CI continue that +spirit of innovation in their product design, always creating new and improved ways for customers to make their releases more reliable and +more frequent." +
+ +

Currently, Thoughtworks offers both on-premise and cloud-based Continuous Delivery solutions. GoCD is free, open-source and +specializes in advanced deployments. Snap CI is cloud-based, taking hardware out of the equation while offering a reliable feedback +loop. Deployment pipelines are at the core of both products and offer visibility to the entire team.

+ +

ABOUT GoCD

+ +
    +
  • Scales to the most complex deliveries
    • +
  • Free and open source
    • +
  • Installed locally
    • +
  • Complex dependency management
    • +
  • Manual, automatic, and timed triggers
    • +
  • Commercial support and add­ons available from Thoughtworks
    • +
+ +

ABOUT SNAP CI

+ +
    +
  • Fast set-up for straightforward releases
    • +
  • Free 1-month trial
    • +
  • Cloud hosted
    • +
  • Simple pipeline editing and modeling
    • +
  • Manual and automatic triggers
    • +
  • Free for open-source software and public repos
    • +
+ +

SOCIAL MEDIA/BLOG

+ +

@goforcd https://www.gocd.org/blog.html

+ +

@snap_ci https://blog.snap­ci.com/

+ +

ABOUT THOUGHTWORKS

+ +

Thoughtworks is a software company and community of passionate, purpose-led individuals that specialize in software consulting, +delivery and products. We think disruptively to deliver technology to address our clients' toughest challenges, all while seeking to +revolutionize the IT industry and create positive social change. We make pioneering tools for software teams who aspire to be great. Our +products help organizations continuously improve and deliver quality software for their most critical needs.

+ +

ABOUT THE DEVOPS ENTERPRISE SUMMIT (DOES15)

+ +

The DevOps Enterprise Summit is co­sponsored by Gene Kim (IT Revolution) and Electric Cloud. Now in its second year, DOES15 is +dedicated to those bringing Lean principles into the IT value stream while building DevOps and Continuous Delivery into their organization.

+ +

Press Contact: Louda Peña lbaca@thoughtworks.com

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/19/index.html b/pr-1714/2015/10/19/index.html new file mode 100644 index 000000000..1627eb362 --- /dev/null +++ b/pr-1714/2015/10/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 19 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/29.html b/pr-1714/2015/10/29.html new file mode 100644 index 000000000..c441692ec --- /dev/null +++ b/pr-1714/2015/10/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/29/go-webinar-recording.html b/pr-1714/2015/10/29/go-webinar-recording.html new file mode 100644 index 000000000..6318557c8 --- /dev/null +++ b/pr-1714/2015/10/29/go-webinar-recording.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 29 Oct, 2015

+ + + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/29/go-webinar-recording/index.html b/pr-1714/2015/10/29/go-webinar-recording/index.html new file mode 100644 index 000000000..073086a58 --- /dev/null +++ b/pr-1714/2015/10/29/go-webinar-recording/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + Continuous Delivery with GoCD Webinar Recording | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Continuous Delivery with GoCD - Webinar Recording

+

Ken Mugrage

+

+

+
+ +
+

Every couple of weeks Thoughtworks hosts learning sessions for people who want more information about continuous delivery with GoCD. This is a recording of the session from 29 Oct, 2015

+ + + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/29/index.html b/pr-1714/2015/10/29/index.html new file mode 100644 index 000000000..206319811 --- /dev/null +++ b/pr-1714/2015/10/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/10/index.html b/pr-1714/2015/10/index.html new file mode 100644 index 000000000..1323ff072 --- /dev/null +++ b/pr-1714/2015/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11.html b/pr-1714/2015/11.html new file mode 100644 index 000000000..3ce536d56 --- /dev/null +++ b/pr-1714/2015/11.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/09.html b/pr-1714/2015/11/09.html new file mode 100644 index 000000000..e91f3516a --- /dev/null +++ b/pr-1714/2015/11/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 9 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections.html b/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections.html new file mode 100644 index 000000000..9a1448ecb --- /dev/null +++ b/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections.html @@ -0,0 +1,340 @@ + + + + + + + + + + + + + + + + Vulnerability in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Vulnerability in GoCD - Java deserialization and Apache commons-collections

+

GoCD Team

+

+

+
+ +
+

This post contains information about a security patch available for GoCD 15.2 (and soon, earlier versions). If you're using GoCD 15.2 in production, and especially if it is available over the internet, it is highly recommended to apply this patch immediately.

+ +

[Any updates to this post are available starting here]

+ +

What is the vulnerability?

+ +

As a part of AppSecCali 2015, a talk highlighted a +vulnerability +using Java deserialization with Apache commons-collections, a very commonly used library in Java-based +applications. Though the talk focused on other applications, GoCD is affected too.

+ +

Impact:

+ +

This is a potentially serious issue and applying the patch is recommended, since it is a remote code execution +vulnerability in Java deserialization (exploited using Apache commons-collections).

+ +

The impact is reduced a bit, because as far as we are able to determine, this attack on the server is possible only by +having the authentication certificate of an already-registered and enabled Go Agent, because of the way the GoCD Server +and GoCD Agent communicate using a secure connection.

+ +

So, even if you have a GoCD server exposed to the internet, you're not immediately vulnerable, as far as we have been +able to determine (and we have given it a lot of thought).

+ +

Risks of applying this patch:

+ +

This patch removes the known vector for this attack, as recommended by the vulnerability report. But, given the urgency, +this patch hasn't been extensively tested. There is a small potential for the Go Server to fail. However, given that the +patch is just a replaced JAR file, you can replace the original JAR file, if that happens and contact us on the +GoCD community mailing list.

+ +

We have been using this patch on https://build.go.cd and it has been fine. We will update this post if anything new is +found.

+ +

Risks of not applying this patch:

+ +

The GoCD server will be open to arbitrary remote code execution from anyone who has access to a registered Go Agent (or +the agent.jks file of such an agent). This is true of an agent which was once registered and then disabled as well.

+ +

How do I apply this patch?

+ +

Steps to apply the patch:

+ +
    +
  1. +

    Download the appropriate go.jar file mentioned below, for your version of the Go Server and verify its checksums.

    +
    2. +
  2. Find out the location of your go.jar file and take a backup. On different ways of installation of Go, this can be in different places: +
      +
    • On Windows: It is usually in C:\Program Files (x86)\Go Server\go.jar
      • +
    • On Debian and RPM based installations: It is usually in /usr/share/go-server/go.jar
      • +
    • On zip installers: It is in the base directory where you start the Go Server from.
      • +
    +
    3. +
  3. +

    Now that you have a backup of go.jar, stop the Go Server and replace go.jar with the one you downloaded.

    +
    4. +
  4. Restart the Go Server.
    5. +
+ +

All of your agents will now fetch the new agent JAR as well, and restart themselves. Depending on the number of agents +you have, this might take a little while (same as an upgrade of the Go Server).

+ +

The different patches available are:

+ +

15.2.0-2248:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/15.2.0-2015_11_09/go.jar
    • +
  • MD5 checksum: 0872e4eefceaaf842a69d8b55ec6a2d0
    • +
  • SHA256 sum: eecee2b04c9bd46e74c5c999585683daf164fe41b39151dfcc3f0642561fd4c5
    • +
  • GPG signature: https://download.go.cd/local/patches/15.2.0-2015_11_09/go.jar.asc
    • +
+ +

15.1.0-1863:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/15.1.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 5981fee0fbd4e7be51a9d0351694bd13
    • +
  • SHA256 sum: 8ffe0461ab7d0f5ab5aaf1c4a10f8519c7acf7d808bff987614a8e867edee152
    • +
  • GPG signature: https://download.go.cd/local/patches/15.1.0-2015_11_10/go.jar.asc
    • +
+ +

14.4.0-1356:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.4.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 72409fb8ee9a305b03439747043752bd
    • +
  • SHA256 sum: 452c1cb7518d9654b000d18068729cd9a2072ce8bc262dededebc002f88141f8
    • +
  • GPG signature: https://download.go.cd/local/patches/14.4.0-2015_11_10/go.jar.asc
    • +
+ +

14.3.0-1186:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.3.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 64de38f7363a9345cad5e9c39aaa468e
    • +
  • SHA256 sum: 80d98e12d0b18107840951b2c067edf554a966131373ab0015a585021f46538f
    • +
  • GPG signature: https://download.go.cd/local/patches/14.3.0-2015_11_10/go.jar.asc
    • +
+ +

14.2.0-377:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.2.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 68a711227d7a2cd663f304cf04c87139
    • +
  • SHA256 sum: 6212eb9d0ab59d626e8ea3ec70ae0c34689f0de233502bd2f034fc91017c08f7
    • +
  • GPG signature: https://download.go.cd/local/patches/14.2.0-2015_11_10/go.jar.asc
    • +
+ +

The JAR files above are signed using the usual key used to sign the RPM and DEB installers. The signature file provided can be used to verify it. +The public key is available on MIT PGP Public Key Server. When verified, you'll see that it is signed by the GoCD team:

+ +
$ gpg --verify go.jar.asc go.jar
+gpg: Signature made Mon Nov  9 12:13:21 2015 EST
+gpg:                using RSA key 0x9149B0A6173454C7
+gpg: Good signature from "Go CD (GPG key for signing bintray downloads) <go-cd@googlegroups.com>" [full]
+Primary key fingerprint: 9A43 9A18 CBD0 7C3F F81B  CE75 9149 B0A6 1734 54C7
+
+ +

I don't trust you. How do I generate this patched go.jar myself?

+ +

Glad you asked. Take a look at this.

+ +

Updates:

+ +

Update 1: 9th Nov, 2015 - 1830 EST

+ +

This patch fixes one of the known vectors, but there could be one other, TemplatesImpl, which might be vulnerable. From an early analysis, it doesn't seem to be, since it has some security and expects a JDK property to be set, before it is used. If we find more about it, this post will be updated. Even if it is vulnerable, there might not be much that can be done, because that is a class provided by the Java Runtime Environment itself. The long-term fix for issues such as this is to move away from Java serialization.

+ +

See these articles for more information: InfoQ: Remotely Exploitable Java Zero Day Exploits through Deserialization and +The Java Deserialization Bug.

+ +

Update 2: 10th Nov, 2015 - 1900 EST

+ +
    +
  • Updated the "How do I apply this patch?" section with information about patches for older, supported versions.
    • +
  • Removed the shell script for generating the patched version. It was too much information on this page. It is +linked.
    • +
  • Go is not vulnerable to the TemplatesImpl payload.
    • +
+ +

Note: This post will be updated with more information, as we find it and with information about patches for older, supported +installers. If you need help, please email the GoCD community mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections/index.html b/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections/index.html new file mode 100644 index 000000000..fd42820ad --- /dev/null +++ b/pr-1714/2015/11/09/deserialization-vulnerability-commons-collections/index.html @@ -0,0 +1,340 @@ + + + + + + + + + + + + + + + + Vulnerability in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Vulnerability in GoCD - Java deserialization and Apache commons-collections

+

GoCD Team

+

+

+
+ +
+

This post contains information about a security patch available for GoCD 15.2 (and soon, earlier versions). If you're using GoCD 15.2 in production, and especially if it is available over the internet, it is highly recommended to apply this patch immediately.

+ +

[Any updates to this post are available starting here]

+ +

What is the vulnerability?

+ +

As a part of AppSecCali 2015, a talk highlighted a +vulnerability +using Java deserialization with Apache commons-collections, a very commonly used library in Java-based +applications. Though the talk focused on other applications, GoCD is affected too.

+ +

Impact:

+ +

This is a potentially serious issue and applying the patch is recommended, since it is a remote code execution +vulnerability in Java deserialization (exploited using Apache commons-collections).

+ +

The impact is reduced a bit, because as far as we are able to determine, this attack on the server is possible only by +having the authentication certificate of an already-registered and enabled Go Agent, because of the way the GoCD Server +and GoCD Agent communicate using a secure connection.

+ +

So, even if you have a GoCD server exposed to the internet, you're not immediately vulnerable, as far as we have been +able to determine (and we have given it a lot of thought).

+ +

Risks of applying this patch:

+ +

This patch removes the known vector for this attack, as recommended by the vulnerability report. But, given the urgency, +this patch hasn't been extensively tested. There is a small potential for the Go Server to fail. However, given that the +patch is just a replaced JAR file, you can replace the original JAR file, if that happens and contact us on the +GoCD community mailing list.

+ +

We have been using this patch on https://build.go.cd and it has been fine. We will update this post if anything new is +found.

+ +

Risks of not applying this patch:

+ +

The GoCD server will be open to arbitrary remote code execution from anyone who has access to a registered Go Agent (or +the agent.jks file of such an agent). This is true of an agent which was once registered and then disabled as well.

+ +

How do I apply this patch?

+ +

Steps to apply the patch:

+ +
    +
  1. +

    Download the appropriate go.jar file mentioned below, for your version of the Go Server and verify its checksums.

    +
    2. +
  2. Find out the location of your go.jar file and take a backup. On different ways of installation of Go, this can be in different places: +
      +
    • On Windows: It is usually in C:\Program Files (x86)\Go Server\go.jar
      • +
    • On Debian and RPM based installations: It is usually in /usr/share/go-server/go.jar
      • +
    • On zip installers: It is in the base directory where you start the Go Server from.
      • +
    +
    3. +
  3. +

    Now that you have a backup of go.jar, stop the Go Server and replace go.jar with the one you downloaded.

    +
    4. +
  4. Restart the Go Server.
    5. +
+ +

All of your agents will now fetch the new agent JAR as well, and restart themselves. Depending on the number of agents +you have, this might take a little while (same as an upgrade of the Go Server).

+ +

The different patches available are:

+ +

15.2.0-2248:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/15.2.0-2015_11_09/go.jar
    • +
  • MD5 checksum: 0872e4eefceaaf842a69d8b55ec6a2d0
    • +
  • SHA256 sum: eecee2b04c9bd46e74c5c999585683daf164fe41b39151dfcc3f0642561fd4c5
    • +
  • GPG signature: https://download.go.cd/local/patches/15.2.0-2015_11_09/go.jar.asc
    • +
+ +

15.1.0-1863:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/15.1.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 5981fee0fbd4e7be51a9d0351694bd13
    • +
  • SHA256 sum: 8ffe0461ab7d0f5ab5aaf1c4a10f8519c7acf7d808bff987614a8e867edee152
    • +
  • GPG signature: https://download.go.cd/local/patches/15.1.0-2015_11_10/go.jar.asc
    • +
+ +

14.4.0-1356:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.4.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 72409fb8ee9a305b03439747043752bd
    • +
  • SHA256 sum: 452c1cb7518d9654b000d18068729cd9a2072ce8bc262dededebc002f88141f8
    • +
  • GPG signature: https://download.go.cd/local/patches/14.4.0-2015_11_10/go.jar.asc
    • +
+ +

14.3.0-1186:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.3.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 64de38f7363a9345cad5e9c39aaa468e
    • +
  • SHA256 sum: 80d98e12d0b18107840951b2c067edf554a966131373ab0015a585021f46538f
    • +
  • GPG signature: https://download.go.cd/local/patches/14.3.0-2015_11_10/go.jar.asc
    • +
+ +

14.2.0-377:

+ +
    +
  • JAR file: https://download.go.cd/local/patches/14.2.0-2015_11_10/go.jar
    • +
  • MD5 checksum: 68a711227d7a2cd663f304cf04c87139
    • +
  • SHA256 sum: 6212eb9d0ab59d626e8ea3ec70ae0c34689f0de233502bd2f034fc91017c08f7
    • +
  • GPG signature: https://download.go.cd/local/patches/14.2.0-2015_11_10/go.jar.asc
    • +
+ +

The JAR files above are signed using the usual key used to sign the RPM and DEB installers. The signature file provided can be used to verify it. +The public key is available on MIT PGP Public Key Server. When verified, you'll see that it is signed by the GoCD team:

+ +
$ gpg --verify go.jar.asc go.jar
+gpg: Signature made Mon Nov  9 12:13:21 2015 EST
+gpg:                using RSA key 0x9149B0A6173454C7
+gpg: Good signature from "Go CD (GPG key for signing bintray downloads) <go-cd@googlegroups.com>" [full]
+Primary key fingerprint: 9A43 9A18 CBD0 7C3F F81B  CE75 9149 B0A6 1734 54C7
+
+ +

I don't trust you. How do I generate this patched go.jar myself?

+ +

Glad you asked. Take a look at this.

+ +

Updates:

+ +

Update 1: 9th Nov, 2015 - 1830 EST

+ +

This patch fixes one of the known vectors, but there could be one other, TemplatesImpl, which might be vulnerable. From an early analysis, it doesn't seem to be, since it has some security and expects a JDK property to be set, before it is used. If we find more about it, this post will be updated. Even if it is vulnerable, there might not be much that can be done, because that is a class provided by the Java Runtime Environment itself. The long-term fix for issues such as this is to move away from Java serialization.

+ +

See these articles for more information: InfoQ: Remotely Exploitable Java Zero Day Exploits through Deserialization and +The Java Deserialization Bug.

+ +

Update 2: 10th Nov, 2015 - 1900 EST

+ +
    +
  • Updated the "How do I apply this patch?" section with information about patches for older, supported versions.
    • +
  • Removed the shell script for generating the patched version. It was too much information on this page. It is +linked.
    • +
  • Go is not vulnerable to the TemplatesImpl payload.
    • +
+ +

Note: This post will be updated with more information, as we find it and with information about patches for older, supported +installers. If you need help, please email the GoCD community mailing list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/09/index.html b/pr-1714/2015/11/09/index.html new file mode 100644 index 000000000..869528f34 --- /dev/null +++ b/pr-1714/2015/11/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 9 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/18.html b/pr-1714/2015/11/18.html new file mode 100644 index 000000000..2d43874fa --- /dev/null +++ b/pr-1714/2015/11/18.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/18/Open-Source-Tests.html b/pr-1714/2015/11/18/Open-Source-Tests.html new file mode 100644 index 000000000..24a27903a --- /dev/null +++ b/pr-1714/2015/11/18/Open-Source-Tests.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + Open Source Tests | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Open Source Tests - The GoCD way

+

Rajiesh

+

+

+
+ +
+

Why Open Source Tests

+ +

Testing open source projects has its own set of problems. +Unit and integration tests are added by the contributors, however end to end tests are added later or neglected. +There are several reasons for this like not being aware of the end to end flow, complexity of automating tests for end to end systems. +However to be confident about a release we need end to end tests. To maintain the healthy balance defined by a test pyramid, every release must have its system test cases reviewed and maintained and this needs collaboration.

+ +

At GoCD we are finally open sourcing our functional tests, we believe open sourcing system tests will - improve quality through collaboration, make regression tests efficient, give the community a detailed picture of the system behavior and act as a live document for users.

+ +

How GoCD is continuously tested

+ +

Let's take a brief tour of how GoCD does continuous testing. GoCD is built, tested and deployed using GoCD itself. Here's a snapshot of the GoCD build pipeline.

+ +

GoCD value stream map

+ +

GoCD is tested using "Server in-the-box" model. In this model we define the system under test - its scope and its boundaries. +External dependencies for the system under test (SUT) say git or yum repo are stubbed out or built into the SUT itself. +The pipeline "qa packages" does the necessary jobs to bundle the stub code with production code, and then pass on the packages to "smoke" and "acceptance" pipelines to run the tests. +Upon successful runs of the upstream pipelines, "distributions-all" pipeline packages only the production code.

+ +

Test Classifications

+ +

Below are the set of functional test types modeled into the GoCD pipelines. +Each of them are run on single or multiple agents as per the size of the tests. +Every agent will be cleaned of any previous versions of the build when a new build is started.

+ +
    +
  • +

    Smoke: As per the classic definition "smoke tests" validates the basic functionality of the system under test. It runs on 2 GoCD server agents - one on windows and one on linux

    +
    • +
  • +

    Acceptance: These tests validates the necessary set of tests for each functionality or use case flow. It does not execute every scenario in the flow, but validates all possible flows. These tests are run on a total of 17 agents. Smoke and Acceptance are triggered by the upstream pipeline ‘qa packages".

    +
    • +
  • +

    Regression: A detailed set of tests which is exhaustive and comprehensive. This job is executed parallel in 17 agents. Regression tests are triggered when Smoke and Acceptance pipelines pass.

    +
    • +
  • +

    Performance: This pipeline is under development, will discuss this on a separate blog

    +
    • +
+ +

How this model helps continuous delivery

+ +

Continuous delivery depends on a faster feedback loop. +However Functional and Performance tests end up being bottlenecks. +This can be reduced to a great extent by distributed tests.

+ +

Though not the only solution, it's a first step to achieving the faster feedback loop. +Further enhancements and optimizations are on the way.

+ +

Twist to Gauge Migration

+ +

GoCD functional tests were initially developed using Thoughtworks Twist automation tool. +Since Twist has hit end-of-life as a product and is being replaced by Gauge, we've migrated our tests to Gauge. +Moving to Gauge now helps us open source these tests (Twist was a commercial product).

+ +

Twist to Gauge migration is handled by the migration plugin bundled in Twist.

+ +

Gauge Specifications

+ +

Gauge specifications are in markdown language making it more readable. Gauge specs intend to be live documents of the system behavior

+ +

Gauge specifications

+ +

Gauge Reports

+ +

Gauge produces reports in an easily readable format and provides specification execution details like steps executed, time for each spec execution, overall test execution time, steps and specs passed, what failed and the screen shot of the failure page.

+ +

Gauge Reports

+ +

Conclusion

+ +

A distributed test environment and parallel execution are ways to support CD, by making long running tests short and getting faster feedback. +Here we have addressed functional tests, we will soon be working on the performance tests.

+ +

If you would like to contribute to GoCD tests, please visit GoCD Functional Tests for contribution.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/18/Open-Source-Tests/index.html b/pr-1714/2015/11/18/Open-Source-Tests/index.html new file mode 100644 index 000000000..568b1dad0 --- /dev/null +++ b/pr-1714/2015/11/18/Open-Source-Tests/index.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + Open Source Tests | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Open Source Tests - The GoCD way

+

Rajiesh

+

+

+
+ +
+

Why Open Source Tests

+ +

Testing open source projects has its own set of problems. +Unit and integration tests are added by the contributors, however end to end tests are added later or neglected. +There are several reasons for this like not being aware of the end to end flow, complexity of automating tests for end to end systems. +However to be confident about a release we need end to end tests. To maintain the healthy balance defined by a test pyramid, every release must have its system test cases reviewed and maintained and this needs collaboration.

+ +

At GoCD we are finally open sourcing our functional tests, we believe open sourcing system tests will - improve quality through collaboration, make regression tests efficient, give the community a detailed picture of the system behavior and act as a live document for users.

+ +

How GoCD is continuously tested

+ +

Let's take a brief tour of how GoCD does continuous testing. GoCD is built, tested and deployed using GoCD itself. Here's a snapshot of the GoCD build pipeline.

+ +

GoCD value stream map

+ +

GoCD is tested using "Server in-the-box" model. In this model we define the system under test - its scope and its boundaries. +External dependencies for the system under test (SUT) say git or yum repo are stubbed out or built into the SUT itself. +The pipeline "qa packages" does the necessary jobs to bundle the stub code with production code, and then pass on the packages to "smoke" and "acceptance" pipelines to run the tests. +Upon successful runs of the upstream pipelines, "distributions-all" pipeline packages only the production code.

+ +

Test Classifications

+ +

Below are the set of functional test types modeled into the GoCD pipelines. +Each of them are run on single or multiple agents as per the size of the tests. +Every agent will be cleaned of any previous versions of the build when a new build is started.

+ +
    +
  • +

    Smoke: As per the classic definition "smoke tests" validates the basic functionality of the system under test. It runs on 2 GoCD server agents - one on windows and one on linux

    +
    • +
  • +

    Acceptance: These tests validates the necessary set of tests for each functionality or use case flow. It does not execute every scenario in the flow, but validates all possible flows. These tests are run on a total of 17 agents. Smoke and Acceptance are triggered by the upstream pipeline ‘qa packages".

    +
    • +
  • +

    Regression: A detailed set of tests which is exhaustive and comprehensive. This job is executed parallel in 17 agents. Regression tests are triggered when Smoke and Acceptance pipelines pass.

    +
    • +
  • +

    Performance: This pipeline is under development, will discuss this on a separate blog

    +
    • +
+ +

How this model helps continuous delivery

+ +

Continuous delivery depends on a faster feedback loop. +However Functional and Performance tests end up being bottlenecks. +This can be reduced to a great extent by distributed tests.

+ +

Though not the only solution, it's a first step to achieving the faster feedback loop. +Further enhancements and optimizations are on the way.

+ +

Twist to Gauge Migration

+ +

GoCD functional tests were initially developed using Thoughtworks Twist automation tool. +Since Twist has hit end-of-life as a product and is being replaced by Gauge, we've migrated our tests to Gauge. +Moving to Gauge now helps us open source these tests (Twist was a commercial product).

+ +

Twist to Gauge migration is handled by the migration plugin bundled in Twist.

+ +

Gauge Specifications

+ +

Gauge specifications are in markdown language making it more readable. Gauge specs intend to be live documents of the system behavior

+ +

Gauge specifications

+ +

Gauge Reports

+ +

Gauge produces reports in an easily readable format and provides specification execution details like steps executed, time for each spec execution, overall test execution time, steps and specs passed, what failed and the screen shot of the failure page.

+ +

Gauge Reports

+ +

Conclusion

+ +

A distributed test environment and parallel execution are ways to support CD, by making long running tests short and getting faster feedback. +Here we have addressed functional tests, we will soon be working on the performance tests.

+ +

If you would like to contribute to GoCD tests, please visit GoCD Functional Tests for contribution.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/18/index.html b/pr-1714/2015/11/18/index.html new file mode 100644 index 000000000..da3efd081 --- /dev/null +++ b/pr-1714/2015/11/18/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/11/index.html b/pr-1714/2015/11/index.html new file mode 100644 index 000000000..0a29c2e63 --- /dev/null +++ b/pr-1714/2015/11/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12.html b/pr-1714/2015/12.html new file mode 100644 index 000000000..fb225fb35 --- /dev/null +++ b/pr-1714/2015/12.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/22.html b/pr-1714/2015/12/22.html new file mode 100644 index 000000000..b261a68f7 --- /dev/null +++ b/pr-1714/2015/12/22.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 22 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/22/gocd-in-2016.html b/pr-1714/2015/12/22/gocd-in-2016.html new file mode 100644 index 000000000..1dba36cfd --- /dev/null +++ b/pr-1714/2015/12/22/gocd-in-2016.html @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + GoCD in 2016 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Roadmap - GoCD in 2016

+

Aravind SV

+

+

+
+ +
+

GoCD 15.3 has been released! I think now is a great time to talk about GoCD in +2016. In a way, a lot of work in 2015 was setup towards enabling more +improvements in 2016. There was some "debt" that needed paying off, some +performance improvements that needed to be made, some APIs that needed to be +standardized and improved and more. All of it was valuable, in my opinion, and +were necessary to do a lot more exciting work!

+ +

This is what the high-level idea for GoCD in 2016 looks like:

+ +
    +
  • Be universal and easily extensible through usable extension points (both APIs and plugins)
    • +
  • Produce more content around how GoCD can be used effectively and even how your CD journey can be more effective
    • +
  • Have a better getting-started experience both in the application itself and on gocd.org
    • +
  • Better support for clouds and containers
    • +
+ +

Let's take a look at each of these areas and what kind of changes can be expected in the GoCD ecosystem for it, in 2016:

+ +

Be universal and easily extensible

+ +

For a while now, GoCD has been introducing new extension points to make new +plugins possible. In 2015, the +material endpoint was introduced to enable GoCD to use newer kinds of +materials. This led to plugins which trigger builds on GitHub pull requests, Git +feature branches, Gerrit change sets and some plugins which have not been +open-sourced by the authoring organizations yet. Similarly, the notification +endpoint allowed, among other plugins, notifiers for Slack, HipChat, Gerrit, +Websockets, etc.

+ +

In 2016, this trend should continue with a more comprehensive notification +endpoint which includes events related to agents registering and going missing, +jobs and pipelines starting and finishing, config changes, user actions, logins +and more. This should allow users and tool authors to write better dashboards, +generate better information out of GoCD and integrate it better with external +tools.

+ +

Adding to this, the elastic agent endpoint, the plan for +which is to start work in the new year, should enable quite interesting +integrations and make GoCD more effective on clouds and containers. More on this +below!

+ +

Finally, the APIs in GoCD are continuously improving and are being +extended. This will continue in 2016, and enable better integrations and UX. The +idea is to continue to be API-first and any change to GoCD itself involves a +re-think of the API surrounding it and often, work is done on the API and it is +improved before the actual change is made.

+ +

Produce more content around GoCD and CD itself

+ +

Though there is some growing content around how CD ("Continuous Delivery") +works, it is hard to find good guides around a lot of concepts and practices +around it. It's definitely hard to find it in one place. The closest is probably +the excellent book, Continuous Delivery, +co-authored by Jez Humble and Dave Farley. However, there's definitely room for +more content, including recent experience reports and learnings. I'd like us to +start this with some ideas and posts, but this is something with which you, +wonderful reader, can help. Guest posts or even edits and comments will always +be useful. This need not be content generated solely by this community. I feel +that it should link out to good external references as needed and be a good +place for everyone to learn more about CD in general and improve their +craft. Look out for more of this in 2016!

+ +

Have a better getting-started experience

+ +

GoCD's getting started experience can definitely be better. As with everything +these days, users' expectations regarding their initial and continued +experiences keeps changing. In GoCD's world, I think one of the problems is that +the domain of GoCD's +concepts +takes getting used to. Other problems include a not-so-easy installation and +evaluation experience, better documentation targeted towards a new user ("How do +I create my first pipeline?"), better dashboard UI, a much better +gocd.org site which points to all this information in a meaningful +way, etc.

+ +

In 2016, GoCD and the ecosystem around it should change to make this possible +and though changing everything in the application is probably a multi-year +effort, the already-mentioned changes to the API have been making this easier to +do, since the frontend and the backend are more clearly separated. If you have +good UI/UX skills and are willing to help, just join us on GitHub +discussions and let us know!

+ +

Better support for clouds and containers

+ +

Though this comes up last in this list, it is definitely not the least +important. In fact, the current plan is to start on this very soon. The cloud +and container ecosystems (who am I kidding, no one seems to be able to look +beyond "docker") have been exploding over the last couple of years (at least) +and there is a definite trend of interest and move towards both of them and +beyond them. As a CD system, I feel that GoCD can definitely help users make use +of their investments in clouds and containers more effective, when used for CD.

+ +

Elastic agents have been mentioned earlier in this document. In 2016, the idea +is to use elastic agents and create a docker-container-per-job plugin, which +runs a fully isolated job with dependency management done inside the docker +image rather than the GoCD agent ("You need Maven 3.0? Sure. Update your +Dockerfile and it will be taken care of. You won't cause issues with this other +pipeline which needs Maven 2.0."). With elastic agents, this can be done +transparently and a GoCD agent can be brought up inside a container temporarily +and a build can be executed and the agent torn down and thrown away. To make +this work really well will involve some exciting changes to the GoCD Agent +infrastructure, like moving away from a pure Java agent to a language-agnostic +one (umm, I'm going to go for full buzz points and say, "golang") and pure JSON +communication between the agent and the server. Though Docker is the one with +the most interest from everyone, there are many other competing container +ecosystems and the fact that the elastic agent endpoint is open and usable by +anyone will help plugin authors do this for other ecosystems, if there is +interest.

+ +

GoCD also needs to be more easily usable in cloud ecosystems. First of all that +means making it more easy to evaluate it on different cloud offerings. Second, +it means having the ability to spin up agents on different cloud offerings and +have them connect to the server. Though this is possible today, and is used by +some users of GoCD, there is a perception that it cannot be done. I think this +scenario should be explicitly thought about and there should be enough content +and related infrastructure provided to make it easy for anyone to run their CD +system in the cloud. Again, with elastic agents, they can be brought up and down +on demand and can be really cost-effective.

+ +

For Thoughtworks' supported offering, the idea is +to pick a cloud provider (most likely AWS, as it is an obvious choice for many) +and provide deeper integration with it, along with the ability to have fully +elastic agents. Similarly, there is a vast ecosystem around containers to work +with, and it is likely that there will be much deeper integration with +Kubernetes or Mesos and maybe more. I am excited about the potential of this to +change how organizations think about their builds, repeatability of builds and +isolation. All topics that interest me and many on the GoCD team as well.

+ +

What else?

+ +

There is some work from 2015 that will need to be wrapped up: the new config UI +for one, getting Tomasz' config +changes merged in, some API endpoints +and smaller changes. But, apart from that, I'd like the core GoCD team to focus +on what is in this document. Though this is different from 2015 where we asked +the community to help choose ideas, I feel that it is worth trying to set a +direction and work towards it rather than try and design by committee.

+ +

There is always room for feedback and I'm not averse to changing this as it is +not set in stone. However, I would like to be convinced for the need to change +this. :) If you really feel strongly about something which is not on this and +you think it should be fixed, you're always welcome to work on it and submit a +pull request and the team has been responsive to them. In fact, the feeling of +knowing that someone else cares enough to take the effort to understand the code +and submit a pull request is … something else. We love it!

+ +

We have had some wonderful contributors in 2015, and I hope they continue in +2016 and beyond and I hope we continue to get new contributors interested in +making GoCD even better.

+ +

You will also see many more releases in 2016 than earlier. The plan is to not +tie releases to features and either release on a date or maybe even every green +regression build. The team and I feel that the groundwork to do this will be +valuable and it will be useful to the many users who are looking to get the +latest and greatest more often, and provide quicker feedback.

+ +

Summary

+ +

Lots of exciting changes coming up: APIs, endpoints, clouds, containers, Docker, +better content, getting started, UI and UX changes … and more. It's going to be +a great year!

+ +

Please pardon the verbosity of this post. A better one with pictures and better +communication might be on its way soon. :) I just wanted the information out here +earlier than later.

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/22/gocd-in-2016/index.html b/pr-1714/2015/12/22/gocd-in-2016/index.html new file mode 100644 index 000000000..03071dc45 --- /dev/null +++ b/pr-1714/2015/12/22/gocd-in-2016/index.html @@ -0,0 +1,369 @@ + + + + + + + + + + + + + + + + GoCD in 2016 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Roadmap - GoCD in 2016

+

Aravind SV

+

+

+
+ +
+

GoCD 15.3 has been released! I think now is a great time to talk about GoCD in +2016. In a way, a lot of work in 2015 was setup towards enabling more +improvements in 2016. There was some "debt" that needed paying off, some +performance improvements that needed to be made, some APIs that needed to be +standardized and improved and more. All of it was valuable, in my opinion, and +were necessary to do a lot more exciting work!

+ +

This is what the high-level idea for GoCD in 2016 looks like:

+ +
    +
  • Be universal and easily extensible through usable extension points (both APIs and plugins)
    • +
  • Produce more content around how GoCD can be used effectively and even how your CD journey can be more effective
    • +
  • Have a better getting-started experience both in the application itself and on gocd.org
    • +
  • Better support for clouds and containers
    • +
+ +

Let's take a look at each of these areas and what kind of changes can be expected in the GoCD ecosystem for it, in 2016:

+ +

Be universal and easily extensible

+ +

For a while now, GoCD has been introducing new extension points to make new +plugins possible. In 2015, the +material endpoint was introduced to enable GoCD to use newer kinds of +materials. This led to plugins which trigger builds on GitHub pull requests, Git +feature branches, Gerrit change sets and some plugins which have not been +open-sourced by the authoring organizations yet. Similarly, the notification +endpoint allowed, among other plugins, notifiers for Slack, HipChat, Gerrit, +Websockets, etc.

+ +

In 2016, this trend should continue with a more comprehensive notification +endpoint which includes events related to agents registering and going missing, +jobs and pipelines starting and finishing, config changes, user actions, logins +and more. This should allow users and tool authors to write better dashboards, +generate better information out of GoCD and integrate it better with external +tools.

+ +

Adding to this, the elastic agent endpoint, the plan for +which is to start work in the new year, should enable quite interesting +integrations and make GoCD more effective on clouds and containers. More on this +below!

+ +

Finally, the APIs in GoCD are continuously improving and are being +extended. This will continue in 2016, and enable better integrations and UX. The +idea is to continue to be API-first and any change to GoCD itself involves a +re-think of the API surrounding it and often, work is done on the API and it is +improved before the actual change is made.

+ +

Produce more content around GoCD and CD itself

+ +

Though there is some growing content around how CD ("Continuous Delivery") +works, it is hard to find good guides around a lot of concepts and practices +around it. It's definitely hard to find it in one place. The closest is probably +the excellent book, Continuous Delivery, +co-authored by Jez Humble and Dave Farley. However, there's definitely room for +more content, including recent experience reports and learnings. I'd like us to +start this with some ideas and posts, but this is something with which you, +wonderful reader, can help. Guest posts or even edits and comments will always +be useful. This need not be content generated solely by this community. I feel +that it should link out to good external references as needed and be a good +place for everyone to learn more about CD in general and improve their +craft. Look out for more of this in 2016!

+ +

Have a better getting-started experience

+ +

GoCD's getting started experience can definitely be better. As with everything +these days, users' expectations regarding their initial and continued +experiences keeps changing. In GoCD's world, I think one of the problems is that +the domain of GoCD's +concepts +takes getting used to. Other problems include a not-so-easy installation and +evaluation experience, better documentation targeted towards a new user ("How do +I create my first pipeline?"), better dashboard UI, a much better +gocd.org site which points to all this information in a meaningful +way, etc.

+ +

In 2016, GoCD and the ecosystem around it should change to make this possible +and though changing everything in the application is probably a multi-year +effort, the already-mentioned changes to the API have been making this easier to +do, since the frontend and the backend are more clearly separated. If you have +good UI/UX skills and are willing to help, just join us on GitHub +discussions and let us know!

+ +

Better support for clouds and containers

+ +

Though this comes up last in this list, it is definitely not the least +important. In fact, the current plan is to start on this very soon. The cloud +and container ecosystems (who am I kidding, no one seems to be able to look +beyond "docker") have been exploding over the last couple of years (at least) +and there is a definite trend of interest and move towards both of them and +beyond them. As a CD system, I feel that GoCD can definitely help users make use +of their investments in clouds and containers more effective, when used for CD.

+ +

Elastic agents have been mentioned earlier in this document. In 2016, the idea +is to use elastic agents and create a docker-container-per-job plugin, which +runs a fully isolated job with dependency management done inside the docker +image rather than the GoCD agent ("You need Maven 3.0? Sure. Update your +Dockerfile and it will be taken care of. You won't cause issues with this other +pipeline which needs Maven 2.0."). With elastic agents, this can be done +transparently and a GoCD agent can be brought up inside a container temporarily +and a build can be executed and the agent torn down and thrown away. To make +this work really well will involve some exciting changes to the GoCD Agent +infrastructure, like moving away from a pure Java agent to a language-agnostic +one (umm, I'm going to go for full buzz points and say, "golang") and pure JSON +communication between the agent and the server. Though Docker is the one with +the most interest from everyone, there are many other competing container +ecosystems and the fact that the elastic agent endpoint is open and usable by +anyone will help plugin authors do this for other ecosystems, if there is +interest.

+ +

GoCD also needs to be more easily usable in cloud ecosystems. First of all that +means making it more easy to evaluate it on different cloud offerings. Second, +it means having the ability to spin up agents on different cloud offerings and +have them connect to the server. Though this is possible today, and is used by +some users of GoCD, there is a perception that it cannot be done. I think this +scenario should be explicitly thought about and there should be enough content +and related infrastructure provided to make it easy for anyone to run their CD +system in the cloud. Again, with elastic agents, they can be brought up and down +on demand and can be really cost-effective.

+ +

For Thoughtworks' supported offering, the idea is +to pick a cloud provider (most likely AWS, as it is an obvious choice for many) +and provide deeper integration with it, along with the ability to have fully +elastic agents. Similarly, there is a vast ecosystem around containers to work +with, and it is likely that there will be much deeper integration with +Kubernetes or Mesos and maybe more. I am excited about the potential of this to +change how organizations think about their builds, repeatability of builds and +isolation. All topics that interest me and many on the GoCD team as well.

+ +

What else?

+ +

There is some work from 2015 that will need to be wrapped up: the new config UI +for one, getting Tomasz' config +changes merged in, some API endpoints +and smaller changes. But, apart from that, I'd like the core GoCD team to focus +on what is in this document. Though this is different from 2015 where we asked +the community to help choose ideas, I feel that it is worth trying to set a +direction and work towards it rather than try and design by committee.

+ +

There is always room for feedback and I'm not averse to changing this as it is +not set in stone. However, I would like to be convinced for the need to change +this. :) If you really feel strongly about something which is not on this and +you think it should be fixed, you're always welcome to work on it and submit a +pull request and the team has been responsive to them. In fact, the feeling of +knowing that someone else cares enough to take the effort to understand the code +and submit a pull request is … something else. We love it!

+ +

We have had some wonderful contributors in 2015, and I hope they continue in +2016 and beyond and I hope we continue to get new contributors interested in +making GoCD even better.

+ +

You will also see many more releases in 2016 than earlier. The plan is to not +tie releases to features and either release on a date or maybe even every green +regression build. The team and I feel that the groundwork to do this will be +valuable and it will be useful to the many users who are looking to get the +latest and greatest more often, and provide quicker feedback.

+ +

Summary

+ +

Lots of exciting changes coming up: APIs, endpoints, clouds, containers, Docker, +better content, getting started, UI and UX changes … and more. It's going to be +a great year!

+ +

Please pardon the verbosity of this post. A better one with pictures and better +communication might be on its way soon. :) I just wanted the information out here +earlier than later.

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/22/index.html b/pr-1714/2015/12/22/index.html new file mode 100644 index 000000000..58e3ec96a --- /dev/null +++ b/pr-1714/2015/12/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 22 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/28.html b/pr-1714/2015/12/28.html new file mode 100644 index 000000000..e1720edb7 --- /dev/null +++ b/pr-1714/2015/12/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines.html b/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines.html new file mode 100644 index 000000000..e1b472d76 --- /dev/null +++ b/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines.html @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + + + Continuous delivery through pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: GoCD - Continuous Delivery through pipelines

+

Nenad Bozic

+

+

+
+ +
+

In order to compete in today's IT market, you must be truly agile, you must listen +to your customers and deliver features in a timely manner. In order to support business +development and marketing in their lean strategies we, as developers, must leverage +fast deliveries and deployments and test automations. Continuous Delivery makes it possible +to continuously adapt software in line with user feedback, shifts in the market and changes +of business strategy. Testing, support, development and operations work together as one +delivery team to automate and streamline the build, test and release process.

+ +

There are a lot of quality tools out there. For a long time, we used Jenkins as the most +widespread CD tool, with a great community and a lot of plugins and integrations with +other tools. What we lacked was a natural pipeline flow and good visualization. We also +lacked some more advanced features like pipeline dependencies, conditional triggering jobs +from many pipelines, templating etc. We needed to look elsewhere and we decided to go with +GoCD, a product by Thoughtworks which became open source in 2014. It is a Java/Ruby on Rails +advanced continuous integration and release management system, according to their website. +The major reason why we chose it was that they modeled pipelines as first class citizens +and that, in our opinion, it used right abstraction for delivery pipeline. +But let us start from the beginning.

+ +

GoCD overview

+ +

At the highest level, Go consists of two main components, the Go Server and multiple Go Agents. +The system works on a pull model where agents periodically poll the server for work.

+ +

GoCD Architecture

+ +

The main flow of Go goes through a couple of following stages:

+ +
    +
  1. User adds a pipeline with material
    2. +
  2. MDU (material update sub-system) notices a new commit
    3. +
  3. Scheduler schedules a build
    4. +
  4. Go agents poll for work and get assignments
    5. +
  5. Agent does the work
    6. +
+ +

Let's talk about the main building blocks of Go. As stated before, the main abstract is a +pipeline which is the highest unit of work with its inputs and outputs. The input object +of one pipeline is called a material and it can be either a version control resource +(Git, Gerrit, Subversion, Mercurial) or an output from another pipeline. The output of a +pipeline is called an artifact. Since there is one server and multiple agents, +there is no guarantee that the whole pipeline will be performed by the same Go agent. +Artifacts are copied to Go server and picked up by agents that require them for their jobs.

+ +

Each pipeline consists of one or more stages, where each stage has one or more jobs and +each job has one or more tasks. Granularity to this level of details is done because of +parallelism. Inside pipeline stages are sequential and can be triggered automatically on +success or manually. Within each stage, jobs are parallel. The outcome of a stage is considered +as failure if at least one job fails. Again, tasks within each job are also sequential.

+ +

After installing Go server and client there is no need for an extensive configuration. +However, it is recommended to create a separate partition on a computer's hard disk for +Go server artifacts (artifacts can grow over time and problems may occur). In server +configuration, there is also an admin tab for URL configuration. We needed to get feedback +on failing builds, so we integrated Go with LDAP so each user of Go had an email and could +subscribe on build information based on preferred filters. +Here is a link +which explains the authentication process.

+ +

It is worth mentioning that GoCD has a powerful API for power users where the entire +configuration can be performed via REST. It has great documentation with examples, +JSON requests and response. Here is a link to +GoCD API documentation.

+ +

Pipeline dependencies

+ +

Go supports pipeline dependencies. Artifacts defined in upstream dependencies can be +accessed by downstream dependency. Downstream pipeline can be configured either to +be triggered automatically (for example for building on development environment) or +manually (for example for building on production environment).

+ +

Multiple pipeline dependency is called fan-in and it ensures that pipeline is triggered +only when all upstream dependencies finish. Upstream dependencies consist of other +pipelines or version control which make them powerful. If you have a client server +application and have functional tests on the client's side, which depend on the server +being updated, you can make a client functional test pipeline which will trigger on commit +on client and successful build and deploy of server side.

+ +

GoCD pipeline dependencies tab showing fan-in

+ +

The additional challenge here is a diamond-like dependency, where it is not enough for both +upstream dependencies to finish but to have right versions. The following diagram depicts +that problem. Here, configuration is really important, C1 must be set as material for both +C2 and C3 and C2 and C3 are materials for the pipeline Package. The package will auto trigger +when both C2 and C3 go green with the same version of code.

+ +

Pipeline dependencies show a Diamond dependency Problem

+ +

Pipeline templates

+ +

Template engine is a great effort and time saver. Each pipeline can be promoted to template +and, based on that template, other pipelines can be built with a few clicks. We used this +extensively for deployment pipelines. Usually, there are multiple environments +(development, stage, UAT, production) and deployment process is the same with only a +few parameters which are different. You can create one deployment pipeline and test it. +When you make sure it works, extract the template out of it and clone the deployment +pipelines for other environments. Differences can usually be covered with a couple of +parameters, which can be created upon pipeline creation.

+ +

Conclusion

+ +

In the introductory part, we mentioned that pipelines are modeled in GoCD as first +class citizens. In Jenkins, you can order a row of boxes and let the flow go through +each one of them until it finishes. Each box here in Jenkins is equivalent to each task +in GoCD. Moreover, in GoCD, each box is pipeline itself with its stages, jobs and tasks.

+ +

GoCD is a fairly new player in the automation world with refreshing UI and a couple of +nice concepts. The community is still growing but it is responsive. We had a couple of +problems which we posted on StackOverflow and usually got answers pretty quickly. +We are using Gerrit/Github plugin +to notify Github PR on failed or passed build which is being actively developed. +New releases are pushed frequently. Documentation is great, especially API documentation. +It's our pleasure to use such a great UI and a couple of nice advanced features. +You have a possibility to model your pipeline in a great variety of ways. +There are some features missing but we in SmartCat are all +about open source so, in the future, we will try to help this project and start contributing.

+ +

About the author

+ +

This is guest post by Nenad Bozic, one of Co-Founders of SmartCat. You can find out more about +Nenad and SmartCat team on their website.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines/index.html b/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines/index.html new file mode 100644 index 000000000..ce2561e65 --- /dev/null +++ b/pr-1714/2015/12/28/gocd-continuous-delivery-through-pipelines/index.html @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + + + Continuous delivery through pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Guest post: GoCD - Continuous Delivery through pipelines

+

Nenad Bozic

+

+

+
+ +
+

In order to compete in today's IT market, you must be truly agile, you must listen +to your customers and deliver features in a timely manner. In order to support business +development and marketing in their lean strategies we, as developers, must leverage +fast deliveries and deployments and test automations. Continuous Delivery makes it possible +to continuously adapt software in line with user feedback, shifts in the market and changes +of business strategy. Testing, support, development and operations work together as one +delivery team to automate and streamline the build, test and release process.

+ +

There are a lot of quality tools out there. For a long time, we used Jenkins as the most +widespread CD tool, with a great community and a lot of plugins and integrations with +other tools. What we lacked was a natural pipeline flow and good visualization. We also +lacked some more advanced features like pipeline dependencies, conditional triggering jobs +from many pipelines, templating etc. We needed to look elsewhere and we decided to go with +GoCD, a product by Thoughtworks which became open source in 2014. It is a Java/Ruby on Rails +advanced continuous integration and release management system, according to their website. +The major reason why we chose it was that they modeled pipelines as first class citizens +and that, in our opinion, it used right abstraction for delivery pipeline. +But let us start from the beginning.

+ +

GoCD overview

+ +

At the highest level, Go consists of two main components, the Go Server and multiple Go Agents. +The system works on a pull model where agents periodically poll the server for work.

+ +

GoCD Architecture

+ +

The main flow of Go goes through a couple of following stages:

+ +
    +
  1. User adds a pipeline with material
    2. +
  2. MDU (material update sub-system) notices a new commit
    3. +
  3. Scheduler schedules a build
    4. +
  4. Go agents poll for work and get assignments
    5. +
  5. Agent does the work
    6. +
+ +

Let's talk about the main building blocks of Go. As stated before, the main abstract is a +pipeline which is the highest unit of work with its inputs and outputs. The input object +of one pipeline is called a material and it can be either a version control resource +(Git, Gerrit, Subversion, Mercurial) or an output from another pipeline. The output of a +pipeline is called an artifact. Since there is one server and multiple agents, +there is no guarantee that the whole pipeline will be performed by the same Go agent. +Artifacts are copied to Go server and picked up by agents that require them for their jobs.

+ +

Each pipeline consists of one or more stages, where each stage has one or more jobs and +each job has one or more tasks. Granularity to this level of details is done because of +parallelism. Inside pipeline stages are sequential and can be triggered automatically on +success or manually. Within each stage, jobs are parallel. The outcome of a stage is considered +as failure if at least one job fails. Again, tasks within each job are also sequential.

+ +

After installing Go server and client there is no need for an extensive configuration. +However, it is recommended to create a separate partition on a computer's hard disk for +Go server artifacts (artifacts can grow over time and problems may occur). In server +configuration, there is also an admin tab for URL configuration. We needed to get feedback +on failing builds, so we integrated Go with LDAP so each user of Go had an email and could +subscribe on build information based on preferred filters. +Here is a link +which explains the authentication process.

+ +

It is worth mentioning that GoCD has a powerful API for power users where the entire +configuration can be performed via REST. It has great documentation with examples, +JSON requests and response. Here is a link to +GoCD API documentation.

+ +

Pipeline dependencies

+ +

Go supports pipeline dependencies. Artifacts defined in upstream dependencies can be +accessed by downstream dependency. Downstream pipeline can be configured either to +be triggered automatically (for example for building on development environment) or +manually (for example for building on production environment).

+ +

Multiple pipeline dependency is called fan-in and it ensures that pipeline is triggered +only when all upstream dependencies finish. Upstream dependencies consist of other +pipelines or version control which make them powerful. If you have a client server +application and have functional tests on the client's side, which depend on the server +being updated, you can make a client functional test pipeline which will trigger on commit +on client and successful build and deploy of server side.

+ +

GoCD pipeline dependencies tab showing fan-in

+ +

The additional challenge here is a diamond-like dependency, where it is not enough for both +upstream dependencies to finish but to have right versions. The following diagram depicts +that problem. Here, configuration is really important, C1 must be set as material for both +C2 and C3 and C2 and C3 are materials for the pipeline Package. The package will auto trigger +when both C2 and C3 go green with the same version of code.

+ +

Pipeline dependencies show a Diamond dependency Problem

+ +

Pipeline templates

+ +

Template engine is a great effort and time saver. Each pipeline can be promoted to template +and, based on that template, other pipelines can be built with a few clicks. We used this +extensively for deployment pipelines. Usually, there are multiple environments +(development, stage, UAT, production) and deployment process is the same with only a +few parameters which are different. You can create one deployment pipeline and test it. +When you make sure it works, extract the template out of it and clone the deployment +pipelines for other environments. Differences can usually be covered with a couple of +parameters, which can be created upon pipeline creation.

+ +

Conclusion

+ +

In the introductory part, we mentioned that pipelines are modeled in GoCD as first +class citizens. In Jenkins, you can order a row of boxes and let the flow go through +each one of them until it finishes. Each box here in Jenkins is equivalent to each task +in GoCD. Moreover, in GoCD, each box is pipeline itself with its stages, jobs and tasks.

+ +

GoCD is a fairly new player in the automation world with refreshing UI and a couple of +nice concepts. The community is still growing but it is responsive. We had a couple of +problems which we posted on StackOverflow and usually got answers pretty quickly. +We are using Gerrit/Github plugin +to notify Github PR on failed or passed build which is being actively developed. +New releases are pushed frequently. Documentation is great, especially API documentation. +It's our pleasure to use such a great UI and a couple of nice advanced features. +You have a possibility to model your pipeline in a great variety of ways. +There are some features missing but we in SmartCat are all +about open source so, in the future, we will try to help this project and start contributing.

+ +

About the author

+ +

This is guest post by Nenad Bozic, one of Co-Founders of SmartCat. You can find out more about +Nenad and SmartCat team on their website.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/28/index.html b/pr-1714/2015/12/28/index.html new file mode 100644 index 000000000..a4939dac1 --- /dev/null +++ b/pr-1714/2015/12/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/12/index.html b/pr-1714/2015/12/index.html new file mode 100644 index 000000000..75b10a2ca --- /dev/null +++ b/pr-1714/2015/12/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/index.html b/pr-1714/2015/index.html new file mode 100644 index 000000000..a38b6ba33 --- /dev/null +++ b/pr-1714/2015/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/page/2.html b/pr-1714/2015/page/2.html new file mode 100644 index 000000000..530026450 --- /dev/null +++ b/pr-1714/2015/page/2.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 2 of 3

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/page/2/index.html b/pr-1714/2015/page/2/index.html new file mode 100644 index 000000000..f05120dd3 --- /dev/null +++ b/pr-1714/2015/page/2/index.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 2 of 3

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/page/3.html b/pr-1714/2015/page/3.html new file mode 100644 index 000000000..f4c9474de --- /dev/null +++ b/pr-1714/2015/page/3.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2015/page/3/index.html b/pr-1714/2015/page/3/index.html new file mode 100644 index 000000000..5c788c7ef --- /dev/null +++ b/pr-1714/2015/page/3/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016.html b/pr-1714/2016.html new file mode 100644 index 000000000..9fec749a1 --- /dev/null +++ b/pr-1714/2016.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01.html b/pr-1714/2016/01.html new file mode 100644 index 000000000..f8bd53aa2 --- /dev/null +++ b/pr-1714/2016/01.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/17.html b/pr-1714/2016/01/17.html new file mode 100644 index 000000000..20772e3be --- /dev/null +++ b/pr-1714/2016/01/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/17/index.html b/pr-1714/2016/01/17/index.html new file mode 100644 index 000000000..8d8136afb --- /dev/null +++ b/pr-1714/2016/01/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/17/not-done-unless-its-done.html b/pr-1714/2016/01/17/not-done-unless-its-done.html new file mode 100644 index 000000000..4ca2029bd --- /dev/null +++ b/pr-1714/2016/01/17/not-done-unless-its-done.html @@ -0,0 +1,343 @@ + + + + + + + + + + + + + + + + It's not CD if you can't deploy right now | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Part 1 - It's not Continuous Delivery if you can't deploy right now

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+ +
+
+ Ingredients ready to go into the oven +
+ +
+

+ This is the first in a series of articles that will cover the types of pipelines you should implement to ensure your software is truly ready for production at any time. The culture changes required in most organizations are incredibly important, but I'm going to focus on some technical practices in this series. +

+ +

+ Years ago, when I was in management, I had a favorite rule. If asked "is something done?" the answer could not include the word "except" or any of its synonyms. +

+ +

+ "It's done except for…" = "no". +

+ +

+ I hear people say all the time that they're practicing continuous delivery. This declaration is often followed by something like, "I can let the security team know anytime", or "I just have to run the performance tests". If you can't push your software to production right now, you're not done with your continuous delivery journey. +

+
+
+
+ +

Some of the things you might not be running but should …

+ +

In this article I'm going to give an overview of some of the types of pipelines that you should be running if you want your software to be ready to ship at all times. Of course this is not an exhaustive list, there are most likely things that are specific to what you're doing that you should have, just as there are probably things that I will list that don't make sense for you. The point is that everything possible should be automated as part of your deployment pipeline.

+ +

Over the next several weeks I'll be writing more about each of these types of pipelines, follow me on Twitter if you would like to know when new articles come out at @kmugrage.

+ +

Security testing

+ +
+
+ sheet music that is not yet recorded +
+ +
+

+All too often this is the primary category of tasks that don't get run until everything else is "done". This often results in issues that are very hard to track down since the time between tests has been very long. By writing these tests all the time you'll have a much easier time tracking down issues before they become too hard to fix. +

+ +

+Many people feel it's not the greatest idea to have the same person writing the security tests who is writing the code. There's also the question of skillset; great security people are not common. It's important that you use a Continuous Delivery server that is capable of using more than one build material for a single pipeline. That way these tests will run whenever the code or the tests are updated. +

+
+
+
+ +

Performance testing

+ +

This one is probably the hardest to run all the time if for no other reason than hardware costs. To properly performance test many applications takes a serious dedication of resources. Luckily public and private cloud infrastructures have made this somewhat easier. Consider having a pipeline where the first stage spins up the machines you need either as virtual machines or containers, runs the tests, and then shuts down those machines.

+ +

In this day of "search for a term, hit the link, wait no more than 2 seconds for the page to load" performance is critical. To make matters worse, performance issues are often very hard to track down. You want to know as soon as possible if you've introduced a problem.

+ +

Management of the environments

+ +

It's been said many times that it's much easier to break an application by messing up the environment that it is by doing something wrong in the source code. If something like the security advisory comes out and you need to update systems as soon as possible, you should be able to commit the change to a configuration management tool, have that change picked up by your continuous delivery system and run it through exactly the same process as a code change.

+ +

Testing of the deployment itself

+ +
+
+ Blank canvas +
+ +
+

+ This isn't really a type of pipeline all by itself. This is the concept that you should be deploying the software exactly the same way in every environment that you plan to deploy in production. Unfortunately it's still not uncommon for people to copy over files to a QA server run test and only then run the actual deployment tool that pushes the same software to a production server. +

+ +

+ No matter how you're doing your actual production deployment, whether that is shell scripts, dedicated tools, configuration management tools, or others, you should be deploying in exactly the same way everywhere else. Consider using tools that can read environment specific details from environment variables or other inputs. +

+
+
+
+ +

Why wouldn't you do this?

+ +

One of the biggest objections I hear to running all of these types of pipelines on every change is that the pipeline will take too long to run. This is why having a continuous delivery server that's capable of running multiple pipelines in parallel while ensuring that software doesn't go any further if any of those pipelines fail is so important.

+ +

The other objection I hear the most is that people simply lack the automation around these areas. This is certainly valid, and I don't want to pretend that any of this is easy to do. Don't be afraid to start with what you can, and then add other things your pipeline as your capabilities grow. A continuous delivery pipeline is a bit of a living system it should be evolving along with your processes.

+ +

What are the other big ones?

+ +

I'm very interested in hearing other types of pipelines that you find useful.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/17/not-done-unless-its-done/index.html b/pr-1714/2016/01/17/not-done-unless-its-done/index.html new file mode 100644 index 000000000..923ce0e9f --- /dev/null +++ b/pr-1714/2016/01/17/not-done-unless-its-done/index.html @@ -0,0 +1,343 @@ + + + + + + + + + + + + + + + + It's not CD if you can't deploy right now | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Part 1 - It's not Continuous Delivery if you can't deploy right now

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+ +
+
+ Ingredients ready to go into the oven +
+ +
+

+ This is the first in a series of articles that will cover the types of pipelines you should implement to ensure your software is truly ready for production at any time. The culture changes required in most organizations are incredibly important, but I'm going to focus on some technical practices in this series. +

+ +

+ Years ago, when I was in management, I had a favorite rule. If asked "is something done?" the answer could not include the word "except" or any of its synonyms. +

+ +

+ "It's done except for…" = "no". +

+ +

+ I hear people say all the time that they're practicing continuous delivery. This declaration is often followed by something like, "I can let the security team know anytime", or "I just have to run the performance tests". If you can't push your software to production right now, you're not done with your continuous delivery journey. +

+
+
+
+ +

Some of the things you might not be running but should …

+ +

In this article I'm going to give an overview of some of the types of pipelines that you should be running if you want your software to be ready to ship at all times. Of course this is not an exhaustive list, there are most likely things that are specific to what you're doing that you should have, just as there are probably things that I will list that don't make sense for you. The point is that everything possible should be automated as part of your deployment pipeline.

+ +

Over the next several weeks I'll be writing more about each of these types of pipelines, follow me on Twitter if you would like to know when new articles come out at @kmugrage.

+ +

Security testing

+ +
+
+ sheet music that is not yet recorded +
+ +
+

+All too often this is the primary category of tasks that don't get run until everything else is "done". This often results in issues that are very hard to track down since the time between tests has been very long. By writing these tests all the time you'll have a much easier time tracking down issues before they become too hard to fix. +

+ +

+Many people feel it's not the greatest idea to have the same person writing the security tests who is writing the code. There's also the question of skillset; great security people are not common. It's important that you use a Continuous Delivery server that is capable of using more than one build material for a single pipeline. That way these tests will run whenever the code or the tests are updated. +

+
+
+
+ +

Performance testing

+ +

This one is probably the hardest to run all the time if for no other reason than hardware costs. To properly performance test many applications takes a serious dedication of resources. Luckily public and private cloud infrastructures have made this somewhat easier. Consider having a pipeline where the first stage spins up the machines you need either as virtual machines or containers, runs the tests, and then shuts down those machines.

+ +

In this day of "search for a term, hit the link, wait no more than 2 seconds for the page to load" performance is critical. To make matters worse, performance issues are often very hard to track down. You want to know as soon as possible if you've introduced a problem.

+ +

Management of the environments

+ +

It's been said many times that it's much easier to break an application by messing up the environment that it is by doing something wrong in the source code. If something like the security advisory comes out and you need to update systems as soon as possible, you should be able to commit the change to a configuration management tool, have that change picked up by your continuous delivery system and run it through exactly the same process as a code change.

+ +

Testing of the deployment itself

+ +
+
+ Blank canvas +
+ +
+

+ This isn't really a type of pipeline all by itself. This is the concept that you should be deploying the software exactly the same way in every environment that you plan to deploy in production. Unfortunately it's still not uncommon for people to copy over files to a QA server run test and only then run the actual deployment tool that pushes the same software to a production server. +

+ +

+ No matter how you're doing your actual production deployment, whether that is shell scripts, dedicated tools, configuration management tools, or others, you should be deploying in exactly the same way everywhere else. Consider using tools that can read environment specific details from environment variables or other inputs. +

+
+
+
+ +

Why wouldn't you do this?

+ +

One of the biggest objections I hear to running all of these types of pipelines on every change is that the pipeline will take too long to run. This is why having a continuous delivery server that's capable of running multiple pipelines in parallel while ensuring that software doesn't go any further if any of those pipelines fail is so important.

+ +

The other objection I hear the most is that people simply lack the automation around these areas. This is certainly valid, and I don't want to pretend that any of this is easy to do. Don't be afraid to start with what you can, and then add other things your pipeline as your capabilities grow. A continuous delivery pipeline is a bit of a living system it should be evolving along with your processes.

+ +

What are the other big ones?

+ +

I'm very interested in hearing other types of pipelines that you find useful.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/25.html b/pr-1714/2016/01/25.html new file mode 100644 index 000000000..1e329ef9d --- /dev/null +++ b/pr-1714/2016/01/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 25 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery.html b/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery.html new file mode 100644 index 000000000..6ad1a0e4a --- /dev/null +++ b/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery.html @@ -0,0 +1,319 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery Part 1 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Ready for Continuous Delivery? + Attribution +
+ +
+ + +
+

Part 1 - Are you ready for Continuous Delivery?

+

David Rice and Aravind SV

+

+ Are you ready for Continuous Delivery +

+
+ +
+ +

During the 10 plus years Thoughtworks has been in the Continuous Delivery ecosystem, we've regularly come across people +wanting to try our tools GoCD and Snap CI as they start their journey toward Continuous Delivery (CD). Very often, +in attempting to support teams new to CD, we suggest that they pause any tool evaluation and consider whether their +organization is actually ready to embark on this journey. If you do not frankly assess your teams' readiness, the result +can be a massive failure. The path to CD should not start by immediately adopting a CD tool.

+ +

This is the first part of a series of posts about Continuous Delivery infrastructure, culture, and process. In this +first post, we'll present questions you need to answer honestly about your own people, teams, and organization to +determine your readiness for Continuous Delivery.

+ +

Part 1: Practices

+ +

Do you put everything into version control?

+ +

A foundation of CD is the ability to put a specific version of your application into a given environment at any point in +time. CD is actually quite fussy about this. It's a must. And this can only be done by:

+ +
    +
  • Putting everything needed to make your application into a version control system
    • +
  • Any time you change anything, push the changes to version control.
    • +
  • Write an automated script that, given a version, checks out everything from version control and assembles your application.
    • +
+ +

CD is impossible when software teams (or the people on a single team) work in isolation from each other. When +development work happens in isolation, large periods of integration and testing are required at the end of the +development phase. This results in long periods during which your application cannot be released. Avoiding these lengthy +integration phases requires that your work be as visible to, and usable by, others as soon as possible. Our preferred +mechanism for doing this is called trunk-based development:

+ +
    +
  • Everyone regularly pulls others' changes from version control.
    • +
  • Everyone regularly pushes their changes to version control.
    • +
  • Everyone works in the same place in version control, typically called "trunk" or "master".
    • +
+ +

If you are new to trunk-based development, it might sound ridiculous. But the practices of CI, unit testing, and +trunk-based development all playing together, not only makes it reasonable, but a truly pleasant way of working.We don't +have space here to go into the details of making trunk-based development work, but know that it cannot work without +version control.

+ +

Even if you aren't planning to do CD, start putting everything into version control now. And we mean everything. Not +just your source code. Everything can include images, database scripts, tests, configuration, libraries, documentation, +and more. Source code won't be enough if you need to get back to a specific version of your application, infrastructure, +etc. Also, this encourages your entire team—not just the developers—to collaborate.

+ +

Do your developers practice Continuous Integration (CI)?

+ +

For CD to be successful, the entire organization must trust that your software is high quality and always in a working +state. In terms of development team practices, CI is the fundamental building block to achieve this level of trust.

+ +

So what is CI? Well, much has been written about CI, but here's the TL;DR version:

+ +
    +
  • Developers check code into trunk/master multiple times each day.
    • +
  • Developers maintain a suite of unit tests that verify the code works before merge, locally, and post merge, on an integration machine or CI server.
    • +
+ +

The end result is a development team that has high trust that the code in trunk/master actually works. This will leave +the development team more willing to push code to testers, or even production, more regularly. With this in place, trust +between the groups will quickly grow.

+ +

Our experience has been that development teams can only move quickly by combining unit testing, refactoring, and +CI. That's a discussion too broad for discussion here, but know that your teams will never deliver at a fast pace +without CI.

+ +

If your developers are not practicing CI we would recommend putting your move to CD on hold and shift your focus +entirely to supporting the adoption of CI.

+ +

Do you automate relentlessly?

+ +

CD is very dependent on automation. Automation everywhere is crucial to achieving trusted, one-click, low drama +deployments. Manual processes are error-prone and do not lend themselves to repeatability. To practice CD, the entire +team needs to get into the mindset of relentless automation of nearly everything.

+ +

This mindset means asking "Why can't this be automated?" every time anyone on the team does anything manually more than +once. Some components and aspects of your process that need automation are:

+ +
    +
  • Tests at different levels, such as unit, integration, UI, regression, security and performance
    • +
  • Database schema creation, data migration and rollback
    • +
  • Installer creation and signing (if you have them)
    • +
  • Generation of documentation for every release
    • +
  • Last-mile deployment of your application to any environment
    • +
  • Provisioning of infrastructure all the way from test environments to production
    • +
  • Provisioning of developer workspaces
    • +
+ +

We mentioned error reduction and repeatability. There are dozens of other compelling reasons to relentlessly automate. We have a few favorites:

+ +
    +
  • Scripts codify team knowledge. This ups your bus factor. That's a good thing.
    • +
  • It encourages consistency across environments. Once you have a script working in one environment, you'll want to use it everywhere.
    • +
  • The output of these scripts provides a detailed audit trail that is hard to match manually.
    • +
+ +

Relentless automation might seem daunting, particularly if you're focused on something that truly cannot be automated, +such as exploratory testing. In our experience, there will be many more parts of your process that can be automated than +those that cannot. The best approach is to figure out the manual processes you are already using, and then make a plan +to gradually automate them. As you begin to achieve small successes, you will want to automate more and more.

+ +

If your team is hesitant to automate and cannot be convinced about the need, you might have to consider if there's +enough maturity in your team to move toward CD. An automation mindset is a firm prerequisite for CD.

+ +

Conclusion

+ +

There are numerous small steps you can take early in your CD journey that will have immediate, positive impacts. Don't +waste time flailing around with CD tools if you've got a bunch of low-hanging fruit that can provide high value +quickly. Also, this approach will set you up for success once you do feel the need to adopt an end-to-end CD tool.

+ +

In coming posts we will present similar sets of questions for you to consider in the areas of infrastructure, +application design, process, and culture.

+ +

Update: Part 2 of this series, discussing feedback loops, has been published.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery/index.html b/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery/index.html new file mode 100644 index 000000000..f525d276d --- /dev/null +++ b/pr-1714/2016/01/25/are-you-ready-for-continuous-delivery/index.html @@ -0,0 +1,319 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery Part 1 | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Ready for Continuous Delivery? + Attribution +
+ +
+ + +
+

Part 1 - Are you ready for Continuous Delivery?

+

David Rice and Aravind SV

+

+ Are you ready for Continuous Delivery +

+
+ +
+ +

During the 10 plus years Thoughtworks has been in the Continuous Delivery ecosystem, we've regularly come across people +wanting to try our tools GoCD and Snap CI as they start their journey toward Continuous Delivery (CD). Very often, +in attempting to support teams new to CD, we suggest that they pause any tool evaluation and consider whether their +organization is actually ready to embark on this journey. If you do not frankly assess your teams' readiness, the result +can be a massive failure. The path to CD should not start by immediately adopting a CD tool.

+ +

This is the first part of a series of posts about Continuous Delivery infrastructure, culture, and process. In this +first post, we'll present questions you need to answer honestly about your own people, teams, and organization to +determine your readiness for Continuous Delivery.

+ +

Part 1: Practices

+ +

Do you put everything into version control?

+ +

A foundation of CD is the ability to put a specific version of your application into a given environment at any point in +time. CD is actually quite fussy about this. It's a must. And this can only be done by:

+ +
    +
  • Putting everything needed to make your application into a version control system
    • +
  • Any time you change anything, push the changes to version control.
    • +
  • Write an automated script that, given a version, checks out everything from version control and assembles your application.
    • +
+ +

CD is impossible when software teams (or the people on a single team) work in isolation from each other. When +development work happens in isolation, large periods of integration and testing are required at the end of the +development phase. This results in long periods during which your application cannot be released. Avoiding these lengthy +integration phases requires that your work be as visible to, and usable by, others as soon as possible. Our preferred +mechanism for doing this is called trunk-based development:

+ +
    +
  • Everyone regularly pulls others' changes from version control.
    • +
  • Everyone regularly pushes their changes to version control.
    • +
  • Everyone works in the same place in version control, typically called "trunk" or "master".
    • +
+ +

If you are new to trunk-based development, it might sound ridiculous. But the practices of CI, unit testing, and +trunk-based development all playing together, not only makes it reasonable, but a truly pleasant way of working.We don't +have space here to go into the details of making trunk-based development work, but know that it cannot work without +version control.

+ +

Even if you aren't planning to do CD, start putting everything into version control now. And we mean everything. Not +just your source code. Everything can include images, database scripts, tests, configuration, libraries, documentation, +and more. Source code won't be enough if you need to get back to a specific version of your application, infrastructure, +etc. Also, this encourages your entire team—not just the developers—to collaborate.

+ +

Do your developers practice Continuous Integration (CI)?

+ +

For CD to be successful, the entire organization must trust that your software is high quality and always in a working +state. In terms of development team practices, CI is the fundamental building block to achieve this level of trust.

+ +

So what is CI? Well, much has been written about CI, but here's the TL;DR version:

+ +
    +
  • Developers check code into trunk/master multiple times each day.
    • +
  • Developers maintain a suite of unit tests that verify the code works before merge, locally, and post merge, on an integration machine or CI server.
    • +
+ +

The end result is a development team that has high trust that the code in trunk/master actually works. This will leave +the development team more willing to push code to testers, or even production, more regularly. With this in place, trust +between the groups will quickly grow.

+ +

Our experience has been that development teams can only move quickly by combining unit testing, refactoring, and +CI. That's a discussion too broad for discussion here, but know that your teams will never deliver at a fast pace +without CI.

+ +

If your developers are not practicing CI we would recommend putting your move to CD on hold and shift your focus +entirely to supporting the adoption of CI.

+ +

Do you automate relentlessly?

+ +

CD is very dependent on automation. Automation everywhere is crucial to achieving trusted, one-click, low drama +deployments. Manual processes are error-prone and do not lend themselves to repeatability. To practice CD, the entire +team needs to get into the mindset of relentless automation of nearly everything.

+ +

This mindset means asking "Why can't this be automated?" every time anyone on the team does anything manually more than +once. Some components and aspects of your process that need automation are:

+ +
    +
  • Tests at different levels, such as unit, integration, UI, regression, security and performance
    • +
  • Database schema creation, data migration and rollback
    • +
  • Installer creation and signing (if you have them)
    • +
  • Generation of documentation for every release
    • +
  • Last-mile deployment of your application to any environment
    • +
  • Provisioning of infrastructure all the way from test environments to production
    • +
  • Provisioning of developer workspaces
    • +
+ +

We mentioned error reduction and repeatability. There are dozens of other compelling reasons to relentlessly automate. We have a few favorites:

+ +
    +
  • Scripts codify team knowledge. This ups your bus factor. That's a good thing.
    • +
  • It encourages consistency across environments. Once you have a script working in one environment, you'll want to use it everywhere.
    • +
  • The output of these scripts provides a detailed audit trail that is hard to match manually.
    • +
+ +

Relentless automation might seem daunting, particularly if you're focused on something that truly cannot be automated, +such as exploratory testing. In our experience, there will be many more parts of your process that can be automated than +those that cannot. The best approach is to figure out the manual processes you are already using, and then make a plan +to gradually automate them. As you begin to achieve small successes, you will want to automate more and more.

+ +

If your team is hesitant to automate and cannot be convinced about the need, you might have to consider if there's +enough maturity in your team to move toward CD. An automation mindset is a firm prerequisite for CD.

+ +

Conclusion

+ +

There are numerous small steps you can take early in your CD journey that will have immediate, positive impacts. Don't +waste time flailing around with CD tools if you've got a bunch of low-hanging fruit that can provide high value +quickly. Also, this approach will set you up for success once you do feel the need to adopt an end-to-end CD tool.

+ +

In coming posts we will present similar sets of questions for you to consider in the areas of infrastructure, +application design, process, and culture.

+ +

Update: Part 2 of this series, discussing feedback loops, has been published.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/25/index.html b/pr-1714/2016/01/25/index.html new file mode 100644 index 000000000..3d209a5d1 --- /dev/null +++ b/pr-1714/2016/01/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 25 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/01/index.html b/pr-1714/2016/01/index.html new file mode 100644 index 000000000..c34582802 --- /dev/null +++ b/pr-1714/2016/01/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02.html b/pr-1714/2016/02.html new file mode 100644 index 000000000..942630288 --- /dev/null +++ b/pr-1714/2016/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02/08.html b/pr-1714/2016/02/08.html new file mode 100644 index 000000000..a6383edc2 --- /dev/null +++ b/pr-1714/2016/02/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02/08/index.html b/pr-1714/2016/02/08/index.html new file mode 100644 index 000000000..896073028 --- /dev/null +++ b/pr-1714/2016/02/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02/08/not-done-unless-its-done-security.html b/pr-1714/2016/02/08/not-done-unless-its-done-security.html new file mode 100644 index 000000000..8abb0f50d --- /dev/null +++ b/pr-1714/2016/02/08/not-done-unless-its-done-security.html @@ -0,0 +1,334 @@ + + + + + + + + + + + + + + + + Add Security Testing to Your Deployment Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Part 2 - It's Not CD if You Can't Deploy Right Now: Add Security Testing to Your Deployment Pipelines

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+
+
+ Continuous Delivery Security Testing +
+ +
+

This is the second part of a series called It's not Continuous Delivery if you can't deploy right now. In this part, I'm going to cover some more common tools in security testing pipelines.

+

In my experience, automated security testing is pretty rare in CD pipelines. If the job of a pipeline is to make you confident in your release, confidence in your security is a must have. While it's not practical to try to list them all, I'll give a few examples of tools used for this automation. You can find more here.

+ +

Tests created by your team and run by tools like the ones in this article should be a key part of any deployment pipeline.

+ +
+
+
+ +

Automation is one part of the solution

+ +

Security has to be addressed in a holistic way. Automation is a way to get fast feedback on common security issues. A talented penetration tester will consider scenarios and methods that are not usually automated.

+ +

The goal of automation is to catch the "low-hanging fruit". Are we pushing things to Git we shouldn't be? Are we using an old, vulnerable package we shouldn't? Are we violating our own company's rules?

+ +

Before committing code

+ +

There is a lot you can—and should—do before your code even gets to a pipeline. Generally speaking, CD servers watch your source code repositories for changes and then act on those changes. For many issues, this is too late!

+ +

One of the biggest recurring stories we hear about SSH keys, auth tokens, private keys etc., being checked into source control. There was a story a few years ago where a basic search for private id_rsa keys returned over 600 matches on GitHub alone.

+ +

Consider incorporating tools that check for these things before they are actually added!

+ +

Thoughtworks recently created Talisman, a tool that is installed as a pre-push hook to Git. The idea is to catch issues before they even get into your source code repository.

+ +

Static Application Security Testing (SAST)

+ +

Gartner defines SAST as "a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the 'inside out' in a nonrunning state."

+ +

This starts with having good unit test coverage. Can you authenticate as you should be able to? Are bad authentication requests refused? Are retries being limited properly? Are password policies being properly enforced?

+ +

Very early in your build process, your CD server can run some security-specific, source code level tests. These could look for issues ranging from bad code to policy violations.

+ +

For Ruby applications, this category includes tools like Brakeman and Bundler-audit.

+ +

Brakeman scans the application's source code and can give out lots of different warning types. I particularly like what I'll call policy checking. Someone implements basic authorization when you don't want to allow that? Pipeline stage fails.

+ +

Bundler-audit does pretty much what it sounds like. It checks to see if you're using Gems that have known vulnerabilities.

+ +

For Java applications, Sonatype has some impressive tools in this area. According to one Sonatype study "of the 106 component ‘parts' used in a typical application, on average 24 have known cyber vulnerabilities, which are rated either critical or severe."

+ +

Dynamic Application Security Testing (DAST)

+ +

Again quoting Gartner's definition, these are tools which are "designed to detect conditions indicative of a security vulnerability in an application in its running state".

+ +

The tools that run against your code are a good start, but they aren't accessing the application like a user. Tools such as Burp, OWASP ZAP, w3af and Vega access the application itself, looking for exploit vectors like SQL Injection and cross-site scripting.

+ +

Who creates the tests?

+ +

Normally, I'm a big proponent of tests being written by the developer as (or preferably before) they write the code. With that said, I don't think it's controversial to state that the average software developer isn't very good at security testing. We should also acknowledge that developers do sometimes leave some doors open on purpose.

+ +

I believe security is one of the few areas where having specialists writing and executing the tests is not only acceptable, but preferable. Development teams should seek out these experts and work with them in close collaboration.

+ +

Where do the tests go in the CD pipeline?

+ +

When people ask this question, they are usually trying to decide if security pipelines or stages should be blocking, meaning that the pipeline can't move forward on failures. I definitely think they should block, but that doesn't mean you can't do other types of testing on the same build.

+ +

If your continuous delivery server supports fan-in / fan-out, you can set tests up as entirely separate pipelines that run while other pipelines (or people) are doing other things. In the example below, we've decided that we can go ahead with User Acceptance while the security scans are in progress. We still know that it won't get deployed to our staging environment unless they both pass.

+ +

GoCD value stream map showing fan-in and fan-out

+ +

Reminder: tools don't solve problems

+ +

I've spent the last 15 years working for makers of software development tools. There are only a few things I'm completely sure of, and one of them is that tools do not solve problems by themselves.

+ +

Having the right continuous delivery server (like GoCD) will make your life a lot easier, and having the right security tools will make it easier to find issues fast. None of this is a substitute for expertise.

+ +

How do you start?

+ +

By starting. Pick an area, automate it. Pick another area, automate it. It will take time, but as that time progresses you'll be more and more confident in the security of your application.

+ +

What are some others?

+ +

What are some other tools you like? Add them to the comments.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02/08/not-done-unless-its-done-security/index.html b/pr-1714/2016/02/08/not-done-unless-its-done-security/index.html new file mode 100644 index 000000000..e33befb48 --- /dev/null +++ b/pr-1714/2016/02/08/not-done-unless-its-done-security/index.html @@ -0,0 +1,334 @@ + + + + + + + + + + + + + + + + Add Security Testing to Your Deployment Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

Part 2 - It's Not CD if You Can't Deploy Right Now: Add Security Testing to Your Deployment Pipelines

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+
+
+ Continuous Delivery Security Testing +
+ +
+

This is the second part of a series called It's not Continuous Delivery if you can't deploy right now. In this part, I'm going to cover some more common tools in security testing pipelines.

+

In my experience, automated security testing is pretty rare in CD pipelines. If the job of a pipeline is to make you confident in your release, confidence in your security is a must have. While it's not practical to try to list them all, I'll give a few examples of tools used for this automation. You can find more here.

+ +

Tests created by your team and run by tools like the ones in this article should be a key part of any deployment pipeline.

+ +
+
+
+ +

Automation is one part of the solution

+ +

Security has to be addressed in a holistic way. Automation is a way to get fast feedback on common security issues. A talented penetration tester will consider scenarios and methods that are not usually automated.

+ +

The goal of automation is to catch the "low-hanging fruit". Are we pushing things to Git we shouldn't be? Are we using an old, vulnerable package we shouldn't? Are we violating our own company's rules?

+ +

Before committing code

+ +

There is a lot you can—and should—do before your code even gets to a pipeline. Generally speaking, CD servers watch your source code repositories for changes and then act on those changes. For many issues, this is too late!

+ +

One of the biggest recurring stories we hear about SSH keys, auth tokens, private keys etc., being checked into source control. There was a story a few years ago where a basic search for private id_rsa keys returned over 600 matches on GitHub alone.

+ +

Consider incorporating tools that check for these things before they are actually added!

+ +

Thoughtworks recently created Talisman, a tool that is installed as a pre-push hook to Git. The idea is to catch issues before they even get into your source code repository.

+ +

Static Application Security Testing (SAST)

+ +

Gartner defines SAST as "a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the 'inside out' in a nonrunning state."

+ +

This starts with having good unit test coverage. Can you authenticate as you should be able to? Are bad authentication requests refused? Are retries being limited properly? Are password policies being properly enforced?

+ +

Very early in your build process, your CD server can run some security-specific, source code level tests. These could look for issues ranging from bad code to policy violations.

+ +

For Ruby applications, this category includes tools like Brakeman and Bundler-audit.

+ +

Brakeman scans the application's source code and can give out lots of different warning types. I particularly like what I'll call policy checking. Someone implements basic authorization when you don't want to allow that? Pipeline stage fails.

+ +

Bundler-audit does pretty much what it sounds like. It checks to see if you're using Gems that have known vulnerabilities.

+ +

For Java applications, Sonatype has some impressive tools in this area. According to one Sonatype study "of the 106 component ‘parts' used in a typical application, on average 24 have known cyber vulnerabilities, which are rated either critical or severe."

+ +

Dynamic Application Security Testing (DAST)

+ +

Again quoting Gartner's definition, these are tools which are "designed to detect conditions indicative of a security vulnerability in an application in its running state".

+ +

The tools that run against your code are a good start, but they aren't accessing the application like a user. Tools such as Burp, OWASP ZAP, w3af and Vega access the application itself, looking for exploit vectors like SQL Injection and cross-site scripting.

+ +

Who creates the tests?

+ +

Normally, I'm a big proponent of tests being written by the developer as (or preferably before) they write the code. With that said, I don't think it's controversial to state that the average software developer isn't very good at security testing. We should also acknowledge that developers do sometimes leave some doors open on purpose.

+ +

I believe security is one of the few areas where having specialists writing and executing the tests is not only acceptable, but preferable. Development teams should seek out these experts and work with them in close collaboration.

+ +

Where do the tests go in the CD pipeline?

+ +

When people ask this question, they are usually trying to decide if security pipelines or stages should be blocking, meaning that the pipeline can't move forward on failures. I definitely think they should block, but that doesn't mean you can't do other types of testing on the same build.

+ +

If your continuous delivery server supports fan-in / fan-out, you can set tests up as entirely separate pipelines that run while other pipelines (or people) are doing other things. In the example below, we've decided that we can go ahead with User Acceptance while the security scans are in progress. We still know that it won't get deployed to our staging environment unless they both pass.

+ +

GoCD value stream map showing fan-in and fan-out

+ +

Reminder: tools don't solve problems

+ +

I've spent the last 15 years working for makers of software development tools. There are only a few things I'm completely sure of, and one of them is that tools do not solve problems by themselves.

+ +

Having the right continuous delivery server (like GoCD) will make your life a lot easier, and having the right security tools will make it easier to find issues fast. None of this is a substitute for expertise.

+ +

How do you start?

+ +

By starting. Pick an area, automate it. Pick another area, automate it. It will take time, but as that time progresses you'll be more and more confident in the security of your application.

+ +

What are some others?

+ +

What are some other tools you like? Add them to the comments.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/02/index.html b/pr-1714/2016/02/index.html new file mode 100644 index 000000000..27369e9fd --- /dev/null +++ b/pr-1714/2016/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03.html b/pr-1714/2016/03.html new file mode 100644 index 000000000..d76cfa503 --- /dev/null +++ b/pr-1714/2016/03.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/15.html b/pr-1714/2016/03/15.html new file mode 100644 index 000000000..1fb05b324 --- /dev/null +++ b/pr-1714/2016/03/15.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 15 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops.html b/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops.html new file mode 100644 index 000000000..cbbc450e8 --- /dev/null +++ b/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops.html @@ -0,0 +1,374 @@ + + + + + + + + + + + + + + + + Feedback Loops | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Feedback Loops + + Attribution - Change: Cropped + +
+ +
+ + +
+

Part 2 - Are you ready for Continuous Delivery: Feedback loops

+

David Rice

+

+ Are you ready for Continuous Delivery +

+
+ +
+ +

During the 10 plus years Thoughtworks has been in the Continuous Delivery (CD) ecosystem, we've regularly come across +people wanting to try our tools (GoCD and Snap CI) as they start their journey toward CD. Very often, in attempting to +support teams new to CD, we suggest that they pause any tool evaluation and consider whether their organization is +actually ready to embark on this journey. If you do not frankly assess your team's readiness, the result can be a +massive failure. The path to CD should not start with the immediate adoption of a CD tool.

+ +

In part one of this series, we explored some core development +practices that are prerequisites for CD. In this part, we'll look at a variety of feedback loops—both manual and +automated—your organization should have in place before rolling out CD.

+ +

Feedback loops and Continuous Delivery

+ +

The aim of Continuous Delivery is to release software faster, more reliably, and more frequently. Given that, diagrams +of CD typically depict a linear flow. On the surface, this is quite different from Continuous Integration, which is +usually shown as a loop.

+ +
+ Continuous Integration Cycle +
+ +

But CD as a linear flow is an incomplete picture. A good deployment pipeline has numerous feedback loops along the +way. At each stage of the pipeline, verifications are run. If they pass, the pipeline continues. If they fail, the +pipeline halts and the team responds appropriately to the feedback. The feedback along the way prevents CD from being +chaos. Poor quality will almost never reach production in a well-designed pipeline.

+ +
+ Continuous Delivery feedback loop +
+ +

Most of the feedback loops you find in a deployment pipeline are good practices in and of themselves. You might already +be doing some or most of them. We think you should have many of these in place before moving forward with CD.

+ +

Test automation

+ +

The most common feedback loop in any deployment pipeline is the execution of automated tests. You must have a solid test +automation strategy before attempting CD. Some people like the approach of the +test pyramid. We're actually fine with any sensible approach, as long +as it's fast and reliable. There are myriad types of automated tests, and which ones you use will depend upon your +circumstances. Here, we will take a look at three of the most important types: unit, regression, and performance.

+ +

Unit tests

+ +

Unit tests verify your application at the most granular level, typically methods or classes. They are fast, easy to +maintain, and support rapid change of your application. Unit tests should be the foundation of your automation +strategy. If your teams don't value a thorough and fast unit test suite, they won't be able to move fast or with +confidence.

+ +

Some points to consider when assessing your team:

+ +
    +
  • The suite must be fast. What's fast? A few minutes on a large code base is OK. But faster is better. Slow unit tests +result in a slow, horribly frustrating development flow.
    • +
  • On a mature team, the testers will be comfortable with pushing as much of your test automation as possible into your +unit test layer.
    • +
  • Code coverage is important, but tracking metrics is generally only beneficial for a team learning the basics.
    • +
  • Some frameworks and platforms are known to be slow when it comes to unit tests. Do not fight or subvert a framework to +make tests fast. Instead, consider switching your framework or platform.
    • +
+ +

Regression test suite

+ +

A regression test suite verifies that your entire application actually works. This suite adds a ton of value to a +deployment pipeline. For many, the regression stage of a pipeline gives the confidence needed to deploy. We want to make +a couple of points about this.

+ +

Firstly, regression tests should be 100 percent automated. They are change-detectors and do not require brain power to +execute. A manual regression stage in your deployment process will prove painful. Work to get rid of it. Your testers +can add more value elsewhere.

+ +

Secondly, we reject the notion that a regression suite must mean slow, flaky Selenium tests. Our take is, yes, it's a +fair reputation, but it was earned by many teams doing it wrong. How to author and maintain an automated regression +suite is a book-worthy topic, but quickly:

+ +
    +
  • Don't couple them to small stories or tasks. Only consider them in the context of the entire application.
    • +
  • Relentlessly prune the suite. Keep it tight. Err on the side of leaving something uncovered rather than accepting +duplication.
    • +
  • Treat them as production code. Keep things very clean.
    • +
  • Have programmers write them. Train your testers to code if they are interested in automation. Avoid drag-and-drop +programming.
    • +
  • Do not accept flaky tests. Fix them or get rid of them.
    • +
  • Even the best suites we've seen tend to be slow. Embrace using some combination of hardware, virtualization, and cloud +to parallelize execution.
    • +
+ +

One caveat to note: the best testers will want to do a manual regression every so often, just to help structure how they +think about the application. That's a good thing so long as it's about their being thoughtful and not how you actually +integrate regression checks into your process.

+ +

Performance testing

+ +

Performance testing—verifying that your application meets specific performance criteria—is a massive topic. There's no +one way to do it: your approach will vary according to request volume and data size. There are many varieties: load, +stress, soak, and spike, to name a few. It's too big a topic for this post. That said, we do have some thinking that can +help you assess your maturity:

+ +
    +
  • Do not leave this phase for last. We cannot stress enough just how difficult this practice is and how much time we've +seen sunk into failed efforts. Everything about it is difficult: modeling, standing up an environment, building the +harness, assessing results, building it into your deployment pipeline.
    • +
  • It's critical to test against specific criteria. Don't worry about getting your criteria wrong at first. You can change +the criteria once you have real production data.
    • +
  • Don't assume you'll reach web-scale in month two. You'll waste huge cycles prematurely optimizing both your application +and your tests. (Don't read this as us saying, "Don't consider what your actual scale might be." Just a suggestion that +you be realistic and pragmatic.)
    • +
  • Utilize production monitoring to the greatest extent possible. A canary release can go a long way toward verifying the +performance of a new version of your application.
    • +
+ +

Production monitoring

+ +

Do you have a production monitoring strategy? Feedback loops aren't only for pre-production phases. As much as we try to +achieve dev/prod parity, production is truly a unique environment for most organizations and things can—and do—go wrong.

+ +

Here are some questions to help you assess your readiness:

+ +
    +
  • How quickly does your team know something is broken? Do they learn about it via monitoring? And then how fast can they +respond?
    • +
  • Does your team ignore alerts?
    • +
  • Do your teams tend to invent an approach to monitoring as they go along? Believe it or not, we actually see this a lot +and it's not a good thing. Be as thoughtful about monitoring and alerts as you are with other parts or your application.
    • +
  • Do you keep a database of events so that you can later query for patterns?
    • +
+ +

User testing

+ +

Sitting users down in front of your application and try it out is a critical feedback loop. In an enterprise setting, we +like to see two type of user testing: usability testing and user acceptance testing. Usability testing verifies that +users find the application easy to use. User acceptance testing verifies that users can complete transactions with the +application in a real-world setting. There can be fair bit of overlap between the two types.

+ +

If you do not do user testing, you will struggle getting users to accept frequent releases of new versions. Users will +only like rapid changes if the experience remains usable, consistent, and effective.

+ +

We also want to call out that these feedback loops are manual processes that often require weeks or months of elapsed +time. They are typically not modeled into the deployment pipeline, and that's fine. But do not leave them both batched +up until the end. That's a long wait period and likely an unknown amount of rework before deploying to prod. If you do +this, your process will feel more like waterfall than CD. Run these user tests early and often, while you are writing +the code.

+ +

Exploratory testing

+ +

All this talk of automation does not mean your testers should retire their analytical thinking and learn to program. In +fact, test automation should free up your testers to do what they're best at: use their +brains. Exploratory testing is when a tester is +simultaneously learning about the system, designing tests, and executing tests. It is when a tester gets into a deep +flow, not even knowing what the next test is. This is where a good tester can really shine, doing some of their most +valuable work.

+ +

For most types of applications, a test strategy should include skilled testers performing exploratory testing. This +testing will find problems, teach you about your system, and inform your automated regression suite. As with user +testing, this testing should be done throughout the development process and not as a gate at the end.

+ +

Summary

+ +

This list of feedback loops organizations should have in place before doing CD is not exhaustive (e.g., we didn't +discuss A/B testing). We have presented the more common feedback loops we see where CD has been successful. Obviously +every situation presents different problems and has different needs.

+ +

You don't need to have high marks on everything we have presented to begin your journey to CD. But if you are feeling +only so-so against a majority of them, we'd suggest working on the individual pieces before approaching CD. Once you get +enough of them in place, you will find that you've actually completed a large swath of your journey to Continuous +Delivery.

+ +

In future parts of this series, we plan to explore culture, the last mile, and more.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/index.html b/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/index.html new file mode 100644 index 000000000..dc7b42828 --- /dev/null +++ b/pr-1714/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/index.html @@ -0,0 +1,374 @@ + + + + + + + + + + + + + + + + Feedback Loops | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Feedback Loops + + Attribution - Change: Cropped + +
+ +
+ + +
+

Part 2 - Are you ready for Continuous Delivery: Feedback loops

+

David Rice

+

+ Are you ready for Continuous Delivery +

+
+ +
+ +

During the 10 plus years Thoughtworks has been in the Continuous Delivery (CD) ecosystem, we've regularly come across +people wanting to try our tools (GoCD and Snap CI) as they start their journey toward CD. Very often, in attempting to +support teams new to CD, we suggest that they pause any tool evaluation and consider whether their organization is +actually ready to embark on this journey. If you do not frankly assess your team's readiness, the result can be a +massive failure. The path to CD should not start with the immediate adoption of a CD tool.

+ +

In part one of this series, we explored some core development +practices that are prerequisites for CD. In this part, we'll look at a variety of feedback loops—both manual and +automated—your organization should have in place before rolling out CD.

+ +

Feedback loops and Continuous Delivery

+ +

The aim of Continuous Delivery is to release software faster, more reliably, and more frequently. Given that, diagrams +of CD typically depict a linear flow. On the surface, this is quite different from Continuous Integration, which is +usually shown as a loop.

+ +
+ Continuous Integration Cycle +
+ +

But CD as a linear flow is an incomplete picture. A good deployment pipeline has numerous feedback loops along the +way. At each stage of the pipeline, verifications are run. If they pass, the pipeline continues. If they fail, the +pipeline halts and the team responds appropriately to the feedback. The feedback along the way prevents CD from being +chaos. Poor quality will almost never reach production in a well-designed pipeline.

+ +
+ Continuous Delivery feedback loop +
+ +

Most of the feedback loops you find in a deployment pipeline are good practices in and of themselves. You might already +be doing some or most of them. We think you should have many of these in place before moving forward with CD.

+ +

Test automation

+ +

The most common feedback loop in any deployment pipeline is the execution of automated tests. You must have a solid test +automation strategy before attempting CD. Some people like the approach of the +test pyramid. We're actually fine with any sensible approach, as long +as it's fast and reliable. There are myriad types of automated tests, and which ones you use will depend upon your +circumstances. Here, we will take a look at three of the most important types: unit, regression, and performance.

+ +

Unit tests

+ +

Unit tests verify your application at the most granular level, typically methods or classes. They are fast, easy to +maintain, and support rapid change of your application. Unit tests should be the foundation of your automation +strategy. If your teams don't value a thorough and fast unit test suite, they won't be able to move fast or with +confidence.

+ +

Some points to consider when assessing your team:

+ +
    +
  • The suite must be fast. What's fast? A few minutes on a large code base is OK. But faster is better. Slow unit tests +result in a slow, horribly frustrating development flow.
    • +
  • On a mature team, the testers will be comfortable with pushing as much of your test automation as possible into your +unit test layer.
    • +
  • Code coverage is important, but tracking metrics is generally only beneficial for a team learning the basics.
    • +
  • Some frameworks and platforms are known to be slow when it comes to unit tests. Do not fight or subvert a framework to +make tests fast. Instead, consider switching your framework or platform.
    • +
+ +

Regression test suite

+ +

A regression test suite verifies that your entire application actually works. This suite adds a ton of value to a +deployment pipeline. For many, the regression stage of a pipeline gives the confidence needed to deploy. We want to make +a couple of points about this.

+ +

Firstly, regression tests should be 100 percent automated. They are change-detectors and do not require brain power to +execute. A manual regression stage in your deployment process will prove painful. Work to get rid of it. Your testers +can add more value elsewhere.

+ +

Secondly, we reject the notion that a regression suite must mean slow, flaky Selenium tests. Our take is, yes, it's a +fair reputation, but it was earned by many teams doing it wrong. How to author and maintain an automated regression +suite is a book-worthy topic, but quickly:

+ +
    +
  • Don't couple them to small stories or tasks. Only consider them in the context of the entire application.
    • +
  • Relentlessly prune the suite. Keep it tight. Err on the side of leaving something uncovered rather than accepting +duplication.
    • +
  • Treat them as production code. Keep things very clean.
    • +
  • Have programmers write them. Train your testers to code if they are interested in automation. Avoid drag-and-drop +programming.
    • +
  • Do not accept flaky tests. Fix them or get rid of them.
    • +
  • Even the best suites we've seen tend to be slow. Embrace using some combination of hardware, virtualization, and cloud +to parallelize execution.
    • +
+ +

One caveat to note: the best testers will want to do a manual regression every so often, just to help structure how they +think about the application. That's a good thing so long as it's about their being thoughtful and not how you actually +integrate regression checks into your process.

+ +

Performance testing

+ +

Performance testing—verifying that your application meets specific performance criteria—is a massive topic. There's no +one way to do it: your approach will vary according to request volume and data size. There are many varieties: load, +stress, soak, and spike, to name a few. It's too big a topic for this post. That said, we do have some thinking that can +help you assess your maturity:

+ +
    +
  • Do not leave this phase for last. We cannot stress enough just how difficult this practice is and how much time we've +seen sunk into failed efforts. Everything about it is difficult: modeling, standing up an environment, building the +harness, assessing results, building it into your deployment pipeline.
    • +
  • It's critical to test against specific criteria. Don't worry about getting your criteria wrong at first. You can change +the criteria once you have real production data.
    • +
  • Don't assume you'll reach web-scale in month two. You'll waste huge cycles prematurely optimizing both your application +and your tests. (Don't read this as us saying, "Don't consider what your actual scale might be." Just a suggestion that +you be realistic and pragmatic.)
    • +
  • Utilize production monitoring to the greatest extent possible. A canary release can go a long way toward verifying the +performance of a new version of your application.
    • +
+ +

Production monitoring

+ +

Do you have a production monitoring strategy? Feedback loops aren't only for pre-production phases. As much as we try to +achieve dev/prod parity, production is truly a unique environment for most organizations and things can—and do—go wrong.

+ +

Here are some questions to help you assess your readiness:

+ +
    +
  • How quickly does your team know something is broken? Do they learn about it via monitoring? And then how fast can they +respond?
    • +
  • Does your team ignore alerts?
    • +
  • Do your teams tend to invent an approach to monitoring as they go along? Believe it or not, we actually see this a lot +and it's not a good thing. Be as thoughtful about monitoring and alerts as you are with other parts or your application.
    • +
  • Do you keep a database of events so that you can later query for patterns?
    • +
+ +

User testing

+ +

Sitting users down in front of your application and try it out is a critical feedback loop. In an enterprise setting, we +like to see two type of user testing: usability testing and user acceptance testing. Usability testing verifies that +users find the application easy to use. User acceptance testing verifies that users can complete transactions with the +application in a real-world setting. There can be fair bit of overlap between the two types.

+ +

If you do not do user testing, you will struggle getting users to accept frequent releases of new versions. Users will +only like rapid changes if the experience remains usable, consistent, and effective.

+ +

We also want to call out that these feedback loops are manual processes that often require weeks or months of elapsed +time. They are typically not modeled into the deployment pipeline, and that's fine. But do not leave them both batched +up until the end. That's a long wait period and likely an unknown amount of rework before deploying to prod. If you do +this, your process will feel more like waterfall than CD. Run these user tests early and often, while you are writing +the code.

+ +

Exploratory testing

+ +

All this talk of automation does not mean your testers should retire their analytical thinking and learn to program. In +fact, test automation should free up your testers to do what they're best at: use their +brains. Exploratory testing is when a tester is +simultaneously learning about the system, designing tests, and executing tests. It is when a tester gets into a deep +flow, not even knowing what the next test is. This is where a good tester can really shine, doing some of their most +valuable work.

+ +

For most types of applications, a test strategy should include skilled testers performing exploratory testing. This +testing will find problems, teach you about your system, and inform your automated regression suite. As with user +testing, this testing should be done throughout the development process and not as a gate at the end.

+ +

Summary

+ +

This list of feedback loops organizations should have in place before doing CD is not exhaustive (e.g., we didn't +discuss A/B testing). We have presented the more common feedback loops we see where CD has been successful. Obviously +every situation presents different problems and has different needs.

+ +

You don't need to have high marks on everything we have presented to begin your journey to CD. But if you are feeling +only so-so against a majority of them, we'd suggest working on the individual pieces before approaching CD. Once you get +enough of them in place, you will find that you've actually completed a large swath of your journey to Continuous +Delivery.

+ +

In future parts of this series, we plan to explore culture, the last mile, and more.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/15/index.html b/pr-1714/2016/03/15/index.html new file mode 100644 index 000000000..fcb28c76a --- /dev/null +++ b/pr-1714/2016/03/15/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 15 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/24.html b/pr-1714/2016/03/24.html new file mode 100644 index 000000000..17dcb1d7f --- /dev/null +++ b/pr-1714/2016/03/24.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 24 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/24/how-to-avoid-brittle-code.html b/pr-1714/2016/03/24/how-to-avoid-brittle-code.html new file mode 100644 index 000000000..5db52c2a9 --- /dev/null +++ b/pr-1714/2016/03/24/how-to-avoid-brittle-code.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + How to Avoid Brittle Code | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ How to Avoid Brittle Code +
+ +
+ + +
+

How to Avoid Brittle Code

+

David Rice

+

+

+
+ +
+ +

The most common problem with legacy code is brittleness. A brittle codebase is one that a team cannot change without great pain. In Thoughtworks' 10 years of building products we've learned some hard lessons while trying to keep fairly large codebases malleable, year after year. In this post I'll share what we learned from our biggest challenges. One caveat: my writing down these thoughts isn't my saying we've got it down cold. We still have our share of pain from legacy code. Like any team, we struggle to get better each and every day.

+ +

Upgrade everything, all the time

+ +

You should aspire to upgrade your dependencies and frameworks all the time. OK, so maybe this is almost in the realm of the obvious now. But very few people thought so 10 years ago. And I wonder whether even teams who know this is the right thing to do, actually prioritize it. It just needs to be something you do all the time and not left to be handled via technical debt. Here's why:

+ +
    +
  1. +

    If it hurts, do it more often. One of the most obvious reasons to upgrade all the time is that upgrading can be hard. There's very often an unpredictable cascade of broken dependencies. The amount of work is mostly unknown. Do it more often and it becomes a non-issue. But there's more to this than simple pain avoidance.

    +
    2. +
  2. +

    Another motivator for upgrading dependencies is fixing security vulnerabilities. One of the biggest differences in building software now versus 10 years ago is the seemingly non-stop flow of vulnerability reports against our libraries, frameworks and applications. Fixing vulnerabilities will almost always involve upgrading some of your dependencies. The upgrades must to be easy in order to quickly ship vulnerability fixes.

    +
    3. +
  3. +

    Teams that don't upgrade regularly typically will label the activity as technical debt. Despite the industry being much more willing to talk about technical debt than 10 years ago, it's still a very painful conversation to convince a product manager to pay down technical debt. If your team works in an "upgrade everything all the time mode", you can avoid any conversation around upgrading technical debt altogether.

    +
    4. +
+ +

It's about the unit tests

+ +

The primary pain point for working with legacy code is how long it takes to make changes. So if you intend for your code to be long-lived, you need to ensure that it will be entirely pleasurable for future developers to make changes to it. And there's one element that dominates all others for this: an extremely fast and thorough unit test suite.

+ +

The cycle for adding new features, including any refactoring, is roughly this: write failing test; code; get to green; make it right. If you're doing it right, you're executing a lot of unit tests along the way, sometimes a focused set and sometimes the entire suite. If these tests aren't fast, the development cycle will not be enjoyable. The coding experience should not be: make a couple of changes and sit around for 10 or 20 minutes while tests run. That's a bad place to be.

+ +

Keeping a unit suite fast isn't just about how you design and code. Yes, you can do a lot of things to keep tests fast, such as avoiding files, databases, sockets, creation of huge graphs of objects, etc. But the other key piece is picking frameworks and languages that lend themselves to fast tests. If you find yourself subverting your framework to make your tests fast, you need to consider a different framework. And—yes—you can read this as my being unlikely to use Rails the next time I'm building a traditional multi-page application.

+ +

There's also a consideration about the size of the application. Once a codebase is a certain size, you need to figure out how to split it up. This is the only way to keep a fairly complete understanding of a piece of software in your head. Finding the seams along which to split a monolith is not an academic modeling exercise. You will spend a lot of time playing with your code, moving things around, redesigning, refactoring. Having a fast test suite to quickly validate your work along the way will make this work several orders of magnitude easier.

+ +

Actually, "several orders of magnitude" is likely underselling it. If you need to split up a monolith and have a painfully slow unit test suite, well… you just might be stuck. That's learning a lesson the hard way. So do everything in your power to keep your unit tests extremely fast and able to run in a single thread on a dev machine.

+ +

"Branch by Abstraction" should not be a permanent state

+ +

Long-lived products are going to have a number of tech leads over the years. A certain type of tech lead will come in and start making noise about what stinks in the stack and immediately want to start swapping in new stuff. And that's OK. New shiny toys aren't always bad. For a long-lived codebase, it requires some fresh energy to generate enough momentum to swap out the parts that are no longer holding their weight. That said, I want to make two important points.

+ +

A new tech lead should not swap out any tech until they've been working on the team for two to three months. There's too much context to understand. The new tech lead needs to learn empathy for the team and the codebase. The team and tech lead need to build trust and a rhythm. Better decisions will be made with an initial pause.

+ +

The typical means of swapping out new tech (outside the absurdity of long-lived branches) is to utilize Branch by Abstraction:

+ +
    +
  • An abstraction is placed in front of component X.
    • +
  • Component Y is introduced as a replacement for X
    • +
  • The abstraction routes intelligently between X & Y while…
    • +
  • X is gradually made obsolete
    • +
  • X is removed; the abstraction is maybe removed
    • +
+ +

I have many times seen this process fail to complete due to discovering how difficult it is to remove that final 20% of the old component. I cannot stress enough how painful it is to drag around multiple ways of doing things year after year. It slows everything down and is demoralizing. Branch by Abstraction is a great pattern. It's the only way I'd do this sort of component swapping. But it needs to be accompanied by the team's complete commitment to eliminate the old component within a specified timebox.

+ +

Technical debt can kill you

+ +

Just because we talk about technical debt more than we used to does not provide any guarantee that it will be paid down. Perversely, maintaining a backlog of technical debt makes it easy to never pay it down. It's too easy for a manger to say "It's OK to hold off on that. We've got this other pressing need over here. It's logged. We can come back to it." And in that moment, it's probably a sound decision. But those pressing needs never go away. Urgent lists only grow longer.

+ +

And the situation get worse. My experience is that there is a point when the technical debt backlog grows so onerous that the team will give up on wanting to pay it off. The team will feel hopeless. The developers cannot achieve flow. The business isn't getting new value. I have a few thoughts on how to avoid insurmountable technical debt.

+ +

A good development team won't play the same technical debt card over and over again. When a team realizes it's playing the same type of technical debt card repeatedly, it must bring the pain forward and quickly assume that work into its normal everyday way of working.

+ +

My colleague Badri suggests that a team must agree to take on debt collectively. No one individual has the right to make the codebase worse while signing up the entire team to fix it later.

+ +

Most importantly, technical leaders and product leaders need to trust each other. Neither side should be able to play the "because I said so" card. Good technical leaders understand the priorities of the business. Good product managers value being able to deliver. Both sides need to talk about risks, costs, and benefits. If you can't ship, your technical debt has converted into a business problem and that's bad for everyone.

+ +

There's obviously much more a team can do to write long-lived code: code for the reader, don't be clever, and always think of your future colleagues to name a few. I'd love to hear what you think should be added to this list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/24/how-to-avoid-brittle-code/index.html b/pr-1714/2016/03/24/how-to-avoid-brittle-code/index.html new file mode 100644 index 000000000..4065743e7 --- /dev/null +++ b/pr-1714/2016/03/24/how-to-avoid-brittle-code/index.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + How to Avoid Brittle Code | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ How to Avoid Brittle Code +
+ +
+ + +
+

How to Avoid Brittle Code

+

David Rice

+

+

+
+ +
+ +

The most common problem with legacy code is brittleness. A brittle codebase is one that a team cannot change without great pain. In Thoughtworks' 10 years of building products we've learned some hard lessons while trying to keep fairly large codebases malleable, year after year. In this post I'll share what we learned from our biggest challenges. One caveat: my writing down these thoughts isn't my saying we've got it down cold. We still have our share of pain from legacy code. Like any team, we struggle to get better each and every day.

+ +

Upgrade everything, all the time

+ +

You should aspire to upgrade your dependencies and frameworks all the time. OK, so maybe this is almost in the realm of the obvious now. But very few people thought so 10 years ago. And I wonder whether even teams who know this is the right thing to do, actually prioritize it. It just needs to be something you do all the time and not left to be handled via technical debt. Here's why:

+ +
    +
  1. +

    If it hurts, do it more often. One of the most obvious reasons to upgrade all the time is that upgrading can be hard. There's very often an unpredictable cascade of broken dependencies. The amount of work is mostly unknown. Do it more often and it becomes a non-issue. But there's more to this than simple pain avoidance.

    +
    2. +
  2. +

    Another motivator for upgrading dependencies is fixing security vulnerabilities. One of the biggest differences in building software now versus 10 years ago is the seemingly non-stop flow of vulnerability reports against our libraries, frameworks and applications. Fixing vulnerabilities will almost always involve upgrading some of your dependencies. The upgrades must to be easy in order to quickly ship vulnerability fixes.

    +
    3. +
  3. +

    Teams that don't upgrade regularly typically will label the activity as technical debt. Despite the industry being much more willing to talk about technical debt than 10 years ago, it's still a very painful conversation to convince a product manager to pay down technical debt. If your team works in an "upgrade everything all the time mode", you can avoid any conversation around upgrading technical debt altogether.

    +
    4. +
+ +

It's about the unit tests

+ +

The primary pain point for working with legacy code is how long it takes to make changes. So if you intend for your code to be long-lived, you need to ensure that it will be entirely pleasurable for future developers to make changes to it. And there's one element that dominates all others for this: an extremely fast and thorough unit test suite.

+ +

The cycle for adding new features, including any refactoring, is roughly this: write failing test; code; get to green; make it right. If you're doing it right, you're executing a lot of unit tests along the way, sometimes a focused set and sometimes the entire suite. If these tests aren't fast, the development cycle will not be enjoyable. The coding experience should not be: make a couple of changes and sit around for 10 or 20 minutes while tests run. That's a bad place to be.

+ +

Keeping a unit suite fast isn't just about how you design and code. Yes, you can do a lot of things to keep tests fast, such as avoiding files, databases, sockets, creation of huge graphs of objects, etc. But the other key piece is picking frameworks and languages that lend themselves to fast tests. If you find yourself subverting your framework to make your tests fast, you need to consider a different framework. And—yes—you can read this as my being unlikely to use Rails the next time I'm building a traditional multi-page application.

+ +

There's also a consideration about the size of the application. Once a codebase is a certain size, you need to figure out how to split it up. This is the only way to keep a fairly complete understanding of a piece of software in your head. Finding the seams along which to split a monolith is not an academic modeling exercise. You will spend a lot of time playing with your code, moving things around, redesigning, refactoring. Having a fast test suite to quickly validate your work along the way will make this work several orders of magnitude easier.

+ +

Actually, "several orders of magnitude" is likely underselling it. If you need to split up a monolith and have a painfully slow unit test suite, well… you just might be stuck. That's learning a lesson the hard way. So do everything in your power to keep your unit tests extremely fast and able to run in a single thread on a dev machine.

+ +

"Branch by Abstraction" should not be a permanent state

+ +

Long-lived products are going to have a number of tech leads over the years. A certain type of tech lead will come in and start making noise about what stinks in the stack and immediately want to start swapping in new stuff. And that's OK. New shiny toys aren't always bad. For a long-lived codebase, it requires some fresh energy to generate enough momentum to swap out the parts that are no longer holding their weight. That said, I want to make two important points.

+ +

A new tech lead should not swap out any tech until they've been working on the team for two to three months. There's too much context to understand. The new tech lead needs to learn empathy for the team and the codebase. The team and tech lead need to build trust and a rhythm. Better decisions will be made with an initial pause.

+ +

The typical means of swapping out new tech (outside the absurdity of long-lived branches) is to utilize Branch by Abstraction:

+ +
    +
  • An abstraction is placed in front of component X.
    • +
  • Component Y is introduced as a replacement for X
    • +
  • The abstraction routes intelligently between X & Y while…
    • +
  • X is gradually made obsolete
    • +
  • X is removed; the abstraction is maybe removed
    • +
+ +

I have many times seen this process fail to complete due to discovering how difficult it is to remove that final 20% of the old component. I cannot stress enough how painful it is to drag around multiple ways of doing things year after year. It slows everything down and is demoralizing. Branch by Abstraction is a great pattern. It's the only way I'd do this sort of component swapping. But it needs to be accompanied by the team's complete commitment to eliminate the old component within a specified timebox.

+ +

Technical debt can kill you

+ +

Just because we talk about technical debt more than we used to does not provide any guarantee that it will be paid down. Perversely, maintaining a backlog of technical debt makes it easy to never pay it down. It's too easy for a manger to say "It's OK to hold off on that. We've got this other pressing need over here. It's logged. We can come back to it." And in that moment, it's probably a sound decision. But those pressing needs never go away. Urgent lists only grow longer.

+ +

And the situation get worse. My experience is that there is a point when the technical debt backlog grows so onerous that the team will give up on wanting to pay it off. The team will feel hopeless. The developers cannot achieve flow. The business isn't getting new value. I have a few thoughts on how to avoid insurmountable technical debt.

+ +

A good development team won't play the same technical debt card over and over again. When a team realizes it's playing the same type of technical debt card repeatedly, it must bring the pain forward and quickly assume that work into its normal everyday way of working.

+ +

My colleague Badri suggests that a team must agree to take on debt collectively. No one individual has the right to make the codebase worse while signing up the entire team to fix it later.

+ +

Most importantly, technical leaders and product leaders need to trust each other. Neither side should be able to play the "because I said so" card. Good technical leaders understand the priorities of the business. Good product managers value being able to deliver. Both sides need to talk about risks, costs, and benefits. If you can't ship, your technical debt has converted into a business problem and that's bad for everyone.

+ +

There's obviously much more a team can do to write long-lived code: code for the reader, don't be clever, and always think of your future colleagues to name a few. I'd love to hear what you think should be added to this list.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/24/index.html b/pr-1714/2016/03/24/index.html new file mode 100644 index 000000000..88a140f48 --- /dev/null +++ b/pr-1714/2016/03/24/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 24 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/03/index.html b/pr-1714/2016/03/index.html new file mode 100644 index 000000000..c57aa8aed --- /dev/null +++ b/pr-1714/2016/03/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06.html b/pr-1714/2016/06.html new file mode 100644 index 000000000..67f926756 --- /dev/null +++ b/pr-1714/2016/06.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/08.html b/pr-1714/2016/06/08.html new file mode 100644 index 000000000..a497196a4 --- /dev/null +++ b/pr-1714/2016/06/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline.html b/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline.html new file mode 100644 index 000000000..05a1e8d5c --- /dev/null +++ b/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline.html @@ -0,0 +1,342 @@ + + + + + + + + + + + + + + + + Performance testing for your CD pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Add performance testing to your Continuous Delivery pipeline +
+ +
+ + +
+

Part 3 - It's Not CD if You Can't Deploy Right Now: Add performance testing to your Continuous Delivery pipeline

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+ +

This is the third part of a series called It's not Continuous Delivery if you can't deploy right now. In this part, we'll talk about performance testing.

+ +

Years ago, when I was in management, I had a favorite rule. If asked "is something done?" the answer could not include the word "except" or any of its synonyms.

+ +

Performance testing as part of a Continuous Delivery (CD) pipeline is rare. In fact, it's so rare that HP applied for a patent on it. To quote from the patent application:

+ +
+

Load and performance tests are rarely included in the [CD] tests due to cost and time constraints since the execution time of performance and load tests are longer than unit tests and application programming interface tests. As a result, the tests lack a quality guarantee since the test sets do not include tests that measure performance of the code changes under testing conditions.

+
+ +

The fact that so few organizations are doing performance testing is especially scary since performance has such a huge impact on your business. In 2007, Amazon found that for every 100 millisecond increase in load time, sales decreased by 1 percent. And that was nine years ago!

+ +

The intent of this article is to provide you with some pointers on the types of testing you can do on a regular basis, and to give some strategies for implementation.

+ +

Most common types of performance testing

+ +

Load testing

+ +

Load testing an application generally means that you're measuring performance with a specific predetermined amount of load. This is a good way to make sure that you haven't introduced a change that has impacted your overall application. There has been quite a bit written on "acceptable" performance for a web application. A 20 percent increase in response time probably isn't going to generate a monitoring alert, but it may very well be killing your business.

+ +

Once you set a baseline, this is the easiest type of performance testing to include in a CD pipeline, since you already have an expectation of how long it'll take.

+ +

Performance tests often take longer than other types of tests, so be sure to use a CD server that allows you to run different pipelines in parallel while still enforcing their success before a release candidate goes too far.

+ +
+ Parallel Pipeline for Load Testing +
+ +

Spike testing

+ +

Spike testing is done by suddenly increasing the load on a system and seeing what happens. This is the type of testing I've seen the least of in the wild, but seems incredibly important in this world of dynamic containers and such. Your system is supposed to start a new container in milliseconds when the load requires it. Does it?

+ +
+ Parallel Pipeline for Spike Testing +
+ +

Stress testing

+ +

Stress testing is normally used to find out how much load your system can take before it fails. Is your site going to go down if you run that big promotion? What about the big holiday shopping days?

+ +

With stress testing in a pipeline, you may not want to always have downstream dependencies which require a "pass" all of the time. It's certainly important to know what your failure point is, but that isn't necessarily a reason not to ship during "normal" business.

+ +
+ Parallel Pipeline for Stress Testing +
+ +

Soak testing

+ +

Soak testing makes sure that your system keeps running under a sustained load. I saw a system once that seemed to be performing well on a short performance test, but growing message queues added up over time making it slower and slower. Memory leaks are also a common cause of issues on soak tests.

+ +
+ Parallel Pipeline for Soak Testing +
+ +

Run them on every build

+ +

During the writing of this post there were several discussions about the "right time" to run security tests. The one common theme that came out was "run them on every release candidate".

+ +

I believe every commit results in a release candidate, so I'm advocating running them on every build. You never know when some security issue or other emergency is going to force you to release today.

+ +

Suzie Price, Thoughtworks Head of Product says "For SaaS products I think this is essential. Even in non SaaS products I honestly don't buy that one is doing CD if you don't do these tests or some smoke of these tests."

+ +

The title of this blog series is "It's Not Continuous Delivery if You Can't Deploy Right Now". If you haven't done the performance tests, then you may not be able to deploy.

+ +

Yeah, but…

+ +

The cost of performance testing does force a bit of a reality check on the "run them on every build" rule. Performance testing can be very expensive to run since you need enough hardware and bandwidth to truly stress (and actually topple over, in the case of stress testing) your application. I understand it's not always possible in every organization to run them every time. You should try anyway.

+ +

Tools

+ +

There are several tools available for performance testing, I won't try to list them all.

+ +

As always, tools are a vital component, but they aren't a substitute for real-world knowledge.

+ +

Summary

+ +

More than ever, in today's world performance has a huge impact on our businesses. If your applications don't perform, people will very quickly find ones that do.

+ +

The longer you go between runs of any type of testing, the harder it's going to be to find out why it failed. This is more true for performance testing than any other category.

+ +

In order to be able to deploy at any time that's right for the business, you have to make sure all of your testing is done every time.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/index.html b/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/index.html new file mode 100644 index 000000000..13a3c6277 --- /dev/null +++ b/pr-1714/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/index.html @@ -0,0 +1,342 @@ + + + + + + + + + + + + + + + + Performance testing for your CD pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Add performance testing to your Continuous Delivery pipeline +
+ +
+ + +
+

Part 3 - It's Not CD if You Can't Deploy Right Now: Add performance testing to your Continuous Delivery pipeline

+

Ken Mugrage

+

+ It's Not CD if You Can't Deploy Right Now +

+
+ +
+ +

This is the third part of a series called It's not Continuous Delivery if you can't deploy right now. In this part, we'll talk about performance testing.

+ +

Years ago, when I was in management, I had a favorite rule. If asked "is something done?" the answer could not include the word "except" or any of its synonyms.

+ +

Performance testing as part of a Continuous Delivery (CD) pipeline is rare. In fact, it's so rare that HP applied for a patent on it. To quote from the patent application:

+ +
+

Load and performance tests are rarely included in the [CD] tests due to cost and time constraints since the execution time of performance and load tests are longer than unit tests and application programming interface tests. As a result, the tests lack a quality guarantee since the test sets do not include tests that measure performance of the code changes under testing conditions.

+
+ +

The fact that so few organizations are doing performance testing is especially scary since performance has such a huge impact on your business. In 2007, Amazon found that for every 100 millisecond increase in load time, sales decreased by 1 percent. And that was nine years ago!

+ +

The intent of this article is to provide you with some pointers on the types of testing you can do on a regular basis, and to give some strategies for implementation.

+ +

Most common types of performance testing

+ +

Load testing

+ +

Load testing an application generally means that you're measuring performance with a specific predetermined amount of load. This is a good way to make sure that you haven't introduced a change that has impacted your overall application. There has been quite a bit written on "acceptable" performance for a web application. A 20 percent increase in response time probably isn't going to generate a monitoring alert, but it may very well be killing your business.

+ +

Once you set a baseline, this is the easiest type of performance testing to include in a CD pipeline, since you already have an expectation of how long it'll take.

+ +

Performance tests often take longer than other types of tests, so be sure to use a CD server that allows you to run different pipelines in parallel while still enforcing their success before a release candidate goes too far.

+ +
+ Parallel Pipeline for Load Testing +
+ +

Spike testing

+ +

Spike testing is done by suddenly increasing the load on a system and seeing what happens. This is the type of testing I've seen the least of in the wild, but seems incredibly important in this world of dynamic containers and such. Your system is supposed to start a new container in milliseconds when the load requires it. Does it?

+ +
+ Parallel Pipeline for Spike Testing +
+ +

Stress testing

+ +

Stress testing is normally used to find out how much load your system can take before it fails. Is your site going to go down if you run that big promotion? What about the big holiday shopping days?

+ +

With stress testing in a pipeline, you may not want to always have downstream dependencies which require a "pass" all of the time. It's certainly important to know what your failure point is, but that isn't necessarily a reason not to ship during "normal" business.

+ +
+ Parallel Pipeline for Stress Testing +
+ +

Soak testing

+ +

Soak testing makes sure that your system keeps running under a sustained load. I saw a system once that seemed to be performing well on a short performance test, but growing message queues added up over time making it slower and slower. Memory leaks are also a common cause of issues on soak tests.

+ +
+ Parallel Pipeline for Soak Testing +
+ +

Run them on every build

+ +

During the writing of this post there were several discussions about the "right time" to run security tests. The one common theme that came out was "run them on every release candidate".

+ +

I believe every commit results in a release candidate, so I'm advocating running them on every build. You never know when some security issue or other emergency is going to force you to release today.

+ +

Suzie Price, Thoughtworks Head of Product says "For SaaS products I think this is essential. Even in non SaaS products I honestly don't buy that one is doing CD if you don't do these tests or some smoke of these tests."

+ +

The title of this blog series is "It's Not Continuous Delivery if You Can't Deploy Right Now". If you haven't done the performance tests, then you may not be able to deploy.

+ +

Yeah, but…

+ +

The cost of performance testing does force a bit of a reality check on the "run them on every build" rule. Performance testing can be very expensive to run since you need enough hardware and bandwidth to truly stress (and actually topple over, in the case of stress testing) your application. I understand it's not always possible in every organization to run them every time. You should try anyway.

+ +

Tools

+ +

There are several tools available for performance testing, I won't try to list them all.

+ +

As always, tools are a vital component, but they aren't a substitute for real-world knowledge.

+ +

Summary

+ +

More than ever, in today's world performance has a huge impact on our businesses. If your applications don't perform, people will very quickly find ones that do.

+ +

The longer you go between runs of any type of testing, the harder it's going to be to find out why it failed. This is more true for performance testing than any other category.

+ +

In order to be able to deploy at any time that's right for the business, you have to make sure all of your testing is done every time.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/08/index.html b/pr-1714/2016/06/08/index.html new file mode 100644 index 000000000..cb75b5034 --- /dev/null +++ b/pr-1714/2016/06/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/21.html b/pr-1714/2016/06/21.html new file mode 100644 index 000000000..171897697 --- /dev/null +++ b/pr-1714/2016/06/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 21 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project.html b/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project.html new file mode 100644 index 000000000..bcf419f84 --- /dev/null +++ b/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project.html @@ -0,0 +1,276 @@ + + + + + + + + + + + + + + + + Don't let sunk costs sink your project | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Don't let sunk costs sink your project +
+ +
+ + +
+

Don't let sunk costs sink your project

+

Jeff Norris

+

+

+
+ +
+ +

When my family and I moved out of our last house, we decided to do the majority of the hauling ourselves using a rental truck. Our house was up on the side of a hill with an uncomfortably steep driveway. We picked up the rental truck early in the day, pulled it up to the house and spent the majority of the day filling it up. When we finally finished loading it, we were exhausted, hungry, and really anxious to get across town to start unloading. I carefully backed the truck out of our driveway while my wife made sure I avoided the tree branches and the mailbox. Everything was fine until I got to that spot where the driveway met the street, where the truck just… stopped moving.

+ +

Truck stuck between driveway and street

+ +

The back frame of the truck was resting peacefully on the street, and the front wheels part way up the driveway. Unfortunately the back wheels spun helplessly a couple of inches above the ground. It was the perfect combination of too much weight in the truck and the wrong angle of the driveway. There was nothing I could do to move either forward or backward. I was really and truly stuck.

+ +

When you drive a vehicle over something high, and the center of your vehicle rests on it, with the wheels slightly in the air, it's referred to as being "high-centered". When we develop software projects, we can get into situations where we are also "high-centered", places where it is difficult to make progress either forwards or backwards. Some examples of where this can happen are when you go too far trying to refactor everything when you are fixing a bug, or when you start trying to replace a part of your application and don't realize just how tightly coupled you are to it. I have lived through a few of these situations.

+ +

Examples of 'High-Centered' Software Development

+ +

The first time I experienced this was with the regression testing suite for a fairly complicated international leasing application. This project had a long and powerful history, and we dealt with this problem about ten years into the evolution of this system. At its peak, the project had about 80 people, then slimmed down to about 20. We had built up a large suite of regression tests with a heavyweight testing tool that I'm embarrassed to admit we ever used. The tests took a substantial percentage of our development effort just to maintain, and we didn't have enough confidence in our test suite to know whether everything was working properly. There were intermittent failures and strange relationships between tests that caused them to fail if the order of execution wasn't exactly right.

+ +

This regression testing suite was a constant source of friction that made it difficult for us to make any progress. We had to do something dramatic to get out of it. We declared bankruptcy on our regression suite and started over again with a more modern, lightweight testing tool. We gave up on testing individual stories and instead focused on testing lighter-weight journeys through the application. It took a lot of courage to walk away from all those sunk costs. All those person-years of development time were already spent, and continuing to invest in them wasn't going to help.

+ +

How to Spot Trouble Earlier

+ +

If you feel like you are putting in too much effort into your project for the actual progress you are making, you too might be stuck. Ask yourself: if you were starting over again, would you still consider doing things that way? If the answer is a definite "no", you may want to try something different.

+ +

Continuous Integration servers like GoCD also give you a pretty good indicator if you are starting to get stuck. If you are following standard CI practices and checking in regularly, you are probably in the cadence of pushing your code to the master/trunk branch at least once a day. If you are coming up to the end of the day and you have that sinking feeling that it wouldn't be safe to check in, or your build fails in some surprising and catastrophic way, then you may need to try breaking your changes into smaller, more manageable pieces. It is much easier to keep yourself from getting stuck if you work in smaller increments and use techniques like "branch by abstraction".

+ +

But oftentimes, it can be difficult to spot when you are about to be high-centered. Unfortunately, trying harder at the things that got you there in the first place probably won't help. You will need to stop, step back and take an honest look at what your options going forward are.

+ +

With our stuck truck, we had to call a giant tow truck to come pick up the fully loaded moving truck from our driveway and set it in the street. With your software project, instead of calling a tow truck, you may need to introduce a strangler application or split your applications into smaller parts so that you can clean up incrementally. I hope this has been helpful. If you have any tips or stories about "high-centered" software projects, please let us know in the comments.

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project/index.html b/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project/index.html new file mode 100644 index 000000000..d6a40d786 --- /dev/null +++ b/pr-1714/2016/06/21/dont-let-sunk-costs-sink-your-project/index.html @@ -0,0 +1,276 @@ + + + + + + + + + + + + + + + + Don't let sunk costs sink your project | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Don't let sunk costs sink your project +
+ +
+ + +
+

Don't let sunk costs sink your project

+

Jeff Norris

+

+

+
+ +
+ +

When my family and I moved out of our last house, we decided to do the majority of the hauling ourselves using a rental truck. Our house was up on the side of a hill with an uncomfortably steep driveway. We picked up the rental truck early in the day, pulled it up to the house and spent the majority of the day filling it up. When we finally finished loading it, we were exhausted, hungry, and really anxious to get across town to start unloading. I carefully backed the truck out of our driveway while my wife made sure I avoided the tree branches and the mailbox. Everything was fine until I got to that spot where the driveway met the street, where the truck just… stopped moving.

+ +

Truck stuck between driveway and street

+ +

The back frame of the truck was resting peacefully on the street, and the front wheels part way up the driveway. Unfortunately the back wheels spun helplessly a couple of inches above the ground. It was the perfect combination of too much weight in the truck and the wrong angle of the driveway. There was nothing I could do to move either forward or backward. I was really and truly stuck.

+ +

When you drive a vehicle over something high, and the center of your vehicle rests on it, with the wheels slightly in the air, it's referred to as being "high-centered". When we develop software projects, we can get into situations where we are also "high-centered", places where it is difficult to make progress either forwards or backwards. Some examples of where this can happen are when you go too far trying to refactor everything when you are fixing a bug, or when you start trying to replace a part of your application and don't realize just how tightly coupled you are to it. I have lived through a few of these situations.

+ +

Examples of 'High-Centered' Software Development

+ +

The first time I experienced this was with the regression testing suite for a fairly complicated international leasing application. This project had a long and powerful history, and we dealt with this problem about ten years into the evolution of this system. At its peak, the project had about 80 people, then slimmed down to about 20. We had built up a large suite of regression tests with a heavyweight testing tool that I'm embarrassed to admit we ever used. The tests took a substantial percentage of our development effort just to maintain, and we didn't have enough confidence in our test suite to know whether everything was working properly. There were intermittent failures and strange relationships between tests that caused them to fail if the order of execution wasn't exactly right.

+ +

This regression testing suite was a constant source of friction that made it difficult for us to make any progress. We had to do something dramatic to get out of it. We declared bankruptcy on our regression suite and started over again with a more modern, lightweight testing tool. We gave up on testing individual stories and instead focused on testing lighter-weight journeys through the application. It took a lot of courage to walk away from all those sunk costs. All those person-years of development time were already spent, and continuing to invest in them wasn't going to help.

+ +

How to Spot Trouble Earlier

+ +

If you feel like you are putting in too much effort into your project for the actual progress you are making, you too might be stuck. Ask yourself: if you were starting over again, would you still consider doing things that way? If the answer is a definite "no", you may want to try something different.

+ +

Continuous Integration servers like GoCD also give you a pretty good indicator if you are starting to get stuck. If you are following standard CI practices and checking in regularly, you are probably in the cadence of pushing your code to the master/trunk branch at least once a day. If you are coming up to the end of the day and you have that sinking feeling that it wouldn't be safe to check in, or your build fails in some surprising and catastrophic way, then you may need to try breaking your changes into smaller, more manageable pieces. It is much easier to keep yourself from getting stuck if you work in smaller increments and use techniques like "branch by abstraction".

+ +

But oftentimes, it can be difficult to spot when you are about to be high-centered. Unfortunately, trying harder at the things that got you there in the first place probably won't help. You will need to stop, step back and take an honest look at what your options going forward are.

+ +

With our stuck truck, we had to call a giant tow truck to come pick up the fully loaded moving truck from our driveway and set it in the street. With your software project, instead of calling a tow truck, you may need to introduce a strangler application or split your applications into smaller parts so that you can clean up incrementally. I hope this has been helpful. If you have any tips or stories about "high-centered" software projects, please let us know in the comments.

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/21/index.html b/pr-1714/2016/06/21/index.html new file mode 100644 index 000000000..f8f1290a0 --- /dev/null +++ b/pr-1714/2016/06/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 21 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/06/index.html b/pr-1714/2016/06/index.html new file mode 100644 index 000000000..ec5941b2c --- /dev/null +++ b/pr-1714/2016/06/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07.html b/pr-1714/2016/07.html new file mode 100644 index 000000000..d104e6840 --- /dev/null +++ b/pr-1714/2016/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07/13.html b/pr-1714/2016/07/13.html new file mode 100644 index 000000000..027e414db --- /dev/null +++ b/pr-1714/2016/07/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07/13/DotNet-Core-and-GoCD.html b/pr-1714/2016/07/13/DotNet-Core-and-GoCD.html new file mode 100644 index 000000000..207f33fb3 --- /dev/null +++ b/pr-1714/2016/07/13/DotNet-Core-and-GoCD.html @@ -0,0 +1,480 @@ + + + + + + + + + + + + + + + + .NET Core and GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD and .NET Core +
+ +
+ + +
+

.NET Core and GoCD

+

Jason Rowe

+

+

+
+ +
+ +

[This post originally appeared on Jason Rowe's site and is reproduced with permission]

+ +

I've been reading up on continuous delivery and the GoCD tool is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it.

+ +

This post documents setting up a .NET core project in GoCD in a minimal way. I cover setting up a hello world app and simple scripts to build, test, and package. Then I will create a pipeline in GoCD to build our site and run unit tests. Finally I'll show how to add additional pipelines for manual acceptance tests and deployment.

+ +

If you want to know about my environment and .NET core project for this demo you can read the next section Demo Environment Setup. If you want to just jump ahead to the GoCD part you can scroll down to the GoCD Setup or GoCD Pipelines sections.

+ +

+ +

Demo Environment Setup

+ +

Demo Environment

+ +

For this post I'll be using the following file structure:

+ +

Where I keep my development git repo.

+ +

C:\demo\development

+ +

Where I will keep my bare git repo to be used as GoCD material.

+ +

C:\demo\git_server

+ +

Material Setup

+ +
    +
  • +

    First I'll setup a file based git server in C:\demo\git_server. I'm just doing this for simplicity. You could also use Github or another SCM server.

    + + 
    mkdir hwapp
+cd hwapp
+git init --bare
+
    +
    • +
  • +

    Then I'll setup a share so the git repo can be used as a material and cloned into my development folder.

    + + 
    \\lenovo-pc\git_server\hwapp
+
    +
    • +
  • +

    Then clone that into my development folder.

    + + 
    cd development
+git clone \\lenovo-pc\git_server\hwapp
+
    +
    • +
  • +

    Now we will just setup the hello world .NET Core app.

    + + 
    cd hwapp
+dotnet new
+
    +
    • +
  • +

    Then run it to make sure everything is working.

    + + 
    dotnet restore
+dotnet run
+
    +
    • +
  • +

    Add a .gitignore file (with contents):

    + + 
    bin/
+obj/
+project.lock.json
+_build
+
    +
    • +
  • +

    To keep things simple I won't use a build tool and just write a few small windows commands.

    + +
      +
    • +

      build.cmd file contents:

      + + 
      git clean -xfd
+dotnet restore
+dotnet build
+
      +
      • +
    • +

      test.cmd file contents:

      + + 
      dotnet test
+
      +
      • +
    • +

      package.cmd file contents:

      + + 
      IF [%1] == [] GOTO error
+@Echo Off
+dotnet pack -o _build --version-suffix %1
+EXIT /B
+:error
+Echo version required.
+
      +
      • +
    +
    • +
  • +

    Add some example unit tests using Xunit.net:

    + +

    Here is my updated project json to allow me to run xunit tests.

    + + 
      {
+    "version": "1.0.0-*",
+    "testRunner": "xunit",
+    "buildOptions": {
+      "emitEntryPoint": true
+    },
+    "dependencies": {
+        "xunit": "2.1.0",
+        "dotnet-test-xunit": "1.0.0-rc2-build10025"
+    },
+    "frameworks": {
+        "netcoreapp1.0": {
+            "dependencies": {
+                "Microsoft.NETCore.App": {
+                    "type": "platform",
+                    "version": "1.0.0-rc2-3002702"
+                }
+            },
+            "imports": [
+                "dnxcore50",
+                "portable-net45+win8"
+            ]
+        }
+    }
+  }
+
    +
    • +
  • +

    Add xunit tests (tests.cs)

    + + 
    using Xunit;
+
+namespace MyFirstDotNetCoreTests
+{
+    public class Class1
+    {
+        [Fact]
+        public void PassingTest()
+        {
+            Assert.Equal(4, Add(2, 2));
+        }
+        int Add(int x, int y)
+        {
+            return x + y;
+        }
+    }
+}
+
    +
    • +
  • +

    Now the build, test, package cmds should work. Test and commit and push that to origin.

    + + 
    git add -A
+git commit -m 'initial hello world app'
+git push origin master
+
    +
    • +
+ +

+ +

GoCD Setup

+ +

Note: For windows users I would suggest a simple file path without spaces. I'll use C:\demo\GoCD\Server and C:\demo\GoCD\Agent for the install and host it on localhost.

+ +

Getting up and running with GoCD is simple. Download the server and agent and run the installers. Once it is running your GoCD server should be available at https://localhost:8153 or https://your-server-installation-hostname:8153. Verify the server and agents are working by visiting the site and checking the agents tab.

+ +

Now that the test environment is setup we can start adding a pipeline.

+ +

+ +

GoCD Pipeline

+ +

Initial setup of the "HwPackagePipeline" pipeline which will contain the stage/job/tasks to do the build, test, and package.

+
+ GoCD Pipeline +
+ +

The second page is how you setup the material in GoCD. Here I've added my git repo endpoint and tested the connection.

+
+ GoCD Pipeline Material +
+ +

The third page sets up the stage/job. I've used the custom build.cmd I created in the setup.

+
+ GoCD Pipeline Stage Job +
+ +

After adding the build task, I un-paused the pipeline to make sure everything is wired up. GoCD will show the status go to orange and then green after the pipeline has finished.

+
+ GoCD Pipeline Passed Build +
+ +

Now I can go setup the unit test and package tasks in this pipeline. I did this by going to the admin navigation and clicking on pipelines. Then clicked on the edit of the pipeline I created above. Then clicked on the defaultstage and defaultjob. Then I added in the unit test task which just calls test.cmd. The package task is a little different because I want to pass in the build number as a variable to the package.cmd.

+
+ GoCD Pipeline Label +
+ +

Here is a view of all the tasks I setup in the default job.

+
+ GoCD Tasks +
+ +

From the pipeline view if you click on the green bar you can view the job console output. I confirmed the label was updated correctly during the package task.

+ +
19:04:59.567 [go] Start to execute task:
+/c
+package.cmd %GO_PIPELINE_LABEL%
+.
+19:04:59.598
+19:04:59.598 C:\demo\GoCD\Agent\pipelines\hwPackagePipeline>IF [2] == [] GOTO error
+19:05:00.022 Project hwPackagePipeline (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
+19:05:00.072 Producing nuget package "hwPackagePipeline.1.0.0-2" for hwPackagePipeline
+19:05:00.118 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.nupkg
+19:05:00.118 Producing nuget package "hwPackagePipeline.1.0.0-2.symbols" for hwPackagePipeline
+19:05:00.122 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.symbols.nupkg
+19:05:00.184 [go] Current job status: passed.
+
+ +

Now that the build, test, and packaging is done I can move on to creating a pipeline for acceptance tests and deployment with required approval. The second pipeline will use the first for it's material. Before we can create the second pipeline we need to go into the first and setup the jobs build artifacts.

+ +

Note: Also by adding a test artifact GoCD will display the results in the tests tab. You can use GoCD with any XUnit style xml reports.

+ +
+ GoCD Artifacts +
+ +

Now via the admin tab and selecting pipelines, I can click on "Create a new pipeline within this group". On step one I'll name the new pipeline "hwDeployPipeline".

+ +

Note: GoCD supports pipeline templates. Deployment pipelines would be a good use case for a template.

+ +

For step two the material will be "Pipeline" and the stage will be the stage we created earlier. GoCD has autocomplete text boxes. I didn't have to type the stage name in the screenshot below.

+ +
+ GoCD Pipeline as Material +
+ +

In step three, I setup a manual stage and a task that represents acceptance tests were performed. If a step in your pipeline is not yet automated this could be a way to incrementally work towards automation.

+
+ GoCD Manual Acceptance Test Example +
+ +

Now I can save the new pipeline and unpause it. If we now go back to the main pipeline page and trigger the build we will see the first pipeline build and the second one will wait to be manually triggered. Once you click into the second pipeline and click on the purple arrow button it will run.

+ +

The value stream will look like this after both pipelines complete. You can view value stream map for any build by clicking on the build label.

+
+ GoCD Value Stream Map +
+ +

Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The "pkg" folder name came from the artifacts configuration from the first pipeline.

+
+ GoCD Fetch Artifacts +
+ +

Now if we trigger the first pipeline again and manually trigger the second one we can see the agent was able to fetch the build output from the first pipeline.

+ +
21:31:26.919 [go] Start to execute task: .
+21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
+21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
+21:31:32.052 [go] Current job status: passed.
+
+ +
+ GoCD Agent Pkg +
+ +

Review

+ +

GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don't need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07/13/DotNet-Core-and-GoCD/index.html b/pr-1714/2016/07/13/DotNet-Core-and-GoCD/index.html new file mode 100644 index 000000000..280b9cb7b --- /dev/null +++ b/pr-1714/2016/07/13/DotNet-Core-and-GoCD/index.html @@ -0,0 +1,480 @@ + + + + + + + + + + + + + + + + .NET Core and GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD and .NET Core +
+ +
+ + +
+

.NET Core and GoCD

+

Jason Rowe

+

+

+
+ +
+ +

[This post originally appeared on Jason Rowe's site and is reproduced with permission]

+ +

I've been reading up on continuous delivery and the GoCD tool is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it.

+ +

This post documents setting up a .NET core project in GoCD in a minimal way. I cover setting up a hello world app and simple scripts to build, test, and package. Then I will create a pipeline in GoCD to build our site and run unit tests. Finally I'll show how to add additional pipelines for manual acceptance tests and deployment.

+ +

If you want to know about my environment and .NET core project for this demo you can read the next section Demo Environment Setup. If you want to just jump ahead to the GoCD part you can scroll down to the GoCD Setup or GoCD Pipelines sections.

+ +

+ +

Demo Environment Setup

+ +

Demo Environment

+ +

For this post I'll be using the following file structure:

+ +

Where I keep my development git repo.

+ +

C:\demo\development

+ +

Where I will keep my bare git repo to be used as GoCD material.

+ +

C:\demo\git_server

+ +

Material Setup

+ +
    +
  • +

    First I'll setup a file based git server in C:\demo\git_server. I'm just doing this for simplicity. You could also use Github or another SCM server.

    + + 
    mkdir hwapp
+cd hwapp
+git init --bare
+
    +
    • +
  • +

    Then I'll setup a share so the git repo can be used as a material and cloned into my development folder.

    + + 
    \\lenovo-pc\git_server\hwapp
+
    +
    • +
  • +

    Then clone that into my development folder.

    + + 
    cd development
+git clone \\lenovo-pc\git_server\hwapp
+
    +
    • +
  • +

    Now we will just setup the hello world .NET Core app.

    + + 
    cd hwapp
+dotnet new
+
    +
    • +
  • +

    Then run it to make sure everything is working.

    + + 
    dotnet restore
+dotnet run
+
    +
    • +
  • +

    Add a .gitignore file (with contents):

    + + 
    bin/
+obj/
+project.lock.json
+_build
+
    +
    • +
  • +

    To keep things simple I won't use a build tool and just write a few small windows commands.

    + +
      +
    • +

      build.cmd file contents:

      + + 
      git clean -xfd
+dotnet restore
+dotnet build
+
      +
      • +
    • +

      test.cmd file contents:

      + + 
      dotnet test
+
      +
      • +
    • +

      package.cmd file contents:

      + + 
      IF [%1] == [] GOTO error
+@Echo Off
+dotnet pack -o _build --version-suffix %1
+EXIT /B
+:error
+Echo version required.
+
      +
      • +
    +
    • +
  • +

    Add some example unit tests using Xunit.net:

    + +

    Here is my updated project json to allow me to run xunit tests.

    + + 
      {
+    "version": "1.0.0-*",
+    "testRunner": "xunit",
+    "buildOptions": {
+      "emitEntryPoint": true
+    },
+    "dependencies": {
+        "xunit": "2.1.0",
+        "dotnet-test-xunit": "1.0.0-rc2-build10025"
+    },
+    "frameworks": {
+        "netcoreapp1.0": {
+            "dependencies": {
+                "Microsoft.NETCore.App": {
+                    "type": "platform",
+                    "version": "1.0.0-rc2-3002702"
+                }
+            },
+            "imports": [
+                "dnxcore50",
+                "portable-net45+win8"
+            ]
+        }
+    }
+  }
+
    +
    • +
  • +

    Add xunit tests (tests.cs)

    + + 
    using Xunit;
+
+namespace MyFirstDotNetCoreTests
+{
+    public class Class1
+    {
+        [Fact]
+        public void PassingTest()
+        {
+            Assert.Equal(4, Add(2, 2));
+        }
+        int Add(int x, int y)
+        {
+            return x + y;
+        }
+    }
+}
+
    +
    • +
  • +

    Now the build, test, package cmds should work. Test and commit and push that to origin.

    + + 
    git add -A
+git commit -m 'initial hello world app'
+git push origin master
+
    +
    • +
+ +

+ +

GoCD Setup

+ +

Note: For windows users I would suggest a simple file path without spaces. I'll use C:\demo\GoCD\Server and C:\demo\GoCD\Agent for the install and host it on localhost.

+ +

Getting up and running with GoCD is simple. Download the server and agent and run the installers. Once it is running your GoCD server should be available at https://localhost:8153 or https://your-server-installation-hostname:8153. Verify the server and agents are working by visiting the site and checking the agents tab.

+ +

Now that the test environment is setup we can start adding a pipeline.

+ +

+ +

GoCD Pipeline

+ +

Initial setup of the "HwPackagePipeline" pipeline which will contain the stage/job/tasks to do the build, test, and package.

+
+ GoCD Pipeline +
+ +

The second page is how you setup the material in GoCD. Here I've added my git repo endpoint and tested the connection.

+
+ GoCD Pipeline Material +
+ +

The third page sets up the stage/job. I've used the custom build.cmd I created in the setup.

+
+ GoCD Pipeline Stage Job +
+ +

After adding the build task, I un-paused the pipeline to make sure everything is wired up. GoCD will show the status go to orange and then green after the pipeline has finished.

+
+ GoCD Pipeline Passed Build +
+ +

Now I can go setup the unit test and package tasks in this pipeline. I did this by going to the admin navigation and clicking on pipelines. Then clicked on the edit of the pipeline I created above. Then clicked on the defaultstage and defaultjob. Then I added in the unit test task which just calls test.cmd. The package task is a little different because I want to pass in the build number as a variable to the package.cmd.

+
+ GoCD Pipeline Label +
+ +

Here is a view of all the tasks I setup in the default job.

+
+ GoCD Tasks +
+ +

From the pipeline view if you click on the green bar you can view the job console output. I confirmed the label was updated correctly during the package task.

+ +
19:04:59.567 [go] Start to execute task:
+/c
+package.cmd %GO_PIPELINE_LABEL%
+.
+19:04:59.598
+19:04:59.598 C:\demo\GoCD\Agent\pipelines\hwPackagePipeline>IF [2] == [] GOTO error
+19:05:00.022 Project hwPackagePipeline (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
+19:05:00.072 Producing nuget package "hwPackagePipeline.1.0.0-2" for hwPackagePipeline
+19:05:00.118 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.nupkg
+19:05:00.118 Producing nuget package "hwPackagePipeline.1.0.0-2.symbols" for hwPackagePipeline
+19:05:00.122 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.symbols.nupkg
+19:05:00.184 [go] Current job status: passed.
+
+ +

Now that the build, test, and packaging is done I can move on to creating a pipeline for acceptance tests and deployment with required approval. The second pipeline will use the first for it's material. Before we can create the second pipeline we need to go into the first and setup the jobs build artifacts.

+ +

Note: Also by adding a test artifact GoCD will display the results in the tests tab. You can use GoCD with any XUnit style xml reports.

+ +
+ GoCD Artifacts +
+ +

Now via the admin tab and selecting pipelines, I can click on "Create a new pipeline within this group". On step one I'll name the new pipeline "hwDeployPipeline".

+ +

Note: GoCD supports pipeline templates. Deployment pipelines would be a good use case for a template.

+ +

For step two the material will be "Pipeline" and the stage will be the stage we created earlier. GoCD has autocomplete text boxes. I didn't have to type the stage name in the screenshot below.

+ +
+ GoCD Pipeline as Material +
+ +

In step three, I setup a manual stage and a task that represents acceptance tests were performed. If a step in your pipeline is not yet automated this could be a way to incrementally work towards automation.

+
+ GoCD Manual Acceptance Test Example +
+ +

Now I can save the new pipeline and unpause it. If we now go back to the main pipeline page and trigger the build we will see the first pipeline build and the second one will wait to be manually triggered. Once you click into the second pipeline and click on the purple arrow button it will run.

+ +

The value stream will look like this after both pipelines complete. You can view value stream map for any build by clicking on the build label.

+
+ GoCD Value Stream Map +
+ +

Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The "pkg" folder name came from the artifacts configuration from the first pipeline.

+
+ GoCD Fetch Artifacts +
+ +

Now if we trigger the first pipeline again and manually trigger the second one we can see the agent was able to fetch the build output from the first pipeline.

+ +
21:31:26.919 [go] Start to execute task: .
+21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
+21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
+21:31:32.052 [go] Current job status: passed.
+
+ +
+ GoCD Agent Pkg +
+ +

Review

+ +

GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don't need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07/13/index.html b/pr-1714/2016/07/13/index.html new file mode 100644 index 000000000..db713f392 --- /dev/null +++ b/pr-1714/2016/07/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/07/index.html b/pr-1714/2016/07/index.html new file mode 100644 index 000000000..4155de26e --- /dev/null +++ b/pr-1714/2016/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2016/index.html b/pr-1714/2016/index.html new file mode 100644 index 000000000..f020117c4 --- /dev/null +++ b/pr-1714/2016/index.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017.html b/pr-1714/2017.html new file mode 100644 index 000000000..e23e1faf2 --- /dev/null +++ b/pr-1714/2017.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 1 of 4

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01.html b/pr-1714/2017/01.html new file mode 100644 index 000000000..7f3231f75 --- /dev/null +++ b/pr-1714/2017/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01/05.html b/pr-1714/2017/01/05.html new file mode 100644 index 000000000..be55f60ed --- /dev/null +++ b/pr-1714/2017/01/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01/05/index.html b/pr-1714/2017/01/05/index.html new file mode 100644 index 000000000..b77adaeeb --- /dev/null +++ b/pr-1714/2017/01/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io.html b/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io.html new file mode 100644 index 000000000..d7875b69a --- /dev/null +++ b/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io.html @@ -0,0 +1,319 @@ + + + + + + + + + + + + + + + + Why we've moved from go.cd to gocd.io | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Please standy by - We are experiencing technical difficulties +
+ +
+ + +
+

Why we've moved from go.cd to gocd.io

+

GoCD team

+

+ Announcements +

+
+ +
+ +

If you've been following us on twitter, our community forum, or +tried to access our website in the past two weeks, you'll know that we've moved from https://go.cd to +https://gocd.io. We are very sorry for the inconvenience this has caused our users and community. We +hope that this post helps give more visibility into what has been happening and why, and a view into our plans going +forward.

+ +

+ +

What the heck happened???

+ +

On December 23, 2016 (at around 15:45 GMT), we learned that the go.cd website was inaccessible. Upon investigation, we +found that our DNS registrar, Conic.cd, marked go.cd as "expired" even though it should not have +been. We had renewed it through 2021.

+ +

+ +

How we responded

+ +

As soon as we realized what had happened, we raised a ticket with Conic. We also tried to call them but found many of +their contact numbers do not work. Our ticket sat unanswered so we pinged them again about our case. No response. As our +frustration grew, we turned to the administrative and technical contacts of the DNS registrar for the ".cd" top-level +domain (TLD). This is the organization that is registered with IANA and ICANN as those responsible to make sure +something like this gets resolved quickly. For ".cd" this is CDNIC. We were able to reach +someone in their organization via phone*. We explained what happened, they said that they would get back to us. We have +not heard from them since, despite repeated efforts to contact them again.

+ +

For users that needed critical access to our website, APIs, documentation, etc., we provided a quick +workaround. This involved adding some entries into local hosts +file. We were able to provide this because all of our sites were really up but just not accessible via the standard URLs +because of the missing DNS entries.

+ +

*FYI – Thankfully we have folks in our organization who speak French, which proved very important as ".cd" is +the ccTLD for the Democratic Republic of Congo (DRC) and is home to CDNIC.

+ +

+ +

Why the domain change to gocd.io?

+ +

By December 28th, our efforts to reach our domain registrar and the TLD registrar for the DRC to get our go.cd domain +back were still unanswered.

+ +

Giving up on go.cd was and is heartbreaking for us. But at this point we had no choice but move to a new domain as we +had no confidence in getting a response from the DNS registrars. So we set up an alternate domain with the TLD .io.

+ +

As of the time of writing this post, we still have not heard back from Conic nor CDNIC, despite many, many attempts to +reach them. When we do get this resolved, we hope to retain the go.cd domain. However, for now, our primary domain for +GoCD will be gocd.io.

+ +

+ +

Will gocd.io be the permanent domain for GoCD?

+ +

This is TBD. We are working tirelessly on finding a forever home for GoCD on the web, but we do not have the final +solution yet. We know this may not be satisfactory for some. But this experience has really made us weary of the DNS +system. And when we make the final move, we want to be as certain as we possibly can this will not happen again. So we +are proceeding quickly but also cautiously.

+ +

However, no matter what happens, we will commit to maintaining registration for gocd.io and ensuring that web pages +redirect properly even if it does not end up being our permanent domain.

+ +

+ +

Were we a little too clever by getting a .cd domain?

+ +

Yes. Clearly we were. Acquiring a great domain is hard 28 years into the WWW Age. In hindsight, we were so thrilled to +get go.cd for our domain that we ignored how problematic it could be to have a TLD that is managed by a country for +which we lacked presence, contacts, and context. We are left in a position where we have no real recourse to fix +this. Lesson learned.

+ +

+ +

What happens to the go.cd domain?

+ +

When we get the go.cd domain back, we plan to set up redirects from go.cd to gocd.io for all pages. We feel most third +party apps and sites should work this way. However we strongly encourage any third party apps or sites to use gocd.io +going forward.

+ +

+ +

What this means for you

+ +

For GoCD users, your version of GoCD will have the outdated link in the footer for documentation. We'll make sure that +subsequent releases of GoCD have the latest URL, but in the meantime, you'll be able to access documentation at +https://docs.gocd.io.

+ +

For those who have built an app that uses https://go.cd, or are referencing the website in a blog post, we urge you to +start using https://gocd.io.

+ +

If you find any links that have "go.cd" in them, please feel free to submit a pull request to replace them with +"gocd.io" since GoCD is open source, or let us know and we will update them.

+ +

Several important GoCD sites have been impacted. Here are the new locations for those (updated in Sep 2019):

+ + + +


+So that's the scoop. While we still love go.cd and hope to get it back, we feel that in the long term, moving to a more +reliable TLD is the best option for GoCD, our users and community.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/index.html b/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/index.html new file mode 100644 index 000000000..40c428a3a --- /dev/null +++ b/pr-1714/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/index.html @@ -0,0 +1,319 @@ + + + + + + + + + + + + + + + + Why we've moved from go.cd to gocd.io | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Please standy by - We are experiencing technical difficulties +
+ +
+ + +
+

Why we've moved from go.cd to gocd.io

+

GoCD team

+

+ Announcements +

+
+ +
+ +

If you've been following us on twitter, our community forum, or +tried to access our website in the past two weeks, you'll know that we've moved from https://go.cd to +https://gocd.io. We are very sorry for the inconvenience this has caused our users and community. We +hope that this post helps give more visibility into what has been happening and why, and a view into our plans going +forward.

+ +

+ +

What the heck happened???

+ +

On December 23, 2016 (at around 15:45 GMT), we learned that the go.cd website was inaccessible. Upon investigation, we +found that our DNS registrar, Conic.cd, marked go.cd as "expired" even though it should not have +been. We had renewed it through 2021.

+ +

+ +

How we responded

+ +

As soon as we realized what had happened, we raised a ticket with Conic. We also tried to call them but found many of +their contact numbers do not work. Our ticket sat unanswered so we pinged them again about our case. No response. As our +frustration grew, we turned to the administrative and technical contacts of the DNS registrar for the ".cd" top-level +domain (TLD). This is the organization that is registered with IANA and ICANN as those responsible to make sure +something like this gets resolved quickly. For ".cd" this is CDNIC. We were able to reach +someone in their organization via phone*. We explained what happened, they said that they would get back to us. We have +not heard from them since, despite repeated efforts to contact them again.

+ +

For users that needed critical access to our website, APIs, documentation, etc., we provided a quick +workaround. This involved adding some entries into local hosts +file. We were able to provide this because all of our sites were really up but just not accessible via the standard URLs +because of the missing DNS entries.

+ +

*FYI – Thankfully we have folks in our organization who speak French, which proved very important as ".cd" is +the ccTLD for the Democratic Republic of Congo (DRC) and is home to CDNIC.

+ +

+ +

Why the domain change to gocd.io?

+ +

By December 28th, our efforts to reach our domain registrar and the TLD registrar for the DRC to get our go.cd domain +back were still unanswered.

+ +

Giving up on go.cd was and is heartbreaking for us. But at this point we had no choice but move to a new domain as we +had no confidence in getting a response from the DNS registrars. So we set up an alternate domain with the TLD .io.

+ +

As of the time of writing this post, we still have not heard back from Conic nor CDNIC, despite many, many attempts to +reach them. When we do get this resolved, we hope to retain the go.cd domain. However, for now, our primary domain for +GoCD will be gocd.io.

+ +

+ +

Will gocd.io be the permanent domain for GoCD?

+ +

This is TBD. We are working tirelessly on finding a forever home for GoCD on the web, but we do not have the final +solution yet. We know this may not be satisfactory for some. But this experience has really made us weary of the DNS +system. And when we make the final move, we want to be as certain as we possibly can this will not happen again. So we +are proceeding quickly but also cautiously.

+ +

However, no matter what happens, we will commit to maintaining registration for gocd.io and ensuring that web pages +redirect properly even if it does not end up being our permanent domain.

+ +

+ +

Were we a little too clever by getting a .cd domain?

+ +

Yes. Clearly we were. Acquiring a great domain is hard 28 years into the WWW Age. In hindsight, we were so thrilled to +get go.cd for our domain that we ignored how problematic it could be to have a TLD that is managed by a country for +which we lacked presence, contacts, and context. We are left in a position where we have no real recourse to fix +this. Lesson learned.

+ +

+ +

What happens to the go.cd domain?

+ +

When we get the go.cd domain back, we plan to set up redirects from go.cd to gocd.io for all pages. We feel most third +party apps and sites should work this way. However we strongly encourage any third party apps or sites to use gocd.io +going forward.

+ +

+ +

What this means for you

+ +

For GoCD users, your version of GoCD will have the outdated link in the footer for documentation. We'll make sure that +subsequent releases of GoCD have the latest URL, but in the meantime, you'll be able to access documentation at +https://docs.gocd.io.

+ +

For those who have built an app that uses https://go.cd, or are referencing the website in a blog post, we urge you to +start using https://gocd.io.

+ +

If you find any links that have "go.cd" in them, please feel free to submit a pull request to replace them with +"gocd.io" since GoCD is open source, or let us know and we will update them.

+ +

Several important GoCD sites have been impacted. Here are the new locations for those (updated in Sep 2019):

+ + + +


+So that's the scoop. While we still love go.cd and hope to get it back, we feel that in the long term, moving to a more +reliable TLD is the best option for GoCD, our users and community.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/01/index.html b/pr-1714/2017/01/index.html new file mode 100644 index 000000000..535e88fdd --- /dev/null +++ b/pr-1714/2017/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02.html b/pr-1714/2017/02.html new file mode 100644 index 000000000..639c607af --- /dev/null +++ b/pr-1714/2017/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02/16.html b/pr-1714/2017/02/16.html new file mode 100644 index 000000000..b85c9a5a9 --- /dev/null +++ b/pr-1714/2017/02/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02/16/index.html b/pr-1714/2017/02/16/index.html new file mode 100644 index 000000000..c47c05887 --- /dev/null +++ b/pr-1714/2017/02/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02/16/migrating-snapci-to-gocd.html b/pr-1714/2017/02/16/migrating-snapci-to-gocd.html new file mode 100644 index 000000000..c0f2c302a --- /dev/null +++ b/pr-1714/2017/02/16/migrating-snapci-to-gocd.html @@ -0,0 +1,321 @@ + + + + + + + + + + + + + + + + Migrating from Snap CI to GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Migrating SnapCI to GoCD +
+ +
+ + +
+

Migrating from Snap CI to GoCD

+

Suzie Prince - Product Manager at Snap CI

+

+

+
+ +
+ +

Many Snap CI users are now looking for a replacement CI/CD tool. In the end of life announcement we recommended that Snap CI users take a look at GoCD and consider it as an alternative. We recommend this not just because Thoughtworks creates and supports both tools, but because we think it's a great choice for Snap CI users. Snap CI had its roots in GoCD and they share common features. However, they were also created with different specific needs in mind and offer unique capabilities.

+ +

This post intends to serve as reference for anyone comparing GoCD to Snap CI (or any other hosted CI/CD tool) and fairly compare them to provide you with useful insights into why GoCD might be a good choice for you. Because we understand the needs of Snap CI users, we will also highlight areas where GoCD may not completely meet your needs and where you may need to consider your own tooling priorities. Finally, should you think that GoCD is a good choice for you, we will provide you with information about how to migrate from Snap CI to GoCD.

+ +

Comparison of GoCD and Snap CI

+ +

Here is the obligatory comparison table. Read on ahead for our opinions.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeaturesSnap CIGoCD
PricingFree for public repositories. Starting at $30 for private repositoriesFree, open source for all users
PlatformHosted software as a serviceRun on your own servers, on-premise or on the cloud
Source ControlGithub integrationGoCD is universal (not platform or tool specific) and extensible through plugins
Pipeline Built with pipelines at the coreBuilt with pipelines at the core
Pipeline DependenciesSome support for fan-in and fan-out pipelines capabilitiesFirst class support for fan-in/fan-out (to chain multiple pipelines) and value stream map.

GoCD works great when it comes to modeling and visualizing workflows spanning across multiple repositories and pipelines.
ConfigurationConfiguration via UIConfiguration via source code, API and UI
Language SupportRuby/JRuby, Python, Node.js/io.js, PHP, Java, Groovy/Gradle, Scala/SBT, Clojure/Leiningen, C/C++, AndroidGoCD will execute tests and perform deployments written using any languages or frameworks
Operating SystemCentOS, UbuntuWindows, Mac OSX and Linux (Debian/Ubuntu CentOS/RedHat)
Docker SupportOut of the box support for dockerUsers are required to setup and configure docker on GoCD agents
Test ParallelizationTest parallelization up to 5 workersTest parallelization and flexibility to scale from one machine to many machines using multiple GoCD agents
Branch TrackingAutomatic branch tracking and pull request integrationPlugin support
SupportFirst class professional support for all usersCommunity based support for all users
1. Google Group
2. Github Discussions for code contributors

Professional support for paid GoCD users
APIAPIs to trigger pipelines and get pipeline historyRich API to configure GoCD, trigger pipelines and get read historical data from GoCD
+ +

What does this really mean for me? Is GoCD the tool for me?

+ +

Basically, if what you liked about Snap CI was the continuous delivery pipelines then GoCD has all that and much more. If you used the Snap CI workaround for fan-in and fan-out pipelines then GoCD can easily meet your pipeline dependency needs. It you loved seeing which stage was broken and halting the line when there was a problem then GoCD can continue to do all that for you. And, if you were waiting for Snap CI's config as code feature to go live or were hoping we'd make Snap CI free to use then GoCD can meet these needs already.

+ +

However, if what you really liked and still need in a CI/CD tool is that it is hosted, and that does not require you to manage your own machines then GoCD is likely not the best choice for you. If seamless support for GitFlow, branch tracking and PRs or out of the box support for Heroku is a priority for you then GoCD is likely not what you should choose.

+ +

If you would like our opinions on which hosted CI/CD tool may best suit your needs please get in touch with us at support@snap-ci.com. We are familiar with many of the tools available and happy to provide our unbiased opinion on what might work for you.

+ +

What's next?

+ +

If you'd like to learn more about GoCD or try it out we recommend the GoCD getting started guide and the GoCD community. And if you do decide to migrate from Snap CI to GoCD then do email us at support@snap-ci.com and we can provide your Snap CI configuration in a GoCD compatible format and help you get started.

+ +

We hope you find this a useful, thorough and fair comparison. We are more than happy to answer any specific questions you may have. We are all the same friendly, informed Thoughtworks team you're used to from Snap CI so drop us a note and say hi!

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02/16/migrating-snapci-to-gocd/index.html b/pr-1714/2017/02/16/migrating-snapci-to-gocd/index.html new file mode 100644 index 000000000..6d67727fa --- /dev/null +++ b/pr-1714/2017/02/16/migrating-snapci-to-gocd/index.html @@ -0,0 +1,321 @@ + + + + + + + + + + + + + + + + Migrating from Snap CI to GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Migrating SnapCI to GoCD +
+ +
+ + +
+

Migrating from Snap CI to GoCD

+

Suzie Prince - Product Manager at Snap CI

+

+

+
+ +
+ +

Many Snap CI users are now looking for a replacement CI/CD tool. In the end of life announcement we recommended that Snap CI users take a look at GoCD and consider it as an alternative. We recommend this not just because Thoughtworks creates and supports both tools, but because we think it's a great choice for Snap CI users. Snap CI had its roots in GoCD and they share common features. However, they were also created with different specific needs in mind and offer unique capabilities.

+ +

This post intends to serve as reference for anyone comparing GoCD to Snap CI (or any other hosted CI/CD tool) and fairly compare them to provide you with useful insights into why GoCD might be a good choice for you. Because we understand the needs of Snap CI users, we will also highlight areas where GoCD may not completely meet your needs and where you may need to consider your own tooling priorities. Finally, should you think that GoCD is a good choice for you, we will provide you with information about how to migrate from Snap CI to GoCD.

+ +

Comparison of GoCD and Snap CI

+ +

Here is the obligatory comparison table. Read on ahead for our opinions.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeaturesSnap CIGoCD
PricingFree for public repositories. Starting at $30 for private repositoriesFree, open source for all users
PlatformHosted software as a serviceRun on your own servers, on-premise or on the cloud
Source ControlGithub integrationGoCD is universal (not platform or tool specific) and extensible through plugins
Pipeline Built with pipelines at the coreBuilt with pipelines at the core
Pipeline DependenciesSome support for fan-in and fan-out pipelines capabilitiesFirst class support for fan-in/fan-out (to chain multiple pipelines) and value stream map.

GoCD works great when it comes to modeling and visualizing workflows spanning across multiple repositories and pipelines.
ConfigurationConfiguration via UIConfiguration via source code, API and UI
Language SupportRuby/JRuby, Python, Node.js/io.js, PHP, Java, Groovy/Gradle, Scala/SBT, Clojure/Leiningen, C/C++, AndroidGoCD will execute tests and perform deployments written using any languages or frameworks
Operating SystemCentOS, UbuntuWindows, Mac OSX and Linux (Debian/Ubuntu CentOS/RedHat)
Docker SupportOut of the box support for dockerUsers are required to setup and configure docker on GoCD agents
Test ParallelizationTest parallelization up to 5 workersTest parallelization and flexibility to scale from one machine to many machines using multiple GoCD agents
Branch TrackingAutomatic branch tracking and pull request integrationPlugin support
SupportFirst class professional support for all usersCommunity based support for all users
1. Google Group
2. Github Discussions for code contributors

Professional support for paid GoCD users
APIAPIs to trigger pipelines and get pipeline historyRich API to configure GoCD, trigger pipelines and get read historical data from GoCD
+ +

What does this really mean for me? Is GoCD the tool for me?

+ +

Basically, if what you liked about Snap CI was the continuous delivery pipelines then GoCD has all that and much more. If you used the Snap CI workaround for fan-in and fan-out pipelines then GoCD can easily meet your pipeline dependency needs. It you loved seeing which stage was broken and halting the line when there was a problem then GoCD can continue to do all that for you. And, if you were waiting for Snap CI's config as code feature to go live or were hoping we'd make Snap CI free to use then GoCD can meet these needs already.

+ +

However, if what you really liked and still need in a CI/CD tool is that it is hosted, and that does not require you to manage your own machines then GoCD is likely not the best choice for you. If seamless support for GitFlow, branch tracking and PRs or out of the box support for Heroku is a priority for you then GoCD is likely not what you should choose.

+ +

If you would like our opinions on which hosted CI/CD tool may best suit your needs please get in touch with us at support@snap-ci.com. We are familiar with many of the tools available and happy to provide our unbiased opinion on what might work for you.

+ +

What's next?

+ +

If you'd like to learn more about GoCD or try it out we recommend the GoCD getting started guide and the GoCD community. And if you do decide to migrate from Snap CI to GoCD then do email us at support@snap-ci.com and we can provide your Snap CI configuration in a GoCD compatible format and help you get started.

+ +

We hope you find this a useful, thorough and fair comparison. We are more than happy to answer any specific questions you may have. We are all the same friendly, informed Thoughtworks team you're used to from Snap CI so drop us a note and say hi!

+ + + + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/02/index.html b/pr-1714/2017/02/index.html new file mode 100644 index 000000000..9cdd01644 --- /dev/null +++ b/pr-1714/2017/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03.html b/pr-1714/2017/03.html new file mode 100644 index 000000000..785a18745 --- /dev/null +++ b/pr-1714/2017/03.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/01.html b/pr-1714/2017/03/01.html new file mode 100644 index 000000000..ba5d5c1cd --- /dev/null +++ b/pr-1714/2017/03/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines.html b/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines.html new file mode 100644 index 000000000..a4d849dde --- /dev/null +++ b/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines.html @@ -0,0 +1,298 @@ + + + + + + + + + + + + + + + + Importance and Principles of CD Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - The Importance and Principles of Continuous Delivery Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 1 - Modeling Deployment Pipelines: The Importance and Principles of Continuous Delivery Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

In an ideal, magical world, your end-to-end deployment from a commit to production looks like this:

+ +

Magic Deployment Pipeline

+ +

If this represents your situation (especially if all your tests run quickly enough that you’re confident about deploying to production), you don’t really need a good Continuous Delivery (referred to as CD) solution and you can stop reading this post right here.

+ +

However, for most of us, the path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. When your path to production is not the magical world shown above, you need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in.

+ +

In this on-going series, we’ll cover aspects of CD pipelines from why they are important to some of the optimal ways to model them.

+ +

What is a Continuous Delivery Pipeline?

+ +

A deployment pipeline is an integral part of Continuous Delivery. It is a way of modeling your software delivery process so that it provides feedback and visibility to the team delivering new features.

+ +

Jez Humble, co-author of the book Continuous Delivery, in his blog says,

+ +
+

Deployment pipelines tie together configuration management, continuous integration and test and deployment automation in a holistic, powerful way that works to improve software quality, increase stability, and reduce the time and cost required to make incremental changes to software, whatever domain you’re operating in.

+
+ +

CD pipelines are incredibly useful in telling you as quickly as possible whether a change is good enough to be taken to production.

+ +

Why do you need a CD pipeline?

+ +

Boiled down to its essence a CD pipeline is a series of feedback loops.

+ +

Quick feedback loops are everywhere, including industries apart from software development. Any situation where you can make a change, see its effect, correct the input to make it go towards a desired outcome (and rinse and repeat) is a great opportunity for feedback loops.

+ +

In technology, some of the obvious attempts at feedback loops are REPLs (Read-Eval-Print-Loops for languages) and tests. And in the world of build and deployment, a deployment pipeline satisfies the need for quick feedback.

+ +

The necessity for a deployment pipeline has been perfectly summed up by Martin Fowler as this

+ +
+

One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of Continuous Delivery.

+
+ +

Some fundamental principles of CD pipelines

+ +

1. Fast feedback first

+ +

Usually, CD pipelines are set up so that the parts which provide fast feedback run first. In practice, quick-running unit tests are usually run earlier in the pipeline than the slower-running functional and performance tests. This ensures quicker feedback by making sure that slower running tests aren’t run unnecessarily taking up resources.

+ +

Fast Feedback Loop

+ +

2. Most important feedback first

+ +

Just because something runs quickly doesn’t mean that it needs to be brought ahead in the CD pipeline. It is possible that running something which is slower but much more valuable, will provide better feedback than running something which is quick but doesn’t fail enough to be useful.

+ +

For instance, installer tests might be valuable and might run quicker than functional tests. However, in a typical project, changes to the installer are much less frequent than changes which might fail functional tests. So, it is reasonable to delay the installer tests till the functional tests have finished.

+ +

3. Parallelize as much as possible

+ +

Ideally, for every change, you want to be able to run every type of test parallely, so that the overall feedback time is reduced. In the extreme case of being able to run everything parallely, the cycle time becomes as much as the longest running part of the pipeline.

+ +

In practice, due to resource constraints, this is not always possible. So, a CD pipeline solution should allow selective parallelization.

+ +

4. Build once and reuse

+ +

This is one of the bedrock CD principles - the ability to build once, get an artifact and run it through different kinds of tests, so that your confidence in that specific artifact increases over time. Once it goes through the final gate in the CD pipeline successfully, you can be assured that the artifact is safe to be deployed to production and used.

+ +

Build artifact once and reuse in deployment pipeline

+ +

It is up to the CD pipeline solution you choose to provide a good artifact propagation mechanism, so that, even with multiple instances of the pipeline running, it keeps track of the correct version of the artifact to be used in the rest of the pipeline.

+ +

5. Able to run this process locally

+ +

It is recommended to have scripts for your whole build and deployment process, so that changes can be easily tracked and audited. Moreover, this allows you to be independent of the CD tool of your choice. This allows you to treat the CD tool as a script runner which is aware of the workflow of deploying to production but isn’t necessarily the only place where the knowledge of how to build and deploy is. This stops it from being a big single-point-of-failure for the organization.

+ +

6. Make the process repeatable

+ +

Through a combination of environment variables and isolation mechanisms such as virtual machines or containers, it is recommended to make the build process repeatable so that it is not dependent on being run at a specific time or on a specific set of worker or agent nodes. Using solutions such as Ansible/Chef/Puppet/SaltStack, etc. for provisioning the virtual machines or agent infrastructure can also help towards this.

+ +

7. Should be able to run or rerun some parts of the pipeline, potentially with different parameters

+ +

It is not uncommon to need to rerun parts of a CD pipeline. Typically, this happens when tests fail for environment-related reasons and you’re trying to confirm that suspicion. It’s also used to get specific versions of a build into an environment, for testing. Even though, ideally, it’s all automatic and you should never have to do this, it’s useful to be able to.

+ +


Boiled down to it, a CD pipeline is going to try to, as quickly as possible, do everything possible to stop your change from going to production. It is great when something fails in a CD pipeline because it means that it did not go into production and fail there.

+ +

In our next post, we’ll look at some common approaches to build and deployment workflows and how CD pipelines can be modeled to accommodate them. We’ll be describing these using GoCD as the CD tool. To follow along, do get to know some of the basic concepts of GoCD and how to get started with GoCD.

+ +

Note: In this series of posts, the examples and images shown will be using GoCD but the concepts are generic and can be implemented on your preferred CD solution.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines/index.html b/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines/index.html new file mode 100644 index 000000000..31e2f65d5 --- /dev/null +++ b/pr-1714/2017/03/01/importance-and-principles-of-cd-pipelines/index.html @@ -0,0 +1,298 @@ + + + + + + + + + + + + + + + + Importance and Principles of CD Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - The Importance and Principles of Continuous Delivery Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 1 - Modeling Deployment Pipelines: The Importance and Principles of Continuous Delivery Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

In an ideal, magical world, your end-to-end deployment from a commit to production looks like this:

+ +

Magic Deployment Pipeline

+ +

If this represents your situation (especially if all your tests run quickly enough that you’re confident about deploying to production), you don’t really need a good Continuous Delivery (referred to as CD) solution and you can stop reading this post right here.

+ +

However, for most of us, the path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. When your path to production is not the magical world shown above, you need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in.

+ +

In this on-going series, we’ll cover aspects of CD pipelines from why they are important to some of the optimal ways to model them.

+ +

What is a Continuous Delivery Pipeline?

+ +

A deployment pipeline is an integral part of Continuous Delivery. It is a way of modeling your software delivery process so that it provides feedback and visibility to the team delivering new features.

+ +

Jez Humble, co-author of the book Continuous Delivery, in his blog says,

+ +
+

Deployment pipelines tie together configuration management, continuous integration and test and deployment automation in a holistic, powerful way that works to improve software quality, increase stability, and reduce the time and cost required to make incremental changes to software, whatever domain you’re operating in.

+
+ +

CD pipelines are incredibly useful in telling you as quickly as possible whether a change is good enough to be taken to production.

+ +

Why do you need a CD pipeline?

+ +

Boiled down to its essence a CD pipeline is a series of feedback loops.

+ +

Quick feedback loops are everywhere, including industries apart from software development. Any situation where you can make a change, see its effect, correct the input to make it go towards a desired outcome (and rinse and repeat) is a great opportunity for feedback loops.

+ +

In technology, some of the obvious attempts at feedback loops are REPLs (Read-Eval-Print-Loops for languages) and tests. And in the world of build and deployment, a deployment pipeline satisfies the need for quick feedback.

+ +

The necessity for a deployment pipeline has been perfectly summed up by Martin Fowler as this

+ +
+

One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of Continuous Delivery.

+
+ +

Some fundamental principles of CD pipelines

+ +

1. Fast feedback first

+ +

Usually, CD pipelines are set up so that the parts which provide fast feedback run first. In practice, quick-running unit tests are usually run earlier in the pipeline than the slower-running functional and performance tests. This ensures quicker feedback by making sure that slower running tests aren’t run unnecessarily taking up resources.

+ +

Fast Feedback Loop

+ +

2. Most important feedback first

+ +

Just because something runs quickly doesn’t mean that it needs to be brought ahead in the CD pipeline. It is possible that running something which is slower but much more valuable, will provide better feedback than running something which is quick but doesn’t fail enough to be useful.

+ +

For instance, installer tests might be valuable and might run quicker than functional tests. However, in a typical project, changes to the installer are much less frequent than changes which might fail functional tests. So, it is reasonable to delay the installer tests till the functional tests have finished.

+ +

3. Parallelize as much as possible

+ +

Ideally, for every change, you want to be able to run every type of test parallely, so that the overall feedback time is reduced. In the extreme case of being able to run everything parallely, the cycle time becomes as much as the longest running part of the pipeline.

+ +

In practice, due to resource constraints, this is not always possible. So, a CD pipeline solution should allow selective parallelization.

+ +

4. Build once and reuse

+ +

This is one of the bedrock CD principles - the ability to build once, get an artifact and run it through different kinds of tests, so that your confidence in that specific artifact increases over time. Once it goes through the final gate in the CD pipeline successfully, you can be assured that the artifact is safe to be deployed to production and used.

+ +

Build artifact once and reuse in deployment pipeline

+ +

It is up to the CD pipeline solution you choose to provide a good artifact propagation mechanism, so that, even with multiple instances of the pipeline running, it keeps track of the correct version of the artifact to be used in the rest of the pipeline.

+ +

5. Able to run this process locally

+ +

It is recommended to have scripts for your whole build and deployment process, so that changes can be easily tracked and audited. Moreover, this allows you to be independent of the CD tool of your choice. This allows you to treat the CD tool as a script runner which is aware of the workflow of deploying to production but isn’t necessarily the only place where the knowledge of how to build and deploy is. This stops it from being a big single-point-of-failure for the organization.

+ +

6. Make the process repeatable

+ +

Through a combination of environment variables and isolation mechanisms such as virtual machines or containers, it is recommended to make the build process repeatable so that it is not dependent on being run at a specific time or on a specific set of worker or agent nodes. Using solutions such as Ansible/Chef/Puppet/SaltStack, etc. for provisioning the virtual machines or agent infrastructure can also help towards this.

+ +

7. Should be able to run or rerun some parts of the pipeline, potentially with different parameters

+ +

It is not uncommon to need to rerun parts of a CD pipeline. Typically, this happens when tests fail for environment-related reasons and you’re trying to confirm that suspicion. It’s also used to get specific versions of a build into an environment, for testing. Even though, ideally, it’s all automatic and you should never have to do this, it’s useful to be able to.

+ +


Boiled down to it, a CD pipeline is going to try to, as quickly as possible, do everything possible to stop your change from going to production. It is great when something fails in a CD pipeline because it means that it did not go into production and fail there.

+ +

In our next post, we’ll look at some common approaches to build and deployment workflows and how CD pipelines can be modeled to accommodate them. We’ll be describing these using GoCD as the CD tool. To follow along, do get to know some of the basic concepts of GoCD and how to get started with GoCD.

+ +

Note: In this series of posts, the examples and images shown will be using GoCD but the concepts are generic and can be implemented on your preferred CD solution.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/01/index.html b/pr-1714/2017/03/01/index.html new file mode 100644 index 000000000..d93a76db6 --- /dev/null +++ b/pr-1714/2017/03/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/29.html b/pr-1714/2017/03/29.html new file mode 100644 index 000000000..9963f589b --- /dev/null +++ b/pr-1714/2017/03/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/29/beginnings-of-a-real-pipeline.html b/pr-1714/2017/03/29/beginnings-of-a-real-pipeline.html new file mode 100644 index 000000000..deef7750a --- /dev/null +++ b/pr-1714/2017/03/29/beginnings-of-a-real-pipeline.html @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + The beginnings of a real CD Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - The beginnings of a real CD pipeline: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 2 - Modeling Deployment Pipelines: The beginnings of a real CD pipeline

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the second post in the series - Modeling Deployment Pipelines. In the first part of the series, we covered what continuous delivery pipelines were, why they were important and some of the fundamental principles behind them. In this post, we'll look at some of the approaches to begin modeling a deployment pipeline for an application and a few ways they can be optimized.

+ +

Typical small app, with some tests

+ +

Consider a small, cross-platform desktop application, with unit, integration and functional tests. Let's assume that the goal of the process is to create an installer which can be downloaded.

+ +

A typical approach to automate this process would be to have a build script (using Rake, Make, Ant, etc. or even a batch file or a shell script) which has all the individual steps of the process automated so that they can be run locally (Principle 5). Having this, you can now create a GoCD pipeline with a single stage which has a single job which has a single task which calls "make all" (for instance). It'll look like this:

+ +

Pipeline with a single task

+ +

While this approach works, it's not very flexible. It doesn't make it easy to run different parts of the process on different agents, makes it hard to track progress and hard to parallelize. Even though it's inside a pipeline, it doesn't use any advantages of the pipeline concept and its modeling capabilities. This is no different from using a standard CI tool and making it run commands.

+ +

A slightly better approach is to break apart the individual pieces into separate GoCD tasks, like so:

+ +

Pipeline with multiple tasks

+ +

This approach makes the individual tasks and the order in which they are run, more explicit. It can be argued that this comes at the expense of tying the order of the processes to the CD tool. However, we think that this orchestration is the job of the CD tool and entrusting it to the CD tool allows better flexibility in modeling the processes.

+ +

Let's see how that can work.

+ +

Does breaking it up into parallelizable jobs help?

+ +

In the current setup, all the tasks still run one after the other and still run on the same agent. Assuming that the tests can be run separately, we can try and use GoCD's jobs to parallelize these. The assumption, at this time, is that the "make build" task creates some artifact which is necessary for the tests to run.

+ +

So, we can try to split up the single job into multiple jobs like this:

+ +

Pipeline with multiple jobs

+ +

However this approach has some disadvantages:

+ +
    +
  • Since jobs run in parallel and are independent of each other, the "make build" is run 4 times, on potentially different agents.
    • +
  • The build (artifact) that the unit tests ran with cannot be guaranteed to be the same as the one that was run with the functional tests and cannot be guaranteed to be the one which the installer was built from.
    • +
  • Apart from this, if the "make build" task fails, it'll fail on all the jobs, complicating efforts to debug the failure.
    • +
+ +

What we really need is some ordering of the different stages of this build process.

+ +

The beginnings of a real pipeline

+ +

When we think about the different parts of this build process, we see that the first one is "make build", which presumably compiles and builds necessary artifacts such as images or generated pages (Stage 1). If this fails, we want to get that feedback quickly (see Principle 1). Once this passes (and only when it passes) do we want to run the unit and integration tests, preferably parallely (see Principle 3) (Stage 2). Moreover, we want to use the same artifact built by the "make build" part of the process, while running these tests (see Principle 4). Once the tests are complete, we want to build the installer (Stage 3) and then run functional tests on the built installer (Stage 4). Very conveniently, GoCD's stage concept allows this kind of a serial handoff and the artifact concept allows us to use the same artifact across the pipeline.

+ +

A setup such as the one described above might look like this:

+ +
+ Pipeline with multiple stages + Click image to zoom in +
+ +

Since stages run one after another, only if Stage 1 passes does it go to Stage 2 and so on. Also, since jobs run parallelly (assuming agents are available), the two jobs which run tests in Stage 2 can potentially run parallelly and provide quicker feedback than when run serially. Also, if both unit tests and integration tests fail for a changeset, then both parts of that feedback will be available simultaneously (in a single pipeline run). This is different from when they were all run serially as tasks in a single job.

+ +

More Jobs vs More Pipelines

+ +

We did mention earlier that our application was cross-platform. So, let's assume that the functional tests need to be run on three different operating systems - Mac OS X, Windows and Linux. We could start to approach this by adding jobs in Stage 4 and use GoCD's resource concept to make sure that the jobs are picked up by agents with the right operating system. This will involve running agents on the different operating systems and tagging them with resources "mac", "windows" and "linux". Once that's done, we could setup our pipeline to look like this:

+ +
+ Pipeline with duplicate jobs + Click image to zoom in +
+

However, this approach isn't the most optimal.

+ +
    +
  • An obvious disadvantage here is the duplication between the three jobs.
    • +
  • Another problem is the lack of extensibility of this approach. It is usual practice to run a set of "smoke" tests before running the full set of functional tests - so that any obvious issues in core functionality are found earlier rather than later. It is also possible that functional tests might need to be run in parallel. So, having a job for each OS's functional tests ends up being limiting. The only way to extend within the job would be to add more tasks which run one after the other.
    • +
+ +

To get around this, we can use GoCD's powerful pipeline chaining mechanism, where a stage of a pipeline can be setup as a dependency for another pipeline. We can create one pipeline per operating system's functional test. Let's see how that looks:

+ +
+ Setting up Pipeline Dependencies + Click image to zoom in +
+ +

This change brings in three new GoCD pipelines and also shows that moving the functional tests to their own pipeline enables better orchestration and control. In this case, there's a "smoke" test stage at the beginning of each pipeline and the functional tests themselves are split into two parallel jobs, which can execute on different agents, potentially improving the end-to-end time. As soon as the installer stage of the "Build" pipeline finishes successfully, all three downstream pipelines are triggered. At this stage, it might occur as if we've replaced duplications that arise with many jobs with multiple pipelines. We'll address how this can be optimized with Pipeline Templates in a later post.

+ +

GoCD provides the same strong guarantees related to artifacts across pipelines and not just within a pipeline. A stage in a downstream pipeline can confidently fetch an artifact published in any of its upstream pipelines and it will get the correct version of that artifact.

+ +

It is not atypical (though it is changing slowly) to deploy a build which has gone through all of these tests onto a set of deployment environments such as a UAT, pre-production and production environment. We'll look at how you can model these in your deployment pipelines in our next post.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/29/beginnings-of-a-real-pipeline/index.html b/pr-1714/2017/03/29/beginnings-of-a-real-pipeline/index.html new file mode 100644 index 000000000..5d3792ae4 --- /dev/null +++ b/pr-1714/2017/03/29/beginnings-of-a-real-pipeline/index.html @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + The beginnings of a real CD Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - The beginnings of a real CD pipeline: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 2 - Modeling Deployment Pipelines: The beginnings of a real CD pipeline

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the second post in the series - Modeling Deployment Pipelines. In the first part of the series, we covered what continuous delivery pipelines were, why they were important and some of the fundamental principles behind them. In this post, we'll look at some of the approaches to begin modeling a deployment pipeline for an application and a few ways they can be optimized.

+ +

Typical small app, with some tests

+ +

Consider a small, cross-platform desktop application, with unit, integration and functional tests. Let's assume that the goal of the process is to create an installer which can be downloaded.

+ +

A typical approach to automate this process would be to have a build script (using Rake, Make, Ant, etc. or even a batch file or a shell script) which has all the individual steps of the process automated so that they can be run locally (Principle 5). Having this, you can now create a GoCD pipeline with a single stage which has a single job which has a single task which calls "make all" (for instance). It'll look like this:

+ +

Pipeline with a single task

+ +

While this approach works, it's not very flexible. It doesn't make it easy to run different parts of the process on different agents, makes it hard to track progress and hard to parallelize. Even though it's inside a pipeline, it doesn't use any advantages of the pipeline concept and its modeling capabilities. This is no different from using a standard CI tool and making it run commands.

+ +

A slightly better approach is to break apart the individual pieces into separate GoCD tasks, like so:

+ +

Pipeline with multiple tasks

+ +

This approach makes the individual tasks and the order in which they are run, more explicit. It can be argued that this comes at the expense of tying the order of the processes to the CD tool. However, we think that this orchestration is the job of the CD tool and entrusting it to the CD tool allows better flexibility in modeling the processes.

+ +

Let's see how that can work.

+ +

Does breaking it up into parallelizable jobs help?

+ +

In the current setup, all the tasks still run one after the other and still run on the same agent. Assuming that the tests can be run separately, we can try and use GoCD's jobs to parallelize these. The assumption, at this time, is that the "make build" task creates some artifact which is necessary for the tests to run.

+ +

So, we can try to split up the single job into multiple jobs like this:

+ +

Pipeline with multiple jobs

+ +

However this approach has some disadvantages:

+ +
    +
  • Since jobs run in parallel and are independent of each other, the "make build" is run 4 times, on potentially different agents.
    • +
  • The build (artifact) that the unit tests ran with cannot be guaranteed to be the same as the one that was run with the functional tests and cannot be guaranteed to be the one which the installer was built from.
    • +
  • Apart from this, if the "make build" task fails, it'll fail on all the jobs, complicating efforts to debug the failure.
    • +
+ +

What we really need is some ordering of the different stages of this build process.

+ +

The beginnings of a real pipeline

+ +

When we think about the different parts of this build process, we see that the first one is "make build", which presumably compiles and builds necessary artifacts such as images or generated pages (Stage 1). If this fails, we want to get that feedback quickly (see Principle 1). Once this passes (and only when it passes) do we want to run the unit and integration tests, preferably parallely (see Principle 3) (Stage 2). Moreover, we want to use the same artifact built by the "make build" part of the process, while running these tests (see Principle 4). Once the tests are complete, we want to build the installer (Stage 3) and then run functional tests on the built installer (Stage 4). Very conveniently, GoCD's stage concept allows this kind of a serial handoff and the artifact concept allows us to use the same artifact across the pipeline.

+ +

A setup such as the one described above might look like this:

+ +
+ Pipeline with multiple stages + Click image to zoom in +
+ +

Since stages run one after another, only if Stage 1 passes does it go to Stage 2 and so on. Also, since jobs run parallelly (assuming agents are available), the two jobs which run tests in Stage 2 can potentially run parallelly and provide quicker feedback than when run serially. Also, if both unit tests and integration tests fail for a changeset, then both parts of that feedback will be available simultaneously (in a single pipeline run). This is different from when they were all run serially as tasks in a single job.

+ +

More Jobs vs More Pipelines

+ +

We did mention earlier that our application was cross-platform. So, let's assume that the functional tests need to be run on three different operating systems - Mac OS X, Windows and Linux. We could start to approach this by adding jobs in Stage 4 and use GoCD's resource concept to make sure that the jobs are picked up by agents with the right operating system. This will involve running agents on the different operating systems and tagging them with resources "mac", "windows" and "linux". Once that's done, we could setup our pipeline to look like this:

+ +
+ Pipeline with duplicate jobs + Click image to zoom in +
+

However, this approach isn't the most optimal.

+ +
    +
  • An obvious disadvantage here is the duplication between the three jobs.
    • +
  • Another problem is the lack of extensibility of this approach. It is usual practice to run a set of "smoke" tests before running the full set of functional tests - so that any obvious issues in core functionality are found earlier rather than later. It is also possible that functional tests might need to be run in parallel. So, having a job for each OS's functional tests ends up being limiting. The only way to extend within the job would be to add more tasks which run one after the other.
    • +
+ +

To get around this, we can use GoCD's powerful pipeline chaining mechanism, where a stage of a pipeline can be setup as a dependency for another pipeline. We can create one pipeline per operating system's functional test. Let's see how that looks:

+ +
+ Setting up Pipeline Dependencies + Click image to zoom in +
+ +

This change brings in three new GoCD pipelines and also shows that moving the functional tests to their own pipeline enables better orchestration and control. In this case, there's a "smoke" test stage at the beginning of each pipeline and the functional tests themselves are split into two parallel jobs, which can execute on different agents, potentially improving the end-to-end time. As soon as the installer stage of the "Build" pipeline finishes successfully, all three downstream pipelines are triggered. At this stage, it might occur as if we've replaced duplications that arise with many jobs with multiple pipelines. We'll address how this can be optimized with Pipeline Templates in a later post.

+ +

GoCD provides the same strong guarantees related to artifacts across pipelines and not just within a pipeline. A stage in a downstream pipeline can confidently fetch an artifact published in any of its upstream pipelines and it will get the correct version of that artifact.

+ +

It is not atypical (though it is changing slowly) to deploy a build which has gone through all of these tests onto a set of deployment environments such as a UAT, pre-production and production environment. We'll look at how you can model these in your deployment pipelines in our next post.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/29/index.html b/pr-1714/2017/03/29/index.html new file mode 100644 index 000000000..319b0a6d7 --- /dev/null +++ b/pr-1714/2017/03/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/03/index.html b/pr-1714/2017/03/index.html new file mode 100644 index 000000000..843428401 --- /dev/null +++ b/pr-1714/2017/03/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04.html b/pr-1714/2017/04.html new file mode 100644 index 000000000..50f39576b --- /dev/null +++ b/pr-1714/2017/04.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/06.html b/pr-1714/2017/04/06.html new file mode 100644 index 000000000..4109fc3f8 --- /dev/null +++ b/pr-1714/2017/04/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/06/index.html b/pr-1714/2017/04/06/index.html new file mode 100644 index 000000000..276e5333f --- /dev/null +++ b/pr-1714/2017/04/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/06/reusing-pipelines.html b/pr-1714/2017/04/06/reusing-pipelines.html new file mode 100644 index 000000000..c639d409b --- /dev/null +++ b/pr-1714/2017/04/06/reusing-pipelines.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Reusing Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - Reusing Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 3 - Modeling Deployment Pipelines: Reusing Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the third post in the series - Modeling Deployment Pipelines. In our previous post, we looked at the initial stages of modeling a deployment pipeline and ways to reduce duplication in jobs by using multiple pipelines. This approach of using multiple pipelines enabled better control, but introduced duplication between the pipelines.

+ +

Having duplicate pipelines increases the time and effort to create and update your pipelines. Ideally, we want to create a reusable pipeline “stencil” that could be used to easily create other similar pipelines by updating certain variables. This makes creation of a new pipeline, that is similar to one already created, much easier & faster. It also means that updating pipelines can be a single update rather than multiple updates. When creating builds that test the same things on different platform or browsers (as in our examples below) this kind of reusability can be very powerful and efficient.

+ +

Reusing Pipelines

+ +

Enter pipeline templates! A template is a concept in GoCD which helps reduce duplication between similar pipelines. It allows stages and jobs to be defined at the template level and through configurable parameters, allows each pipeline which is based off of that template, to set the parameters which make sense for it. Let’s see how a pipeline template can help in this case:

+ +
+Introducing CD build Pipeline Templates +Click image to zoom in +
+ +

There are still 4 pipelines in this image, but because we’ve used a template, all stage and job information has been moved into it. The only parameter used in this template is “OS” and it is shown in the template as “#{OS}”. Any number of parameters can be used in a template. Also, a template in GoCD is “live”, in the sense that any change to the template will automatically apply to all pipelines which are based off of it.

+ +

Here’s a look at what we’ve been able to achieve so far:

+ +
    +
  • We have a three stage “Build” pipeline, which builds, then runs unit and integration tests in parallel and then builds an installer.
    • +
  • As soon as the installer stage in this pipeline succeeds, all three downstream functional test pipelines get triggered.
    • +
  • Based on the template and their own parameters substituted into it, they run a “smoke” stage each and then run functional tests split into two parts.
    • +
  • Owing to the specified resources, GoCD makes sure that only those agents tagged with the resources specified pick up the jobs, thereby running the tests on different operating systems.
    • +
+ +

All of this is just orchestrated through GoCD (or your chosen CD solution), but the actual scripts which do all of this are safely checked into your source control repository, thereby ensuring that you can easily run this locally if you need (see Principle 5).

+ +

Not bad at all!

+ +

Before we look at moving a build to your deployment environment, here is a simplified version of our CD pipeline, which will help with continuing to extend it.

+ +
+Simplified Version of CD build Pipeline +Click image to zoom in +
+ +

Typically, once a build has gone through the various tests (functional, unit, integration etc.), it is deployed onto a set of environments(^1) such as UAT, pre-production and production (for example). This is called “Build Propagation”. We’ll cover in more detail how to implement Build Propagation in your deployment pipeline in our next post.

+ +

^1 - These “deployment environments” are different from the concept of an “Environment” in GoCD. More on that in a later post.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/06/reusing-pipelines/index.html b/pr-1714/2017/04/06/reusing-pipelines/index.html new file mode 100644 index 000000000..fa4bb1d88 --- /dev/null +++ b/pr-1714/2017/04/06/reusing-pipelines/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Reusing Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - Reusing Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 3 - Modeling Deployment Pipelines: Reusing Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the third post in the series - Modeling Deployment Pipelines. In our previous post, we looked at the initial stages of modeling a deployment pipeline and ways to reduce duplication in jobs by using multiple pipelines. This approach of using multiple pipelines enabled better control, but introduced duplication between the pipelines.

+ +

Having duplicate pipelines increases the time and effort to create and update your pipelines. Ideally, we want to create a reusable pipeline “stencil” that could be used to easily create other similar pipelines by updating certain variables. This makes creation of a new pipeline, that is similar to one already created, much easier & faster. It also means that updating pipelines can be a single update rather than multiple updates. When creating builds that test the same things on different platform or browsers (as in our examples below) this kind of reusability can be very powerful and efficient.

+ +

Reusing Pipelines

+ +

Enter pipeline templates! A template is a concept in GoCD which helps reduce duplication between similar pipelines. It allows stages and jobs to be defined at the template level and through configurable parameters, allows each pipeline which is based off of that template, to set the parameters which make sense for it. Let’s see how a pipeline template can help in this case:

+ +
+Introducing CD build Pipeline Templates +Click image to zoom in +
+ +

There are still 4 pipelines in this image, but because we’ve used a template, all stage and job information has been moved into it. The only parameter used in this template is “OS” and it is shown in the template as “#{OS}”. Any number of parameters can be used in a template. Also, a template in GoCD is “live”, in the sense that any change to the template will automatically apply to all pipelines which are based off of it.

+ +

Here’s a look at what we’ve been able to achieve so far:

+ +
    +
  • We have a three stage “Build” pipeline, which builds, then runs unit and integration tests in parallel and then builds an installer.
    • +
  • As soon as the installer stage in this pipeline succeeds, all three downstream functional test pipelines get triggered.
    • +
  • Based on the template and their own parameters substituted into it, they run a “smoke” stage each and then run functional tests split into two parts.
    • +
  • Owing to the specified resources, GoCD makes sure that only those agents tagged with the resources specified pick up the jobs, thereby running the tests on different operating systems.
    • +
+ +

All of this is just orchestrated through GoCD (or your chosen CD solution), but the actual scripts which do all of this are safely checked into your source control repository, thereby ensuring that you can easily run this locally if you need (see Principle 5).

+ +

Not bad at all!

+ +

Before we look at moving a build to your deployment environment, here is a simplified version of our CD pipeline, which will help with continuing to extend it.

+ +
+Simplified Version of CD build Pipeline +Click image to zoom in +
+ +

Typically, once a build has gone through the various tests (functional, unit, integration etc.), it is deployed onto a set of environments(^1) such as UAT, pre-production and production (for example). This is called “Build Propagation”. We’ll cover in more detail how to implement Build Propagation in your deployment pipeline in our next post.

+ +

^1 - These “deployment environments” are different from the concept of an “Environment” in GoCD. More on that in a later post.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/11/gocd-over-jenkins.html b/pr-1714/2017/04/11/gocd-over-jenkins.html new file mode 100644 index 000000000..b835f4b81 --- /dev/null +++ b/pr-1714/2017/04/11/gocd-over-jenkins.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2017/04/11/gocd-over-jenkins/index.html b/pr-1714/2017/04/11/gocd-over-jenkins/index.html new file mode 100644 index 000000000..594b26f7c --- /dev/null +++ b/pr-1714/2017/04/11/gocd-over-jenkins/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../../25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/2017/04/17.html b/pr-1714/2017/04/17.html new file mode 100644 index 000000000..2bb629478 --- /dev/null +++ b/pr-1714/2017/04/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out.html b/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out.html new file mode 100644 index 000000000..a9da6f34e --- /dev/null +++ b/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out.html @@ -0,0 +1,270 @@ + + + + + + + + + + + + + + + + Build Propagation using Fan-in Fan-out | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 4 - Build Propagation using Fan-in/Fan-out: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 4 - Modeling Deployment Pipelines: Build Propagation using Fan-in/Fan-out

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the fourth post in the series - Modeling Deployment Pipelines. In our previous post, we saw the advantages of reusing pipelines (using Templates). In this post, we’ll dive into ways to move your build through the deployment pipeline. Typically, once a build has gone through the various tests, it is deployed onto a set of environments such as UAT, pre-production and production (for example). This concept is called “Build Propagation”.

+ +

Fan-in / Fan-out

+ +

To implement the idea of build propagation in your pipeline, we can use a concept called fan-in / fan-out. In the image below, there is a “fan-out” from the end of the “Build” pipeline. It fans out into three functional test pipelines. The opposite of a fan-out is “fan-in”, where multiple (upstream) pipelines lead into a single (downstream) pipeline.

+ +

Here’s how that looks:

+ +
+Fan-in Fan-out +Click image to zoom in +
+ +

In this scenario, the “UAT” pipeline will wait for all three of its upstream functional test pipelines to finish successfully before it starts. This doesn’t happen just because there are three pipelines fanning into the “UAT” pipeline, but because those three pipelines trace back to the same code repository. This is important to understand. If all three pipelines traced back to different code repositories, for instance, then every successful pipeline run would lead to the “UAT” pipeline starting. Fan-in ensures consistency by making sure that all upstream pipelines which trace back to the same repository have all finished successfully for the same changeset.

+ +

In practice, this means that if one or more of the functional test pipelines fails, then the UAT pipeline doesn’t get triggered. This makes sense since that changeset is not “good enough” to go to UAT.

+ +
+

That’s the real beauty of a CD pipeline - it prevents bad changes from reaching important environments (such as production).

+
+ +

The green arrow in the image represents “Build Propagation” in the pipeline. The installer artifact from the “Build installer” stage is fetched and used. This is the same installer artifact used by the functional test pipelines as well. So, the same artifact, built once, is being pushed further along in the pipeline.

+ +

Highlighting Dependencies

+ +

What we don’t see in the image above, are the dependencies between

+ +
    +
  • the functional test pipelines and the code repository
    • +
  • and between the UAT pipeline and the code repository.
    • +
+ +

For the sake of completeness, we added these dependencies in and this is what the pipeline would look like.

+ +
+Pipeline Dependencies +Click image to zoom in +
+ +

As you can see, it complicates the image quite a bit and so, has been omitted from other images. Owing to GoCD’s fan-in ability, adding that dependency doesn’t change how and when the pipelines are triggered. If a commit is made to the code repository, it does not mean that the functional test pipelines are triggered. Since each functional test pipeline has two dependencies now, both of them have to be compatible (i.e. be the same version) before it triggers.

+ +

For example, if a commit was made in the repository, the “Build” pipeline would build first with that commit. If the "Build" pipeline is successful, then both the dependencies (often called materials) of the functional test pipelines are compatible and the functional test pipelines will run.

+ +

Unlike the example in the image above, maybe your repositories are structured so that functional tests and deployment scripts are in their own repositories. If so, they can be modeled as shown below:

+ +
+Pipeline Repos +Click image to zoom in +
+ +

The advantage of this approach is that a commit to the functional test repository does not trigger the “Build” pipeline (which makes sense). The latest successful instance of the “Build” pipeline will be verified using the new functional test code. In this case, fan-in does not apply, since the two dependencies of the functional test pipelines do not trace back to the same repository or repositories. Similarly, a change to the deployment scripts will not trigger the build and functional tests.

+ +

Depending on your business case, you might find it necessary to have a manual approval process, especially to deploy into sensitive environments such as production, and often pre-production (mostly because it is being used by several people and needs co-ordination). We’ll dive into how to create a manual approval process to propagate your build in our next post. Stay tuned.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out/index.html b/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out/index.html new file mode 100644 index 000000000..d6f648526 --- /dev/null +++ b/pr-1714/2017/04/17/build-propagation-using-fan-in-fan-out/index.html @@ -0,0 +1,270 @@ + + + + + + + + + + + + + + + + Build Propagation using Fan-in Fan-out | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 4 - Build Propagation using Fan-in/Fan-out: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 4 - Modeling Deployment Pipelines: Build Propagation using Fan-in/Fan-out

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the fourth post in the series - Modeling Deployment Pipelines. In our previous post, we saw the advantages of reusing pipelines (using Templates). In this post, we’ll dive into ways to move your build through the deployment pipeline. Typically, once a build has gone through the various tests, it is deployed onto a set of environments such as UAT, pre-production and production (for example). This concept is called “Build Propagation”.

+ +

Fan-in / Fan-out

+ +

To implement the idea of build propagation in your pipeline, we can use a concept called fan-in / fan-out. In the image below, there is a “fan-out” from the end of the “Build” pipeline. It fans out into three functional test pipelines. The opposite of a fan-out is “fan-in”, where multiple (upstream) pipelines lead into a single (downstream) pipeline.

+ +

Here’s how that looks:

+ +
+Fan-in Fan-out +Click image to zoom in +
+ +

In this scenario, the “UAT” pipeline will wait for all three of its upstream functional test pipelines to finish successfully before it starts. This doesn’t happen just because there are three pipelines fanning into the “UAT” pipeline, but because those three pipelines trace back to the same code repository. This is important to understand. If all three pipelines traced back to different code repositories, for instance, then every successful pipeline run would lead to the “UAT” pipeline starting. Fan-in ensures consistency by making sure that all upstream pipelines which trace back to the same repository have all finished successfully for the same changeset.

+ +

In practice, this means that if one or more of the functional test pipelines fails, then the UAT pipeline doesn’t get triggered. This makes sense since that changeset is not “good enough” to go to UAT.

+ +
+

That’s the real beauty of a CD pipeline - it prevents bad changes from reaching important environments (such as production).

+
+ +

The green arrow in the image represents “Build Propagation” in the pipeline. The installer artifact from the “Build installer” stage is fetched and used. This is the same installer artifact used by the functional test pipelines as well. So, the same artifact, built once, is being pushed further along in the pipeline.

+ +

Highlighting Dependencies

+ +

What we don’t see in the image above, are the dependencies between

+ +
    +
  • the functional test pipelines and the code repository
    • +
  • and between the UAT pipeline and the code repository.
    • +
+ +

For the sake of completeness, we added these dependencies in and this is what the pipeline would look like.

+ +
+Pipeline Dependencies +Click image to zoom in +
+ +

As you can see, it complicates the image quite a bit and so, has been omitted from other images. Owing to GoCD’s fan-in ability, adding that dependency doesn’t change how and when the pipelines are triggered. If a commit is made to the code repository, it does not mean that the functional test pipelines are triggered. Since each functional test pipeline has two dependencies now, both of them have to be compatible (i.e. be the same version) before it triggers.

+ +

For example, if a commit was made in the repository, the “Build” pipeline would build first with that commit. If the "Build" pipeline is successful, then both the dependencies (often called materials) of the functional test pipelines are compatible and the functional test pipelines will run.

+ +

Unlike the example in the image above, maybe your repositories are structured so that functional tests and deployment scripts are in their own repositories. If so, they can be modeled as shown below:

+ +
+Pipeline Repos +Click image to zoom in +
+ +

The advantage of this approach is that a commit to the functional test repository does not trigger the “Build” pipeline (which makes sense). The latest successful instance of the “Build” pipeline will be verified using the new functional test code. In this case, fan-in does not apply, since the two dependencies of the functional test pipelines do not trace back to the same repository or repositories. Similarly, a change to the deployment scripts will not trigger the build and functional tests.

+ +

Depending on your business case, you might find it necessary to have a manual approval process, especially to deploy into sensitive environments such as production, and often pre-production (mostly because it is being used by several people and needs co-ordination). We’ll dive into how to create a manual approval process to propagate your build in our next post. Stay tuned.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/17/index.html b/pr-1714/2017/04/17/index.html new file mode 100644 index 000000000..44dcb37c1 --- /dev/null +++ b/pr-1714/2017/04/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/25.html b/pr-1714/2017/04/25.html new file mode 100644 index 000000000..92d564e2f --- /dev/null +++ b/pr-1714/2017/04/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/25/gocd-over-jenkins.html b/pr-1714/2017/04/25/gocd-over-jenkins.html new file mode 100644 index 000000000..dd5faaa59 --- /dev/null +++ b/pr-1714/2017/04/25/gocd-over-jenkins.html @@ -0,0 +1,263 @@ + + + + + + + + + + + + + + + + Why GoCD over Jenkins | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD vs Jenkins +
+ +
+ + +
+

Why GoCD over Jenkins

+

David Rice, Managing Director - Thoughtworks Products

+

+

+
+ +
+ +

We often get asked by potential GoCD users “Why GoCD?” or “Why GoCD over Jenkins?”. Or even more often: “We use Jenkins. It’s not great but it’s set up, we are familiar with it and it’s good enough. Why change?” This blog post sets out to answer those questions. We are not going to tell you GoCD is perfect or even that it does all the same things as Jenkins. It wouldn’t be true. Nor will we provide an exhaustive feature comparison. There is no doubt that this post will skip some Jenkins features that are loved by its users. We will share where GoCD shines when compared to Jenkins. We’ll compare philosophy, getting started, continuous delivery, and plugins. (Spoiler alert: Use GoCD if you want to do continuous delivery).

+ +

Philosophy

+ +

GoCD is a best-of-breed tool for Continuous Delivery (CD). Full stop. GoCD aims to support the most common CD scenarios out of the box without any plugin installation. GoCD’s model maps to the core concepts of CD deployment pipelines.

+ +

Jenkins is a general purpose automation tool. It is not a best-of-breed CI or CD tool. (Yes, Jenkins is a pretty good CI tool.) Pretty much any use case requires installation of a particular set of plugins. Near everything is pluggable and there are over 1000 community plugins. Plugins are fundamental to Jenkins.

+ +

Bottom Line: If you want a single-purposed, focused tool use GoCD. If you aren’t laser-focused on CD and prefer maximum tinker-ability, Jenkins might be for you.

+ +

Continuous Delivery

+ +

CD is a priority for GoCD and for Thoughtworks. GoCD exists to help its users implement CD. Thoughtworks is a thought leader in CD and our people regularly write and speak about CD to the wider tech community.

+ +

GoCD encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns you will generally find a single, well-known, well-tested answer. These searches will turn up results for Jenkins as well but the results might show obsolete plugins or many solutions, without any definitive guidance.

+ +

If you are are new to CD and deployment pipelines, GoCD’s getting started tutorial is a big help. It will teach you the key deployment pipeline patterns while you learn how GoCD works.

+ +

Jenkins 2.0 placed a big emphasis on its Pipeline feature. But there is little evidence that Jenkins has made CD its top priority. CD is still implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile combinations of plugins. The official Pipeline feature documentation does not reference CD or deployment pipeline concepts. You might struggle when implementing many of the core deployment pipeline patterns.

+ +

Bottom Line: If you are serious about implementing CD, beginner or expert, GoCD is the right choice. It’s easy to model deployment pipelines and the GoCD community truly cares about CD.

+ +

Getting Started

+ +

GoCD has an easy to follow, definitive tutorial for getting started. This tutorial teaches the basic concepts of CD as well as the GoCD domain model. Someone new to GoCD will be up and running in 15 minutes with this tutorial. It teaches the app, the core concepts, and the preferred style of building deployment pipelines.

+ +

A large part of installing Jenkins is installing the right mix of plugins for your use case. It can be challenging to know what plugins you will need up front. Jenkins 2.0 has improved this experience a bit by providing a wizard to guide you through plugin installation. This wizard includes a default set of common plugins and prompting you to setup your first build. But this won’t prevent you from needing an in depth understanding of the plugins to create the correct plugin mix for your use case.

+ +

Both products can present a tough getting started experience for someone who just wants to dive right in. GoCD’s model can be difficult to grok if you are coming to it from a pure CI tool. Jenkins has hurdles around configuring required tools, unintuitive SCM configuration, and installing additional plugins.

+ +

Bottom Line: If you are wanting to build deployment pipelines for CD, GoCD’s tutorial will quickly get you to a very productive place. Both tools can be frustrating to use if you are new to them and you don’t RTFM.

+ +

Plugins

+ +

GoCD’s plugin philosophy is that plugins should extend its ecosystem and not alter its core functionality. Nor does the team aim to use plugins to make GoCD ultimately flexible. The aim is to keep it as easy-as-possible to implement CD on GoCD but in as many environments as possible.

+ +

GoCD has a handful of extension points: SCM, task, notifications, authentication, authorization, configuration, elastic agents. The team designs endpoints such that all plugins will be interoperable. It doesn’t matter whether the core team or the community has built the plugin.

+ +

Jenkins has a thriving plugin ecosystem. They should be proud. Jenkins is seemingly infinitely configurable, hackable, and extendable via plugins.

+ +

It’s our opinion requiring just the right set of plugins to get Jenkins to support your use case is problematic. Upgrades are challenging. Support and maintenance are unclear. Not all plugins play well together. There’s almost never one way to do something. Multiple ways of doing things is not bad in and of itself but the follow-on from that is that it’s hard to find answers to questions around how to implement builds & pipelines. And we think that’s a huge problem.

+ +

Bottom Line: GoCD provides its core value out of the box. Maybe you will add a few integration plugins to make GoCD fit better in your environment. Jenkins will require many plugins to deliver value. You will need to understand the plugins, how they interoperate, and how to upgrade them. GoCD will feel more stable. Jenkins will feel more hackable. You will need to decide which is a better match to your needs and philosophy.

+ +

The Final Word

+ +

If you are doing or want to do CD you should be using GoCD. GoCD will feel good to both beginners and those highly experienced in building deployment pipelines. If you want to utilize a vast plugin catalog to automate “all the things” then Jenkins might be a better fit for you.

+ +

The GoCD community continues to grow, is passionate about CD and is where you should be if you are serious about CD. We are happy to discuss individual needs in our user group so get in touch.

+ +
+
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/25/gocd-over-jenkins/index.html b/pr-1714/2017/04/25/gocd-over-jenkins/index.html new file mode 100644 index 000000000..9168cae32 --- /dev/null +++ b/pr-1714/2017/04/25/gocd-over-jenkins/index.html @@ -0,0 +1,263 @@ + + + + + + + + + + + + + + + + Why GoCD over Jenkins | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD vs Jenkins +
+ +
+ + +
+

Why GoCD over Jenkins

+

David Rice, Managing Director - Thoughtworks Products

+

+

+
+ +
+ +

We often get asked by potential GoCD users “Why GoCD?” or “Why GoCD over Jenkins?”. Or even more often: “We use Jenkins. It’s not great but it’s set up, we are familiar with it and it’s good enough. Why change?” This blog post sets out to answer those questions. We are not going to tell you GoCD is perfect or even that it does all the same things as Jenkins. It wouldn’t be true. Nor will we provide an exhaustive feature comparison. There is no doubt that this post will skip some Jenkins features that are loved by its users. We will share where GoCD shines when compared to Jenkins. We’ll compare philosophy, getting started, continuous delivery, and plugins. (Spoiler alert: Use GoCD if you want to do continuous delivery).

+ +

Philosophy

+ +

GoCD is a best-of-breed tool for Continuous Delivery (CD). Full stop. GoCD aims to support the most common CD scenarios out of the box without any plugin installation. GoCD’s model maps to the core concepts of CD deployment pipelines.

+ +

Jenkins is a general purpose automation tool. It is not a best-of-breed CI or CD tool. (Yes, Jenkins is a pretty good CI tool.) Pretty much any use case requires installation of a particular set of plugins. Near everything is pluggable and there are over 1000 community plugins. Plugins are fundamental to Jenkins.

+ +

Bottom Line: If you want a single-purposed, focused tool use GoCD. If you aren’t laser-focused on CD and prefer maximum tinker-ability, Jenkins might be for you.

+ +

Continuous Delivery

+ +

CD is a priority for GoCD and for Thoughtworks. GoCD exists to help its users implement CD. Thoughtworks is a thought leader in CD and our people regularly write and speak about CD to the wider tech community.

+ +

GoCD encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns you will generally find a single, well-known, well-tested answer. These searches will turn up results for Jenkins as well but the results might show obsolete plugins or many solutions, without any definitive guidance.

+ +

If you are are new to CD and deployment pipelines, GoCD’s getting started tutorial is a big help. It will teach you the key deployment pipeline patterns while you learn how GoCD works.

+ +

Jenkins 2.0 placed a big emphasis on its Pipeline feature. But there is little evidence that Jenkins has made CD its top priority. CD is still implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile combinations of plugins. The official Pipeline feature documentation does not reference CD or deployment pipeline concepts. You might struggle when implementing many of the core deployment pipeline patterns.

+ +

Bottom Line: If you are serious about implementing CD, beginner or expert, GoCD is the right choice. It’s easy to model deployment pipelines and the GoCD community truly cares about CD.

+ +

Getting Started

+ +

GoCD has an easy to follow, definitive tutorial for getting started. This tutorial teaches the basic concepts of CD as well as the GoCD domain model. Someone new to GoCD will be up and running in 15 minutes with this tutorial. It teaches the app, the core concepts, and the preferred style of building deployment pipelines.

+ +

A large part of installing Jenkins is installing the right mix of plugins for your use case. It can be challenging to know what plugins you will need up front. Jenkins 2.0 has improved this experience a bit by providing a wizard to guide you through plugin installation. This wizard includes a default set of common plugins and prompting you to setup your first build. But this won’t prevent you from needing an in depth understanding of the plugins to create the correct plugin mix for your use case.

+ +

Both products can present a tough getting started experience for someone who just wants to dive right in. GoCD’s model can be difficult to grok if you are coming to it from a pure CI tool. Jenkins has hurdles around configuring required tools, unintuitive SCM configuration, and installing additional plugins.

+ +

Bottom Line: If you are wanting to build deployment pipelines for CD, GoCD’s tutorial will quickly get you to a very productive place. Both tools can be frustrating to use if you are new to them and you don’t RTFM.

+ +

Plugins

+ +

GoCD’s plugin philosophy is that plugins should extend its ecosystem and not alter its core functionality. Nor does the team aim to use plugins to make GoCD ultimately flexible. The aim is to keep it as easy-as-possible to implement CD on GoCD but in as many environments as possible.

+ +

GoCD has a handful of extension points: SCM, task, notifications, authentication, authorization, configuration, elastic agents. The team designs endpoints such that all plugins will be interoperable. It doesn’t matter whether the core team or the community has built the plugin.

+ +

Jenkins has a thriving plugin ecosystem. They should be proud. Jenkins is seemingly infinitely configurable, hackable, and extendable via plugins.

+ +

It’s our opinion requiring just the right set of plugins to get Jenkins to support your use case is problematic. Upgrades are challenging. Support and maintenance are unclear. Not all plugins play well together. There’s almost never one way to do something. Multiple ways of doing things is not bad in and of itself but the follow-on from that is that it’s hard to find answers to questions around how to implement builds & pipelines. And we think that’s a huge problem.

+ +

Bottom Line: GoCD provides its core value out of the box. Maybe you will add a few integration plugins to make GoCD fit better in your environment. Jenkins will require many plugins to deliver value. You will need to understand the plugins, how they interoperate, and how to upgrade them. GoCD will feel more stable. Jenkins will feel more hackable. You will need to decide which is a better match to your needs and philosophy.

+ +

The Final Word

+ +

If you are doing or want to do CD you should be using GoCD. GoCD will feel good to both beginners and those highly experienced in building deployment pipelines. If you want to utilize a vast plugin catalog to automate “all the things” then Jenkins might be a better fit for you.

+ +

The GoCD community continues to grow, is passionate about CD and is where you should be if you are serious about CD. We are happy to discuss individual needs in our user group so get in touch.

+ +
+
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/25/index.html b/pr-1714/2017/04/25/index.html new file mode 100644 index 000000000..ed07beb46 --- /dev/null +++ b/pr-1714/2017/04/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/04/index.html b/pr-1714/2017/04/index.html new file mode 100644 index 000000000..b0935c2fa --- /dev/null +++ b/pr-1714/2017/04/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05.html b/pr-1714/2017/05.html new file mode 100644 index 000000000..08043be17 --- /dev/null +++ b/pr-1714/2017/05.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/02.html b/pr-1714/2017/05/02.html new file mode 100644 index 000000000..72121c083 --- /dev/null +++ b/pr-1714/2017/05/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/02/index.html b/pr-1714/2017/05/02/index.html new file mode 100644 index 000000000..2de4883cc --- /dev/null +++ b/pr-1714/2017/05/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean.html b/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean.html new file mode 100644 index 000000000..db8e24d87 --- /dev/null +++ b/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean.html @@ -0,0 +1,289 @@ + + + + + + + + + + + + + + + + What Does Pipelines as Code Really Mean | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Pipelines As Code +
+ +
+ + +
+

What Does Pipelines as Code Really Mean?

+

Badri Janakiraman and David Rice

+

+

+
+ +
+ +

Mirroring the rise of interest in infrastructure as code, there has been a considerable interest in defining builds and pipelines as code. But unlike with infrastructure as code, we see a rise in the assumption that defining pipelines as code requires the use of a full programming language. This assumption puzzles us.

+ +

This post will attempt to:

+ +
    +
  • Break down how we got to build and pipelines as code
    • +
  • Fight the assumption that pipelines as code equates to always configuring pipelines with a general purpose programming language
    • +
  • Call out that storing pipeline config in your team’s project repository is orthogonal to pipelines as code
    • +
+ +

Infrastructure as code

+ +

As infrastructure as code is the “as code” movement the majority of us are most familiar with, let’s take a quick look.

+ +

Martin Fowler’s bliki tells us that “Infrastructure as code is the approach to defining computing and network infrastructure through source code that can then be treated just like any software system.” We can keep the code in version control for audit and reproducible builds. As it’s code, we can also test it. Two of the bigger benefits are less stress when rolling out changes as well as reduced mean time to recovery when disaster strikes.

+ +

Infrastructure as code is enabled by countless libraries, scripts, and definition files. Configuration is typically via a declarative syntax such as YAML or JSON, a DSL, or a full-fledged programming language such as Ruby. Pick the right tool for the job.

+ +

Build as code and pipeline as code would have much the same definition. They are an approach to defining your builds and pipelines in diffable, readable files checked into source control that can then be treated just like any software system.

+ +

Build as code

+ +

The first CI server, CruiseControl appeared around 2000/01. Interestingly, CruiseControl fully supported build as code. CruiseControl ran a build by simply calling a specified target in a specified ant file that lived in the project’s source repository. The build was defined in code, an ant build file, and stored in the team’s source repository.

+ +

The next generation of CI servers, mostly notably Hudson/Jenkins (pre 2.0), quickly moved away from that style of build definition. They fully owned the build configuration, often allowed editing only via a GUI, and stored it outside the team’s source code. This caused a number of problems:

+ +
    +
  • Inability to change code and build configuration in lockstep, forcing a lengthy game of whack-a-mole to get the build, the application, and tests in synch.
    • +
  • Inability to track changes to the build configuration, resulting in non-reproducible builds.
    • +
  • Inability to make build configuration changes atomically, resulting in unintended build executions and failures.
    • +
  • In an environment with central build servers, a team was not in control of its own build.
    • +
+ +

In 2011 Travis CI changed things. Travis builds could only be defined in a travis.yml file that lived in your source repository. Developers absolutely loved the travis.yml file. No doubt one reason is that it fixed the above list of problems. But we think it might have as much to do with devops culture and infrastructure as code being in vogue by this time.

+ +

Lessons from the Travis model were as follows:

+ +
    +
  • Keep the build configuration for a specific project alongside the code for that project in the same version control system
    • +
  • Pick an external form for the build configuration that is plain text and is human readable so that the changes could be tracked and diffed much like the changes to any other part of the code.
    • +
+ +

Travis CI mainstreamed build as code. Note that we aren’t talking about utilizing a full programming language yet. Travis CI’s build as code was a YAML file.

+ +

Pipelines as code

+ +

Today, we see deployment pipelines and “CI/CD Servers” are mainstream. And pipelines as code requiring a full programming language is the de facto assumption. In fact, Jenkins has clearly set out to own the term “Pipelines as Code,” including popularizing that the configuration of pipelines should only be done via a programming language.

+ +

We can understand why equating pipelines as code with configuration via a programming language has happened. Deployment pipelines have more complex workflows. A typical microservice architecture will require many deployment pipelines that are for the most part identical. These are problems that are in fact well-solved by most programming languages. And “Pipelines as Code” makes for some great marketing.

+ +

But infrastructure as code doesn’t demand a programming language. Nor should pipelines as code. A CD tool with deployment pipelines really should support the reuse of build and pipeline configuration, parameterization, conditional execution and other common constructs via simple, declarative definitions. We reject the notion that pipelines as code requires writing imperative code.

+ +

Is configuring via a general purpose language wrong?

+ +

No! Absolutely not. We just don’t want it to be the starting point. It brings more complexity. More complexity brings more errors. And in the same way that complex Chef repositories need test-kitchen based unit tests to make sure that they are doing the right thing, a complex and programmed build configuration needs tests itself. Quis custodiet ipsos custodes?

+ +

GoCD tries very hard to support deployment pipelines in such a way that you only need to declare definitions to define your pipelines. But there are scenarios where GoCD’s limits are hit and then something like Gomatic, allowing configuration of pipelines via Python scripts, is useful. As with everything in software, you need to understand the trade-offs and choose the right tools.

+ +

Storing build and pipeline config in the main project repository

+ +

Lastly, there is great confusion between the concept of pipelines as code and the concept of storing the configuration in the team’s main code repository. While the two concepts are often in play together, they are in fact separate concerns. That the pipeline is stored in version control is non-negotiable. But storing pipeline config in the team’s main application repository is not a requirement of pipeline as code.

+ +

In the simple scenarios, where a single team owns everything, by all means store the pipeline config in your main application repository. But in a more complex system, with multiple repositories, multiple dependencies, or other intricacies, there is not enough information in any of the application code repositories to reason how the full pipeline should work. Here you will want to store your pipeline configuration in its own repository.

+ +

GoCD supports pipeline configuration via your application code repository, a repository external to your application code, or a central file that GoCD itself manages under git version control.

+ +

Summary

+ +

It’s great that we all are demanding builds and pipelines as code. Pipelines as code need not always be via a programming language. Don’t awkwardly force your build and pipeline config into your main source repository when it’s not the right thing to do.

+ +

We hope this post helped clear up some of the confusion surrounding pipelines as code. Do let us know by commenting below or tweet to us at @david_j_rice and @badrij.

+ +

Thanks to Paul Hammant for pushing us to offer more prescriptive guidance on where to store the pipeline configuration.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean/index.html b/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean/index.html new file mode 100644 index 000000000..fd5d2b9b7 --- /dev/null +++ b/pr-1714/2017/05/02/what-does-pipelines-as-code-really-mean/index.html @@ -0,0 +1,289 @@ + + + + + + + + + + + + + + + + What Does Pipelines as Code Really Mean | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Pipelines As Code +
+ +
+ + +
+

What Does Pipelines as Code Really Mean?

+

Badri Janakiraman and David Rice

+

+

+
+ +
+ +

Mirroring the rise of interest in infrastructure as code, there has been a considerable interest in defining builds and pipelines as code. But unlike with infrastructure as code, we see a rise in the assumption that defining pipelines as code requires the use of a full programming language. This assumption puzzles us.

+ +

This post will attempt to:

+ +
    +
  • Break down how we got to build and pipelines as code
    • +
  • Fight the assumption that pipelines as code equates to always configuring pipelines with a general purpose programming language
    • +
  • Call out that storing pipeline config in your team’s project repository is orthogonal to pipelines as code
    • +
+ +

Infrastructure as code

+ +

As infrastructure as code is the “as code” movement the majority of us are most familiar with, let’s take a quick look.

+ +

Martin Fowler’s bliki tells us that “Infrastructure as code is the approach to defining computing and network infrastructure through source code that can then be treated just like any software system.” We can keep the code in version control for audit and reproducible builds. As it’s code, we can also test it. Two of the bigger benefits are less stress when rolling out changes as well as reduced mean time to recovery when disaster strikes.

+ +

Infrastructure as code is enabled by countless libraries, scripts, and definition files. Configuration is typically via a declarative syntax such as YAML or JSON, a DSL, or a full-fledged programming language such as Ruby. Pick the right tool for the job.

+ +

Build as code and pipeline as code would have much the same definition. They are an approach to defining your builds and pipelines in diffable, readable files checked into source control that can then be treated just like any software system.

+ +

Build as code

+ +

The first CI server, CruiseControl appeared around 2000/01. Interestingly, CruiseControl fully supported build as code. CruiseControl ran a build by simply calling a specified target in a specified ant file that lived in the project’s source repository. The build was defined in code, an ant build file, and stored in the team’s source repository.

+ +

The next generation of CI servers, mostly notably Hudson/Jenkins (pre 2.0), quickly moved away from that style of build definition. They fully owned the build configuration, often allowed editing only via a GUI, and stored it outside the team’s source code. This caused a number of problems:

+ +
    +
  • Inability to change code and build configuration in lockstep, forcing a lengthy game of whack-a-mole to get the build, the application, and tests in synch.
    • +
  • Inability to track changes to the build configuration, resulting in non-reproducible builds.
    • +
  • Inability to make build configuration changes atomically, resulting in unintended build executions and failures.
    • +
  • In an environment with central build servers, a team was not in control of its own build.
    • +
+ +

In 2011 Travis CI changed things. Travis builds could only be defined in a travis.yml file that lived in your source repository. Developers absolutely loved the travis.yml file. No doubt one reason is that it fixed the above list of problems. But we think it might have as much to do with devops culture and infrastructure as code being in vogue by this time.

+ +

Lessons from the Travis model were as follows:

+ +
    +
  • Keep the build configuration for a specific project alongside the code for that project in the same version control system
    • +
  • Pick an external form for the build configuration that is plain text and is human readable so that the changes could be tracked and diffed much like the changes to any other part of the code.
    • +
+ +

Travis CI mainstreamed build as code. Note that we aren’t talking about utilizing a full programming language yet. Travis CI’s build as code was a YAML file.

+ +

Pipelines as code

+ +

Today, we see deployment pipelines and “CI/CD Servers” are mainstream. And pipelines as code requiring a full programming language is the de facto assumption. In fact, Jenkins has clearly set out to own the term “Pipelines as Code,” including popularizing that the configuration of pipelines should only be done via a programming language.

+ +

We can understand why equating pipelines as code with configuration via a programming language has happened. Deployment pipelines have more complex workflows. A typical microservice architecture will require many deployment pipelines that are for the most part identical. These are problems that are in fact well-solved by most programming languages. And “Pipelines as Code” makes for some great marketing.

+ +

But infrastructure as code doesn’t demand a programming language. Nor should pipelines as code. A CD tool with deployment pipelines really should support the reuse of build and pipeline configuration, parameterization, conditional execution and other common constructs via simple, declarative definitions. We reject the notion that pipelines as code requires writing imperative code.

+ +

Is configuring via a general purpose language wrong?

+ +

No! Absolutely not. We just don’t want it to be the starting point. It brings more complexity. More complexity brings more errors. And in the same way that complex Chef repositories need test-kitchen based unit tests to make sure that they are doing the right thing, a complex and programmed build configuration needs tests itself. Quis custodiet ipsos custodes?

+ +

GoCD tries very hard to support deployment pipelines in such a way that you only need to declare definitions to define your pipelines. But there are scenarios where GoCD’s limits are hit and then something like Gomatic, allowing configuration of pipelines via Python scripts, is useful. As with everything in software, you need to understand the trade-offs and choose the right tools.

+ +

Storing build and pipeline config in the main project repository

+ +

Lastly, there is great confusion between the concept of pipelines as code and the concept of storing the configuration in the team’s main code repository. While the two concepts are often in play together, they are in fact separate concerns. That the pipeline is stored in version control is non-negotiable. But storing pipeline config in the team’s main application repository is not a requirement of pipeline as code.

+ +

In the simple scenarios, where a single team owns everything, by all means store the pipeline config in your main application repository. But in a more complex system, with multiple repositories, multiple dependencies, or other intricacies, there is not enough information in any of the application code repositories to reason how the full pipeline should work. Here you will want to store your pipeline configuration in its own repository.

+ +

GoCD supports pipeline configuration via your application code repository, a repository external to your application code, or a central file that GoCD itself manages under git version control.

+ +

Summary

+ +

It’s great that we all are demanding builds and pipelines as code. Pipelines as code need not always be via a programming language. Don’t awkwardly force your build and pipeline config into your main source repository when it’s not the right thing to do.

+ +

We hope this post helped clear up some of the confusion surrounding pipelines as code. Do let us know by commenting below or tweet to us at @david_j_rice and @badrij.

+ +

Thanks to Paul Hammant for pushing us to offer more prescriptive guidance on where to store the pipeline configuration.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/09.html b/pr-1714/2017/05/09.html new file mode 100644 index 000000000..e75504502 --- /dev/null +++ b/pr-1714/2017/05/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 9 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/09/continuous-integration-devops-research.html b/pr-1714/2017/05/09/continuous-integration-devops-research.html new file mode 100644 index 000000000..d9f8f769e --- /dev/null +++ b/pr-1714/2017/05/09/continuous-integration-devops-research.html @@ -0,0 +1,324 @@ + + + + + + + + + + + + + + + + No One Agrees How to Define CI or CD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ No one agree on CI and CD +
+ +
+ + +
+

No One Agrees How to Define CI or CD

+

Emily Luke (Head of Experience) and Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

Our product teams care deeply about understanding what our users want. We spend a lot of time listening to feedback, chatting with users and seeking their input. Unlike the more customary feedback sessions, Intercom-style chat, and usability studies that we see in most organizations, one type of user research that we do on an ongoing basis is contextual inquiry.

+ +

Contextual inquiry research combines a directed interview with an observation session to understand what a user is saying and feeling, as well as what they do and how they behave on a daily basis. This kind of research helps us to learn more about our community members - how they work, how they want to work, what could be better and what is already pretty great. We learn a lot from this kind of research and use our findings to help us build better products.

+ +

As supporters of open source and promoters of software excellence, we also know that our findings can be helpful to others in our space and so we want to share them with you. This blog post will outline our goals for our most recent contextual research study, how we conducted the study and our main findings. We hope it’s helpful to you and your team! – Emily Luke and Suzie Prince

+ +

Goals

+ +

The two main goals for our study were to:

+ +
    +
  • Identify what users know about continuous integration (CI) and continuous delivery practices and principles.
    • +
  • Identify pain points around practicing continuous delivery on a daily basis.
    • +
+ +

The Study

+ +

We conducted this study using contextual inquiry — a research methodology that takes a combined interview and observation approach. We set up calls, video chats, and in-person conversations with software engineers at varying organizations and with varying levels of expertise to understand how they work, what their big pains are, and the nuances of their days. In most cases, we did a Q&A for part of the session and then asked users to share their screens to show us the CI/continuous delivery tools they currently use and how they use them.

+ +

Contextual Inquiry Study

+ +

After gathering the research, we used a variety of qualitative and quantitative techniques such as an affinity wall, word analysis and data counts to look for trends and meaning.

+ +

Who

+ +

The study took place between February and June 2016. There were 20 participants from 20 different organizations from North America and Europe. The majority of the participants were practicing software engineers whose experience ranged from three years to 20 years. Some participants were also in supporting roles such as engineering managers, founders, data analysts and QAs. Most participants were not users of our products and were selected for their current role and responsibilities rather than familiarity with specific products.

+ +

CI CD Tools Used

+ +

Findings

+ +

There were four key findings we want to share from this study. They are separated out below into the following categories: Definitions, Development Practices, Speed, and Stickiness.

+ +

1. Definitions

+ +

A key focus of our study was learning about what people know about continuous integration and continuous delivery practices and principles. In order to assess this we asked each participant to define continuous integration, continuous deployment, deployment pipelines, continuous delivery and DevOps. We then further explored their understanding by hearing about their current practices and processes as well as future goals.

+ +

Terminology confusion

+ +

There was no consensus on the definitions of CI, continuous delivery, or continuous deployment… at all. Participants confused the definitions of continuous integration, continuous deployment and continuous delivery, often repeating the same definitions for all three terms.

+ +
+

“I honestly don’t really know what the difference between that [continuous delivery] and continuous deployment would be.”

+
+ +

Continuous Integration

+ +

Most participants were unable to comprehensively define CI.[^1] However, many of those who gave an incomplete definition (specifically missing the need to integrate to master/trunk/mainline daily) said they were practicing CI. In particular, of those who said they were using long-lived branches and not regularly checking into a master branch, 90% also said they were practicing continuous integration. With the exception of just more than 10%, everyone using a CI tool said they were practicing CI. It appears that the use of a CI server or tool is fairly synonymous with doing CI.

+ +

Continuous integration and continuous deployment vs. continuous delivery

+ +

Participants are far better able to define continuous deployment than continuous delivery. When describing continuous delivery many would repeat the definition they used to describe continuous deployment. This was exemplified by the use of the phase “continuous deployment” which appeared four times more frequently when describing “continuous delivery” than “continuous delivery” did when describing “continuous deployment”. Likewise, it was clear to us from this study that people were way more likely to use the terms “continuous integration” and “continuous deployment” to explain how they worked (or would like to work) than continuous delivery.

+ +

Continuous deployment was seen as an aspiration for many surveyed, but most believed that they were currently only practicing CI.

+ +

Continuous Delievery Wordcloud

+ +

Continuous Deployment Wordcloud

+ +

Definitions vs practises and aspirations

+ +

Interestingly, many people are still deploying fairly frequently (daily or weekly) and with relative ease even if they didn’t know or could not define the terms surrounding these practices or if they didn’t think they were practicing these things at all. Likewise, some participants unable to define continuous delivery and/or who said they were not practicing continuous delivery did describe a process that was close to our definition of continuous delivery.

+ +

DevOps

+ +

This was almost universally remarked as “hard to define”. The confusion of “ops” with “DevOps” also led some people to remark that it was hard for them to see how anyone could work without DevOps (meaning without operations at all).

+ +
+

“A lot of people have different definitions of it over the years. What I think it boils down to is the organizational practices that allow various teams to come together and successfully deliver software.”

+
+ +

These results were more surprising than we had thought they would be. Most people could not define continuous delivery, CI, continuous deployment, and DevOps - even those who said that they were practicing these things. Although we were already aware from a previous quantitative survey that users of our products (Snap CI and GoCD) were statistically more likely to understand continuous delivery than those using other CI/continuous delivery tools, we were not expecting the confusion between continuous integration, continuous deployment and continuous delivery to be so pronounced.

+ +

2. Development Practices

+ +

Agile

+ +

With all the talk of agile in many parts of the software community we were surprised to find that the majority of people are not self identifying as agile practitioners. Some remain unaware of agile, some identify that they are not agile (“we are waterfall”) and the majority of those that remained recognize agile influences and spoke of specific agile practices that they use (such as iterations or sprints or two week cycles, stories or tasks and standups) when helpful. Agile has become a defacto a choose-your-own-adventure for a lot of software development teams.

+ +

Branches, code reviews and pairing

+ +

Of those surveyed, over 60% described their practices as using branches or branch-based development. In those cases participants regularly used branches for feature development or had long-lived (~ over a day or two) branches of some kind.

+ +

There were particular sets of practices that we recognized occurred frequently together, e.g. branched-based development was often accompanied by code reviews and low levels of pairing. In particular, even with the small sample size, we were able to see that there was statistical significance (at 80% confidence) that people who used branch-based development were likely not to be pairing on a daily basis and that those not pairing regularly were likely to practice code reviews. In many cases, code reviews were highlighted as a painful practice.

+ +
+

“Code review tends to be fairly brutal. The idea being the code should be well formed and if it’s not well formed it just doesn’t pass code review, so people learn very quickly not to get precious about their code.”

+
+ +

Likewise, it was very interesting to see that pair programming was not considered to be a crucial development practice, even for those who considered themselves to be doing agile development. Only 13% of participants paired on a daily basis. While not practicing pairing regularly, some remarked that it was used when necessary, such as when training new team members, when there were hard problems or when someone asked for support.

+ +

3. Speed

+ +

When asked what the #1 thing most teams could do better, multiple answers hinged on doing things quickly. Even individuals in teams who were used to deploying very regularly - as needed, daily or weekly rather than monthly or yearly - expressed a desire to be quicker. Sometimes the urgency was explained as a frustration with slow tools or slow processes but other times it was a desire and need for urgency and to “be better”. It is clear that software teams in many organizations are feeling the push to deliver quickly and being faster becomes an important goal for many.

+ +
+

“I think we make pretty good software. I think we can make it faster. I think that we have a lot of pain around iteration cycles. I make a change and I want to see that it passed tests and it takes me a long time for that to happen.”

+
+ +

External research such as Puppet’s State of DevOps survey supports these findings and show us what’s driving this urgency on engineering teams. In the 2016 survey, Humble, et. al. concluded that high performers deploy 200 times more frequently than low performers, with 2,555 times faster lead times. It is therefore easy to understand that many teams are striving for these more frequent deployments and faster lead times.

+ +

4. Stickiness

+ +
+

“Once something is ingrained, it’s hard to replace it but if we think it’s causing us more pain, we’re willing to do the investigation to determine what it would take to replace it.“

+
+ +

CI/continuous delivery tools are sticky… even when they are painful. Despite frequently hearing about frustrations with CI/continuous delivery tools, we also found that participants in our study seem to stick with their current CI/continuous delivery tools even if they recognized pain with them. People recognized that CI/continuous delivery tools need to be reliable but also continued to use tools that were embedded in their process even if they had prior reliability problems. Participants also expressed numerous times that moving tools was not easy and that although new tools were described as desirable, people also seemed reluctant to undergo the change for limited or unknown new value.

+ +
+ +

We see immense value in understanding customers, users and the software community in general. As highlighted by findings in this study, users of specific technologies are not necessarily a good indication of the market at large. Similarly, in-depth conversations and observations can reveal nuances that surveys and/or shallow conversations can obscure. We highly recommend that all creators of software for developers use techniques such as contextual inquiry research to learn more. We also encourage you all to add to our growing knowledge about software by sharing your findings publicly.

+ +

In future blog posts we hope to share more findings from other research studies we do, share tips and tricks for conducting contextual research and details about other methods of ethnographic research that could be useful to you.

+ +

We are also open to your feedback. Let us know how we can improve our tools, techniques, and how we share information. You can comment below or tweet us at @emilyeatskale and @pm_suzie.

+ +

Footnote: [^1]: Our standard definition for continuous integration in this study was set as “Everyone merges to mainline/master/trunk at least once a day. Each merge is built and tested on an integration machine.”

+ +

Note: This post was originally published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/09/continuous-integration-devops-research/index.html b/pr-1714/2017/05/09/continuous-integration-devops-research/index.html new file mode 100644 index 000000000..9d88efa19 --- /dev/null +++ b/pr-1714/2017/05/09/continuous-integration-devops-research/index.html @@ -0,0 +1,324 @@ + + + + + + + + + + + + + + + + No One Agrees How to Define CI or CD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ No one agree on CI and CD +
+ +
+ + +
+

No One Agrees How to Define CI or CD

+

Emily Luke (Head of Experience) and Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

Our product teams care deeply about understanding what our users want. We spend a lot of time listening to feedback, chatting with users and seeking their input. Unlike the more customary feedback sessions, Intercom-style chat, and usability studies that we see in most organizations, one type of user research that we do on an ongoing basis is contextual inquiry.

+ +

Contextual inquiry research combines a directed interview with an observation session to understand what a user is saying and feeling, as well as what they do and how they behave on a daily basis. This kind of research helps us to learn more about our community members - how they work, how they want to work, what could be better and what is already pretty great. We learn a lot from this kind of research and use our findings to help us build better products.

+ +

As supporters of open source and promoters of software excellence, we also know that our findings can be helpful to others in our space and so we want to share them with you. This blog post will outline our goals for our most recent contextual research study, how we conducted the study and our main findings. We hope it’s helpful to you and your team! – Emily Luke and Suzie Prince

+ +

Goals

+ +

The two main goals for our study were to:

+ +
    +
  • Identify what users know about continuous integration (CI) and continuous delivery practices and principles.
    • +
  • Identify pain points around practicing continuous delivery on a daily basis.
    • +
+ +

The Study

+ +

We conducted this study using contextual inquiry — a research methodology that takes a combined interview and observation approach. We set up calls, video chats, and in-person conversations with software engineers at varying organizations and with varying levels of expertise to understand how they work, what their big pains are, and the nuances of their days. In most cases, we did a Q&A for part of the session and then asked users to share their screens to show us the CI/continuous delivery tools they currently use and how they use them.

+ +

Contextual Inquiry Study

+ +

After gathering the research, we used a variety of qualitative and quantitative techniques such as an affinity wall, word analysis and data counts to look for trends and meaning.

+ +

Who

+ +

The study took place between February and June 2016. There were 20 participants from 20 different organizations from North America and Europe. The majority of the participants were practicing software engineers whose experience ranged from three years to 20 years. Some participants were also in supporting roles such as engineering managers, founders, data analysts and QAs. Most participants were not users of our products and were selected for their current role and responsibilities rather than familiarity with specific products.

+ +

CI CD Tools Used

+ +

Findings

+ +

There were four key findings we want to share from this study. They are separated out below into the following categories: Definitions, Development Practices, Speed, and Stickiness.

+ +

1. Definitions

+ +

A key focus of our study was learning about what people know about continuous integration and continuous delivery practices and principles. In order to assess this we asked each participant to define continuous integration, continuous deployment, deployment pipelines, continuous delivery and DevOps. We then further explored their understanding by hearing about their current practices and processes as well as future goals.

+ +

Terminology confusion

+ +

There was no consensus on the definitions of CI, continuous delivery, or continuous deployment… at all. Participants confused the definitions of continuous integration, continuous deployment and continuous delivery, often repeating the same definitions for all three terms.

+ +
+

“I honestly don’t really know what the difference between that [continuous delivery] and continuous deployment would be.”

+
+ +

Continuous Integration

+ +

Most participants were unable to comprehensively define CI.[^1] However, many of those who gave an incomplete definition (specifically missing the need to integrate to master/trunk/mainline daily) said they were practicing CI. In particular, of those who said they were using long-lived branches and not regularly checking into a master branch, 90% also said they were practicing continuous integration. With the exception of just more than 10%, everyone using a CI tool said they were practicing CI. It appears that the use of a CI server or tool is fairly synonymous with doing CI.

+ +

Continuous integration and continuous deployment vs. continuous delivery

+ +

Participants are far better able to define continuous deployment than continuous delivery. When describing continuous delivery many would repeat the definition they used to describe continuous deployment. This was exemplified by the use of the phase “continuous deployment” which appeared four times more frequently when describing “continuous delivery” than “continuous delivery” did when describing “continuous deployment”. Likewise, it was clear to us from this study that people were way more likely to use the terms “continuous integration” and “continuous deployment” to explain how they worked (or would like to work) than continuous delivery.

+ +

Continuous deployment was seen as an aspiration for many surveyed, but most believed that they were currently only practicing CI.

+ +

Continuous Delievery Wordcloud

+ +

Continuous Deployment Wordcloud

+ +

Definitions vs practises and aspirations

+ +

Interestingly, many people are still deploying fairly frequently (daily or weekly) and with relative ease even if they didn’t know or could not define the terms surrounding these practices or if they didn’t think they were practicing these things at all. Likewise, some participants unable to define continuous delivery and/or who said they were not practicing continuous delivery did describe a process that was close to our definition of continuous delivery.

+ +

DevOps

+ +

This was almost universally remarked as “hard to define”. The confusion of “ops” with “DevOps” also led some people to remark that it was hard for them to see how anyone could work without DevOps (meaning without operations at all).

+ +
+

“A lot of people have different definitions of it over the years. What I think it boils down to is the organizational practices that allow various teams to come together and successfully deliver software.”

+
+ +

These results were more surprising than we had thought they would be. Most people could not define continuous delivery, CI, continuous deployment, and DevOps - even those who said that they were practicing these things. Although we were already aware from a previous quantitative survey that users of our products (Snap CI and GoCD) were statistically more likely to understand continuous delivery than those using other CI/continuous delivery tools, we were not expecting the confusion between continuous integration, continuous deployment and continuous delivery to be so pronounced.

+ +

2. Development Practices

+ +

Agile

+ +

With all the talk of agile in many parts of the software community we were surprised to find that the majority of people are not self identifying as agile practitioners. Some remain unaware of agile, some identify that they are not agile (“we are waterfall”) and the majority of those that remained recognize agile influences and spoke of specific agile practices that they use (such as iterations or sprints or two week cycles, stories or tasks and standups) when helpful. Agile has become a defacto a choose-your-own-adventure for a lot of software development teams.

+ +

Branches, code reviews and pairing

+ +

Of those surveyed, over 60% described their practices as using branches or branch-based development. In those cases participants regularly used branches for feature development or had long-lived (~ over a day or two) branches of some kind.

+ +

There were particular sets of practices that we recognized occurred frequently together, e.g. branched-based development was often accompanied by code reviews and low levels of pairing. In particular, even with the small sample size, we were able to see that there was statistical significance (at 80% confidence) that people who used branch-based development were likely not to be pairing on a daily basis and that those not pairing regularly were likely to practice code reviews. In many cases, code reviews were highlighted as a painful practice.

+ +
+

“Code review tends to be fairly brutal. The idea being the code should be well formed and if it’s not well formed it just doesn’t pass code review, so people learn very quickly not to get precious about their code.”

+
+ +

Likewise, it was very interesting to see that pair programming was not considered to be a crucial development practice, even for those who considered themselves to be doing agile development. Only 13% of participants paired on a daily basis. While not practicing pairing regularly, some remarked that it was used when necessary, such as when training new team members, when there were hard problems or when someone asked for support.

+ +

3. Speed

+ +

When asked what the #1 thing most teams could do better, multiple answers hinged on doing things quickly. Even individuals in teams who were used to deploying very regularly - as needed, daily or weekly rather than monthly or yearly - expressed a desire to be quicker. Sometimes the urgency was explained as a frustration with slow tools or slow processes but other times it was a desire and need for urgency and to “be better”. It is clear that software teams in many organizations are feeling the push to deliver quickly and being faster becomes an important goal for many.

+ +
+

“I think we make pretty good software. I think we can make it faster. I think that we have a lot of pain around iteration cycles. I make a change and I want to see that it passed tests and it takes me a long time for that to happen.”

+
+ +

External research such as Puppet’s State of DevOps survey supports these findings and show us what’s driving this urgency on engineering teams. In the 2016 survey, Humble, et. al. concluded that high performers deploy 200 times more frequently than low performers, with 2,555 times faster lead times. It is therefore easy to understand that many teams are striving for these more frequent deployments and faster lead times.

+ +

4. Stickiness

+ +
+

“Once something is ingrained, it’s hard to replace it but if we think it’s causing us more pain, we’re willing to do the investigation to determine what it would take to replace it.“

+
+ +

CI/continuous delivery tools are sticky… even when they are painful. Despite frequently hearing about frustrations with CI/continuous delivery tools, we also found that participants in our study seem to stick with their current CI/continuous delivery tools even if they recognized pain with them. People recognized that CI/continuous delivery tools need to be reliable but also continued to use tools that were embedded in their process even if they had prior reliability problems. Participants also expressed numerous times that moving tools was not easy and that although new tools were described as desirable, people also seemed reluctant to undergo the change for limited or unknown new value.

+ +
+ +

We see immense value in understanding customers, users and the software community in general. As highlighted by findings in this study, users of specific technologies are not necessarily a good indication of the market at large. Similarly, in-depth conversations and observations can reveal nuances that surveys and/or shallow conversations can obscure. We highly recommend that all creators of software for developers use techniques such as contextual inquiry research to learn more. We also encourage you all to add to our growing knowledge about software by sharing your findings publicly.

+ +

In future blog posts we hope to share more findings from other research studies we do, share tips and tricks for conducting contextual research and details about other methods of ethnographic research that could be useful to you.

+ +

We are also open to your feedback. Let us know how we can improve our tools, techniques, and how we share information. You can comment below or tweet us at @emilyeatskale and @pm_suzie.

+ +

Footnote: [^1]: Our standard definition for continuous integration in this study was set as “Everyone merges to mainline/master/trunk at least once a day. Each merge is built and tested on an integration machine.”

+ +

Note: This post was originally published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/09/index.html b/pr-1714/2017/05/09/index.html new file mode 100644 index 000000000..00ef7c48e --- /dev/null +++ b/pr-1714/2017/05/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 9 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/16.html b/pr-1714/2017/05/16.html new file mode 100644 index 000000000..00bfe12df --- /dev/null +++ b/pr-1714/2017/05/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/16/index.html b/pr-1714/2017/05/16/index.html new file mode 100644 index 000000000..21cd966d9 --- /dev/null +++ b/pr-1714/2017/05/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/16/its-not-CI-its-CI-theatre.html b/pr-1714/2017/05/16/its-not-CI-its-CI-theatre.html new file mode 100644 index 000000000..d55186e9c --- /dev/null +++ b/pr-1714/2017/05/16/its-not-CI-its-CI-theatre.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + It's not CI, it's just CI Theatre | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CI Theatre +
+ +
+ + +
+

It’s not CI, it’s just CI theatre

+

Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

The Thoughtworks tech radar recently recommended putting a “Hold” on the tech team antipattern, “CI Theatre”. “CI theatre” describes the illusion of practising continuous integration (CI) while not really practising it. Based on continuous integration research my colleague, Emily Luke, and I conducted, I will share what CI Theatre looks like, why we recommend you “Hold” on that, and ways to combat CI theatre.

+ +

Continuous Integration

+ +

My favorite definition of CI comes from Jez Humble on continuousdelivery.com

+ +
+

"CI developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily)."

+
+ +

There are two fundamental principles of the CI practice hiding in this quote. The first is “integrate all their work into trunk” and the second, “at least daily”.

+ +

There are also a whole host of other principles and practices that make CI, such as checking everything into your source repository, building every commit, automating the build, keeping the build fast, having self testing code, showing visible failures and fixing failures immediately as detailed by Martin Fowler in his reference post on Continuous Integration. Personally I believe that checking into master at least once daily is a fundamental cornerstone to good CI. And without it, you are not practising CI but CI theatre.

+ +

What does CI theatre look like?

+ +

Here’s a story from our research. An experienced developer, (let’s call him David) is from a medium sized startup in the Bay Area and delivers to production twice a week. David described his organization as practising CI by saying, "Yeah, we use Circle CI.", He described a challenging situation where he worked on a branch for a while, changed 100 files and 7000 lines of code, entered a code review and became overwhelmed explaining all his changes to his colleagues.

+ +

"The most challenging thing is when you end up with a lot of features piled together in one commit because they're all part of one story", he said "I wish there was a nicer way to decompose commits because it's hard to keep everything in your head."

+ +

If this situation sounds familiar to you, you have a case of CI theater. You have CI Theatre if you:

+ +
    +
  • Say “we have a CI server” and “we use x tool” when asked “are you practising CI?”
    • +
+ +

In our study only 10% of participants acknowledged that having a CI server was not the same as practising CI. Conversely, 90% of individuals said they were practising CI regardless of whether they were specifically practising the fundamentals of CI or not. Therefore, thinking that simply by having a CI server is “doing CI” is a clear indicator of “CI theatre”.

+ +
    +
  • Use long-lived branches and do not regularly check into your master branch
    • +
+ +

In David’s story, not checking into master on a daily basis was a sign of “CI Theatre”. It’s a pattern we saw in our research where teams ran CI against the master but with infrequent, less than daily commits. Or they ran CI against their branches without integrating to master frequently. Running CI against feature branches leads to a different definition of CI called continuous isolation.

+ +
    +
  • Feel anxiety and fatigue when merging branches
    • +
+ +

True continuous integration distributes code ownership. This changes the perspective of people within the team and their attitude towards broken builds. It’s no longer "my precious branch” or “my fault the build is broken”, but “our code” and “our failure”. The fact that David experienced anxiety and fatigue is a clear indication that he was missing one important benefit of CI: continuous feedback and collective ownership.

+ +

There are more signs of CI theater that we found to be less common but still challenging and problematic like,

+ +
    +
  • running a build with poor test coverage and
    • +
  • allowing the build to stay red for long periods.
    • +
+ +

Although David’s team had a well respected CI tool in place and + common processes such as feature branching and code reviews, they were not practising the full set of CI practices and therefore missed many of its benefits. We sadly find that it’s happened in 90% of organisations in our research.

+ +
+

Key benefits missed by organizations practising CI Theatre are - fast feedback, collective ownership and being ready to move to continuous delivery.

+
+ +

How to avoid, combat and resolve CI theatre?

+ +

If you have identified that you might be suffering from CI theatre, here are three ways to combat the problem and make lasting change.

+ +

1. Commit more often

+ +

Go back to basics. Commit more often. Committing at least daily, is the minimum you should be aiming for. If you are not doing CI, this is where you can get started and even if you are “doing CI” there is always room to improve. I love the saying “Frequency reduces difficulty”. In doing something more often, the task becomes smaller, making it easier to achieve. Continuous integration is a key example of something becoming easier the more often you do it. My advice is commit code to your repos more often and integrate branches to ‘master’ at least daily.

+ +

2. Trunk based development

+ +

There are many forums for discussion about trunk based development vs branch based development and I don’t want to get into the gory details. However, in our research when we talked to people who experienced pain with their CI process, the teams that didn’t practice trunk based development, experienced it the most. The State of DevOps report 2016 also found that practising trunk based development and continuous integration were important aspects of continuous delivery and contributed to higher performance of teams.

+ +

Trunk based development certainly has its own challenges, but it brings the pain forward rather than storing it up for merges, code reviews or delaying releases. I recommend doing trunk based development if you want to do better CI and CD, or if you prefer, use short lived branches with very short lifetimes (less than a day before merging to master), and have less than three active branches in total.

+ +

3. Automate

+ +

Automation is a cornerstone of strong continuous integration so if you haven’t automated everything already, now is a good time to start. If you think you have automated all you can, then every time anyone on the team does anything manually more than once, ask yourself “Why can’t this be automated?”. I’ve seen that not only does automation help you get better at CI, it helps you to start practising continuous delivery as well.

+ +

Summary

+ +

Now you know what CI theatre is, if your team is practising it and ways you can avoid it. If you are still confused I recommend you check out the tongue in cheek “CI Certification test” on Martin Fowler’s blog to confirm if your organisation is doing credible CI or not. And if you passed the CI test, great. Now it’s time to consider whether you are ready for Continuous Delivery.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/16/its-not-CI-its-CI-theatre/index.html b/pr-1714/2017/05/16/its-not-CI-its-CI-theatre/index.html new file mode 100644 index 000000000..e375bfe91 --- /dev/null +++ b/pr-1714/2017/05/16/its-not-CI-its-CI-theatre/index.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + It's not CI, it's just CI Theatre | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CI Theatre +
+ +
+ + +
+

It’s not CI, it’s just CI theatre

+

Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

The Thoughtworks tech radar recently recommended putting a “Hold” on the tech team antipattern, “CI Theatre”. “CI theatre” describes the illusion of practising continuous integration (CI) while not really practising it. Based on continuous integration research my colleague, Emily Luke, and I conducted, I will share what CI Theatre looks like, why we recommend you “Hold” on that, and ways to combat CI theatre.

+ +

Continuous Integration

+ +

My favorite definition of CI comes from Jez Humble on continuousdelivery.com

+ +
+

"CI developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily)."

+
+ +

There are two fundamental principles of the CI practice hiding in this quote. The first is “integrate all their work into trunk” and the second, “at least daily”.

+ +

There are also a whole host of other principles and practices that make CI, such as checking everything into your source repository, building every commit, automating the build, keeping the build fast, having self testing code, showing visible failures and fixing failures immediately as detailed by Martin Fowler in his reference post on Continuous Integration. Personally I believe that checking into master at least once daily is a fundamental cornerstone to good CI. And without it, you are not practising CI but CI theatre.

+ +

What does CI theatre look like?

+ +

Here’s a story from our research. An experienced developer, (let’s call him David) is from a medium sized startup in the Bay Area and delivers to production twice a week. David described his organization as practising CI by saying, "Yeah, we use Circle CI.", He described a challenging situation where he worked on a branch for a while, changed 100 files and 7000 lines of code, entered a code review and became overwhelmed explaining all his changes to his colleagues.

+ +

"The most challenging thing is when you end up with a lot of features piled together in one commit because they're all part of one story", he said "I wish there was a nicer way to decompose commits because it's hard to keep everything in your head."

+ +

If this situation sounds familiar to you, you have a case of CI theater. You have CI Theatre if you:

+ +
    +
  • Say “we have a CI server” and “we use x tool” when asked “are you practising CI?”
    • +
+ +

In our study only 10% of participants acknowledged that having a CI server was not the same as practising CI. Conversely, 90% of individuals said they were practising CI regardless of whether they were specifically practising the fundamentals of CI or not. Therefore, thinking that simply by having a CI server is “doing CI” is a clear indicator of “CI theatre”.

+ +
    +
  • Use long-lived branches and do not regularly check into your master branch
    • +
+ +

In David’s story, not checking into master on a daily basis was a sign of “CI Theatre”. It’s a pattern we saw in our research where teams ran CI against the master but with infrequent, less than daily commits. Or they ran CI against their branches without integrating to master frequently. Running CI against feature branches leads to a different definition of CI called continuous isolation.

+ +
    +
  • Feel anxiety and fatigue when merging branches
    • +
+ +

True continuous integration distributes code ownership. This changes the perspective of people within the team and their attitude towards broken builds. It’s no longer "my precious branch” or “my fault the build is broken”, but “our code” and “our failure”. The fact that David experienced anxiety and fatigue is a clear indication that he was missing one important benefit of CI: continuous feedback and collective ownership.

+ +

There are more signs of CI theater that we found to be less common but still challenging and problematic like,

+ +
    +
  • running a build with poor test coverage and
    • +
  • allowing the build to stay red for long periods.
    • +
+ +

Although David’s team had a well respected CI tool in place and + common processes such as feature branching and code reviews, they were not practising the full set of CI practices and therefore missed many of its benefits. We sadly find that it’s happened in 90% of organisations in our research.

+ +
+

Key benefits missed by organizations practising CI Theatre are - fast feedback, collective ownership and being ready to move to continuous delivery.

+
+ +

How to avoid, combat and resolve CI theatre?

+ +

If you have identified that you might be suffering from CI theatre, here are three ways to combat the problem and make lasting change.

+ +

1. Commit more often

+ +

Go back to basics. Commit more often. Committing at least daily, is the minimum you should be aiming for. If you are not doing CI, this is where you can get started and even if you are “doing CI” there is always room to improve. I love the saying “Frequency reduces difficulty”. In doing something more often, the task becomes smaller, making it easier to achieve. Continuous integration is a key example of something becoming easier the more often you do it. My advice is commit code to your repos more often and integrate branches to ‘master’ at least daily.

+ +

2. Trunk based development

+ +

There are many forums for discussion about trunk based development vs branch based development and I don’t want to get into the gory details. However, in our research when we talked to people who experienced pain with their CI process, the teams that didn’t practice trunk based development, experienced it the most. The State of DevOps report 2016 also found that practising trunk based development and continuous integration were important aspects of continuous delivery and contributed to higher performance of teams.

+ +

Trunk based development certainly has its own challenges, but it brings the pain forward rather than storing it up for merges, code reviews or delaying releases. I recommend doing trunk based development if you want to do better CI and CD, or if you prefer, use short lived branches with very short lifetimes (less than a day before merging to master), and have less than three active branches in total.

+ +

3. Automate

+ +

Automation is a cornerstone of strong continuous integration so if you haven’t automated everything already, now is a good time to start. If you think you have automated all you can, then every time anyone on the team does anything manually more than once, ask yourself “Why can’t this be automated?”. I’ve seen that not only does automation help you get better at CI, it helps you to start practising continuous delivery as well.

+ +

Summary

+ +

Now you know what CI theatre is, if your team is practising it and ways you can avoid it. If you are still confused I recommend you check out the tongue in cheek “CI Certification test” on Martin Fowler’s blog to confirm if your organisation is doing credible CI or not. And if you passed the CI test, great. Now it’s time to consider whether you are ready for Continuous Delivery.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/23.html b/pr-1714/2017/05/23.html new file mode 100644 index 000000000..593d5a613 --- /dev/null +++ b/pr-1714/2017/05/23.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 23 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/23/control-deployments-manual-approvals.html b/pr-1714/2017/05/23/control-deployments-manual-approvals.html new file mode 100644 index 000000000..34d1b5cba --- /dev/null +++ b/pr-1714/2017/05/23/control-deployments-manual-approvals.html @@ -0,0 +1,260 @@ + + + + + + + + + + + + + + + + Control deployments using Manual Gates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 5 - Control deployments using Manual Gates: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 5 - Modeling Deployment Pipelines: Control deployments using Manual Gates

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the fifth post in the series - Modeling Deployment Pipelines. In our previous post, we talked about how using Fan-in/Fan-out helps build propagation. In this post, we will show you how to use a manual approval process to propagate your build which is especially useful for critical deployments.

+ +

The Importance of Manual Approvals

+ +

To deploy into environments such as production, and pre-production, it’s often important to have a manual approval process. This way, you can also make sure that your deployment happens only when you're ready for it (be it in terms of the time of the day, or in terms of other dependencies you need to wait for). We refer to this approval process as a “gate” since it works as one to control the build propagation by either stopping or allowing the build to go through. (Note: Manual gates are supported by GoCD, out of the box, by marking a stage as manual). Here’s an image which shows the environments that the build is propagated through by using pipelines with manual gates.

+ +
+Pipeline with Environments +Click image to zoom in +
+ +

To see how we came up with this deployment pipeline diagram, see this earlier post.

+ +

Types of Manual Gates

+ +

There are three manual gates (or manual stages) shown as little red boxes in this image. The one between the two stages of the “UAT” pipeline is often used as a pass/fail gate. This is to help control which builds go to “Test” stage. In this case, if the testing is manual and someone needs to approve a “build”, this kind of a gate is useful. The “Test” stage can also just be a dummy stage. If the deployed build is deemed to be a failure, no one approves it and the “Test” stage for that pipeline never gets run. So, that build never shows up as a candidate for the “Pre_Prod” environment.

+ +

The second and the third gates shown are before the first stage of both the “Pre_Prod” and “Production” pipelines. When the first stage of a pipeline is marked manual, the whole pipeline is also called a “manual pipeline”. In this case, you don't want the pipeline to automatically trigger when one of its dependencies finishes successfully. Instead, you want to have the ability to select the upstream dependencies of the pipeline and then trigger it. It’s also quite useful for manual stages to have their own “approvers”. Therefore you can allow only a subset of people to see and approve it. (Note: If you’d like to know how manual stages can be set up in GoCD, read this. You can use the “trigger with options” feature to decide what to run when the first stage is manual). We highly recommend this be used where you need to limit access.

+ +

Build propagation continues to be shown in green and works equally well with manual gates. Even if you take multiple days before you approve a stage, the correct artifact will be fetched from the correct upstream pipeline. Important: Please make sure that the old artifacts are not purged before they’re fetched. When using GoCD, you can choose to never purge artifacts for a stage, so that it is always available for downstream pipelines to use.

+ +

A GoCD pro tip for Manual Pipelines

+ +

When using GoCD, it’s more convenient to have a dummy first stage and a gate after it, instead of making a pipeline’s first stage manual (like the third manual gate shown in the image above). This prevents a user from having to trigger with options and making a mistake in choosing the available upstream dependencies. More importantly, the pipeline history page in GoCD can then be used to see all available builds and choose one to take further. In the configuration, it looks like this:

+ +

Pipeline with Dummy Stage

+ +

In the pipeline history page in GoCD, it will look like this:

+ +
+Pipeline History +Click image to zoom in +
+ +

This approach becomes even more important in a fan-in scenario. Without this (having the first stage be manual), it is more prone to human error - Eg. A user can pick upstream dependencies which are not compatible like using a run of “Upstream_1” pipeline which ran with SVN revision 1 combined with a run of “Upstream_2” pipeline which ran with SVN revision 2. By using the dummy stage approach, fan-in will apply to the pipeline first and an incompatible combination of the two upstream pipelines will not lead to the “Dummy stage” being triggered at all.

+ +

We recommend using this approach to model manual pipelines in GoCD. It not only gives you more control, but also prevents human error in complex pipelines thereby making your deployments safer.

+ +
+ +

So far throughout the series, we have a defined process of taking a set of changes through a set of tests, automated and manual, and based on the result, through a set of environments coming closer and closer to production, with increasing confidence.

+ +

In our next post, we’ll look at “Where does all of this run?” and talk in more detail about workers, or in GoCD terms, GoCD Agents. If you haven’t already, we recommend you to have your GoCD server setup to better follow our upcoming posts.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/23/control-deployments-manual-approvals/index.html b/pr-1714/2017/05/23/control-deployments-manual-approvals/index.html new file mode 100644 index 000000000..5f683c39d --- /dev/null +++ b/pr-1714/2017/05/23/control-deployments-manual-approvals/index.html @@ -0,0 +1,260 @@ + + + + + + + + + + + + + + + + Control deployments using Manual Gates | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 5 - Control deployments using Manual Gates: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 5 - Modeling Deployment Pipelines: Control deployments using Manual Gates

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the fifth post in the series - Modeling Deployment Pipelines. In our previous post, we talked about how using Fan-in/Fan-out helps build propagation. In this post, we will show you how to use a manual approval process to propagate your build which is especially useful for critical deployments.

+ +

The Importance of Manual Approvals

+ +

To deploy into environments such as production, and pre-production, it’s often important to have a manual approval process. This way, you can also make sure that your deployment happens only when you're ready for it (be it in terms of the time of the day, or in terms of other dependencies you need to wait for). We refer to this approval process as a “gate” since it works as one to control the build propagation by either stopping or allowing the build to go through. (Note: Manual gates are supported by GoCD, out of the box, by marking a stage as manual). Here’s an image which shows the environments that the build is propagated through by using pipelines with manual gates.

+ +
+Pipeline with Environments +Click image to zoom in +
+ +

To see how we came up with this deployment pipeline diagram, see this earlier post.

+ +

Types of Manual Gates

+ +

There are three manual gates (or manual stages) shown as little red boxes in this image. The one between the two stages of the “UAT” pipeline is often used as a pass/fail gate. This is to help control which builds go to “Test” stage. In this case, if the testing is manual and someone needs to approve a “build”, this kind of a gate is useful. The “Test” stage can also just be a dummy stage. If the deployed build is deemed to be a failure, no one approves it and the “Test” stage for that pipeline never gets run. So, that build never shows up as a candidate for the “Pre_Prod” environment.

+ +

The second and the third gates shown are before the first stage of both the “Pre_Prod” and “Production” pipelines. When the first stage of a pipeline is marked manual, the whole pipeline is also called a “manual pipeline”. In this case, you don't want the pipeline to automatically trigger when one of its dependencies finishes successfully. Instead, you want to have the ability to select the upstream dependencies of the pipeline and then trigger it. It’s also quite useful for manual stages to have their own “approvers”. Therefore you can allow only a subset of people to see and approve it. (Note: If you’d like to know how manual stages can be set up in GoCD, read this. You can use the “trigger with options” feature to decide what to run when the first stage is manual). We highly recommend this be used where you need to limit access.

+ +

Build propagation continues to be shown in green and works equally well with manual gates. Even if you take multiple days before you approve a stage, the correct artifact will be fetched from the correct upstream pipeline. Important: Please make sure that the old artifacts are not purged before they’re fetched. When using GoCD, you can choose to never purge artifacts for a stage, so that it is always available for downstream pipelines to use.

+ +

A GoCD pro tip for Manual Pipelines

+ +

When using GoCD, it’s more convenient to have a dummy first stage and a gate after it, instead of making a pipeline’s first stage manual (like the third manual gate shown in the image above). This prevents a user from having to trigger with options and making a mistake in choosing the available upstream dependencies. More importantly, the pipeline history page in GoCD can then be used to see all available builds and choose one to take further. In the configuration, it looks like this:

+ +

Pipeline with Dummy Stage

+ +

In the pipeline history page in GoCD, it will look like this:

+ +
+Pipeline History +Click image to zoom in +
+ +

This approach becomes even more important in a fan-in scenario. Without this (having the first stage be manual), it is more prone to human error - Eg. A user can pick upstream dependencies which are not compatible like using a run of “Upstream_1” pipeline which ran with SVN revision 1 combined with a run of “Upstream_2” pipeline which ran with SVN revision 2. By using the dummy stage approach, fan-in will apply to the pipeline first and an incompatible combination of the two upstream pipelines will not lead to the “Dummy stage” being triggered at all.

+ +

We recommend using this approach to model manual pipelines in GoCD. It not only gives you more control, but also prevents human error in complex pipelines thereby making your deployments safer.

+ +
+ +

So far throughout the series, we have a defined process of taking a set of changes through a set of tests, automated and manual, and based on the result, through a set of environments coming closer and closer to production, with increasing confidence.

+ +

In our next post, we’ll look at “Where does all of this run?” and talk in more detail about workers, or in GoCD terms, GoCD Agents. If you haven’t already, we recommend you to have your GoCD server setup to better follow our upcoming posts.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/23/index.html b/pr-1714/2017/05/23/index.html new file mode 100644 index 000000000..003a8a645 --- /dev/null +++ b/pr-1714/2017/05/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 23 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/05/index.html b/pr-1714/2017/05/index.html new file mode 100644 index 000000000..38c824598 --- /dev/null +++ b/pr-1714/2017/05/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06.html b/pr-1714/2017/06.html new file mode 100644 index 000000000..7037eb66d --- /dev/null +++ b/pr-1714/2017/06.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/01.html b/pr-1714/2017/06/01.html new file mode 100644 index 000000000..33926e46f --- /dev/null +++ b/pr-1714/2017/06/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/01/forever-home.html b/pr-1714/2017/06/01/forever-home.html new file mode 100644 index 000000000..458d6de45 --- /dev/null +++ b/pr-1714/2017/06/01/forever-home.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + + + + + We've found our forever home | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD has a new home +
+ +
+ + +
+

We've found our forever home

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

We’re overjoyed to announce that GoCD has found home at www.gocd.org!

+ +

Why did we move again?

+ +

During the holiday season last year, we made the decision to switch our main domain from go.cd to gocd.io, due to an issue with the DNS registrar. While this wasn’t ideal, we had to make a quick decision based on our available choices at that point. And so, we went ahead with switching to gocd.io even though it wasn’t ideal for us. Since then, we’d been searching for a more permanent home for GoCD.

+ +

This is from our post in January 2017.

+ +

Will GoCD.io be permanent

+ +

Do I need to change anything?

+ +

No. Redirects will be set up to point to the new domain, and should not impact anything. However, we strongly encourage any third party apps or sites to use gocd.org going forward.

+ +
+

All links to any of our domains will continue to work and redirect you to gocd.org.

+
+ +

Will this now be GoCD’s forever home?

+ +

Yes! We are here to stay.

+ +

Thank you for supporting GoCD!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/01/forever-home/index.html b/pr-1714/2017/06/01/forever-home/index.html new file mode 100644 index 000000000..556b8bc00 --- /dev/null +++ b/pr-1714/2017/06/01/forever-home/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + + + + + We've found our forever home | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD has a new home +
+ +
+ + +
+

We've found our forever home

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

We’re overjoyed to announce that GoCD has found home at www.gocd.org!

+ +

Why did we move again?

+ +

During the holiday season last year, we made the decision to switch our main domain from go.cd to gocd.io, due to an issue with the DNS registrar. While this wasn’t ideal, we had to make a quick decision based on our available choices at that point. And so, we went ahead with switching to gocd.io even though it wasn’t ideal for us. Since then, we’d been searching for a more permanent home for GoCD.

+ +

This is from our post in January 2017.

+ +

Will GoCD.io be permanent

+ +

Do I need to change anything?

+ +

No. Redirects will be set up to point to the new domain, and should not impact anything. However, we strongly encourage any third party apps or sites to use gocd.org going forward.

+ +
+

All links to any of our domains will continue to work and redirect you to gocd.org.

+
+ +

Will this now be GoCD’s forever home?

+ +

Yes! We are here to stay.

+ +

Thank you for supporting GoCD!

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/01/index.html b/pr-1714/2017/06/01/index.html new file mode 100644 index 000000000..97bcaca4f --- /dev/null +++ b/pr-1714/2017/06/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/13.html b/pr-1714/2017/06/13.html new file mode 100644 index 000000000..10b6d2c35 --- /dev/null +++ b/pr-1714/2017/06/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/13/index.html b/pr-1714/2017/06/13/index.html new file mode 100644 index 000000000..3c22149ea --- /dev/null +++ b/pr-1714/2017/06/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments.html b/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments.html new file mode 100644 index 000000000..a787758d7 --- /dev/null +++ b/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments.html @@ -0,0 +1,244 @@ + + + + + + + + + + + + + + + + Under the hood of Deployment Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 6 - Under the hood of Deployment Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 6 - Modeling Deployment Pipelines: Under the hood of Deployment Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the sixth post in the series, Modeling Deployment Pipelines. In our last post we looked at how having manual approvals or gates through the pipeline can give you more control over your deployments. So now, we have a defined process of taking a set of changes through a series of tests (automated and manual) and based on the results, through multiple environments coming closer to “production”. In this post, we are going to look at where all these elements of your deployment pipeline actually run.

+ +

Where do the Deployment Pipelines run?

+ +

In GoCD almost no part of the deployment process runs on the GoCD server (which mainly waits for changes in repositories). What really powers the deployment pipeline are the GoCD agents. So, the question becomes: Where do the Agents themselves run? Does one need to install GoCD agents on the production box to deploy to production? The answer is, “It depends on what you’re comfortable with”.

+ +

If your reaction to installing GoCD agents into production is "Sure, makes sense!", then, it’s fairly straightforward. You can run a GoCD agent on every node you want to deploy to or run anything in. Using resources and possibly GoCD environments (which we will talk about in a moment), you can make sure that only the jobs that need to run on a specific agent (designated “production agents”, for instance) are run there. This is to make sure that something like a functional test job does not end up running in your production GoCD agent.

+ +

In the more common scenario where your reaction to running a GoCD agent on production is "OMG! No way. That’s not going to happen!”, then that’s fine too. We understand that there are situations where access to production is tightly controlled and running a GoCD agent in production can be frowned upon. In such cases, you can still designate some agents as “production agents”, but their job will be to use some kind of a remoting mechanism such as OpenSSH to connect to the real production boxes and run a deployment in a controlled fashion. You’ll need to manage SSH keys etc. so that this is possible to be run without any intervention. Since GoCD agents execute commands for the most part, they don’t care what you do. As long as your tasks and jobs are setup properly to execute that part of your process using ssh, everything should work fine.

+ +

Group Pipelines and Agents with Environments

+ +

As we’ve seen above, in case of designated “production agents”, we need a way to group and isolate pipelines and agents. This is where GoCD environments come in. We could put our UAT and pre-prod pipelines and some of their agents into a “PreProd” environment and do something similar for the “Production” pipeline and its agents. A representation of this can be as shown below:

+ +
+ Pipeline with Agents and Environments + Click image to zoom in +
+ +

In this particular example, there are a set of 6 agents and 4 pipelines (“Build” and three functional test pipelines), which make up the “Development” GoCD environment. Similarly, 4 agents and 2 pipelines make up the “Pre-production” environment. 2 designated agents and the “Production” pipeline make up the “Production” environment. Now that they’re all in their own environments, only the designated agents of that environment will be used to run jobs of pipelines in that environment.

+ +

Dynamically allocate your Agent Machines

+ +

In an ideal world, you’d have unlimited machines to allow you to scale whenever you need. But in reality, your infrastructure resource is never unlimited. Imagine that you have an automated performance test which runs occasionally but needs a lot of machines to run. Rather than having agents dedicated to this (which would be idle when the tests are not running), you want agent machines to be started at the beginning of the performance test, possibly using some cloud service, and then be brought down when not needed. These on-demand agents are called Elastic Agents (supported in GoCD) and can optimize utilization and reduce costs.

+ +
+

Sometimes, despite our best intentions in defining a workable process, an emergency may arise which requires us to bypass this very process or undo a change that was made. The rigidity of your deployment pipeline can be a limitation in these situations. It’s important then to have flexibility in your pipeline. Enter Hotfixes! A hotfix is essentially a pass to go directly into production. Stay tuned for our next post on incorporating roll-backs and modeling a hotfix into your deployment pipeline.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments/index.html b/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments/index.html new file mode 100644 index 000000000..2f849554e --- /dev/null +++ b/pr-1714/2017/06/13/modeling-deployment-pipelines-agents-environments/index.html @@ -0,0 +1,244 @@ + + + + + + + + + + + + + + + + Under the hood of Deployment Pipelines | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 6 - Under the hood of Deployment Pipelines: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 6 - Modeling Deployment Pipelines: Under the hood of Deployment Pipelines

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the sixth post in the series, Modeling Deployment Pipelines. In our last post we looked at how having manual approvals or gates through the pipeline can give you more control over your deployments. So now, we have a defined process of taking a set of changes through a series of tests (automated and manual) and based on the results, through multiple environments coming closer to “production”. In this post, we are going to look at where all these elements of your deployment pipeline actually run.

+ +

Where do the Deployment Pipelines run?

+ +

In GoCD almost no part of the deployment process runs on the GoCD server (which mainly waits for changes in repositories). What really powers the deployment pipeline are the GoCD agents. So, the question becomes: Where do the Agents themselves run? Does one need to install GoCD agents on the production box to deploy to production? The answer is, “It depends on what you’re comfortable with”.

+ +

If your reaction to installing GoCD agents into production is "Sure, makes sense!", then, it’s fairly straightforward. You can run a GoCD agent on every node you want to deploy to or run anything in. Using resources and possibly GoCD environments (which we will talk about in a moment), you can make sure that only the jobs that need to run on a specific agent (designated “production agents”, for instance) are run there. This is to make sure that something like a functional test job does not end up running in your production GoCD agent.

+ +

In the more common scenario where your reaction to running a GoCD agent on production is "OMG! No way. That’s not going to happen!”, then that’s fine too. We understand that there are situations where access to production is tightly controlled and running a GoCD agent in production can be frowned upon. In such cases, you can still designate some agents as “production agents”, but their job will be to use some kind of a remoting mechanism such as OpenSSH to connect to the real production boxes and run a deployment in a controlled fashion. You’ll need to manage SSH keys etc. so that this is possible to be run without any intervention. Since GoCD agents execute commands for the most part, they don’t care what you do. As long as your tasks and jobs are setup properly to execute that part of your process using ssh, everything should work fine.

+ +

Group Pipelines and Agents with Environments

+ +

As we’ve seen above, in case of designated “production agents”, we need a way to group and isolate pipelines and agents. This is where GoCD environments come in. We could put our UAT and pre-prod pipelines and some of their agents into a “PreProd” environment and do something similar for the “Production” pipeline and its agents. A representation of this can be as shown below:

+ +
+ Pipeline with Agents and Environments + Click image to zoom in +
+ +

In this particular example, there are a set of 6 agents and 4 pipelines (“Build” and three functional test pipelines), which make up the “Development” GoCD environment. Similarly, 4 agents and 2 pipelines make up the “Pre-production” environment. 2 designated agents and the “Production” pipeline make up the “Production” environment. Now that they’re all in their own environments, only the designated agents of that environment will be used to run jobs of pipelines in that environment.

+ +

Dynamically allocate your Agent Machines

+ +

In an ideal world, you’d have unlimited machines to allow you to scale whenever you need. But in reality, your infrastructure resource is never unlimited. Imagine that you have an automated performance test which runs occasionally but needs a lot of machines to run. Rather than having agents dedicated to this (which would be idle when the tests are not running), you want agent machines to be started at the beginning of the performance test, possibly using some cloud service, and then be brought down when not needed. These on-demand agents are called Elastic Agents (supported in GoCD) and can optimize utilization and reduce costs.

+ +
+

Sometimes, despite our best intentions in defining a workable process, an emergency may arise which requires us to bypass this very process or undo a change that was made. The rigidity of your deployment pipeline can be a limitation in these situations. It’s important then to have flexibility in your pipeline. Enter Hotfixes! A hotfix is essentially a pass to go directly into production. Stay tuned for our next post on incorporating roll-backs and modeling a hotfix into your deployment pipeline.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/20.html b/pr-1714/2017/06/20.html new file mode 100644 index 000000000..1d99181f6 --- /dev/null +++ b/pr-1714/2017/06/20.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/20/hotfixes-rollback-rollforward.html b/pr-1714/2017/06/20/hotfixes-rollback-rollforward.html new file mode 100644 index 000000000..c745a7b4c --- /dev/null +++ b/pr-1714/2017/06/20/hotfixes-rollback-rollforward.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Preparing for emergency deployments and rollbacks | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 7 - Preparing for emergency deployments and rollbacks: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 7 - Modeling Deployment Pipelines: Preparing for emergency deployments and rollbacks

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the seventh post in the series, Modeling Deployment Pipelines. In our last post we saw how deployment pipelines are powered by Agents and Environments. In this post, we’ll cover ways to make your pipeline more flexible and some techniques to help during an emergency.

+ +

What is a Hotfix

+ +

While it’s best not to rely on them, when used in rare cases hotfixes can be a life-saver. A hotfix is essentially a pass to go directly into production. It can be modeled as shown below:

+ +
+ Pipeline with Hotfix + Click image to zoom in +
+

The red gate in the image above signifies a manual gate.

+ +

What is the best way to model a “Hotfix”?

+ +

The above image is just one of the ways you could model hotfixes. As these are not truly certified builds you’re putting into production, it would be wise to keep these pipelines paused and have strict controls over who can trigger them. Hotfixes can be modeled this way because of the recommendation to move the actual deployment logic into scripts which are checked-in locally. In this case, the “Hotfix” pipeline is almost exactly the same as the “Production” pipeline. The only real change is that it fetches its deployment artifact directly from the “Build installer” stage.

+ +

Rollback or Roll-forward

+ +

A similar approach can be taken for rollbacks. There’s always a question of whether rollbacks are appropriate or whether it should always be a roll-forward. That is not a decision made lightly. It depends on the culture and ability of the team and the maturity of the codebase being worked on.

+ +
+

A quick roll-forward is preferable to a rollback.

+
+ +

If the codebase and the CD pipeline are setup properly with an appropriate set of tests, then the number of times a really bad build goes into production (requiring a rollback) should be extremely small. If you find that you need to roll back too often, it is a sign that you need to stop and take a look at the processes and checks and balances in your CD pipeline and find out what’s missing.

+ +

Having said that, here are some approaches to creating a rollback or roll-forward:

+ +

1. Re-running an old pipeline run

+ +

Depending on the kind of application being deployed, a “rollback” might just be the deployment of an older build. In cases such as a static website or an application without state, this is appropriate.

+ +

2. Having a “roll-forward” pipeline exactly like the “hotfix” pipeline shown above

+ +

If you’re really sure that this will only be used judiciously, a “hotfix” pipeline can double as a “roll-forward” pipeline in a pinch. It’s a risky approach, though. A better approach, if your end-to-end pipeline runs quickly enough, is to make a commit and let it run through the whole pipeline and then deploy a fully tested build. You should probably then go back and do a root cause analysis of how a bad build went into production.

+ +

3. Use a “rollback” stage with a manual gate

+ +

You can have a “rollback” stage at the end of your “production” pipeline, as shown here:

+ +

Pipeline with Rollback

+ +

The advantage here is that you can see exactly which version has been deployed (in GoCD’s pipeline history page) and you can run the “Rollback” stage for that version. You could set it up so that that “Rollback” stage just undoes any state change created by the “Deploy” stage of the pipeline. Since the “Rollback” stage is part of the same pipeline, all the environment variables and upstream dependencies used by the “Deploy” stage can be used by the “Rollback” stage too.

+ +
+ +

In summary, a rollback or roll-forward can be orchestrated by the CD tool as a part of the workflow, but the actual process of the rollback or roll-forward is highly specific to the application you’re building. This is why rollback strategies (and even the way to set-up your deployment pipelines) need to be thought out depending on what makes sense for the application and the business, rather than expecting a CD tool to magically provide a solution.

+ +

There are many more concepts to explore in modeling deployment pipelines like implementing feature toggles, performance tests, microservices, security tests etc. Let us know what you’d like to hear about in our next post in the comments section below.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/20/hotfixes-rollback-rollforward/index.html b/pr-1714/2017/06/20/hotfixes-rollback-rollforward/index.html new file mode 100644 index 000000000..68a947fe6 --- /dev/null +++ b/pr-1714/2017/06/20/hotfixes-rollback-rollforward/index.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Preparing for emergency deployments and rollbacks | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 7 - Preparing for emergency deployments and rollbacks: Modeling Deployment Pipelines +
+ +
+ + +
+

Part 7 - Modeling Deployment Pipelines: Preparing for emergency deployments and rollbacks

+

Aravind S.V, Product Manager at GoCD

+

+ Modeling Deployment Pipelines +

+
+ +
+ +

This is the seventh post in the series, Modeling Deployment Pipelines. In our last post we saw how deployment pipelines are powered by Agents and Environments. In this post, we’ll cover ways to make your pipeline more flexible and some techniques to help during an emergency.

+ +

What is a Hotfix

+ +

While it’s best not to rely on them, when used in rare cases hotfixes can be a life-saver. A hotfix is essentially a pass to go directly into production. It can be modeled as shown below:

+ +
+ Pipeline with Hotfix + Click image to zoom in +
+

The red gate in the image above signifies a manual gate.

+ +

What is the best way to model a “Hotfix”?

+ +

The above image is just one of the ways you could model hotfixes. As these are not truly certified builds you’re putting into production, it would be wise to keep these pipelines paused and have strict controls over who can trigger them. Hotfixes can be modeled this way because of the recommendation to move the actual deployment logic into scripts which are checked-in locally. In this case, the “Hotfix” pipeline is almost exactly the same as the “Production” pipeline. The only real change is that it fetches its deployment artifact directly from the “Build installer” stage.

+ +

Rollback or Roll-forward

+ +

A similar approach can be taken for rollbacks. There’s always a question of whether rollbacks are appropriate or whether it should always be a roll-forward. That is not a decision made lightly. It depends on the culture and ability of the team and the maturity of the codebase being worked on.

+ +
+

A quick roll-forward is preferable to a rollback.

+
+ +

If the codebase and the CD pipeline are setup properly with an appropriate set of tests, then the number of times a really bad build goes into production (requiring a rollback) should be extremely small. If you find that you need to roll back too often, it is a sign that you need to stop and take a look at the processes and checks and balances in your CD pipeline and find out what’s missing.

+ +

Having said that, here are some approaches to creating a rollback or roll-forward:

+ +

1. Re-running an old pipeline run

+ +

Depending on the kind of application being deployed, a “rollback” might just be the deployment of an older build. In cases such as a static website or an application without state, this is appropriate.

+ +

2. Having a “roll-forward” pipeline exactly like the “hotfix” pipeline shown above

+ +

If you’re really sure that this will only be used judiciously, a “hotfix” pipeline can double as a “roll-forward” pipeline in a pinch. It’s a risky approach, though. A better approach, if your end-to-end pipeline runs quickly enough, is to make a commit and let it run through the whole pipeline and then deploy a fully tested build. You should probably then go back and do a root cause analysis of how a bad build went into production.

+ +

3. Use a “rollback” stage with a manual gate

+ +

You can have a “rollback” stage at the end of your “production” pipeline, as shown here:

+ +

Pipeline with Rollback

+ +

The advantage here is that you can see exactly which version has been deployed (in GoCD’s pipeline history page) and you can run the “Rollback” stage for that version. You could set it up so that that “Rollback” stage just undoes any state change created by the “Deploy” stage of the pipeline. Since the “Rollback” stage is part of the same pipeline, all the environment variables and upstream dependencies used by the “Deploy” stage can be used by the “Rollback” stage too.

+ +
+ +

In summary, a rollback or roll-forward can be orchestrated by the CD tool as a part of the workflow, but the actual process of the rollback or roll-forward is highly specific to the application you’re building. This is why rollback strategies (and even the way to set-up your deployment pipelines) need to be thought out depending on what makes sense for the application and the business, rather than expecting a CD tool to magically provide a solution.

+ +

There are many more concepts to explore in modeling deployment pipelines like implementing feature toggles, performance tests, microservices, security tests etc. Let us know what you’d like to hear about in our next post in the comments section below.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/20/index.html b/pr-1714/2017/06/20/index.html new file mode 100644 index 000000000..688f2f8ea --- /dev/null +++ b/pr-1714/2017/06/20/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/22.html b/pr-1714/2017/06/22.html new file mode 100644 index 000000000..b41cc9d1e --- /dev/null +++ b/pr-1714/2017/06/22.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic.html b/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic.html new file mode 100644 index 000000000..58ee0b539 --- /dev/null +++ b/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic.html @@ -0,0 +1,235 @@ + + + + + + + + + + + + + + + + Infographic: 5 Key Patterns for your Deployment Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Infographic: 5 Key Patterns for your Deployment Pipeline +
+ +
+ + +
+

Infographic: 5 Key Patterns for your Deployment Pipeline

+

Ken Mugrage

+

+ Infographic +

+
+ +
+ +

Here’s a handy infographic to help you get started on your deployment pipelines.

+ +
+Infographic of deployment pipeline patterns +
+ +

1: Build Things Once

+

Store your build binaries for later use to ensure that you deploy the exact same thing that you’ve tested.

+ +

2: Run tests in parallel

+

Split tests up into manageable chunks, then run them in parallel to speed things up.

+ +

3: Design parallel workflows (a.k.a Fan in/Fan out)

+

Use parallel workflows to create pipeline dependencies and reduce the time it takes to run your pipeline.

+ +

4: Verify on a production-like environment

+

Stage and test on the same environment as your production.

+ +

5: Manage your environments in a pipeline

+

Apply the same rigor reserved for software code on automating your environment configuration.

+ +

If you’d like a more in-depth understanding of the deployment patterns, read our full article.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic/index.html b/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic/index.html new file mode 100644 index 000000000..f77695357 --- /dev/null +++ b/pr-1714/2017/06/22/deployment-pipeline-patterns-infographic/index.html @@ -0,0 +1,235 @@ + + + + + + + + + + + + + + + + Infographic: 5 Key Patterns for your Deployment Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Infographic: 5 Key Patterns for your Deployment Pipeline +
+ +
+ + +
+

Infographic: 5 Key Patterns for your Deployment Pipeline

+

Ken Mugrage

+

+ Infographic +

+
+ +
+ +

Here’s a handy infographic to help you get started on your deployment pipelines.

+ +
+Infographic of deployment pipeline patterns +
+ +

1: Build Things Once

+

Store your build binaries for later use to ensure that you deploy the exact same thing that you’ve tested.

+ +

2: Run tests in parallel

+

Split tests up into manageable chunks, then run them in parallel to speed things up.

+ +

3: Design parallel workflows (a.k.a Fan in/Fan out)

+

Use parallel workflows to create pipeline dependencies and reduce the time it takes to run your pipeline.

+ +

4: Verify on a production-like environment

+

Stage and test on the same environment as your production.

+ +

5: Manage your environments in a pipeline

+

Apply the same rigor reserved for software code on automating your environment configuration.

+ +

If you’d like a more in-depth understanding of the deployment patterns, read our full article.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/22/index.html b/pr-1714/2017/06/22/index.html new file mode 100644 index 000000000..cf30e1664 --- /dev/null +++ b/pr-1714/2017/06/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/26.html b/pr-1714/2017/06/26.html new file mode 100644 index 000000000..040961ac0 --- /dev/null +++ b/pr-1714/2017/06/26.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/26/index.html b/pr-1714/2017/06/26/index.html new file mode 100644 index 000000000..eadb14e00 --- /dev/null +++ b/pr-1714/2017/06/26/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/26/serverless-architecture-continuous-delivery.html b/pr-1714/2017/06/26/serverless-architecture-continuous-delivery.html new file mode 100644 index 000000000..cc3dc1c71 --- /dev/null +++ b/pr-1714/2017/06/26/serverless-architecture-continuous-delivery.html @@ -0,0 +1,294 @@ + + + + + + + + + + + + + + + + Serverless Architectures and Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Serverless Architectures and Continuous Delivery +
+ +
+ + +
+

Serverless Architectures and Continuous Delivery

+

Robin Weston

+

+

+
+ +
+ +

At PipelineConf this year, I spoke about my experiences with serverless architectures and how they play well with the patterns and practices of continuous delivery. This post explains what a serverless architecture is, their benefits and how they can enable continuous delivery.

+ +

What is serverless?

+ +
+Traditional vs Serverless +
+ +

We're in buzzword bingo land here so it's important that we start with a common definition of what serverless is:

+ +
+

Serverless architectures are internet-based systems where the application development does not use the usual server process. Instead, they rely solely on a combination of third-party services, client-side logic and service-hosted remote procedure calls (Functions as a Service).

+
+ +

“Not the usual server process” means that your software isn't running on a server that you have access to. You don't own those servers. You can't log in to them, even if you wanted to. +They are abstracted away and managed for you by someone else, typically a cloud provider.

+ +

There are many immediate benefits to not managing your own servers:

+ +
    +
  • You don't have to worry about them randomly rebooting or going down.
    • +
  • You don't end up with snowflake servers, where you don't know quite what's installed on them but they are mission-critical to your organisation.
    • +
  • You're not responsible for installing software on them. Even if you use configuration management tools such as Chef or Ansible to automate this, that’s still extra code you have to maintain over time.
    • +
+ +

By “third-party services”, I mean hosted databases like an AWS Elasticsearch cluster or Microsoft SQL Azure, or authentication services like Auth0 or AWS Cognito. You’re essentially outsourcing capabilities to specialised providers.

+ +

Client-side logic typically refers to rich client applications such as single-page web apps or native mobile apps.

+ +

Functions as a service

+ +

Let’s take a deeper look at Functions as a Service (FaaS) since they are newer, have significant differences to how we typically think about technical architecture, and have been driving a lot of the recent serverless hype.

+ +

Functions as a Service have six key properties:

+ +

Independent, server-side, logical functions

+ +

FaaS are much like the functions you’re used to writing in conventional programming languages; small, separate, units of logic that take input arguments, process them in some manner, then return the result.

+ +

Stateless

+ +

As you're not in control of the underlying server infrastructure, you can’t save a file to disk on one run of your function and expect it to be there the next. Any two invocations of the same function could potentially run on completely different servers under the hood.

+ +

Ephemeral

+ +

FaaS are designed to spin up quickly, do their work and then shut down again.

+ +

Event-triggered

+ +

Although functions can be invoked directly, they are typically triggered by events from other cloud services, such as incoming HTTP requests, new database data or inbound message notifications. FaaS are often used and thought of as the glue between services in a cloud environment.

+ +

Scalable by default

+ +

This takes advantage of the FaaS properties mentioned above, allowing as many functions to be run (in parallel, if necessary) as needed to continually service all incoming event triggers.

+ +

Fully managed by a third party

+ +

Examples are AWS Lambda, Azure Functions, Auth0 Webtasks or Google Cloud Functions. Each offering typically supports a range of languages and runtimes e.g. Node.js, .NET Core, Java.

+ +

Four key ways that Serverless Architectures enable Continuous Delivery

+ +

1. Naturally small deployable units

+ +

You really can't get a smaller unit of functionality than a function, and this forces you to think small from the outset. In Continuous Delivery we want to be deploying the smallest thing that adds value to our business. When you have all these small, granular functions that can be deployed independently, you can start to ask interesting questions such as “Do we need to deploy more than one at a time?”, “Could we just deploy that one function?”, “Does that deliver value on it's own?”.

+ +

2. Simple deployment model

+ +

Thanks to the small size of deployment artifacts, in general, deployments are simple and quick. Deployment artifacts are typically idiomatic of the chosen runtime e.g. NuGet packages, npm packages, JAR files. This, coupled with the growth of open source FaaS tooling (such as the Serverless Application Framework and ClaudiaJS), make it simple to build an artifact and move it through a continuous delivery pipeline to production.

+ +

3. No more “works on my machine”

+ +

As you will recall, FaaS are fully managed by a third party. This means that in many cases you cannot test your application in the same way as a traditional application. What I have found useful is for each developer to have their own cloud-hosted sandbox. Developers will run a script that will deploy their functions and associated services (e.g. HTTP API endpoints) to that sandbox, then execute tests against the deployed system in situ. You might think, "oh, the feedback loop is going to be slow" but as deployments of FaaS are so quick this usually doesn’t cause too many problems.

+ +

And the fact that you can’t run tests locally forces you to push testing closer to production. Every time developers deploy to their local sandboxes, they are exercising the same deployment scripts that run as part of their main deployment pipeline. Therefore, you are getting continuous feedback on the effectiveness of your pipeline steps.

+ +

This production-like testing cycle, coupled with a greater focus on monitoring and operability, gives you much greater confidence in the quality of your system, and removes a lot of barriers that can typically be found on the path to continuous delivery.

+ +

4. Serverless enables focus on business value

+ +

It's always worth remembering that our goal as software engineers is not to continuously deliver code to production, but to instead continuously deliver working software that provides value to our users. Serverless architectures really allow you to focus on your core competencies, while offloading capabilities you don't want to care about.

+ +

For example, to implement log shipping and aggregation for a system, your team could spend a number of weeks developing and deploying a custom solution to managed servers (whether on premise or in the cloud). Even by choosing mature products, e.g. Splunk or the ELK stack, and implementing good practices such as Infrastructure as Code, you will suffer an initial implementation cost (in both time and money) as well as an ongoing penalty in terms of maintenance and operability. Alternatively, if your system was built using AWS Lambda and the Node.js runtime, then a simple console.log statement will send your logs to AWS Cloudwatch and store them for up to 15 months. This gets you a long way towards a sustainable solution for a much reduced set of upfront and ongoing costs.

+ +

This reasoning can be applied to many other examples. The key point here is that by using serverless architectures, you can get a lot of functionality “out of the box”. This allows you to focus on work that directly benefits your users and can give you a distinct advantage over your competitors who are having to spread their efforts over a greater technical surface area.

+ +
+ +

This article covered some of the key components of serverless architecture and focussed in particular on Functions as a Service (FaaS). We examined that serverless architectures can be great enablers of Continuous Delivery by combining a focus on value with small, quick-to-deploy, independent units of functionality. While of course there are downsides (which we have deliberately avoided discussing here), implementing a serverless architecture helps support these fundamentals of Continuous Delivery, and could well be a game changer for you and your business.

+ +

Robin Weston is a Lead Consultant at Thoughtworks. Robin has worked in technology for over 10 years and has been at Thoughtworks since 2014. He cares passionately about helping deliver value to clients through simple, effective software.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/26/serverless-architecture-continuous-delivery/index.html b/pr-1714/2017/06/26/serverless-architecture-continuous-delivery/index.html new file mode 100644 index 000000000..b77e6cda6 --- /dev/null +++ b/pr-1714/2017/06/26/serverless-architecture-continuous-delivery/index.html @@ -0,0 +1,294 @@ + + + + + + + + + + + + + + + + Serverless Architectures and Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Serverless Architectures and Continuous Delivery +
+ +
+ + +
+

Serverless Architectures and Continuous Delivery

+

Robin Weston

+

+

+
+ +
+ +

At PipelineConf this year, I spoke about my experiences with serverless architectures and how they play well with the patterns and practices of continuous delivery. This post explains what a serverless architecture is, their benefits and how they can enable continuous delivery.

+ +

What is serverless?

+ +
+Traditional vs Serverless +
+ +

We're in buzzword bingo land here so it's important that we start with a common definition of what serverless is:

+ +
+

Serverless architectures are internet-based systems where the application development does not use the usual server process. Instead, they rely solely on a combination of third-party services, client-side logic and service-hosted remote procedure calls (Functions as a Service).

+
+ +

“Not the usual server process” means that your software isn't running on a server that you have access to. You don't own those servers. You can't log in to them, even if you wanted to. +They are abstracted away and managed for you by someone else, typically a cloud provider.

+ +

There are many immediate benefits to not managing your own servers:

+ +
    +
  • You don't have to worry about them randomly rebooting or going down.
    • +
  • You don't end up with snowflake servers, where you don't know quite what's installed on them but they are mission-critical to your organisation.
    • +
  • You're not responsible for installing software on them. Even if you use configuration management tools such as Chef or Ansible to automate this, that’s still extra code you have to maintain over time.
    • +
+ +

By “third-party services”, I mean hosted databases like an AWS Elasticsearch cluster or Microsoft SQL Azure, or authentication services like Auth0 or AWS Cognito. You’re essentially outsourcing capabilities to specialised providers.

+ +

Client-side logic typically refers to rich client applications such as single-page web apps or native mobile apps.

+ +

Functions as a service

+ +

Let’s take a deeper look at Functions as a Service (FaaS) since they are newer, have significant differences to how we typically think about technical architecture, and have been driving a lot of the recent serverless hype.

+ +

Functions as a Service have six key properties:

+ +

Independent, server-side, logical functions

+ +

FaaS are much like the functions you’re used to writing in conventional programming languages; small, separate, units of logic that take input arguments, process them in some manner, then return the result.

+ +

Stateless

+ +

As you're not in control of the underlying server infrastructure, you can’t save a file to disk on one run of your function and expect it to be there the next. Any two invocations of the same function could potentially run on completely different servers under the hood.

+ +

Ephemeral

+ +

FaaS are designed to spin up quickly, do their work and then shut down again.

+ +

Event-triggered

+ +

Although functions can be invoked directly, they are typically triggered by events from other cloud services, such as incoming HTTP requests, new database data or inbound message notifications. FaaS are often used and thought of as the glue between services in a cloud environment.

+ +

Scalable by default

+ +

This takes advantage of the FaaS properties mentioned above, allowing as many functions to be run (in parallel, if necessary) as needed to continually service all incoming event triggers.

+ +

Fully managed by a third party

+ +

Examples are AWS Lambda, Azure Functions, Auth0 Webtasks or Google Cloud Functions. Each offering typically supports a range of languages and runtimes e.g. Node.js, .NET Core, Java.

+ +

Four key ways that Serverless Architectures enable Continuous Delivery

+ +

1. Naturally small deployable units

+ +

You really can't get a smaller unit of functionality than a function, and this forces you to think small from the outset. In Continuous Delivery we want to be deploying the smallest thing that adds value to our business. When you have all these small, granular functions that can be deployed independently, you can start to ask interesting questions such as “Do we need to deploy more than one at a time?”, “Could we just deploy that one function?”, “Does that deliver value on it's own?”.

+ +

2. Simple deployment model

+ +

Thanks to the small size of deployment artifacts, in general, deployments are simple and quick. Deployment artifacts are typically idiomatic of the chosen runtime e.g. NuGet packages, npm packages, JAR files. This, coupled with the growth of open source FaaS tooling (such as the Serverless Application Framework and ClaudiaJS), make it simple to build an artifact and move it through a continuous delivery pipeline to production.

+ +

3. No more “works on my machine”

+ +

As you will recall, FaaS are fully managed by a third party. This means that in many cases you cannot test your application in the same way as a traditional application. What I have found useful is for each developer to have their own cloud-hosted sandbox. Developers will run a script that will deploy their functions and associated services (e.g. HTTP API endpoints) to that sandbox, then execute tests against the deployed system in situ. You might think, "oh, the feedback loop is going to be slow" but as deployments of FaaS are so quick this usually doesn’t cause too many problems.

+ +

And the fact that you can’t run tests locally forces you to push testing closer to production. Every time developers deploy to their local sandboxes, they are exercising the same deployment scripts that run as part of their main deployment pipeline. Therefore, you are getting continuous feedback on the effectiveness of your pipeline steps.

+ +

This production-like testing cycle, coupled with a greater focus on monitoring and operability, gives you much greater confidence in the quality of your system, and removes a lot of barriers that can typically be found on the path to continuous delivery.

+ +

4. Serverless enables focus on business value

+ +

It's always worth remembering that our goal as software engineers is not to continuously deliver code to production, but to instead continuously deliver working software that provides value to our users. Serverless architectures really allow you to focus on your core competencies, while offloading capabilities you don't want to care about.

+ +

For example, to implement log shipping and aggregation for a system, your team could spend a number of weeks developing and deploying a custom solution to managed servers (whether on premise or in the cloud). Even by choosing mature products, e.g. Splunk or the ELK stack, and implementing good practices such as Infrastructure as Code, you will suffer an initial implementation cost (in both time and money) as well as an ongoing penalty in terms of maintenance and operability. Alternatively, if your system was built using AWS Lambda and the Node.js runtime, then a simple console.log statement will send your logs to AWS Cloudwatch and store them for up to 15 months. This gets you a long way towards a sustainable solution for a much reduced set of upfront and ongoing costs.

+ +

This reasoning can be applied to many other examples. The key point here is that by using serverless architectures, you can get a lot of functionality “out of the box”. This allows you to focus on work that directly benefits your users and can give you a distinct advantage over your competitors who are having to spread their efforts over a greater technical surface area.

+ +
+ +

This article covered some of the key components of serverless architecture and focussed in particular on Functions as a Service (FaaS). We examined that serverless architectures can be great enablers of Continuous Delivery by combining a focus on value with small, quick-to-deploy, independent units of functionality. While of course there are downsides (which we have deliberately avoided discussing here), implementing a serverless architecture helps support these fundamentals of Continuous Delivery, and could well be a game changer for you and your business.

+ +

Robin Weston is a Lead Consultant at Thoughtworks. Robin has worked in technology for over 10 years and has been at Thoughtworks since 2014. He cares passionately about helping deliver value to clients through simple, effective software.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/06/index.html b/pr-1714/2017/06/index.html new file mode 100644 index 000000000..f5c0acd97 --- /dev/null +++ b/pr-1714/2017/06/index.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07.html b/pr-1714/2017/07.html new file mode 100644 index 000000000..dd8055bcb --- /dev/null +++ b/pr-1714/2017/07.html @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/05.html b/pr-1714/2017/07/05.html new file mode 100644 index 000000000..04ec03d01 --- /dev/null +++ b/pr-1714/2017/07/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/05/index.html b/pr-1714/2017/07/05/index.html new file mode 100644 index 000000000..32f82cdf8 --- /dev/null +++ b/pr-1714/2017/07/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/05/product-manager-guide-continuous-delivery.html b/pr-1714/2017/07/05/product-manager-guide-continuous-delivery.html new file mode 100644 index 000000000..74b999f8d --- /dev/null +++ b/pr-1714/2017/07/05/product-manager-guide-continuous-delivery.html @@ -0,0 +1,359 @@ + + + + + + + + + + + + + + + + The Product Managers’ Guide to Continuous Delivery and DevOps | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ The Product Managers’ Guide to Continuous Delivery and DevOps +
+ +
+ + +
+

The Product Managers’ Guide to Continuous Delivery and DevOps

+

Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

A beginner's guide to Continuous Delivery

+ +

This guide is for you if,

+ +
    +
  • You’re in tech, you’re a product manager or an MBA. Your team A/B tests, feature toggles, and you have a dog in the office! Of course you understand what feature branches are, what CD is and what a DevOps culture looks like. Right? Uh … sure.
    • +
  • You’ve gone Agile. Engineering teams now meet with your product people every week to discuss stories and iterations. They collaborate well and what they’re building feels better than ever. But your customers still don’t get those features any faster. You still have to wait for the release train to leave the station. You’ve heard about companies like Etsy, Flickr and Google who deliver a 100 times a day. How do they do it?
    • +
  • Your development team wants to “do CD”. You’ve heard some good things but you’re also concerned about changes going to production without them being properly tested or not being able to market the changes properly. What is this CD thing?
    • +
+ +

I am here to demystify these practices, tell you just how important they are to you “on the business side” and help you get involved. It’s not that complicated, we have pictures and everything.

+ +

Let’s start with some definitions and examples

+ +

Continuous Integration (CI)

+ +

In traditional software development the process of integration generally took place at the end of a project after each person had completed their work. Integration generally took weeks or months and could be very painful. Continuous integration is a practice that puts the integration phase earlier in the development cycle so that building, testing and integrating code happens on a more regular basis.

+ +

CI means that one developer (hi Steve!) who writes code on his laptop at home, and another dev (hey Annie!) who codes on her desktop in the office can both write software for the same product separately, integrate their changes together in a place called the source repository. They can then build the combined software from the bits they each wrote and test that it works the way they expect.

+ +

Developers generally use a tool called the CI Server to do the building and the integration for them. CI requires that Steve and Annie have self-testing code. This is code that tests itself to ensure that it is working as expected, and these tests are often called unit tests. When all the unit tests pass after the code is integrated Steve and Annie will get a green build. This indicates that they have verified that their changes are successfully integrated together, and the code is working as expected by the tests. However, while the integrated code is successfully working together, it not yet ready for production because it has not been tested and verified as working in production-like environments. You can read more about what happens after CI in the Continuous Delivery section below.

+ +
+GoCD Continuous Integration +
+ +

To be considered to be practicing CI, Steve and Annie must check-in to the main source repository, integrate and test their code frequently and often. Usually many times an hour, but at a minimum once a day.

+ +

The benefit of CI is that integration becomes a non-event. Software is written and integrated all the time. Before CI, integration happened at the end of the creation process, all at once, and took an unknown amount of time; now with CI, it happens everyday, takes minutes and is just “the way we work”.

+ +

It’s most likely the your team is doing CI (or at least they believe they are). You can confirm by asking them whether they integrated code once a day :) CI is the first practice that is required to do Continuous Delivery. In fact, if you’ve ever checked in help text, documentation or images, then you may have been continuously integrating!

+ +

Continuous Delivery (CD)

+ +

Let’s go back to our two developers, Steve and Annie. Continuous Delivery means that each time Steve or Annie makes changes to the code, integrates and builds the code, that they also automatically test this code on environments that are very similar to production. We call this progression of deploying to – and testing on – different environments a deployment pipeline. Often the deployment pipeline has a development environment, a test environment, and a staging environment, but these stages vary by the team, product and organization. For example, our Mingle team has a stage called “Cupcake” which is a staging environment, and Etsy’s staging environment is called “Princess”.

+ +
+GoCD Continuous Delivery +
+ +

In each different environment, the code that Annie or Steve wrote is tested differently. This gives more and more confidence to them, and to you, that the code will work on the production environment when the code is deployed there. Crucially, the code is only promoted to (tested on) the next environment in the deployment pipeline if it passes the tests of the previous environment. This way Annie and Steve get new feedback from the tests in each environment and, if there is a failure, they can understand more easily where the issue might be and get it fixed before the code gets to the production environment.

+ +

Continuously Learning

+ +

This process is very empowering for those of us in the business. It means that if Annie’s tests pass on all the environments, you know that her code is likely to be work as intended when it gets to production. Once the tests pass in all environments, you get to decide whether your end users get it or not, right away. Do we want this green build in production now? Yes! And with that, new, fully tested, working software is readily available for customers as soon as your developers finished building it. Woot!

+ +

Continuous Deployment

+ +

This is a practice where every change that Steve or Annie makes, and which passes all the test stages, automatically goes to production. Tim Fitz has a great explanation of it as it was first coined. Some companies do this and others do not. To achieve continuous deployment you first need to get to continuous delivery, so it’s not a priority to decide which is better for you until you’ve starting practicing CD. Either way, I’m of the opinion that continuous delivery is about empowering the business as a whole, and so at the very least you should be involved in deciding if you should use continuous deployment or not. After all, if you’re reading this then you’re probably on the “business side”.

+ +
+GoCD Continuous Deployment +
+ +

DevOps

+ +

The word ‘DevOps’ comes from the combination of the words ‘development’ and ‘operations’. DevOps is a culture that promotes collaboration between developers (hey Steve and Annie, you’re back) and other technology professionals, often called operations or just ops (high-five ops star Joey!). Specifically, communication and collaboration during the software delivery and deployment process, with the goal of releasing better quality software more quickly and more reliably.

+ +

Common traits of organizations who have a so-called DevOps culture are: autonomous poly-skilled teams (Steve, Annie and Joey are all on the same team), high levels of test and release automation (a la continuous delivery) and common goals between the poly-skilled members.

+ +
+Before DevOps +
+ +

One way you may see this working in your organizations is that our developer friends Steve and Annie will work with ops people like Joey to deliver software into production, rather than just “hand off” their code to Joey for release when they’re done with it. Likewise Steve, Annie and Joey will all act as part of a common product or service team who will all be responsible for the support and maintenance of the product, rather than support being a solely ops-team responsibility.

+ +

You will also see automation of activities becoming increasingly important to an organization doing CD and DevOps. This is because, in order to achieve the repeatable, regular and successful process of releasing software that we expect from CD and DevOps, organizations must move to an automated process. Manual processes are simply too error prone and inefficient.

+ +
+After DevOps +
+ +

DevOps culture is commonly associated with Continuous Delivery because they both aim to increase collaboration between developers and operations teams, and both use automatic processes to build, test and release software more quickly, frequently and reliably. All things that people like us want.

+ +

What’s Next?

+ +

While development teams often see the most immediate benefits of process improvements, there are lots of benefits of CI, CD and DevOps to the rest of us. Put simply, I believe that organizations practicing CD and embracing a DevOps culture will deliver more valuable, reliable software to their customers, more often. That’s got to be good, right? Especially if you’re on “the business side.”

+ +

Next time I will talk more about why you should care about these concepts. I’ll address the impact it can have on your business and how to get involved. If you have any questions, talk to me in the comments. The whole point of these posts is to empower you and inform you about technical practices that are meant to be business-relevant. Questions are great!

+ +
+ +

Useful Terminology

+ +

Checking in

+ +

The process of pushing local development code changes to the common source repository.

+ +

CI server

+ +

A tool used to build and test source code. The CI server will tell a developer if their latest code builds were successful and if they continue to pass tests.

+ +

Development environment

+ +

Where developers create, integrate, build and test code.

+ +

Deployment pipeline / pipeline

+ +

This is a set of stages that Steve and Annie’s code changes go through before they are done and ready to be delivered to production. Commonly these will be “build”, “unit test”, “functional tests”, “performance test” and “deploy”. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production.

+ +

Green build

+ +

Green is an indication of success. A green version or build is one where it has passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline unless it is “green”. The opposite of a green build is a red build (see below).

+ +

Incremental development

+ +

Not to be confused with iterative development (see below). Incremental development is where a little bit of the product gets built at a time until it is all complete. Pieces are added on in each increment, and those increments may be small or large. You can use CI with incremental development but it can be harder to achieve Continuous Delivery or Continuous Deployment with incremental development, as you must wait until all increments are completed to deliver value. A great illustration of the difference between Incremental and Iterative development is Jeff Paton’s Mona Lisa.

+ +

Integration

+ +

All code that is written by individuals or teams needs to be combined. We call this integration. In continuous integration, we generally mean software from individuals needs to be consolidated on a regular basis. In continuous delivery, we often mean software from different teams is integrated together to create the whole product.

+ +

Iterative development

+ +

Not to be confused with incremental development (see above). Iterative development is where a little bit of the product gets built at a time and is refined until it is complete. The product is built iteratively where the same pieces are reworked each iteration. Change is expected and planned between features in different iterations. You can use CI, Continuous Delivery or Continuous Deployment with iterative development. A great illustration of the difference between incremental and iterative development is Jeff Paton’s Mona Lisa.

+ +

Master/trunk/mainline

+ +

The “master”, “trunk” or “mainline” branch is the main branch of the source repository. Most people do trunk-based development, meaning that they will always integrate their changes to main line. Others do branch-based development when individually developers will have their own branches, or teams will have branches for different features.

+ +

Production environment

+ +

This is the place where software gets deployed or released. Customers using your product or website are most likely using this environment. Also referred to as “in production”, “in prod” or “live”.

+ +

Red build

+ +

Red is an indication of failure. A red version or build is one where it has not passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline if it is “red”. The opposite of a red build is a green build (see above).

+ +

Source repository

+ +

This is where the source code lives. Steve and Annie have their own local version of the code that they are working on (meaning on their own machines), but the source repository will contain all the code after developers check in their changes to it.

+ +

Test automation

+ +

High quality test automation is needed to do continuous integration and continuous delivery. Tests are ways to check that the software will work as expected. Automated tests are tests that are coded and automatically run once code is checked into the common source repositories.

+ +

In the CI world, the unit tests are run each time the software gets integrated and built. If the tests don’t pass, that version of your software is determined as “not working”, “red” or “broken”. In some workplaces “red lights” or sad sounds occur when this happens.

+ +

In the case of a broken build, Steve or Annie (whoever committed the malfunctioning code) need to “fix it”, “make it green” or “get it working”. They can either do this by making a change to the code to fix it, or removing the prior change that broke it.

+ +

Unit tests

+ +

Unit tests are automated tests in code that test low-level, single pieces of code to ensure that they are usable and working as expected. Unit tests are considered a prerequisite for practicing CI and CD.

+ +

Further reading

+ +

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Link

+ +

Martin Fowler’s easy to read guide on CI – Link

+ +

The Phoenix Project: A Novel about IT, DevOps, and helping your business win – Link

+ +
+ +

This article was first published on Mind the Product and the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/05/product-manager-guide-continuous-delivery/index.html b/pr-1714/2017/07/05/product-manager-guide-continuous-delivery/index.html new file mode 100644 index 000000000..c5948b84a --- /dev/null +++ b/pr-1714/2017/07/05/product-manager-guide-continuous-delivery/index.html @@ -0,0 +1,359 @@ + + + + + + + + + + + + + + + + The Product Managers’ Guide to Continuous Delivery and DevOps | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ The Product Managers’ Guide to Continuous Delivery and DevOps +
+ +
+ + +
+

The Product Managers’ Guide to Continuous Delivery and DevOps

+

Suzie Prince (Head of Product), Thoughtworks Products

+

+

+
+ +
+ +

A beginner's guide to Continuous Delivery

+ +

This guide is for you if,

+ +
    +
  • You’re in tech, you’re a product manager or an MBA. Your team A/B tests, feature toggles, and you have a dog in the office! Of course you understand what feature branches are, what CD is and what a DevOps culture looks like. Right? Uh … sure.
    • +
  • You’ve gone Agile. Engineering teams now meet with your product people every week to discuss stories and iterations. They collaborate well and what they’re building feels better than ever. But your customers still don’t get those features any faster. You still have to wait for the release train to leave the station. You’ve heard about companies like Etsy, Flickr and Google who deliver a 100 times a day. How do they do it?
    • +
  • Your development team wants to “do CD”. You’ve heard some good things but you’re also concerned about changes going to production without them being properly tested or not being able to market the changes properly. What is this CD thing?
    • +
+ +

I am here to demystify these practices, tell you just how important they are to you “on the business side” and help you get involved. It’s not that complicated, we have pictures and everything.

+ +

Let’s start with some definitions and examples

+ +

Continuous Integration (CI)

+ +

In traditional software development the process of integration generally took place at the end of a project after each person had completed their work. Integration generally took weeks or months and could be very painful. Continuous integration is a practice that puts the integration phase earlier in the development cycle so that building, testing and integrating code happens on a more regular basis.

+ +

CI means that one developer (hi Steve!) who writes code on his laptop at home, and another dev (hey Annie!) who codes on her desktop in the office can both write software for the same product separately, integrate their changes together in a place called the source repository. They can then build the combined software from the bits they each wrote and test that it works the way they expect.

+ +

Developers generally use a tool called the CI Server to do the building and the integration for them. CI requires that Steve and Annie have self-testing code. This is code that tests itself to ensure that it is working as expected, and these tests are often called unit tests. When all the unit tests pass after the code is integrated Steve and Annie will get a green build. This indicates that they have verified that their changes are successfully integrated together, and the code is working as expected by the tests. However, while the integrated code is successfully working together, it not yet ready for production because it has not been tested and verified as working in production-like environments. You can read more about what happens after CI in the Continuous Delivery section below.

+ +
+GoCD Continuous Integration +
+ +

To be considered to be practicing CI, Steve and Annie must check-in to the main source repository, integrate and test their code frequently and often. Usually many times an hour, but at a minimum once a day.

+ +

The benefit of CI is that integration becomes a non-event. Software is written and integrated all the time. Before CI, integration happened at the end of the creation process, all at once, and took an unknown amount of time; now with CI, it happens everyday, takes minutes and is just “the way we work”.

+ +

It’s most likely the your team is doing CI (or at least they believe they are). You can confirm by asking them whether they integrated code once a day :) CI is the first practice that is required to do Continuous Delivery. In fact, if you’ve ever checked in help text, documentation or images, then you may have been continuously integrating!

+ +

Continuous Delivery (CD)

+ +

Let’s go back to our two developers, Steve and Annie. Continuous Delivery means that each time Steve or Annie makes changes to the code, integrates and builds the code, that they also automatically test this code on environments that are very similar to production. We call this progression of deploying to – and testing on – different environments a deployment pipeline. Often the deployment pipeline has a development environment, a test environment, and a staging environment, but these stages vary by the team, product and organization. For example, our Mingle team has a stage called “Cupcake” which is a staging environment, and Etsy’s staging environment is called “Princess”.

+ +
+GoCD Continuous Delivery +
+ +

In each different environment, the code that Annie or Steve wrote is tested differently. This gives more and more confidence to them, and to you, that the code will work on the production environment when the code is deployed there. Crucially, the code is only promoted to (tested on) the next environment in the deployment pipeline if it passes the tests of the previous environment. This way Annie and Steve get new feedback from the tests in each environment and, if there is a failure, they can understand more easily where the issue might be and get it fixed before the code gets to the production environment.

+ +

Continuously Learning

+ +

This process is very empowering for those of us in the business. It means that if Annie’s tests pass on all the environments, you know that her code is likely to be work as intended when it gets to production. Once the tests pass in all environments, you get to decide whether your end users get it or not, right away. Do we want this green build in production now? Yes! And with that, new, fully tested, working software is readily available for customers as soon as your developers finished building it. Woot!

+ +

Continuous Deployment

+ +

This is a practice where every change that Steve or Annie makes, and which passes all the test stages, automatically goes to production. Tim Fitz has a great explanation of it as it was first coined. Some companies do this and others do not. To achieve continuous deployment you first need to get to continuous delivery, so it’s not a priority to decide which is better for you until you’ve starting practicing CD. Either way, I’m of the opinion that continuous delivery is about empowering the business as a whole, and so at the very least you should be involved in deciding if you should use continuous deployment or not. After all, if you’re reading this then you’re probably on the “business side”.

+ +
+GoCD Continuous Deployment +
+ +

DevOps

+ +

The word ‘DevOps’ comes from the combination of the words ‘development’ and ‘operations’. DevOps is a culture that promotes collaboration between developers (hey Steve and Annie, you’re back) and other technology professionals, often called operations or just ops (high-five ops star Joey!). Specifically, communication and collaboration during the software delivery and deployment process, with the goal of releasing better quality software more quickly and more reliably.

+ +

Common traits of organizations who have a so-called DevOps culture are: autonomous poly-skilled teams (Steve, Annie and Joey are all on the same team), high levels of test and release automation (a la continuous delivery) and common goals between the poly-skilled members.

+ +
+Before DevOps +
+ +

One way you may see this working in your organizations is that our developer friends Steve and Annie will work with ops people like Joey to deliver software into production, rather than just “hand off” their code to Joey for release when they’re done with it. Likewise Steve, Annie and Joey will all act as part of a common product or service team who will all be responsible for the support and maintenance of the product, rather than support being a solely ops-team responsibility.

+ +

You will also see automation of activities becoming increasingly important to an organization doing CD and DevOps. This is because, in order to achieve the repeatable, regular and successful process of releasing software that we expect from CD and DevOps, organizations must move to an automated process. Manual processes are simply too error prone and inefficient.

+ +
+After DevOps +
+ +

DevOps culture is commonly associated with Continuous Delivery because they both aim to increase collaboration between developers and operations teams, and both use automatic processes to build, test and release software more quickly, frequently and reliably. All things that people like us want.

+ +

What’s Next?

+ +

While development teams often see the most immediate benefits of process improvements, there are lots of benefits of CI, CD and DevOps to the rest of us. Put simply, I believe that organizations practicing CD and embracing a DevOps culture will deliver more valuable, reliable software to their customers, more often. That’s got to be good, right? Especially if you’re on “the business side.”

+ +

Next time I will talk more about why you should care about these concepts. I’ll address the impact it can have on your business and how to get involved. If you have any questions, talk to me in the comments. The whole point of these posts is to empower you and inform you about technical practices that are meant to be business-relevant. Questions are great!

+ +
+ +

Useful Terminology

+ +

Checking in

+ +

The process of pushing local development code changes to the common source repository.

+ +

CI server

+ +

A tool used to build and test source code. The CI server will tell a developer if their latest code builds were successful and if they continue to pass tests.

+ +

Development environment

+ +

Where developers create, integrate, build and test code.

+ +

Deployment pipeline / pipeline

+ +

This is a set of stages that Steve and Annie’s code changes go through before they are done and ready to be delivered to production. Commonly these will be “build”, “unit test”, “functional tests”, “performance test” and “deploy”. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production.

+ +

Green build

+ +

Green is an indication of success. A green version or build is one where it has passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline unless it is “green”. The opposite of a green build is a red build (see below).

+ +

Incremental development

+ +

Not to be confused with iterative development (see below). Incremental development is where a little bit of the product gets built at a time until it is all complete. Pieces are added on in each increment, and those increments may be small or large. You can use CI with incremental development but it can be harder to achieve Continuous Delivery or Continuous Deployment with incremental development, as you must wait until all increments are completed to deliver value. A great illustration of the difference between Incremental and Iterative development is Jeff Paton’s Mona Lisa.

+ +

Integration

+ +

All code that is written by individuals or teams needs to be combined. We call this integration. In continuous integration, we generally mean software from individuals needs to be consolidated on a regular basis. In continuous delivery, we often mean software from different teams is integrated together to create the whole product.

+ +

Iterative development

+ +

Not to be confused with incremental development (see above). Iterative development is where a little bit of the product gets built at a time and is refined until it is complete. The product is built iteratively where the same pieces are reworked each iteration. Change is expected and planned between features in different iterations. You can use CI, Continuous Delivery or Continuous Deployment with iterative development. A great illustration of the difference between incremental and iterative development is Jeff Paton’s Mona Lisa.

+ +

Master/trunk/mainline

+ +

The “master”, “trunk” or “mainline” branch is the main branch of the source repository. Most people do trunk-based development, meaning that they will always integrate their changes to main line. Others do branch-based development when individually developers will have their own branches, or teams will have branches for different features.

+ +

Production environment

+ +

This is the place where software gets deployed or released. Customers using your product or website are most likely using this environment. Also referred to as “in production”, “in prod” or “live”.

+ +

Red build

+ +

Red is an indication of failure. A red version or build is one where it has not passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline if it is “red”. The opposite of a red build is a green build (see above).

+ +

Source repository

+ +

This is where the source code lives. Steve and Annie have their own local version of the code that they are working on (meaning on their own machines), but the source repository will contain all the code after developers check in their changes to it.

+ +

Test automation

+ +

High quality test automation is needed to do continuous integration and continuous delivery. Tests are ways to check that the software will work as expected. Automated tests are tests that are coded and automatically run once code is checked into the common source repositories.

+ +

In the CI world, the unit tests are run each time the software gets integrated and built. If the tests don’t pass, that version of your software is determined as “not working”, “red” or “broken”. In some workplaces “red lights” or sad sounds occur when this happens.

+ +

In the case of a broken build, Steve or Annie (whoever committed the malfunctioning code) need to “fix it”, “make it green” or “get it working”. They can either do this by making a change to the code to fix it, or removing the prior change that broke it.

+ +

Unit tests

+ +

Unit tests are automated tests in code that test low-level, single pieces of code to ensure that they are usable and working as expected. Unit tests are considered a prerequisite for practicing CI and CD.

+ +

Further reading

+ +

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Link

+ +

Martin Fowler’s easy to read guide on CI – Link

+ +

The Phoenix Project: A Novel about IT, DevOps, and helping your business win – Link

+ +
+ +

This article was first published on Mind the Product and the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/10.html b/pr-1714/2017/07/10.html new file mode 100644 index 000000000..06edb6a48 --- /dev/null +++ b/pr-1714/2017/07/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/10/gocd-vs-spinnaker.html b/pr-1714/2017/07/10/gocd-vs-spinnaker.html new file mode 100644 index 000000000..97ca81694 --- /dev/null +++ b/pr-1714/2017/07/10/gocd-vs-spinnaker.html @@ -0,0 +1,270 @@ + + + + + + + + + + + + + + + + GoCD vs Spinnaker | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery: GoCD vs Spinnaker +
+ +
+ + +
+

Continuous Delivery: GoCD vs Spinnaker

+

Sheroy Marker (Head of Technology), Thoughtworks Products

+

+

+
+ +
+ +

With Continuous Delivery (CD) adoption on the rise, tools that help teams with CD are becoming popular too. GoCD and Spinnaker are two sought after tools in this space. We are often asked how they compare - “GoCD or Spinnaker?” and the truth is that these tools solve different problems and are not interchangeable. Before we delve further, here’s a quick refresher on Continuous Delivery.

+ +

Continuous Delivery

+ +
+

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way - Jez Humble

+
+ +

Continuous Delivery is an overarching practice that includes Build Automation or Continuous Integration, Test Automation and Deployment Automation. By automating these concerns in a Continuous Delivery pipeline you are enabling your software to be releasable to production at any time. A CD workflow is incomplete if it doesn’t address all of these concerns.

+ +
+Concerns addressed in a CD workflow +
+ +

Continuous Delivery has its roots in the lean principle of value stream mapping to improve the efficiency of software delivery, by identifying and eliminating waste in the process. For organizations looking to introduce efficiency in their release engineering with CD, an understanding of their value stream is crucial. An efficient software release process must model this value stream effectively. A good visualization of the current state goes a long way in finding and removing bottlenecks.

+ +

As Continuous Delivery becomes more popular as a practice, so do some of the tools that enable this practice. GoCD and Spinnaker are two of the popular tools in this space.

+ +

GoCD

+ +

GoCD is a best-of-breed Continuous Delivery tool that allows you to orchestrate complex Continuous Delivery workflows. It was the first Continuous Delivery server to provide built-in abstractions to create CD pipelines, along with value stream visualizations for you to be able to truly take stock of the efficiencies (or lack of) in your release process.

+ +

GoCD provides the flexibility to introduce the levels of parallelism and manual stages that specific workflows may require. The tool allows you to introduce the right mix of controls such as role based access control for critical stages, and leaves the implementation of the steps to the user.

+ +

GoCD does not think of Continuous Integration and Continuous Delivery as disconnected processes. When designing a Continuous Delivery workflow for a non-trivial software system, representing the end to end process, from a developer commit to a production deployment is key.

+ +
+GoCD Value Stream Map +GoCD's Value Stream Map +
+ +

With GoCD, you can define your build, test, and deploy stages in the same pipeline with end to end visualization of the process. The value stream view in GoCD gives you the complete picture of your deployment pipeline including traceability and lineage of artifacts that are currently deployed on environments.

+ +

GoCD is open source and provides a plugin architecture that lets you extend its ecosystem.

+ +

Spinnaker

+ +

Spinnaker is a best-in-class multi-cloud deployment automation tool built at Netflix to handle deployments to large clusters on AWS. Spinnaker does not model the end to end Continuous Delivery workflow. You have to integrate with a Continuous Integration tool like Jenkins to automate the build and test automation stages for your CD workflow.

+ +

Spinnaker provides cloud abstractions such as applications, deployments and clusters out of the box. These abstractions enable you to automate deployments relatively quickly and without the need for much scripting. Though Spinnaker has the concept of pipelines, they are specific to deployments and don’t model a complete Continuous Delivery workflow, from commit to production.

+ +

Spinnaker is prescriptive about deployment patterns with it’s built-in abstractions such as out-of-the-box stage types, immutable images, and deployment strategies. The opinionated nature of the tool is beneficial for teams that are looking for industry standard solutions to some of these deployment concerns and don’t really want to implement these patterns themselves.

+ +
+Spinnaker’s Pipeline View +Spinnaker’s Pipeline View. Image from: https://www.spinnaker.io/guides/tutorials/codelabs/hello-deployment/ +
+ +

Spinnaker is designed to handle deployments to popular cloud environments and allows you to define workflows for these deployments. For large software systems, at scales close to the Netflix service, deployment is in itself a complex problem. When you are releasing software to tens of thousands of nodes, concerns such as automated deployment and rollback strategies become key. A tool that provides these abstractions out of the box can be hugely beneficial.

+ +

Spinnaker doesn’t support a plugin model but provides extension points to support deployments to new cloud providers. These cloud provider implementations exist for most of the popular cloud providers.

+ +
+ +

Summary

+ +

In summary, GoCD is a best-in-breed Continuous Delivery server that allows you to represent complex CD workflows to any environment. If you are looking to represent your end-to-end CD workflow with good visualizations of your value stream, artifact lineage and pipeline current state, consider GoCD.

+ +

If you are managing large scale clusters and can benefit from the Netflix style deployment patterns and cloud native abstractions, consider Spinnaker. Spinnaker focuses on one thing, deployments, and does it well. You will have to use additional tools to design an end-to-end CD workflow.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/10/gocd-vs-spinnaker/index.html b/pr-1714/2017/07/10/gocd-vs-spinnaker/index.html new file mode 100644 index 000000000..c015b7f13 --- /dev/null +++ b/pr-1714/2017/07/10/gocd-vs-spinnaker/index.html @@ -0,0 +1,270 @@ + + + + + + + + + + + + + + + + GoCD vs Spinnaker | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery: GoCD vs Spinnaker +
+ +
+ + +
+

Continuous Delivery: GoCD vs Spinnaker

+

Sheroy Marker (Head of Technology), Thoughtworks Products

+

+

+
+ +
+ +

With Continuous Delivery (CD) adoption on the rise, tools that help teams with CD are becoming popular too. GoCD and Spinnaker are two sought after tools in this space. We are often asked how they compare - “GoCD or Spinnaker?” and the truth is that these tools solve different problems and are not interchangeable. Before we delve further, here’s a quick refresher on Continuous Delivery.

+ +

Continuous Delivery

+ +
+

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way - Jez Humble

+
+ +

Continuous Delivery is an overarching practice that includes Build Automation or Continuous Integration, Test Automation and Deployment Automation. By automating these concerns in a Continuous Delivery pipeline you are enabling your software to be releasable to production at any time. A CD workflow is incomplete if it doesn’t address all of these concerns.

+ +
+Concerns addressed in a CD workflow +
+ +

Continuous Delivery has its roots in the lean principle of value stream mapping to improve the efficiency of software delivery, by identifying and eliminating waste in the process. For organizations looking to introduce efficiency in their release engineering with CD, an understanding of their value stream is crucial. An efficient software release process must model this value stream effectively. A good visualization of the current state goes a long way in finding and removing bottlenecks.

+ +

As Continuous Delivery becomes more popular as a practice, so do some of the tools that enable this practice. GoCD and Spinnaker are two of the popular tools in this space.

+ +

GoCD

+ +

GoCD is a best-of-breed Continuous Delivery tool that allows you to orchestrate complex Continuous Delivery workflows. It was the first Continuous Delivery server to provide built-in abstractions to create CD pipelines, along with value stream visualizations for you to be able to truly take stock of the efficiencies (or lack of) in your release process.

+ +

GoCD provides the flexibility to introduce the levels of parallelism and manual stages that specific workflows may require. The tool allows you to introduce the right mix of controls such as role based access control for critical stages, and leaves the implementation of the steps to the user.

+ +

GoCD does not think of Continuous Integration and Continuous Delivery as disconnected processes. When designing a Continuous Delivery workflow for a non-trivial software system, representing the end to end process, from a developer commit to a production deployment is key.

+ +
+GoCD Value Stream Map +GoCD's Value Stream Map +
+ +

With GoCD, you can define your build, test, and deploy stages in the same pipeline with end to end visualization of the process. The value stream view in GoCD gives you the complete picture of your deployment pipeline including traceability and lineage of artifacts that are currently deployed on environments.

+ +

GoCD is open source and provides a plugin architecture that lets you extend its ecosystem.

+ +

Spinnaker

+ +

Spinnaker is a best-in-class multi-cloud deployment automation tool built at Netflix to handle deployments to large clusters on AWS. Spinnaker does not model the end to end Continuous Delivery workflow. You have to integrate with a Continuous Integration tool like Jenkins to automate the build and test automation stages for your CD workflow.

+ +

Spinnaker provides cloud abstractions such as applications, deployments and clusters out of the box. These abstractions enable you to automate deployments relatively quickly and without the need for much scripting. Though Spinnaker has the concept of pipelines, they are specific to deployments and don’t model a complete Continuous Delivery workflow, from commit to production.

+ +

Spinnaker is prescriptive about deployment patterns with it’s built-in abstractions such as out-of-the-box stage types, immutable images, and deployment strategies. The opinionated nature of the tool is beneficial for teams that are looking for industry standard solutions to some of these deployment concerns and don’t really want to implement these patterns themselves.

+ +
+Spinnaker’s Pipeline View +Spinnaker’s Pipeline View. Image from: https://www.spinnaker.io/guides/tutorials/codelabs/hello-deployment/ +
+ +

Spinnaker is designed to handle deployments to popular cloud environments and allows you to define workflows for these deployments. For large software systems, at scales close to the Netflix service, deployment is in itself a complex problem. When you are releasing software to tens of thousands of nodes, concerns such as automated deployment and rollback strategies become key. A tool that provides these abstractions out of the box can be hugely beneficial.

+ +

Spinnaker doesn’t support a plugin model but provides extension points to support deployments to new cloud providers. These cloud provider implementations exist for most of the popular cloud providers.

+ +
+ +

Summary

+ +

In summary, GoCD is a best-in-breed Continuous Delivery server that allows you to represent complex CD workflows to any environment. If you are looking to represent your end-to-end CD workflow with good visualizations of your value stream, artifact lineage and pipeline current state, consider GoCD.

+ +

If you are managing large scale clusters and can benefit from the Netflix style deployment patterns and cloud native abstractions, consider Spinnaker. Spinnaker focuses on one thing, deployments, and does it well. You will have to use additional tools to design an end-to-end CD workflow.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/10/index.html b/pr-1714/2017/07/10/index.html new file mode 100644 index 000000000..e8df4939f --- /dev/null +++ b/pr-1714/2017/07/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/13.html b/pr-1714/2017/07/13.html new file mode 100644 index 000000000..122419828 --- /dev/null +++ b/pr-1714/2017/07/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/13/index.html b/pr-1714/2017/07/13/index.html new file mode 100644 index 000000000..2f469b7c5 --- /dev/null +++ b/pr-1714/2017/07/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/13/introduction-continuous-delivery-101.html b/pr-1714/2017/07/13/introduction-continuous-delivery-101.html new file mode 100644 index 000000000..38357e33d --- /dev/null +++ b/pr-1714/2017/07/13/introduction-continuous-delivery-101.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + An introduction to continuous delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - An introduction to continuous delivery: CD 101 +
+ +
+ + +
+

Part 1 - CD 101: An introduction to continuous delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, an advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

This series is for you if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +

CD 101 - Part 1 - History and Introduction to the deployment pipeline

+ +

In the first part of this series, Ken covers

+ +
    +
  • a brief history of continuous delivery
    • +
  • the difference between continuous delivery and continuous deployment (Yes, they are different)
    • +
  • a brief introduction of a 'deployment pipeline' +
    • +
+
+ +
+


+Stay tuned for Part 2 of the Continuous Delivery 101 series which talks about the deployment pipeline in more detail.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/13/introduction-continuous-delivery-101/index.html b/pr-1714/2017/07/13/introduction-continuous-delivery-101/index.html new file mode 100644 index 000000000..60c78ae50 --- /dev/null +++ b/pr-1714/2017/07/13/introduction-continuous-delivery-101/index.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + An introduction to continuous delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - An introduction to continuous delivery: CD 101 +
+ +
+ + +
+

Part 1 - CD 101: An introduction to continuous delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, an advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

This series is for you if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +

CD 101 - Part 1 - History and Introduction to the deployment pipeline

+ +

In the first part of this series, Ken covers

+ +
    +
  • a brief history of continuous delivery
    • +
  • the difference between continuous delivery and continuous deployment (Yes, they are different)
    • +
  • a brief introduction of a 'deployment pipeline' +
    • +
+
+ +
+


+Stay tuned for Part 2 of the Continuous Delivery 101 series which talks about the deployment pipeline in more detail.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/18.html b/pr-1714/2017/07/18.html new file mode 100644 index 000000000..a3490d13c --- /dev/null +++ b/pr-1714/2017/07/18.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 18 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/18/continuous-deployment-strategies.html b/pr-1714/2017/07/18/continuous-deployment-strategies.html new file mode 100644 index 000000000..8012f37c7 --- /dev/null +++ b/pr-1714/2017/07/18/continuous-deployment-strategies.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Continuous Deployment Strategies | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - Continuous Deployment Strategies +
+ +
+ + +
+

Part 1 - Continuous Deployment Strategies

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+

Not very long ago, during the days of Perl/CGI and PHP (and even today); deployments involved 'ftp-ing' your files to the webserver directory and running a bunch of migrations by shelling into the webserver.

+ +

Modern webapps and application servers have evolved quite a bit since then, but many developers continue to use similar strategies to perform deployments. FTP has been replaced by git pull followed by bundle install or npm install and then restarting the appserver that you use.

+ +

Along with similar deployment strategies, many developers also continue to use the same servers for months and years on end. But even with the right patches, updates, etc, after a while it's easy to end up with a "snowflake server": a server with a delicate, unique configuration that does not lend itself to change. A solution to this is the "phoenix server." Here's a little more about both these concepts.

+ +

Snowflake servers

+ +

While this approach may work great for small webapps, it quickly falls apart when you're managing anything but a couple of servers.

+ +

It is generally difficult to set up a new server if your existing server has problems. If you're looking to scale by adding more servers, it's difficult to keep each server's software, configuration and services in sync. You may not be in a position to replicate a production (or production-like) environment for testing.

+ +

Over time, one loses track of the magic configuration files, packages and services that are installed on the production machines.

+ +

Phoenix servers

+ +

Some of these issues can be addressed by using a bit of configuration management tools like chef, puppet, or ansible among a few others.

+ +

These tools help avoid configuration drift, the sort of one-off changes that go unnoticed and undocumented.

+ +

An important point to note is that these tools only apply the configuration that they are asked to. If you applied any additional configuration outside of what these tools are aware of, or if you forgot to un-apply or remove some configuration, you'd be out of luck. This what Ranjib Dey calls the Accumulator Anti-Pattern.

+ +

A much better alternative is to tear down servers periodically and apply configuration changes every once in a while. This helps avoid and catch any configuration drift outside of configuration management tools. Eventually one can move to deploying new servers on every configuration change. This strategy is known as an Immutable Server.

+ +

How does this apply to Continuous Deployment?

+ +

Continuous Deployment requires that at a very minimum, you have:

+ +
    +
  • a solid foundation of tests that gives you confidence in your software
    • +
  • a set of automation tools and scripts that give you confidence that your deployment will succeed, or rollback in case of issues
    • +
+ +

A few of the more popular continuous deployment strategies include blue/green deployments and canary releases, which I've briefly outlined below.

+ +

Blue/green deployments

+ +

This is one of the simplest CD strategies to implement and get started with.

+ +

Blue Green Deployments

+ +

Blue/green is a technique for deployments where the existing running deployment is left in place. A new version of the application is installed in parallel with the existing version. When the new version is ready, cut over to the new version by changing the load balancer configuration.

+ +

This makes rollback really simple and gives time to make sure that the new version works as expected before putting it live.

+ +

Canary releases

+ +

This is named after the "canary in a coal mine" metaphor. The metaphor originates from the times when miners used to carry caged canaries into the mines with them: if there were any dangerous gases (methane or carbon monoxide) in the mine, the canary would die before the gas levels reached levels hazardous to humans.

+ +

Canary Release

+ +

Canary releasing is similar to blue/green, although only a small amount of the servers are upgraded. Then, using a cookie or similar, a fraction of users are directed to the new version.

+ +

This allows for the load and functionality of the site to be tested with a small group of users. If the application behaves as expected, migrate more and more servers to the new version until all the users are on the new version.

+ +

This technique can also be used to do some interesting multi-variant testing and performance testing.

+ +

Next steps

+ +

In my next post, I'll get into the implementation techniques of blue/green deployments. A subsequent post will talk about implementing canary releases. Let me know if you have feedback in the comments section below.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/18/continuous-deployment-strategies/index.html b/pr-1714/2017/07/18/continuous-deployment-strategies/index.html new file mode 100644 index 000000000..49720af22 --- /dev/null +++ b/pr-1714/2017/07/18/continuous-deployment-strategies/index.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Continuous Deployment Strategies | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - Continuous Deployment Strategies +
+ +
+ + +
+

Part 1 - Continuous Deployment Strategies

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+

Not very long ago, during the days of Perl/CGI and PHP (and even today); deployments involved 'ftp-ing' your files to the webserver directory and running a bunch of migrations by shelling into the webserver.

+ +

Modern webapps and application servers have evolved quite a bit since then, but many developers continue to use similar strategies to perform deployments. FTP has been replaced by git pull followed by bundle install or npm install and then restarting the appserver that you use.

+ +

Along with similar deployment strategies, many developers also continue to use the same servers for months and years on end. But even with the right patches, updates, etc, after a while it's easy to end up with a "snowflake server": a server with a delicate, unique configuration that does not lend itself to change. A solution to this is the "phoenix server." Here's a little more about both these concepts.

+ +

Snowflake servers

+ +

While this approach may work great for small webapps, it quickly falls apart when you're managing anything but a couple of servers.

+ +

It is generally difficult to set up a new server if your existing server has problems. If you're looking to scale by adding more servers, it's difficult to keep each server's software, configuration and services in sync. You may not be in a position to replicate a production (or production-like) environment for testing.

+ +

Over time, one loses track of the magic configuration files, packages and services that are installed on the production machines.

+ +

Phoenix servers

+ +

Some of these issues can be addressed by using a bit of configuration management tools like chef, puppet, or ansible among a few others.

+ +

These tools help avoid configuration drift, the sort of one-off changes that go unnoticed and undocumented.

+ +

An important point to note is that these tools only apply the configuration that they are asked to. If you applied any additional configuration outside of what these tools are aware of, or if you forgot to un-apply or remove some configuration, you'd be out of luck. This what Ranjib Dey calls the Accumulator Anti-Pattern.

+ +

A much better alternative is to tear down servers periodically and apply configuration changes every once in a while. This helps avoid and catch any configuration drift outside of configuration management tools. Eventually one can move to deploying new servers on every configuration change. This strategy is known as an Immutable Server.

+ +

How does this apply to Continuous Deployment?

+ +

Continuous Deployment requires that at a very minimum, you have:

+ +
    +
  • a solid foundation of tests that gives you confidence in your software
    • +
  • a set of automation tools and scripts that give you confidence that your deployment will succeed, or rollback in case of issues
    • +
+ +

A few of the more popular continuous deployment strategies include blue/green deployments and canary releases, which I've briefly outlined below.

+ +

Blue/green deployments

+ +

This is one of the simplest CD strategies to implement and get started with.

+ +

Blue Green Deployments

+ +

Blue/green is a technique for deployments where the existing running deployment is left in place. A new version of the application is installed in parallel with the existing version. When the new version is ready, cut over to the new version by changing the load balancer configuration.

+ +

This makes rollback really simple and gives time to make sure that the new version works as expected before putting it live.

+ +

Canary releases

+ +

This is named after the "canary in a coal mine" metaphor. The metaphor originates from the times when miners used to carry caged canaries into the mines with them: if there were any dangerous gases (methane or carbon monoxide) in the mine, the canary would die before the gas levels reached levels hazardous to humans.

+ +

Canary Release

+ +

Canary releasing is similar to blue/green, although only a small amount of the servers are upgraded. Then, using a cookie or similar, a fraction of users are directed to the new version.

+ +

This allows for the load and functionality of the site to be tested with a small group of users. If the application behaves as expected, migrate more and more servers to the new version until all the users are on the new version.

+ +

This technique can also be used to do some interesting multi-variant testing and performance testing.

+ +

Next steps

+ +

In my next post, I'll get into the implementation techniques of blue/green deployments. A subsequent post will talk about implementing canary releases. Let me know if you have feedback in the comments section below.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/18/index.html b/pr-1714/2017/07/18/index.html new file mode 100644 index 000000000..0ca11f728 --- /dev/null +++ b/pr-1714/2017/07/18/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 18 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/20.html b/pr-1714/2017/07/20.html new file mode 100644 index 000000000..3e3cb7847 --- /dev/null +++ b/pr-1714/2017/07/20.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/20/deployment-pipeline-automated-testing.html b/pr-1714/2017/07/20/deployment-pipeline-automated-testing.html new file mode 100644 index 000000000..87df46d1f --- /dev/null +++ b/pr-1714/2017/07/20/deployment-pipeline-automated-testing.html @@ -0,0 +1,248 @@ + + + + + + + + + + + + + + + + Deployment pipeline and types of automated testing | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - Deployment pipeline and types of automated testing: CD 101 +
+ +
+ + +
+

Part 2 - CD 101: Deployment pipeline and types of automated testing

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

In part 2 of our Continuous Delivery 101 video series, we’ll be looking at:

+ +
    +
  • A detailed view of the ‘deployment pipeline’. Do check out part 1 of the series to see an introduction to the deployment pipeline.
    • +
  • Common types of automated testing
    • +
  • Some misconceptions about DevOps and Continuous Delivery
    • +
+ +

This video can help you understand the basics of how to order your tests in a pipeline. Look at the types of automated testing such as unit, regression, and performance tests. Tips on monitoring your continuous delivery pipeline so you react appropriately when things do go wrong. +

+
+ +
+


+In part 3, we’ll look at some of the principles and practices behind CD. Stay tuned!

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/20/deployment-pipeline-automated-testing/index.html b/pr-1714/2017/07/20/deployment-pipeline-automated-testing/index.html new file mode 100644 index 000000000..c21a2620d --- /dev/null +++ b/pr-1714/2017/07/20/deployment-pipeline-automated-testing/index.html @@ -0,0 +1,248 @@ + + + + + + + + + + + + + + + + Deployment pipeline and types of automated testing | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - Deployment pipeline and types of automated testing: CD 101 +
+ +
+ + +
+

Part 2 - CD 101: Deployment pipeline and types of automated testing

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

In part 2 of our Continuous Delivery 101 video series, we’ll be looking at:

+ +
    +
  • A detailed view of the ‘deployment pipeline’. Do check out part 1 of the series to see an introduction to the deployment pipeline.
    • +
  • Common types of automated testing
    • +
  • Some misconceptions about DevOps and Continuous Delivery
    • +
+ +

This video can help you understand the basics of how to order your tests in a pipeline. Look at the types of automated testing such as unit, regression, and performance tests. Tips on monitoring your continuous delivery pipeline so you react appropriately when things do go wrong. +

+
+ +
+


+In part 3, we’ll look at some of the principles and practices behind CD. Stay tuned!

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/20/index.html b/pr-1714/2017/07/20/index.html new file mode 100644 index 000000000..64eca8380 --- /dev/null +++ b/pr-1714/2017/07/20/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/25.html b/pr-1714/2017/07/25.html new file mode 100644 index 000000000..d3be9aa89 --- /dev/null +++ b/pr-1714/2017/07/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/25/blue-green-deployments.html b/pr-1714/2017/07/25/blue-green-deployments.html new file mode 100644 index 000000000..10731fe5c --- /dev/null +++ b/pr-1714/2017/07/25/blue-green-deployments.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + Blue/Green Deployments | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Blue/Green Deployments +
+ +
+ + +
+

Part 2 - Continuous Deployment Strategies: Blue/Green Deployments

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+ +

In the previous article on Continuous Deployment Strategies, we explored at a high level some of the popular CD strategies.

+ +

This article describes some of the implementation techniques for performing blue/green deployments.

+ +
+

Blue/green is a technique for deployments where the existing running deployment is left in place. A new version of the application is installed in parallel with the existing version. When the new version is ready, cut over to the new version by changing the load balancer configuration.

+
+ +

The basic idea behind this technique is to be able to route users to either the green set of servers, or the blue set of servers.

+ +

This can be achieved in multiple ways:

+ +
    +
  • Changing the load balancer/router
    • +
  • Changing public DNS records
    • +
  • Load Balancer + Internal DNS records
    • +
+ +

Changing the load balancer/router

+ +

Load Balancer Router

+ +

Using this technique you would change the load balancer or request router to point to either the blue server or the green server.

+ +

Changing public DNS records

+ +

Using this technique involves load-balancing at the DNS level by changing either the CNAME or the A records. When users request a DNS entry for your website, your DNS server could return the IP address for either the blue server or the green server. This particular approach would require that the time to live (TTL) is set to a very small value.

+ +

Changing public DNS records

+ +

This particular approach is not recommended for changing public DNS records because some DNS servers run some browsers don't respect the low TTL values on the DNS entry, they will cache the DNS records for longer than the TTL. This may leave a subset of your users not being able to access your website.

+ +

Load Balancer + Internal DNS records

+ +

This approach is a combination of the two techniques we've seen so far.

+ +

Load Balancer + Internal DNS records

+ +

In this technique, instead of changing public DNS records, we'll change internal (private) DNS records. Since the internal network and the DNS server can be managed and configured to respect TTLs, this approach works a lot better than changing public DNS records.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/25/blue-green-deployments/index.html b/pr-1714/2017/07/25/blue-green-deployments/index.html new file mode 100644 index 000000000..e5c29b9f6 --- /dev/null +++ b/pr-1714/2017/07/25/blue-green-deployments/index.html @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + Blue/Green Deployments | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Blue/Green Deployments +
+ +
+ + +
+

Part 2 - Continuous Deployment Strategies: Blue/Green Deployments

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+ +

In the previous article on Continuous Deployment Strategies, we explored at a high level some of the popular CD strategies.

+ +

This article describes some of the implementation techniques for performing blue/green deployments.

+ +
+

Blue/green is a technique for deployments where the existing running deployment is left in place. A new version of the application is installed in parallel with the existing version. When the new version is ready, cut over to the new version by changing the load balancer configuration.

+
+ +

The basic idea behind this technique is to be able to route users to either the green set of servers, or the blue set of servers.

+ +

This can be achieved in multiple ways:

+ +
    +
  • Changing the load balancer/router
    • +
  • Changing public DNS records
    • +
  • Load Balancer + Internal DNS records
    • +
+ +

Changing the load balancer/router

+ +

Load Balancer Router

+ +

Using this technique you would change the load balancer or request router to point to either the blue server or the green server.

+ +

Changing public DNS records

+ +

Using this technique involves load-balancing at the DNS level by changing either the CNAME or the A records. When users request a DNS entry for your website, your DNS server could return the IP address for either the blue server or the green server. This particular approach would require that the time to live (TTL) is set to a very small value.

+ +

Changing public DNS records

+ +

This particular approach is not recommended for changing public DNS records because some DNS servers run some browsers don't respect the low TTL values on the DNS entry, they will cache the DNS records for longer than the TTL. This may leave a subset of your users not being able to access your website.

+ +

Load Balancer + Internal DNS records

+ +

This approach is a combination of the two techniques we've seen so far.

+ +

Load Balancer + Internal DNS records

+ +

In this technique, instead of changing public DNS records, we'll change internal (private) DNS records. Since the internal network and the DNS server can be managed and configured to respect TTLs, this approach works a lot better than changing public DNS records.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/25/index.html b/pr-1714/2017/07/25/index.html new file mode 100644 index 000000000..ca8d6f195 --- /dev/null +++ b/pr-1714/2017/07/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/07/index.html b/pr-1714/2017/07/index.html new file mode 100644 index 000000000..e39d9fc2e --- /dev/null +++ b/pr-1714/2017/07/index.html @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08.html b/pr-1714/2017/08.html new file mode 100644 index 000000000..6633e7f54 --- /dev/null +++ b/pr-1714/2017/08.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/08.html b/pr-1714/2017/08/08.html new file mode 100644 index 000000000..2b0773a00 --- /dev/null +++ b/pr-1714/2017/08/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 8 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/08/gocd-elastic-agents-benefits.html b/pr-1714/2017/08/08/gocd-elastic-agents-benefits.html new file mode 100644 index 000000000..12c5feff0 --- /dev/null +++ b/pr-1714/2017/08/08/gocd-elastic-agents-benefits.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + GoCD Elastic Agents | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Elastic Agents +
+ +
+ + +
+

The benefits of GoCD elastic agents

+

Ketan Padegaonkar

+

+

+
+ +
+ +

This post is about the GoCD team’s journey in building elastic agents, our experience while using it in anger and the benefits we saw.

+ +

Why elastic agents

+ +

GoCD operates on a server-agent model where a server communicates with many agents. The server is responsible for orchestrating various stages, jobs and tasks on the agents. The agents are responsible for their execution in the deployment pipeline.

+ +

Oftentimes it makes sense to parallelize, to speed up build and test execution, get feedback quickly and deploy rapidly.

+ +

Parallelize Workflow

+ +

But for some teams, parallelization requires an intense use of hardware resources for brief periods of time. The situation becomes particularly frustrating when different branches of code or environments require different kinds of hardware and software to run on.

+ +

In many cases, this leads to:

+ +
    +
  • excessive provisioning of build machines, leaving a lot of hardware under-utilized when builds and tests are not running.
    • +
  • re-provisioning some of the hardware based on need, leading to a significant lead time depending on its availability
    • +
  • slower build time when sufficient hardware is not available.
    • +
+ +

We wanted to help reduce infrastructure costs and improve hardware utilization. We believed that allowing organizations to bring up GoCD agents on-demand will achieve that goal. So we designed elastic agents to allow teams to leverage a combination of their own hardware and the cloud to run their builds.

+ +

Benefits we observed

+ +

We started using the elastic agents for Docker plugin as it was the first one we built. We observed these benefits from elastic agents since we started to use them.

+ +

1. Save time, reduce effort

+ +
+

It has saved us hours of wasted developer productivity per week.

+
+ +

Before elastic agents, if we wanted to test something new that needed different hardware or software, we needed to provision build machines, and have the relevant software installed on these agents. Then if we chose to not keep the change, we also had to decommission the machines. It was time consuming to do all of that, and took the focus away from development.

+ +

Using elastic agents, we can apply the idea behind ImmutableServer to our build machines. We now build an operating system image with all the required software (with the versions we need). This allowed us to operate quickly, and experiment without the worry of managing hardware.

+ +

2. Less pain and overhead

+ +
+

Every team member feels that our build and deployment process is much easier and less painful.

+
+ +

We can now quickly bring up Docker containers (with all the required software) and kick off the builds within a certain environment without affecting other environments. We completely avoid all the pain we experienced before. Moving to a combination of on-premises hardware and Amazon ECS has helped the team move a lot faster. We are not dependent on hardware being procured and provisioned with the right set of tools/software version on it, before we start using it.

+ +

3. Improve utilization of resources

+ +
+

We never had this capability to optimize our resources as we do now.

+
+ +

The real beauty of elastic agents was that it improved our infrastructure utilization. We can now use the same hardware to run and test GoCD on several operating systems improving the overall utilization of our hardware. If someone needs more machines to run builds, we can now terminate existing machines and bring up new ones. And if we still need more, we can overflow our builds on AWS with very little reconfiguring.

+ +

How can your team benefit from elastic agents?

+ +

Several open-source elastic agent plugins are currently available. We already have an Amazon Elastic Container Service(ECS) plugin which a lot of our users are trying out. A guiding principle for GoCD is to keep it as agnostic as possible. This allows the user to choose what technology they want to use and provision agents there. Therefore, we put a lot of time and effort into our plugin API, so you can just plug in any cloud provider you have or build your own plugin.

+ +

Depending on user demand and the popularity of the cloud providers among our users we will potentially build support for agents running on Amazon EC2 instances, Azure and other cloud providers.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/08/gocd-elastic-agents-benefits/index.html b/pr-1714/2017/08/08/gocd-elastic-agents-benefits/index.html new file mode 100644 index 000000000..b6641d553 --- /dev/null +++ b/pr-1714/2017/08/08/gocd-elastic-agents-benefits/index.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + GoCD Elastic Agents | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Elastic Agents +
+ +
+ + +
+

The benefits of GoCD elastic agents

+

Ketan Padegaonkar

+

+

+
+ +
+ +

This post is about the GoCD team’s journey in building elastic agents, our experience while using it in anger and the benefits we saw.

+ +

Why elastic agents

+ +

GoCD operates on a server-agent model where a server communicates with many agents. The server is responsible for orchestrating various stages, jobs and tasks on the agents. The agents are responsible for their execution in the deployment pipeline.

+ +

Oftentimes it makes sense to parallelize, to speed up build and test execution, get feedback quickly and deploy rapidly.

+ +

Parallelize Workflow

+ +

But for some teams, parallelization requires an intense use of hardware resources for brief periods of time. The situation becomes particularly frustrating when different branches of code or environments require different kinds of hardware and software to run on.

+ +

In many cases, this leads to:

+ +
    +
  • excessive provisioning of build machines, leaving a lot of hardware under-utilized when builds and tests are not running.
    • +
  • re-provisioning some of the hardware based on need, leading to a significant lead time depending on its availability
    • +
  • slower build time when sufficient hardware is not available.
    • +
+ +

We wanted to help reduce infrastructure costs and improve hardware utilization. We believed that allowing organizations to bring up GoCD agents on-demand will achieve that goal. So we designed elastic agents to allow teams to leverage a combination of their own hardware and the cloud to run their builds.

+ +

Benefits we observed

+ +

We started using the elastic agents for Docker plugin as it was the first one we built. We observed these benefits from elastic agents since we started to use them.

+ +

1. Save time, reduce effort

+ +
+

It has saved us hours of wasted developer productivity per week.

+
+ +

Before elastic agents, if we wanted to test something new that needed different hardware or software, we needed to provision build machines, and have the relevant software installed on these agents. Then if we chose to not keep the change, we also had to decommission the machines. It was time consuming to do all of that, and took the focus away from development.

+ +

Using elastic agents, we can apply the idea behind ImmutableServer to our build machines. We now build an operating system image with all the required software (with the versions we need). This allowed us to operate quickly, and experiment without the worry of managing hardware.

+ +

2. Less pain and overhead

+ +
+

Every team member feels that our build and deployment process is much easier and less painful.

+
+ +

We can now quickly bring up Docker containers (with all the required software) and kick off the builds within a certain environment without affecting other environments. We completely avoid all the pain we experienced before. Moving to a combination of on-premises hardware and Amazon ECS has helped the team move a lot faster. We are not dependent on hardware being procured and provisioned with the right set of tools/software version on it, before we start using it.

+ +

3. Improve utilization of resources

+ +
+

We never had this capability to optimize our resources as we do now.

+
+ +

The real beauty of elastic agents was that it improved our infrastructure utilization. We can now use the same hardware to run and test GoCD on several operating systems improving the overall utilization of our hardware. If someone needs more machines to run builds, we can now terminate existing machines and bring up new ones. And if we still need more, we can overflow our builds on AWS with very little reconfiguring.

+ +

How can your team benefit from elastic agents?

+ +

Several open-source elastic agent plugins are currently available. We already have an Amazon Elastic Container Service(ECS) plugin which a lot of our users are trying out. A guiding principle for GoCD is to keep it as agnostic as possible. This allows the user to choose what technology they want to use and provision agents there. Therefore, we put a lot of time and effort into our plugin API, so you can just plug in any cloud provider you have or build your own plugin.

+ +

Depending on user demand and the popularity of the cloud providers among our users we will potentially build support for agents running on Amazon EC2 instances, Azure and other cloud providers.

+ +
+
+
+ +
+
+ +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/08/index.html b/pr-1714/2017/08/08/index.html new file mode 100644 index 000000000..114025aba --- /dev/null +++ b/pr-1714/2017/08/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 8 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/15.html b/pr-1714/2017/08/15.html new file mode 100644 index 000000000..204b05eb5 --- /dev/null +++ b/pr-1714/2017/08/15.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 15 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/15/canary-releases.html b/pr-1714/2017/08/15/canary-releases.html new file mode 100644 index 000000000..47b5e0cf7 --- /dev/null +++ b/pr-1714/2017/08/15/canary-releases.html @@ -0,0 +1,234 @@ + + + + + + + + + + + + + + + + Implementation Techniques for Canary Releases | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Canary Releases +
+ +
+ + +
+

Part 3 - Continuous Deployment Strategies: Implementation Techniques for Canary Releases

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+ +

In the previous article on Continuous Deployment Strategies, we explored techniques of performing blue/green deployments. In this post, we’ll cover how to perform Canary Releases. We know that

+ +
+

Canary releases are similar to blue/green, although only a small amount of the servers are upgraded. Then, using a cookie or similar, a fraction of users are directed to the new version.

+
+ +

Canary Release

+ +

Just like Blue/Green Deployments, one would start by deploying the application to a small subset of your servers. Once the subset of servers is deployed to, you may then route requests for a few users to the new set of servers.

+ +

This strategy lets you do a lot of interesting things, like:

+ +
    +
  • test the performance of the application
    • +
  • perform A/B tests based on demographics and user profiles, for example "users between the ages of 20-25 living in Iowa"
    • +
  • get feedback from a subset of beta testers or users from your company
    • +
+ +

As your confidence in the deployment improves, you can deploy your application to more and more servers, and route more users to the new servers.

+ +

If one or more versions of your application are running in production for some period of time, your application and its components (webservices, microservices, database) needs to be backward-compatible so that it works with at least one or two previous versions of your application. Parallel-Change Pattern can be an effective way to implement backward-incompatible changes between application interfaces.

+ +
+ +

Summary

+ +

In this blog series, we've looked at concepts like Phoenix Servers, Blue/Green Deployments and Canary Releases to help with effective continuous deployment. If you have any feedback or would like to hear about other continuous deployment strategies, leave a comment below.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/15/canary-releases/index.html b/pr-1714/2017/08/15/canary-releases/index.html new file mode 100644 index 000000000..d39a7dd45 --- /dev/null +++ b/pr-1714/2017/08/15/canary-releases/index.html @@ -0,0 +1,234 @@ + + + + + + + + + + + + + + + + Implementation Techniques for Canary Releases | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Canary Releases +
+ +
+ + +
+

Part 3 - Continuous Deployment Strategies: Implementation Techniques for Canary Releases

+

Ketan Padegaonkar

+

+ Continuous Deployment Strategies +

+
+ +
+ +

In the previous article on Continuous Deployment Strategies, we explored techniques of performing blue/green deployments. In this post, we’ll cover how to perform Canary Releases. We know that

+ +
+

Canary releases are similar to blue/green, although only a small amount of the servers are upgraded. Then, using a cookie or similar, a fraction of users are directed to the new version.

+
+ +

Canary Release

+ +

Just like Blue/Green Deployments, one would start by deploying the application to a small subset of your servers. Once the subset of servers is deployed to, you may then route requests for a few users to the new set of servers.

+ +

This strategy lets you do a lot of interesting things, like:

+ +
    +
  • test the performance of the application
    • +
  • perform A/B tests based on demographics and user profiles, for example "users between the ages of 20-25 living in Iowa"
    • +
  • get feedback from a subset of beta testers or users from your company
    • +
+ +

As your confidence in the deployment improves, you can deploy your application to more and more servers, and route more users to the new servers.

+ +

If one or more versions of your application are running in production for some period of time, your application and its components (webservices, microservices, database) needs to be backward-compatible so that it works with at least one or two previous versions of your application. Parallel-Change Pattern can be an effective way to implement backward-incompatible changes between application interfaces.

+ +
+ +

Summary

+ +

In this blog series, we've looked at concepts like Phoenix Servers, Blue/Green Deployments and Canary Releases to help with effective continuous deployment. If you have any feedback or would like to hear about other continuous deployment strategies, leave a comment below.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/15/index.html b/pr-1714/2017/08/15/index.html new file mode 100644 index 000000000..7119fbdd7 --- /dev/null +++ b/pr-1714/2017/08/15/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 15 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/22.html b/pr-1714/2017/08/22.html new file mode 100644 index 000000000..bee041079 --- /dev/null +++ b/pr-1714/2017/08/22.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/22/index.html b/pr-1714/2017/08/22/index.html new file mode 100644 index 000000000..e6723b66d --- /dev/null +++ b/pr-1714/2017/08/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/22/principles-practices-continuous-delivery.html b/pr-1714/2017/08/22/principles-practices-continuous-delivery.html new file mode 100644 index 000000000..faa9f545d --- /dev/null +++ b/pr-1714/2017/08/22/principles-practices-continuous-delivery.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Deployment pipeline and types of automated testing | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - Principles and Best Practices for Continuous Delivery: CD 101 +
+ +
+ + +
+

Part 3 - CD101: Principles and Best Practices for Continuous Delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is part 3 of our Continuous Delivery 101 video series, where we’ll be looking at some of the principles and best practices in continuous delivery like:

+ +
    +
  • The need for a repeatable process
    • +
  • Automation
    • +
  • Version controlling everything
    • +
  • Building in quality from the start
    • +
  • Redefining done as ‘released’
    • +
+ +

For some background on details of a continuous delivery pipeline and types of automated testing, please watch part 2 of our video series.

+ +

In this video we also cover some of the characteristics of a team where there is a concept of shared ownership and what it means to practice a ‘DevOps’ culture.

+ +


+
+ +
+


+ +

Now that we’ve covered the basics & best practices of Continuous Delivery, in part 4, we’ll look at how anyone can get started. Stay tuned.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/22/principles-practices-continuous-delivery/index.html b/pr-1714/2017/08/22/principles-practices-continuous-delivery/index.html new file mode 100644 index 000000000..33341b4ab --- /dev/null +++ b/pr-1714/2017/08/22/principles-practices-continuous-delivery/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Deployment pipeline and types of automated testing | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - Principles and Best Practices for Continuous Delivery: CD 101 +
+ +
+ + +
+

Part 3 - CD101: Principles and Best Practices for Continuous Delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is part 3 of our Continuous Delivery 101 video series, where we’ll be looking at some of the principles and best practices in continuous delivery like:

+ +
    +
  • The need for a repeatable process
    • +
  • Automation
    • +
  • Version controlling everything
    • +
  • Building in quality from the start
    • +
  • Redefining done as ‘released’
    • +
+ +

For some background on details of a continuous delivery pipeline and types of automated testing, please watch part 2 of our video series.

+ +

In this video we also cover some of the characteristics of a team where there is a concept of shared ownership and what it means to practice a ‘DevOps’ culture.

+ +


+
+ +
+


+ +

Now that we’ve covered the basics & best practices of Continuous Delivery, in part 4, we’ll look at how anyone can get started. Stay tuned.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/29.html b/pr-1714/2017/08/29.html new file mode 100644 index 000000000..532527932 --- /dev/null +++ b/pr-1714/2017/08/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/29/driving-change-devops-adoption.html b/pr-1714/2017/08/29/driving-change-devops-adoption.html new file mode 100644 index 000000000..e13af0384 --- /dev/null +++ b/pr-1714/2017/08/29/driving-change-devops-adoption.html @@ -0,0 +1,269 @@ + + + + + + + + + + + + + + + + DevOps Statistics and Stories | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - You can’t buy DevOps, but you may need to sell it: DevOps Statistics and Stories +
+ +
+ + +
+

Part 1 - You can’t buy DevOps, but you may need to sell it: DevOps Statistics and Stories

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

Having worked in the continuous delivery and DevOps space for several years, I often get frustrated when I hear "Oh, I’ll buy this tool and then I can do the DevOps." As a tool vendor, I wish it worked like that. In reality, it takes a lot of effort for anyone to drive and socialize change in an organization.

+ +

In this blog series, I am going to help you get stakeholder buy-in and also clear up some misconceptions about “selling” DevOps.

+ +

DevOps is driving change

+ +

There are many different methodologies, techniques, and architectures promising to make teams better. If you go on Wikipedia and looked up ‘software methodologies’, you will get a really long list. But unless people actually change the way they work, they won’t experience the benefits of these techniques. So in order to do ‘DevOps’ (or implement anything new), your biggest challenge will be to drive behavior change amongst your team members.

+ +

I’ve observed that there are usually two reasons that motivate people to ‘do’ anything:

+ +
    +
  • they're trying to make something better or to gain something (the carrot)
    • +
  • they’re trying to avoid pain (the stick)
    • +
+ +

The Carrot: What can DevOps make better?

+ +

1. Increase performance of your teams

+ +

Based on statistics from the 2017 State of DevOps report (authored by Jez Humble, Gene Kim and Nicole Forsgren), we know that teams practicing Devops experience:

+ +
    +
  • 24x faster recovery from failures
    • +
  • 3x lower change failure rate
    • +
  • 22% less time spent on unplanned work and rework
    • +
  • 50% less time remediating security issues.
    • +
+ +

2. Become attractive workplaces to people you’d like to hire

+ +

The State of Devops report also points out that employees in high-performing teams were 2.2 times more likely to recommend their organizations as a great place to work.

+ +

Note: If you are interested in the science behind the report, you can check out the video Sciencing the Crap Out of DevOps and the SSRN paper on 'The Role of Continuous Delivery in IT and Organizational Performance'.

+ +

The Stick: What if you don’t “do DevOps”

+ +

If the benefits alone are not enough to convince your audience, then try pointing out the threats of not practicing DevOps.

+ +

1. Get overtaken by the competition

+ +
+

Survival is optional. No one has to change.

+
+ +

I like to use this quote to describe the current situation. If you don’t do DevOps, that’s fine. But in all probability, your competitors will do it, get faster, and beat you.

+ +

2. Slow recovery from inevitable security issues

+ +

Heartbleed is a great example of this. According to their survey, when this SSL issue came out, the average recovery was around 10 days. There were a lot of sites that were fixed in 20 minutes because they had solid continuous delivery pipelines and were able to run through their entire process to get to product very quickly. Symantec did a survey on vulnerabilities by year, and the number of vulnerabilities grows every year.

+ +

3. Pay the high cost of human errors

+ +

Manual deployments is a game of russian roulette. In 2012, trading firm Knight Capital, used a manual process to deploy their software. They had eight servers to deploy to, but on one occasion, the technician did not copy the new code to one of the eight. This company, with nearly $400 million in assets, went bankrupt in 45 minutes because of a failed deployment.

+ +

More recently, an employee at Amazon typed in a command and unintentionally brought down a whole lot of servers and a huge part of the Internet with it. It still took them (Amazon!) four and a half hours to recover.

+ +

Here are some numbers about the cost of downtime which you can use to convince your business stakeholder about DevOps. According to Business Insider, during AWS' four-hour disruption downtime, S&P 500 companies lost 150 million, US financial services lost 160 million, but Apple, Walmart, Newegg, Best Buy, Costco, and surprisingly Amazon/Zappos were not affected by the outage. This is because they had processes in place and were able to switch data centers.

+ +
+ +

Summary

+ +

These anecdotes and statistics show the merits of adopting a DevOps culture. But these stories and statistics by themselves aren’t enough to bring out a team-wide or an organization-wide change. In my next post I’ll cover some of the strategies you can use to drive adoption of a DevOps culture (and drive any change) in your teams.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/29/driving-change-devops-adoption/index.html b/pr-1714/2017/08/29/driving-change-devops-adoption/index.html new file mode 100644 index 000000000..73f08e470 --- /dev/null +++ b/pr-1714/2017/08/29/driving-change-devops-adoption/index.html @@ -0,0 +1,269 @@ + + + + + + + + + + + + + + + + DevOps Statistics and Stories | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 1 - You can’t buy DevOps, but you may need to sell it: DevOps Statistics and Stories +
+ +
+ + +
+

Part 1 - You can’t buy DevOps, but you may need to sell it: DevOps Statistics and Stories

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

Having worked in the continuous delivery and DevOps space for several years, I often get frustrated when I hear "Oh, I’ll buy this tool and then I can do the DevOps." As a tool vendor, I wish it worked like that. In reality, it takes a lot of effort for anyone to drive and socialize change in an organization.

+ +

In this blog series, I am going to help you get stakeholder buy-in and also clear up some misconceptions about “selling” DevOps.

+ +

DevOps is driving change

+ +

There are many different methodologies, techniques, and architectures promising to make teams better. If you go on Wikipedia and looked up ‘software methodologies’, you will get a really long list. But unless people actually change the way they work, they won’t experience the benefits of these techniques. So in order to do ‘DevOps’ (or implement anything new), your biggest challenge will be to drive behavior change amongst your team members.

+ +

I’ve observed that there are usually two reasons that motivate people to ‘do’ anything:

+ +
    +
  • they're trying to make something better or to gain something (the carrot)
    • +
  • they’re trying to avoid pain (the stick)
    • +
+ +

The Carrot: What can DevOps make better?

+ +

1. Increase performance of your teams

+ +

Based on statistics from the 2017 State of DevOps report (authored by Jez Humble, Gene Kim and Nicole Forsgren), we know that teams practicing Devops experience:

+ +
    +
  • 24x faster recovery from failures
    • +
  • 3x lower change failure rate
    • +
  • 22% less time spent on unplanned work and rework
    • +
  • 50% less time remediating security issues.
    • +
+ +

2. Become attractive workplaces to people you’d like to hire

+ +

The State of Devops report also points out that employees in high-performing teams were 2.2 times more likely to recommend their organizations as a great place to work.

+ +

Note: If you are interested in the science behind the report, you can check out the video Sciencing the Crap Out of DevOps and the SSRN paper on 'The Role of Continuous Delivery in IT and Organizational Performance'.

+ +

The Stick: What if you don’t “do DevOps”

+ +

If the benefits alone are not enough to convince your audience, then try pointing out the threats of not practicing DevOps.

+ +

1. Get overtaken by the competition

+ +
+

Survival is optional. No one has to change.

+
+ +

I like to use this quote to describe the current situation. If you don’t do DevOps, that’s fine. But in all probability, your competitors will do it, get faster, and beat you.

+ +

2. Slow recovery from inevitable security issues

+ +

Heartbleed is a great example of this. According to their survey, when this SSL issue came out, the average recovery was around 10 days. There were a lot of sites that were fixed in 20 minutes because they had solid continuous delivery pipelines and were able to run through their entire process to get to product very quickly. Symantec did a survey on vulnerabilities by year, and the number of vulnerabilities grows every year.

+ +

3. Pay the high cost of human errors

+ +

Manual deployments is a game of russian roulette. In 2012, trading firm Knight Capital, used a manual process to deploy their software. They had eight servers to deploy to, but on one occasion, the technician did not copy the new code to one of the eight. This company, with nearly $400 million in assets, went bankrupt in 45 minutes because of a failed deployment.

+ +

More recently, an employee at Amazon typed in a command and unintentionally brought down a whole lot of servers and a huge part of the Internet with it. It still took them (Amazon!) four and a half hours to recover.

+ +

Here are some numbers about the cost of downtime which you can use to convince your business stakeholder about DevOps. According to Business Insider, during AWS' four-hour disruption downtime, S&P 500 companies lost 150 million, US financial services lost 160 million, but Apple, Walmart, Newegg, Best Buy, Costco, and surprisingly Amazon/Zappos were not affected by the outage. This is because they had processes in place and were able to switch data centers.

+ +
+ +

Summary

+ +

These anecdotes and statistics show the merits of adopting a DevOps culture. But these stories and statistics by themselves aren’t enough to bring out a team-wide or an organization-wide change. In my next post I’ll cover some of the strategies you can use to drive adoption of a DevOps culture (and drive any change) in your teams.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/29/index.html b/pr-1714/2017/08/29/index.html new file mode 100644 index 000000000..ce39c1c32 --- /dev/null +++ b/pr-1714/2017/08/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/31.html b/pr-1714/2017/08/31.html new file mode 100644 index 000000000..da08c7619 --- /dev/null +++ b/pr-1714/2017/08/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/31/apax-acquires-thoughtworks.html b/pr-1714/2017/08/31/apax-acquires-thoughtworks.html new file mode 100644 index 000000000..f410c9a78 --- /dev/null +++ b/pr-1714/2017/08/31/apax-acquires-thoughtworks.html @@ -0,0 +1,219 @@ + + + + + + + + + + + + + + + + GoCD and the Impact of the Thoughtworks Acquisition | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD and the Impact of the Thoughtworks Acquisition +
+ +
+ + +
+

GoCD and the Impact of the Thoughtworks Acquisition

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

On August 23 2017, Apax Funds announced their acquisition of Thoughtworks, Inc. As you know, even though there are other contributors to GoCD, most of the core team members are from Thoughtworks. We wanted to share what this news means to the GoCD product, its contributors, and the open source community.

+ +

If you'd like to read more about the acquisition, this post by Martin Fowler has interesting context about the news.

+ +

The impact on GoCD

+ +

For the GoCD core team there will be no change. Thoughtworks remains committed to building the best open source continuous delivery tool. This transaction does not change that. We will continue to innovate by building on the thought leadership of both this community and the larger Thoughtworks community.

+ +

In fact, now seems like a great time to share what's coming next with GoCD.

+ +

What’s coming in GoCD

+ +

We recently reached out to some of you to understand your CD processes with some of the newer deployment ecosystems and have some exciting ideas to make GoCD more cloud native with better support for container orchestrators. We will start this journey with better support for Kubernetes and the Docker workflow. Stay tuned for further updates.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/31/apax-acquires-thoughtworks/index.html b/pr-1714/2017/08/31/apax-acquires-thoughtworks/index.html new file mode 100644 index 000000000..a2d0b9f45 --- /dev/null +++ b/pr-1714/2017/08/31/apax-acquires-thoughtworks/index.html @@ -0,0 +1,219 @@ + + + + + + + + + + + + + + + + GoCD and the Impact of the Thoughtworks Acquisition | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD and the Impact of the Thoughtworks Acquisition +
+ +
+ + +
+

GoCD and the Impact of the Thoughtworks Acquisition

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

On August 23 2017, Apax Funds announced their acquisition of Thoughtworks, Inc. As you know, even though there are other contributors to GoCD, most of the core team members are from Thoughtworks. We wanted to share what this news means to the GoCD product, its contributors, and the open source community.

+ +

If you'd like to read more about the acquisition, this post by Martin Fowler has interesting context about the news.

+ +

The impact on GoCD

+ +

For the GoCD core team there will be no change. Thoughtworks remains committed to building the best open source continuous delivery tool. This transaction does not change that. We will continue to innovate by building on the thought leadership of both this community and the larger Thoughtworks community.

+ +

In fact, now seems like a great time to share what's coming next with GoCD.

+ +

What’s coming in GoCD

+ +

We recently reached out to some of you to understand your CD processes with some of the newer deployment ecosystems and have some exciting ideas to make GoCD more cloud native with better support for container orchestrators. We will start this journey with better support for Kubernetes and the Docker workflow. Stay tuned for further updates.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/31/index.html b/pr-1714/2017/08/31/index.html new file mode 100644 index 000000000..12e852c80 --- /dev/null +++ b/pr-1714/2017/08/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/08/index.html b/pr-1714/2017/08/index.html new file mode 100644 index 000000000..97726b1cf --- /dev/null +++ b/pr-1714/2017/08/index.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09.html b/pr-1714/2017/09.html new file mode 100644 index 000000000..936ee911c --- /dev/null +++ b/pr-1714/2017/09.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/05.html b/pr-1714/2017/09/05.html new file mode 100644 index 000000000..f76d6ad7f --- /dev/null +++ b/pr-1714/2017/09/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/05/index.html b/pr-1714/2017/09/05/index.html new file mode 100644 index 000000000..f0dadf517 --- /dev/null +++ b/pr-1714/2017/09/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption.html b/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption.html new file mode 100644 index 000000000..f9787291a --- /dev/null +++ b/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption.html @@ -0,0 +1,277 @@ + + + + + + + + + + + + + + + + Misconceptions and Patterns to drive DevOps Adoption | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - You can’t buy DevOps, but you may need to sell it: Misconceptions and Patterns to drive DevOps Adoption +
+ +
+ + +
+

Part 2 - You can’t buy DevOps, but you may need to sell it: Misconceptions and Patterns to drive DevOps Adoption

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

This is part 2 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. In the previous post, we looked at some industry statistics and anecdotes that can be used to convey the effectiveness of adopting a DevOps culture. While these are important to have and understand, by themselves, they won’t change people radically. To create a lasting impact, you have to drive change in a way that makes sense to individuals.

+ +

In this post, we’ll look at some of the most commonly held misconceptions about driving change. We’ll also explore some patterns that you can use to help gain acceptance of your ideas.

+ +

Common misconceptions

+ +

Before we get to the strategies to implement change, I want to highlight what I see are the most common misconceptions about implementing new ideas. These are highly opinionated, but I will explain why I believe so.

+ +

Ideas are judged 100% on merit

+ +

Those of us that have been in technology for a while know that there are a lot of successful products in the market that might not have been the best idea. Ideas actually aren't judged 100% on merit. If they were, betamax would've beat VHS. Good ideas need to go together with implementation to create a lasting impact. You can not just do a session to introduce it. Implementing change means that there's work to be done and it’s an ongoing process.

+ +

Top down approach is effective for changes

+ +

It’s very common for companies to attempt top-down culture change. A quick web search would turn up many examples of organizations who “went agile” and failed. Quite often a deeper dive reveals that they never actually changed behavior.

+ +

I saw a group several years ago who decided to switch from waterfall to agile methods. They went through fairly extensive training in things like user stories. For those that aren’t familiar, most successful agile organizations use stories as “conversation starters”, not detailed requirements.

+ +

At least one group in this organization took their massive waterfall requirements document, split it on paragraph markers and then proudly presented a spreadsheet with hundreds of smaller pieces of text they called user stories.

+ +
+

They got compliance, they created user stories. There was no commitment to real change.

+
+ +

The lesson I learned was that top-down change seldom works. You can’t just say, "Okay. CEO, CIO, CFO, CTO said we're gonna do the DevOps", and expect results. . Pauly Comtois from Hearst Media did a great talk how middle managers are instrumental in propagating change.

+ +

Patterns for gaining acceptance

+ +

As an engineer, I'm a fan of patterns - things that are repeatable. I am going to introduce you to some patterns from Linda Rising and Mary Lynn Manns’ book Fearless Change, which I personally, found very useful.

+ +

1. Become an evangelist

+ +

A technology evangelist is a person who builds a critical mass of support for a given technology and then establishes it as a technical standard. If you want to drive a DevOps cultural change, you need to go around to teams and get support from different groups of people. It’s an ongoing process, which means that you are never done.

+ +

2. Tailor your message

+ +

It’s important that you communicate differently depending on who you are talking to. For example, It’s very unlikely that your Chief Financial Officer cares how many times a day you can deploy. It’s very likely that they do care if you can quickly address issues which are blocking your customers from buying your products and services.

+ +

3. Lunch and learn

+ +

Make lunch and learns effective by being creative about the food & the format, making it interactive, having clear takeaways and promote the session. This is another place where you should tailor the message. “Come learn how we’re working to respond faster to security risks” is better than “check out our new deployment tool”.

+ +

4. Leave hints

+ +

Collect things like stickers, flyers, and white papers. Leave them behind where people can pick them up to read them later. People will be curious and might take some to read at their own time if you put a stack of DevOps or state of DevOps reports somewhere in the office. Build the curiosity.

+ +

5. Find innovators to help

+ +

Find people who are identified as early adopters in your organization. These are the people who will be waiting in line for the newest iPhone, or always upgrade their laptop as soon as a new version of the operating system is released. Get them excited, so then they tell their friends and then their friends continue to spread the word. It's really good to get help from innovators as early as possible. Keep in mind that this is useful for building excitement early, but not as a long term strategy. This group will be off chasing the next new thing soon.

+ +

6. Ask for help

+ +

Don't hesitate to ask for help. This could be introductions to other teams, access to software or systems you don’t normally use, or just about anything else. I believe most people really want to be helpful, but they don’t want to seem presumptuous and often won’t offer if not asked.

+ +

7. Say thank you

+ +

Spell it out, something like “I really appreciate that you introduced me to that other team. They knew more about the deployment tools and it saved me a bunch of time”A sincere thank you is more effective than a gift card. Avoid hollow gestures.

+ +

8. Celebrate your little successes

+ +

It’s hard to push an organizational change. There will be lots of challenges. There will be people that don't care. Internally, acknowledge your successes. One of the things that I often speak about is burn out in the technology industry. There's others here that do as well. Not acknowledging when something goes right is a really good way to letting yourself down that road.

+ +

9. Be honest with yourself and seek feedback

+ +

If you do the lunch and learn, if you do the presentation, don’t just see how many people showed up, ask feedback and act on the feedback. If they enjoyed the selection of food but didn’t find the content useful you may need to adjust in the future.

+ +
+ +

Summary

+ +

In this post, I talked about some strategies to drive changes in a way that makes sense to your people and hopefully cleared some misconceptions as well. In our next post, the final one in this series, I will elaborate on some of the actions that one can take to actually propagate change.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption/index.html b/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption/index.html new file mode 100644 index 000000000..a32a0f680 --- /dev/null +++ b/pr-1714/2017/09/05/misconceptions-patterns-devops-adoption/index.html @@ -0,0 +1,277 @@ + + + + + + + + + + + + + + + + Misconceptions and Patterns to drive DevOps Adoption | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 2 - You can’t buy DevOps, but you may need to sell it: Misconceptions and Patterns to drive DevOps Adoption +
+ +
+ + +
+

Part 2 - You can’t buy DevOps, but you may need to sell it: Misconceptions and Patterns to drive DevOps Adoption

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

This is part 2 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. In the previous post, we looked at some industry statistics and anecdotes that can be used to convey the effectiveness of adopting a DevOps culture. While these are important to have and understand, by themselves, they won’t change people radically. To create a lasting impact, you have to drive change in a way that makes sense to individuals.

+ +

In this post, we’ll look at some of the most commonly held misconceptions about driving change. We’ll also explore some patterns that you can use to help gain acceptance of your ideas.

+ +

Common misconceptions

+ +

Before we get to the strategies to implement change, I want to highlight what I see are the most common misconceptions about implementing new ideas. These are highly opinionated, but I will explain why I believe so.

+ +

Ideas are judged 100% on merit

+ +

Those of us that have been in technology for a while know that there are a lot of successful products in the market that might not have been the best idea. Ideas actually aren't judged 100% on merit. If they were, betamax would've beat VHS. Good ideas need to go together with implementation to create a lasting impact. You can not just do a session to introduce it. Implementing change means that there's work to be done and it’s an ongoing process.

+ +

Top down approach is effective for changes

+ +

It’s very common for companies to attempt top-down culture change. A quick web search would turn up many examples of organizations who “went agile” and failed. Quite often a deeper dive reveals that they never actually changed behavior.

+ +

I saw a group several years ago who decided to switch from waterfall to agile methods. They went through fairly extensive training in things like user stories. For those that aren’t familiar, most successful agile organizations use stories as “conversation starters”, not detailed requirements.

+ +

At least one group in this organization took their massive waterfall requirements document, split it on paragraph markers and then proudly presented a spreadsheet with hundreds of smaller pieces of text they called user stories.

+ +
+

They got compliance, they created user stories. There was no commitment to real change.

+
+ +

The lesson I learned was that top-down change seldom works. You can’t just say, "Okay. CEO, CIO, CFO, CTO said we're gonna do the DevOps", and expect results. . Pauly Comtois from Hearst Media did a great talk how middle managers are instrumental in propagating change.

+ +

Patterns for gaining acceptance

+ +

As an engineer, I'm a fan of patterns - things that are repeatable. I am going to introduce you to some patterns from Linda Rising and Mary Lynn Manns’ book Fearless Change, which I personally, found very useful.

+ +

1. Become an evangelist

+ +

A technology evangelist is a person who builds a critical mass of support for a given technology and then establishes it as a technical standard. If you want to drive a DevOps cultural change, you need to go around to teams and get support from different groups of people. It’s an ongoing process, which means that you are never done.

+ +

2. Tailor your message

+ +

It’s important that you communicate differently depending on who you are talking to. For example, It’s very unlikely that your Chief Financial Officer cares how many times a day you can deploy. It’s very likely that they do care if you can quickly address issues which are blocking your customers from buying your products and services.

+ +

3. Lunch and learn

+ +

Make lunch and learns effective by being creative about the food & the format, making it interactive, having clear takeaways and promote the session. This is another place where you should tailor the message. “Come learn how we’re working to respond faster to security risks” is better than “check out our new deployment tool”.

+ +

4. Leave hints

+ +

Collect things like stickers, flyers, and white papers. Leave them behind where people can pick them up to read them later. People will be curious and might take some to read at their own time if you put a stack of DevOps or state of DevOps reports somewhere in the office. Build the curiosity.

+ +

5. Find innovators to help

+ +

Find people who are identified as early adopters in your organization. These are the people who will be waiting in line for the newest iPhone, or always upgrade their laptop as soon as a new version of the operating system is released. Get them excited, so then they tell their friends and then their friends continue to spread the word. It's really good to get help from innovators as early as possible. Keep in mind that this is useful for building excitement early, but not as a long term strategy. This group will be off chasing the next new thing soon.

+ +

6. Ask for help

+ +

Don't hesitate to ask for help. This could be introductions to other teams, access to software or systems you don’t normally use, or just about anything else. I believe most people really want to be helpful, but they don’t want to seem presumptuous and often won’t offer if not asked.

+ +

7. Say thank you

+ +

Spell it out, something like “I really appreciate that you introduced me to that other team. They knew more about the deployment tools and it saved me a bunch of time”A sincere thank you is more effective than a gift card. Avoid hollow gestures.

+ +

8. Celebrate your little successes

+ +

It’s hard to push an organizational change. There will be lots of challenges. There will be people that don't care. Internally, acknowledge your successes. One of the things that I often speak about is burn out in the technology industry. There's others here that do as well. Not acknowledging when something goes right is a really good way to letting yourself down that road.

+ +

9. Be honest with yourself and seek feedback

+ +

If you do the lunch and learn, if you do the presentation, don’t just see how many people showed up, ask feedback and act on the feedback. If they enjoyed the selection of food but didn’t find the content useful you may need to adjust in the future.

+ +
+ +

Summary

+ +

In this post, I talked about some strategies to drive changes in a way that makes sense to your people and hopefully cleared some misconceptions as well. In our next post, the final one in this series, I will elaborate on some of the actions that one can take to actually propagate change.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/12.html b/pr-1714/2017/09/12.html new file mode 100644 index 000000000..913e980be --- /dev/null +++ b/pr-1714/2017/09/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 12 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/12/index.html b/pr-1714/2017/09/12/index.html new file mode 100644 index 000000000..f23ae9fab --- /dev/null +++ b/pr-1714/2017/09/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 12 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/12/value-stream-mapping.html b/pr-1714/2017/09/12/value-stream-mapping.html new file mode 100644 index 000000000..77a65f691 --- /dev/null +++ b/pr-1714/2017/09/12/value-stream-mapping.html @@ -0,0 +1,249 @@ + + + + + + + + + + + + + + + + Getting started with value stream mapping | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 4 - CD101: Getting Started with Value Stream Mapping +
+ +
+ + +
+

Part 4 - CD101: Getting Started with Value Stream Mapping

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is part 4 of our Continuous Delivery 101 video series. In the previous videos, we covered best practices and principles of continuous delivery. In this video, we’ll talk about

+ +
    +
  • Getting started with continuous delivery using ‘value stream mapping’ and
    • +
  • How to create a value stream map
    • +
+ +

Before getting started, it is important to ask yourself if you’re truly ready for continuous delivery. This post helps you ask and answer critical questions about your processes that will show you where you are in your continuous delivery journey.

+ +


+
+ +
+


+ +

Stay tuned for part 5, where we’ll look at some of the tools commonly used for continuous delivery.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/12/value-stream-mapping/index.html b/pr-1714/2017/09/12/value-stream-mapping/index.html new file mode 100644 index 000000000..acf0f8c98 --- /dev/null +++ b/pr-1714/2017/09/12/value-stream-mapping/index.html @@ -0,0 +1,249 @@ + + + + + + + + + + + + + + + + Getting started with value stream mapping | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 4 - CD101: Getting Started with Value Stream Mapping +
+ +
+ + +
+

Part 4 - CD101: Getting Started with Value Stream Mapping

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is part 4 of our Continuous Delivery 101 video series. In the previous videos, we covered best practices and principles of continuous delivery. In this video, we’ll talk about

+ +
    +
  • Getting started with continuous delivery using ‘value stream mapping’ and
    • +
  • How to create a value stream map
    • +
+ +

Before getting started, it is important to ask yourself if you’re truly ready for continuous delivery. This post helps you ask and answer critical questions about your processes that will show you where you are in your continuous delivery journey.

+ +


+
+ +
+


+ +

Stay tuned for part 5, where we’ll look at some of the tools commonly used for continuous delivery.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/19.html b/pr-1714/2017/09/19.html new file mode 100644 index 000000000..8f7d7ec60 --- /dev/null +++ b/pr-1714/2017/09/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 19 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/19/actions-spread-devops-adoption.html b/pr-1714/2017/09/19/actions-spread-devops-adoption.html new file mode 100644 index 000000000..e9bf7838c --- /dev/null +++ b/pr-1714/2017/09/19/actions-spread-devops-adoption.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Actions to spread DevOps Adoption | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - You can’t buy DevOps, but you may need to sell it: Spreading DevOps Adoption +
+ +
+ + +
+

Part 3 - You can’t buy DevOps, but you may need to sell it: Actions to spread DevOps Adoption

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

This is part 3 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. Previously, we looked at some ways to get buy-in on driving DevOps changes. In this post, we will explore some of actions to take to spread change.

+ +

Actions to Spread Change

+ +

At this point, you’ve convinced people to start learning more about DevOps and maybe even driving some change. But how do you go from simply sharing your ideas to getting other involved? Here are a few ways.

+ +

Study Groups

+ +

There may be little or no money for formal training on the specific topic in your organization. But you can try to find other people who are interested in it. Form a small group of colleagues who also want to explore or continue to learn. Consider inviting outsiders. You can get somebody else is in front of your colleagues and talking about their DevOps practice. Sometimes, external validation can be more powerful.

+ +

This is different from “lunch and learns” mentioned previously in that it’s the group learning from each other more than you presenting ideas.

+ +

Internal Events

+ +

There are a lot of public events and conferences where you can go to learn about DevOps. I think these are great places to learn, but they aren’t going to be talking about the specifics of your organization.

+ +

Consider hosting internal events where you're free to talk about your challenges, because somebody else might have overcome them. I like structures with a combination of presentations and interactive sessions that you'll see in public events like DevOpsDays.

+ +

Mentor Teams

+ +

I normally rant against terms like “DevOps Team”. Most of the time this is another new silo or the rebranding of some other existing team.

+ +
+

“In a fit of rage caused by reading yet another email in which one of our customers proposed creating a ‘devops team’ so as to ‘implement’ devops, I tweeted that ‘THERE IS NO SUCH THING AS A DEVOPS TEAM.’” - Jez Humble

+
+ +

A team of mentors who will go out and embed with product teams however is perfectly valid.

+ +

You create a team of people who are further along with DevOps and Continuous Delivery. The individuals from that team spend the vast majority of their time embedded on product teams sharing their knowledge. Developers who have never learned about deployment are paired with people who can help them automate that as part of their normal work.

+ +

The team of mentors still gets together regularly to share their experiences. Once the product teams are up to speed, the mentor can rotate to the next one who needs help.

+ +

Pilot the Change

+ +

When choosing a project to use as a pilot, avoid the temptation to choose something “safe”. You don’t want to put your organization in jeopardy, but the project you choose needs to have enough impact that your success (or failure) can be a catalyst for ongoing organizational change.

+ +

Don't be discouraged

+ +

There is a scientific reason why we repeatedly make and break resolutions. Social science researchers have named this tendency “False Hope Syndrome”: because we believe self-change is easy, we set high expectation that aren’t realistic. In our context, set expectations but make sure they're reasonable expectations. Don't forget the small successes and don't get discouraged.

+ +
+ +

Summary

+ +

In these three posts, we went through some DevOps statistics and industry stories for you get buy-in, misconceptions and strategies to gain acceptance and patterns to drive and spread DevOps adoption. Having working in continuous delivery and DevOps space for several years, I truly understand that it’s really hard. I want to end this series with Robin Sharma’s quote:

+ +
+

All change is hard at first, messy in the middle and so gorgeous at the end. - Robin Sharma

+
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/19/actions-spread-devops-adoption/index.html b/pr-1714/2017/09/19/actions-spread-devops-adoption/index.html new file mode 100644 index 000000000..6e0b26c8f --- /dev/null +++ b/pr-1714/2017/09/19/actions-spread-devops-adoption/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Actions to spread DevOps Adoption | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 3 - You can’t buy DevOps, but you may need to sell it: Spreading DevOps Adoption +
+ +
+ + +
+

Part 3 - You can’t buy DevOps, but you may need to sell it: Actions to spread DevOps Adoption

+

Ken Mugrage

+

+ Selling DevOps +

+
+ +
+ +

This is part 3 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. Previously, we looked at some ways to get buy-in on driving DevOps changes. In this post, we will explore some of actions to take to spread change.

+ +

Actions to Spread Change

+ +

At this point, you’ve convinced people to start learning more about DevOps and maybe even driving some change. But how do you go from simply sharing your ideas to getting other involved? Here are a few ways.

+ +

Study Groups

+ +

There may be little or no money for formal training on the specific topic in your organization. But you can try to find other people who are interested in it. Form a small group of colleagues who also want to explore or continue to learn. Consider inviting outsiders. You can get somebody else is in front of your colleagues and talking about their DevOps practice. Sometimes, external validation can be more powerful.

+ +

This is different from “lunch and learns” mentioned previously in that it’s the group learning from each other more than you presenting ideas.

+ +

Internal Events

+ +

There are a lot of public events and conferences where you can go to learn about DevOps. I think these are great places to learn, but they aren’t going to be talking about the specifics of your organization.

+ +

Consider hosting internal events where you're free to talk about your challenges, because somebody else might have overcome them. I like structures with a combination of presentations and interactive sessions that you'll see in public events like DevOpsDays.

+ +

Mentor Teams

+ +

I normally rant against terms like “DevOps Team”. Most of the time this is another new silo or the rebranding of some other existing team.

+ +
+

“In a fit of rage caused by reading yet another email in which one of our customers proposed creating a ‘devops team’ so as to ‘implement’ devops, I tweeted that ‘THERE IS NO SUCH THING AS A DEVOPS TEAM.’” - Jez Humble

+
+ +

A team of mentors who will go out and embed with product teams however is perfectly valid.

+ +

You create a team of people who are further along with DevOps and Continuous Delivery. The individuals from that team spend the vast majority of their time embedded on product teams sharing their knowledge. Developers who have never learned about deployment are paired with people who can help them automate that as part of their normal work.

+ +

The team of mentors still gets together regularly to share their experiences. Once the product teams are up to speed, the mentor can rotate to the next one who needs help.

+ +

Pilot the Change

+ +

When choosing a project to use as a pilot, avoid the temptation to choose something “safe”. You don’t want to put your organization in jeopardy, but the project you choose needs to have enough impact that your success (or failure) can be a catalyst for ongoing organizational change.

+ +

Don't be discouraged

+ +

There is a scientific reason why we repeatedly make and break resolutions. Social science researchers have named this tendency “False Hope Syndrome”: because we believe self-change is easy, we set high expectation that aren’t realistic. In our context, set expectations but make sure they're reasonable expectations. Don't forget the small successes and don't get discouraged.

+ +
+ +

Summary

+ +

In these three posts, we went through some DevOps statistics and industry stories for you get buy-in, misconceptions and strategies to gain acceptance and patterns to drive and spread DevOps adoption. Having working in continuous delivery and DevOps space for several years, I truly understand that it’s really hard. I want to end this series with Robin Sharma’s quote:

+ +
+

All change is hard at first, messy in the middle and so gorgeous at the end. - Robin Sharma

+
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/19/index.html b/pr-1714/2017/09/19/index.html new file mode 100644 index 000000000..562b7df7b --- /dev/null +++ b/pr-1714/2017/09/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 19 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/26.html b/pr-1714/2017/09/26.html new file mode 100644 index 000000000..328f58ac5 --- /dev/null +++ b/pr-1714/2017/09/26.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic.html b/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic.html new file mode 100644 index 000000000..c64b81ccd --- /dev/null +++ b/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic.html @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery Infographic | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Ready for Continuous Delivery? +
+ +
+ + +
+

Infographic - Are you ready for Continuous Delivery

+

Aravind SV

+

+ Are you ready for Continuous Delivery + Infographic +

+
+ +
+ +

Answer these questions honestly about your own people, teams, and organization to determine your readiness for Continuous Delivery.

+ +
+Are you ready for Continuous Delivery - Infographic +
+ +
+ +

If you’d like more details about these questions, read the full article.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic/index.html b/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic/index.html new file mode 100644 index 000000000..d734f1fd5 --- /dev/null +++ b/pr-1714/2017/09/26/are-you-ready-for-continuous-delivery-infographic/index.html @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery Infographic | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Ready for Continuous Delivery? +
+ +
+ + +
+

Infographic - Are you ready for Continuous Delivery

+

Aravind SV

+

+ Are you ready for Continuous Delivery + Infographic +

+
+ +
+ +

Answer these questions honestly about your own people, teams, and organization to determine your readiness for Continuous Delivery.

+ +
+Are you ready for Continuous Delivery - Infographic +
+ +
+ +

If you’d like more details about these questions, read the full article.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/26/index.html b/pr-1714/2017/09/26/index.html new file mode 100644 index 000000000..f3b66ebdf --- /dev/null +++ b/pr-1714/2017/09/26/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/09/index.html b/pr-1714/2017/09/index.html new file mode 100644 index 000000000..f53f00525 --- /dev/null +++ b/pr-1714/2017/09/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10.html b/pr-1714/2017/10.html new file mode 100644 index 000000000..8fbe5453f --- /dev/null +++ b/pr-1714/2017/10.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/03.html b/pr-1714/2017/10/03.html new file mode 100644 index 000000000..17c5a2ad7 --- /dev/null +++ b/pr-1714/2017/10/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 3 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/03/index.html b/pr-1714/2017/10/03/index.html new file mode 100644 index 000000000..b0af5556d --- /dev/null +++ b/pr-1714/2017/10/03/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 3 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools.html b/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools.html new file mode 100644 index 000000000..8deb6e976 --- /dev/null +++ b/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools.html @@ -0,0 +1,251 @@ + + + + + + + + + + + + + + + + Common Tools for Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 5 - CD101: Common Tools for Continuous Delivery +
+ +
+ + +
+

Part 5 - CD101: Common Tools for Continuous Delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is the final part of our Continuous Delivery 101 video series. In the previous videos, we covered best practices and principles of continuous delivery. In this part, we’ll talk about

+ +
    +
  • Common tools in the continuous delivery space
    • +
  • How not to choose tools for your deployment process
    • +
+ +
+

Choosing your tool is just as important as choosing the right technology stack and any other decisions you make in how you go to market.

+
+ +


+
+ +
+


+ +

That brings us to the end of the CD101 series. If you have any questions or comments regarding our video series, please place them in the comment section below. We would be happy to hear your thoughts.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools/index.html b/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools/index.html new file mode 100644 index 000000000..3acaf9899 --- /dev/null +++ b/pr-1714/2017/10/03/introduction-continuous-delivery-deployment-tools/index.html @@ -0,0 +1,251 @@ + + + + + + + + + + + + + + + + Common Tools for Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Part 5 - CD101: Common Tools for Continuous Delivery +
+ +
+ + +
+

Part 5 - CD101: Common Tools for Continuous Delivery

+

Ken Mugrage

+

+ CD 101 +

+
+ +
+ +

This is the final part of our Continuous Delivery 101 video series. In the previous videos, we covered best practices and principles of continuous delivery. In this part, we’ll talk about

+ +
    +
  • Common tools in the continuous delivery space
    • +
  • How not to choose tools for your deployment process
    • +
+ +
+

Choosing your tool is just as important as choosing the right technology stack and any other decisions you make in how you go to market.

+
+ +


+
+ +
+


+ +

That brings us to the end of the CD101 series. If you have any questions or comments regarding our video series, please place them in the comment section below. We would be happy to hear your thoughts.

+ +
+ +

What is Continuous Delivery 101?

+ +

This is a video series to help you get started on your CD journey. Ken Mugrage, a notable advocate for continuous delivery, will walk you through a collection of 5 short videos. This series will cover the history of CD, basic concepts, best practices, how to get started and popular tools. We will also introduce in-depth readings as we go through these basic concepts with you.

+ +

By the end of the video series, you'll have a holistic view of continuous delivery and a deeper understanding and appreciation of critical concepts.

+ +

Why should you watch it?

+ +

These videos can help you and more specifically, your team, learn to adopt best practices of Continuous Delivery, understand the core concepts of a deployment pipeline, and the history of how Agile and Lean drove these technical practices.

+ +

You can truly benefit out of these videos if you:

+ +
    +
  • are looking to get an overview of continuous delivery for yourself
    • +
  • are championing DevOps transformation in your organization and need a concise 'getting started' guide for your team
    • +
  • think your team are doing continuous delivery but not quite there yet and want to take as step back to refresh the fundamentals
    • +
+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/10.html b/pr-1714/2017/10/10.html new file mode 100644 index 000000000..72b9af9dc --- /dev/null +++ b/pr-1714/2017/10/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/10/architecting-continuous-delivery.html b/pr-1714/2017/10/10/architecting-continuous-delivery.html new file mode 100644 index 000000000..765de1631 --- /dev/null +++ b/pr-1714/2017/10/10/architecting-continuous-delivery.html @@ -0,0 +1,353 @@ + + + + + + + + + + + + + + + + Architecting for Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Architecting for Continuous Delivery +
+ +
+ + +
+

Architecting for Continuous Delivery - Themes in CD Enablement

+

Vishal Naik

+

+

+
+ +
+ +

When you start on the CD journey +, it is tempting to think of it only as “What tools should I use?”.

+ +

While part of it is selecting the right tools +for each aspect like version control, CD server, infrastructure configuration tool, monitoring tool and so on, an effective CD implementation doesn't stop at that. For instance, you might use a particular version control tool and have a particular CI server set-up but if you are not checking in code in small batches frequently, or don't have automated tests, it is not Continuous Integration (it's CI Theatre!).

+ +
+

Continuous Delivery enablement doesn't stop with adopting tools

+
+ +

Remember also that the goal of continuous delivery is to be able to release software frequently, and reliably, in a frictionless manner. So, while you start automating your deployment process, it is also important to identify bottlenecks in the deployment process and streamline it over time.

+ +

3 recurring themes in Continuous Delivery enablement

+ +

In this article I am going to talk about three recurring themes in CD enablement that I have seen in my experience as a developer:

+ +
    +
  • The trouble with monolithic codebases and approaches to break it down
    • +
  • Designing the test suite for optimal feedback
    • +
  • Setting up a deployment pipeline as the backbone of CD
    • +
+ +

Theme 1: The trouble with monoliths and approaches to break it down

+ +

A common recurring challenge on CD is dealing with large monolithic codebases that show the following immediate symptoms:

+ +
    +
  • Sluggish build and application start-up time
    • +
  • Slow feedback loop with large test suites
    • +
+ +

Up to some point, you can attack this problem by parallelizing build tasks and test runs. Build tools like Gradle, Rake, and others, support parallel task capabilities that we can take advantage of. Additionally, tools including GoCD support test parallelism with multiple agents.

+ +

But for teams working on a monolithic codebase, this is usually not enough. Apart from the aforementioned problems, a large codebase can be difficult to work with and intimidating to new members on the team. When multiple functional teams work on the same codebase, there tends to be less ownership of the code, multiple implementation patterns begin emerging, and it's more difficult to get consensus. Technical debt accumulates and can easily spiral out of control.

+ +

A large team working on a monolithic codebase also compounds problems on the continuous integration front. Many teams in this situation find that their build times increase to dangerous lengths. At some point the build is slow enough that developers think twice about running the full test suite locally before checking in. With so many people checking in changes at the same time, the feedback cycle slows down. This, in turn, makes it tricky to diagnose build failures. Broken builds get left for someone else to fix, like dirty dishes in a sink waiting for someone to clean them.

+ +

A large monolithic app can also be a significant overhead on your deployment throughput. Cycle times are longer because of the slower builds and automated and manual tests required to validate the entire app. This creates a lot of friction in the pipeline. In short, with a monolith, it becomes increasingly hard to manage technical debt, encourage good engineering practices, and deploy.

+ +

We can address the issues with the monolith by decomposing the codebase into smaller components such as libraries or services.

+ +

Componentization via Libraries

+ +

For a start, shared components (like a pagination UI component or a library to make database or API calls) can be extracted out and added as binary dependencies on the application.

+ +

But when there are multiple functional teams working on the same repo, the biggest payoff comes when you can separate out each team's work into components to be managed in their own repos.

+ +

One large-scale Open Source project doing this is the OpenMRS application where independent modules are wired up together in the application runtime. A component in this case is a binary dependency that includes end-to-end functionality of a module including the UI. Deployment of a component can be managed on the deployment pipeline and means upgrading the component version on the parent application.

+ +

On one of our projects where we saw the pains of a large team working on a monolithic content management system (CMS) codebase in Java, we started to break out components under active development into separate repos. For example, the search functionality was separated out. Then, everything related to search - from UI to backend code - could be developed on a much smaller codebase. The binary artifact, in this case a JAR file, could then be plugged in as a runtime dependency on the application. We then had a small test suite on the main application build pipeline to validate that the component worked well within the application boundaries.

+ +

Separating out the component enabled the Search feature team to focus on their parts of the code. In addition, the test suite on the new repo was smaller and directly related to what the team was working on, so as a result there was better ownership of the code and better management of technical debt. Furthermore, the savings on the short feedback loop for both application development and on CI were enormous.

+ +

Componentization via Services

+ +

Depending on the situation, breaking down the monolith app into a composition of smaller runtime services can provide enormous leverage in terms of the autonomy it affords to the team given that apart from service boundary or API, everything else is completely decoupled from each other. A standalone service can be deployed independently and scaled appropriately based on its requirements. The Building Microservices book by Sam Newman is an excellent read on the subject.

+ +

But of course, microservices are not a free lunch and your team or organization needs to be tall enough to use them effectively. When used appropriately, the microservice approach can help drastically reduce cycle times and simplify the deployment pipeline.

+ +

However, by either approach, componentization can be a multi-month effort with no quick wins. In addition, the separation boundaries between components need to be thought through before implementation. But that said, the payoffs in terms of CD impact will more than make up for the time spent setting it up.

+ +

Theme 2: Prune the test suite for optimal feedback

+ +

When you start on a greenfield project, automated GUI tests or acceptance tests seem small and manageable and it is tempting to add as much coverage on that layer as possible. But unless tended to, these tests grow become unmanageable over time.

+ +

The ice cream cone anti-pattern for test suites is well described by Alister B Scott's Testing Pyramids (since offline).

+ +
+

"Tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run." - Martin Fowler

+
+ +

Indeed, teams that are saddled with a large number of acceptance tests end up getting slowed down by the very automation that was supposed to make the application delivery process easier and faster – tests taking many hours to run and producing random failures in the end. Acceptance tests also tend to be brittle and because they are harder to reproduce and fix; these tend to accumulate over time. In many instances, the quality starts being gauged in terms of the percentage of passed tests. “85 percentage pass. Not bad compared to previous run!” This doesn't say anything about the quality of the application.

+ +

Therefore, it is advisable to design your test suite to give just the necessary validation with acceptance tests and everything else covered by unit tests and a smaller layer of integration tests. Unit tests are fast to execute, give the right level of feedback about what is broken. As you go up the pyramid, the tests are slower and it becomes harder to point out root cause of failures because the surface area is larger.

+ +
+Ice cream cone test ani-pattern +Click image to zoom in +
+ +

On a recent project - a single page application on AngularJS talking to a backend API - we knew we had to test the UI layer because there was a lot of conditional logic, formatting, etc., embedded within the UI on AngularJS view templates. But instead of settling with a heavyweight Selenium or a Protractor test suite that would have been prohibitive given the number of test cases we had, a team member developed a tool called Duck-Angular which could validate AngularJS rendered DOM and simulate DOM interactions using JS tests in-memory.

+ +

With that tool, we could write as many UI validation tests as needed as unit tests. In the end, we had comprehensive coverage, with more than 1000 tests that ran in a few seconds. You can read more about why we love Duck-Angular.

+ +

Another project had hundreds of functional tests which were so slow and flaky that they were ignored. We were able to dedicate a couple of weeks as a team exclusively towards replacing acceptance tests with unit and integration level tests and that effort set the impetus to prune the test suite to the desired state.

+ +

Theme 3: The deployment pipeline as the backbone for effective continuous delivery

+ +

The deployment pipeline concept in CD is a huge step change in the the way we build and release software.

+ +
+

Continuous integration is essential but not sufficient for an effective application delivery workflow

+
+ +

Automating the deployment procedure is the first step and most CI tools like Jenkins or TeamCity do a good job of providing that capability. For example, you can set up build configurations for each phase - say a build phase or a unit test phase, acceptance tests - and also automate deployments to each environment.

+ +

While this is certainly useful, the trouble is that it is very difficult to answer the question:

+ +
+

Do we have confidence to release this version of software to Production?

+
+ +

Because deployment process is spread across disconnected build configurations, it is difficult to visualize the entire production flow process and this additionally ends up hiding inefficiencies in the process.

+ +

This is where the deployment pipeline helps.

+ +
+

A deployment pipeline is, in essence, an automated implementation of your application’s build, deploy, test, and release process. Every organization will have differences in the implementation of their deployment pipelines, depending on their value-stream for releasing software, but the principles that govern them do not vary.

+
+ +

The Deployment Pipeline

+ +

(Source - The Continuous Delivery book)

+ +

I am constantly amazed by how much this idea of the pipeline is similar and inspired from non-software manufacturing workflows like Lean manufacturing.

+ +

In his book High Output Management, Andy Grove talks about modeling the production process and constantly optimizing the steps to achieve better throughput.

+ +
+

Automation is certainly one way to improve the leverage of all types of work. Having machines to help them, human beings can create more output. But in both manufacturing and administrative work, something else can also increase the productivity of the black box. This is called work simplification. To get leverage this way, you first need to create a flow chart of the production process as it exists. Every single step must be shown on it; no step should be omitted in order to pretty things up on paper.

+
+ +

The deployment pipeline in essence represents a flow chart of your production process and enables you to automate and visualize your deployment process from source repo all the way to Production. Each step of your build and deployment process can be modeled into the pipeline to provide high resolution visibility into your deployment workflow.

+ +

Below is the view of a simple pipeline in GoCD

+ +
+GoCD Pipeline +Click image to zoom in +
+ +

Each commit goes through a series of stages that lead all the way to Production. With each passing stage, you get higher confidence with that revision of the code. If something fails, the pipeline stops and you have to fix the build OR revert the commit that caused the failure. If the deploy to Production fails, you can rollback by triggering the last successful stage that deployed to Production.

+ +
+Rolling back +Click image to zoom in +
+ +

With this level of visibility, you can not only determine whether the application is releasable any point, but also identify the bottlenecks in your process and set yourself in a position to continuously improve the process over time.

+ +

The pipeline abstraction can also support complex build and deploy configurations including component dependencies. The deployment pipeline can also easily support requirements like integration testing microservice dependencies and has the flexibility to support best practices like trunk-based development.

+ +
+ +

Summary

+ +

Continuous Delivery is not just about automating deployments. The goal is to be able to release software reliably and without friction. Architectural choices play a huge role in achieving that state. Adopting the deployment pipeline to model your entire process can provide the visibility required to address gaps sooner rather than later.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/10/architecting-continuous-delivery/index.html b/pr-1714/2017/10/10/architecting-continuous-delivery/index.html new file mode 100644 index 000000000..225133b2d --- /dev/null +++ b/pr-1714/2017/10/10/architecting-continuous-delivery/index.html @@ -0,0 +1,353 @@ + + + + + + + + + + + + + + + + Architecting for Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Architecting for Continuous Delivery +
+ +
+ + +
+

Architecting for Continuous Delivery - Themes in CD Enablement

+

Vishal Naik

+

+

+
+ +
+ +

When you start on the CD journey +, it is tempting to think of it only as “What tools should I use?”.

+ +

While part of it is selecting the right tools +for each aspect like version control, CD server, infrastructure configuration tool, monitoring tool and so on, an effective CD implementation doesn't stop at that. For instance, you might use a particular version control tool and have a particular CI server set-up but if you are not checking in code in small batches frequently, or don't have automated tests, it is not Continuous Integration (it's CI Theatre!).

+ +
+

Continuous Delivery enablement doesn't stop with adopting tools

+
+ +

Remember also that the goal of continuous delivery is to be able to release software frequently, and reliably, in a frictionless manner. So, while you start automating your deployment process, it is also important to identify bottlenecks in the deployment process and streamline it over time.

+ +

3 recurring themes in Continuous Delivery enablement

+ +

In this article I am going to talk about three recurring themes in CD enablement that I have seen in my experience as a developer:

+ +
    +
  • The trouble with monolithic codebases and approaches to break it down
    • +
  • Designing the test suite for optimal feedback
    • +
  • Setting up a deployment pipeline as the backbone of CD
    • +
+ +

Theme 1: The trouble with monoliths and approaches to break it down

+ +

A common recurring challenge on CD is dealing with large monolithic codebases that show the following immediate symptoms:

+ +
    +
  • Sluggish build and application start-up time
    • +
  • Slow feedback loop with large test suites
    • +
+ +

Up to some point, you can attack this problem by parallelizing build tasks and test runs. Build tools like Gradle, Rake, and others, support parallel task capabilities that we can take advantage of. Additionally, tools including GoCD support test parallelism with multiple agents.

+ +

But for teams working on a monolithic codebase, this is usually not enough. Apart from the aforementioned problems, a large codebase can be difficult to work with and intimidating to new members on the team. When multiple functional teams work on the same codebase, there tends to be less ownership of the code, multiple implementation patterns begin emerging, and it's more difficult to get consensus. Technical debt accumulates and can easily spiral out of control.

+ +

A large team working on a monolithic codebase also compounds problems on the continuous integration front. Many teams in this situation find that their build times increase to dangerous lengths. At some point the build is slow enough that developers think twice about running the full test suite locally before checking in. With so many people checking in changes at the same time, the feedback cycle slows down. This, in turn, makes it tricky to diagnose build failures. Broken builds get left for someone else to fix, like dirty dishes in a sink waiting for someone to clean them.

+ +

A large monolithic app can also be a significant overhead on your deployment throughput. Cycle times are longer because of the slower builds and automated and manual tests required to validate the entire app. This creates a lot of friction in the pipeline. In short, with a monolith, it becomes increasingly hard to manage technical debt, encourage good engineering practices, and deploy.

+ +

We can address the issues with the monolith by decomposing the codebase into smaller components such as libraries or services.

+ +

Componentization via Libraries

+ +

For a start, shared components (like a pagination UI component or a library to make database or API calls) can be extracted out and added as binary dependencies on the application.

+ +

But when there are multiple functional teams working on the same repo, the biggest payoff comes when you can separate out each team's work into components to be managed in their own repos.

+ +

One large-scale Open Source project doing this is the OpenMRS application where independent modules are wired up together in the application runtime. A component in this case is a binary dependency that includes end-to-end functionality of a module including the UI. Deployment of a component can be managed on the deployment pipeline and means upgrading the component version on the parent application.

+ +

On one of our projects where we saw the pains of a large team working on a monolithic content management system (CMS) codebase in Java, we started to break out components under active development into separate repos. For example, the search functionality was separated out. Then, everything related to search - from UI to backend code - could be developed on a much smaller codebase. The binary artifact, in this case a JAR file, could then be plugged in as a runtime dependency on the application. We then had a small test suite on the main application build pipeline to validate that the component worked well within the application boundaries.

+ +

Separating out the component enabled the Search feature team to focus on their parts of the code. In addition, the test suite on the new repo was smaller and directly related to what the team was working on, so as a result there was better ownership of the code and better management of technical debt. Furthermore, the savings on the short feedback loop for both application development and on CI were enormous.

+ +

Componentization via Services

+ +

Depending on the situation, breaking down the monolith app into a composition of smaller runtime services can provide enormous leverage in terms of the autonomy it affords to the team given that apart from service boundary or API, everything else is completely decoupled from each other. A standalone service can be deployed independently and scaled appropriately based on its requirements. The Building Microservices book by Sam Newman is an excellent read on the subject.

+ +

But of course, microservices are not a free lunch and your team or organization needs to be tall enough to use them effectively. When used appropriately, the microservice approach can help drastically reduce cycle times and simplify the deployment pipeline.

+ +

However, by either approach, componentization can be a multi-month effort with no quick wins. In addition, the separation boundaries between components need to be thought through before implementation. But that said, the payoffs in terms of CD impact will more than make up for the time spent setting it up.

+ +

Theme 2: Prune the test suite for optimal feedback

+ +

When you start on a greenfield project, automated GUI tests or acceptance tests seem small and manageable and it is tempting to add as much coverage on that layer as possible. But unless tended to, these tests grow become unmanageable over time.

+ +

The ice cream cone anti-pattern for test suites is well described by Alister B Scott's Testing Pyramids (since offline).

+ +
+

"Tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run." - Martin Fowler

+
+ +

Indeed, teams that are saddled with a large number of acceptance tests end up getting slowed down by the very automation that was supposed to make the application delivery process easier and faster – tests taking many hours to run and producing random failures in the end. Acceptance tests also tend to be brittle and because they are harder to reproduce and fix; these tend to accumulate over time. In many instances, the quality starts being gauged in terms of the percentage of passed tests. “85 percentage pass. Not bad compared to previous run!” This doesn't say anything about the quality of the application.

+ +

Therefore, it is advisable to design your test suite to give just the necessary validation with acceptance tests and everything else covered by unit tests and a smaller layer of integration tests. Unit tests are fast to execute, give the right level of feedback about what is broken. As you go up the pyramid, the tests are slower and it becomes harder to point out root cause of failures because the surface area is larger.

+ +
+Ice cream cone test ani-pattern +Click image to zoom in +
+ +

On a recent project - a single page application on AngularJS talking to a backend API - we knew we had to test the UI layer because there was a lot of conditional logic, formatting, etc., embedded within the UI on AngularJS view templates. But instead of settling with a heavyweight Selenium or a Protractor test suite that would have been prohibitive given the number of test cases we had, a team member developed a tool called Duck-Angular which could validate AngularJS rendered DOM and simulate DOM interactions using JS tests in-memory.

+ +

With that tool, we could write as many UI validation tests as needed as unit tests. In the end, we had comprehensive coverage, with more than 1000 tests that ran in a few seconds. You can read more about why we love Duck-Angular.

+ +

Another project had hundreds of functional tests which were so slow and flaky that they were ignored. We were able to dedicate a couple of weeks as a team exclusively towards replacing acceptance tests with unit and integration level tests and that effort set the impetus to prune the test suite to the desired state.

+ +

Theme 3: The deployment pipeline as the backbone for effective continuous delivery

+ +

The deployment pipeline concept in CD is a huge step change in the the way we build and release software.

+ +
+

Continuous integration is essential but not sufficient for an effective application delivery workflow

+
+ +

Automating the deployment procedure is the first step and most CI tools like Jenkins or TeamCity do a good job of providing that capability. For example, you can set up build configurations for each phase - say a build phase or a unit test phase, acceptance tests - and also automate deployments to each environment.

+ +

While this is certainly useful, the trouble is that it is very difficult to answer the question:

+ +
+

Do we have confidence to release this version of software to Production?

+
+ +

Because deployment process is spread across disconnected build configurations, it is difficult to visualize the entire production flow process and this additionally ends up hiding inefficiencies in the process.

+ +

This is where the deployment pipeline helps.

+ +
+

A deployment pipeline is, in essence, an automated implementation of your application’s build, deploy, test, and release process. Every organization will have differences in the implementation of their deployment pipelines, depending on their value-stream for releasing software, but the principles that govern them do not vary.

+
+ +

The Deployment Pipeline

+ +

(Source - The Continuous Delivery book)

+ +

I am constantly amazed by how much this idea of the pipeline is similar and inspired from non-software manufacturing workflows like Lean manufacturing.

+ +

In his book High Output Management, Andy Grove talks about modeling the production process and constantly optimizing the steps to achieve better throughput.

+ +
+

Automation is certainly one way to improve the leverage of all types of work. Having machines to help them, human beings can create more output. But in both manufacturing and administrative work, something else can also increase the productivity of the black box. This is called work simplification. To get leverage this way, you first need to create a flow chart of the production process as it exists. Every single step must be shown on it; no step should be omitted in order to pretty things up on paper.

+
+ +

The deployment pipeline in essence represents a flow chart of your production process and enables you to automate and visualize your deployment process from source repo all the way to Production. Each step of your build and deployment process can be modeled into the pipeline to provide high resolution visibility into your deployment workflow.

+ +

Below is the view of a simple pipeline in GoCD

+ +
+GoCD Pipeline +Click image to zoom in +
+ +

Each commit goes through a series of stages that lead all the way to Production. With each passing stage, you get higher confidence with that revision of the code. If something fails, the pipeline stops and you have to fix the build OR revert the commit that caused the failure. If the deploy to Production fails, you can rollback by triggering the last successful stage that deployed to Production.

+ +
+Rolling back +Click image to zoom in +
+ +

With this level of visibility, you can not only determine whether the application is releasable any point, but also identify the bottlenecks in your process and set yourself in a position to continuously improve the process over time.

+ +

The pipeline abstraction can also support complex build and deploy configurations including component dependencies. The deployment pipeline can also easily support requirements like integration testing microservice dependencies and has the flexibility to support best practices like trunk-based development.

+ +
+ +

Summary

+ +

Continuous Delivery is not just about automating deployments. The goal is to be able to release software reliably and without friction. Architectural choices play a huge role in achieving that state. Adopting the deployment pipeline to model your entire process can provide the visibility required to address gaps sooner rather than later.

+ +

This article was first published on the SnapCI Blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/10/index.html b/pr-1714/2017/10/10/index.html new file mode 100644 index 000000000..184ba3998 --- /dev/null +++ b/pr-1714/2017/10/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/17.html b/pr-1714/2017/10/17.html new file mode 100644 index 000000000..5e04c6075 --- /dev/null +++ b/pr-1714/2017/10/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic.html b/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic.html new file mode 100644 index 000000000..1d9cb25ed --- /dev/null +++ b/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic.html @@ -0,0 +1,210 @@ + + + + + + + + + + + + + + + + Continuous Delivery vs Continuous Deployment Infographic | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ The difference between Continuous Delivery and Continuous Deployment +
+ +
+ + +
+

Infographic - What's the difference between Continuous Delivery and Continuous Deployment?

+

Louda Peña

+

+ Infographic +

+
+ +
+ +

There are quite a few terms thrown around the Continuous Delivery arena: Continuous Integration, Continuous Delivery, Continuous Deployment, CD, CI, and so on and so forth. It's easy to get confused. The two terms we see (erroneously) equated most frequently are Continuous Delivery and Continuous Deployment. Below is the easy infographic we designed to help people understand the differences between the two practices.

+ +
+The difference between Continuous Delivery and Continuous Deployment - Infographic +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/index.html b/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/index.html new file mode 100644 index 000000000..f66c3ad99 --- /dev/null +++ b/pr-1714/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/index.html @@ -0,0 +1,210 @@ + + + + + + + + + + + + + + + + Continuous Delivery vs Continuous Deployment Infographic | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ The difference between Continuous Delivery and Continuous Deployment +
+ +
+ + +
+

Infographic - What's the difference between Continuous Delivery and Continuous Deployment?

+

Louda Peña

+

+ Infographic +

+
+ +
+ +

There are quite a few terms thrown around the Continuous Delivery arena: Continuous Integration, Continuous Delivery, Continuous Deployment, CD, CI, and so on and so forth. It's easy to get confused. The two terms we see (erroneously) equated most frequently are Continuous Delivery and Continuous Deployment. Below is the easy infographic we designed to help people understand the differences between the two practices.

+ +
+The difference between Continuous Delivery and Continuous Deployment - Infographic +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/17/index.html b/pr-1714/2017/10/17/index.html new file mode 100644 index 000000000..7464beb2b --- /dev/null +++ b/pr-1714/2017/10/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/31.html b/pr-1714/2017/10/31.html new file mode 100644 index 000000000..ca6e72894 --- /dev/null +++ b/pr-1714/2017/10/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/31/index.html b/pr-1714/2017/10/31/index.html new file mode 100644 index 000000000..1006fb211 --- /dev/null +++ b/pr-1714/2017/10/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd.html b/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd.html new file mode 100644 index 000000000..c8fdfbe3c --- /dev/null +++ b/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd.html @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + Continuous Delivery for Mobile Development | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Challenges in deploying a mobile app +
+ +
+ + +
+

Our learnings from Continuous Delivery for Mobile Development

+

Sanchit Bahal

+

+

+
+ +
+ +

As a Technical Principal, I had the opportunity to work with one of the largest US airlines to build their consumer facing mobile application. My role was to ensure that the application was technically sound and remove any roadblocks for the team. During my stint on the project, one of our challenges was to help the entire team adopt continuous delivery. We had a team of approximately 80 people distributed over three locations. This post chronicles our journey to continuous delivery, the challenges along the way, and how we overcame them.

+ +

How we overcame challenges on the road to Continuous Delivery

+ +

1. Creating a robust build infrastructure

+ +

One of the most critical success factors for any large distributed team is developer productivity. And having a robust and stable build infrastructure is key. The build infrastructure needs of a mobile project are very unique and working with emulators/simulators was difficult compared to working with web browsers.

+ +

We used to run simulations of tests on different environments, the primary among them being Mac OS (for the iOS app). At first, we provisioned these machines manually. This process not only took over two days but also left us a lot of configuration drift in the build agents. We ended up with poor utilization of our hardware, long waiting time for build (as long as 1.5 days) and significant loss of productivity in managing infrastructure.

+ +

To mitigate this, we decided to completely automate the provisioning of our build agents using Ansible. We also created a pre-baked machine image by running our automated provisioning scripts over a vanilla Mac OS installation. We called this our “golden image”. At any time, if a build agent failed due to accidental configuration drift, we just restored the 'golden image' on that agent. We also introduced the concept of 'homogeneous' build agents. This enabled all build agents to run all build types (Android/iOS).

+ +
+

All these helped reduce our machine provisioning time drastically - from two days to less than 30 minutes.

+
+ +

2. Making test failures more visible

+ +

When we started, we had inherited a monolithic application. Over time, with more and more functionality getting added to the application, our functional regression suite became extremely difficult to work with. There was a single pipeline per platform (Android/iOS), and it always used to be red. It was extremely tedious to figure out which part of the application was broken. Our goal here became to make the test failures more visible, and help identify which parts of the application need our attention. To this end, we broke down the single regression test suite pipeline into multiple functional pipelines. This also helped us maintain our regression test suite in a green state.

+ +

Breaking down monolith tests

+ +

3. Ensuring that every commit leaves the pipeline in a ‘releasable’ state

+ +

Initially, the team were doing feature branches, which caused a lot of strain. Every time we merged a feature branch, it took a lot of effort and would halt everyone for a day or two before things went back to schedule. What made it more tricky, was that we used to run CI only on our master and not on the feature branches. A branch where the code was getting pushed almost daily generally lived three to four months without continuous integration. People were doing their due diligence to make sure they'd merge master back into the feature branch to keep the code up to date, but that was never enough. We had (at one point) eight feature teams in multiple locations; it was inevitable that people would cross paths.

+ +

Another deeper problem caused by long-lived feature branches was that our team started becoming hesitant to do any re-factoring. When you know that the merge is going to be very difficult, people used to shy away from re-factoring even knowing that things are in bad shape. That meant that a huge amount of technical debt started accumulating.

+ +

We started focussing on ensuring that every commit left the pipeline in a releasable state. We approached this goal in two ways, by:

+ +
    +
  • building adequate tests into our CD Pipeline and
    • +
  • developing code keeping in mind CI/CD practices.
    • +
+ +

Here’s a quick view of what our CD pipeline looked like by the end.

+ +

CD pipeline

+ +

We had a combination of unit tests, integration tests, smoke tests, and regression tests (visual and functional) to make sure that each commit was ready to be deployed.

+ +

Along with this, we also educated our team to

+ +
    +
  • choose feature toggles over feature branches,
    • +
  • commit regularly to master and
    • +
  • rely on continuous integration tests.
    • +
+ +

After adopting these practices, some of these challenges just went away. Now, we see that the level of confidence that the developers have when pushing any piece of code is very high.

+ +

4. Introducing quality as part of the deployment pipeline

+ +

In most typical setups, code quality is monitored outside of the deployment pipeline. One of the steps we took to ensure continuous delivery was making sure that code quality is part of the build pipeline. Rather than having it to be a dashboard that just worked independently of our pipeline, we integrated our build pipeline with the SonarQube Server. This allowed us to be able to run quality checks on every commit as part of the build process.

+ +

SonarQube Builds

+ +

Apart from this, we also added strong quality gates. So if there was a failure in SonarQube, we failed the particular build as well. This helped bring the focus of the team on quality of the code. If the code quality failed at any stage, it meant that the build was a failure, and the team sought to fix that with the same urgency as any other failure.

+ +

5. Taking advantage of a good continuous delivery tool

+ +

Customization and the ability to orchestrate

+ +

Before we could start leveraging our CD tool, we had to make sure that we were able to automate and continuously integrate. A CD tool can only take you so far. That said, we found the pipelines in GoCD really powerful as a first class concept. Once we got the concepts of pipelines, stages, jobs, etc. we used GoCD to our advantage to build custom workflows and were able to define what CI/CD looked like for us.

+ +

Traceability

+ +

Picking a tool that gives advanced traceability can save you a lot of time and agony. Recently, there was an issue that required us to make a hotfix. Due to an error, the wrong git material was picked for the release pipeline. This resulted in the wrong artifact being produced and so there were random failures all over. It’s not uncommon for these types of incidents to happen in projects, and without a tool that offers traceability, it would take a lot of effort to troubleshoot.

+ +

The impact of these changes

+ +
+

Honestly, the best thing after adopting continuous delivery is that we move much faster than before and with confidence.

+
+ +

Some measurable changes that we saw were:

+ +
    +
  • The machine provisioning time reduced from two days to less than 30 minutes.
    • +
  • The build waiting time reduced from 6 hours to less than 10 seconds.
    • +
+ +

What’s impactful is that less waiting means developers can focus without wasteful interruption. We have a big boost on team productivity. A positive change that we cannot really quantify was the effect on our culture! Our team became proactive about re-factoring and tackling tech-debt. Continuous integration and automation became the new normal.

+ +

Beyond Continuous Delivery

+ +

After these improvements, we wanted to go a bit further and find ways to improve our delivery process. We felt the need to have continuous monitoring or continuous feedback to keep understanding what needs to be fixed in our deployment cycle. This is a place that I felt that tools like GoCD need to evolve. The idea was to get some reporting and actionable insights into our deployment cycle so we as a team can make changes as we go. Eventually, we built a custom analytics module suited for our application that we could draw insights from.

+ +

Monitoring Insights

+ +
+ +

At its core, continuous delivery is a journey. In my experience, it was adopting a balance of all of these practices that helped us get closer to our goals for deployment. I don’t think we could have achieved the same measure of success with the same velocity had we only chosen to focus on one or two practices. From where we started, the benefits we experienced using CD practices have been immeasurable. It can be a challenge in the beginning, but if you stick by it, it hugely improves not just the quality of code that gets delivered but the quality of the team as well.

+ +

Sanchit Bahal is a Lead Technical Consultant with Thoughtworks and has over 14 years of experience in building complex enterprise applications. He loves using devops practices and principles to build high performing delivery teams.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd/index.html b/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd/index.html new file mode 100644 index 000000000..e90ede0d3 --- /dev/null +++ b/pr-1714/2017/10/31/mobile-app-continuous-delivery-gocd/index.html @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + Continuous Delivery for Mobile Development | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Challenges in deploying a mobile app +
+ +
+ + +
+

Our learnings from Continuous Delivery for Mobile Development

+

Sanchit Bahal

+

+

+
+ +
+ +

As a Technical Principal, I had the opportunity to work with one of the largest US airlines to build their consumer facing mobile application. My role was to ensure that the application was technically sound and remove any roadblocks for the team. During my stint on the project, one of our challenges was to help the entire team adopt continuous delivery. We had a team of approximately 80 people distributed over three locations. This post chronicles our journey to continuous delivery, the challenges along the way, and how we overcame them.

+ +

How we overcame challenges on the road to Continuous Delivery

+ +

1. Creating a robust build infrastructure

+ +

One of the most critical success factors for any large distributed team is developer productivity. And having a robust and stable build infrastructure is key. The build infrastructure needs of a mobile project are very unique and working with emulators/simulators was difficult compared to working with web browsers.

+ +

We used to run simulations of tests on different environments, the primary among them being Mac OS (for the iOS app). At first, we provisioned these machines manually. This process not only took over two days but also left us a lot of configuration drift in the build agents. We ended up with poor utilization of our hardware, long waiting time for build (as long as 1.5 days) and significant loss of productivity in managing infrastructure.

+ +

To mitigate this, we decided to completely automate the provisioning of our build agents using Ansible. We also created a pre-baked machine image by running our automated provisioning scripts over a vanilla Mac OS installation. We called this our “golden image”. At any time, if a build agent failed due to accidental configuration drift, we just restored the 'golden image' on that agent. We also introduced the concept of 'homogeneous' build agents. This enabled all build agents to run all build types (Android/iOS).

+ +
+

All these helped reduce our machine provisioning time drastically - from two days to less than 30 minutes.

+
+ +

2. Making test failures more visible

+ +

When we started, we had inherited a monolithic application. Over time, with more and more functionality getting added to the application, our functional regression suite became extremely difficult to work with. There was a single pipeline per platform (Android/iOS), and it always used to be red. It was extremely tedious to figure out which part of the application was broken. Our goal here became to make the test failures more visible, and help identify which parts of the application need our attention. To this end, we broke down the single regression test suite pipeline into multiple functional pipelines. This also helped us maintain our regression test suite in a green state.

+ +

Breaking down monolith tests

+ +

3. Ensuring that every commit leaves the pipeline in a ‘releasable’ state

+ +

Initially, the team were doing feature branches, which caused a lot of strain. Every time we merged a feature branch, it took a lot of effort and would halt everyone for a day or two before things went back to schedule. What made it more tricky, was that we used to run CI only on our master and not on the feature branches. A branch where the code was getting pushed almost daily generally lived three to four months without continuous integration. People were doing their due diligence to make sure they'd merge master back into the feature branch to keep the code up to date, but that was never enough. We had (at one point) eight feature teams in multiple locations; it was inevitable that people would cross paths.

+ +

Another deeper problem caused by long-lived feature branches was that our team started becoming hesitant to do any re-factoring. When you know that the merge is going to be very difficult, people used to shy away from re-factoring even knowing that things are in bad shape. That meant that a huge amount of technical debt started accumulating.

+ +

We started focussing on ensuring that every commit left the pipeline in a releasable state. We approached this goal in two ways, by:

+ +
    +
  • building adequate tests into our CD Pipeline and
    • +
  • developing code keeping in mind CI/CD practices.
    • +
+ +

Here’s a quick view of what our CD pipeline looked like by the end.

+ +

CD pipeline

+ +

We had a combination of unit tests, integration tests, smoke tests, and regression tests (visual and functional) to make sure that each commit was ready to be deployed.

+ +

Along with this, we also educated our team to

+ +
    +
  • choose feature toggles over feature branches,
    • +
  • commit regularly to master and
    • +
  • rely on continuous integration tests.
    • +
+ +

After adopting these practices, some of these challenges just went away. Now, we see that the level of confidence that the developers have when pushing any piece of code is very high.

+ +

4. Introducing quality as part of the deployment pipeline

+ +

In most typical setups, code quality is monitored outside of the deployment pipeline. One of the steps we took to ensure continuous delivery was making sure that code quality is part of the build pipeline. Rather than having it to be a dashboard that just worked independently of our pipeline, we integrated our build pipeline with the SonarQube Server. This allowed us to be able to run quality checks on every commit as part of the build process.

+ +

SonarQube Builds

+ +

Apart from this, we also added strong quality gates. So if there was a failure in SonarQube, we failed the particular build as well. This helped bring the focus of the team on quality of the code. If the code quality failed at any stage, it meant that the build was a failure, and the team sought to fix that with the same urgency as any other failure.

+ +

5. Taking advantage of a good continuous delivery tool

+ +

Customization and the ability to orchestrate

+ +

Before we could start leveraging our CD tool, we had to make sure that we were able to automate and continuously integrate. A CD tool can only take you so far. That said, we found the pipelines in GoCD really powerful as a first class concept. Once we got the concepts of pipelines, stages, jobs, etc. we used GoCD to our advantage to build custom workflows and were able to define what CI/CD looked like for us.

+ +

Traceability

+ +

Picking a tool that gives advanced traceability can save you a lot of time and agony. Recently, there was an issue that required us to make a hotfix. Due to an error, the wrong git material was picked for the release pipeline. This resulted in the wrong artifact being produced and so there were random failures all over. It’s not uncommon for these types of incidents to happen in projects, and without a tool that offers traceability, it would take a lot of effort to troubleshoot.

+ +

The impact of these changes

+ +
+

Honestly, the best thing after adopting continuous delivery is that we move much faster than before and with confidence.

+
+ +

Some measurable changes that we saw were:

+ +
    +
  • The machine provisioning time reduced from two days to less than 30 minutes.
    • +
  • The build waiting time reduced from 6 hours to less than 10 seconds.
    • +
+ +

What’s impactful is that less waiting means developers can focus without wasteful interruption. We have a big boost on team productivity. A positive change that we cannot really quantify was the effect on our culture! Our team became proactive about re-factoring and tackling tech-debt. Continuous integration and automation became the new normal.

+ +

Beyond Continuous Delivery

+ +

After these improvements, we wanted to go a bit further and find ways to improve our delivery process. We felt the need to have continuous monitoring or continuous feedback to keep understanding what needs to be fixed in our deployment cycle. This is a place that I felt that tools like GoCD need to evolve. The idea was to get some reporting and actionable insights into our deployment cycle so we as a team can make changes as we go. Eventually, we built a custom analytics module suited for our application that we could draw insights from.

+ +

Monitoring Insights

+ +
+ +

At its core, continuous delivery is a journey. In my experience, it was adopting a balance of all of these practices that helped us get closer to our goals for deployment. I don’t think we could have achieved the same measure of success with the same velocity had we only chosen to focus on one or two practices. From where we started, the benefits we experienced using CD practices have been immeasurable. It can be a challenge in the beginning, but if you stick by it, it hugely improves not just the quality of code that gets delivered but the quality of the team as well.

+ +

Sanchit Bahal is a Lead Technical Consultant with Thoughtworks and has over 14 years of experience in building complex enterprise applications. He loves using devops practices and principles to build high performing delivery teams.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/10/index.html b/pr-1714/2017/10/index.html new file mode 100644 index 000000000..e8b0a16f3 --- /dev/null +++ b/pr-1714/2017/10/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11.html b/pr-1714/2017/11.html new file mode 100644 index 000000000..4e2262bd4 --- /dev/null +++ b/pr-1714/2017/11.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/07.html b/pr-1714/2017/11/07.html new file mode 100644 index 000000000..409a84891 --- /dev/null +++ b/pr-1714/2017/11/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 7 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool.html b/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool.html new file mode 100644 index 000000000..5279316a6 --- /dev/null +++ b/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Confessions of continuous delivery experts: How Mingle saw the light | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Mingle - Confessions of CD Experts +
+ +
+ + +
+

Confessions of continuous delivery experts: How Mingle saw the light

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

At Thoughtworks, we are passionate advocates for continuous delivery - we even wrote the book on it. One might think that we know all there is to know about continuous delivery and that nothing can surprise us. This isn’t entirely true. We do understand the challenges behind continuous delivery and one of the reasons for this is that we’ve been through them ourselves. This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery.

+ +

This post is about the journey of the Mingle development team from not doing continuous delivery at all to a state where continuous delivery is considered as a routine.

+ +

Mingle is a project management tool built by Thoughtworks Products. Before Mingle was available on the cloud, it used to be only an installed product (on-premise). We had a three-month release cycle at the end of which we packaged everything up and shipped it out to our customers.

+ +

Confession: We weren’t delivering everyday but we thought that if we need to, we probably could

+ +

At that time, we were sure that we were practicing continuous delivery. Each commit the team made went through a comprehensive automated test suite. We regularly deployed to an environment where we could test out the working software ourselves and all of us could build those installers at anytime. And then once in a month, we would deploy to our ‘staging’ environment which was available for use to anyone within Thoughtworks.

+ +

Overall, we felt pretty good about our development practices, and thought we didn’t release more often just because the cadence was set by our business. If we needed, we could do it.

+ +

Realizations when we moved to the cloud

+ +

In 2012, we started moving our product to the cloud. This meant that Mingle was going to be offered as both a SAAS product as well as an on-premise one. The team was excited and thought that it would be a piece of cake since we were already following best practices. The key aspects to moving to a cloud application was the ability to be deploy to production frequently as well as quickly. When we compared the reality of daily releases to our quarterly release cycle, we realized two things:

+ +
    +
  • We needed to figure out how are we going to balance doing the on-premise software and the SAAS product together
    • +
  • And that we were not really ready to deliver daily!
    • +
+ +

We took a closer look at our practices and processes and we found big gaps in our cycle time.

+ +
+

"25% of that three-month release cycle was actually taken up by an activity we called installer testing."

+
+ +

We were taking our installer and testing it on a combination of different operating systems and browsers to ensure that when we shipped it to our customer, it worked on their hardware. This process took about two or three weeks. At the end of every release, we could not be ready to ship our software until the ‘installer testing’ was done. Before we were pushed into thinking about delivering frequently, we really hadn't tried to optimize this.

+ +

Reflecting on our current CD processes

+ +

Here’s Jez Humble's definition of continuous delivery from his book:

+ +
+

"Continuous delivery is the ability to get all kinds of changes, configuration codes, features, bug fixes, infrastructure, everything into the hands of users safely, quickly and in a reliable manner."

+
+ +

In practice, what it comes down to is feedback loops. Your check-ins trigger automation tests that run and give you feedback. At any step, if you see any failures, you need to know why, and once that goes green, then you move on to other kind of tests, e.g. performance tests, security tests. Each of this is a feedback loop. It could be manual or automated, but the idea is to go from test-to-test, getting more and more confidence as you go towards production. So when you actually deploy into production, you're assured that it's going to work.

+ +

Feedback Loops

+ +

Confession: We secretly knew that there were areas in our deployment that we needed to optimize.

+ +

Even though we’d known that there were areas in our Software Development Life Cycle that we could optimize, they didn’t become critical to us till we decided to release daily. So we reassessed whether we could actually remove the manual installer testing and make it part of our automated process - which is what we did. We couldn’t automate this 100%, but after this, we could make a release whenever we decided to.

+ +

And we saw benefits right away.

+ +

We reduced our time spent in manual testing from 25% to about 5% - from two to three weeks to about two to three days. This meant that if we wanted to release a small bug-fix to our cloud app, it could be done quickly, easily, and reliably.

+ +

We also had some unexpected benefits: In our older way of working, when our QA's had been doing the installer testing, they were siloed. While the rest of the team were talking about features for the next release and ideating about how this was going to work in the real world, the QA team was testing on their own. In the new world, we have the entire team working together, especially when we were able to have our QA's as part of our ideation sessions. They were able to assess functionality and highlight critical test cases a lot earlier in the process. So we were able to build quality in from the very beginning, rather than leaving it for the end.

+ +

We continue to use the same fundamentals for the release process today.

+ +
+ +

Summary

+ +

If you think you’re doing continuous delivery, challenge your assumption by actually releasing more frequently. Making a decision to deliver continuously helped us identify roadblocks in our process that we had otherwise not paid attention to. It wasn’t easy and initially took time, but we were able to recover the time invested within the first year. We saw benefits to both the cycle time of our deliveries as well as a shift in our team culture. Moving to continuous delivery freed up our people to do the work they like to do.

+ +

In our next post, we’ll share anecdotes about our learnings from continuous delivery with GoCD.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/index.html b/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/index.html new file mode 100644 index 000000000..52acd6512 --- /dev/null +++ b/pr-1714/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/index.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Confessions of continuous delivery experts: How Mingle saw the light | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Mingle - Confessions of CD Experts +
+ +
+ + +
+

Confessions of continuous delivery experts: How Mingle saw the light

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

At Thoughtworks, we are passionate advocates for continuous delivery - we even wrote the book on it. One might think that we know all there is to know about continuous delivery and that nothing can surprise us. This isn’t entirely true. We do understand the challenges behind continuous delivery and one of the reasons for this is that we’ve been through them ourselves. This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery.

+ +

This post is about the journey of the Mingle development team from not doing continuous delivery at all to a state where continuous delivery is considered as a routine.

+ +

Mingle is a project management tool built by Thoughtworks Products. Before Mingle was available on the cloud, it used to be only an installed product (on-premise). We had a three-month release cycle at the end of which we packaged everything up and shipped it out to our customers.

+ +

Confession: We weren’t delivering everyday but we thought that if we need to, we probably could

+ +

At that time, we were sure that we were practicing continuous delivery. Each commit the team made went through a comprehensive automated test suite. We regularly deployed to an environment where we could test out the working software ourselves and all of us could build those installers at anytime. And then once in a month, we would deploy to our ‘staging’ environment which was available for use to anyone within Thoughtworks.

+ +

Overall, we felt pretty good about our development practices, and thought we didn’t release more often just because the cadence was set by our business. If we needed, we could do it.

+ +

Realizations when we moved to the cloud

+ +

In 2012, we started moving our product to the cloud. This meant that Mingle was going to be offered as both a SAAS product as well as an on-premise one. The team was excited and thought that it would be a piece of cake since we were already following best practices. The key aspects to moving to a cloud application was the ability to be deploy to production frequently as well as quickly. When we compared the reality of daily releases to our quarterly release cycle, we realized two things:

+ +
    +
  • We needed to figure out how are we going to balance doing the on-premise software and the SAAS product together
    • +
  • And that we were not really ready to deliver daily!
    • +
+ +

We took a closer look at our practices and processes and we found big gaps in our cycle time.

+ +
+

"25% of that three-month release cycle was actually taken up by an activity we called installer testing."

+
+ +

We were taking our installer and testing it on a combination of different operating systems and browsers to ensure that when we shipped it to our customer, it worked on their hardware. This process took about two or three weeks. At the end of every release, we could not be ready to ship our software until the ‘installer testing’ was done. Before we were pushed into thinking about delivering frequently, we really hadn't tried to optimize this.

+ +

Reflecting on our current CD processes

+ +

Here’s Jez Humble's definition of continuous delivery from his book:

+ +
+

"Continuous delivery is the ability to get all kinds of changes, configuration codes, features, bug fixes, infrastructure, everything into the hands of users safely, quickly and in a reliable manner."

+
+ +

In practice, what it comes down to is feedback loops. Your check-ins trigger automation tests that run and give you feedback. At any step, if you see any failures, you need to know why, and once that goes green, then you move on to other kind of tests, e.g. performance tests, security tests. Each of this is a feedback loop. It could be manual or automated, but the idea is to go from test-to-test, getting more and more confidence as you go towards production. So when you actually deploy into production, you're assured that it's going to work.

+ +

Feedback Loops

+ +

Confession: We secretly knew that there were areas in our deployment that we needed to optimize.

+ +

Even though we’d known that there were areas in our Software Development Life Cycle that we could optimize, they didn’t become critical to us till we decided to release daily. So we reassessed whether we could actually remove the manual installer testing and make it part of our automated process - which is what we did. We couldn’t automate this 100%, but after this, we could make a release whenever we decided to.

+ +

And we saw benefits right away.

+ +

We reduced our time spent in manual testing from 25% to about 5% - from two to three weeks to about two to three days. This meant that if we wanted to release a small bug-fix to our cloud app, it could be done quickly, easily, and reliably.

+ +

We also had some unexpected benefits: In our older way of working, when our QA's had been doing the installer testing, they were siloed. While the rest of the team were talking about features for the next release and ideating about how this was going to work in the real world, the QA team was testing on their own. In the new world, we have the entire team working together, especially when we were able to have our QA's as part of our ideation sessions. They were able to assess functionality and highlight critical test cases a lot earlier in the process. So we were able to build quality in from the very beginning, rather than leaving it for the end.

+ +

We continue to use the same fundamentals for the release process today.

+ +
+ +

Summary

+ +

If you think you’re doing continuous delivery, challenge your assumption by actually releasing more frequently. Making a decision to deliver continuously helped us identify roadblocks in our process that we had otherwise not paid attention to. It wasn’t easy and initially took time, but we were able to recover the time invested within the first year. We saw benefits to both the cycle time of our deliveries as well as a shift in our team culture. Moving to continuous delivery freed up our people to do the work they like to do.

+ +

In our next post, we’ll share anecdotes about our learnings from continuous delivery with GoCD.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/07/index.html b/pr-1714/2017/11/07/index.html new file mode 100644 index 000000000..e01de5ef5 --- /dev/null +++ b/pr-1714/2017/11/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 7 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/14.html b/pr-1714/2017/11/14.html new file mode 100644 index 000000000..214612d39 --- /dev/null +++ b/pr-1714/2017/11/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 14 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/14/index.html b/pr-1714/2017/11/14/index.html new file mode 100644 index 000000000..1f90f8fb7 --- /dev/null +++ b/pr-1714/2017/11/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 14 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/14/minimizing-risk-improving-security-devops.html b/pr-1714/2017/11/14/minimizing-risk-improving-security-devops.html new file mode 100644 index 000000000..7011c94ea --- /dev/null +++ b/pr-1714/2017/11/14/minimizing-risk-improving-security-devops.html @@ -0,0 +1,283 @@ + + + + + + + + + + + + + + + + Minimizing Risk and Improving Security in DevOps | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Security in DevOps +
+ +
+ + +
+

Minimizing Risk and Improving Security in DevOps

+

Franklin Mosley

+

+

+
+ +
+ +

Organizations today are utilizing DevOps to accelerate the software development and deployment space with the goal of releasing better quality software more reliably. According to the 2017 State of DevOps report, those that are practicing DevOps are experiencing:

+ +
    +
  • 24x faster recovery from failures
    • +
  • 3x lower change failure rate
    • +
  • 22% less time spent on unplanned work and rework
    • +
+ +

But how secure are these releases? We know that high performing teams spend 50% less time remediating security issues.

+ +

Having been in security for many years, I remember the days when it was mostly a function of securing the perimeter. But today, the way we conduct business has changed: we have moved to the cloud and have mobile applications. We are producing web application software that according to the Verizon Data Breach Investigation Report (DBIR) accounted for over 40% of incidents resulting in a data breach and were the single-biggest source of data loss. So it has become critical to integrate proper security thinking into the DevOps process.

+ +

Minimizing Risk, Improving Security

+ +

DevOps is a culture that promotes collaboration between developers and IT professionals. The two groups have found a way to work together in poly-skilled teams to accomplish their common goals while satisfying their different needs. For developers, it is to deliver features quickly and on-time. And for operations, it is to have highly available and stable systems.

+ +

So what is the need of security? Security at its core is about managing risk by finding vulnerabilities early and fixing them quickly. By prioritizing security in a DevOps culture (sometimes referred to as DevSecOps), security, development, and operations teams can achieve a common goal of minimizing risk and delivering safe software. It is about completely integrating security with DevOps by bringing it to every stage of the development and delivery process. To do it successfully takes communication and collaboration among the teams.

+ +

I have presented on this topic at several conferences, and one of the most common questions I get is how to integrate security into a DevOps culture successfully. People who recognize and understand the need for security want to know how to help their team start practicing it. Here are a few tips to help anyone get started:

+ +
    +
  • Changing the security mindset
    • +
  • Getting buy-in from stakeholders
    • +
  • Enforce Security as Code
    • +
  • Learn and continuously improve
    • +
+ +

Changing the Security Mindset

+ +

Traditionally, security tasks were performed during the testing phase or were bolted on in production. Security was perceived as a roadblock. Our goal is to shift security left in the Software Development Lifecycle (SDLC) and focus on it throughout the continuous integration and continuous delivery process. We do this by integrating security at every step of the way. This means that the traditional mindsets around security have to change.

+ +

The security professional needs to walk in the developer's shoes, and learn how software is made and the issues that are faced. It’s best to work with developers to come up with solutions that allow them to do the right thing when it comes to security.

+ +

Security was always seen as a function of the ‘security’ organization. With DevOps, we aim to break down those silos, and security has to become a shared responsibility. The agile teams have to own it the same way they have started owning user experience, reliability, and performance. As Pete Chestna, a DevOps practitioner and AppSec evangelist with Veracode says,

+ +
+

"DevOps now requires Full Spectrum Engineers, and as part of that developers will have to make security a priority."

+
+ +

Getting buy-in from stakeholders

+ +
+

If security is becoming a shared responsibility, how do you get those who traditionally didn’t care about it to make it a priority?

+
+ +

This is a question I get frequently, and I always answer that it starts at the top. Buy-in from stakeholders makes it a priority that trickles down to your agile teams and helps to foster a culture where it is a priority for everyone in the organization.

+ +

I worked at a company where the CEO was conducting a town hall to discuss our new software platform, and what it would take to make it successful. He mentioned the security of the customer data as one of the pillars of success. At that point, every employee realized they had a personal stake in securing the platform.

+ +

To get that buy-in, you can make a case for the importance of securing your software. Many security incidents occur in the news every week that can be used to highlight why it should be a priority.

+ +

Enforce Security as Code

+ +

Automation is a big part of DevOps, and it is no different for the security aspect of it. The manual gating that security traditionally added must be removed to perform security at scale and achieve continuous delivery. Security and compliance should be scripted as available services, integrated into your pipeline, and used to enforce the policies that you have developed.

+ +

As an application security engineer, my job is to help the process continue to flow, while minimizing risk. I have scripted tests to:

+ +
    +
  • check transport layer security settings of an endpoint
    • +
  • check software composition analysis for vulnerable components
    • +
  • perform automated code reviews
    • +
+ +

These are just some examples of security checks you may automate into your CI/CD pipeline.

+ +

Learn and Continuously Improve

+ +

Moving to a focus on security in a DevOps culture is a significant transformation project, and it can be overwhelming. As the saying goes, the best way to eat an elephant is one bite at a time. To integrate security into CI/CD, I recommend starting off with a small solution and use the feedback to determine necessary changes. Don’t be afraid to fail. This should be an iterative learning and improvement process and choosing the right tool for the job is part of it.

+ +

When implementing security tests into your CI/CD, start with a small set of rules, validate the results, and gradually increase them. Too many false positives can cause your developers to lose faith in the security testing, and to stop using the security service because the CI/CD pipeline is being halted unnecessarily. I have made this mistake before, and it’s not pretty when development teams flood you with Slack messages because their deployments keep failing. So start off small and increase gradually.

+ +
+ +

Summary

+ +

In this article, I covered some tips for successfully transitioning to DevOps culturally while integrating security into your CI/CD. These tips can be used as a guideline to encourage communication and collaboration among security, development, and operation teams.

+ +

Franklin Mosley, currently helping define and build out the Security Vision and Roadmap for PagerDuty, has over 16-years of experience as an Information Security professional, during which he supported several businesses counter threats. Prior to that, he was a software engineer, which makes him perfectly suited for his passionate focus on Application Security and DevOps. He is always looking for ways to improve processes, while still ensuring that teams are delivering secure software.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/14/minimizing-risk-improving-security-devops/index.html b/pr-1714/2017/11/14/minimizing-risk-improving-security-devops/index.html new file mode 100644 index 000000000..255bde8b7 --- /dev/null +++ b/pr-1714/2017/11/14/minimizing-risk-improving-security-devops/index.html @@ -0,0 +1,283 @@ + + + + + + + + + + + + + + + + Minimizing Risk and Improving Security in DevOps | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Security in DevOps +
+ +
+ + +
+

Minimizing Risk and Improving Security in DevOps

+

Franklin Mosley

+

+

+
+ +
+ +

Organizations today are utilizing DevOps to accelerate the software development and deployment space with the goal of releasing better quality software more reliably. According to the 2017 State of DevOps report, those that are practicing DevOps are experiencing:

+ +
    +
  • 24x faster recovery from failures
    • +
  • 3x lower change failure rate
    • +
  • 22% less time spent on unplanned work and rework
    • +
+ +

But how secure are these releases? We know that high performing teams spend 50% less time remediating security issues.

+ +

Having been in security for many years, I remember the days when it was mostly a function of securing the perimeter. But today, the way we conduct business has changed: we have moved to the cloud and have mobile applications. We are producing web application software that according to the Verizon Data Breach Investigation Report (DBIR) accounted for over 40% of incidents resulting in a data breach and were the single-biggest source of data loss. So it has become critical to integrate proper security thinking into the DevOps process.

+ +

Minimizing Risk, Improving Security

+ +

DevOps is a culture that promotes collaboration between developers and IT professionals. The two groups have found a way to work together in poly-skilled teams to accomplish their common goals while satisfying their different needs. For developers, it is to deliver features quickly and on-time. And for operations, it is to have highly available and stable systems.

+ +

So what is the need of security? Security at its core is about managing risk by finding vulnerabilities early and fixing them quickly. By prioritizing security in a DevOps culture (sometimes referred to as DevSecOps), security, development, and operations teams can achieve a common goal of minimizing risk and delivering safe software. It is about completely integrating security with DevOps by bringing it to every stage of the development and delivery process. To do it successfully takes communication and collaboration among the teams.

+ +

I have presented on this topic at several conferences, and one of the most common questions I get is how to integrate security into a DevOps culture successfully. People who recognize and understand the need for security want to know how to help their team start practicing it. Here are a few tips to help anyone get started:

+ +
    +
  • Changing the security mindset
    • +
  • Getting buy-in from stakeholders
    • +
  • Enforce Security as Code
    • +
  • Learn and continuously improve
    • +
+ +

Changing the Security Mindset

+ +

Traditionally, security tasks were performed during the testing phase or were bolted on in production. Security was perceived as a roadblock. Our goal is to shift security left in the Software Development Lifecycle (SDLC) and focus on it throughout the continuous integration and continuous delivery process. We do this by integrating security at every step of the way. This means that the traditional mindsets around security have to change.

+ +

The security professional needs to walk in the developer's shoes, and learn how software is made and the issues that are faced. It’s best to work with developers to come up with solutions that allow them to do the right thing when it comes to security.

+ +

Security was always seen as a function of the ‘security’ organization. With DevOps, we aim to break down those silos, and security has to become a shared responsibility. The agile teams have to own it the same way they have started owning user experience, reliability, and performance. As Pete Chestna, a DevOps practitioner and AppSec evangelist with Veracode says,

+ +
+

"DevOps now requires Full Spectrum Engineers, and as part of that developers will have to make security a priority."

+
+ +

Getting buy-in from stakeholders

+ +
+

If security is becoming a shared responsibility, how do you get those who traditionally didn’t care about it to make it a priority?

+
+ +

This is a question I get frequently, and I always answer that it starts at the top. Buy-in from stakeholders makes it a priority that trickles down to your agile teams and helps to foster a culture where it is a priority for everyone in the organization.

+ +

I worked at a company where the CEO was conducting a town hall to discuss our new software platform, and what it would take to make it successful. He mentioned the security of the customer data as one of the pillars of success. At that point, every employee realized they had a personal stake in securing the platform.

+ +

To get that buy-in, you can make a case for the importance of securing your software. Many security incidents occur in the news every week that can be used to highlight why it should be a priority.

+ +

Enforce Security as Code

+ +

Automation is a big part of DevOps, and it is no different for the security aspect of it. The manual gating that security traditionally added must be removed to perform security at scale and achieve continuous delivery. Security and compliance should be scripted as available services, integrated into your pipeline, and used to enforce the policies that you have developed.

+ +

As an application security engineer, my job is to help the process continue to flow, while minimizing risk. I have scripted tests to:

+ +
    +
  • check transport layer security settings of an endpoint
    • +
  • check software composition analysis for vulnerable components
    • +
  • perform automated code reviews
    • +
+ +

These are just some examples of security checks you may automate into your CI/CD pipeline.

+ +

Learn and Continuously Improve

+ +

Moving to a focus on security in a DevOps culture is a significant transformation project, and it can be overwhelming. As the saying goes, the best way to eat an elephant is one bite at a time. To integrate security into CI/CD, I recommend starting off with a small solution and use the feedback to determine necessary changes. Don’t be afraid to fail. This should be an iterative learning and improvement process and choosing the right tool for the job is part of it.

+ +

When implementing security tests into your CI/CD, start with a small set of rules, validate the results, and gradually increase them. Too many false positives can cause your developers to lose faith in the security testing, and to stop using the security service because the CI/CD pipeline is being halted unnecessarily. I have made this mistake before, and it’s not pretty when development teams flood you with Slack messages because their deployments keep failing. So start off small and increase gradually.

+ +
+ +

Summary

+ +

In this article, I covered some tips for successfully transitioning to DevOps culturally while integrating security into your CI/CD. These tips can be used as a guideline to encourage communication and collaboration among security, development, and operation teams.

+ +

Franklin Mosley, currently helping define and build out the Security Vision and Roadmap for PagerDuty, has over 16-years of experience as an Information Security professional, during which he supported several businesses counter threats. Prior to that, he was a software engineer, which makes him perfectly suited for his passionate focus on Application Security and DevOps. He is always looking for ways to improve processes, while still ensuring that teams are delivering secure software.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/28.html b/pr-1714/2017/11/28.html new file mode 100644 index 000000000..b70a8bf8f --- /dev/null +++ b/pr-1714/2017/11/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 28 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source.html b/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source.html new file mode 100644 index 000000000..a01614a69 --- /dev/null +++ b/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source.html @@ -0,0 +1,242 @@ + + + + + + + + + + + + + + + + Confessions of Continuous Delivery Experts: When GoCD went open source | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CD confessions when GoCD went open source +
+ +
+ + +
+

Confessions of Continuous Delivery Experts: When GoCD went open source

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

At Thoughtworks, we are passionate advocates for continuous delivery - we even wrote the book on it. One might think that we know all there is to know about continuous delivery and that nothing can surprise us. This isn’t entirely true. We do understand the challenges behind continuous delivery and one of the reasons for this is that we’ve been through them ourselves. This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery.

+ +

This is the second in our series of confessions from continuous delivery experts. This post is the story of how continuous delivery became critical to the GoCD team’s decision to go open source in 2014.

+ +

Moving from proprietary to open source

+ +

GoCD was originally created as a proprietary solution by Thoughtworks around 2010. At this point, we had a stellar team with people like Jez Humble, GoCD’s first product manager. It was through his experience with GoCD that he wrote the book Continuous Delivery; which also means that our team was well versed and confident in those concepts. In hindsight, I can see that while our knowledge of these concepts was great, we needed practice in recognizing its applications. One such moment was when GoCD decided to go open source.

+ +

Initially, we had a release cycle of three to four months. The product was being consumed by several enterprise customers and given their resistance to upgrade often, there was no real impetus for the team to deliver change any quicker. We had a long exploratory and regression cycle - which worked in that scenario. We also had automated tests which helped us, but they weren’t 100% reliable. We had always contemplated if it were possible to release an installed product more frequently than our 2-3 month cycle… and was the team was truly practicing continuous delivery?

+ +

We were about to get the answers to this question in 2014 - when we decided to go open source.

+ +

Confession: We were extremely comfortable with the concepts of continuous delivery, but not when it came to practicing it.

+ +

With this decision, came new expectations from a new audience. Now we were seeing adoption from a new group of people who expected changes faster than our previous enterprise customers and were keen to see their contributions in production.

+ +

Our first goal was to shorten our release process from 3 - 4 months to 1.5 months. When we did this, we saw that our regression cycle (which worked fine for us initially) broke. There was an installer testing phase and performance testing which had enormous gaps. Our entire automation had huge gaps that we hadn't really noticed till we needed to release much more quickly. This was embarrassing because we were building a CD product!

+ +

We decided to break down the automation of our entire deployment into tiny chunks. We did this by figuring out smaller bits to automate with each release, rather than attempting to automate the entire process at once. Our first step was to automate the publishing of releases. Earlier, this was something that people did manually and because it was done every three or four months, it didn’t affect us much. However, now since we’d be releasing more often, it no longer made sense, so we automated it completely. In fact, everything became automatic so within a release cycle, we started to do this activity multiple times.

+ +

As we kept going, we started finding newer things to automate (that we didn’t have earlier) such as our Release Notes. Since we were delivering an open source tool to the public, we needed to have reliable and sensible release notes. First, we got everyone who contributed code (the team and external contributors) to write good commit messages and then automated release notes out of these. Despite the automation, we do still curate it and make it easier to read.

+ +

Automate everything

+ +

Confession: We were still not delivering continuously at 100%, as we kept identifying new things to automate.

+ +

The ultimate goal was to get to a place where we could automatically publish releases to production. With automated installer tests, performance tests, release notes etc., we got closer and closer to this goal. It took confidence in our automation ability for us to be able to say,

+ +
+

"Yes, this is a release that we can stand by”.

+
+ +

And if there was a problem with it, we had the ability to release a new version or deploy a fix much more easily. We're also happy to say that we're in a "good enough phase", where the release cadence is decent for an installed product, and increasing it does not necessarily add much value to users. We do publish certified, experimental builds for every good build - but we deem one of them a "release" only about once a month.

+ +

Learnings

+ +

The biggest learning for me, as a product manager for GoCD, has been that frequency reduces difficulty. The idea is simple - if you find something difficult, do it more often. If you can bring that pain forward, you will realize that there are a lot of costs and complexity that you can reduce. The second learning for me has been that automation costs pay for themselves. We used to have long cycles and at the end we still spent manual effort checking if all the tests had been carried out and correcting when anything had been missed. We don't have to worry about that now. There is an initial cost at the beginning, but in the end, it definitely pays off.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/index.html b/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/index.html new file mode 100644 index 000000000..aa686e8c2 --- /dev/null +++ b/pr-1714/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/index.html @@ -0,0 +1,242 @@ + + + + + + + + + + + + + + + + Confessions of Continuous Delivery Experts: When GoCD went open source | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CD confessions when GoCD went open source +
+ +
+ + +
+

Confessions of Continuous Delivery Experts: When GoCD went open source

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

At Thoughtworks, we are passionate advocates for continuous delivery - we even wrote the book on it. One might think that we know all there is to know about continuous delivery and that nothing can surprise us. This isn’t entirely true. We do understand the challenges behind continuous delivery and one of the reasons for this is that we’ve been through them ourselves. This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery.

+ +

This is the second in our series of confessions from continuous delivery experts. This post is the story of how continuous delivery became critical to the GoCD team’s decision to go open source in 2014.

+ +

Moving from proprietary to open source

+ +

GoCD was originally created as a proprietary solution by Thoughtworks around 2010. At this point, we had a stellar team with people like Jez Humble, GoCD’s first product manager. It was through his experience with GoCD that he wrote the book Continuous Delivery; which also means that our team was well versed and confident in those concepts. In hindsight, I can see that while our knowledge of these concepts was great, we needed practice in recognizing its applications. One such moment was when GoCD decided to go open source.

+ +

Initially, we had a release cycle of three to four months. The product was being consumed by several enterprise customers and given their resistance to upgrade often, there was no real impetus for the team to deliver change any quicker. We had a long exploratory and regression cycle - which worked in that scenario. We also had automated tests which helped us, but they weren’t 100% reliable. We had always contemplated if it were possible to release an installed product more frequently than our 2-3 month cycle… and was the team was truly practicing continuous delivery?

+ +

We were about to get the answers to this question in 2014 - when we decided to go open source.

+ +

Confession: We were extremely comfortable with the concepts of continuous delivery, but not when it came to practicing it.

+ +

With this decision, came new expectations from a new audience. Now we were seeing adoption from a new group of people who expected changes faster than our previous enterprise customers and were keen to see their contributions in production.

+ +

Our first goal was to shorten our release process from 3 - 4 months to 1.5 months. When we did this, we saw that our regression cycle (which worked fine for us initially) broke. There was an installer testing phase and performance testing which had enormous gaps. Our entire automation had huge gaps that we hadn't really noticed till we needed to release much more quickly. This was embarrassing because we were building a CD product!

+ +

We decided to break down the automation of our entire deployment into tiny chunks. We did this by figuring out smaller bits to automate with each release, rather than attempting to automate the entire process at once. Our first step was to automate the publishing of releases. Earlier, this was something that people did manually and because it was done every three or four months, it didn’t affect us much. However, now since we’d be releasing more often, it no longer made sense, so we automated it completely. In fact, everything became automatic so within a release cycle, we started to do this activity multiple times.

+ +

As we kept going, we started finding newer things to automate (that we didn’t have earlier) such as our Release Notes. Since we were delivering an open source tool to the public, we needed to have reliable and sensible release notes. First, we got everyone who contributed code (the team and external contributors) to write good commit messages and then automated release notes out of these. Despite the automation, we do still curate it and make it easier to read.

+ +

Automate everything

+ +

Confession: We were still not delivering continuously at 100%, as we kept identifying new things to automate.

+ +

The ultimate goal was to get to a place where we could automatically publish releases to production. With automated installer tests, performance tests, release notes etc., we got closer and closer to this goal. It took confidence in our automation ability for us to be able to say,

+ +
+

"Yes, this is a release that we can stand by”.

+
+ +

And if there was a problem with it, we had the ability to release a new version or deploy a fix much more easily. We're also happy to say that we're in a "good enough phase", where the release cadence is decent for an installed product, and increasing it does not necessarily add much value to users. We do publish certified, experimental builds for every good build - but we deem one of them a "release" only about once a month.

+ +

Learnings

+ +

The biggest learning for me, as a product manager for GoCD, has been that frequency reduces difficulty. The idea is simple - if you find something difficult, do it more often. If you can bring that pain forward, you will realize that there are a lot of costs and complexity that you can reduce. The second learning for me has been that automation costs pay for themselves. We used to have long cycles and at the end we still spent manual effort checking if all the tests had been carried out and correcting when anything had been missed. We don't have to worry about that now. There is an initial cost at the beginning, but in the end, it definitely pays off.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/28/index.html b/pr-1714/2017/11/28/index.html new file mode 100644 index 000000000..4bf587a8b --- /dev/null +++ b/pr-1714/2017/11/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 28 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/11/index.html b/pr-1714/2017/11/index.html new file mode 100644 index 000000000..cdd2f8ae1 --- /dev/null +++ b/pr-1714/2017/11/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12.html b/pr-1714/2017/12.html new file mode 100644 index 000000000..045d7653e --- /dev/null +++ b/pr-1714/2017/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12/06.html b/pr-1714/2017/12/06.html new file mode 100644 index 000000000..6c7ae29e0 --- /dev/null +++ b/pr-1714/2017/12/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith.html b/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith.html new file mode 100644 index 000000000..0e6b4dee3 --- /dev/null +++ b/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith.html @@ -0,0 +1,242 @@ + + + + + + + + + + + + + + + + Confessions of Continuous Delivery Experts: From microservices back to monolith | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CD confessions moving from monolith to microservices +
+ +
+ + +
+

Confessions of Continuous Delivery Experts: From microservices back to monolith

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery. This is the third in our series of confessions from continuous delivery experts. This story is about the experiences of the Snap CI team in moving a monolith codebase to microservices and why they chose to move back.

+ +

Snap CI was a continuous integration and delivery server for teams who work in the Cloud. If you were using GitHub, Snap CI could take your commit, put it through an automated test or suite of tests that you've written, and then help you deploy it to your Cloud target (like Heroku, AWS etc) .

+ +

Confession: We fulfilled all the practices on a checklist, but we failed on the core principle which is ‘to deliver changes quickly’

+ +

Snap CI’s team had very enthusiastic and experienced CD practitioners. The team wanted to do ‘everything CD’. Within six months after we began the product, we had a microservices architecture with nine different components, sophisticated messaging queues, monitoring, an automated infrastructure, and deployment pipelines for all of these different components.

+ +
+

“We were in CD Nirvana”

+
+ +

We had everything except for one important piece - delivering quickly. We were delivering to production every two weeks, which sounds “not so bad,” but was not a business decision. We were unable to deploy any sooner than that. The product manager was exceptionally frustrated that they were unable to do daily ‘continuous deployment’ as the business needed to.

+ +

Confession: We did not pay attention to the other core principle of continuous delivery, which was to deliver changes reliably

+ +

The second problem we had, was that when it came time to deliver, the likelihood of key features working was only about 50%. All that monitoring we had in place wasn’t giving us usable feedback. We were forced to rely on manual testing or using a small test group to inform us of any failures. We were unable to move the product forward for public use.

+ +

Assess and reassess your continuous delivery practices

+ +

It’s commonly thought that microservices are essential to do continuous delivery as a best practice. However, in our situation they were not right for us at that time.

+ +

We were enamoured by the idea of “microservices” and separated our components without pausing to think if they truly made sense for delivery. As a result, components were only separated superficially. When we changed one component, we still needed to change the data structure in the other components. And because of this, we were unable to deliver those pieces separately from each other.

+ +

At this time, we made a decision to go back to a monolith structure which put us in a better place to understand what was going on with the product. This gave us the ability to gradually release more often and allow the business needs and the needs of the product to dictate where those splits should be.

+ +

Lessons we learned

+ +

We learned that users don’t care if your team is practicing continuous delivery or using microservices. These are decisions a team makes to ensure what they build reaches users quickly and reliably. It’s easy to get caught up in the checklists, “doing CI and CD”, trying cool new microservices etc.

+ +
+

Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.

+
+ +

The second lesson we learned was that CD is a journey. It's an evolution, and you first need to set your goals driven by your business and then make your way there. It is tempting to move to the latest practice or new technology as soon as you hear about it. However I recommend that in the first few weeks, unless you are 100% sure that that's what you need, don’t make any major architectural decisions. Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.

+ +

Snap CI was created by Thoughtworks Products. It is no longer available and has been discontinued since Feb 2017.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/index.html b/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/index.html new file mode 100644 index 000000000..282af8fd2 --- /dev/null +++ b/pr-1714/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/index.html @@ -0,0 +1,242 @@ + + + + + + + + + + + + + + + + Confessions of Continuous Delivery Experts: From microservices back to monolith | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ CD confessions moving from monolith to microservices +
+ +
+ + +
+

Confessions of Continuous Delivery Experts: From microservices back to monolith

+

GoCD Team

+

+ CD Confessions +

+
+ +
+ +

This blog series highlights the important lessons that we learned when we thought we were practicing continuous delivery. This is the third in our series of confessions from continuous delivery experts. This story is about the experiences of the Snap CI team in moving a monolith codebase to microservices and why they chose to move back.

+ +

Snap CI was a continuous integration and delivery server for teams who work in the Cloud. If you were using GitHub, Snap CI could take your commit, put it through an automated test or suite of tests that you've written, and then help you deploy it to your Cloud target (like Heroku, AWS etc) .

+ +

Confession: We fulfilled all the practices on a checklist, but we failed on the core principle which is ‘to deliver changes quickly’

+ +

Snap CI’s team had very enthusiastic and experienced CD practitioners. The team wanted to do ‘everything CD’. Within six months after we began the product, we had a microservices architecture with nine different components, sophisticated messaging queues, monitoring, an automated infrastructure, and deployment pipelines for all of these different components.

+ +
+

“We were in CD Nirvana”

+
+ +

We had everything except for one important piece - delivering quickly. We were delivering to production every two weeks, which sounds “not so bad,” but was not a business decision. We were unable to deploy any sooner than that. The product manager was exceptionally frustrated that they were unable to do daily ‘continuous deployment’ as the business needed to.

+ +

Confession: We did not pay attention to the other core principle of continuous delivery, which was to deliver changes reliably

+ +

The second problem we had, was that when it came time to deliver, the likelihood of key features working was only about 50%. All that monitoring we had in place wasn’t giving us usable feedback. We were forced to rely on manual testing or using a small test group to inform us of any failures. We were unable to move the product forward for public use.

+ +

Assess and reassess your continuous delivery practices

+ +

It’s commonly thought that microservices are essential to do continuous delivery as a best practice. However, in our situation they were not right for us at that time.

+ +

We were enamoured by the idea of “microservices” and separated our components without pausing to think if they truly made sense for delivery. As a result, components were only separated superficially. When we changed one component, we still needed to change the data structure in the other components. And because of this, we were unable to deliver those pieces separately from each other.

+ +

At this time, we made a decision to go back to a monolith structure which put us in a better place to understand what was going on with the product. This gave us the ability to gradually release more often and allow the business needs and the needs of the product to dictate where those splits should be.

+ +

Lessons we learned

+ +

We learned that users don’t care if your team is practicing continuous delivery or using microservices. These are decisions a team makes to ensure what they build reaches users quickly and reliably. It’s easy to get caught up in the checklists, “doing CI and CD”, trying cool new microservices etc.

+ +
+

Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.

+
+ +

The second lesson we learned was that CD is a journey. It's an evolution, and you first need to set your goals driven by your business and then make your way there. It is tempting to move to the latest practice or new technology as soon as you hear about it. However I recommend that in the first few weeks, unless you are 100% sure that that's what you need, don’t make any major architectural decisions. Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.

+ +

Snap CI was created by Thoughtworks Products. It is no longer available and has been discontinued since Feb 2017.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12/06/index.html b/pr-1714/2017/12/06/index.html new file mode 100644 index 000000000..c6810b6ad --- /dev/null +++ b/pr-1714/2017/12/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/12/index.html b/pr-1714/2017/12/index.html new file mode 100644 index 000000000..208ae384b --- /dev/null +++ b/pr-1714/2017/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/index.html b/pr-1714/2017/index.html new file mode 100644 index 000000000..7fd49fd1d --- /dev/null +++ b/pr-1714/2017/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 1 of 4

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/2.html b/pr-1714/2017/page/2.html new file mode 100644 index 000000000..51c34cb08 --- /dev/null +++ b/pr-1714/2017/page/2.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 2 of 4

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/2/index.html b/pr-1714/2017/page/2/index.html new file mode 100644 index 000000000..9ed2ffd73 --- /dev/null +++ b/pr-1714/2017/page/2/index.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 2 of 4

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/3.html b/pr-1714/2017/page/3.html new file mode 100644 index 000000000..d6febc9a8 --- /dev/null +++ b/pr-1714/2017/page/3.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 3 of 4

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/3/index.html b/pr-1714/2017/page/3/index.html new file mode 100644 index 000000000..e9b76098b --- /dev/null +++ b/pr-1714/2017/page/3/index.html @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 3 of 4

+ +

Previous page

+ + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/4.html b/pr-1714/2017/page/4.html new file mode 100644 index 000000000..5bd2fedb6 --- /dev/null +++ b/pr-1714/2017/page/4.html @@ -0,0 +1,143 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 4 of 4

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2017/page/4/index.html b/pr-1714/2017/page/4/index.html new file mode 100644 index 000000000..ee891fa4b --- /dev/null +++ b/pr-1714/2017/page/4/index.html @@ -0,0 +1,143 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 4 of 4

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018.html b/pr-1714/2018.html new file mode 100644 index 000000000..ee49ac22d --- /dev/null +++ b/pr-1714/2018.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 1 of 2

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01.html b/pr-1714/2018/01.html new file mode 100644 index 000000000..767409515 --- /dev/null +++ b/pr-1714/2018/01.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/17.html b/pr-1714/2018/01/17.html new file mode 100644 index 000000000..60dd82f18 --- /dev/null +++ b/pr-1714/2018/01/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/17/continuous-delivery-beginners-guide.html b/pr-1714/2018/01/17/continuous-delivery-beginners-guide.html new file mode 100644 index 000000000..29bbef8d0 --- /dev/null +++ b/pr-1714/2018/01/17/continuous-delivery-beginners-guide.html @@ -0,0 +1,280 @@ + + + + + + + + + + + + + + + + An absolute beginners guide to Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Beginners Guide to Continuous Delivery +
+ +
+ + +
+

An absolute beginners guide to Continuous Delivery

+

Erin Snyder

+

+

+
+ +
+ +

My first gig at Thoughtworks was as a Support Engineer for Mingle - an agile project management tool. When I joined, some of my instructors at the coding bootcamp I attended, tried to teach us how agile development works. Well, they tried. None of us really practiced agile besides having daily stand-ups where we talked about blockers and successes. Some of the practices I figured out on my own, but most of it, I learned from observing my team. And, that’s how I eventually learnt about continuous delivery too.

+ +

After working with Mingle, I expanded my support-net (it’s like a fishing net but made of empathy and clever workarounds instead of rope) to cover support for GoCD and SnapCI - both in the domain of Continuous Delivery and Release Management systems.

+ +

Those are very big intimidating words (worthy of capitalization even) and prior to this, I had no idea what any of that meant. I expect that a lot of people might be in the same position. Perhaps, you’ve heard of it and like me, found them intimidating. Hopefully, by the end of this post, I’d have demystified this for you. And I can’t promise that you’ll be ready to immediately jump into “doing CD”, but you’ll have a better idea (as I eventually did) of what ‘continuous delivery’ means and what the fuss is all about.

+ +

In this post, I decided to pour out my knowledge for the benefit of anyone who might not be familiar with such things. Experienced developers can take a break: this one’s for the new kids and people like me who come from non-traditional (no CS degree here!) backgrounds.

+ +

First of all, how does software even get made?

+ +

When I was attending a coding bootcamp, here was my process:

+ +
    +
  • An instructor told me to write some code.
    • +
  • I wrote the code.
    • +
  • I ran some tests to see if the code works.
    • +
  • If it didn't work, I’d try to fix it.
    • +
  • Sometimes the code worked - because, magic!
    • +
  • I submitted my code for review by my instructor, usually by issuing a pull request on GitHub, or by deploying to Heroku, or something.
    • +
  • Done. Go have a cookie!
    • +
+ +

In a workplace that practices agile development, it is a bit different. Here is your process:

+ +
    +
  • Identify a need (aka, What am I building and why am I building it?)
    • +
  • Flesh out the idea (What are the specifics? Create a blueprint.)
    • +
  • Design the thing (What features should it have? What user stories?)
    • +
  • Code the thing (Allocate tasks to designers, developers, etc)
    • +
  • Test the thing while you are coding the thing (Easier to fix it when it breaks)
    • +
  • Integrate your thing into existing code base and test that too (Did your thing break someone else’s thing?)
    • +
  • Deploy the thing to an environment, like staging or production (OMG it's live and everyone can see it!)
    • +
  • Maintain the thing (Bug fixes, documentation, etc)
    • +
  • Repeat
    • +
+ +

So, what does continuous deployment do?

+ +

Some of the above steps can be automated to make the whole process faster. The faster you push a bug fix or a new feature, the happier your customers will be.

+ +

When you use continuous deployment software, here is your process:

+ +
    +
  • Think up the idea
    • +
  • Flesh out the idea
    • +
  • Design it
    • +
  • Code it
    • +
  • Each time you make a commit, it triggers a build server to package the code and sends it off for testing. You should treat any commit as if it could cause your code to be deployed to production and released to your customers, unless you do continuous delivery. More on that in a minute!
    • +
  • Code is automatically deployed to different environments and tested (unit tests, functional tests, integration tests, etc). If any of the tests fail, the process stops.
    • +
  • Then it’s time to maintain your code, fix some bugs and write some documentation to help your lovely support people troubleshoot the thing. :)
    • +
  • Repeat
    • +
+ +

What was that about continuous delivery?

+ +

The only difference between continuous deployment and continuous delivery is a manual trigger on the deployment stage. In continuous delivery, a human being has to push the button to deploy to an environment (staging, production, whatever).

+ +

This means that you can control your release cycle and decide what is getting pushed where and when.

+ +
+

Deployment becomes a business decision.

+
+ +

You can even rig up a big red button for your PM or whoever to push when it’s time to release!

+ +
+ +

So that’s it! That is your very basic introduction to CD. It’s just a way to automate some of the steps that your code goes through when you’re developing software and gives you control over your release schedule. Not so intimidating after all :).

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/17/continuous-delivery-beginners-guide/index.html b/pr-1714/2018/01/17/continuous-delivery-beginners-guide/index.html new file mode 100644 index 000000000..f6a559a06 --- /dev/null +++ b/pr-1714/2018/01/17/continuous-delivery-beginners-guide/index.html @@ -0,0 +1,280 @@ + + + + + + + + + + + + + + + + An absolute beginners guide to Continuous Delivery | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Beginners Guide to Continuous Delivery +
+ +
+ + +
+

An absolute beginners guide to Continuous Delivery

+

Erin Snyder

+

+

+
+ +
+ +

My first gig at Thoughtworks was as a Support Engineer for Mingle - an agile project management tool. When I joined, some of my instructors at the coding bootcamp I attended, tried to teach us how agile development works. Well, they tried. None of us really practiced agile besides having daily stand-ups where we talked about blockers and successes. Some of the practices I figured out on my own, but most of it, I learned from observing my team. And, that’s how I eventually learnt about continuous delivery too.

+ +

After working with Mingle, I expanded my support-net (it’s like a fishing net but made of empathy and clever workarounds instead of rope) to cover support for GoCD and SnapCI - both in the domain of Continuous Delivery and Release Management systems.

+ +

Those are very big intimidating words (worthy of capitalization even) and prior to this, I had no idea what any of that meant. I expect that a lot of people might be in the same position. Perhaps, you’ve heard of it and like me, found them intimidating. Hopefully, by the end of this post, I’d have demystified this for you. And I can’t promise that you’ll be ready to immediately jump into “doing CD”, but you’ll have a better idea (as I eventually did) of what ‘continuous delivery’ means and what the fuss is all about.

+ +

In this post, I decided to pour out my knowledge for the benefit of anyone who might not be familiar with such things. Experienced developers can take a break: this one’s for the new kids and people like me who come from non-traditional (no CS degree here!) backgrounds.

+ +

First of all, how does software even get made?

+ +

When I was attending a coding bootcamp, here was my process:

+ +
    +
  • An instructor told me to write some code.
    • +
  • I wrote the code.
    • +
  • I ran some tests to see if the code works.
    • +
  • If it didn't work, I’d try to fix it.
    • +
  • Sometimes the code worked - because, magic!
    • +
  • I submitted my code for review by my instructor, usually by issuing a pull request on GitHub, or by deploying to Heroku, or something.
    • +
  • Done. Go have a cookie!
    • +
+ +

In a workplace that practices agile development, it is a bit different. Here is your process:

+ +
    +
  • Identify a need (aka, What am I building and why am I building it?)
    • +
  • Flesh out the idea (What are the specifics? Create a blueprint.)
    • +
  • Design the thing (What features should it have? What user stories?)
    • +
  • Code the thing (Allocate tasks to designers, developers, etc)
    • +
  • Test the thing while you are coding the thing (Easier to fix it when it breaks)
    • +
  • Integrate your thing into existing code base and test that too (Did your thing break someone else’s thing?)
    • +
  • Deploy the thing to an environment, like staging or production (OMG it's live and everyone can see it!)
    • +
  • Maintain the thing (Bug fixes, documentation, etc)
    • +
  • Repeat
    • +
+ +

So, what does continuous deployment do?

+ +

Some of the above steps can be automated to make the whole process faster. The faster you push a bug fix or a new feature, the happier your customers will be.

+ +

When you use continuous deployment software, here is your process:

+ +
    +
  • Think up the idea
    • +
  • Flesh out the idea
    • +
  • Design it
    • +
  • Code it
    • +
  • Each time you make a commit, it triggers a build server to package the code and sends it off for testing. You should treat any commit as if it could cause your code to be deployed to production and released to your customers, unless you do continuous delivery. More on that in a minute!
    • +
  • Code is automatically deployed to different environments and tested (unit tests, functional tests, integration tests, etc). If any of the tests fail, the process stops.
    • +
  • Then it’s time to maintain your code, fix some bugs and write some documentation to help your lovely support people troubleshoot the thing. :)
    • +
  • Repeat
    • +
+ +

What was that about continuous delivery?

+ +

The only difference between continuous deployment and continuous delivery is a manual trigger on the deployment stage. In continuous delivery, a human being has to push the button to deploy to an environment (staging, production, whatever).

+ +

This means that you can control your release cycle and decide what is getting pushed where and when.

+ +
+

Deployment becomes a business decision.

+
+ +

You can even rig up a big red button for your PM or whoever to push when it’s time to release!

+ +
+ +

So that’s it! That is your very basic introduction to CD. It’s just a way to automate some of the steps that your code goes through when you’re developing software and gives you control over your release schedule. Not so intimidating after all :).

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/17/index.html b/pr-1714/2018/01/17/index.html new file mode 100644 index 000000000..102df7b2b --- /dev/null +++ b/pr-1714/2018/01/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/31.html b/pr-1714/2018/01/31.html new file mode 100644 index 000000000..b2a15a6be --- /dev/null +++ b/pr-1714/2018/01/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/31/continuous-delivery-metrics.html b/pr-1714/2018/01/31/continuous-delivery-metrics.html new file mode 100644 index 000000000..baaa0b1f5 --- /dev/null +++ b/pr-1714/2018/01/31/continuous-delivery-metrics.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + 4 Important Metrics for Continuous Delivery| GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Metrics for Continuous Delivery +
+ +
+ + +
+

4 Important Metrics for Continuous Delivery

+

Alison Polton-Simon

+

+

+
+ +
+ +
+

It's impossible to improve what you can't measure. – Peter Drucker

+
+ +

This quote reflects the importance of metrics in every domain right now. Intuitively, this statement resonates with all of us. How do you know if you're actually growing if you don't have the data to understand where you've been and where you're going? This blog post talks about the importance we see of metrics, particularly in continuous delivery.

+ +

How do metrics matter in the context of continuous delivery?

+ +

What lets you know if you've actually achieved a good state of continuous delivery? To understand the answers to these questions, the GoCD team interviewed consultants, developers, operations teams, and people at every intersection of DevOps. We also talked to business stakeholders, because part of successful continuous delivery is being able to collaborate successfully between business and technology, and being able to communicate the value of some of the underlying work that goes into the implementation of continuous delivery.

+ +

There are four metrics that we synthesized out of this that we think are really valuable:

+ +
    +
  • Number of deploy-ready builds
    • +
  • Cycle time
    • +
  • Mean time between failures
    • +
  • Mean time to recover
    • +
+ +

How many deploy-ready builds do you have?

+ +

For successful continuous delivery, you need routine commits, and specifically routine commits to master. If I'm committing all the time to my own personal branch, I'm not adding value to the code that's actually ready for production.

+ +

A good rate of deploy-ready builds also relies on having testing you can trust. One common anti-pattern we heard was the existence of testing that has to run for several hours, or even an entire day to do validation. In many cases these tests were unreliable, meaning that at the end of that period, you're no more certain than you were at the start. That becomes costly because it makes everyone very wary of ever releasing. Deploying software can feel like Russian Roulette.

+ +

This metric also emphasizes the importance of collaboration between product and engineering roles. Cross-functional teams must be able to create a roadmap such that at any point stories are broken up small enough that you can release them and deliver real value to users. If the product side isn't engaged in this, teams develop backlogs of large chunks of work that don't add any value until late in the game.

+ +

As a complement to careful roadmap planning, the development team should employ patterns like feature toggles, which allow features to be deployed without exposing them to customers.

+ +

What is your cycle time?

+ +

Long cycle time was the most common pain point we heard from developers. The time from when a commit is made, through testing and validation, to a deployment can be an enormous source of frustration for a developer. As an engineer, waiting for feedback requires disruptive context switching and represents wasted time. A light-hearted, but very real representation of this is a classic XKCD comic about sword fighting while waiting for code to compile.

+ +
+Waiting for code to compile +
+ +

This dead time doesn’t get you any closer to delivering real value to users, and can create a loss of focus. Improving a team’s cycle time relies on efficient testing, and on getting feedback as quickly as you can. Here are a few practices that can help improve your cycle time.

+ +
    +
  1. Running your unit tests early in your pipeline and your complex, longer running automated tests downstream, will provide essential feedback sooner, and save you time.
    2. +
  2. Passing dependencies from pipeline stage to pipeline stage can help avoid unnecessary rebuilding of artifacts, which can be really valuable.
    3. +
  3. Parallelizing your builds when possible also provides significant savings.
    4. +
  4. Lastly, make sure you've got the right build resources so that whatever builds you need to run, you have enough agents to do the job.
    5. +
+ +

What’s your mean time between failures and mean time to recover?

+ +

Mean time between failures and mean time to recover often go hand in hand because it is important to balance the two of them. Mean time between failures reminds the team to keep the build green whenever possible, and to avoid easy failures. However, only looking at mean time between failures and trying to avoid failure completely can result in teams becoming overly cautious and never releasing anything new. The core point of software development is to provide new value to users and make sure that we're serving their needs. Thus, a focus on mean time to recover – a metric that represents the ability to bounce back from a misstep – is a key counterbalance.

+ +

Achieving a good mean time between failures relies on getting feedback early on and making sure that thorough validation occurs in testing environments. These validations should be run on production-like environments with realistic data. Strong local builds are also crucial here.

+ +

Since failure is inevitable, it’s important to make sure that your mean time to recover is as quick as possible. How long does it take to get you back to a green build after you've had a pipeline failure, or after you've had a release that's failed? Robust monitoring of production is essential. Teams should learn about failures through your monitoring and alerts, not through customer complaints.

+ +

Drilling key practices like rolling back can also improve mean time to recover. Having an automated rollback process can buy you a little bit of time to understand where the issue occurs. Diagnosing the cause of an issue quickly also relies on informative logging that enables developers to pinpoint a problem when they’ve been paged at 2:00am.

+ +
+ +

Summary

+ +

Going back to Peter Drucker's quote, to improve anything, first you need to find a way to measure it and make it visible. This is why, having a dashboard and making metrics visible to the team gives them a sense of ownership and a sense of connection that is really valuable. On the other hand, I don't want to say that metrics are a panacea. There are definitely some meaningless metrics and vanity metrics out there. Ultimately, you want to incentivize people to look at hard problems, and where they can create meaning for the team or organization.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/31/continuous-delivery-metrics/index.html b/pr-1714/2018/01/31/continuous-delivery-metrics/index.html new file mode 100644 index 000000000..b2dcc21a0 --- /dev/null +++ b/pr-1714/2018/01/31/continuous-delivery-metrics/index.html @@ -0,0 +1,265 @@ + + + + + + + + + + + + + + + + 4 Important Metrics for Continuous Delivery| GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Metrics for Continuous Delivery +
+ +
+ + +
+

4 Important Metrics for Continuous Delivery

+

Alison Polton-Simon

+

+

+
+ +
+ +
+

It's impossible to improve what you can't measure. – Peter Drucker

+
+ +

This quote reflects the importance of metrics in every domain right now. Intuitively, this statement resonates with all of us. How do you know if you're actually growing if you don't have the data to understand where you've been and where you're going? This blog post talks about the importance we see of metrics, particularly in continuous delivery.

+ +

How do metrics matter in the context of continuous delivery?

+ +

What lets you know if you've actually achieved a good state of continuous delivery? To understand the answers to these questions, the GoCD team interviewed consultants, developers, operations teams, and people at every intersection of DevOps. We also talked to business stakeholders, because part of successful continuous delivery is being able to collaborate successfully between business and technology, and being able to communicate the value of some of the underlying work that goes into the implementation of continuous delivery.

+ +

There are four metrics that we synthesized out of this that we think are really valuable:

+ +
    +
  • Number of deploy-ready builds
    • +
  • Cycle time
    • +
  • Mean time between failures
    • +
  • Mean time to recover
    • +
+ +

How many deploy-ready builds do you have?

+ +

For successful continuous delivery, you need routine commits, and specifically routine commits to master. If I'm committing all the time to my own personal branch, I'm not adding value to the code that's actually ready for production.

+ +

A good rate of deploy-ready builds also relies on having testing you can trust. One common anti-pattern we heard was the existence of testing that has to run for several hours, or even an entire day to do validation. In many cases these tests were unreliable, meaning that at the end of that period, you're no more certain than you were at the start. That becomes costly because it makes everyone very wary of ever releasing. Deploying software can feel like Russian Roulette.

+ +

This metric also emphasizes the importance of collaboration between product and engineering roles. Cross-functional teams must be able to create a roadmap such that at any point stories are broken up small enough that you can release them and deliver real value to users. If the product side isn't engaged in this, teams develop backlogs of large chunks of work that don't add any value until late in the game.

+ +

As a complement to careful roadmap planning, the development team should employ patterns like feature toggles, which allow features to be deployed without exposing them to customers.

+ +

What is your cycle time?

+ +

Long cycle time was the most common pain point we heard from developers. The time from when a commit is made, through testing and validation, to a deployment can be an enormous source of frustration for a developer. As an engineer, waiting for feedback requires disruptive context switching and represents wasted time. A light-hearted, but very real representation of this is a classic XKCD comic about sword fighting while waiting for code to compile.

+ +
+Waiting for code to compile +
+ +

This dead time doesn’t get you any closer to delivering real value to users, and can create a loss of focus. Improving a team’s cycle time relies on efficient testing, and on getting feedback as quickly as you can. Here are a few practices that can help improve your cycle time.

+ +
    +
  1. Running your unit tests early in your pipeline and your complex, longer running automated tests downstream, will provide essential feedback sooner, and save you time.
    2. +
  2. Passing dependencies from pipeline stage to pipeline stage can help avoid unnecessary rebuilding of artifacts, which can be really valuable.
    3. +
  3. Parallelizing your builds when possible also provides significant savings.
    4. +
  4. Lastly, make sure you've got the right build resources so that whatever builds you need to run, you have enough agents to do the job.
    5. +
+ +

What’s your mean time between failures and mean time to recover?

+ +

Mean time between failures and mean time to recover often go hand in hand because it is important to balance the two of them. Mean time between failures reminds the team to keep the build green whenever possible, and to avoid easy failures. However, only looking at mean time between failures and trying to avoid failure completely can result in teams becoming overly cautious and never releasing anything new. The core point of software development is to provide new value to users and make sure that we're serving their needs. Thus, a focus on mean time to recover – a metric that represents the ability to bounce back from a misstep – is a key counterbalance.

+ +

Achieving a good mean time between failures relies on getting feedback early on and making sure that thorough validation occurs in testing environments. These validations should be run on production-like environments with realistic data. Strong local builds are also crucial here.

+ +

Since failure is inevitable, it’s important to make sure that your mean time to recover is as quick as possible. How long does it take to get you back to a green build after you've had a pipeline failure, or after you've had a release that's failed? Robust monitoring of production is essential. Teams should learn about failures through your monitoring and alerts, not through customer complaints.

+ +

Drilling key practices like rolling back can also improve mean time to recover. Having an automated rollback process can buy you a little bit of time to understand where the issue occurs. Diagnosing the cause of an issue quickly also relies on informative logging that enables developers to pinpoint a problem when they’ve been paged at 2:00am.

+ +
+ +

Summary

+ +

Going back to Peter Drucker's quote, to improve anything, first you need to find a way to measure it and make it visible. This is why, having a dashboard and making metrics visible to the team gives them a sense of ownership and a sense of connection that is really valuable. On the other hand, I don't want to say that metrics are a panacea. There are definitely some meaningless metrics and vanity metrics out there. Ultimately, you want to incentivize people to look at hard problems, and where they can create meaning for the team or organization.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/31/index.html b/pr-1714/2018/01/31/index.html new file mode 100644 index 000000000..f3a5a1735 --- /dev/null +++ b/pr-1714/2018/01/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/01/index.html b/pr-1714/2018/01/index.html new file mode 100644 index 000000000..1b2a6b962 --- /dev/null +++ b/pr-1714/2018/01/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02.html b/pr-1714/2018/02.html new file mode 100644 index 000000000..a4ea1c4eb --- /dev/null +++ b/pr-1714/2018/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02/13.html b/pr-1714/2018/02/13.html new file mode 100644 index 000000000..6c52f26a8 --- /dev/null +++ b/pr-1714/2018/02/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02/13/index.html b/pr-1714/2018/02/13/index.html new file mode 100644 index 000000000..2b22548d4 --- /dev/null +++ b/pr-1714/2018/02/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02/13/managing-build-versions-pipeline.html b/pr-1714/2018/02/13/managing-build-versions-pipeline.html new file mode 100644 index 000000000..fa112f207 --- /dev/null +++ b/pr-1714/2018/02/13/managing-build-versions-pipeline.html @@ -0,0 +1,330 @@ + + + + + + + + + + + + + + + + Managing Build Versions in your GoCD Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Managing build versions in your GoCD pipeline +
+ +
+ + +
+

Managing Build Versions in your GoCD Pipeline

+

Moritz Lenz

+

+ CD Hacks +

+
+ +
+ +

Let's say you're building your first GoCD continuous delivery pipline.

+ +

Typically the first step of a delivery pipeline is to build the software from source. For this post, a tiny web service will serve as an example, and we'll build Debian packages from that.

+ +

GoCD can poll a git repository for changes, and if it has changed, clone the repository on an agent machine. So the remaining task is to execute the actual build command, and collect the resulting package file (and optionally the .changes file).

+ +

Since describing each click through the GoCD web interface can be time consuming, let's talk about the XML configuration for the first pipeline instead. Here it is:

+ +
<pipelines group="deployment">
+ <pipeline name="package-info">
+   <materials>
+     <git url="https://github.com/moritz/package-info.git" dest="package-info" />
+   </materials>
+   <stage name="build" cleanWorkingDir="true">
+     <jobs>
+       <job name="build-deb" timeout="5">
+         <tasks>
+           <exec command="/bin/bash" workingdir="package-info">
+             <arg>-c</arg>
+             <arg>debuild -b -us -uc</arg>
+           </exec>
+         </tasks>
+         <artifacts>
+           <artifact src="version" />
+           <artifact src="package-info*_*" dest="package-info/" />
+         </artifacts>
+       </job>
+     </jobs>
+   </stage>
+ </pipeline>
+</pipelines>
+
+ +

The build command, debuild -b -us -uc, return exit code zero on success and a non-zero exit code on failure, which is the standard convention for UNIX commands, and the same that the GoCD job runner for system commands understands, so we don't have to take special care with error handling.

+ +

The debuild command is part of the devscripts package on Debian and Ubuntu, and we just assume that it is installed on the agent machine. If you have a heterogenous environment, you can use resources to limit the job to fitting agents.

+ +

The timeout="5" in the job tag specifies a timeout in minutes that applies when the build script hasn't produced any output for five minutes. It acts as a safeguard against infinitely looping builds.

+ +

The artifacts tag specifies files and wildcards that GoCD collecst and stores on the server. The use of a wildcard is both to account for the fact that the version number and thus the file name of the generated Debian package is variable, and to able to capture both the generated .deb and .changes file. The fixed destination path makes it easier to retrieve those artifacts later on without knowing the exact version number.

+ +

If you use the environments feature, you also need to add the pipeline and at least one fitting agent to an environment. To keep things simple, we'll skip that here.

+ +

After you configure the pipeline with the XML above, you may wait a bit. You'll see the pipeline turns green on the front page of GoCD's web interface!

+ +

We can celebrate the first small success!

+ +

Recycling version numbers is confusing

+ +

Here, there is a small problem with this build stage. The version number of the generated Debian package comes from the debian/changelog file, which is part of the source git repository. So each time a developer pushes a commit that doesn't increment the version, the build stage generates a binary that reuses the previous version number. Even if the developers had perfect discipline, pipelines and stages can be rerun with the same git +revision as before. The Debian tool chain very much assumes that new versions +of a package come with incremented version numbers, so the build pipeline +should do that.

+ +

Ways to increment build numbers

+ +

The simplest approach is to use the pipeline label as a version number, but it comes with two small problems:

+ +
    +
  • it is reused when the stage is rerun within the pipeline instance,
    • +
  • and it requires a GoCD configuration change for each manual version increment.
    • +
+ +

An approach that works faily well in practice is to use the latest git tag as the base version number, and then append the number of commits since the tag, followed by the pipeline counter and the stage counter, which GoCD conveniently supplies through environment variables.

+ +

Here is a small shell script that implements this version number increase, and then starts the build.

+ +
#!/bin/bash
+
+set -e
+set -o pipefail
+version=$(git describe --long | sed 's/-g[a-f\d]*$//')
+# Remove commit hash with leading "g"
+version=$(sed 's/-g[A-Fa-f0-9]*$//' <<< "$version")
+version="$version.${GO_PIPELINE_COUNTER:-0}.${GO_STAGE_COUNTER:-0}"
+
+DISTRIBUTION=${DISTRIBUTION:-jessie}
+
+echo $version
+echo $version > ../version
+
+DEBFULLNAME='Go Debian Build Agent' DEBEMAIL='go-noreply@example.com' debchange --newversion=$version  --force-distribution -b  --distribution="${DISTRIBUTION:-jessie}" 'New Version'
+debuild -b -us -uc
+
+ +

Since this is code that is required for building the software, it needs to be +version-controlled just like the other code. If you planned to only deploy a +single application, you could add it to its source repository. But most +organisations have multiple applications to deploy, and this script works for +all software that is deployed through Debian packages. So it makes sense to create +another git repository, and add it as a second material to the pipeilne, and to any other pipeline of the same structure.

+ +

Now each time a developer pushes a new commit without a tag, the number behind +the tag increases. Every rerun of the pipeline or the stage increments one of +the subsequent numbers in the version string. For a git tag 2016.01, the version number produced typically looks like 2016.01-42.4.1. Not really pretty, but it does fulfill the requirement of distinct and incrementing version numbers, and the first part can easily be influenced by the developer.

+ +

To make use of this script, we need to add the git repository with the tools as a second material:

+ +
<git url="https://github.com/moritz/deployment-utils.git" dest="deployment-utils" materialName="deployment-utils" />
+
+ +

And modify the shell task to invoke the script:

+ +
<exec command="/bin/bash" workingdir="package-info">
+  <arg>../deployment-utils/debian-autobuild</arg>
+</exec>
+
+ +

After triggering the pipeline in the web interface and waiting a bit, it turns green again, and this time generates a Debian package with a unique version string.

+ +

What's next?

+ +

After the build stage is in place, there are several possible next steps to drive your Continuous Delivery efforts:

+ +
    +
  • The next stage in the pipeline could add the freshly built package to a repository, making it available for installation on test servers.
    • +
  • The package build could be improved to run unit tests (for the package being built), ensuring that only software that has passed the unit tests, reach the 'testing' or 'staging' environment. Note that this doesn't require any changes in GoCD.
    • +
  • When multiple applications are to be built automatically, it makes sense to extract a template from the pipeline, so that configuring a pipeline for the next project becomes a simple matter of instantiating the template and defining a few parameters.
    • +
+ +

Do whatever is necessary to solve your pain points and save time.

+ +

About the author

+ +

This is guest post by Moritz Lenz, a software engineer and architect at noris network. He's currently writing a book on automating deployments.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02/13/managing-build-versions-pipeline/index.html b/pr-1714/2018/02/13/managing-build-versions-pipeline/index.html new file mode 100644 index 000000000..d9c57ffc4 --- /dev/null +++ b/pr-1714/2018/02/13/managing-build-versions-pipeline/index.html @@ -0,0 +1,330 @@ + + + + + + + + + + + + + + + + Managing Build Versions in your GoCD Pipeline | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Managing build versions in your GoCD pipeline +
+ +
+ + +
+

Managing Build Versions in your GoCD Pipeline

+

Moritz Lenz

+

+ CD Hacks +

+
+ +
+ +

Let's say you're building your first GoCD continuous delivery pipline.

+ +

Typically the first step of a delivery pipeline is to build the software from source. For this post, a tiny web service will serve as an example, and we'll build Debian packages from that.

+ +

GoCD can poll a git repository for changes, and if it has changed, clone the repository on an agent machine. So the remaining task is to execute the actual build command, and collect the resulting package file (and optionally the .changes file).

+ +

Since describing each click through the GoCD web interface can be time consuming, let's talk about the XML configuration for the first pipeline instead. Here it is:

+ +
<pipelines group="deployment">
+ <pipeline name="package-info">
+   <materials>
+     <git url="https://github.com/moritz/package-info.git" dest="package-info" />
+   </materials>
+   <stage name="build" cleanWorkingDir="true">
+     <jobs>
+       <job name="build-deb" timeout="5">
+         <tasks>
+           <exec command="/bin/bash" workingdir="package-info">
+             <arg>-c</arg>
+             <arg>debuild -b -us -uc</arg>
+           </exec>
+         </tasks>
+         <artifacts>
+           <artifact src="version" />
+           <artifact src="package-info*_*" dest="package-info/" />
+         </artifacts>
+       </job>
+     </jobs>
+   </stage>
+ </pipeline>
+</pipelines>
+
+ +

The build command, debuild -b -us -uc, return exit code zero on success and a non-zero exit code on failure, which is the standard convention for UNIX commands, and the same that the GoCD job runner for system commands understands, so we don't have to take special care with error handling.

+ +

The debuild command is part of the devscripts package on Debian and Ubuntu, and we just assume that it is installed on the agent machine. If you have a heterogenous environment, you can use resources to limit the job to fitting agents.

+ +

The timeout="5" in the job tag specifies a timeout in minutes that applies when the build script hasn't produced any output for five minutes. It acts as a safeguard against infinitely looping builds.

+ +

The artifacts tag specifies files and wildcards that GoCD collecst and stores on the server. The use of a wildcard is both to account for the fact that the version number and thus the file name of the generated Debian package is variable, and to able to capture both the generated .deb and .changes file. The fixed destination path makes it easier to retrieve those artifacts later on without knowing the exact version number.

+ +

If you use the environments feature, you also need to add the pipeline and at least one fitting agent to an environment. To keep things simple, we'll skip that here.

+ +

After you configure the pipeline with the XML above, you may wait a bit. You'll see the pipeline turns green on the front page of GoCD's web interface!

+ +

We can celebrate the first small success!

+ +

Recycling version numbers is confusing

+ +

Here, there is a small problem with this build stage. The version number of the generated Debian package comes from the debian/changelog file, which is part of the source git repository. So each time a developer pushes a commit that doesn't increment the version, the build stage generates a binary that reuses the previous version number. Even if the developers had perfect discipline, pipelines and stages can be rerun with the same git +revision as before. The Debian tool chain very much assumes that new versions +of a package come with incremented version numbers, so the build pipeline +should do that.

+ +

Ways to increment build numbers

+ +

The simplest approach is to use the pipeline label as a version number, but it comes with two small problems:

+ +
    +
  • it is reused when the stage is rerun within the pipeline instance,
    • +
  • and it requires a GoCD configuration change for each manual version increment.
    • +
+ +

An approach that works faily well in practice is to use the latest git tag as the base version number, and then append the number of commits since the tag, followed by the pipeline counter and the stage counter, which GoCD conveniently supplies through environment variables.

+ +

Here is a small shell script that implements this version number increase, and then starts the build.

+ +
#!/bin/bash
+
+set -e
+set -o pipefail
+version=$(git describe --long | sed 's/-g[a-f\d]*$//')
+# Remove commit hash with leading "g"
+version=$(sed 's/-g[A-Fa-f0-9]*$//' <<< "$version")
+version="$version.${GO_PIPELINE_COUNTER:-0}.${GO_STAGE_COUNTER:-0}"
+
+DISTRIBUTION=${DISTRIBUTION:-jessie}
+
+echo $version
+echo $version > ../version
+
+DEBFULLNAME='Go Debian Build Agent' DEBEMAIL='go-noreply@example.com' debchange --newversion=$version  --force-distribution -b  --distribution="${DISTRIBUTION:-jessie}" 'New Version'
+debuild -b -us -uc
+
+ +

Since this is code that is required for building the software, it needs to be +version-controlled just like the other code. If you planned to only deploy a +single application, you could add it to its source repository. But most +organisations have multiple applications to deploy, and this script works for +all software that is deployed through Debian packages. So it makes sense to create +another git repository, and add it as a second material to the pipeilne, and to any other pipeline of the same structure.

+ +

Now each time a developer pushes a new commit without a tag, the number behind +the tag increases. Every rerun of the pipeline or the stage increments one of +the subsequent numbers in the version string. For a git tag 2016.01, the version number produced typically looks like 2016.01-42.4.1. Not really pretty, but it does fulfill the requirement of distinct and incrementing version numbers, and the first part can easily be influenced by the developer.

+ +

To make use of this script, we need to add the git repository with the tools as a second material:

+ +
<git url="https://github.com/moritz/deployment-utils.git" dest="deployment-utils" materialName="deployment-utils" />
+
+ +

And modify the shell task to invoke the script:

+ +
<exec command="/bin/bash" workingdir="package-info">
+  <arg>../deployment-utils/debian-autobuild</arg>
+</exec>
+
+ +

After triggering the pipeline in the web interface and waiting a bit, it turns green again, and this time generates a Debian package with a unique version string.

+ +

What's next?

+ +

After the build stage is in place, there are several possible next steps to drive your Continuous Delivery efforts:

+ +
    +
  • The next stage in the pipeline could add the freshly built package to a repository, making it available for installation on test servers.
    • +
  • The package build could be improved to run unit tests (for the package being built), ensuring that only software that has passed the unit tests, reach the 'testing' or 'staging' environment. Note that this doesn't require any changes in GoCD.
    • +
  • When multiple applications are to be built automatically, it makes sense to extract a template from the pipeline, so that configuring a pipeline for the next project becomes a simple matter of instantiating the template and defining a few parameters.
    • +
+ +

Do whatever is necessary to solve your pain points and save time.

+ +

About the author

+ +

This is guest post by Moritz Lenz, a software engineer and architect at noris network. He's currently writing a book on automating deployments.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/02/index.html b/pr-1714/2018/02/index.html new file mode 100644 index 000000000..d3ff3e5c5 --- /dev/null +++ b/pr-1714/2018/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03.html b/pr-1714/2018/03.html new file mode 100644 index 000000000..56040fa50 --- /dev/null +++ b/pr-1714/2018/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03/21.html b/pr-1714/2018/03/21.html new file mode 100644 index 000000000..dd9a62505 --- /dev/null +++ b/pr-1714/2018/03/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes.html b/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes.html new file mode 100644 index 000000000..cdeba2475 --- /dev/null +++ b/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes.html @@ -0,0 +1,260 @@ + + + + + + + + + + + + + + + + Run GoCD on Kubernetes | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Kubernetes Helm Chart +
+ +
+ + +
+

Continuous delivery workflows on modern infrastructure - Run GoCD on Kubernetes

+

Sheroy Marker

+

+

+
+ +
+ +

We are excited to announce the release of our Kubernetes helm chart that will allow our users to run GoCD natively on Kubernetes.

+ +

GoCD is a best-of-breed continuous delivery tool that allows you to model complex continuous delivery workflows. Kubernetes has emerged as one of the most interesting application delivery platforms. Our upcoming releases will have features that allow GoCD users to model Docker based build workflows with deployments to Kubernetes - we’ll cover more about this later in the post.

+ +

Continuous Delivery with Kubernetes

+ +

An efficient continuous delivery (CD) workflow is key to enabling high performance teams deliver software frequently, and reliably. CD workflows are specific to an organization’s processes. One of the enablers of continuous delivery is a high level of automation with few manual interventions. And so, automation around delivery infrastructure is key to a successful CD workflow.

+ +

Kubernetes provides simple abstractions for designing deployments for modern application architectures without the need for a lot of ‘configuration management’ code. A powerful API makes it programmable and easily accessible to development teams. Though Kubernetes provides the platform to build self-service delivery infrastructure, it does not provide the facilities to build and deploy your applications.

+ +
+

GoCD gives you the flexibility to effectively represent CD pipelines that suit your organization’s processes. Kubernetes gives you a highly programmable delivery infrastructure platform. And together, they provide the foundation for a powerful Continuous Delivery platform.

+
+ +

We wanted our users to be able to leverage GoCD’s pipeline modeling capabilities with Kubernetes’ developer-centric APIs to enhance their deployment process. To do this, we planned our Kubernetes-related feature releases in two steps.

+ +

Step 1 (Current Release) : Run GoCD natively on Kubernetes

+ +

Provisioning GoCD Elastic Agents on a Kubernetes Cluster

+ +

Our first goal was to get GoCD to run natively on Kubernetes. In our latest release, we have provided our users with the ability to:

+ +
    +
  • Install GoCD as a Kubernetes native application with an officially supported helm chart
    • +
  • Scale GoCD agents seamlessly with the new ElasticAgent plugin that spins up agents on the fly in response to build workload
    • +
  • Design Docker-based build workflows using the Docker in Docker capability
    • +
+ +

Step 2 (Upcoming Releases): Model a Docker-based build workflow

+ +

GoCD deploying to a Kubernetes Cluster

+ +

Beyond enabling GoCD to run natively on Kubernetes, we are also working on giving our users the ability to fully leverage the container-based build workflow. Containerization provides a clean separation of concerns for managing applications. Docker and Kubernetes together, enable a standard and simplified CD workflow.

+ +

These upcoming features will allow our users to:

+ +
    +
  • +

    Use Docker images as build artifacts
    +Docker images are the artifacts that are generated and propagated in a Docker based build workflow. Our users will be able to designate Docker images generated during the build process as artifacts. GoCD will even publish and fetch Docker images from a registry of choice. Metadata regarding Docker image artifacts will be made available to the build context for use in downstream pipelines.

    +
    • +
  • +

    Deploy applications to a Kubernetes environment
    +Deployments to Kubernetes are based on deployment specifications that are hydrated with runtime configuration. This hydrated deployment specification is then applied to a Kubernetes cluster that performs the actual deployment of the application. This capability will allow our users to compose these deployments in a continuous delivery build pipeline.

    +
    • +
  • +

    Monitor the deployment and call it done once the services come up
    +Kubernetes provides a rich API to monitor the progress of a deployment and provide the status of running applications. With this capability, a GoCD build task will complete once the Kubernetes deployment has completed. This will allow for reliably triggering post-deployment stages.

    +
    • +
+ +
+ +

We've built GoCD to encompass the best CD practices. We’ve always tried to stay true to that with every release we make and the Kubernetes plugin is no exception.

+ +

Check out our documentation on how to start using GoCD on Kubernetes with our officially supported helm chart now.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes/index.html b/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes/index.html new file mode 100644 index 000000000..03a54fff7 --- /dev/null +++ b/pr-1714/2018/03/21/continuous-delivery-gocd-kubernetes/index.html @@ -0,0 +1,260 @@ + + + + + + + + + + + + + + + + Run GoCD on Kubernetes | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Kubernetes Helm Chart +
+ +
+ + +
+

Continuous delivery workflows on modern infrastructure - Run GoCD on Kubernetes

+

Sheroy Marker

+

+

+
+ +
+ +

We are excited to announce the release of our Kubernetes helm chart that will allow our users to run GoCD natively on Kubernetes.

+ +

GoCD is a best-of-breed continuous delivery tool that allows you to model complex continuous delivery workflows. Kubernetes has emerged as one of the most interesting application delivery platforms. Our upcoming releases will have features that allow GoCD users to model Docker based build workflows with deployments to Kubernetes - we’ll cover more about this later in the post.

+ +

Continuous Delivery with Kubernetes

+ +

An efficient continuous delivery (CD) workflow is key to enabling high performance teams deliver software frequently, and reliably. CD workflows are specific to an organization’s processes. One of the enablers of continuous delivery is a high level of automation with few manual interventions. And so, automation around delivery infrastructure is key to a successful CD workflow.

+ +

Kubernetes provides simple abstractions for designing deployments for modern application architectures without the need for a lot of ‘configuration management’ code. A powerful API makes it programmable and easily accessible to development teams. Though Kubernetes provides the platform to build self-service delivery infrastructure, it does not provide the facilities to build and deploy your applications.

+ +
+

GoCD gives you the flexibility to effectively represent CD pipelines that suit your organization’s processes. Kubernetes gives you a highly programmable delivery infrastructure platform. And together, they provide the foundation for a powerful Continuous Delivery platform.

+
+ +

We wanted our users to be able to leverage GoCD’s pipeline modeling capabilities with Kubernetes’ developer-centric APIs to enhance their deployment process. To do this, we planned our Kubernetes-related feature releases in two steps.

+ +

Step 1 (Current Release) : Run GoCD natively on Kubernetes

+ +

Provisioning GoCD Elastic Agents on a Kubernetes Cluster

+ +

Our first goal was to get GoCD to run natively on Kubernetes. In our latest release, we have provided our users with the ability to:

+ +
    +
  • Install GoCD as a Kubernetes native application with an officially supported helm chart
    • +
  • Scale GoCD agents seamlessly with the new ElasticAgent plugin that spins up agents on the fly in response to build workload
    • +
  • Design Docker-based build workflows using the Docker in Docker capability
    • +
+ +

Step 2 (Upcoming Releases): Model a Docker-based build workflow

+ +

GoCD deploying to a Kubernetes Cluster

+ +

Beyond enabling GoCD to run natively on Kubernetes, we are also working on giving our users the ability to fully leverage the container-based build workflow. Containerization provides a clean separation of concerns for managing applications. Docker and Kubernetes together, enable a standard and simplified CD workflow.

+ +

These upcoming features will allow our users to:

+ +
    +
  • +

    Use Docker images as build artifacts
    +Docker images are the artifacts that are generated and propagated in a Docker based build workflow. Our users will be able to designate Docker images generated during the build process as artifacts. GoCD will even publish and fetch Docker images from a registry of choice. Metadata regarding Docker image artifacts will be made available to the build context for use in downstream pipelines.

    +
    • +
  • +

    Deploy applications to a Kubernetes environment
    +Deployments to Kubernetes are based on deployment specifications that are hydrated with runtime configuration. This hydrated deployment specification is then applied to a Kubernetes cluster that performs the actual deployment of the application. This capability will allow our users to compose these deployments in a continuous delivery build pipeline.

    +
    • +
  • +

    Monitor the deployment and call it done once the services come up
    +Kubernetes provides a rich API to monitor the progress of a deployment and provide the status of running applications. With this capability, a GoCD build task will complete once the Kubernetes deployment has completed. This will allow for reliably triggering post-deployment stages.

    +
    • +
+ +
+ +

We've built GoCD to encompass the best CD practices. We’ve always tried to stay true to that with every release we make and the Kubernetes plugin is no exception.

+ +

Check out our documentation on how to start using GoCD on Kubernetes with our officially supported helm chart now.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03/21/index.html b/pr-1714/2018/03/21/index.html new file mode 100644 index 000000000..345888616 --- /dev/null +++ b/pr-1714/2018/03/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/03/index.html b/pr-1714/2018/03/index.html new file mode 100644 index 000000000..3ac552805 --- /dev/null +++ b/pr-1714/2018/03/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04.html b/pr-1714/2018/04.html new file mode 100644 index 000000000..3fe5997ef --- /dev/null +++ b/pr-1714/2018/04.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04/25.html b/pr-1714/2018/04/25.html new file mode 100644 index 000000000..805840425 --- /dev/null +++ b/pr-1714/2018/04/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices.html b/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices.html new file mode 100644 index 000000000..11e490b1b --- /dev/null +++ b/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices.html @@ -0,0 +1,290 @@ + + + + + + + + + + + + + + + + Five Considerations for Continuous Delivery of Microservices | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

5 Considerations for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

A microservice architecture builds software as suites of collaborating services. These architectures are generally accepted as a better way to build apps these days. +Continuous Delivery is an essential component of any software delivery practice. Regardless of the target deployment environment, you have to design a CD workflow to get software changes into production.

+ +

At Thoughtworks, while partnering with clients building business-critical software, we overcome many challenges around building CD workflows for microservices. In this blog series, I will share the considerations we keep in mind in architecture design and application development.

+ +

Microservices and Continuous Delivery

+ +

According to Martin Fowler, microservices architectures are “a particular way of designing software applications as suites of independently deployable services.” These architectures are prevalent these days for building applications based on distributed systems concepts.

+ +

Jez Humble, in his pioneering book describes continuous delivery as "the ability to get changes of all types - including new features, configuration, bug fixes, and experiments - into production, safely and quickly in a sustainable way."

+ +

Regardless of the target deployment environment or your architecture choice, monolithic architecture in the past or microservices these days, it’s important to design a continuous delivery workflow to get your changes into production. A CD workflow is central to a DevOps process, and spans well across various functions in an organization including your development, QA and IT operations.

+ +

Four Challenges for CD on Microservices

+ +
    +
  1. +

    Maintaining the integrity of complex distributed systems. Since you decompose a large monolithic system into smaller, more manageable microservices, the overall complexity of the system itself increases. You now have to deal with distributed systems concerns.

    +
    2. +
  2. +

    Safely and rapidly releasing features constantly. Managing frequent feature releases needs special consideration when your features could involve changes in one or many microservices.

    +
    3. +
  3. +

    Managing deployments of disparate technology stacks. Microservice environments often include disparate technology stacks for services. Managing a deployment process across these different stacks is challenging.

    +
    4. +
  4. +

    Process and tooling for deploying services independently and out of band. There are a lot of tools available to model CD workflows. It’s daunting to initially map out your CD workflow and pick tooling that best represents this workflow.

    +
    5. +
+ +

Five Considerations for CD on Microservices

+ +

There are five considerations I recommend keeping in mind when you design a CD workflow on microservices architectures. I will have an in-depth discussion for each of them in the following posts of this series. Here is just an overview:

+ +

1. Have an effective test strategy

+ +

Effective test strategy

+ +

Testing and verification of microservice systems is significantly more nuanced and complex than testing a traditional monolithic application. An effective test strategy needs to account for both testing individual services in isolation and the verification of overall system behavior.

+ +

For pre-production testing of services, especially in an isolated manner, traditional testing methodologies are still applicable and relevant. The test pyramid can still help you in maintaining a balance between the different types of tests. However, this style of testing has limited effectiveness when testing the aggregate of services. There are categories of errors that you can’t simulate in test environments, for example, issues caused by eventual consistency in a highly distributed system, hardware and network failures causing parts of the system to fail.

+ +

You have to supplement traditional testing techniques with techniques like synthetic user testing, lightweight user acceptance testing and fault injection testing.

+ +

2. Examine your CI practices

+ +

Continuous integration is a key practice in a successful continuous delivery strategy. Apart from the obvious considerations around build servers and build definitions, trunk based development and feature toggles are two key practices that go a long way in implementing a simple and robust CI process.

+ +

In trunk based development, developers collaborate on code in a single branch called “trunk.” The key benefit is to avoid drift in development branches and the resulting merge hell. This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably you aren’t doing continuous integration.

+ +

To do trunk based development, you need to have controls called feature toggles. Feature toggles enable multiple commits of a combination of WIP and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and testing sufficiently in pre-production environments. Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments.

+ +

Once you have a mechanism for maintaining feature toggles, you can use the same mechanism to introduce other categories of toggles like release toggles (to control access to unfinished code), Ops toggles (to control the behavior of production code), permissions toggles (to turn on specific behavior for privileged users), and experimental toggles (for multivariate testing - How well a feature is received before you make it permanent).

+ +

3. Plan your environments

+ +

Environments plan

+ +

An environment plan includes your sets of environments, the intended use of them, strategies to promote artifacts through these environments and toggle states on these environments.

+ +

First, think about what environments are needed and their intended use cases. Different groups in your organization will have different competing needs. When creating an environment, you should cater to all of these competing needs. Secondly, if possible, consider using cloud infrastructure to create environments dynamically. For example, use Kubernetes’ labels capability to create on the fly test environments for automated testing rather than have long lived environments. Thirdly, have an artifact promotion strategy. CD pipelines generate a lot of artifacts. You should you think about: how many artifacts to store, how many repositories you need, etc.

+ +

4. Manage configuration strategically

+ +

An application’s configuration includes everything that varies per deployment and should be stored separately from the code. How should you treat configuration when you have suites of microservices?

+ +

One technique we've seen to be useful is to manage deployment configuration centrally in repositories like Consul or Vault. Spreading deployment configurations across tools like Chef and the CD pipeline just makes it hard to understand and reason.

+ +

Another technique we use is to standardize processes for distributing configuration regardless of the technology stack of your services, and just let services handle the consuming of this configuration depending on the stack. For example, we generally use the 12-factor recommendations and avoid distributing configuration files.

+ +

And lastly, secrets like certificates need a governance process to ensure they are managed appropriately. This is usually a manual process but you need to think about it earlier and get it in place.

+ +

5. Prepare for things to go wrong

+ +

In microservices systems, multiple services get updated frequently, how do you respond when a deployment of a service introduces instability or bugs?

+ +

Roll forward, which means finding the root cause of a failure and applying the fix as soon as possible, is most times the best remediation response. A prerequisite for being able to do this is to ensure you have the capability to release from a hot fix branch straight to production. You may not want a fix to a production outage to go through the CD pipeline, depending on the time it takes for a change to make it through the pipeline.

+ +

Hotfix process

+ +

Rollbacks are always tricky in production systems. In most cases if the change is granular and can be reasoned about, it’s easy to rollback. But if the deployment includes changes that aren’t easy to reason about, e.g., DB changes, especially ones that make schema changes, you need to deploy DB changes separately from code changes in consecutive deployments to ensure backwards compatibility of DB changes with earlier versions of code.

+ +

Summary

+ +

This is the part 1 of our Continuous Delivery of Microservices blog series. We have talked about four challenges and five considerations for building CD pipelines on microservices architecture. In the next blog, I will have an in-depth discussion on the first consideration: testing strategy for a system based on microservices architectures.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices/index.html b/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices/index.html new file mode 100644 index 000000000..63e9ad776 --- /dev/null +++ b/pr-1714/2018/04/25/five-considerations-continuous-delivery-microservices/index.html @@ -0,0 +1,290 @@ + + + + + + + + + + + + + + + + Five Considerations for Continuous Delivery of Microservices | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

5 Considerations for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

A microservice architecture builds software as suites of collaborating services. These architectures are generally accepted as a better way to build apps these days. +Continuous Delivery is an essential component of any software delivery practice. Regardless of the target deployment environment, you have to design a CD workflow to get software changes into production.

+ +

At Thoughtworks, while partnering with clients building business-critical software, we overcome many challenges around building CD workflows for microservices. In this blog series, I will share the considerations we keep in mind in architecture design and application development.

+ +

Microservices and Continuous Delivery

+ +

According to Martin Fowler, microservices architectures are “a particular way of designing software applications as suites of independently deployable services.” These architectures are prevalent these days for building applications based on distributed systems concepts.

+ +

Jez Humble, in his pioneering book describes continuous delivery as "the ability to get changes of all types - including new features, configuration, bug fixes, and experiments - into production, safely and quickly in a sustainable way."

+ +

Regardless of the target deployment environment or your architecture choice, monolithic architecture in the past or microservices these days, it’s important to design a continuous delivery workflow to get your changes into production. A CD workflow is central to a DevOps process, and spans well across various functions in an organization including your development, QA and IT operations.

+ +

Four Challenges for CD on Microservices

+ +
    +
  1. +

    Maintaining the integrity of complex distributed systems. Since you decompose a large monolithic system into smaller, more manageable microservices, the overall complexity of the system itself increases. You now have to deal with distributed systems concerns.

    +
    2. +
  2. +

    Safely and rapidly releasing features constantly. Managing frequent feature releases needs special consideration when your features could involve changes in one or many microservices.

    +
    3. +
  3. +

    Managing deployments of disparate technology stacks. Microservice environments often include disparate technology stacks for services. Managing a deployment process across these different stacks is challenging.

    +
    4. +
  4. +

    Process and tooling for deploying services independently and out of band. There are a lot of tools available to model CD workflows. It’s daunting to initially map out your CD workflow and pick tooling that best represents this workflow.

    +
    5. +
+ +

Five Considerations for CD on Microservices

+ +

There are five considerations I recommend keeping in mind when you design a CD workflow on microservices architectures. I will have an in-depth discussion for each of them in the following posts of this series. Here is just an overview:

+ +

1. Have an effective test strategy

+ +

Effective test strategy

+ +

Testing and verification of microservice systems is significantly more nuanced and complex than testing a traditional monolithic application. An effective test strategy needs to account for both testing individual services in isolation and the verification of overall system behavior.

+ +

For pre-production testing of services, especially in an isolated manner, traditional testing methodologies are still applicable and relevant. The test pyramid can still help you in maintaining a balance between the different types of tests. However, this style of testing has limited effectiveness when testing the aggregate of services. There are categories of errors that you can’t simulate in test environments, for example, issues caused by eventual consistency in a highly distributed system, hardware and network failures causing parts of the system to fail.

+ +

You have to supplement traditional testing techniques with techniques like synthetic user testing, lightweight user acceptance testing and fault injection testing.

+ +

2. Examine your CI practices

+ +

Continuous integration is a key practice in a successful continuous delivery strategy. Apart from the obvious considerations around build servers and build definitions, trunk based development and feature toggles are two key practices that go a long way in implementing a simple and robust CI process.

+ +

In trunk based development, developers collaborate on code in a single branch called “trunk.” The key benefit is to avoid drift in development branches and the resulting merge hell. This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably you aren’t doing continuous integration.

+ +

To do trunk based development, you need to have controls called feature toggles. Feature toggles enable multiple commits of a combination of WIP and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and testing sufficiently in pre-production environments. Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments.

+ +

Once you have a mechanism for maintaining feature toggles, you can use the same mechanism to introduce other categories of toggles like release toggles (to control access to unfinished code), Ops toggles (to control the behavior of production code), permissions toggles (to turn on specific behavior for privileged users), and experimental toggles (for multivariate testing - How well a feature is received before you make it permanent).

+ +

3. Plan your environments

+ +

Environments plan

+ +

An environment plan includes your sets of environments, the intended use of them, strategies to promote artifacts through these environments and toggle states on these environments.

+ +

First, think about what environments are needed and their intended use cases. Different groups in your organization will have different competing needs. When creating an environment, you should cater to all of these competing needs. Secondly, if possible, consider using cloud infrastructure to create environments dynamically. For example, use Kubernetes’ labels capability to create on the fly test environments for automated testing rather than have long lived environments. Thirdly, have an artifact promotion strategy. CD pipelines generate a lot of artifacts. You should you think about: how many artifacts to store, how many repositories you need, etc.

+ +

4. Manage configuration strategically

+ +

An application’s configuration includes everything that varies per deployment and should be stored separately from the code. How should you treat configuration when you have suites of microservices?

+ +

One technique we've seen to be useful is to manage deployment configuration centrally in repositories like Consul or Vault. Spreading deployment configurations across tools like Chef and the CD pipeline just makes it hard to understand and reason.

+ +

Another technique we use is to standardize processes for distributing configuration regardless of the technology stack of your services, and just let services handle the consuming of this configuration depending on the stack. For example, we generally use the 12-factor recommendations and avoid distributing configuration files.

+ +

And lastly, secrets like certificates need a governance process to ensure they are managed appropriately. This is usually a manual process but you need to think about it earlier and get it in place.

+ +

5. Prepare for things to go wrong

+ +

In microservices systems, multiple services get updated frequently, how do you respond when a deployment of a service introduces instability or bugs?

+ +

Roll forward, which means finding the root cause of a failure and applying the fix as soon as possible, is most times the best remediation response. A prerequisite for being able to do this is to ensure you have the capability to release from a hot fix branch straight to production. You may not want a fix to a production outage to go through the CD pipeline, depending on the time it takes for a change to make it through the pipeline.

+ +

Hotfix process

+ +

Rollbacks are always tricky in production systems. In most cases if the change is granular and can be reasoned about, it’s easy to rollback. But if the deployment includes changes that aren’t easy to reason about, e.g., DB changes, especially ones that make schema changes, you need to deploy DB changes separately from code changes in consecutive deployments to ensure backwards compatibility of DB changes with earlier versions of code.

+ +

Summary

+ +

This is the part 1 of our Continuous Delivery of Microservices blog series. We have talked about four challenges and five considerations for building CD pipelines on microservices architecture. In the next blog, I will have an in-depth discussion on the first consideration: testing strategy for a system based on microservices architectures.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04/25/index.html b/pr-1714/2018/04/25/index.html new file mode 100644 index 000000000..d6e479331 --- /dev/null +++ b/pr-1714/2018/04/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/04/index.html b/pr-1714/2018/04/index.html new file mode 100644 index 000000000..3ff28acb8 --- /dev/null +++ b/pr-1714/2018/04/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05.html b/pr-1714/2018/05.html new file mode 100644 index 000000000..735dc22e9 --- /dev/null +++ b/pr-1714/2018/05.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/08.html b/pr-1714/2018/05/08.html new file mode 100644 index 000000000..78bf15ec0 --- /dev/null +++ b/pr-1714/2018/05/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 8 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy.html b/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy.html new file mode 100644 index 000000000..f234db25f --- /dev/null +++ b/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy.html @@ -0,0 +1,258 @@ + + + + + + + + + + + + + + + + Test Strategy for Microservices | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Test Strategy for Microservices +
+ +
+ + +
+

Test Strategy for Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the second post in the series - Continuous Delivery for Microservices. In my previous post, I gave an overview of five considerations for building CD pipelines on a microservices architecture. In this post, we’ll get deeper into test strategy.

+ +

Test Strategy

+ +

A microservices architecture involves many moving parts with different guarantees and failure modes. Testing and verification of these systems are significantly more nuanced and complex than testing a traditional monolithic application. An effective test strategy needs to account for both testing individual services in isolation and the verification of overall system behavior. You can broadly break testing down into two categories: pre-production testing and monitoring and testing in production.

+ +

Test Strategies for Microservices

+ +

Pre-production testing of services

+ +

Here’s a simple example where you have build pipelines for multiple services and you're testing a service in isolation. In this case, the traditional test pyramid helps to maintain a balance between the different types of tests.

+ +

In a typical test pyramid, you have:

+ +

Unit tests
+Tests that cover the smallest piece of testable functionality in your software.

+ +

Integration tests
+Integration tests, in this context, deal with testing integrations and interface defects for components within your service; these are more granular tests.

+ +

Component tests
+When you look at component tests for microservices, a component is a service that exposes certain functionalities. Therefore, component tests for microservice can just be acceptance tests for services and your tests need to validate whether the service provides the functionality that it promises to.

+ +

Contract tests
+Another category of tests that's very applicable to microservices are contract tests. They test the contracts of APIs of your services to see if the API is valid or if the microservice honors its API. A cool variation of these contract tests is consumer driven contract tests. These tests are written by consumer services of an API; the consumers codify this contract in a suite of tests that get run on every change to the API. That way, if a change to the API breaks a contract that one of its consumers expect, this breaking change is caught early in the CD pipeline.

+ +

End-to-end tests
+The test suites we discussed earlier are applicable to testing individual services. End-to-end tests, however, are more coarse-grained and try to test the functionality of an overall system. Depending on the deployment architecture you're going for, if you are deploying all of your services in a pre-production environment in an aggregate manner, you can run end-to-end tests there. Since end-to-end tests are usually brittle and take a long time to run, you’ll usually want to restrict the number of these tests to as few as possible. If you have microservices that are completely independent and don't get deployed to a pre-production test environment, then consider approaches that test in production.

+ +

Monitoring and testing in production

+ +

This traditional style of testing has its limitations. There are categories of errors that you can’t really simulate in test environments. Examples of these sorts of issues include issues caused by eventual consistency in a highly distributed system, and hardware and network failures causing parts of the system to fail. You have to supplement traditional testing techniques with techniques that allow you to profile and monitor systems in production effectively, and the ability to take remedial action in production when things do go wrong. In this post, I will focus on testing in production, and cover remediation strategy in a later part of this series.

+ +

There is a category of testing in production called fault-injection, which is introducing errors in a controlled manner in production to see if your system can hold up to those errors.

+ +

A variation of in-production testing are some specific deployment strategies that are popular in these environments:

+ +

Canary deployment
+Canary deployment is where you take a new release and release it to a certain subsection of your production infrastructure, see how well that goes, and keep increasing the footprint of the new service until the time you completely roll it out. If you face issues, you can start rolling back the new version of your service.

+ +

Canary deployments

+ +

Blue-Green deployment
+Blue-green deployments are similar, where you have a new footprint of your new service, and then you do some testing and route some traffic through it. If everything is fine, you switch over all of your traffic to the new instance of services, otherwise, you keep the old footprint going.

+ +

Blue green deployments

+ +

Multivariate testing
+Another interesting variation of this kind of testing is multivariate testing, where you're not really testing your new service against defects, instead, you are A/B testing new release features behind A/B testing toggles. The purpose of this type of testing is to see how well these features are received. You can decide roll it out to your entire set of users or make fixes where necessary.

+ +

Summary

+ +

This is part 2 of our Continuous Delivery for Microservices blog series. We have talked in depth about testing strategies for microservices, which include how to apply traditional testing pyramids to pre-production testing for microservices and also new techniques for production monitoring and testing. In my next post, we will talk about the second consideration: CI practices for microservices systems.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy/index.html b/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy/index.html new file mode 100644 index 000000000..f0bd88162 --- /dev/null +++ b/pr-1714/2018/05/08/continuous-delivery-microservices-test-strategy/index.html @@ -0,0 +1,258 @@ + + + + + + + + + + + + + + + + Test Strategy for Microservices | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Test Strategy for Microservices +
+ +
+ + +
+

Test Strategy for Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the second post in the series - Continuous Delivery for Microservices. In my previous post, I gave an overview of five considerations for building CD pipelines on a microservices architecture. In this post, we’ll get deeper into test strategy.

+ +

Test Strategy

+ +

A microservices architecture involves many moving parts with different guarantees and failure modes. Testing and verification of these systems are significantly more nuanced and complex than testing a traditional monolithic application. An effective test strategy needs to account for both testing individual services in isolation and the verification of overall system behavior. You can broadly break testing down into two categories: pre-production testing and monitoring and testing in production.

+ +

Test Strategies for Microservices

+ +

Pre-production testing of services

+ +

Here’s a simple example where you have build pipelines for multiple services and you're testing a service in isolation. In this case, the traditional test pyramid helps to maintain a balance between the different types of tests.

+ +

In a typical test pyramid, you have:

+ +

Unit tests
+Tests that cover the smallest piece of testable functionality in your software.

+ +

Integration tests
+Integration tests, in this context, deal with testing integrations and interface defects for components within your service; these are more granular tests.

+ +

Component tests
+When you look at component tests for microservices, a component is a service that exposes certain functionalities. Therefore, component tests for microservice can just be acceptance tests for services and your tests need to validate whether the service provides the functionality that it promises to.

+ +

Contract tests
+Another category of tests that's very applicable to microservices are contract tests. They test the contracts of APIs of your services to see if the API is valid or if the microservice honors its API. A cool variation of these contract tests is consumer driven contract tests. These tests are written by consumer services of an API; the consumers codify this contract in a suite of tests that get run on every change to the API. That way, if a change to the API breaks a contract that one of its consumers expect, this breaking change is caught early in the CD pipeline.

+ +

End-to-end tests
+The test suites we discussed earlier are applicable to testing individual services. End-to-end tests, however, are more coarse-grained and try to test the functionality of an overall system. Depending on the deployment architecture you're going for, if you are deploying all of your services in a pre-production environment in an aggregate manner, you can run end-to-end tests there. Since end-to-end tests are usually brittle and take a long time to run, you’ll usually want to restrict the number of these tests to as few as possible. If you have microservices that are completely independent and don't get deployed to a pre-production test environment, then consider approaches that test in production.

+ +

Monitoring and testing in production

+ +

This traditional style of testing has its limitations. There are categories of errors that you can’t really simulate in test environments. Examples of these sorts of issues include issues caused by eventual consistency in a highly distributed system, and hardware and network failures causing parts of the system to fail. You have to supplement traditional testing techniques with techniques that allow you to profile and monitor systems in production effectively, and the ability to take remedial action in production when things do go wrong. In this post, I will focus on testing in production, and cover remediation strategy in a later part of this series.

+ +

There is a category of testing in production called fault-injection, which is introducing errors in a controlled manner in production to see if your system can hold up to those errors.

+ +

A variation of in-production testing are some specific deployment strategies that are popular in these environments:

+ +

Canary deployment
+Canary deployment is where you take a new release and release it to a certain subsection of your production infrastructure, see how well that goes, and keep increasing the footprint of the new service until the time you completely roll it out. If you face issues, you can start rolling back the new version of your service.

+ +

Canary deployments

+ +

Blue-Green deployment
+Blue-green deployments are similar, where you have a new footprint of your new service, and then you do some testing and route some traffic through it. If everything is fine, you switch over all of your traffic to the new instance of services, otherwise, you keep the old footprint going.

+ +

Blue green deployments

+ +

Multivariate testing
+Another interesting variation of this kind of testing is multivariate testing, where you're not really testing your new service against defects, instead, you are A/B testing new release features behind A/B testing toggles. The purpose of this type of testing is to see how well these features are received. You can decide roll it out to your entire set of users or make fixes where necessary.

+ +

Summary

+ +

This is part 2 of our Continuous Delivery for Microservices blog series. We have talked in depth about testing strategies for microservices, which include how to apply traditional testing pyramids to pre-production testing for microservices and also new techniques for production monitoring and testing. In my next post, we will talk about the second consideration: CI practices for microservices systems.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/08/index.html b/pr-1714/2018/05/08/index.html new file mode 100644 index 000000000..d74d5f732 --- /dev/null +++ b/pr-1714/2018/05/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 8 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/30.html b/pr-1714/2018/05/30.html new file mode 100644 index 000000000..4b1eebe50 --- /dev/null +++ b/pr-1714/2018/05/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development.html b/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development.html new file mode 100644 index 000000000..5f7dc2277 --- /dev/null +++ b/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the third post in the series - CD of Microservices. In the previous post, we talked about testing strategy for building CD pipelines on microservices architecture. In this post, we’ll get deep into CI practices.

+ +

Continuous integration

+ +

Continuous integration is a key practice in a successful continuous delivery strategy. Simply defined, it’s a practice that requires developers to integrate their code into a shared repository several times a day. Every checkin is verified by an automated build, allowing teams to detect problems early.

+ +

We’ll focus on two key practices, trunk based development and feature toggles. These two go a long way in implementing a simple and robust CI process.

+ +

Trunk Based Development

+ +

In trunk based development (TBD), developers collaborate on code in a single branch called “trunk”. The key benefit is to avoid drift in development branches and the resulting merge hell.

+ +

Trunk Based Development - TBD

+ +

This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably you aren’t doing continuous integration. In trunk based development, you should never find your trunk in a state where your CD process is unable to deploy. All code should be checked into trunk, built and tested constantly, and the codebase deployable on demand: all of this make CD a reality.

+ +

TBD results in much simpler CD workflows: you don’t have to build multiple branches in parallel, map branches to environments and re-test when the same features get merged to trunk. Simplifying workflows is very important in the context of microservices, as the complexity is exasperated as the number of microservices grows.

+ +

Feature toggles is an important technique for TBD.

+ +

Feature Toggles

+ +

Feature toggles enable commits of a combination of work-in-progress and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and tested sufficiently in pre-production environments.

+ +

Here is a very simple example. The team are working on four features for the same application: search, menu, sign-in and in-app chat. The in-app chat feature is incomplete (but you still check into trunk in TBD) or you find issues with the in-app chat in pre-production testing. With feature toggles, you can simply turn in-app chat off, even at run time.

+ +

Feature Toggles

+ +

Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments. They are just conditions in your code base.You should separate setting these toggles from the actual release process so that you can control it in run time.

+ +

Some things you should consider when implementing feature toggles:

+ +

Feature toggles should be short lived

+ +

Feature toggles should be discarded once a feature has gone through the development lifecycle and is turned on in production. They are considered to be a code debt that needs to be cleaned up.

+ +

Use tooling to manage toggles’ lifecycles

+ +

Don’t underestimate the amount of effort required to manage these toggles. You can easily run into hundreds of them. Use tooling which provides visibility into the list of toggles, what’s turned on in which environment, and which features will get turned on in production in the next release.

+ +

Consider building your own utilities

+ +

There isn't a lot of tooling out there, so consider writing your own utilities to solve some of these problems. Again, getting this tooling in place before you go down a microservice strategy is a wise thing to do.

+ +

Once you have a mechanism for maintaining feature toggles, you could use the same mechanism to introduce other categories of toggles:

+ +

Feature Toggles Permissions

+ +

This diagram is borrowed from my colleague Pete Hodgson, who has written a lot about toggles. In this diagram, release toggles is defined as toggles that control access to unfinished code, which is same as feature toggles.

+ +

Ops toggles control the behavior of production code. Retail sites that have heavy seasonal traffic use Ops toggles to provide a degraded experience when they have peak loads. For example, when Apple is releasing a new iPhone and it's getting a crazy amount of traffic coming in just to buy the iPhone, they can turn off features like user recommendations during peak time to support the sales transactions.

+ +

Permissions toggles are used to turn on specific behavior for privileged users, such as admin features, or provide a guest user browsing experience.

+ +

Experimental toggles are used for multivariate testing. It is used to test how well a feature is received before you make it permanent. It's the same as A/B testing.

+ +

One thing to note is that each of these categories of toggles has a very different lifecycle and different way to be turned on and off. You need to plan accordingly. Release toggles generally are more short-lived and only live for the duration of a few releases. Once the feature is completely released, you get rid of the toggle and remove your technical debt. An ops toggle is used frequently for functionality in production, so it lives for much longer.

+ +

Summary

+

This is the part 3 of our CD of Microservices blog series. We have talked in depth about CI practices, in particular trunk based deployment and feature toggles. In the next post, we will talk about the third consideration: environment strategy.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/index.html b/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/index.html new file mode 100644 index 000000000..b6347d33a --- /dev/null +++ b/pr-1714/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/index.html @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the third post in the series - CD of Microservices. In the previous post, we talked about testing strategy for building CD pipelines on microservices architecture. In this post, we’ll get deep into CI practices.

+ +

Continuous integration

+ +

Continuous integration is a key practice in a successful continuous delivery strategy. Simply defined, it’s a practice that requires developers to integrate their code into a shared repository several times a day. Every checkin is verified by an automated build, allowing teams to detect problems early.

+ +

We’ll focus on two key practices, trunk based development and feature toggles. These two go a long way in implementing a simple and robust CI process.

+ +

Trunk Based Development

+ +

In trunk based development (TBD), developers collaborate on code in a single branch called “trunk”. The key benefit is to avoid drift in development branches and the resulting merge hell.

+ +

Trunk Based Development - TBD

+ +

This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably you aren’t doing continuous integration. In trunk based development, you should never find your trunk in a state where your CD process is unable to deploy. All code should be checked into trunk, built and tested constantly, and the codebase deployable on demand: all of this make CD a reality.

+ +

TBD results in much simpler CD workflows: you don’t have to build multiple branches in parallel, map branches to environments and re-test when the same features get merged to trunk. Simplifying workflows is very important in the context of microservices, as the complexity is exasperated as the number of microservices grows.

+ +

Feature toggles is an important technique for TBD.

+ +

Feature Toggles

+ +

Feature toggles enable commits of a combination of work-in-progress and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and tested sufficiently in pre-production environments.

+ +

Here is a very simple example. The team are working on four features for the same application: search, menu, sign-in and in-app chat. The in-app chat feature is incomplete (but you still check into trunk in TBD) or you find issues with the in-app chat in pre-production testing. With feature toggles, you can simply turn in-app chat off, even at run time.

+ +

Feature Toggles

+ +

Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments. They are just conditions in your code base.You should separate setting these toggles from the actual release process so that you can control it in run time.

+ +

Some things you should consider when implementing feature toggles:

+ +

Feature toggles should be short lived

+ +

Feature toggles should be discarded once a feature has gone through the development lifecycle and is turned on in production. They are considered to be a code debt that needs to be cleaned up.

+ +

Use tooling to manage toggles’ lifecycles

+ +

Don’t underestimate the amount of effort required to manage these toggles. You can easily run into hundreds of them. Use tooling which provides visibility into the list of toggles, what’s turned on in which environment, and which features will get turned on in production in the next release.

+ +

Consider building your own utilities

+ +

There isn't a lot of tooling out there, so consider writing your own utilities to solve some of these problems. Again, getting this tooling in place before you go down a microservice strategy is a wise thing to do.

+ +

Once you have a mechanism for maintaining feature toggles, you could use the same mechanism to introduce other categories of toggles:

+ +

Feature Toggles Permissions

+ +

This diagram is borrowed from my colleague Pete Hodgson, who has written a lot about toggles. In this diagram, release toggles is defined as toggles that control access to unfinished code, which is same as feature toggles.

+ +

Ops toggles control the behavior of production code. Retail sites that have heavy seasonal traffic use Ops toggles to provide a degraded experience when they have peak loads. For example, when Apple is releasing a new iPhone and it's getting a crazy amount of traffic coming in just to buy the iPhone, they can turn off features like user recommendations during peak time to support the sales transactions.

+ +

Permissions toggles are used to turn on specific behavior for privileged users, such as admin features, or provide a guest user browsing experience.

+ +

Experimental toggles are used for multivariate testing. It is used to test how well a feature is received before you make it permanent. It's the same as A/B testing.

+ +

One thing to note is that each of these categories of toggles has a very different lifecycle and different way to be turned on and off. You need to plan accordingly. Release toggles generally are more short-lived and only live for the duration of a few releases. Once the feature is completely released, you get rid of the toggle and remove your technical debt. An ops toggle is used frequently for functionality in production, so it lives for much longer.

+ +

Summary

+

This is the part 3 of our CD of Microservices blog series. We have talked in depth about CI practices, in particular trunk based deployment and feature toggles. In the next post, we will talk about the third consideration: environment strategy.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/30/index.html b/pr-1714/2018/05/30/index.html new file mode 100644 index 000000000..984c3a5d6 --- /dev/null +++ b/pr-1714/2018/05/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/05/index.html b/pr-1714/2018/05/index.html new file mode 100644 index 000000000..caf6bae3f --- /dev/null +++ b/pr-1714/2018/05/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06.html b/pr-1714/2018/06.html new file mode 100644 index 000000000..6cd437281 --- /dev/null +++ b/pr-1714/2018/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06/12.html b/pr-1714/2018/06/12.html new file mode 100644 index 000000000..08a3f2486 --- /dev/null +++ b/pr-1714/2018/06/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 12 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06/12/cd-microservices-environment-strategy.html b/pr-1714/2018/06/12/cd-microservices-environment-strategy.html new file mode 100644 index 000000000..5c16e1482 --- /dev/null +++ b/pr-1714/2018/06/12/cd-microservices-environment-strategy.html @@ -0,0 +1,250 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Environment Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

Environment Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the fourth post in the series - CD of Microservices. In the previous post, we talked in depth about CI practices, in particular trunk based deployment and feature toggles. In this post, we’ll discuss environment strategy.

+ +

Environment plan

+ +

In some organizations people don’t realize the importance of an environment plan until they have too many environments and maintaining them becomes overwhelming.

+ +

An environment plan communicates the various environments that are involved in the path to production and their intended uses. It also communicates how your artifacts are promoted and the toggle states on these environments.

+ +

You can start with thinking about what environments need to be created upfront and talking about the intended use cases for these environments. Different groups in your organization will have different competing needs. Your environment plan should accommodate the needs from different parties.

+ +

Artifact promotion

+ +

Artifacts are one of many kinds of tangible by-products produced during the development of software. Some of these artifacts are text files like test and coverage reports. Some of these artifacts are binary artifacts like npm packages, jar files, and AMI machine images, which are built once and propagated along the CD pipelines for deployment in downstream environments.

+ +

CD pipelines generate a lot of artifacts. Before you know it, you're getting into terabytes, or tens of terabytes of generated artifacts. It's important to think through an artifact promotion strategy, which deals with where these artifacts are stored, how many are retained, and how you do clean-up.

+ +

Environment Plan for Continuous Delivery

+ +

The diagram above shows you an environment plan which factors in an artifact promotion strategy. From the plan you can see the environments that exist in the CD pipeline, with different colored arrows depicting different artifact promotion strategies. Early on in this pipeline, we generate artifacts that go to an artifact repository that has a more aggressive clean-up strategy, so we don't really retain too many of those environments. As you go further down this pipeline, artifacts are verified and more robust and you may want to keep these for a little longer, so you could keep them in a store with a different retention policy.

+ +

Dynamic environments

+ +

Environments are expensive and cumbersome to maintain. One way to make the process simpler and less expensive is to create environments on the fly. For example, when running functional tests, you can provision a functional test environment on demand, then clean it up right after your test is done.

+ +

To do this, you need use IaaC techniques to script all aspects of environment provisioning. Here are the benefits of doing this:

+ +

Parity with production +If you create all environments dynamically based on automation, you will use exactly the same way to create testing and staging environments. The scale and nature of infrastructure may be different, but the footprint of the environment remains the same.

+ +

Prevent drift +If you have manual processes and manual installations, you can't really ensure that two environments are the same. But using a script to create short-lived dynamic environments prevents drift.

+ +

Efficient use of hardware and infrastructure +Only creating an environment when you need it and cleaning up dynamically optimizes utilization and saves infrastructure costs.

+ +

Technologies such as container schedulers are all the rage these days for deploying and running applications. The diagram below is an example of a Dock - a Docker based build workflow with Kubernetes.

+ +

Environment Plan Dynamic Provisioning for Continuous Delivery

+ +

The CI aspect of this pipeline, which is the build pipeline on the left, generates Docker images. The artifacts from this pipeline, which are Docker images, are stored in a Docker registry. Further downstream, deploy environments deploy directly to Kubernetes. You can leverage features of Kubernetes like its concept of labels to provision environments on the fly.

+ +

Summary

+ +

This is the part 4 of our CD of Microservices blog series. We have talked about environment strategy including artifact promotion and leveraging modern infrastructure for dynamic environments. In the next post, we will talk about the fourth consideration: configuration strategy.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06/12/cd-microservices-environment-strategy/index.html b/pr-1714/2018/06/12/cd-microservices-environment-strategy/index.html new file mode 100644 index 000000000..ce953ee02 --- /dev/null +++ b/pr-1714/2018/06/12/cd-microservices-environment-strategy/index.html @@ -0,0 +1,250 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Environment Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices +
+ +
+ + +
+

Environment Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the fourth post in the series - CD of Microservices. In the previous post, we talked in depth about CI practices, in particular trunk based deployment and feature toggles. In this post, we’ll discuss environment strategy.

+ +

Environment plan

+ +

In some organizations people don’t realize the importance of an environment plan until they have too many environments and maintaining them becomes overwhelming.

+ +

An environment plan communicates the various environments that are involved in the path to production and their intended uses. It also communicates how your artifacts are promoted and the toggle states on these environments.

+ +

You can start with thinking about what environments need to be created upfront and talking about the intended use cases for these environments. Different groups in your organization will have different competing needs. Your environment plan should accommodate the needs from different parties.

+ +

Artifact promotion

+ +

Artifacts are one of many kinds of tangible by-products produced during the development of software. Some of these artifacts are text files like test and coverage reports. Some of these artifacts are binary artifacts like npm packages, jar files, and AMI machine images, which are built once and propagated along the CD pipelines for deployment in downstream environments.

+ +

CD pipelines generate a lot of artifacts. Before you know it, you're getting into terabytes, or tens of terabytes of generated artifacts. It's important to think through an artifact promotion strategy, which deals with where these artifacts are stored, how many are retained, and how you do clean-up.

+ +

Environment Plan for Continuous Delivery

+ +

The diagram above shows you an environment plan which factors in an artifact promotion strategy. From the plan you can see the environments that exist in the CD pipeline, with different colored arrows depicting different artifact promotion strategies. Early on in this pipeline, we generate artifacts that go to an artifact repository that has a more aggressive clean-up strategy, so we don't really retain too many of those environments. As you go further down this pipeline, artifacts are verified and more robust and you may want to keep these for a little longer, so you could keep them in a store with a different retention policy.

+ +

Dynamic environments

+ +

Environments are expensive and cumbersome to maintain. One way to make the process simpler and less expensive is to create environments on the fly. For example, when running functional tests, you can provision a functional test environment on demand, then clean it up right after your test is done.

+ +

To do this, you need use IaaC techniques to script all aspects of environment provisioning. Here are the benefits of doing this:

+ +

Parity with production +If you create all environments dynamically based on automation, you will use exactly the same way to create testing and staging environments. The scale and nature of infrastructure may be different, but the footprint of the environment remains the same.

+ +

Prevent drift +If you have manual processes and manual installations, you can't really ensure that two environments are the same. But using a script to create short-lived dynamic environments prevents drift.

+ +

Efficient use of hardware and infrastructure +Only creating an environment when you need it and cleaning up dynamically optimizes utilization and saves infrastructure costs.

+ +

Technologies such as container schedulers are all the rage these days for deploying and running applications. The diagram below is an example of a Dock - a Docker based build workflow with Kubernetes.

+ +

Environment Plan Dynamic Provisioning for Continuous Delivery

+ +

The CI aspect of this pipeline, which is the build pipeline on the left, generates Docker images. The artifacts from this pipeline, which are Docker images, are stored in a Docker registry. Further downstream, deploy environments deploy directly to Kubernetes. You can leverage features of Kubernetes like its concept of labels to provision environments on the fly.

+ +

Summary

+ +

This is the part 4 of our CD of Microservices blog series. We have talked about environment strategy including artifact promotion and leveraging modern infrastructure for dynamic environments. In the next post, we will talk about the fourth consideration: configuration strategy.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06/12/index.html b/pr-1714/2018/06/12/index.html new file mode 100644 index 000000000..e22acbd7d --- /dev/null +++ b/pr-1714/2018/06/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 12 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/06/index.html b/pr-1714/2018/06/index.html new file mode 100644 index 000000000..2f9b47920 --- /dev/null +++ b/pr-1714/2018/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07.html b/pr-1714/2018/07.html new file mode 100644 index 000000000..0e68dcd6b --- /dev/null +++ b/pr-1714/2018/07.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/17.html b/pr-1714/2018/07/17.html new file mode 100644 index 000000000..0aeccd319 --- /dev/null +++ b/pr-1714/2018/07/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting.html b/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting.html new file mode 100644 index 000000000..8dd98609d --- /dev/null +++ b/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting.html @@ -0,0 +1,282 @@ + + + + + + + + + + + + + + + + How to Works with Materials in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Materials in GoCD +
+ +
+ + +
+

How to Work with Materials in GoCD

+

Ankit Srivastava

+

+ CD Hacks +

+
+ +
+ +

In this series called CD Hacks, we introduce some quick and easy ways to get things done in GoCD. In this post, we’re going to cover how to use materials in GoCD.

+ +

A material is the 'cause' for a deployment pipeline to run. In most cases, it is a source code material repository (like Git, SVN, Mercurial, etc). A CD server continuously polls the configured materials and when a new change or commit is found, the corresponding pipelines are run or "triggered". A pipeline can even be configured with multiple materials.

+ +

The best way to control what changes get polled, and eventually trigger your pipeline, is by using the blacklisting/whitelisting feature for materials.

+ +

What is material blacklisting/whitelisting?

+ +

The blacklisting feature for materials in GoCD allows users to specify a file or a set of files for GoCD to ignore when it polls for new changes. The advantage of this is that repository changesets which contain blacklisted file/s will not trigger a pipeline automatically.

+ +

Sometimes, instead of ignoring files, you want to trigger a pipeline only for specific files or folder/s. GoCD allows you to invert the blacklisting feature to whitelist and poll only for changes to specific files

+ +

How does it work?

+ +

Let’s say you have a pipeline which has four different git materials.

+ +

Git - g1 : poll for new changes enabled and everything is blacklisted.
+Git - g2 : poll for new changes enabled and files under misc folder is blacklisted.
+Git - g3 : poll for new changes disabled with no blacklisting.
+Git - g4 : poll for new changes enabled with no blacklisting.

+ +

Blacklisting Materials in GoCD

+ +

Here’s a breakdown of how your pipeline behaves when there are commits made to the source code materials.

+ +

At 10:00 AM: Commit g1-c2 happens on g1. +Result: Pipeline does not trigger, because the material is fully blacklisted. But, the server sees that commit and will change its latest known commit to g1-c2.

+ +

At 10:05 AM: Commit g2-c2 happens on g2. +All changes in the commit affect only misc/abc/README.txt and misc/def/hello.txt

+ +

Result: Pipeline does not trigger, because path misc/*/ is blacklisted. But, the server sees that commit and will change its latest known commit to g2-c2.

+ +

At time 10:10 AM: Commit g3-c2 happens on g3.

+ +

Result: Pipeline does not trigger, because polling is turned off (and the server does not see that commit at all).

+ +

At time 10:15 AM: Commit g4-c2 happens on g4.

+ +

Result: Pipeline triggers - with g1-c2, g2-c2, g3-c1 and g4-c2. Since polling is turned off, g3-c2 has not been seen.

+ +

At time 10:20 AM: Commit g2-c3 happens on g2. Changes in the commit affect misc/abc/README.txt and src/test.rb

+ +

Result: Pipeline triggers - with g1-c2, g2-c3, g3-c1 and g4-c2. This is because src/test.rb does not match the blacklist misc/*/.

+ +

At time 10:25 AM: Pipeline is manually forced (click on "Play" button)

+ +

Result: Pipeline triggers - with g1-c2, g2-c3, g3-c2 and g4-c2. A manual trigger will forcibly update every material it knows of to the latest revision and triggers the pipeline.

+ +

In order to perform whitelisting, you choose “Invert the file filter, e.g. a blacklist becomes a whitelist instead.” option as shown below.

+ +

GoCD Fetch Materials

+ +

Server-side Material Blacklisting vs Fetch Materials

+ +

In blacklisting, all of the decisions about which materials to use for a pipeline trigger are configured on the GoCD server side and gives advantage to skip a pipeline trigger for set of files and folder.

+ +

The "Fetch Materials" option, on the other hand, affects only the Agent side. It's an option which allows the agent to not fetch / checkout / clone the materials at all, when run. By this time, the server has already decided which materials to use. The agent cannot control it.

+ +

GoCD Fetch Materials

+ +

When Fetch Material is set to False.
+<stage name="stagename" fetchMaterials="false">

+ +

“Fetch materials” option should be turned off only in cases where you don't care about the material at all. In some cases, you just want a timer trigger for a pipeline - and don't care about the revision of the checked out material - or you want to check out the material yourself for some reason. Then, you'd turn off "Fetch materials".

+ +

We believe incorporating the GoCD material blacklisting/whitelisting feature would help avoid undesirable pipeline builds and help save time.

+ +

You can visit help documentation to understand more about the material blacklisting/whitelisting feature.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting/index.html b/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting/index.html new file mode 100644 index 000000000..d09a2e7e8 --- /dev/null +++ b/pr-1714/2018/07/17/gocd-materials-blacklisting-whitelisting/index.html @@ -0,0 +1,282 @@ + + + + + + + + + + + + + + + + How to Works with Materials in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Materials in GoCD +
+ +
+ + +
+

How to Work with Materials in GoCD

+

Ankit Srivastava

+

+ CD Hacks +

+
+ +
+ +

In this series called CD Hacks, we introduce some quick and easy ways to get things done in GoCD. In this post, we’re going to cover how to use materials in GoCD.

+ +

A material is the 'cause' for a deployment pipeline to run. In most cases, it is a source code material repository (like Git, SVN, Mercurial, etc). A CD server continuously polls the configured materials and when a new change or commit is found, the corresponding pipelines are run or "triggered". A pipeline can even be configured with multiple materials.

+ +

The best way to control what changes get polled, and eventually trigger your pipeline, is by using the blacklisting/whitelisting feature for materials.

+ +

What is material blacklisting/whitelisting?

+ +

The blacklisting feature for materials in GoCD allows users to specify a file or a set of files for GoCD to ignore when it polls for new changes. The advantage of this is that repository changesets which contain blacklisted file/s will not trigger a pipeline automatically.

+ +

Sometimes, instead of ignoring files, you want to trigger a pipeline only for specific files or folder/s. GoCD allows you to invert the blacklisting feature to whitelist and poll only for changes to specific files

+ +

How does it work?

+ +

Let’s say you have a pipeline which has four different git materials.

+ +

Git - g1 : poll for new changes enabled and everything is blacklisted.
+Git - g2 : poll for new changes enabled and files under misc folder is blacklisted.
+Git - g3 : poll for new changes disabled with no blacklisting.
+Git - g4 : poll for new changes enabled with no blacklisting.

+ +

Blacklisting Materials in GoCD

+ +

Here’s a breakdown of how your pipeline behaves when there are commits made to the source code materials.

+ +

At 10:00 AM: Commit g1-c2 happens on g1. +Result: Pipeline does not trigger, because the material is fully blacklisted. But, the server sees that commit and will change its latest known commit to g1-c2.

+ +

At 10:05 AM: Commit g2-c2 happens on g2. +All changes in the commit affect only misc/abc/README.txt and misc/def/hello.txt

+ +

Result: Pipeline does not trigger, because path misc/*/ is blacklisted. But, the server sees that commit and will change its latest known commit to g2-c2.

+ +

At time 10:10 AM: Commit g3-c2 happens on g3.

+ +

Result: Pipeline does not trigger, because polling is turned off (and the server does not see that commit at all).

+ +

At time 10:15 AM: Commit g4-c2 happens on g4.

+ +

Result: Pipeline triggers - with g1-c2, g2-c2, g3-c1 and g4-c2. Since polling is turned off, g3-c2 has not been seen.

+ +

At time 10:20 AM: Commit g2-c3 happens on g2. Changes in the commit affect misc/abc/README.txt and src/test.rb

+ +

Result: Pipeline triggers - with g1-c2, g2-c3, g3-c1 and g4-c2. This is because src/test.rb does not match the blacklist misc/*/.

+ +

At time 10:25 AM: Pipeline is manually forced (click on "Play" button)

+ +

Result: Pipeline triggers - with g1-c2, g2-c3, g3-c2 and g4-c2. A manual trigger will forcibly update every material it knows of to the latest revision and triggers the pipeline.

+ +

In order to perform whitelisting, you choose “Invert the file filter, e.g. a blacklist becomes a whitelist instead.” option as shown below.

+ +

GoCD Fetch Materials

+ +

Server-side Material Blacklisting vs Fetch Materials

+ +

In blacklisting, all of the decisions about which materials to use for a pipeline trigger are configured on the GoCD server side and gives advantage to skip a pipeline trigger for set of files and folder.

+ +

The "Fetch Materials" option, on the other hand, affects only the Agent side. It's an option which allows the agent to not fetch / checkout / clone the materials at all, when run. By this time, the server has already decided which materials to use. The agent cannot control it.

+ +

GoCD Fetch Materials

+ +

When Fetch Material is set to False.
+<stage name="stagename" fetchMaterials="false">

+ +

“Fetch materials” option should be turned off only in cases where you don't care about the material at all. In some cases, you just want a timer trigger for a pipeline - and don't care about the revision of the checked out material - or you want to check out the material yourself for some reason. Then, you'd turn off "Fetch materials".

+ +

We believe incorporating the GoCD material blacklisting/whitelisting feature would help avoid undesirable pipeline builds and help save time.

+ +

You can visit help documentation to understand more about the material blacklisting/whitelisting feature.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/17/index.html b/pr-1714/2018/07/17/index.html new file mode 100644 index 000000000..53528248d --- /dev/null +++ b/pr-1714/2018/07/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/24.html b/pr-1714/2018/07/24.html new file mode 100644 index 000000000..3fdd0a536 --- /dev/null +++ b/pr-1714/2018/07/24.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 24 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/24/gocd-usage-analytics.html b/pr-1714/2018/07/24/gocd-usage-analytics.html new file mode 100644 index 000000000..d88e86e29 --- /dev/null +++ b/pr-1714/2018/07/24/gocd-usage-analytics.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Improving GoCD through usage analytics | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Usage Analytics +
+ +
+ + +
+

Improving GoCD through usage analytics

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

This blog has been edited on September 5, 2018 to include the data sharing updates released in GoCD 18.8.

+ +

GoCD started collecting and analyzing usage data in 18.7. If you are a GoCD System Administrator, you will be able to see a notification that pops up when you upgrade to version 18.7 or newer.

+ +

GoCD collecting usage analytics

+ +

Why are we collecting data?

+ +

We strive to understand our users better and provide the best product experience. Having data like number of pipelines and agents on an instance helps us optimize the GoCD experience for scale. We will never collect any private or personal information, and we will always be transparent about what is being shared. We take privacy seriously and can confirm that since this isn’t personally identifiable information, we comply with general data protection regulations (GDPR).

+ +

What data is being shared?

+ +

This is a rundown of all the information that we currently collect:

+ +
    +
  • Number of pipelines (pipeline_count): This allows the calculation of the average number of pipelines a GoCD instance has. Knowing the average number of pipelines helps us optimize the GoCD experience.
    • +
  • Number of agents (agent_count): This allows the calculation of the average number of agents a GoCD instance has. This will help us ensure GoCD can handle a reasonable number of requests from the average number of agents.
    • +
  • Oldest pipeline run time (oldest_pipeline_execution_time): This provides data around the age of the GoCD instance. Along with the number of pipelines data point, it helps establish an expected growth in the number of pipelines.
    • +
  • GoCD version (gocd_version): This is the version of GoCD the server is on.
    • +
  • Server ID (server_id): A randomly-generated identifier for this instance of GoCD to help correlate the data. This does not tie into any other ID in this instance.
    • +
  • Message version (message_version): This is the JSON Schema version number for this message.
    • +
  • Number of config repo pipelines (config_repo_pipeline_count): This is the number of pipelines added through config repo. It helps us gauge the effectiveness of the pipeline as code feature.
    • +
  • Number of elastic agent jobs (job_count and elastic_agent_job_count): These counts provides a measure of usefulness of elastic agent plugins. This helps decide which plugins to put more effort into and improve.
    • +
+ +

The data that gets sent looks like this:

+ +
{
+    "server_id": "2ab54f99-5fb5-4a5b-850b-ac790aba52b4",
+    "message_version": 2,
+    "data": {
+        "pipeline_count": 139,
+        "config_repo_pipeline_count": 63, 
+        "agent_count": 43,
+        "oldest_pipeline_execution_time": 1398322181981,
+        "job_count": 506,
+        "elastic_agent_job_count": [
+            { "plugin_id": "cd.go.contrib.elasticagent.kubernetes", "job_count": 2 }
+        ]
+        "gocd_version": "18.8.0-7433"
+    }
+}
+
+ +

Turning data sharing off

+ +

You can absolutely turn this off, if you’d like. The toggle to turn off the data collection is accessible by the GoCD System Administrator under Admin > Data Sharing. You’ll be able to change this at any time and don’t forget to hit ‘Save’ when you’re done.

+ +

GoCD usage analytics

+ +

If you have any questions or would like more clarity about how and why we collect this information, chat with us on our discussion forum.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/24/gocd-usage-analytics/index.html b/pr-1714/2018/07/24/gocd-usage-analytics/index.html new file mode 100644 index 000000000..d72dd2568 --- /dev/null +++ b/pr-1714/2018/07/24/gocd-usage-analytics/index.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Improving GoCD through usage analytics | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD Usage Analytics +
+ +
+ + +
+

Improving GoCD through usage analytics

+

GoCD Team

+

+ Announcements +

+
+ +
+ +

This blog has been edited on September 5, 2018 to include the data sharing updates released in GoCD 18.8.

+ +

GoCD started collecting and analyzing usage data in 18.7. If you are a GoCD System Administrator, you will be able to see a notification that pops up when you upgrade to version 18.7 or newer.

+ +

GoCD collecting usage analytics

+ +

Why are we collecting data?

+ +

We strive to understand our users better and provide the best product experience. Having data like number of pipelines and agents on an instance helps us optimize the GoCD experience for scale. We will never collect any private or personal information, and we will always be transparent about what is being shared. We take privacy seriously and can confirm that since this isn’t personally identifiable information, we comply with general data protection regulations (GDPR).

+ +

What data is being shared?

+ +

This is a rundown of all the information that we currently collect:

+ +
    +
  • Number of pipelines (pipeline_count): This allows the calculation of the average number of pipelines a GoCD instance has. Knowing the average number of pipelines helps us optimize the GoCD experience.
    • +
  • Number of agents (agent_count): This allows the calculation of the average number of agents a GoCD instance has. This will help us ensure GoCD can handle a reasonable number of requests from the average number of agents.
    • +
  • Oldest pipeline run time (oldest_pipeline_execution_time): This provides data around the age of the GoCD instance. Along with the number of pipelines data point, it helps establish an expected growth in the number of pipelines.
    • +
  • GoCD version (gocd_version): This is the version of GoCD the server is on.
    • +
  • Server ID (server_id): A randomly-generated identifier for this instance of GoCD to help correlate the data. This does not tie into any other ID in this instance.
    • +
  • Message version (message_version): This is the JSON Schema version number for this message.
    • +
  • Number of config repo pipelines (config_repo_pipeline_count): This is the number of pipelines added through config repo. It helps us gauge the effectiveness of the pipeline as code feature.
    • +
  • Number of elastic agent jobs (job_count and elastic_agent_job_count): These counts provides a measure of usefulness of elastic agent plugins. This helps decide which plugins to put more effort into and improve.
    • +
+ +

The data that gets sent looks like this:

+ +
{
+    "server_id": "2ab54f99-5fb5-4a5b-850b-ac790aba52b4",
+    "message_version": 2,
+    "data": {
+        "pipeline_count": 139,
+        "config_repo_pipeline_count": 63, 
+        "agent_count": 43,
+        "oldest_pipeline_execution_time": 1398322181981,
+        "job_count": 506,
+        "elastic_agent_job_count": [
+            { "plugin_id": "cd.go.contrib.elasticagent.kubernetes", "job_count": 2 }
+        ]
+        "gocd_version": "18.8.0-7433"
+    }
+}
+
+ +

Turning data sharing off

+ +

You can absolutely turn this off, if you’d like. The toggle to turn off the data collection is accessible by the GoCD System Administrator under Admin > Data Sharing. You’ll be able to change this at any time and don’t forget to hit ‘Save’ when you’re done.

+ +

GoCD usage analytics

+ +

If you have any questions or would like more clarity about how and why we collect this information, chat with us on our discussion forum.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/24/index.html b/pr-1714/2018/07/24/index.html new file mode 100644 index 000000000..8da53cf58 --- /dev/null +++ b/pr-1714/2018/07/24/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 24 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/31.html b/pr-1714/2018/07/31.html new file mode 100644 index 000000000..d0d26dcf3 --- /dev/null +++ b/pr-1714/2018/07/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/31/cd-microservices-configuration-strategy.html b/pr-1714/2018/07/31/cd-microservices-configuration-strategy.html new file mode 100644 index 000000000..b3726118c --- /dev/null +++ b/pr-1714/2018/07/31/cd-microservices-configuration-strategy.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Configuration Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices - Configuration Strategy +
+ +
+ + +
+

Configuration Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the fifth post in the series - Continuous Delivery of Microservices. In the previous post, we talked about environment strategy - including artifact promotion and ways to leverage modern infrastructure for dynamic environments. In this post, we will discuss configuration strategy.

+ +

Introduction

+ +

An application’s configuration is everything that is variable across deployment environments such as development, test, and production. Deploying the same code but switching out certain aspects (like URLs to backing services, database connection information, credentials to third-party services, etc.) are examples of what I mean by variables in this context. Such configuration should be stored separately from the application code.

+ +

In a system based on a microservices architecture, configuration also needs to be distributed across multiple services. There are a couple of ways to manage configurations in a distributed way: +*make configuration available in environment variables at deploy time, +*use an external configuration server product designed to expose configuration

+ +

Here are three things you should consider for your microservices configuration strategy:

+ +

1: Manage application configurations centrally

+ +

An external configuration server is a more appropriate system for managing application configuration and introduces cleaner separation of concerns.

+ +

The configuration management code (in chef or puppet) can solely be responsible for cluster management. With Chef, updating application configuration would require a slow convergence operation of the cluster. With an external configuration server, updates to application configuration can be more dynamic without the need to update any other aspect of the infrastructure.

+ +

Another added advantage of this approach is that it forces consistent practices with organizing configuration by application, and environment.

+ +

There are a number of purpose built external configuration servers you could consider. The Spring cloud config server is a good option for Spring applications. With support for multiple backends, you could integrate with industry standard KV stores such as Consul for non-sensitive configuration, and Vault for sensitive configuration.

+ +

2: Standard process for distributing configuration

+ +

For microservices systems, it is possible to have different tech stacks across the systems. If one is handling configuration differently for different stacks, then the complexity becomes hard to manage. Therefore, regardless of the tech stack of a microservice, configurations should be distributed to nodes in a standard manner.

+ +

A technique we use is to supply configuration as environment variables per The Twelve-Factor App methodology. As a rule of thumb, always avoid distributing configuration files.

+ +

The Twelve-Factor app is a manifesto that provides some guidelines to be followed while building cloud-native applications. These guidelines let you build applications that are cloud-friendly. To truly harness the advantages of a cloud environment, an application needs to embrace cloud concepts such as elastic scalability, independently deployable and operable services, and statelessness.

+ +

3: Governance policy around secrets

+ +

Secrets such as API keys, passwords, and certificates need to be accessed securely. You need a governance process to ensure secrets access is managed appropriately. One technique we recommend to store all secrets is a central secrets store. The central external configuration server could provide this capability.

+ +

This central store gives you traceability on how and when policies were changed. That traceability goes a long way in setting up a governance process.

+ +

A tool we recommend to store secrets is the Vault by Hashicorp.

+ +

Example:

+ +

Managing Configuration

+ +

This is an example of an architecture where configurations are stored centrally in a config server and updated by the CD pipeline and pushed out to service instances.

+ +

At the top there is an abstraction of the CD pipeline. This updates the config server and then the configuration from the config server is pushed to the service instances. At run time, service instances are aware of how to consume this configuration. When setting-up an architecture like this, you need to consider how many configuration servers should you have. We recommend that you have one configuration server per CD environment, or at least one for production and one for all other environments.

+ +

Summary

+ +

This is the part 5 of our CD for Microservices blog series. We have talked about configuration strategy for your CD pipeline. In the next post, we will talk about the last consideration: remediation strategies for when something goes wrong.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/31/cd-microservices-configuration-strategy/index.html b/pr-1714/2018/07/31/cd-microservices-configuration-strategy/index.html new file mode 100644 index 000000000..9138cd448 --- /dev/null +++ b/pr-1714/2018/07/31/cd-microservices-configuration-strategy/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Configuration Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices - Configuration Strategy +
+ +
+ + +
+

Configuration Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the fifth post in the series - Continuous Delivery of Microservices. In the previous post, we talked about environment strategy - including artifact promotion and ways to leverage modern infrastructure for dynamic environments. In this post, we will discuss configuration strategy.

+ +

Introduction

+ +

An application’s configuration is everything that is variable across deployment environments such as development, test, and production. Deploying the same code but switching out certain aspects (like URLs to backing services, database connection information, credentials to third-party services, etc.) are examples of what I mean by variables in this context. Such configuration should be stored separately from the application code.

+ +

In a system based on a microservices architecture, configuration also needs to be distributed across multiple services. There are a couple of ways to manage configurations in a distributed way: +*make configuration available in environment variables at deploy time, +*use an external configuration server product designed to expose configuration

+ +

Here are three things you should consider for your microservices configuration strategy:

+ +

1: Manage application configurations centrally

+ +

An external configuration server is a more appropriate system for managing application configuration and introduces cleaner separation of concerns.

+ +

The configuration management code (in chef or puppet) can solely be responsible for cluster management. With Chef, updating application configuration would require a slow convergence operation of the cluster. With an external configuration server, updates to application configuration can be more dynamic without the need to update any other aspect of the infrastructure.

+ +

Another added advantage of this approach is that it forces consistent practices with organizing configuration by application, and environment.

+ +

There are a number of purpose built external configuration servers you could consider. The Spring cloud config server is a good option for Spring applications. With support for multiple backends, you could integrate with industry standard KV stores such as Consul for non-sensitive configuration, and Vault for sensitive configuration.

+ +

2: Standard process for distributing configuration

+ +

For microservices systems, it is possible to have different tech stacks across the systems. If one is handling configuration differently for different stacks, then the complexity becomes hard to manage. Therefore, regardless of the tech stack of a microservice, configurations should be distributed to nodes in a standard manner.

+ +

A technique we use is to supply configuration as environment variables per The Twelve-Factor App methodology. As a rule of thumb, always avoid distributing configuration files.

+ +

The Twelve-Factor app is a manifesto that provides some guidelines to be followed while building cloud-native applications. These guidelines let you build applications that are cloud-friendly. To truly harness the advantages of a cloud environment, an application needs to embrace cloud concepts such as elastic scalability, independently deployable and operable services, and statelessness.

+ +

3: Governance policy around secrets

+ +

Secrets such as API keys, passwords, and certificates need to be accessed securely. You need a governance process to ensure secrets access is managed appropriately. One technique we recommend to store all secrets is a central secrets store. The central external configuration server could provide this capability.

+ +

This central store gives you traceability on how and when policies were changed. That traceability goes a long way in setting up a governance process.

+ +

A tool we recommend to store secrets is the Vault by Hashicorp.

+ +

Example:

+ +

Managing Configuration

+ +

This is an example of an architecture where configurations are stored centrally in a config server and updated by the CD pipeline and pushed out to service instances.

+ +

At the top there is an abstraction of the CD pipeline. This updates the config server and then the configuration from the config server is pushed to the service instances. At run time, service instances are aware of how to consume this configuration. When setting-up an architecture like this, you need to consider how many configuration servers should you have. We recommend that you have one configuration server per CD environment, or at least one for production and one for all other environments.

+ +

Summary

+ +

This is the part 5 of our CD for Microservices blog series. We have talked about configuration strategy for your CD pipeline. In the next post, we will talk about the last consideration: remediation strategies for when something goes wrong.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/31/index.html b/pr-1714/2018/07/31/index.html new file mode 100644 index 000000000..03afa2f5f --- /dev/null +++ b/pr-1714/2018/07/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/07/index.html b/pr-1714/2018/07/index.html new file mode 100644 index 000000000..36d7ad307 --- /dev/null +++ b/pr-1714/2018/07/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08.html b/pr-1714/2018/08.html new file mode 100644 index 000000000..ce0344825 --- /dev/null +++ b/pr-1714/2018/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08/21.html b/pr-1714/2018/08/21.html new file mode 100644 index 000000000..cc9f23dc1 --- /dev/null +++ b/pr-1714/2018/08/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08/21/index.html b/pr-1714/2018/08/21/index.html new file mode 100644 index 000000000..919ca0ba1 --- /dev/null +++ b/pr-1714/2018/08/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08/21/replacing-gocd-with-gocd.html b/pr-1714/2018/08/21/replacing-gocd-with-gocd.html new file mode 100644 index 000000000..ac74d28e0 --- /dev/null +++ b/pr-1714/2018/08/21/replacing-gocd-with-gocd.html @@ -0,0 +1,241 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Configuration Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Replacing GoCD with GoCD +
+ +
+ + +
+

Replacing GoCD with GoCD

+

Ken Mugrage

+

+

+
+ +
+ +

If you haven't tried GoCD lately, you haven't tried GoCD

+ +

In my role I get to attend a lot of different events in the software industry. When I do, I get to meet a lot of people using a lot of different products and services. I recently asked someone what they were using for continuous delivery. They told me they were using GoCD but were thinking about changing. Of course I asked him what they were going to change to. He told me there were going to replace GoCD… with GoCD.

+ +

I imagine the look on your face right now is pretty close to the look on mine when he told me. Total confusion.

+ +

Luckily, he explained:

+ +

They had configured GoCD taking advantage of configuration options and features available at that time, which was five years ago. As time went on, they found themselves wanting to use newer technologies such as public cloud and containers to speed up their builds while lowering their costs.

+ +

After a bit of research, they determined that what they needed was to take advantage of features added to GoCD over the past few years that they hadn't been using.

+ +

Elastic agents

+ +

Originally, when you set up GoCD, you install a server and build agents. Agents were running all the time for most people. You can still do that with GoCD, but you no longer have to. +GoCD now has functionality that we call elastic agents. With this functionality you can define what's needed in a build agent and tell a job in your pipeline which configuration to use. When you do this, GoCD will start agents when it needs them, and shut them down when it's done. This way, you can take advantage of things like cloud services to run agents only when you need them.

+ +

Configuration as Code

+ +

Another cool feature that came out in the past couple years is the ability to use external source code repositories for GoCD's configuration. Originally, all configuration for GoCD was stored internally. This was true whether you used the GUI or the API. This is very powerful, as it gives GoCD the ability to troubleshoot potential problems before they happen. This is still the way most people configure GoCD, but it's no longer the only option. +You can now store pipeline configuration in YAML or JSON files in your own external source code repository. This allows teams who wish to control everything about their build process, without having administrator access to GoCD. This also makes it easier for teams who update their pipeline configuration often.

+ +

Deployment options

+ +

Thoughtworks has created installers for the most popular operating systems for many years. This includes Windows, many distributions of Linux, Mac OS and more. In the past couple of years, the team has added official Docker images and AMIs. +And now we've added…

+ +

Native Kubernetes support

+ +

You can now deploy GoCD on Kubernetes using supported helm charts. You can use the new Kubernetes elastic agent functionality to scale your agents up and down the same way you would on cloud services. You can even store build artifacts such as Docker containers in external registries with the same functionality as the file-based artifact management available in GoCD.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08/21/replacing-gocd-with-gocd/index.html b/pr-1714/2018/08/21/replacing-gocd-with-gocd/index.html new file mode 100644 index 000000000..20d95c8e1 --- /dev/null +++ b/pr-1714/2018/08/21/replacing-gocd-with-gocd/index.html @@ -0,0 +1,241 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Configuration Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Replacing GoCD with GoCD +
+ +
+ + +
+

Replacing GoCD with GoCD

+

Ken Mugrage

+

+

+
+ +
+ +

If you haven't tried GoCD lately, you haven't tried GoCD

+ +

In my role I get to attend a lot of different events in the software industry. When I do, I get to meet a lot of people using a lot of different products and services. I recently asked someone what they were using for continuous delivery. They told me they were using GoCD but were thinking about changing. Of course I asked him what they were going to change to. He told me there were going to replace GoCD… with GoCD.

+ +

I imagine the look on your face right now is pretty close to the look on mine when he told me. Total confusion.

+ +

Luckily, he explained:

+ +

They had configured GoCD taking advantage of configuration options and features available at that time, which was five years ago. As time went on, they found themselves wanting to use newer technologies such as public cloud and containers to speed up their builds while lowering their costs.

+ +

After a bit of research, they determined that what they needed was to take advantage of features added to GoCD over the past few years that they hadn't been using.

+ +

Elastic agents

+ +

Originally, when you set up GoCD, you install a server and build agents. Agents were running all the time for most people. You can still do that with GoCD, but you no longer have to. +GoCD now has functionality that we call elastic agents. With this functionality you can define what's needed in a build agent and tell a job in your pipeline which configuration to use. When you do this, GoCD will start agents when it needs them, and shut them down when it's done. This way, you can take advantage of things like cloud services to run agents only when you need them.

+ +

Configuration as Code

+ +

Another cool feature that came out in the past couple years is the ability to use external source code repositories for GoCD's configuration. Originally, all configuration for GoCD was stored internally. This was true whether you used the GUI or the API. This is very powerful, as it gives GoCD the ability to troubleshoot potential problems before they happen. This is still the way most people configure GoCD, but it's no longer the only option. +You can now store pipeline configuration in YAML or JSON files in your own external source code repository. This allows teams who wish to control everything about their build process, without having administrator access to GoCD. This also makes it easier for teams who update their pipeline configuration often.

+ +

Deployment options

+ +

Thoughtworks has created installers for the most popular operating systems for many years. This includes Windows, many distributions of Linux, Mac OS and more. In the past couple of years, the team has added official Docker images and AMIs. +And now we've added…

+ +

Native Kubernetes support

+ +

You can now deploy GoCD on Kubernetes using supported helm charts. You can use the new Kubernetes elastic agent functionality to scale your agents up and down the same way you would on cloud services. You can even store build artifacts such as Docker containers in external registries with the same functionality as the file-based artifact management available in GoCD.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/08/index.html b/pr-1714/2018/08/index.html new file mode 100644 index 000000000..1d2b07d21 --- /dev/null +++ b/pr-1714/2018/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09.html b/pr-1714/2018/09.html new file mode 100644 index 000000000..afc5c71a0 --- /dev/null +++ b/pr-1714/2018/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09/11.html b/pr-1714/2018/09/11.html new file mode 100644 index 000000000..b5534cf3f --- /dev/null +++ b/pr-1714/2018/09/11.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 11 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09/11/cd-microservices-remediation-strategy.html b/pr-1714/2018/09/11/cd-microservices-remediation-strategy.html new file mode 100644 index 000000000..1cfd70396 --- /dev/null +++ b/pr-1714/2018/09/11/cd-microservices-remediation-strategy.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Remediation Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices - Remediation Strategy +
+ +
+ + +
+

Remediation Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the final post in the series - Continuous Delivery of Microservices. In the previous post, we talked about configuration strategy for your CD pipeline. In this post, we’ll discuss remediation strategies when something goes wrong.

+ +

Introduction

+ +

In systems based on microservices architecture, you have multiple services getting updated frequently. How do you respond when a deployment of a service introduces instability or bugs? How do you ensure changes to an API are backwards compatible? We try to answer these questions in this post.

+ +

Roll forward and hotfix

+ +

Roll forward is an emergency fix strategy: you introduced an issue, you find the root cause of the failure, apply the fix as soon as possible and then move forward. If the fix is a small contained change that doesn’t compromise the entire environment, roll forward is recommended.

+ +

Hotfix process

+ +

A prerequisite for roll forward is to ensure you have a comprehensive hotfix process already in place, so that you can bypass the CD pipeline to push changes from a hotfix branch directly to production. It is not uncommon to see a hotfix environment where these changes are deployed and tested before deploying to production.

+ +

Rollbacks and database refactoring

+ +

Rollback is another an emergency fix strategy when rolling forward is not an option due to maturity of the codebase, status of CD pipeline, or the team culture. In most cases, it’s easy to rollback if the change is granular and can be reasoned about. But if your deployment has changes to the database, especially to the database schema, you can't easily roll them back because transaction traffic could have been written into a new aspect of the schema. One common technique to deal with this is database refactoring.

+ +

A DB refactoring is a change made to the DB schema - the table structure or the data itself - while maintaining its informational semantics. A simple example: to rename a database table column, you take the following steps:

+ +
    +
  • add a new column with the new name
    • +
  • populate the new column with data
    • +
  • change the code to consume the new column
    • +
  • delete the old column
    • +
+ +

Each of these steps can be in a different deployment. By doing this, the existing application code still writes to the older column, while newer code makes use of the new column. Once all instances of the old code are migrated over to using the new column, you can safely delete the old column.

+ +

Database refactoring allows you to be able to rollback more robustly. You can apply database changes out of band from code changes. When you have a database change used by both new code and old code, you can release the version of the database changes in isolation, and then follow it with a deployment of the app code that actually uses that database change. Keep repeating cycles of this and when you need to rollback for emergency fix, it will be straightforward because the V1 version of the code still works with the V2 of that database.

+ +

Remediation Strategy

+ +

API backward compatibility

+ +

In microservices systems, you need to make changes to service APIs in a backward compatible manner. A change to the API should not break existing consumers of the API.

+ +

Ensure your API is backward compatible

+ +

For a single version strategy, ensure changes to an API are backwards compatible. That way careful consideration can be applied to major breaking changes.

+ +

One technique that is useful is to expose your API via GraphQL rather than REST to make backwards compatible changes to your APIs. GraphQL encourages backwards compatibility by allowing you to define the fields in the response in the query rather than letting the server define the format of the response.

+ +

Introducing service versioning

+ +

Versioning services adds significant complexity to the maintainability of a service. Multiple versions make a CD pipeline significantly more complex as multiple versions of a service need to be deployed and tested. We recommend as far as possible, start with a simple strategy of maintaining a single version of a service, along with Trunk Based Development. Maintaining multiple versions should be treated as a last resort and the operational complexities of managing multiple versions should be considered.

+ +

Summary

+ +

This is the last post of our CD of Microservices blog series. We hope you've enjoyed it. Please do leave a comment on the blog if you have any questions, we'd love to hear from you.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09/11/cd-microservices-remediation-strategy/index.html b/pr-1714/2018/09/11/cd-microservices-remediation-strategy/index.html new file mode 100644 index 000000000..a0fecff8b --- /dev/null +++ b/pr-1714/2018/09/11/cd-microservices-remediation-strategy/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Continuous Delivery of Microservices - Remediation Strategy | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Continuous Delivery of Microservices - Remediation Strategy +
+ +
+ + +
+

Remediation Strategy for Continuous Delivery of Microservices

+

Sheroy Marker

+

+ CD for Microservices +

+
+ +
+ +

This is the final post in the series - Continuous Delivery of Microservices. In the previous post, we talked about configuration strategy for your CD pipeline. In this post, we’ll discuss remediation strategies when something goes wrong.

+ +

Introduction

+ +

In systems based on microservices architecture, you have multiple services getting updated frequently. How do you respond when a deployment of a service introduces instability or bugs? How do you ensure changes to an API are backwards compatible? We try to answer these questions in this post.

+ +

Roll forward and hotfix

+ +

Roll forward is an emergency fix strategy: you introduced an issue, you find the root cause of the failure, apply the fix as soon as possible and then move forward. If the fix is a small contained change that doesn’t compromise the entire environment, roll forward is recommended.

+ +

Hotfix process

+ +

A prerequisite for roll forward is to ensure you have a comprehensive hotfix process already in place, so that you can bypass the CD pipeline to push changes from a hotfix branch directly to production. It is not uncommon to see a hotfix environment where these changes are deployed and tested before deploying to production.

+ +

Rollbacks and database refactoring

+ +

Rollback is another an emergency fix strategy when rolling forward is not an option due to maturity of the codebase, status of CD pipeline, or the team culture. In most cases, it’s easy to rollback if the change is granular and can be reasoned about. But if your deployment has changes to the database, especially to the database schema, you can't easily roll them back because transaction traffic could have been written into a new aspect of the schema. One common technique to deal with this is database refactoring.

+ +

A DB refactoring is a change made to the DB schema - the table structure or the data itself - while maintaining its informational semantics. A simple example: to rename a database table column, you take the following steps:

+ +
    +
  • add a new column with the new name
    • +
  • populate the new column with data
    • +
  • change the code to consume the new column
    • +
  • delete the old column
    • +
+ +

Each of these steps can be in a different deployment. By doing this, the existing application code still writes to the older column, while newer code makes use of the new column. Once all instances of the old code are migrated over to using the new column, you can safely delete the old column.

+ +

Database refactoring allows you to be able to rollback more robustly. You can apply database changes out of band from code changes. When you have a database change used by both new code and old code, you can release the version of the database changes in isolation, and then follow it with a deployment of the app code that actually uses that database change. Keep repeating cycles of this and when you need to rollback for emergency fix, it will be straightforward because the V1 version of the code still works with the V2 of that database.

+ +

Remediation Strategy

+ +

API backward compatibility

+ +

In microservices systems, you need to make changes to service APIs in a backward compatible manner. A change to the API should not break existing consumers of the API.

+ +

Ensure your API is backward compatible

+ +

For a single version strategy, ensure changes to an API are backwards compatible. That way careful consideration can be applied to major breaking changes.

+ +

One technique that is useful is to expose your API via GraphQL rather than REST to make backwards compatible changes to your APIs. GraphQL encourages backwards compatibility by allowing you to define the fields in the response in the query rather than letting the server define the format of the response.

+ +

Introducing service versioning

+ +

Versioning services adds significant complexity to the maintainability of a service. Multiple versions make a CD pipeline significantly more complex as multiple versions of a service need to be deployed and tested. We recommend as far as possible, start with a simple strategy of maintaining a single version of a service, along with Trunk Based Development. Maintaining multiple versions should be treated as a last resort and the operational complexities of managing multiple versions should be considered.

+ +

Summary

+ +

This is the last post of our CD of Microservices blog series. We hope you've enjoyed it. Please do leave a comment on the blog if you have any questions, we'd love to hear from you.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09/11/index.html b/pr-1714/2018/09/11/index.html new file mode 100644 index 000000000..dfa7b0822 --- /dev/null +++ b/pr-1714/2018/09/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 11 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/09/index.html b/pr-1714/2018/09/index.html new file mode 100644 index 000000000..d49dfe69f --- /dev/null +++ b/pr-1714/2018/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10.html b/pr-1714/2018/10.html new file mode 100644 index 000000000..93dbf84bc --- /dev/null +++ b/pr-1714/2018/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/16.html b/pr-1714/2018/10/16.html new file mode 100644 index 000000000..d3e1131fa --- /dev/null +++ b/pr-1714/2018/10/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 16 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/16/index.html b/pr-1714/2018/10/16/index.html new file mode 100644 index 000000000..b67b4adea --- /dev/null +++ b/pr-1714/2018/10/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 16 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/16/new-gocd-features.html b/pr-1714/2018/10/16/new-gocd-features.html new file mode 100644 index 000000000..2a7b53996 --- /dev/null +++ b/pr-1714/2018/10/16/new-gocd-features.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + What's New in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+New Features in GoCD +
+ +
+ + +
+

What's new in GoCD

+

Aravind S.V, Product Manager at GoCD

+

+

+
+ +
+ +

The continuous delivery space is moving at the speed of light. Containers, infrastructure, and cloud, are all moving incredibly fast, and so is GoCD. In the past few months we have released some exciting new features.

+ +

GoCD is cloud native

+ +

We’ve built two distinct sets of features to make GoCD cloud native. First, we've made it easier to operate GoCD on cloud infrastructure providers. Second, we have provided better support for container-based workflows.

+ +

Operating on cloud infrastructure

+ +

People operating CI and CD servers on cloud providers want to perform as little administration of their build infrastructure as possible. Getting started should be easy. Build resources, or agents in GoCD parlance, should scale up and down transparently, as needed. GoCD addresses this with a suite of “elastic agent” plugins that provide scalable build infrastructure on Amazon ECS, Docker, Docker Swarm, OpenStack, and of course, Kubernetes.

+ +

Veteran users of GoCD likely have spent a fair bit of time managing their agent grids via scripts, puppet, chef and similar. An elastic agent plugin eliminates this work as GoCD installs, starts, and stops agents as needed on whatever cloud provider you point it at.

+ +

On Kubernetes, we've provided a helm chart to make it near trivial to install and operate GoCD in its entirety on your Kubernetes cluster.

+ +

Check out more about:

+ + + +

Improved container based workflows

+ +

There are two elements to our improved container based workflows:

+ +
    +
  1. Teams who are fully immersed in Docker want pretty much everything to be Docker-based. If you are utilizing our Docker, ECS Docker or Kubernetes support then all your build activity will now be Docker based. It just works.
    2. +
  2. GoCD now supports Docker images as native GoCD artifacts. GoCD abides by "build once and only once" and provides full traceability up and downstream for artifacts. You can now specify a Docker image repository as a GoCD artifact repository. This allows Docker images to be a part of GoCD’s native artifact tracing, pushing, and fetching.
    3. +
+ +

Analytics plugin for enterprise users

+ +

We have added a CD analytics plugin to our GoCD enterprise offering. The analytics plugin is intended to provide visualizations and actionable metrics to help you to optimize both value stream and the underlying build resources powering your pipeline.

+ +

One of the highlights, is when you're looking at your value stream, you can pick any two points and take a quick look at throughput or cycle time. This helps you answer questions like "How often do we deploy to production" and "How long will this take to reach the customer" more accurately. We have free trial available. Sign up here.

+ +

CD Pipeline Analytics

+ +

Another supported use case is to view your pipeline trends and identify builds that are slowing down. GoCD allows you to drill down to different levels of your pipeline to find root causes, e.g. slow tests or a lack of resources.

+ +

The GoCD enterprise offering provides you add-on software and support from the core team to enable GoCD for larger enterprise environments.

+ +

Improved the main dashboard

+ +

We have also made a couple of dashboard improvements. First, we improved performance for big organizations with hundreds or thousands of pipelines. Second, we have added personalization to the dashboard. You can now filter the dashboard to show only specific pipelines and pipeline groups. And you can save those settings as custom dashboard tabs for future reference.

+ +

GoCD Dashboard

+ +

Pipelines as code

+ +

In case you missed it, another cool feature we have improved over the past year is “Pipelines as code”. With this feature, you can store your pipeline configuration as YAML or JSON files in your own repository, so that you can modify, control and version it externally.

+ +

We also exposed this ability as a plugin endpoint so anyone can write a plugin for a config repository, to store the configuration in any manner you choose. For more in depth reading on GoCD’s pipeline as code feature, please visit our documentation for more details.

+ +

What's next:

+ +

Moving forward, we’re going to be focusing on user experience for a few months. To start, we are going to make it much easier to utilize pipelines as code. This will include making it easier to add new pipelines as well as get feedback on whether your YAML or JSON specifies a valid pipeline. Beyond that we are likely to look at improving how we store secrets, including integration with popular 3rd party tools.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/16/new-gocd-features/index.html b/pr-1714/2018/10/16/new-gocd-features/index.html new file mode 100644 index 000000000..223c204c6 --- /dev/null +++ b/pr-1714/2018/10/16/new-gocd-features/index.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + + + + + What's New in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+New Features in GoCD +
+ +
+ + +
+

What's new in GoCD

+

Aravind S.V, Product Manager at GoCD

+

+

+
+ +
+ +

The continuous delivery space is moving at the speed of light. Containers, infrastructure, and cloud, are all moving incredibly fast, and so is GoCD. In the past few months we have released some exciting new features.

+ +

GoCD is cloud native

+ +

We’ve built two distinct sets of features to make GoCD cloud native. First, we've made it easier to operate GoCD on cloud infrastructure providers. Second, we have provided better support for container-based workflows.

+ +

Operating on cloud infrastructure

+ +

People operating CI and CD servers on cloud providers want to perform as little administration of their build infrastructure as possible. Getting started should be easy. Build resources, or agents in GoCD parlance, should scale up and down transparently, as needed. GoCD addresses this with a suite of “elastic agent” plugins that provide scalable build infrastructure on Amazon ECS, Docker, Docker Swarm, OpenStack, and of course, Kubernetes.

+ +

Veteran users of GoCD likely have spent a fair bit of time managing their agent grids via scripts, puppet, chef and similar. An elastic agent plugin eliminates this work as GoCD installs, starts, and stops agents as needed on whatever cloud provider you point it at.

+ +

On Kubernetes, we've provided a helm chart to make it near trivial to install and operate GoCD in its entirety on your Kubernetes cluster.

+ +

Check out more about:

+ + + +

Improved container based workflows

+ +

There are two elements to our improved container based workflows:

+ +
    +
  1. Teams who are fully immersed in Docker want pretty much everything to be Docker-based. If you are utilizing our Docker, ECS Docker or Kubernetes support then all your build activity will now be Docker based. It just works.
    2. +
  2. GoCD now supports Docker images as native GoCD artifacts. GoCD abides by "build once and only once" and provides full traceability up and downstream for artifacts. You can now specify a Docker image repository as a GoCD artifact repository. This allows Docker images to be a part of GoCD’s native artifact tracing, pushing, and fetching.
    3. +
+ +

Analytics plugin for enterprise users

+ +

We have added a CD analytics plugin to our GoCD enterprise offering. The analytics plugin is intended to provide visualizations and actionable metrics to help you to optimize both value stream and the underlying build resources powering your pipeline.

+ +

One of the highlights, is when you're looking at your value stream, you can pick any two points and take a quick look at throughput or cycle time. This helps you answer questions like "How often do we deploy to production" and "How long will this take to reach the customer" more accurately. We have free trial available. Sign up here.

+ +

CD Pipeline Analytics

+ +

Another supported use case is to view your pipeline trends and identify builds that are slowing down. GoCD allows you to drill down to different levels of your pipeline to find root causes, e.g. slow tests or a lack of resources.

+ +

The GoCD enterprise offering provides you add-on software and support from the core team to enable GoCD for larger enterprise environments.

+ +

Improved the main dashboard

+ +

We have also made a couple of dashboard improvements. First, we improved performance for big organizations with hundreds or thousands of pipelines. Second, we have added personalization to the dashboard. You can now filter the dashboard to show only specific pipelines and pipeline groups. And you can save those settings as custom dashboard tabs for future reference.

+ +

GoCD Dashboard

+ +

Pipelines as code

+ +

In case you missed it, another cool feature we have improved over the past year is “Pipelines as code”. With this feature, you can store your pipeline configuration as YAML or JSON files in your own repository, so that you can modify, control and version it externally.

+ +

We also exposed this ability as a plugin endpoint so anyone can write a plugin for a config repository, to store the configuration in any manner you choose. For more in depth reading on GoCD’s pipeline as code feature, please visit our documentation for more details.

+ +

What's next:

+ +

Moving forward, we’re going to be focusing on user experience for a few months. To start, we are going to make it much easier to utilize pipelines as code. This will include making it easier to add new pipelines as well as get feedback on whether your YAML or JSON specifies a valid pipeline. Beyond that we are likely to look at improving how we store secrets, including integration with popular 3rd party tools.

+ +
+

+ Try GoCD today with our new Test Drive experience +

+ START NOW +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/30.html b/pr-1714/2018/10/30.html new file mode 100644 index 000000000..da8481daf --- /dev/null +++ b/pr-1714/2018/10/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/30/index.html b/pr-1714/2018/10/30/index.html new file mode 100644 index 000000000..6ae6eec1b --- /dev/null +++ b/pr-1714/2018/10/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/30/measure-continuous-delivery-process.html b/pr-1714/2018/10/30/measure-continuous-delivery-process.html new file mode 100644 index 000000000..984e47e7b --- /dev/null +++ b/pr-1714/2018/10/30/measure-continuous-delivery-process.html @@ -0,0 +1,281 @@ + + + + + + + + + + + + + + + + Why Measure Your CD Process | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 1: Why Measure your CD process +
+ +
+ + +
+

Continuous Delivery Metrics Part 1: Why measure your CD process

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

As software and IT become key drivers for innovation in most organizations these days, the speed of software delivery becomes very important to their success. More and more teams are adopting Continuous Delivery (CD) and expect to benefit from the accelerated feedback loop CD offers. To understand whether you are improving and delivering on your goals, you need to measure you CD process.

+ +

In this blog series, we will share :

+ +
    +
  • Why CD metrics are important
    • +
  • What metrics you should measure
    • +
  • A step by step guide to getting started
    • +
+ +

Continuous Delivery

+ +

Jez Humble defined continuous delivery on continuousdelivery.com as

+ +
+

"the ability to get changes of all types - including new features, configuration, bug fixes, and experiments - into production, safely and quickly in a sustainable way."

+
+ +

In practice, a CD pipeline can look like this:

+ +

CD pipelines

+ +

On the left of the diagram, the material is a repository such as git or svn. The delivery team commits a change, and your CI/CD server such as GoCD, runs build and unit tests. If these tests fail, the team immediately fixes any problems. The new version with those fixes goes further along the CD pipeline. If tests further down fails, again the team fixes them as quickly as possible. This process happens over and over in the life-cycle of an application.

+ +

Why measure your CD process

+ +

1. Measurement, Feedback, and improvement

+ +

Build, Learn, Measure

+ +

If we consider a feedback cycle like “Build, Measure and Learn”, metrics are a way to set specific and measurable goals, direct activities towards achieving those goals, and help you understand if you are achieving those goals.

+ +

2. Predict future behavior

+ +

Data will provide you more accurate estimates to your business. For example, if you know your lead time, you can more accurately answer questions about how long it will take for something to be ready for your customers.

+ +

If you are considering parallelizing tasks or removing manual steps in your process, once you have some data about your current process, you can calculate the time savings of these improvement activities. From there, this data could potentially help your organization estimate dollars made or saved by certain specific improvements.

+ +

3. Continuous delivery benchmarking

+ +

Once you have some data, the values can be used as your baseline. Those baseline values are key to understanding whether you are improving your own process as well as key to understanding where you stand relative to “high performing” teams.

+ +

CD Benchmarking

+ +

Credit: Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Location 564). IT Revolution Press. Kindle Edition.

+ +

What metrics are important to measure?

+ +

Once you introduce a CD pipeline and have established your path-to-production, the next step is to monitor its efficiency. We do not suggest measuring everything. At a high level here are the four metrics that we suggest using to help monitor your CD process. We’ll go deeper into details in future parts of the series.

+ +

1. Deployment Frequency a.k.a Throughput

+ +

Deployment freqency is a measure of how frequently your team deploys code. This metric is represented as a percentage. It is the answer to the question “how often does code reach a certain point in the CD pipeline”.

+ +

2. Lead Time

+ +

Lead time is a measure of how long it takes from committing code to deploying it to a production environment. This metric is represented as a duration. It is the answer to the question "how long does it take from committing code to it reaching production".

+ +

3. Change Fail Percentage

+ +

Change fail percentage is a measure of the percentage of changes that result in a failure. This metric is represented as a percentage. It is the answer to questions like “what percentage of changes break builds” and “what percentage of deployments result in a service outage”.

+ +

4. Mean time to restore

+ +

Mean time to restore (MTTR) is a measure of how long it takes to fix a build failure. This metric is represented as a mean duration. It is the answer to questions like "how long does it take you to restore service during a failed deployment".

+ +

Summary

+ +

This is the part 1 of our Actionable CD metrics blog series. We talked about why CD metrics are important, and an overview of the important metrics we recommend. In the next post, we will dig deeper into each metric.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/30/measure-continuous-delivery-process/index.html b/pr-1714/2018/10/30/measure-continuous-delivery-process/index.html new file mode 100644 index 000000000..9985cd87f --- /dev/null +++ b/pr-1714/2018/10/30/measure-continuous-delivery-process/index.html @@ -0,0 +1,281 @@ + + + + + + + + + + + + + + + + Why Measure Your CD Process | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 1: Why Measure your CD process +
+ +
+ + +
+

Continuous Delivery Metrics Part 1: Why measure your CD process

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

As software and IT become key drivers for innovation in most organizations these days, the speed of software delivery becomes very important to their success. More and more teams are adopting Continuous Delivery (CD) and expect to benefit from the accelerated feedback loop CD offers. To understand whether you are improving and delivering on your goals, you need to measure you CD process.

+ +

In this blog series, we will share :

+ +
    +
  • Why CD metrics are important
    • +
  • What metrics you should measure
    • +
  • A step by step guide to getting started
    • +
+ +

Continuous Delivery

+ +

Jez Humble defined continuous delivery on continuousdelivery.com as

+ +
+

"the ability to get changes of all types - including new features, configuration, bug fixes, and experiments - into production, safely and quickly in a sustainable way."

+
+ +

In practice, a CD pipeline can look like this:

+ +

CD pipelines

+ +

On the left of the diagram, the material is a repository such as git or svn. The delivery team commits a change, and your CI/CD server such as GoCD, runs build and unit tests. If these tests fail, the team immediately fixes any problems. The new version with those fixes goes further along the CD pipeline. If tests further down fails, again the team fixes them as quickly as possible. This process happens over and over in the life-cycle of an application.

+ +

Why measure your CD process

+ +

1. Measurement, Feedback, and improvement

+ +

Build, Learn, Measure

+ +

If we consider a feedback cycle like “Build, Measure and Learn”, metrics are a way to set specific and measurable goals, direct activities towards achieving those goals, and help you understand if you are achieving those goals.

+ +

2. Predict future behavior

+ +

Data will provide you more accurate estimates to your business. For example, if you know your lead time, you can more accurately answer questions about how long it will take for something to be ready for your customers.

+ +

If you are considering parallelizing tasks or removing manual steps in your process, once you have some data about your current process, you can calculate the time savings of these improvement activities. From there, this data could potentially help your organization estimate dollars made or saved by certain specific improvements.

+ +

3. Continuous delivery benchmarking

+ +

Once you have some data, the values can be used as your baseline. Those baseline values are key to understanding whether you are improving your own process as well as key to understanding where you stand relative to “high performing” teams.

+ +

CD Benchmarking

+ +

Credit: Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Location 564). IT Revolution Press. Kindle Edition.

+ +

What metrics are important to measure?

+ +

Once you introduce a CD pipeline and have established your path-to-production, the next step is to monitor its efficiency. We do not suggest measuring everything. At a high level here are the four metrics that we suggest using to help monitor your CD process. We’ll go deeper into details in future parts of the series.

+ +

1. Deployment Frequency a.k.a Throughput

+ +

Deployment freqency is a measure of how frequently your team deploys code. This metric is represented as a percentage. It is the answer to the question “how often does code reach a certain point in the CD pipeline”.

+ +

2. Lead Time

+ +

Lead time is a measure of how long it takes from committing code to deploying it to a production environment. This metric is represented as a duration. It is the answer to the question "how long does it take from committing code to it reaching production".

+ +

3. Change Fail Percentage

+ +

Change fail percentage is a measure of the percentage of changes that result in a failure. This metric is represented as a percentage. It is the answer to questions like “what percentage of changes break builds” and “what percentage of deployments result in a service outage”.

+ +

4. Mean time to restore

+ +

Mean time to restore (MTTR) is a measure of how long it takes to fix a build failure. This metric is represented as a mean duration. It is the answer to questions like "how long does it take you to restore service during a failed deployment".

+ +

Summary

+ +

This is the part 1 of our Actionable CD metrics blog series. We talked about why CD metrics are important, and an overview of the important metrics we recommend. In the next post, we will dig deeper into each metric.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/10/index.html b/pr-1714/2018/10/index.html new file mode 100644 index 000000000..ec3464231 --- /dev/null +++ b/pr-1714/2018/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11.html b/pr-1714/2018/11.html new file mode 100644 index 000000000..5fb883710 --- /dev/null +++ b/pr-1714/2018/11.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11/30.html b/pr-1714/2018/11/30.html new file mode 100644 index 000000000..b44b29644 --- /dev/null +++ b/pr-1714/2018/11/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11/30/deployment-frequency.html b/pr-1714/2018/11/30/deployment-frequency.html new file mode 100644 index 000000000..ddf100a7c --- /dev/null +++ b/pr-1714/2018/11/30/deployment-frequency.html @@ -0,0 +1,261 @@ + + + + + + + + + + + + + + + + How often do you deploy to production? | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 2: How often do you deploy to production? +
+ +
+ + +
+

Continuous Delivery Metrics Part 2: How often do you deploy to production?

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

This is the second post in the series - Actionable Continuous Delivery Metrics. In the previous post, we gave an overview of why metrics matter to your CD process and what metrics we recommend you measure. In this post, we’ll get deeper into the first metric: deployment frequency.

+ +

What Deployment Frequency Is

+ +

Deployment frequency otherwise known as throughput, is a measure of how frequently your team deploys code. This metric is often represented as a percentage and it answers the question “how often do we deploy to production or to another significant point in our CD pipeline such as a staging environment?”.

+ +

deployment frequency concept

+ +

We consider production deployment as a significant point in the CD pipeline and we are counting the number of times a deployment to production happens versus not happening. In the example above, we have 8 instances or opportunities to deploy, with only 2 deployments happening, so the deployment frequency is 25%.

+ +

Why Deployment Frequency Is Important

+ +

The word "continuous" in continuous delivery implies high deployment frequency. Having a high deployment frequency means that you have more deployments, and gives you more opportunities for feedback on your software. More importantly, higher deployment frequency means that you’re delivering value to end users and stakeholders more quickly.

+ +

According to the research done by the State of DevOps report team, high functioning teams have higher deployment frequency as compared to their less efficient peers. It is good to baseline your deployment frequency and try to increase it as much as it makes sense, in the context of your organization’s business and goals.

+ +

However, deployment frequency has to be balanced with quality. You don't want to increase deployment frequency by removing tests. You want to be able to deliver more often to production, while maintaining or even improving quality. That's what CD is about and what the deployment frequency metric captures.

+ +

An Example: How to Use Deployment Frequency

+ +

If you are measuring your pipeline and have low deployment frequency, what can you do? We’ll take a hypothetical example, and use GoCD, our continuous delivery server, to take you through how you can identify and act on deployment frequency issues. In our example, the team received a complaint from the business that they don’t get value very often. Let’s find out why.

+ +

example pipelines

+ +

The picture above shows you the continuous delivery pipelines, represented in GoCD’s Value Stream Map (VSM). Here, GoCD runs through the value stream including some unit tests, then integration tests and smoke tests in parallel, and then eventually the regression tests. Finally, there are User Acceptance Tests (UAT) and a production deployment.

+ +

To understand what is happening here, we start with finding out whether your deployment frequency is concerning. In our example, it’s easy to look this metric up in GoCD using the GoCD enterprise analytics plugin: go to GoCD’s VSM view, select the part of the CD pipeline you care about, and see the deployment frequency (known as throughput in GoCD). We can see that the throughput is only 9%, which means out of the opportunities to deploy only 9% are reaching production. This number is too low.

+ +

deployment frequency in GoCD

+ +

These can also be tracked manually in a spreadsheet or other tool. If you note down the status each time BuildAndUnitTests ran, as well as the production pipeline ran, , you’ll see more failures on the way to the production part of the CD pipelines. In the table below, you can see when you track and plot the run times, in the same time period of five days, BuildAndUnitTests ran many more times than Production. Again, you see the deployment frequency is very low.

+ +

deployment frequency in excel

+ +

The main signal here is clearly that the deployment frequency is low. But why and how should we act on that? There may be many reasons for this. We recommend checking the following potential causes:

+ +
    +
  • Is your build very slow? Is slowness and lack of feedback causing the development team to avoid checking in often? Do the team respond by combining changes into bigger chunks and causing even longer delays?
    • +
  • Is your end-to-end lead time from commit to deployment too long?
    • +
  • Do you have builds that fail very often?
    • +
  • Do you have flaky tests? If tests are flaky consider understanding which ones are the biggest problem and addressing the root cause.
    • +
  • Are you stopping the line to address other problems?
    • +
  • Do you have long-lived feature branches or pull-requests which are not merged often?. Very often we see the development team working hard on their branches, but the business won’t see that value until the changes are deployed. If your problem is that you have work going on in long-lived branches, consider feature toggles and trunk based development.
    • +
+ +

Summary

+ +

In this post, we discussed what deployment frequency is, why it is important, and how to act on low deployment frequency. As we discussed in our previous post, there are three other important metrics we recommend measuring: lead time, change to fail percentage and MTTR. These metrics work closely with deployment frequency, and can will help you further understand the root cause of low deployment frequency. We we will cover the interrelationship of these metrics in future posts.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11/30/deployment-frequency/index.html b/pr-1714/2018/11/30/deployment-frequency/index.html new file mode 100644 index 000000000..daecb177d --- /dev/null +++ b/pr-1714/2018/11/30/deployment-frequency/index.html @@ -0,0 +1,261 @@ + + + + + + + + + + + + + + + + How often do you deploy to production? | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 2: How often do you deploy to production? +
+ +
+ + +
+

Continuous Delivery Metrics Part 2: How often do you deploy to production?

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

This is the second post in the series - Actionable Continuous Delivery Metrics. In the previous post, we gave an overview of why metrics matter to your CD process and what metrics we recommend you measure. In this post, we’ll get deeper into the first metric: deployment frequency.

+ +

What Deployment Frequency Is

+ +

Deployment frequency otherwise known as throughput, is a measure of how frequently your team deploys code. This metric is often represented as a percentage and it answers the question “how often do we deploy to production or to another significant point in our CD pipeline such as a staging environment?”.

+ +

deployment frequency concept

+ +

We consider production deployment as a significant point in the CD pipeline and we are counting the number of times a deployment to production happens versus not happening. In the example above, we have 8 instances or opportunities to deploy, with only 2 deployments happening, so the deployment frequency is 25%.

+ +

Why Deployment Frequency Is Important

+ +

The word "continuous" in continuous delivery implies high deployment frequency. Having a high deployment frequency means that you have more deployments, and gives you more opportunities for feedback on your software. More importantly, higher deployment frequency means that you’re delivering value to end users and stakeholders more quickly.

+ +

According to the research done by the State of DevOps report team, high functioning teams have higher deployment frequency as compared to their less efficient peers. It is good to baseline your deployment frequency and try to increase it as much as it makes sense, in the context of your organization’s business and goals.

+ +

However, deployment frequency has to be balanced with quality. You don't want to increase deployment frequency by removing tests. You want to be able to deliver more often to production, while maintaining or even improving quality. That's what CD is about and what the deployment frequency metric captures.

+ +

An Example: How to Use Deployment Frequency

+ +

If you are measuring your pipeline and have low deployment frequency, what can you do? We’ll take a hypothetical example, and use GoCD, our continuous delivery server, to take you through how you can identify and act on deployment frequency issues. In our example, the team received a complaint from the business that they don’t get value very often. Let’s find out why.

+ +

example pipelines

+ +

The picture above shows you the continuous delivery pipelines, represented in GoCD’s Value Stream Map (VSM). Here, GoCD runs through the value stream including some unit tests, then integration tests and smoke tests in parallel, and then eventually the regression tests. Finally, there are User Acceptance Tests (UAT) and a production deployment.

+ +

To understand what is happening here, we start with finding out whether your deployment frequency is concerning. In our example, it’s easy to look this metric up in GoCD using the GoCD enterprise analytics plugin: go to GoCD’s VSM view, select the part of the CD pipeline you care about, and see the deployment frequency (known as throughput in GoCD). We can see that the throughput is only 9%, which means out of the opportunities to deploy only 9% are reaching production. This number is too low.

+ +

deployment frequency in GoCD

+ +

These can also be tracked manually in a spreadsheet or other tool. If you note down the status each time BuildAndUnitTests ran, as well as the production pipeline ran, , you’ll see more failures on the way to the production part of the CD pipelines. In the table below, you can see when you track and plot the run times, in the same time period of five days, BuildAndUnitTests ran many more times than Production. Again, you see the deployment frequency is very low.

+ +

deployment frequency in excel

+ +

The main signal here is clearly that the deployment frequency is low. But why and how should we act on that? There may be many reasons for this. We recommend checking the following potential causes:

+ +
    +
  • Is your build very slow? Is slowness and lack of feedback causing the development team to avoid checking in often? Do the team respond by combining changes into bigger chunks and causing even longer delays?
    • +
  • Is your end-to-end lead time from commit to deployment too long?
    • +
  • Do you have builds that fail very often?
    • +
  • Do you have flaky tests? If tests are flaky consider understanding which ones are the biggest problem and addressing the root cause.
    • +
  • Are you stopping the line to address other problems?
    • +
  • Do you have long-lived feature branches or pull-requests which are not merged often?. Very often we see the development team working hard on their branches, but the business won’t see that value until the changes are deployed. If your problem is that you have work going on in long-lived branches, consider feature toggles and trunk based development.
    • +
+ +

Summary

+ +

In this post, we discussed what deployment frequency is, why it is important, and how to act on low deployment frequency. As we discussed in our previous post, there are three other important metrics we recommend measuring: lead time, change to fail percentage and MTTR. These metrics work closely with deployment frequency, and can will help you further understand the root cause of low deployment frequency. We we will cover the interrelationship of these metrics in future posts.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11/30/index.html b/pr-1714/2018/11/30/index.html new file mode 100644 index 000000000..94602a23e --- /dev/null +++ b/pr-1714/2018/11/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/11/index.html b/pr-1714/2018/11/index.html new file mode 100644 index 000000000..83bba9ded --- /dev/null +++ b/pr-1714/2018/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/index.html b/pr-1714/2018/index.html new file mode 100644 index 000000000..dd234f087 --- /dev/null +++ b/pr-1714/2018/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 1 of 2

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/page/2.html b/pr-1714/2018/page/2.html new file mode 100644 index 000000000..5b2959c4a --- /dev/null +++ b/pr-1714/2018/page/2.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 2 of 2

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2018/page/2/index.html b/pr-1714/2018/page/2/index.html new file mode 100644 index 000000000..f2258fa52 --- /dev/null +++ b/pr-1714/2018/page/2/index.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 2 of 2

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019.html b/pr-1714/2019.html new file mode 100644 index 000000000..b851ec6f7 --- /dev/null +++ b/pr-1714/2019.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01.html b/pr-1714/2019/01.html new file mode 100644 index 000000000..48f89661f --- /dev/null +++ b/pr-1714/2019/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01/14.html b/pr-1714/2019/01/14.html new file mode 100644 index 000000000..7269e4fa8 --- /dev/null +++ b/pr-1714/2019/01/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01/14/cd-metrics-deployment-lead-time.html b/pr-1714/2019/01/14/cd-metrics-deployment-lead-time.html new file mode 100644 index 000000000..340f0481f --- /dev/null +++ b/pr-1714/2019/01/14/cd-metrics-deployment-lead-time.html @@ -0,0 +1,267 @@ + + + + + + + + + + + + + + + + How often do you deploy to production? | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 3: Lead Time +
+ +
+ + +
+

Continuous Delivery Metrics Part 3: How long does it take to get from committing code to production?

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

This is the third post in the series - Actionable Continuous Delivery Metrics. In the previous posts, we gave an overview of why and what metrics matter to your CD process as well as an in depth discussion on deployment frequency. In this post, we’ll get deeper into lead time.

+ +

What Lead Time Is

+ +

Whereas deployment frequency is the number of times deployment happened, lead time for change is the cumulative lapsed time it took from start to deployment. This metric is represented as a duration and it helps answer the question “how long does it take to get from from code commit to production?”

+ +

You may see lead time used interchangeably with cycle time, and there is a lot of confusion around what these two terms mean. By definition, the lead time clock starts when the feature request is made and ends at delivery, while the cycle time clock starts when work begins on the request and ends when the item is ready for delivery. We are not going to distinguish these two terms in this post. We think the important thing is that you clearly define what you mean, and be consistent with your definition. In our context, we suggest avoid saying lead time or cycle time without qualifying the starting point and ending point.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

In the diagram above, we calculate time from a commit (at the start of a CD pipeline) until when that code commit goes to production (at the end of the CD pipeline). Although other points in the CD pipeline have happened multiple times, it was only after three days that the deployment happened, so we calculate the lead time for that commit as three days.

+ +

Why Lead Time is Important

+ +

Lead time is a key element of lean theory. Focusing on reducing lead time will allow you to look at your process as a whole and understand the slowest parts. If teams and organizations only concentrated on lowering lead time they would improve and add more value to their organization.

+ +

Lead time helps you answer questions like "When will this be done? If we start now when can we get it to production? Can we deliver this next week?" It helps inform business decisions and helps with planning.

+ +

Finally, we recommend only considering the “delivery” part when calculating lead time for your CD process. If you define the start time from first line of code, and remove the “fuzzy front-end”, which include activities like requirement gathering, system analysis, prioritization etc, it is a simple and very practical metric to calculate.

+ +

An Example: How to Use Lead Time

+ +

We will continue with the hypothetical scenario we used in part 2 of the series, in this scenario, the development team received the complaint from their stakeholders that they didn’t get value very often.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

This picture above is a quick refresher of this team’s CD pipelines represented in GoCD’s Value Stream Map (VSM). It includes some unit tests, integration tests and smoke tests in parallel, and then the regression tests. At the end, there are User Acceptance Tests (UAT) and a production deployment.

+ +

In the previous post, we have found out the deployment frequency is as low as 8%. Here, GoCD enterprise analytics plugin can help find out what parts of the CD pipeline are causing this low deployment frequency.

+ +

In the screenshots below, you can see the average cycle time from BuildAndUnitTests to Production is 33m.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

When you drill down into each pipeline, you can see these details with wait times (shown in gray), and run times (shown in purple) towards production with each stage shown separately. From there, you can identify your slowest steps.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

This process can also be done manually, or with another tool. When you track the time and plot the different parts of the workflow, you can achieve similar results. The example below is a possible representation of the process, when done outside of GoCD. You can see there are some long-running parts of your pipeline (as in “Regression” here) and some long delays due to manual approvals.

+ +

Continuous Delivery Metrics Part 3: Lead Time

+ +

As you can see from our example, with lead time metric and the supporting details, you can identify your problematic steps: steps that are slow to complete and require lots of wait time will lead to overall low deployment frequency. From here, we recommend

+ +
    +
  • focusing on the slowest steps first- that is what will give you the most gains.
    • +
  • converting manual approvals into automated ones, which will increase your level of confidence in the tests and automation.
    • +
  • Rewriting the tests in the slowest steps, if possible.
    • +
+ +

Sometimes, just focusing on optimizing a number of slow steps is not enough. Consider bigger changes to your pipelines. Start with drawing the value stream map and truly understanding the dependencies of your process. Identify opportunities to parallelize, rearrange your tests to start the slow-running tests earlier on in the process.

+ +

Summary

+ +

In this post, we discussed what lead time is, why it is important, and how to act on long lead time. As we discussed in part 1, there are two other important metrics we recommend measuring: change fail percentage and MTTR. These metrics work closely with deployment frequency and lead time. We we will cover the interrelationship of these metrics in future posts.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01/14/cd-metrics-deployment-lead-time/index.html b/pr-1714/2019/01/14/cd-metrics-deployment-lead-time/index.html new file mode 100644 index 000000000..57ede1c72 --- /dev/null +++ b/pr-1714/2019/01/14/cd-metrics-deployment-lead-time/index.html @@ -0,0 +1,267 @@ + + + + + + + + + + + + + + + + How often do you deploy to production? | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Continuous Delivery Metrics Part 3: Lead Time +
+ +
+ + +
+

Continuous Delivery Metrics Part 3: How long does it take to get from committing code to production?

+

Aravind S.V and Suzie Prince

+

+ CD Analytics +

+
+ +
+ +

This is the third post in the series - Actionable Continuous Delivery Metrics. In the previous posts, we gave an overview of why and what metrics matter to your CD process as well as an in depth discussion on deployment frequency. In this post, we’ll get deeper into lead time.

+ +

What Lead Time Is

+ +

Whereas deployment frequency is the number of times deployment happened, lead time for change is the cumulative lapsed time it took from start to deployment. This metric is represented as a duration and it helps answer the question “how long does it take to get from from code commit to production?”

+ +

You may see lead time used interchangeably with cycle time, and there is a lot of confusion around what these two terms mean. By definition, the lead time clock starts when the feature request is made and ends at delivery, while the cycle time clock starts when work begins on the request and ends when the item is ready for delivery. We are not going to distinguish these two terms in this post. We think the important thing is that you clearly define what you mean, and be consistent with your definition. In our context, we suggest avoid saying lead time or cycle time without qualifying the starting point and ending point.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

In the diagram above, we calculate time from a commit (at the start of a CD pipeline) until when that code commit goes to production (at the end of the CD pipeline). Although other points in the CD pipeline have happened multiple times, it was only after three days that the deployment happened, so we calculate the lead time for that commit as three days.

+ +

Why Lead Time is Important

+ +

Lead time is a key element of lean theory. Focusing on reducing lead time will allow you to look at your process as a whole and understand the slowest parts. If teams and organizations only concentrated on lowering lead time they would improve and add more value to their organization.

+ +

Lead time helps you answer questions like "When will this be done? If we start now when can we get it to production? Can we deliver this next week?" It helps inform business decisions and helps with planning.

+ +

Finally, we recommend only considering the “delivery” part when calculating lead time for your CD process. If you define the start time from first line of code, and remove the “fuzzy front-end”, which include activities like requirement gathering, system analysis, prioritization etc, it is a simple and very practical metric to calculate.

+ +

An Example: How to Use Lead Time

+ +

We will continue with the hypothetical scenario we used in part 2 of the series, in this scenario, the development team received the complaint from their stakeholders that they didn’t get value very often.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

This picture above is a quick refresher of this team’s CD pipelines represented in GoCD’s Value Stream Map (VSM). It includes some unit tests, integration tests and smoke tests in parallel, and then the regression tests. At the end, there are User Acceptance Tests (UAT) and a production deployment.

+ +

In the previous post, we have found out the deployment frequency is as low as 8%. Here, GoCD enterprise analytics plugin can help find out what parts of the CD pipeline are causing this low deployment frequency.

+ +

In the screenshots below, you can see the average cycle time from BuildAndUnitTests to Production is 33m.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

When you drill down into each pipeline, you can see these details with wait times (shown in gray), and run times (shown in purple) towards production with each stage shown separately. From there, you can identify your slowest steps.

+ +

Continuous Delivery Metrics Part 3: Lead Time Diagram

+ +

This process can also be done manually, or with another tool. When you track the time and plot the different parts of the workflow, you can achieve similar results. The example below is a possible representation of the process, when done outside of GoCD. You can see there are some long-running parts of your pipeline (as in “Regression” here) and some long delays due to manual approvals.

+ +

Continuous Delivery Metrics Part 3: Lead Time

+ +

As you can see from our example, with lead time metric and the supporting details, you can identify your problematic steps: steps that are slow to complete and require lots of wait time will lead to overall low deployment frequency. From here, we recommend

+ +
    +
  • focusing on the slowest steps first- that is what will give you the most gains.
    • +
  • converting manual approvals into automated ones, which will increase your level of confidence in the tests and automation.
    • +
  • Rewriting the tests in the slowest steps, if possible.
    • +
+ +

Sometimes, just focusing on optimizing a number of slow steps is not enough. Consider bigger changes to your pipelines. Start with drawing the value stream map and truly understanding the dependencies of your process. Identify opportunities to parallelize, rearrange your tests to start the slow-running tests earlier on in the process.

+ +

Summary

+ +

In this post, we discussed what lead time is, why it is important, and how to act on long lead time. As we discussed in part 1, there are two other important metrics we recommend measuring: change fail percentage and MTTR. These metrics work closely with deployment frequency and lead time. We we will cover the interrelationship of these metrics in future posts.

+ +
+

+ Free GoCD Analytics trial is available +

+ SIGN UP +
+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01/14/index.html b/pr-1714/2019/01/14/index.html new file mode 100644 index 000000000..7ac932432 --- /dev/null +++ b/pr-1714/2019/01/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/01/index.html b/pr-1714/2019/01/index.html new file mode 100644 index 000000000..d9597843b --- /dev/null +++ b/pr-1714/2019/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03.html b/pr-1714/2019/03.html new file mode 100644 index 000000000..f386ecd06 --- /dev/null +++ b/pr-1714/2019/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03/19.html b/pr-1714/2019/03/19.html new file mode 100644 index 000000000..f8501c397 --- /dev/null +++ b/pr-1714/2019/03/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 19 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03/19/index.html b/pr-1714/2019/03/19/index.html new file mode 100644 index 000000000..26dc1180d --- /dev/null +++ b/pr-1714/2019/03/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 19 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03/19/user-authorization-ldap.html b/pr-1714/2019/03/19/user-authorization-ldap.html new file mode 100644 index 000000000..8b3708fc2 --- /dev/null +++ b/pr-1714/2019/03/19/user-authorization-ldap.html @@ -0,0 +1,398 @@ + + + + + + + + + + + + + + + + OpenLDAP for User Authentication in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Open LDAP with GoCD +
+ +
+ + +
+

Use OpenLDAP for User Authentication in GoCD

+

Ankit Srivistava

+

+ CD Hacks +

+
+ +
+ +

A newly installed GoCD server does not require users to authenticate. This is great for a trial. However, it is one of the first things you should change, as soon as you decide to use GoCD more widely.

+ +

GoCD has two methods of authentication built into it: Password-file based authentication and LDAP/Active Directory authentication. You can also choose from a collection of community-maintained plugins for other methods of authentication, such as using Google or GitHub OAuth.

+ +

GoCD doesn’t restrict you to only one source of authentication but allows you to connect multiple authentication sources. For instance, a user can have combination of password-file based and LDAP authentication or GoCD can be setup to use multiple LDAP servers.

+ +

In this post, you will learn about setting upon OpenLDAP and then, setting up GoCD to use that OpenLDAP instance for authentication.

+ +

OpenLDAP is an open-source implementation of the LDAP protocol.

+ +

Prerequisites

+ +
    +
  • Ubuntu
    • +
  • Latest GoCD server
    • +
  • Knowledge of LDAP (https://ldap.com/basic-ldap-concepts/)
    • +
+ +

Step 1 — Installing and Configuring the OpenLDAP server

+ +

Our first step is to install the OpenLDAP server and some associated utilities. The packages we need are all available in Ubuntu's default repositories.

+ +

Log into your server and run below commands.

+ +
sudo apt-get update
+sudo apt-get install slapd ldap-utils
+
+ +

The above will install and start an openLDAP server with the database suffix of dc=example,dc=com. In order to update suffix, run below command.

+ +
sudo dpkg-reconfigure slapd
+
+ +

You should see below output:

+ +

Open LDAP with GoCD

+ +

At this point, your LDAP server is configured and running. Open up the LDAP port on your firewall so external clients can connect:

+ +
sudo ufw allow ldap
+
+ +

Let's test our LDAP connection using ldapwhoami, which should return the username we're connected as:

+ +
ldapwhoami -H ldap:// -x
+
+ +

Output:

+ +
anonymous
+
+ +

This should give you “anonymous” as result, since we ran it without logging into the LDAP server. This means the LDAP server is running and responding.

+ +

If this gives you connect error something similar to below, try checking the ldap service status /etc/init.d/slapd status and restart if it is stopped.

+ +
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
+
+ +

Next we'll add a user to the OpenLDAP server and see if we are able to connect.

+ +

Step 2 — Add user to LDAP server

+ +

Create an add.ldif file and add below content for user details:

+ +
dn: ou=People,dc=gocd,dc=org
+objectClass: organizationalUnit
+ou: People
+
+dn: ou=Groups,dc=gocd,dc=org
+objectClass: organizationalUnit
+ou: Groups
+
+dn: uid=john,ou=People,dc=gocd,dc=org
+objectClass: inetOrgPerson
+objectClass: shadowAccount
+uid: john
+sn: Doe
+givenName: John
+cn: John Doe
+displayName: John Doe
+userPassword: badger
+
+ +

Execute below command to add user to LDAP:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add.ldif
+
+ +

Output:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add.ldif
+Enter LDAP Password:
+adding new entry  "ou=People,dc=gocd,dc=org"
+
+adding new entry  "ou=Groups,dc=gocd,dc=org"
+
+adding new entry  "uid=john,ou=People,dc=gocd,dc=org"
+
+ +

Check if the user is successfully added:

+ +
ldapsearch -x -LLL -b dc=gocd,dc=org 'uid=john' cn gidNumber
+
+ +

Output:

+ +
ldapsearch -x -LLL -b dc=gocd,dc=org 'uid=john' cn gidNumber
+dn:  uid=john,ou=People,dc=gocd,dc=org
+cn:  John Doe
+
+ +

If you need to add another user at some point, you can do it by creating add_user.ldif file with below content.

+ +
dn: uid=bob,ou=People,dc=gocd,dc=org
+objectClass: inetOrgPerson
+objectClass: shadowAccount
+uid: bob
+sn: builder
+givenName: bob
+cn: Bob Builder
+displayName: Bob Builder
+userPassword: badger
+
+ +

Run below command to add another user:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add_user.ldif
+
+ +

Change user password:

+ +
ldappasswd -x -D cn=admin,dc=gocd,dc=org -W -S "uid=john,ou=People,dc=gocd,dc=org"
+
+ +

Step 3 — Setup LDAP authentication for GoCD

+ +

This configuration will help you connect to the OpenLDAP server you setup.

+ +

Open LDAP with GoCD

+ +

[Screenshot of the GoCD LDAP authentication setup]

+ +

Open LDAP with GoCD

+ +

Users can also configure this via Config XML tab on the Admin section:

+ +
 <security>
+      <authConfigs>
+        <authConfig id="OpenLDAP" pluginId="cd.go.authentication.ldap">
+          <property>
+            <key>Url</key>
+            <value>ldap://</value>
+          </property>
+          <property>
+            <key>SearchBases</key>
+            <value>ou=People,dc=gocd,dc=org</value>
+          </property>
+          <property>
+            <key>ManagerDN</key>
+            <value>cn=admin,dc=gocd,dc=org</value>
+          </property>
+          <property>
+            <key>Password</key>
+            <encryptedValue>3mfoJ3hSBBM=</encryptedValue>
+          </property>
+          <property>
+            <key>UserSearchFilter</key>
+            <value />
+          </property>
+          <property>
+            <key>UserLoginFilter</key>
+            <value>uid={0}</value>
+          </property>
+          <property>
+            <key>DisplayNameAttribute</key>
+            <value>cn</value>
+          </property>
+          <property>
+            <key>EmailAttribute</key>
+            <value />
+          </property>
+        </authConfig>
+      </authConfigs>
+    </security>
+
+ +

More info on GoCD LDAP configuration can be found here - https://github.com/gocd/gocd-ldap-authentication-plugin

+ +

Conclusion

+ +

Our goal is to provide flexible endpoints so that people can use any/multiple authorization service providers of their choice. As demonstrated in the above example, we were able to add a light-weight OpenLDAP server with ease.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03/19/user-authorization-ldap/index.html b/pr-1714/2019/03/19/user-authorization-ldap/index.html new file mode 100644 index 000000000..04fe2825e --- /dev/null +++ b/pr-1714/2019/03/19/user-authorization-ldap/index.html @@ -0,0 +1,398 @@ + + + + + + + + + + + + + + + + OpenLDAP for User Authentication in GoCD | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Open LDAP with GoCD +
+ +
+ + +
+

Use OpenLDAP for User Authentication in GoCD

+

Ankit Srivistava

+

+ CD Hacks +

+
+ +
+ +

A newly installed GoCD server does not require users to authenticate. This is great for a trial. However, it is one of the first things you should change, as soon as you decide to use GoCD more widely.

+ +

GoCD has two methods of authentication built into it: Password-file based authentication and LDAP/Active Directory authentication. You can also choose from a collection of community-maintained plugins for other methods of authentication, such as using Google or GitHub OAuth.

+ +

GoCD doesn’t restrict you to only one source of authentication but allows you to connect multiple authentication sources. For instance, a user can have combination of password-file based and LDAP authentication or GoCD can be setup to use multiple LDAP servers.

+ +

In this post, you will learn about setting upon OpenLDAP and then, setting up GoCD to use that OpenLDAP instance for authentication.

+ +

OpenLDAP is an open-source implementation of the LDAP protocol.

+ +

Prerequisites

+ +
    +
  • Ubuntu
    • +
  • Latest GoCD server
    • +
  • Knowledge of LDAP (https://ldap.com/basic-ldap-concepts/)
    • +
+ +

Step 1 — Installing and Configuring the OpenLDAP server

+ +

Our first step is to install the OpenLDAP server and some associated utilities. The packages we need are all available in Ubuntu's default repositories.

+ +

Log into your server and run below commands.

+ +
sudo apt-get update
+sudo apt-get install slapd ldap-utils
+
+ +

The above will install and start an openLDAP server with the database suffix of dc=example,dc=com. In order to update suffix, run below command.

+ +
sudo dpkg-reconfigure slapd
+
+ +

You should see below output:

+ +

Open LDAP with GoCD

+ +

At this point, your LDAP server is configured and running. Open up the LDAP port on your firewall so external clients can connect:

+ +
sudo ufw allow ldap
+
+ +

Let's test our LDAP connection using ldapwhoami, which should return the username we're connected as:

+ +
ldapwhoami -H ldap:// -x
+
+ +

Output:

+ +
anonymous
+
+ +

This should give you “anonymous” as result, since we ran it without logging into the LDAP server. This means the LDAP server is running and responding.

+ +

If this gives you connect error something similar to below, try checking the ldap service status /etc/init.d/slapd status and restart if it is stopped.

+ +
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
+
+ +

Next we'll add a user to the OpenLDAP server and see if we are able to connect.

+ +

Step 2 — Add user to LDAP server

+ +

Create an add.ldif file and add below content for user details:

+ +
dn: ou=People,dc=gocd,dc=org
+objectClass: organizationalUnit
+ou: People
+
+dn: ou=Groups,dc=gocd,dc=org
+objectClass: organizationalUnit
+ou: Groups
+
+dn: uid=john,ou=People,dc=gocd,dc=org
+objectClass: inetOrgPerson
+objectClass: shadowAccount
+uid: john
+sn: Doe
+givenName: John
+cn: John Doe
+displayName: John Doe
+userPassword: badger
+
+ +

Execute below command to add user to LDAP:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add.ldif
+
+ +

Output:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add.ldif
+Enter LDAP Password:
+adding new entry  "ou=People,dc=gocd,dc=org"
+
+adding new entry  "ou=Groups,dc=gocd,dc=org"
+
+adding new entry  "uid=john,ou=People,dc=gocd,dc=org"
+
+ +

Check if the user is successfully added:

+ +
ldapsearch -x -LLL -b dc=gocd,dc=org 'uid=john' cn gidNumber
+
+ +

Output:

+ +
ldapsearch -x -LLL -b dc=gocd,dc=org 'uid=john' cn gidNumber
+dn:  uid=john,ou=People,dc=gocd,dc=org
+cn:  John Doe
+
+ +

If you need to add another user at some point, you can do it by creating add_user.ldif file with below content.

+ +
dn: uid=bob,ou=People,dc=gocd,dc=org
+objectClass: inetOrgPerson
+objectClass: shadowAccount
+uid: bob
+sn: builder
+givenName: bob
+cn: Bob Builder
+displayName: Bob Builder
+userPassword: badger
+
+ +

Run below command to add another user:

+ +
ldapadd -x -D cn=admin,dc=gocd,dc=org -W -f add_user.ldif
+
+ +

Change user password:

+ +
ldappasswd -x -D cn=admin,dc=gocd,dc=org -W -S "uid=john,ou=People,dc=gocd,dc=org"
+
+ +

Step 3 — Setup LDAP authentication for GoCD

+ +

This configuration will help you connect to the OpenLDAP server you setup.

+ +

Open LDAP with GoCD

+ +

[Screenshot of the GoCD LDAP authentication setup]

+ +

Open LDAP with GoCD

+ +

Users can also configure this via Config XML tab on the Admin section:

+ +
 <security>
+      <authConfigs>
+        <authConfig id="OpenLDAP" pluginId="cd.go.authentication.ldap">
+          <property>
+            <key>Url</key>
+            <value>ldap://</value>
+          </property>
+          <property>
+            <key>SearchBases</key>
+            <value>ou=People,dc=gocd,dc=org</value>
+          </property>
+          <property>
+            <key>ManagerDN</key>
+            <value>cn=admin,dc=gocd,dc=org</value>
+          </property>
+          <property>
+            <key>Password</key>
+            <encryptedValue>3mfoJ3hSBBM=</encryptedValue>
+          </property>
+          <property>
+            <key>UserSearchFilter</key>
+            <value />
+          </property>
+          <property>
+            <key>UserLoginFilter</key>
+            <value>uid={0}</value>
+          </property>
+          <property>
+            <key>DisplayNameAttribute</key>
+            <value>cn</value>
+          </property>
+          <property>
+            <key>EmailAttribute</key>
+            <value />
+          </property>
+        </authConfig>
+      </authConfigs>
+    </security>
+
+ +

More info on GoCD LDAP configuration can be found here - https://github.com/gocd/gocd-ldap-authentication-plugin

+ +

Conclusion

+ +

Our goal is to provide flexible endpoints so that people can use any/multiple authorization service providers of their choice. As demonstrated in the above example, we were able to add a light-weight OpenLDAP server with ease.

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/03/index.html b/pr-1714/2019/03/index.html new file mode 100644 index 000000000..b11c363b1 --- /dev/null +++ b/pr-1714/2019/03/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05.html b/pr-1714/2019/05.html new file mode 100644 index 000000000..fcc50ca8e --- /dev/null +++ b/pr-1714/2019/05.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/14.html b/pr-1714/2019/05/14.html new file mode 100644 index 000000000..2c5cb7e51 --- /dev/null +++ b/pr-1714/2019/05/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/14/index.html b/pr-1714/2019/05/14/index.html new file mode 100644 index 000000000..9d8c15138 --- /dev/null +++ b/pr-1714/2019/05/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm.html b/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm.html new file mode 100644 index 000000000..d5d674f8e --- /dev/null +++ b/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm.html @@ -0,0 +1,365 @@ + + + + + + + + + + + + + + + + Installing and Configuring GoCD on GKE using Helm | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Install and Configure GoCD on GKE using Helm +
+ +
+ + +
+

Installing and Configuring GoCD on GKE using Helm

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this post hoping someone like me would find it helpful.

+ +

Creating a Cluster

+ +

You can create the cluster using multiple options. You can use

+ + + +

You can specify the zone, GKE master version, the machine type and number of nodes among other things as per your requirements. Remember to allocate enough vCPUs and RAM to run the GoCD server as well as the agents.

+ +

Deploy GoCD

+

GoCD provides a helm chart to deploy GoCD easily in a cluster. You can also find a basic tutorial here which I’m repeating for better continuity.

+ +

1) First you have to set the correct context so that we are able to deploy GoCD in the correct cluster.

+ +
gcloud container clusters get-credentials <CLUSTER-NAME> —- zone
+ <ZONE-NAME> —- project <PROJECT-NAME>
+
+ +

2) Once the correct context is set, helm needs to be installed. If you don’t have it in your machine, install it using one of the many options that helm offers. Then helm needs to be installed on the cluster. This can be done as

+ +
helm init
+
+ +

This will install Tiller which is the server side component of Helm on your cluster.

+ +

3) Next we need to create a cluster role binding with the kube-system service account.

+ +
kubectl create clusterrolebinding clusterRoleBinding \
+--clusterrole=cluster-admin \
+--serviceaccount=kube-system:default
+
+ +

4) Now we add the repository where the GoCD chart is available as follows.

+ +
helm repo add gocd https://gocd.github.io/helm-chart
+
+ +

5) Now, all we have to do is just install the chart as

+ +
helm install gocd/gocd —- name gocd —- namespace gocd
+
+ +

This will install GoCD on your server along with an ingress to allow access to the Go server over the internet.

+ +

GoCD Public IP Address

+ +

You can use the following command to get the IP address of the Go server

+ +
kubectl get ingress --namespace gocd gocd-server -o jsonpath=
+"{.status.loadBalancer.ingress[0].ip}"
+
+ +

If you go to the server you’ll be able to see the GoCD dashboard with a hello-world pipeline executed just to verify if everything works.

+ +

But executing the above command configures the Go server using the values available in this values.yaml file. If you are just playing around to get a feel of using GoCD in Kubernetes, this is fine. However if you are trying to configure the GoCD server with some basic options, then it’s better to use your own values.yaml file as follows

+ +
helm install —- name gocd-app —- namespace gocd -f values.yaml gocd/gocd
+
+ +

Configuring Password File based Authentication

+ +

For our usecase we needed to add password based authentication in GoCD. Password based authentication is available in GoCD as a built-in plugin called Password File Authentication Plugin. The plugin uses a password file to authenticate whose location can be configured.

+ +

The GoCD helm chart allows us to mount volumes using secrets. We can make use of this to mount the password file to a specific location. For example if your password file name is go-password, before installing the GoCD helm chart, you can create a secret in the gocd namespace in the cluster as

+ +
kubectl create secret generic go-password \
+--from-file=go-password=go-password \
+--namespace=gocd
+
+ +

Then you can go to the server.persistence.extraVolumes section and add the secret as

+ +
extraVolumes:
+ - name: go-password-volume-name
+   secret:
+     secretName: go-password
+     defaultMode: 0744
+
+ +

This will create a volume (go-password-volume-name) from the given secret name (go-password). Now you can mount the volume to any location you want in the server.persistence.extraVolumeMounts section as follows

+ +
extraVolumeMounts:
+ - name: go-password-volume-name
+   mountPath: /etc/go
+   readOnly: true
+
+ +

This will mount the volume to the /etc/go location. You can now install the GoCD helm chart using the above modified values in the values.yaml.

+ +

An important point to note is that this will only mount the password file in the given location. It will NOT enable password based authentication directly. To enable this, you need to add a new Authorization Configuration. This can be configured using either the UI or using a POST request.

+ +
    +
  1. To use the UI to configure this, you can refer here. Make sure to provide the Password file path correctly. In our case it will be /etc/go/go-password
    2. +
  2. To use a POST request, you can use this cURL command
    3. +
+ +
curl "https://$gocd_public_ip/go/api/admin/security/auth_configs" \
+      -H 'Accept: application/vnd.go.cd.v1+json' \
+      -H 'Content-Type: application/json' \
+      -X POST -d '{
+        "id": "passwordfile",
+        "plugin_id": "cd.go.authentication.passwordfile",
+        "properties": [
+          {
+            "key": "PasswordFilePath",
+            "value": "/etc/go/go-password"
+          }
+        ]
+      }'
+
+ +

You can change the $gocd_public_ip with your GoCD dashboard public IP. You can get this IP from the GoCD Public IP Address section above.

+ +

Configuring Access to GitHub for GoCD Server

+ +

Since we had all of our code hosted in GitHub, we also needed the GoCD server to have access to our GitHub repositories. One of the most used ways to give access to GitHub is SSH. The values.yaml file allows us to specify a secret that will contain the necessary SSH key files. For more information on generating SSH keys, you can refer here. For GoCD, the three files i.e id_rsa, id_rsa.pub and known_hosts have to be copied to the /etc/go/.ssh folder. This is because GoCD operates with a username called go.

+ +

Once you have created these three files you can create a kubernetes secret as

+ +
echo "Creating SSH secret to allow access to our Git Repos"
+kubectl create secret generic gocd-server-ssh \
+--from-file=id_rsa=ssh/id_rsa \
+--from-file=id_rsa.pub=ssh/id_rsa.pub \
+--from-file=known_hosts=ssh/known_hosts \
+--namespace=gocd
+
+ +

This creates a secret gocd-server-ssh in the cluster’s gocd namespace. We can then specify this secret in the server.security.ssh section as follows

+ +
security:
+  ssh:
+    # server.security.ssh.enabled is the toggle to enable/disable mounting of ssh secret on GoCD server pods
+    enabled: true
+    # server.security.ssh.secretName specifies the name of the k8s secret object that contains the ssh key and known hosts
+    secretName: gocd-server-ssh
+
+ +

Configuring Access to GitHub for GoCD Agent

+ +

Just because the GoCD Server has access doesn’t mean that it’s corresponding GoCD agents will also have access. Access for agents has to be configured separately. This is similar to configuring for the server. You can specify the secret name in the agent.security.ssh section as follows

+ +
security:
+  ssh:
+    # agent.security.ssh.enabled is the toggle to enable/disable mounting of ssh secret on GoCD agent pods
+    enabled: true
+    # agent.security.ssh.secretName specifies the name of the k8s secret object that contains the ssh key and known hosts
+    secretName: gocd-agent-ssh
+
+ +

Note: This will work only if you use static GoCD agents that are always running. It will NOT work if you use elastic agents via elastic agent profiles.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I’ll answer from whatever I’ve learnt so far.

+ +

*This post was originally published on Mohamed Najiullah's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm/index.html b/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm/index.html new file mode 100644 index 000000000..584a4d149 --- /dev/null +++ b/pr-1714/2019/05/14/installing-configuring-gocd-gke-using-helm/index.html @@ -0,0 +1,365 @@ + + + + + + + + + + + + + + + + Installing and Configuring GoCD on GKE using Helm | GoCD Blog + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+Install and Configure GoCD on GKE using Helm +
+ +
+ + +
+

Installing and Configuring GoCD on GKE using Helm

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this post hoping someone like me would find it helpful.

+ +

Creating a Cluster

+ +

You can create the cluster using multiple options. You can use

+ + + +

You can specify the zone, GKE master version, the machine type and number of nodes among other things as per your requirements. Remember to allocate enough vCPUs and RAM to run the GoCD server as well as the agents.

+ +

Deploy GoCD

+

GoCD provides a helm chart to deploy GoCD easily in a cluster. You can also find a basic tutorial here which I’m repeating for better continuity.

+ +

1) First you have to set the correct context so that we are able to deploy GoCD in the correct cluster.

+ +
gcloud container clusters get-credentials <CLUSTER-NAME> —- zone
+ <ZONE-NAME> —- project <PROJECT-NAME>
+
+ +

2) Once the correct context is set, helm needs to be installed. If you don’t have it in your machine, install it using one of the many options that helm offers. Then helm needs to be installed on the cluster. This can be done as

+ +
helm init
+
+ +

This will install Tiller which is the server side component of Helm on your cluster.

+ +

3) Next we need to create a cluster role binding with the kube-system service account.

+ +
kubectl create clusterrolebinding clusterRoleBinding \
+--clusterrole=cluster-admin \
+--serviceaccount=kube-system:default
+
+ +

4) Now we add the repository where the GoCD chart is available as follows.

+ +
helm repo add gocd https://gocd.github.io/helm-chart
+
+ +

5) Now, all we have to do is just install the chart as

+ +
helm install gocd/gocd —- name gocd —- namespace gocd
+
+ +

This will install GoCD on your server along with an ingress to allow access to the Go server over the internet.

+ +

GoCD Public IP Address

+ +

You can use the following command to get the IP address of the Go server

+ +
kubectl get ingress --namespace gocd gocd-server -o jsonpath=
+"{.status.loadBalancer.ingress[0].ip}"
+
+ +

If you go to the server you’ll be able to see the GoCD dashboard with a hello-world pipeline executed just to verify if everything works.

+ +

But executing the above command configures the Go server using the values available in this values.yaml file. If you are just playing around to get a feel of using GoCD in Kubernetes, this is fine. However if you are trying to configure the GoCD server with some basic options, then it’s better to use your own values.yaml file as follows

+ +
helm install —- name gocd-app —- namespace gocd -f values.yaml gocd/gocd
+
+ +

Configuring Password File based Authentication

+ +

For our usecase we needed to add password based authentication in GoCD. Password based authentication is available in GoCD as a built-in plugin called Password File Authentication Plugin. The plugin uses a password file to authenticate whose location can be configured.

+ +

The GoCD helm chart allows us to mount volumes using secrets. We can make use of this to mount the password file to a specific location. For example if your password file name is go-password, before installing the GoCD helm chart, you can create a secret in the gocd namespace in the cluster as

+ +
kubectl create secret generic go-password \
+--from-file=go-password=go-password \
+--namespace=gocd
+
+ +

Then you can go to the server.persistence.extraVolumes section and add the secret as

+ +
extraVolumes:
+ - name: go-password-volume-name
+   secret:
+     secretName: go-password
+     defaultMode: 0744
+
+ +

This will create a volume (go-password-volume-name) from the given secret name (go-password). Now you can mount the volume to any location you want in the server.persistence.extraVolumeMounts section as follows

+ +
extraVolumeMounts:
+ - name: go-password-volume-name
+   mountPath: /etc/go
+   readOnly: true
+
+ +

This will mount the volume to the /etc/go location. You can now install the GoCD helm chart using the above modified values in the values.yaml.

+ +

An important point to note is that this will only mount the password file in the given location. It will NOT enable password based authentication directly. To enable this, you need to add a new Authorization Configuration. This can be configured using either the UI or using a POST request.

+ +
    +
  1. To use the UI to configure this, you can refer here. Make sure to provide the Password file path correctly. In our case it will be /etc/go/go-password
    2. +
  2. To use a POST request, you can use this cURL command
    3. +
+ +
curl "https://$gocd_public_ip/go/api/admin/security/auth_configs" \
+      -H 'Accept: application/vnd.go.cd.v1+json' \
+      -H 'Content-Type: application/json' \
+      -X POST -d '{
+        "id": "passwordfile",
+        "plugin_id": "cd.go.authentication.passwordfile",
+        "properties": [
+          {
+            "key": "PasswordFilePath",
+            "value": "/etc/go/go-password"
+          }
+        ]
+      }'
+
+ +

You can change the $gocd_public_ip with your GoCD dashboard public IP. You can get this IP from the GoCD Public IP Address section above.

+ +

Configuring Access to GitHub for GoCD Server

+ +

Since we had all of our code hosted in GitHub, we also needed the GoCD server to have access to our GitHub repositories. One of the most used ways to give access to GitHub is SSH. The values.yaml file allows us to specify a secret that will contain the necessary SSH key files. For more information on generating SSH keys, you can refer here. For GoCD, the three files i.e id_rsa, id_rsa.pub and known_hosts have to be copied to the /etc/go/.ssh folder. This is because GoCD operates with a username called go.

+ +

Once you have created these three files you can create a kubernetes secret as

+ +
echo "Creating SSH secret to allow access to our Git Repos"
+kubectl create secret generic gocd-server-ssh \
+--from-file=id_rsa=ssh/id_rsa \
+--from-file=id_rsa.pub=ssh/id_rsa.pub \
+--from-file=known_hosts=ssh/known_hosts \
+--namespace=gocd
+
+ +

This creates a secret gocd-server-ssh in the cluster’s gocd namespace. We can then specify this secret in the server.security.ssh section as follows

+ +
security:
+  ssh:
+    # server.security.ssh.enabled is the toggle to enable/disable mounting of ssh secret on GoCD server pods
+    enabled: true
+    # server.security.ssh.secretName specifies the name of the k8s secret object that contains the ssh key and known hosts
+    secretName: gocd-server-ssh
+
+ +

Configuring Access to GitHub for GoCD Agent

+ +

Just because the GoCD Server has access doesn’t mean that it’s corresponding GoCD agents will also have access. Access for agents has to be configured separately. This is similar to configuring for the server. You can specify the secret name in the agent.security.ssh section as follows

+ +
security:
+  ssh:
+    # agent.security.ssh.enabled is the toggle to enable/disable mounting of ssh secret on GoCD agent pods
+    enabled: true
+    # agent.security.ssh.secretName specifies the name of the k8s secret object that contains the ssh key and known hosts
+    secretName: gocd-agent-ssh
+
+ +

Note: This will work only if you use static GoCD agents that are always running. It will NOT work if you use elastic agents via elastic agent profiles.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I’ll answer from whatever I’ve learnt so far.

+ +

*This post was originally published on Mohamed Najiullah's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/21.html b/pr-1714/2019/05/21.html new file mode 100644 index 000000000..aa7153294 --- /dev/null +++ b/pr-1714/2019/05/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 21 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/21/index.html b/pr-1714/2019/05/21/index.html new file mode 100644 index 000000000..5258699c9 --- /dev/null +++ b/pr-1714/2019/05/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 21 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/21/official-stance-on-java.html b/pr-1714/2019/05/21/official-stance-on-java.html new file mode 100644 index 000000000..3796ce331 --- /dev/null +++ b/pr-1714/2019/05/21/official-stance-on-java.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Effect of Java licensing changes on GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Effect of Java licensing changes on GoCD +
+ +
+ + +
+

Effect of Java licensing changes on GoCD

+

GoCD Team

+

+

+
+ +
+ +

In mid 2018, Oracle announced several changes to the licensing of Java Standard Edition (SE) that took effect in early 2019. Organizations that want to continue to use a supported and up-to-date Oracle JRE will be required to purchase a license from Oracle.

+ +

Oracle also announced a new 6 month release cadence of Java SE. New releases of Java SE will be made available every 6 months. Each release of Java SE will be end-of-life once a newer version is released. For organizations concerned with this release cadence, Oracle will designate some releases as long-term-support (LTS) releases. These editions will receive 8 years of paid commercial support from Oracle.

+ +

For more information about this, take a look at:

+ + + +

What are the options available?

+ +

As an alternative to purchasing commercial support from Oracle, organisations may want to consider OpenJDK, the free, open-source implementation of Java SE. The OpenJDK project will follow Oracle’s 6 month release cadence for Java, and will publish patches and security updates. There are commercially supported and open-source distributions of OpenJDK that GoCD users may possibly use:

+ + + +

A comparison of the different JDK offerings is available here. The GoCD team builds and tests all releases against an appropriate distribution of OpenJDK.

+ +

What does this mean for users of GoCD?

+ +

GoCD bundles the OpenJDK JRE in certain cases: Docker images, Windows installers and Mac OSX installers. We want to ensure that what we ship does not cause infringement issues for organizations using GoCD. Based on conversations with our legal counsel, we believe that it is safe to bundle OpenJDK with GoCD, since it is licensed under GPLv2+CPE (GNU General Public License, version 2, with the Classpath Exception), and is free even for commercial uses.

+ +

Given the 6-month release cycle, the effort required to maintain compatibility and test GoCD on several versions of Java can quickly become overwhelming. We also realize that due to operational and regulatory concerns, it may be infeasible to update Java versions every 6 months in production environments. So, GoCD will will support the last 3 versions of Java. This translates to support for Java versions roughly 18 months older than the current version. We recommend that users stay on the latest version of Java to ensure that they receive security updates or use a JRE from a vendor who backports security fixes and provides updates.

+ +

The compiler target will be adjusted every 6 months when a new Java release is out. The compiler target will be (LATEST_VERSION - 2). For example: if the current GA Java version is 15, the compiler target will be set to 13.

+ +

The impact upon upgrading GoCD:

+ +

Java 13 is expected to be out around September 2019, around the same time this policy kicks in. This will mean that in the GoCD release around September 2019, GoCD will support Java 11, 12, 13 only. If this is not already obvious: Support for Java 8, 9, 10 will be completely dropped in the September 2019 release.

+ +

If you’re using a non-bundled JRE, with any version of GoCD, please make sure that you’re not using a commercial JRE such as Oracle JRE or JDK without a license. GoCD will still work with Oracle JRE, but you might get audited by Oracle and fined, if you are running it without a license.

+ +

Glossary:

+ +
    +
  • Java SE: Java Standard Edition, often just called “Java”.
    • +
  • JRE: Java SE Runtime Environment - needed to run Java SE programs.
    • +
  • JDK: Java SE Development Kit - needed to compile Java SE programs.
    • +
  • GA: General Availability. See the Java release calendar.
    • +
+ +

DISCLAIMER: This does not constitute legal advice. You should consult with your legal counsel to ensure you are compliant with all applicable licensing and other legal or regulatory requirements applicable to your activities or arising from your use of GoCD, Java SE, OpenJDK, or any other software.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/21/official-stance-on-java/index.html b/pr-1714/2019/05/21/official-stance-on-java/index.html new file mode 100644 index 000000000..be7f22cc2 --- /dev/null +++ b/pr-1714/2019/05/21/official-stance-on-java/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + + + + + Effect of Java licensing changes on GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Effect of Java licensing changes on GoCD +
+ +
+ + +
+

Effect of Java licensing changes on GoCD

+

GoCD Team

+

+

+
+ +
+ +

In mid 2018, Oracle announced several changes to the licensing of Java Standard Edition (SE) that took effect in early 2019. Organizations that want to continue to use a supported and up-to-date Oracle JRE will be required to purchase a license from Oracle.

+ +

Oracle also announced a new 6 month release cadence of Java SE. New releases of Java SE will be made available every 6 months. Each release of Java SE will be end-of-life once a newer version is released. For organizations concerned with this release cadence, Oracle will designate some releases as long-term-support (LTS) releases. These editions will receive 8 years of paid commercial support from Oracle.

+ +

For more information about this, take a look at:

+ + + +

What are the options available?

+ +

As an alternative to purchasing commercial support from Oracle, organisations may want to consider OpenJDK, the free, open-source implementation of Java SE. The OpenJDK project will follow Oracle’s 6 month release cadence for Java, and will publish patches and security updates. There are commercially supported and open-source distributions of OpenJDK that GoCD users may possibly use:

+ + + +

A comparison of the different JDK offerings is available here. The GoCD team builds and tests all releases against an appropriate distribution of OpenJDK.

+ +

What does this mean for users of GoCD?

+ +

GoCD bundles the OpenJDK JRE in certain cases: Docker images, Windows installers and Mac OSX installers. We want to ensure that what we ship does not cause infringement issues for organizations using GoCD. Based on conversations with our legal counsel, we believe that it is safe to bundle OpenJDK with GoCD, since it is licensed under GPLv2+CPE (GNU General Public License, version 2, with the Classpath Exception), and is free even for commercial uses.

+ +

Given the 6-month release cycle, the effort required to maintain compatibility and test GoCD on several versions of Java can quickly become overwhelming. We also realize that due to operational and regulatory concerns, it may be infeasible to update Java versions every 6 months in production environments. So, GoCD will will support the last 3 versions of Java. This translates to support for Java versions roughly 18 months older than the current version. We recommend that users stay on the latest version of Java to ensure that they receive security updates or use a JRE from a vendor who backports security fixes and provides updates.

+ +

The compiler target will be adjusted every 6 months when a new Java release is out. The compiler target will be (LATEST_VERSION - 2). For example: if the current GA Java version is 15, the compiler target will be set to 13.

+ +

The impact upon upgrading GoCD:

+ +

Java 13 is expected to be out around September 2019, around the same time this policy kicks in. This will mean that in the GoCD release around September 2019, GoCD will support Java 11, 12, 13 only. If this is not already obvious: Support for Java 8, 9, 10 will be completely dropped in the September 2019 release.

+ +

If you’re using a non-bundled JRE, with any version of GoCD, please make sure that you’re not using a commercial JRE such as Oracle JRE or JDK without a license. GoCD will still work with Oracle JRE, but you might get audited by Oracle and fined, if you are running it without a license.

+ +

Glossary:

+ +
    +
  • Java SE: Java Standard Edition, often just called “Java”.
    • +
  • JRE: Java SE Runtime Environment - needed to run Java SE programs.
    • +
  • JDK: Java SE Development Kit - needed to compile Java SE programs.
    • +
  • GA: General Availability. See the Java release calendar.
    • +
+ +

DISCLAIMER: This does not constitute legal advice. You should consult with your legal counsel to ensure you are compliant with all applicable licensing and other legal or regulatory requirements applicable to your activities or arising from your use of GoCD, Java SE, OpenJDK, or any other software.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/05/index.html b/pr-1714/2019/05/index.html new file mode 100644 index 000000000..052297e83 --- /dev/null +++ b/pr-1714/2019/05/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06.html b/pr-1714/2019/06.html new file mode 100644 index 000000000..ae9cedf43 --- /dev/null +++ b/pr-1714/2019/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06/25.html b/pr-1714/2019/06/25.html new file mode 100644 index 000000000..263903e44 --- /dev/null +++ b/pr-1714/2019/06/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 25 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06/25/GoCD-non-root-containers.html b/pr-1714/2019/06/25/GoCD-non-root-containers.html new file mode 100644 index 000000000..c799c6cd1 --- /dev/null +++ b/pr-1714/2019/06/25/GoCD-non-root-containers.html @@ -0,0 +1,370 @@ + + + + + + + + + + + + + + + + Running Dockerized GoCD Containers as Non Root + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Running Dockerized GoCD Containers as Non Root +
+ +
+ + +
+

Running Dockerized GoCD Containers as Non Root

+

GoCD Team

+

+

+
+ +
+ +

Docker images run with root privileges by default. root user in the container is the same root (uid:0) as on the host machine. If a user manages to break out of an application running as root in a container, they may be able to gain access to the host machine with the same root user.

+ +

Running containers using non-root user provides an additional layer of security against processes escaping the container due to a container engine vulnerability and thereby achieving escalated permissions on the host node.

+ +

Starting from GoCD release v19.6.0, GoCD containers run as non-root user, by default. The Dockerized GoCD application will run as go:root (uid:1000, gid:0) user instead of running as root:root (uid:0, gid:0).

+ +

What are the changes made to GoCD Docker Images to support running containers as non-root?

+ +

1. Add USER instruction in the Dockerfile:

+ +

The USER instruction sets the user name (or UID) to use when running the container and for any instructions that follow it in the Dockerfile.

+ +

GoCD Dockerfile adds a USER instruction to change the current user from the root user to go (uid:1000) user. This instruction will make sure that the go (uid:1000) user is used while running the docker container and also for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile.

+ +

2. Add go user to root group:

+ +

OpenShift Container Platform (OCP) manages containers life-cycle with security in mind at every stage and every layer of application deployments.

+ +

By default, OpenShift prevents root user containers by running containers using an arbitrarily assigned user ID. This arbitrary user ID in the container is always a member of root group on OCP. For an image to support running as an arbitrary user, directories and files that may be written to by processes in the image should be owned by the root group and be read/writable by that group.

+ +

Hence, to allow GoCD application to be deployed on OCP, dockerized GoCD applications run with go:root user.

+ +

Note : The root group does not have any special permissions (unlike the root user). So, there are no security concerns with this arrangement.

+ +

For more information, checkout OCP General Container Image Guidelines.

+ +

3. Modify GoCD Directories and File permissions:

+ +

The GoCD server stores all configuration, pipeline history database, artifacts, plugins, addons and logs into /godata, whereas, additional information such as secure credentials, ssh keys can additionally be stored at /home/go.

+ +

As the existing container user has changed from go:go to go:root, the file permissions of the above mentioned directories and files are changed to go:root.

+ +

What are the Breaking Changes in GoCD Docker Image?

+ +

1. Creating directories in file-system root:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN mkdir /.ssh
+
+ +

Moving files or directories into or out of system directories (i.e., directories that are critical to the functioning of the operating system), copying files into system directories requires root privileges. As GoCD containers do not run as root, RUN mkdir /.ssh command would result in mkdir: /.ssh: Permission denied error.

+ +

In general, root privileges should not be needed by applications running inside the container. In GoCD's context, application-related files and directories should be created under /home/go.

+ +
FROM gocd/gocd-server:v19.6.0
+
+RUN mkdir /home/go/.ssh
+
+ +

Alternatively, if an application requires creating root directories, it can be achieved by switching users in the Dockerfile and executing the root directory creation instruction.

+ +

2. Installing packages:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN apk --update add jq
+
+ +

Root privileges are usually required for installing software because of the need to write to system directories. Packages can be installed by switching users in the Dockerfile.

+ +

3. go group migration:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN mkdir /home/go/creds
+
+RUN chown go:go /home/go/creds
+
+ +

As the go user belongs to root group instead of go group, the above Dockerfile can be changed to:

+ +
FROM gocd/gocd-server:v19.6.0
+
+RUN mkdir /home/go/creds
+
+RUN chown go:root /home/go/creds
+
+ +

Note: Ownership of any files/directories owned by go group needs to be changed to root group as there will no longer be a go group on GoCD images.

+ +

4. Custom Entrypoint Scripts:

+ +

GoCD allows running custom entrypoint scripts to configure GoCD Server before starting. These entrypoint scripts could involve instructions for installing required plugins, configuring basic authentication, etc.

+ +

Starting from GoCD release v19.6.0, custom entrypoint scripts will run as go user (instead of root user). We recommend users to not include scripts requiring root privileges as part of custom entrypoint scripts.

+ +

Any pre-configuration instructions requiring root privileges should be included in a Dockerfile.

+ +

+ +

5. Shared Volume Permissions:

+ +

GoCD stores all configuration, pipeline history database, artifacts, plugins, and logs into /godata. Whereas, secure credentials like SSH private keys among other things, can be mounted at /home/go.

+ +

For GoCD to persist these configurations across container restarts, /godata and /home/go directories can be volume mounted inside the container.

+ +

Prior to GoCD v19.6.0, GoCD containers are run as root user, because of which, the container user has permissions to the volume mounted folders/files. Starting from GoCD release v19.6.0, the GoCD container user will be running as go(uid:1000) user. As a result, the container non-root user will not have permissions to the volume mounted folder/files (by default).

+ +

In the Docker context, container's users are mapped with host's users. Similarly, the permissions for host mounted volumes comes from the host OS. To allow go(uid:1000) within the container to have permissions to the mounted volume folders/files requires changing the mounted volume ownership to go:root.

+ +

Multiple USER instructions

+ +

The USER instruction in the Dockerfile changes the user to the specified user for the subsequent instructions in the Dockerfile. Multiple USER instructions can be used to switch the user context from root to non-root user.

+ +

Example:

+ +
FROM gocd/gocd-server:v19.6.0
+
+USER root
+
+RUN mkdir /creds
+RUN chown -r go:root /creds
+RUN apk --update add jq
+
+USER go
+
+ +

In the above example, the following instruction block is executed as root user because of the preceding USER root instruction. And finally, the user is switched back to go using USER go instruction.

+ +
RUN mkdir /creds
+RUN chown -r go:root /creds
+RUN apk --update add jq
+
+ +

Note: The USER go instruction after the instruction requiring root privileges is required to change the user back to go. Failing to add USER go instruction at the end would make container to execute as root user.

+ +

How to verify the container user?

+ +

To verify whether the user running inside the container is root or non-root, we can execute following command(s):

+ +

1. Verify the UID of container user is non-zero:

+ +
$ docker container run gocd/gocd-server:v19.6.0 id
+> uid=1000(go) gid=0(root) groups=0(root)
+
+ +

2. Verify the container user does have access to root directory:

+ +
$ docker container run gocd/gocd-server:v19.6.0 ls /root/
+> ls: can't open '/root/': Permission denied
+
+ +

But, what if I want to run containers as root?

+ +

Sometimes, the application container requires access to the privileged resources in order to perform its required function(s). It can be achieved by granting certain privileges to the user, or running the application container as root user.

+ +

1. Using USER root instruction:

+ +
FROM gocd/gocd-server:v19.6.0
+
+USER root
+
+ +

A USER root instruction can be added to the extending image to change the user context from go user to root user.

+ +

2. Using --user argument:

+ +
docker container run --user root:root gocd/gocd-server:v19.6.0
+
+ +

The container user can be specified using --user option to the docker container run command while starting the container from command line.

+ +

Note: Well designed systems adhere to the principle of least privilege. This simply states that an application should only have access to the resources it needs in order to perform its required function.

+ +

GoCD containerized processes are application services and therefore don’t require root access. We strongly recommend users to grant required privileges to the go user and avoid running as root.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06/25/GoCD-non-root-containers/index.html b/pr-1714/2019/06/25/GoCD-non-root-containers/index.html new file mode 100644 index 000000000..5bfb1ff23 --- /dev/null +++ b/pr-1714/2019/06/25/GoCD-non-root-containers/index.html @@ -0,0 +1,370 @@ + + + + + + + + + + + + + + + + Running Dockerized GoCD Containers as Non Root + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Running Dockerized GoCD Containers as Non Root +
+ +
+ + +
+

Running Dockerized GoCD Containers as Non Root

+

GoCD Team

+

+

+
+ +
+ +

Docker images run with root privileges by default. root user in the container is the same root (uid:0) as on the host machine. If a user manages to break out of an application running as root in a container, they may be able to gain access to the host machine with the same root user.

+ +

Running containers using non-root user provides an additional layer of security against processes escaping the container due to a container engine vulnerability and thereby achieving escalated permissions on the host node.

+ +

Starting from GoCD release v19.6.0, GoCD containers run as non-root user, by default. The Dockerized GoCD application will run as go:root (uid:1000, gid:0) user instead of running as root:root (uid:0, gid:0).

+ +

What are the changes made to GoCD Docker Images to support running containers as non-root?

+ +

1. Add USER instruction in the Dockerfile:

+ +

The USER instruction sets the user name (or UID) to use when running the container and for any instructions that follow it in the Dockerfile.

+ +

GoCD Dockerfile adds a USER instruction to change the current user from the root user to go (uid:1000) user. This instruction will make sure that the go (uid:1000) user is used while running the docker container and also for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile.

+ +

2. Add go user to root group:

+ +

OpenShift Container Platform (OCP) manages containers life-cycle with security in mind at every stage and every layer of application deployments.

+ +

By default, OpenShift prevents root user containers by running containers using an arbitrarily assigned user ID. This arbitrary user ID in the container is always a member of root group on OCP. For an image to support running as an arbitrary user, directories and files that may be written to by processes in the image should be owned by the root group and be read/writable by that group.

+ +

Hence, to allow GoCD application to be deployed on OCP, dockerized GoCD applications run with go:root user.

+ +

Note : The root group does not have any special permissions (unlike the root user). So, there are no security concerns with this arrangement.

+ +

For more information, checkout OCP General Container Image Guidelines.

+ +

3. Modify GoCD Directories and File permissions:

+ +

The GoCD server stores all configuration, pipeline history database, artifacts, plugins, addons and logs into /godata, whereas, additional information such as secure credentials, ssh keys can additionally be stored at /home/go.

+ +

As the existing container user has changed from go:go to go:root, the file permissions of the above mentioned directories and files are changed to go:root.

+ +

What are the Breaking Changes in GoCD Docker Image?

+ +

1. Creating directories in file-system root:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN mkdir /.ssh
+
+ +

Moving files or directories into or out of system directories (i.e., directories that are critical to the functioning of the operating system), copying files into system directories requires root privileges. As GoCD containers do not run as root, RUN mkdir /.ssh command would result in mkdir: /.ssh: Permission denied error.

+ +

In general, root privileges should not be needed by applications running inside the container. In GoCD's context, application-related files and directories should be created under /home/go.

+ +
FROM gocd/gocd-server:v19.6.0
+
+RUN mkdir /home/go/.ssh
+
+ +

Alternatively, if an application requires creating root directories, it can be achieved by switching users in the Dockerfile and executing the root directory creation instruction.

+ +

2. Installing packages:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN apk --update add jq
+
+ +

Root privileges are usually required for installing software because of the need to write to system directories. Packages can be installed by switching users in the Dockerfile.

+ +

3. go group migration:

+ +
FROM gocd/gocd-server:v19.5.0
+
+RUN mkdir /home/go/creds
+
+RUN chown go:go /home/go/creds
+
+ +

As the go user belongs to root group instead of go group, the above Dockerfile can be changed to:

+ +
FROM gocd/gocd-server:v19.6.0
+
+RUN mkdir /home/go/creds
+
+RUN chown go:root /home/go/creds
+
+ +

Note: Ownership of any files/directories owned by go group needs to be changed to root group as there will no longer be a go group on GoCD images.

+ +

4. Custom Entrypoint Scripts:

+ +

GoCD allows running custom entrypoint scripts to configure GoCD Server before starting. These entrypoint scripts could involve instructions for installing required plugins, configuring basic authentication, etc.

+ +

Starting from GoCD release v19.6.0, custom entrypoint scripts will run as go user (instead of root user). We recommend users to not include scripts requiring root privileges as part of custom entrypoint scripts.

+ +

Any pre-configuration instructions requiring root privileges should be included in a Dockerfile.

+ +

+ +

5. Shared Volume Permissions:

+ +

GoCD stores all configuration, pipeline history database, artifacts, plugins, and logs into /godata. Whereas, secure credentials like SSH private keys among other things, can be mounted at /home/go.

+ +

For GoCD to persist these configurations across container restarts, /godata and /home/go directories can be volume mounted inside the container.

+ +

Prior to GoCD v19.6.0, GoCD containers are run as root user, because of which, the container user has permissions to the volume mounted folders/files. Starting from GoCD release v19.6.0, the GoCD container user will be running as go(uid:1000) user. As a result, the container non-root user will not have permissions to the volume mounted folder/files (by default).

+ +

In the Docker context, container's users are mapped with host's users. Similarly, the permissions for host mounted volumes comes from the host OS. To allow go(uid:1000) within the container to have permissions to the mounted volume folders/files requires changing the mounted volume ownership to go:root.

+ +

Multiple USER instructions

+ +

The USER instruction in the Dockerfile changes the user to the specified user for the subsequent instructions in the Dockerfile. Multiple USER instructions can be used to switch the user context from root to non-root user.

+ +

Example:

+ +
FROM gocd/gocd-server:v19.6.0
+
+USER root
+
+RUN mkdir /creds
+RUN chown -r go:root /creds
+RUN apk --update add jq
+
+USER go
+
+ +

In the above example, the following instruction block is executed as root user because of the preceding USER root instruction. And finally, the user is switched back to go using USER go instruction.

+ +
RUN mkdir /creds
+RUN chown -r go:root /creds
+RUN apk --update add jq
+
+ +

Note: The USER go instruction after the instruction requiring root privileges is required to change the user back to go. Failing to add USER go instruction at the end would make container to execute as root user.

+ +

How to verify the container user?

+ +

To verify whether the user running inside the container is root or non-root, we can execute following command(s):

+ +

1. Verify the UID of container user is non-zero:

+ +
$ docker container run gocd/gocd-server:v19.6.0 id
+> uid=1000(go) gid=0(root) groups=0(root)
+
+ +

2. Verify the container user does have access to root directory:

+ +
$ docker container run gocd/gocd-server:v19.6.0 ls /root/
+> ls: can't open '/root/': Permission denied
+
+ +

But, what if I want to run containers as root?

+ +

Sometimes, the application container requires access to the privileged resources in order to perform its required function(s). It can be achieved by granting certain privileges to the user, or running the application container as root user.

+ +

1. Using USER root instruction:

+ +
FROM gocd/gocd-server:v19.6.0
+
+USER root
+
+ +

A USER root instruction can be added to the extending image to change the user context from go user to root user.

+ +

2. Using --user argument:

+ +
docker container run --user root:root gocd/gocd-server:v19.6.0
+
+ +

The container user can be specified using --user option to the docker container run command while starting the container from command line.

+ +

Note: Well designed systems adhere to the principle of least privilege. This simply states that an application should only have access to the resources it needs in order to perform its required function.

+ +

GoCD containerized processes are application services and therefore don’t require root access. We strongly recommend users to grant required privileges to the go user and avoid running as root.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06/25/index.html b/pr-1714/2019/06/25/index.html new file mode 100644 index 000000000..9228ed0c6 --- /dev/null +++ b/pr-1714/2019/06/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 25 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/06/index.html b/pr-1714/2019/06/index.html new file mode 100644 index 000000000..ca157c018 --- /dev/null +++ b/pr-1714/2019/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08.html b/pr-1714/2019/08.html new file mode 100644 index 000000000..3c25b6e70 --- /dev/null +++ b/pr-1714/2019/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08/05.html b/pr-1714/2019/08/05.html new file mode 100644 index 000000000..01430876a --- /dev/null +++ b/pr-1714/2019/08/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html b/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html new file mode 100644 index 000000000..27723d375 --- /dev/null +++ b/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + Configuring Google Container Registry (GCR) as an Artifact Store in GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Configuring Google Container Registry as an Artifact Store in GoCD +
+ +
+ + +
+

Configuring Google Container Registry (GCR) as an Artifact Store in GoCD

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this and a few other posts hoping someone like me would find it helpful. This is the second part on Configuring Google Container Registry (GCR) as an Artifact Store in GoCD. You can find the first part on Installing and Configuring GoCD on GKE using Helm.

+ +

GoCD allows configuration of artifact stores such as Dockerhub, Amazon's ECR, Google's GCR to store and pull docker image artifacts. Depending on your version you can get two types of configuration windows. Let me show the latest configuration window of the artifact store`

+ +

Configuring Google Container Registry as an Artifact Store in GoCD

+ +

There are two options based on the Registry Type. The first one is Amazon ECR. There are corresponding options for ECR Registry ID, AWS Region, AWS Access Key Id and AWS Secret Access Key.The second one says 'Others' and lists Dockerhub, GCR and private. For Dockerhub there are fields for username and password along with Docker Registry URL.

+ +

The older plugin version does not have a separate option for Amazon ECR. It just has the same fields for all stores

+ +

Configuring Google Container Registry as an Artifact Store in GoCD

+ +

Trying to configure GCR in both the versions seems a bit confusing as GCR best practices state the use of a service account for CI/CD pipelines.

+ +

Now if you try to create a service account, you might get a json file with the following fields:

+ +
{
+  "type": "service_account",
+  "project_id": "<project-id>",
+  "private_key_id": "<private-key-id>",
+  "private_key": "<private-key>",
+  "client_email": "<client-email>,
+  "client_id": "<client-id>",
+  "auth_uri": "<auth-uri>",
+  "token_uri": "<token-uri>",
+  "auth_provider_x509_cert_url": "<auth-provider-x509-cert-url>",
+  "client_x509_cert_url": "<client-x509-cert-url>"
+}
+
+ +

This json file contains the keys necessary for authenticating with GCR to push or pull docker images. Going through the GitHub repository for information regarding how we can use the service account credentials, we came across this issue that had a comment on how to use the service account.

+ +

According to the comment, we had to use _json_key as the username and just use the entire json file content as the password. You can see this in the above image of the configuration window. While this seemed odd, it worked!

+ +

You can also set this up using a cURL command to make a POST call to the API exposed by the GoCD server.

+ +
curl "https://$gocd_public_ip/go/api/admin/artifact_stores" \
+  -u "$USERNAME:$PASSWORD" \
+  -H 'Accept: application/vnd.go.cd.v1+json' \
+  -H 'Content-Type: application/json' \
+  -X POST -d '{
+    "id": "docker",
+    "plugin_id": "cd.go.artifact.docker.registry",
+    "properties" : [ {
+      "key" : "RegistryURL",
+      "value" : "<registry-url>"
+    }, {
+      "key" : "Username",
+      "value" : "_json_key"
+    }, {
+      "key" : "Password",
+      "value" : "{
+  \"type\": \"service_account\",
+  \"project_id\": \"<project-id>\",
+  \"private_key_id\": \"<private-key-id>\",
+  \"private_key\": \"<private-key>\",
+  \"client_email\": \"<client-email>\",
+  \"client_id\": \"<client-id>\",
+  \"auth_uri\": \"<auth-uri>\",
+  \"token_uri\": \"<token-uri>\",
+  \"auth_provider_x509_cert_url\": \"<auth-provider-x509-cert-url>\",
+  \"client_x509_cert_url\": \"<client-x509-cert-url>\"
+}"
+    }]
+}'
+
+ +

Replace the $gocd_public_ip with the public IP of the GoCD server along with $USERNAME and $PASSWORD of an admin account before running the above command with the values from your service account json file.

+ +

This should give your GoCD server access to your GCR images. If your GoCD Agent image is in this GCR repository, you should be able to use the images present here for your GoCD Agents.

+ +

Note: This will work directly only if you are using GKE for your GoCD cluster. For other providers like EKS, AKS or even Minikube, you'll need to do a few additional steps of adding imagePullSecrets to the service account. You can find this information here.

+ +

Pushing Images to an Artifact Store

+ +

If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry.

+ +

This comes with a significant advantage that your GoCD Agents do NOT need to have access to the registry/repository as your GoCD Server will push the image instead of the Go Agents.

+ +

All you have to do is to configure the generated image as an external artifact. You can find the steps to do that here.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I'll answer from whatever I've learnt so far.

+ +

This post was originally published on Mohamed Najiullah's blog

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/index.html b/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/index.html new file mode 100644 index 000000000..8dcefa02e --- /dev/null +++ b/pr-1714/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/index.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + Configuring Google Container Registry (GCR) as an Artifact Store in GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Configuring Google Container Registry as an Artifact Store in GoCD +
+ +
+ + +
+

Configuring Google Container Registry (GCR) as an Artifact Store in GoCD

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this and a few other posts hoping someone like me would find it helpful. This is the second part on Configuring Google Container Registry (GCR) as an Artifact Store in GoCD. You can find the first part on Installing and Configuring GoCD on GKE using Helm.

+ +

GoCD allows configuration of artifact stores such as Dockerhub, Amazon's ECR, Google's GCR to store and pull docker image artifacts. Depending on your version you can get two types of configuration windows. Let me show the latest configuration window of the artifact store`

+ +

Configuring Google Container Registry as an Artifact Store in GoCD

+ +

There are two options based on the Registry Type. The first one is Amazon ECR. There are corresponding options for ECR Registry ID, AWS Region, AWS Access Key Id and AWS Secret Access Key.The second one says 'Others' and lists Dockerhub, GCR and private. For Dockerhub there are fields for username and password along with Docker Registry URL.

+ +

The older plugin version does not have a separate option for Amazon ECR. It just has the same fields for all stores

+ +

Configuring Google Container Registry as an Artifact Store in GoCD

+ +

Trying to configure GCR in both the versions seems a bit confusing as GCR best practices state the use of a service account for CI/CD pipelines.

+ +

Now if you try to create a service account, you might get a json file with the following fields:

+ +
{
+  "type": "service_account",
+  "project_id": "<project-id>",
+  "private_key_id": "<private-key-id>",
+  "private_key": "<private-key>",
+  "client_email": "<client-email>,
+  "client_id": "<client-id>",
+  "auth_uri": "<auth-uri>",
+  "token_uri": "<token-uri>",
+  "auth_provider_x509_cert_url": "<auth-provider-x509-cert-url>",
+  "client_x509_cert_url": "<client-x509-cert-url>"
+}
+
+ +

This json file contains the keys necessary for authenticating with GCR to push or pull docker images. Going through the GitHub repository for information regarding how we can use the service account credentials, we came across this issue that had a comment on how to use the service account.

+ +

According to the comment, we had to use _json_key as the username and just use the entire json file content as the password. You can see this in the above image of the configuration window. While this seemed odd, it worked!

+ +

You can also set this up using a cURL command to make a POST call to the API exposed by the GoCD server.

+ +
curl "https://$gocd_public_ip/go/api/admin/artifact_stores" \
+  -u "$USERNAME:$PASSWORD" \
+  -H 'Accept: application/vnd.go.cd.v1+json' \
+  -H 'Content-Type: application/json' \
+  -X POST -d '{
+    "id": "docker",
+    "plugin_id": "cd.go.artifact.docker.registry",
+    "properties" : [ {
+      "key" : "RegistryURL",
+      "value" : "<registry-url>"
+    }, {
+      "key" : "Username",
+      "value" : "_json_key"
+    }, {
+      "key" : "Password",
+      "value" : "{
+  \"type\": \"service_account\",
+  \"project_id\": \"<project-id>\",
+  \"private_key_id\": \"<private-key-id>\",
+  \"private_key\": \"<private-key>\",
+  \"client_email\": \"<client-email>\",
+  \"client_id\": \"<client-id>\",
+  \"auth_uri\": \"<auth-uri>\",
+  \"token_uri\": \"<token-uri>\",
+  \"auth_provider_x509_cert_url\": \"<auth-provider-x509-cert-url>\",
+  \"client_x509_cert_url\": \"<client-x509-cert-url>\"
+}"
+    }]
+}'
+
+ +

Replace the $gocd_public_ip with the public IP of the GoCD server along with $USERNAME and $PASSWORD of an admin account before running the above command with the values from your service account json file.

+ +

This should give your GoCD server access to your GCR images. If your GoCD Agent image is in this GCR repository, you should be able to use the images present here for your GoCD Agents.

+ +

Note: This will work directly only if you are using GKE for your GoCD cluster. For other providers like EKS, AKS or even Minikube, you'll need to do a few additional steps of adding imagePullSecrets to the service account. You can find this information here.

+ +

Pushing Images to an Artifact Store

+ +

If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry.

+ +

This comes with a significant advantage that your GoCD Agents do NOT need to have access to the registry/repository as your GoCD Server will push the image instead of the Go Agents.

+ +

All you have to do is to configure the generated image as an external artifact. You can find the steps to do that here.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I'll answer from whatever I've learnt so far.

+ +

This post was originally published on Mohamed Najiullah's blog

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08/05/index.html b/pr-1714/2019/08/05/index.html new file mode 100644 index 000000000..74d49100d --- /dev/null +++ b/pr-1714/2019/08/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/08/index.html b/pr-1714/2019/08/index.html new file mode 100644 index 000000000..11e33781b --- /dev/null +++ b/pr-1714/2019/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09.html b/pr-1714/2019/09.html new file mode 100644 index 000000000..8111faa31 --- /dev/null +++ b/pr-1714/2019/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09/17.html b/pr-1714/2019/09/17.html new file mode 100644 index 000000000..5060e36d4 --- /dev/null +++ b/pr-1714/2019/09/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 17 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html b/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html new file mode 100644 index 000000000..5ea10f189 --- /dev/null +++ b/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html @@ -0,0 +1,339 @@ + + + + + + + + + + + + + + + + Configuring GoCD Agents in Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Configuring Google Container Registry as an Artifact Store in GoCD +
+ +
+ + +
+

Configuring GoCD Agents in Kubernetes

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this and a few other posts hoping someone like me would find it helpful. This is the third part on Configuring Go Agents in GoCD in Kubernetes: Static and Elastic Agents. You can find the first part on Installing and Configuring GoCD on GKE using Helm here and the second part on Configuring Google Container Registry (GCR) as an Artifact Store in GoCD here.

+ +

While carrying out our spike on our CI/CD infrastructure from a VM based design to a Kubernetes based one, we also had to configure GoCD Agents. According to the official documentation,

+ +
+

GoCD Agents are the workers in the GoCD ecosystem. All tasks configured in the system run on GoCD Agents.

+
+ +

The latest version of GoCD offers two types of GoCD agents, Static and Elastic.

+ +

Static Agents

+

In our old system, we have a predefined number of GoCD Agents. These agents are VMs that we had created, provisioned and connected to the Go Server using Infrastructure as Code tools like Puppet. The agents needed a number of tools and packages to do the things we needed them to do. All these tools and packages had to be provisioned into all the agents individually once we had created them.

+ +

But for a GoCD setup on Kubernetes, it becomes much simpler to maintain agents as every agent is simply a pod. The GoCD Helm chart allows us to configure always running agents using the values in the values.yaml file I’ve mentioned in my previous post.

+ +

This greatly simplifies provisioning the agents as all we have to do is create a Docker image with all the tools and packages installed in it. Once we have this image ready we can specify it in the agent.image section of the values.yaml fileas follows

+ +
agent:
+  image:
+    # agent.image.repository is the GoCD Agent image name
+    repository: "gocd/gocd-agent-alpine-3.9"# agent.image.tag is the GoCD Agent image's tag
+    tag: v19.3
+    # agent.image.pullPolicy is the GoCD Agent image's pull policy
+    pullPolicy: "IfNotPresent" # agent.replicaCount is the GoCD Agent replicas Count. Specify the number of GoCD agents to run
+  replicaCount: 2
+
+ +

The above example states that the agent repository is gocd/gocd-agent-alpine-3.9 with the version being v19.3. You can also the specify the replica count. This is the number of agents that will be running once the values are deployed.

+ +

Every time a new tool or package is to be added to the agent, a new image can be created. Then this image can be referenced in the given image fields before being applied. This greatly simplifies the upgrade process.

+ +

*Note:

+ +
    +
  1. The given repository should be public. If a private repository is used, then the Go server should have access to it. I have mentioned how to configure access for a private repository using the Docker Artifact Store plugin here.
    2. +
  2. All agents that are created after applying the values will be in a pending state. They have to be manually enabled.*
    3. +
+ +

There are many other configuration options available in the values.yaml that can be used to configure the agents. One important example is the security.ssh section that allows us to mount a SSH files using a kubernetes secret. This can be used to allow access to various VCS that use SSH to control access. I’ve explained it in a little more detail in the first post of this series. You can also specify the storage, memory as well as maximum CPU allocation for the agents.

+ +

Elastic Agents:

+ +

We also experimented with elastic agents which is a relatively new feature offered by GoCD. According to the official documentation

+ +

Elastic Agents is an extension-point in GoCD that allows for on-demand agents which are created and provisioned by an elastic-agent plugin when there are jobs to be executed, and terminated when the agents are running idle.

+ +

Elastic Agents have a significant advantage in that they get created when there is a pending job and get destroyed when the job gets completed. This can theoretically result in a lot of cost saving as the agents don’t have to keep on waiting for a job but rather are created only when necessary.

+ +

I can explain a scenario of how using elastic agents can result in cost savings. You can provision a cluster with a single n1-standard-1 VM (3.5GB RAM, 1vCPU) to start with. You can then enable the auto-scaling feature with a reasonable maximum node limit. This will ensure that when no jobs are running all nodes except the first node will be deleted resulting in cost saving compared to have a fixed number of static Go agents.

+ +

GoCD offers a number of plugins that support different Cloud providers like AWS or Azure or different orchestration platforms like DockerSwarm or Kubernetes. Considering that we were trying this out on Kubernetes we used the GoCD Elastic Agent plugin for Kubernetes.

+ +

Elastic Agent Profiles

+ +

Elastic Agent Profiles allows you to configure elastic agents. This configuration allows you to specify the following

+ +
    +
  • Container Image with its tag
    • +
  • Max Memory and CPU
    • +
  • Security Context
    • +
  • Volume Mounts
    • +
  • Environment Variables
    • +
+ +

The configuration can be specified using the UI or by making a cURL request to the API exposed by the Go Server.

+ +

Configuration Using UI

+ +

The UI option can be found under the Elastic Profiles section in the Admin menu of the Go Dashboard. You’ll be able to see a cluster profile called k8-cluster-profile. You can see the existing elastic agent profiles if you expand the section. You’ll find an option to add an Elastic Agent Profile. If you select it, you’ll be able to see a pop-up window with 3 options on how to specify the Agent Pod configuration. You can either

+ +
    +
  • Use the config properties option to add the configuration using the various fields.
    • +
  • Use the Pod Yaml option to specify the pod’s configuration in yaml.
    • +
  • Use the Remote file option to specify the pod’s configuration using an external json or yaml file.
    • +
+ +

Configuration Using API POST Request

+ +

You can also configure an Elastic Agent profile using the API that the GoCD server exposes. You can simply make a POST call using cURL like the following

+ +
curl -vi "[https://$gocd_public_ip/go/api/elastic/profiles](https://$gocd_public_ip/go/api/elastic/profiles)" \
+           -u "$USERNAME:$PASSWORD" \
+           -H 'Accept: application/vnd.go.cd.v2+json' \
+           -H 'Content-Type: application/json' \
+           -X POST -d '{
+        "id": "goagent-1",
+        "plugin_id": "cd.go.contrib.elasticagent.kubernetes",
+        "cluster_profile_id": "k8-cluster-profile",
+        "properties": [
+          {
+            "key": "PodConfiguration",
+            "value": "apiVersion: v1
+kind: Pod
+metadata:
+  name: gocd-agent-{{ POD_POSTFIX }}
+  labels:
+    app: web
+spec:
+  serviceAccountName: default
+  containers:
+    - name: gocd-agent-container-{{ CONTAINER_POSTFIX }}
+      image: <image-name-with-version>
+      volumeMounts:
+      - name: gocd-agent-ssh
+        mountPath: \"/home/go/.ssh\"
+        readOnly: true
+  volumes:
+  - name: gocd-agent-ssh
+    secret:
+      secretName: gocd-agent-ssh"
+          },
+          {
+            "key": "PodSpecType",
+            "value": "yaml"
+          },
+          {
+            "key": "Privileged",
+            "value": "true"
+          }
+        ]
+      }'
+
+ +

As you can see the pod spec has been specified in YAML. You will have to set the variables _$gocd_public_ip , $USERNAME and $PASSWORD with the appropriate values. The username and password should be of a user that has admin privileges to run the above command. If you want to configure using other options, you can use the appropriate keys in the properties array.

+ +

Git Repositories Access Using Git

+ +

If you want the pod to have SSH access to a Git service, you can create a secret with the SSH files and then mount it like shown in the pod spec above. Doing this should give your elastic agents access to your Git repositories.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I’ll answer from whatever I’ve learnt so far.

+ +

This article was originally posted on Mohamed Najiullah's blog

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/index.html b/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/index.html new file mode 100644 index 000000000..0759ff48b --- /dev/null +++ b/pr-1714/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/index.html @@ -0,0 +1,339 @@ + + + + + + + + + + + + + + + + Configuring GoCD Agents in Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Configuring Google Container Registry as an Artifact Store in GoCD +
+ +
+ + +
+

Configuring GoCD Agents in Kubernetes

+

Mohamed Najiullah

+

+

+
+ +
+ +

Recently, a colleague and I had to spike on the possibility of migrating our CI/CD infrastructure from a VM based design to a Kubernetes based one.

+ +

While exploring how to do it, we had to spend some time to find out all the information we needed just to install and configure GoCD without the migration. So I decided to write this and a few other posts hoping someone like me would find it helpful. This is the third part on Configuring Go Agents in GoCD in Kubernetes: Static and Elastic Agents. You can find the first part on Installing and Configuring GoCD on GKE using Helm here and the second part on Configuring Google Container Registry (GCR) as an Artifact Store in GoCD here.

+ +

While carrying out our spike on our CI/CD infrastructure from a VM based design to a Kubernetes based one, we also had to configure GoCD Agents. According to the official documentation,

+ +
+

GoCD Agents are the workers in the GoCD ecosystem. All tasks configured in the system run on GoCD Agents.

+
+ +

The latest version of GoCD offers two types of GoCD agents, Static and Elastic.

+ +

Static Agents

+

In our old system, we have a predefined number of GoCD Agents. These agents are VMs that we had created, provisioned and connected to the Go Server using Infrastructure as Code tools like Puppet. The agents needed a number of tools and packages to do the things we needed them to do. All these tools and packages had to be provisioned into all the agents individually once we had created them.

+ +

But for a GoCD setup on Kubernetes, it becomes much simpler to maintain agents as every agent is simply a pod. The GoCD Helm chart allows us to configure always running agents using the values in the values.yaml file I’ve mentioned in my previous post.

+ +

This greatly simplifies provisioning the agents as all we have to do is create a Docker image with all the tools and packages installed in it. Once we have this image ready we can specify it in the agent.image section of the values.yaml fileas follows

+ +
agent:
+  image:
+    # agent.image.repository is the GoCD Agent image name
+    repository: "gocd/gocd-agent-alpine-3.9"# agent.image.tag is the GoCD Agent image's tag
+    tag: v19.3
+    # agent.image.pullPolicy is the GoCD Agent image's pull policy
+    pullPolicy: "IfNotPresent" # agent.replicaCount is the GoCD Agent replicas Count. Specify the number of GoCD agents to run
+  replicaCount: 2
+
+ +

The above example states that the agent repository is gocd/gocd-agent-alpine-3.9 with the version being v19.3. You can also the specify the replica count. This is the number of agents that will be running once the values are deployed.

+ +

Every time a new tool or package is to be added to the agent, a new image can be created. Then this image can be referenced in the given image fields before being applied. This greatly simplifies the upgrade process.

+ +

*Note:

+ +
    +
  1. The given repository should be public. If a private repository is used, then the Go server should have access to it. I have mentioned how to configure access for a private repository using the Docker Artifact Store plugin here.
    2. +
  2. All agents that are created after applying the values will be in a pending state. They have to be manually enabled.*
    3. +
+ +

There are many other configuration options available in the values.yaml that can be used to configure the agents. One important example is the security.ssh section that allows us to mount a SSH files using a kubernetes secret. This can be used to allow access to various VCS that use SSH to control access. I’ve explained it in a little more detail in the first post of this series. You can also specify the storage, memory as well as maximum CPU allocation for the agents.

+ +

Elastic Agents:

+ +

We also experimented with elastic agents which is a relatively new feature offered by GoCD. According to the official documentation

+ +

Elastic Agents is an extension-point in GoCD that allows for on-demand agents which are created and provisioned by an elastic-agent plugin when there are jobs to be executed, and terminated when the agents are running idle.

+ +

Elastic Agents have a significant advantage in that they get created when there is a pending job and get destroyed when the job gets completed. This can theoretically result in a lot of cost saving as the agents don’t have to keep on waiting for a job but rather are created only when necessary.

+ +

I can explain a scenario of how using elastic agents can result in cost savings. You can provision a cluster with a single n1-standard-1 VM (3.5GB RAM, 1vCPU) to start with. You can then enable the auto-scaling feature with a reasonable maximum node limit. This will ensure that when no jobs are running all nodes except the first node will be deleted resulting in cost saving compared to have a fixed number of static Go agents.

+ +

GoCD offers a number of plugins that support different Cloud providers like AWS or Azure or different orchestration platforms like DockerSwarm or Kubernetes. Considering that we were trying this out on Kubernetes we used the GoCD Elastic Agent plugin for Kubernetes.

+ +

Elastic Agent Profiles

+ +

Elastic Agent Profiles allows you to configure elastic agents. This configuration allows you to specify the following

+ +
    +
  • Container Image with its tag
    • +
  • Max Memory and CPU
    • +
  • Security Context
    • +
  • Volume Mounts
    • +
  • Environment Variables
    • +
+ +

The configuration can be specified using the UI or by making a cURL request to the API exposed by the Go Server.

+ +

Configuration Using UI

+ +

The UI option can be found under the Elastic Profiles section in the Admin menu of the Go Dashboard. You’ll be able to see a cluster profile called k8-cluster-profile. You can see the existing elastic agent profiles if you expand the section. You’ll find an option to add an Elastic Agent Profile. If you select it, you’ll be able to see a pop-up window with 3 options on how to specify the Agent Pod configuration. You can either

+ +
    +
  • Use the config properties option to add the configuration using the various fields.
    • +
  • Use the Pod Yaml option to specify the pod’s configuration in yaml.
    • +
  • Use the Remote file option to specify the pod’s configuration using an external json or yaml file.
    • +
+ +

Configuration Using API POST Request

+ +

You can also configure an Elastic Agent profile using the API that the GoCD server exposes. You can simply make a POST call using cURL like the following

+ +
curl -vi "[https://$gocd_public_ip/go/api/elastic/profiles](https://$gocd_public_ip/go/api/elastic/profiles)" \
+           -u "$USERNAME:$PASSWORD" \
+           -H 'Accept: application/vnd.go.cd.v2+json' \
+           -H 'Content-Type: application/json' \
+           -X POST -d '{
+        "id": "goagent-1",
+        "plugin_id": "cd.go.contrib.elasticagent.kubernetes",
+        "cluster_profile_id": "k8-cluster-profile",
+        "properties": [
+          {
+            "key": "PodConfiguration",
+            "value": "apiVersion: v1
+kind: Pod
+metadata:
+  name: gocd-agent-{{ POD_POSTFIX }}
+  labels:
+    app: web
+spec:
+  serviceAccountName: default
+  containers:
+    - name: gocd-agent-container-{{ CONTAINER_POSTFIX }}
+      image: <image-name-with-version>
+      volumeMounts:
+      - name: gocd-agent-ssh
+        mountPath: \"/home/go/.ssh\"
+        readOnly: true
+  volumes:
+  - name: gocd-agent-ssh
+    secret:
+      secretName: gocd-agent-ssh"
+          },
+          {
+            "key": "PodSpecType",
+            "value": "yaml"
+          },
+          {
+            "key": "Privileged",
+            "value": "true"
+          }
+        ]
+      }'
+
+ +

As you can see the pod spec has been specified in YAML. You will have to set the variables _$gocd_public_ip , $USERNAME and $PASSWORD with the appropriate values. The username and password should be of a user that has admin privileges to run the above command. If you want to configure using other options, you can use the appropriate keys in the properties array.

+ +

Git Repositories Access Using Git

+ +

If you want the pod to have SSH access to a Git service, you can create a secret with the SSH files and then mount it like shown in the pod spec above. Doing this should give your elastic agents access to your Git repositories.

+ +

So there you go. I hope you find it useful. If you have any questions, please feel free to comment and I’ll answer from whatever I’ve learnt so far.

+ +

This article was originally posted on Mohamed Najiullah's blog

+ + +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09/17/index.html b/pr-1714/2019/09/17/index.html new file mode 100644 index 000000000..29d3a51a8 --- /dev/null +++ b/pr-1714/2019/09/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 17 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/09/index.html b/pr-1714/2019/09/index.html new file mode 100644 index 000000000..2020f7667 --- /dev/null +++ b/pr-1714/2019/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2019/index.html b/pr-1714/2019/index.html new file mode 100644 index 000000000..7d77d8ed7 --- /dev/null +++ b/pr-1714/2019/index.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020.html b/pr-1714/2020.html new file mode 100644 index 000000000..4f7b93531 --- /dev/null +++ b/pr-1714/2020.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04.html b/pr-1714/2020/04.html new file mode 100644 index 000000000..ab3a6b4d8 --- /dev/null +++ b/pr-1714/2020/04.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04/14.html b/pr-1714/2020/04/14.html new file mode 100644 index 000000000..5353e0555 --- /dev/null +++ b/pr-1714/2020/04/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 14 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform.html b/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform.html new file mode 100644 index 000000000..62ff4e70d --- /dev/null +++ b/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform.html @@ -0,0 +1,376 @@ + + + + + + + + + + + + + + + + GoCD on Kubernetes using Terraform + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD on Kubernetes using Terraform +
+ +
+ + +
+

GoCD on Kubernetes using Terraform

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

Have you ever been in a team where you had to setup GoCD server and agents (without Kubernetes)? It could be tiring and some of the +challenges that we face with agents are not limited to continuously monitoring the load of it, agents running idle, clear segregation of +environments and so on. Overall the effort and the cost is enormous.

+ +

Can you think of setting up GoCD as one time effort and that too by maximum one hour? Thanks to Kubernetes and the supporting tools that +made the job easier for us. Let us see how to achieve it.

+ +

We will use Terraform to deploy on Google Kubernetes Engine. The steps should be similar for any other cloud providers.

+ +
+

Note: Version of tools/libraries are subject to change. We have used the latest version as of date.

+
+ +

Create Kubernetes Cluster

+

Create a file with .tf extension.

+ +

Step 1: First part of the file contain the provider.

+ +
provider "google" {
+  credentials = "${file("./<service-account-cred>.json")}"
+  project = "<project-id>"
+  region = "us-east4-a"
+}
+
+ +

Replace ./<service-account-cred>.json to the path where you have the service account key downloaded. Create service account key if you haven't created.

+ +

Replace <project-id> with the project ID.

+ +
+ +

Step 2: Next, we need to provide a VPC network. If not, it defaults to the default VPC network. It is recommended to create our own VPC +network to avoid conflict.

+ +
resource "google_compute_network" "vpc_network" {
+  name = "gocd-vpc-network"
+}
+
+ +
+ +

Step 3. Now we need to create the Kubernetes cluster. It is good practice to avoid using default node pools. We are using custom node pools +and these nodes can auto scale based on the min_node_count and max_node_count.

+ +
resource "google_container_cluster" "ci" {
+  name = "gocd-cluster"
+  network = google_compute_network.vpc_network.name
+  location = "us-east4-a"
+  initial_node_count = 1
+  remove_default_node_pool = true
+  depends_on = [
+    "google_compute_network.vpc_network"]
+}
+
+resource "google_container_node_pool" "ci_nodes" {
+  name = "gocd-node-pool"
+  location = "us-east4-a"
+  cluster = google_container_cluster.ci.name
+
+  node_config {
+    machine_type = "n1-standard-2"
+  }
+
+  autoscaling {
+    min_node_count = 3
+    max_node_count = 5
+  }
+  depends_on = [
+    "google_container_cluster.ci"]
+}
+
+ +
+ +

Step 4: It is time to deploy our Terraform script. To run Terraform script for the first time, You need to install +Terraform in a local machine and run the scripts below.

+ +
terraform init
+
+ +
terraform plan
+
+ +
terraform apply
+
+ +

It will take some time to create the cluster. You can view the created cluster at https://console.cloud.google.com/kubernetes/list.

+ +

Setup GoCD

+ +

Our Kubernetes cluster is ready. Now, we will be using Helm chart to setup GoCD. For helm and kubernetes to interact with the cluster, we need to configure the Terraform provider.

+ +

Mention the latest Terraform provider helm version.

+ +
data "google_client_config" "current" {}
+
+provider "helm" {
+  version = "v1.1.1"
+  kubernetes {
+    load_config_file = false
+    host = "${google_container_cluster.ci.endpoint}"
+    token = "${data.google_client_config.current.access_token}"
+    client_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.client_certificate)}"
+    client_key = "${base64decode(google_container_cluster.ci.master_auth.0.client_key)}"
+    cluster_ca_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.cluster_ca_certificate)}"
+  }
+}
+
+provider "kubernetes" {
+  load_config_file = false
+  host = "${google_container_cluster.ci.endpoint}"
+  token = "${data.google_client_config.current.access_token}"
+  client_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.client_certificate)}"
+  client_key = "${base64decode(google_container_cluster.ci.master_auth.0.client_key)}"
+  cluster_ca_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.cluster_ca_certificate)}"
+}
+
+ +

Create a namespace (say gocd) to install helm in the gocd namespace.

+ +
resource "kubernetes_namespace" "gocd_namespace" {
+  metadata {
+    name = "gocd"
+  }
+  depends_on = [google_container_node_pool.ci_nodes]
+}
+
+ +
resource "helm_release" "gocd" {
+  name = "gocd"
+  chart = "gocd/gocd"
+  namespace = kubernetes_namespace.gocd_namespace.metadata.0.name
+  depends_on = [kubernetes_namespace.gocd_namespace]
+}
+
+

Download the plugins for provider helm and kubernetes. Apply the changes.

+ +
terraform init
+
+ +
terraform apply
+
+ +

Verification

+ +

Locally you should have gcloud and kubectl to verify.

+ +

Step 1: Use gcloud to authenticate with the cluster. https://console.cloud.google.com/kubernetes/list -> connect - will give the command to connect to the cluster. Execute it.

+ +
+ +

Step 2: You can see the state of GoCD server by running:

+ +
kubectl get pods -n gocd
+
+ +
+ +

Step 3: GoCD is still not exposed to public. You can port forward to get to the UI.

+ +
kubectl port-forward svc/gocd-server 8153:8153 -n gocd
+
+ +

After running the above command, you can view the GoCD UI at https://localhost:8153.

+ +

We have successfully deployed GoCD on Google Kubernetes Engine.

+ +
+ +

Credits to Selvakumar Natesan for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog. A blog series which details the setup of Let's Encrypt and Github OAuth with GoCD can be found there as well.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform/index.html b/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform/index.html new file mode 100644 index 000000000..70a1a8a81 --- /dev/null +++ b/pr-1714/2020/04/14/gocd-on-kubernetes-using-terraform/index.html @@ -0,0 +1,376 @@ + + + + + + + + + + + + + + + + GoCD on Kubernetes using Terraform + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ GoCD on Kubernetes using Terraform +
+ +
+ + +
+

GoCD on Kubernetes using Terraform

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

Have you ever been in a team where you had to setup GoCD server and agents (without Kubernetes)? It could be tiring and some of the +challenges that we face with agents are not limited to continuously monitoring the load of it, agents running idle, clear segregation of +environments and so on. Overall the effort and the cost is enormous.

+ +

Can you think of setting up GoCD as one time effort and that too by maximum one hour? Thanks to Kubernetes and the supporting tools that +made the job easier for us. Let us see how to achieve it.

+ +

We will use Terraform to deploy on Google Kubernetes Engine. The steps should be similar for any other cloud providers.

+ +
+

Note: Version of tools/libraries are subject to change. We have used the latest version as of date.

+
+ +

Create Kubernetes Cluster

+

Create a file with .tf extension.

+ +

Step 1: First part of the file contain the provider.

+ +
provider "google" {
+  credentials = "${file("./<service-account-cred>.json")}"
+  project = "<project-id>"
+  region = "us-east4-a"
+}
+
+ +

Replace ./<service-account-cred>.json to the path where you have the service account key downloaded. Create service account key if you haven't created.

+ +

Replace <project-id> with the project ID.

+ +
+ +

Step 2: Next, we need to provide a VPC network. If not, it defaults to the default VPC network. It is recommended to create our own VPC +network to avoid conflict.

+ +
resource "google_compute_network" "vpc_network" {
+  name = "gocd-vpc-network"
+}
+
+ +
+ +

Step 3. Now we need to create the Kubernetes cluster. It is good practice to avoid using default node pools. We are using custom node pools +and these nodes can auto scale based on the min_node_count and max_node_count.

+ +
resource "google_container_cluster" "ci" {
+  name = "gocd-cluster"
+  network = google_compute_network.vpc_network.name
+  location = "us-east4-a"
+  initial_node_count = 1
+  remove_default_node_pool = true
+  depends_on = [
+    "google_compute_network.vpc_network"]
+}
+
+resource "google_container_node_pool" "ci_nodes" {
+  name = "gocd-node-pool"
+  location = "us-east4-a"
+  cluster = google_container_cluster.ci.name
+
+  node_config {
+    machine_type = "n1-standard-2"
+  }
+
+  autoscaling {
+    min_node_count = 3
+    max_node_count = 5
+  }
+  depends_on = [
+    "google_container_cluster.ci"]
+}
+
+ +
+ +

Step 4: It is time to deploy our Terraform script. To run Terraform script for the first time, You need to install +Terraform in a local machine and run the scripts below.

+ +
terraform init
+
+ +
terraform plan
+
+ +
terraform apply
+
+ +

It will take some time to create the cluster. You can view the created cluster at https://console.cloud.google.com/kubernetes/list.

+ +

Setup GoCD

+ +

Our Kubernetes cluster is ready. Now, we will be using Helm chart to setup GoCD. For helm and kubernetes to interact with the cluster, we need to configure the Terraform provider.

+ +

Mention the latest Terraform provider helm version.

+ +
data "google_client_config" "current" {}
+
+provider "helm" {
+  version = "v1.1.1"
+  kubernetes {
+    load_config_file = false
+    host = "${google_container_cluster.ci.endpoint}"
+    token = "${data.google_client_config.current.access_token}"
+    client_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.client_certificate)}"
+    client_key = "${base64decode(google_container_cluster.ci.master_auth.0.client_key)}"
+    cluster_ca_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.cluster_ca_certificate)}"
+  }
+}
+
+provider "kubernetes" {
+  load_config_file = false
+  host = "${google_container_cluster.ci.endpoint}"
+  token = "${data.google_client_config.current.access_token}"
+  client_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.client_certificate)}"
+  client_key = "${base64decode(google_container_cluster.ci.master_auth.0.client_key)}"
+  cluster_ca_certificate = "${base64decode(google_container_cluster.ci.master_auth.0.cluster_ca_certificate)}"
+}
+
+ +

Create a namespace (say gocd) to install helm in the gocd namespace.

+ +
resource "kubernetes_namespace" "gocd_namespace" {
+  metadata {
+    name = "gocd"
+  }
+  depends_on = [google_container_node_pool.ci_nodes]
+}
+
+ +
resource "helm_release" "gocd" {
+  name = "gocd"
+  chart = "gocd/gocd"
+  namespace = kubernetes_namespace.gocd_namespace.metadata.0.name
+  depends_on = [kubernetes_namespace.gocd_namespace]
+}
+
+

Download the plugins for provider helm and kubernetes. Apply the changes.

+ +
terraform init
+
+ +
terraform apply
+
+ +

Verification

+ +

Locally you should have gcloud and kubectl to verify.

+ +

Step 1: Use gcloud to authenticate with the cluster. https://console.cloud.google.com/kubernetes/list -> connect - will give the command to connect to the cluster. Execute it.

+ +
+ +

Step 2: You can see the state of GoCD server by running:

+ +
kubectl get pods -n gocd
+
+ +
+ +

Step 3: GoCD is still not exposed to public. You can port forward to get to the UI.

+ +
kubectl port-forward svc/gocd-server 8153:8153 -n gocd
+
+ +

After running the above command, you can view the GoCD UI at https://localhost:8153.

+ +

We have successfully deployed GoCD on Google Kubernetes Engine.

+ +
+ +

Credits to Selvakumar Natesan for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog. A blog series which details the setup of Let's Encrypt and Github OAuth with GoCD can be found there as well.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04/14/index.html b/pr-1714/2020/04/14/index.html new file mode 100644 index 000000000..738e6d1fa --- /dev/null +++ b/pr-1714/2020/04/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 14 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/04/index.html b/pr-1714/2020/04/index.html new file mode 100644 index 000000000..c21038394 --- /dev/null +++ b/pr-1714/2020/04/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10.html b/pr-1714/2020/10.html new file mode 100644 index 000000000..5f1950dd2 --- /dev/null +++ b/pr-1714/2020/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11.html b/pr-1714/2020/10/11.html new file mode 100644 index 000000000..09ecbcd5a --- /dev/null +++ b/pr-1714/2020/10/11.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 11 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11/index.html b/pr-1714/2020/10/11/index.html new file mode 100644 index 000000000..cc5521a98 --- /dev/null +++ b/pr-1714/2020/10/11/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 11 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes.html b/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes.html new file mode 100644 index 000000000..93eb32cd7 --- /dev/null +++ b/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + Perform Backup for GoCD on Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Perform Backup for GoCD on Kubernetes +
+ +
+ + +
+

Perform Backup for GoCD on Kubernetes

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

Backup is essential as it helps to restore the setup. Possibility of crash or mistake are high and we need to prepare ourselves for the worst case. Backup can give life to the devs. Let's see the ways to backup GoCD when running on Kubernetes.

+ +

If you are attempting to restore backup, please refer to Restore Backup for GoCD on Kubernetes.

+ +

Backup can be performed manually or we can configure automated backup. It is a good practice to configure automated backup and we have to aim for it. Below are the detailed steps for both manual and automated backup.

+ +

Manual Backup:

+ +

Step 1: Enable Maintenance Mode - Navigate to Admin -> Server Maintenance Mode and toggle on Enable Maintenance Mode.

+ +
+ +

Step 2: Navigate to Admin -> Backup and click Perform Backup. Once the backup is complete, we will be able to see the backup folder in /go-working-dir/artifacts/serverBackups. Take a copy and store it in a safe place. You could use the command kubectl cp ... to achieve it.

+ +
+ +

Step 3: Toggle of Maintenance Mode.

+ +

Automated Backup:

+ +

We shall walk through the steps to backup and push into Google Storage Bucket. Steps should be similar if we use any other cloud providers whereas tools can differ.

+ +

Step 1: Navigate to Admin -> Backup -> Configure backup settings. Where we can provide Backup Schedule to something like 0 0 0 ? * 3 *(Every week backup).

+ +
+ +

Step 2: Provide path to our sh script in Post backup script. In our case it is /home/go/backup.sh. Here, backup.sh contains the script file.

+ +
+ +

Step 3: Generate Personal Access Token to Enable Maintenance Mode via API. Token can be generated as mentioned in Access Token. Keep it safe as we need it in the step 7. Moreover, this step is recommended but not mandatory because generation of token depends on the authentication plugin we have leveraged. In our case we were using okta plugin where token generation was not supported. Certainly it is a good practice to make sure that we do not have any running subsystems that would be interrupted during backup.

+ +
+ +

Step 4: Now, we had to create backup.sh file in the GoCD server. Exec into the GoCD server pod by using command:

+ +
kubectl exec <pod_name> -it sh -n <namespace_name>
+
+ +
+ +

Step 5: Navigate to /home/go and install Google Cloud SDK.

+ +
+ +

Step 6: Create a service account with relevant permission and use that service account to login. We can copy the service account from local to pod using the kubectl cp ..... and then authenticate gcloud using the command

+ +
/home/go/google-cloud-sdk/gcloud auth activate-service-account --key-file=<service-account-file>.json
+
+ +
+ +

Step 7: Create a file called backup.sh in path /home/go and paste the below script:

+ +
curl 'https://<gocd-domain>/go/api/admin/maintenance_mode/enable' -X POST -H 'Authorization: Bearer <personal-access-token>' -H 'X-GoCD-Confirm:true' -H 'Accept: application/vnd.go.cd.v1+json'
+/home/go/google-cloud-sdk/bin/gsutil cp -R $GOCD_BACKUP_PATH gs://<bucket-name>
+rm -R $GOCD_BACKUP_PATH
+curl 'https://<gocd-domain>/go/api/admin/maintenance_mode/disable' -X POST -H 'Authorization: Bearer <personal-access-token>' -H 'X-GoCD-Confirm:true' -H 'Accept: application/vnd.go.cd.v1+json'
+Replace <bucket-name> with the bucket you have created in GCP
+
+ +

Replace <bucket-name> with the bucket you have created in GCP. Replace <gocd-domain> with your domain name. Replace <personal-access-token> with the access token we have created in step 3.

+ +

The above script will get called whenever automated backup kicks in and does the below execution in order.

+ +
    +
  1. Enable Maintenance mode.
    2. +
  2. Push the backup to the Google Storage Bucket.
    3. +
  3. Remove the backup folder so it does not accumulate and use the storage space of the pod.
    4. +
  4. Disable Maintenance mode.
    5. +
+ +
+

If you were not able to generate Personal Access Token as mentioned in step 4, remove the first and the last script.

+
+ +

Now we have configured the automation and it is time to sit relax without reminding ourselves to backup each time.

+ +

Further Thoughts:

+ +

Remember if PVC(Persistence Volume Claim) is deleted, we might loose all the data and even the backup script. We might have to do all the automation setup again, so to not lose we could create a Docker image from the GoCD server base image and that would help to avoid do any of the steps mentioned above when PVC is deleted.

+ +
+ +

Credits to Ganesh Patil and Kritika Singh for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes/index.html b/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes/index.html new file mode 100644 index 000000000..538f6508f --- /dev/null +++ b/pr-1714/2020/10/11/perform-backup-for-gocd-on-kubernetes/index.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + + + + + Perform Backup for GoCD on Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Perform Backup for GoCD on Kubernetes +
+ +
+ + +
+

Perform Backup for GoCD on Kubernetes

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

Backup is essential as it helps to restore the setup. Possibility of crash or mistake are high and we need to prepare ourselves for the worst case. Backup can give life to the devs. Let's see the ways to backup GoCD when running on Kubernetes.

+ +

If you are attempting to restore backup, please refer to Restore Backup for GoCD on Kubernetes.

+ +

Backup can be performed manually or we can configure automated backup. It is a good practice to configure automated backup and we have to aim for it. Below are the detailed steps for both manual and automated backup.

+ +

Manual Backup:

+ +

Step 1: Enable Maintenance Mode - Navigate to Admin -> Server Maintenance Mode and toggle on Enable Maintenance Mode.

+ +
+ +

Step 2: Navigate to Admin -> Backup and click Perform Backup. Once the backup is complete, we will be able to see the backup folder in /go-working-dir/artifacts/serverBackups. Take a copy and store it in a safe place. You could use the command kubectl cp ... to achieve it.

+ +
+ +

Step 3: Toggle of Maintenance Mode.

+ +

Automated Backup:

+ +

We shall walk through the steps to backup and push into Google Storage Bucket. Steps should be similar if we use any other cloud providers whereas tools can differ.

+ +

Step 1: Navigate to Admin -> Backup -> Configure backup settings. Where we can provide Backup Schedule to something like 0 0 0 ? * 3 *(Every week backup).

+ +
+ +

Step 2: Provide path to our sh script in Post backup script. In our case it is /home/go/backup.sh. Here, backup.sh contains the script file.

+ +
+ +

Step 3: Generate Personal Access Token to Enable Maintenance Mode via API. Token can be generated as mentioned in Access Token. Keep it safe as we need it in the step 7. Moreover, this step is recommended but not mandatory because generation of token depends on the authentication plugin we have leveraged. In our case we were using okta plugin where token generation was not supported. Certainly it is a good practice to make sure that we do not have any running subsystems that would be interrupted during backup.

+ +
+ +

Step 4: Now, we had to create backup.sh file in the GoCD server. Exec into the GoCD server pod by using command:

+ +
kubectl exec <pod_name> -it sh -n <namespace_name>
+
+ +
+ +

Step 5: Navigate to /home/go and install Google Cloud SDK.

+ +
+ +

Step 6: Create a service account with relevant permission and use that service account to login. We can copy the service account from local to pod using the kubectl cp ..... and then authenticate gcloud using the command

+ +
/home/go/google-cloud-sdk/gcloud auth activate-service-account --key-file=<service-account-file>.json
+
+ +
+ +

Step 7: Create a file called backup.sh in path /home/go and paste the below script:

+ +
curl 'https://<gocd-domain>/go/api/admin/maintenance_mode/enable' -X POST -H 'Authorization: Bearer <personal-access-token>' -H 'X-GoCD-Confirm:true' -H 'Accept: application/vnd.go.cd.v1+json'
+/home/go/google-cloud-sdk/bin/gsutil cp -R $GOCD_BACKUP_PATH gs://<bucket-name>
+rm -R $GOCD_BACKUP_PATH
+curl 'https://<gocd-domain>/go/api/admin/maintenance_mode/disable' -X POST -H 'Authorization: Bearer <personal-access-token>' -H 'X-GoCD-Confirm:true' -H 'Accept: application/vnd.go.cd.v1+json'
+Replace <bucket-name> with the bucket you have created in GCP
+
+ +

Replace <bucket-name> with the bucket you have created in GCP. Replace <gocd-domain> with your domain name. Replace <personal-access-token> with the access token we have created in step 3.

+ +

The above script will get called whenever automated backup kicks in and does the below execution in order.

+ +
    +
  1. Enable Maintenance mode.
    2. +
  2. Push the backup to the Google Storage Bucket.
    3. +
  3. Remove the backup folder so it does not accumulate and use the storage space of the pod.
    4. +
  4. Disable Maintenance mode.
    5. +
+ +
+

If you were not able to generate Personal Access Token as mentioned in step 4, remove the first and the last script.

+
+ +

Now we have configured the automation and it is time to sit relax without reminding ourselves to backup each time.

+ +

Further Thoughts:

+ +

Remember if PVC(Persistence Volume Claim) is deleted, we might loose all the data and even the backup script. We might have to do all the automation setup again, so to not lose we could create a Docker image from the GoCD server base image and that would help to avoid do any of the steps mentioned above when PVC is deleted.

+ +
+ +

Credits to Ganesh Patil and Kritika Singh for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes.html b/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes.html new file mode 100644 index 000000000..2412792e3 --- /dev/null +++ b/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes.html @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + Restore Backup for GoCD on Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Restore Backup for GoCD on Kubernetes +
+ +
+ + +
+

Restore Backup for GoCD on Kubernetes

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

We must have backup zip before attempting to restore. Or else make sure to download and have the backup zip in local. So, how to Backup? Refer to Perform Backup for GoCD on Kubernetes.

+ +

The steps to restore backup are similar as mentioned in Backup GoCD Server.

+ +

But some complications arise when performing the same when GoCD is running on kubernetes, it is because of the latest release that incorporated additional security layer to run as non root user in GoCD server. Because of this it is not possible to directly exec into GoCD server pod and change the files.

+ +
+ +

When GoCD server pod is running in kubernetes, it gets attached with one PVC(Persistence Volume Claim). This PVC cannot be attached to multiple pod. In our case, GoCD server pod is already attached with a PVC, we need to follow below steps to restore the backup:

+ +
    +
  1. Detach PVC from server pod.
    2. +
  2. Introduce another temporary pod that can attach to the same PVC.
    3. +
  3. Restore the files from the backup.
    4. +
  4. Finally reverse the process, by detaching temporary pod and hooking it to the GoCD server pod.
    5. +
+ +

Let's walk through each step with commands to achieve the above steps.

+ +

Step 1: Detach PVC from server pod

+ +

Stop the running GoCD server to disconnect from the PV by using one of the following approaches:

+ +
    +
  1. Uninstall GoCD helm release from the cluster.
    2. +
  2. Stop the GoCD server pod using helm-stop plugin.
    3. +
+ +
+ +

Step 2: Introduce another temporary pod that can attach to the same PVC

+ +

Get the name of the pvc.

+ +
kubectl get pvc -n gocd
+
+ +

Now, create a file by name gocd-backup.yaml and paste the below Pod configuration.

+ +
apiVersion: v1
+kind: Pod
+metadata:
+  name: connect-to-gocd-pv-pod
+  namespace: gocd
+spec:
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: <pvc-name>
+  containers:
+    - name: task-pv-container
+      image: nginxinc/nginx-unprivileged
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/godata"
+          name: task-pv-storage
+      securityContext:
+        runAsUser: 1000
+
+ +

Rename <pvc-name> with the pvc name that we got previously.

+ +

Apply gocd-backup.yaml by running:

+ +
kubectl create -f gocd-backup.yaml -n gocd
+
+ +
+ +

Step 3: Restore the files from the backup

+ +

The pvc that was existing should have attached to this temporary pod. Exec into this pod, copy the backup files from local using kubectl cp ....., then place them into respective folders as mentioned in Backup GoCD Server.

+ +
+ +

Step 4: Finally reverse the process, by detaching temporary pod and hooking in server pod

+ +

It is time to drop the temporary pod and install the GoCD helm again. When running GoCD server pod, you should observe that the pvc we modified gets attached to the GoCD server pod. We can check this by describing the pod.

+ +
kubectl describe <pod-name> -n gocd
+
+ +

We have successfully restored the backup. Great work.

+ +
+ +

Credits to Ganesh Patil and Kritika Singh for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes/index.html b/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes/index.html new file mode 100644 index 000000000..6d0b9088b --- /dev/null +++ b/pr-1714/2020/10/11/restore-backup-for-gocd-on-kubernetes/index.html @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + Restore Backup for GoCD on Kubernetes + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ +
+
+ Restore Backup for GoCD on Kubernetes +
+ +
+ + +
+

Restore Backup for GoCD on Kubernetes

+

Guest post by Abilash Rajasekaran

+

+

+
+ +
+ +

We must have backup zip before attempting to restore. Or else make sure to download and have the backup zip in local. So, how to Backup? Refer to Perform Backup for GoCD on Kubernetes.

+ +

The steps to restore backup are similar as mentioned in Backup GoCD Server.

+ +

But some complications arise when performing the same when GoCD is running on kubernetes, it is because of the latest release that incorporated additional security layer to run as non root user in GoCD server. Because of this it is not possible to directly exec into GoCD server pod and change the files.

+ +
+ +

When GoCD server pod is running in kubernetes, it gets attached with one PVC(Persistence Volume Claim). This PVC cannot be attached to multiple pod. In our case, GoCD server pod is already attached with a PVC, we need to follow below steps to restore the backup:

+ +
    +
  1. Detach PVC from server pod.
    2. +
  2. Introduce another temporary pod that can attach to the same PVC.
    3. +
  3. Restore the files from the backup.
    4. +
  4. Finally reverse the process, by detaching temporary pod and hooking it to the GoCD server pod.
    5. +
+ +

Let's walk through each step with commands to achieve the above steps.

+ +

Step 1: Detach PVC from server pod

+ +

Stop the running GoCD server to disconnect from the PV by using one of the following approaches:

+ +
    +
  1. Uninstall GoCD helm release from the cluster.
    2. +
  2. Stop the GoCD server pod using helm-stop plugin.
    3. +
+ +
+ +

Step 2: Introduce another temporary pod that can attach to the same PVC

+ +

Get the name of the pvc.

+ +
kubectl get pvc -n gocd
+
+ +

Now, create a file by name gocd-backup.yaml and paste the below Pod configuration.

+ +
apiVersion: v1
+kind: Pod
+metadata:
+  name: connect-to-gocd-pv-pod
+  namespace: gocd
+spec:
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: <pvc-name>
+  containers:
+    - name: task-pv-container
+      image: nginxinc/nginx-unprivileged
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/godata"
+          name: task-pv-storage
+      securityContext:
+        runAsUser: 1000
+
+ +

Rename <pvc-name> with the pvc name that we got previously.

+ +

Apply gocd-backup.yaml by running:

+ +
kubectl create -f gocd-backup.yaml -n gocd
+
+ +
+ +

Step 3: Restore the files from the backup

+ +

The pvc that was existing should have attached to this temporary pod. Exec into this pod, copy the backup files from local using kubectl cp ....., then place them into respective folders as mentioned in Backup GoCD Server.

+ +
+ +

Step 4: Finally reverse the process, by detaching temporary pod and hooking in server pod

+ +

It is time to drop the temporary pod and install the GoCD helm again. When running GoCD server pod, you should observe that the pvc we modified gets attached to the GoCD server pod. We can check this by describing the pod.

+ +
kubectl describe <pod-name> -n gocd
+
+ +

We have successfully restored the backup. Great work.

+ +
+ +

Credits to Ganesh Patil and Kritika Singh for directions.

+ +

This post was originally published on Abilash Rajasekaran's blog.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/10/index.html b/pr-1714/2020/10/index.html new file mode 100644 index 000000000..899cad803 --- /dev/null +++ b/pr-1714/2020/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2020/index.html b/pr-1714/2020/index.html new file mode 100644 index 000000000..83be2d186 --- /dev/null +++ b/pr-1714/2020/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021.html b/pr-1714/2021.html new file mode 100644 index 000000000..c3b83cb45 --- /dev/null +++ b/pr-1714/2021.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12.html b/pr-1714/2021/12.html new file mode 100644 index 000000000..50ba8f7c3 --- /dev/null +++ b/pr-1714/2021/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12/14.html b/pr-1714/2021/12/14.html new file mode 100644 index 000000000..7fc905b67 --- /dev/null +++ b/pr-1714/2021/12/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 14 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12/14/index.html b/pr-1714/2021/12/14/index.html new file mode 100644 index 000000000..6ef0e16bb --- /dev/null +++ b/pr-1714/2021/12/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 14 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12/14/log4j-vulnerability.html b/pr-1714/2021/12/14/log4j-vulnerability.html new file mode 100644 index 000000000..ef36edeb9 --- /dev/null +++ b/pr-1714/2021/12/14/log4j-vulnerability.html @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + + GoCD and the Log4j vulnerability - CVE-2021-44228 + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD and the Log4j vulnerability - CVE-2021-44228

+

Aravind SV

+

+

+
+ +
+

Please see this GitHub Discussion for the latest information regarding whether GoCD is vulnerable to CVE-2021-44228.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12/14/log4j-vulnerability/index.html b/pr-1714/2021/12/14/log4j-vulnerability/index.html new file mode 100644 index 000000000..22530e9ec --- /dev/null +++ b/pr-1714/2021/12/14/log4j-vulnerability/index.html @@ -0,0 +1,198 @@ + + + + + + + + + + + + + + + + GoCD and the Log4j vulnerability - CVE-2021-44228 + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD and the Log4j vulnerability - CVE-2021-44228

+

Aravind SV

+

+

+
+ +
+

Please see this GitHub Discussion for the latest information regarding whether GoCD is vulnerable to CVE-2021-44228.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/12/index.html b/pr-1714/2021/12/index.html new file mode 100644 index 000000000..765dac426 --- /dev/null +++ b/pr-1714/2021/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2021/index.html b/pr-1714/2021/index.html new file mode 100644 index 000000000..882b76bc2 --- /dev/null +++ b/pr-1714/2021/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023.html b/pr-1714/2023.html new file mode 100644 index 000000000..f7af8a118 --- /dev/null +++ b/pr-1714/2023.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02.html b/pr-1714/2023/02.html new file mode 100644 index 000000000..a2427f6e0 --- /dev/null +++ b/pr-1714/2023/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02/13.html b/pr-1714/2023/02/13.html new file mode 100644 index 000000000..ebc1781fb --- /dev/null +++ b/pr-1714/2023/02/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02/13/gocd-project-status.html b/pr-1714/2023/02/13/gocd-project-status.html new file mode 100644 index 000000000..d8fd2fed0 --- /dev/null +++ b/pr-1714/2023/02/13/gocd-project-status.html @@ -0,0 +1,353 @@ + + + + + + + + + + + + + + + + GoCD project status in 2023 + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD project status in 2023

+

Chad Wilson & Aravind SV

+

+

+
+ +
+

A couple of years have passed since Thoughtworks-funded development on GoCD ended. A number of folks have asked about +GoCD's general project, maintenance, development and support status - along with some speculation. While some of this +has been discussed in the GoCD forums over time, we thought it might help to add +some clarity for users here.

+ +

We hope for this to give a fair summary of the current state so you can make the best choice for you or your organization.

+ +

The following represents the opinions solely of the writers (Chad Wilson & +Aravind SV) in their personal capacity contributing to GoCD maintenance, and not an official position +of Thoughtworks.

+ +

TL;DR

+ +

As of early 2023, GoCD has a very small open-source maintainer group who are still driving a limited amount of bug fixes, +minor enhancements, periodic releases and otherwise supporting the wider community.

+ +

Since January 2021, GoCD has had no organizational backing behind development, nor a commercial/enterprise support offering.

+ +

Background

+ +

Here's a brief history of how we got here:

+ +
    +
  • 2007: GoCD was originally developed as a commercial, closed-sourced product named Cruise by Thoughtworks Studios, +as an evolution of CruiseControl, the first continuous integration server. +In contrast to CruiseControl, GoCD's design instead focused on supporting continuous delivery with complex workflows, +rather than purely supporting the build automation at the core of continuous integration practices.
    • +
  • 2010: Cruise was renamed to Go. (later slightly adjusted to GoCD to disambiguate from the increasingly popular golang language)
    • +
  • 2011: The Go Community Edition is made license-free, easing use for folks in many settings.
    • +
  • 2014: GoCD was open-sourced, with certain features (including +support) remaining commercial closed source features requiring licensing from Thoughtworks.
    • +
  • November 2019: Thoughtworks announces the plans for full transfer of GoCD to the community +and end of the commercial support offering.
    • +
  • May 2020: Previously commercial features/plugins are all open-sourced or capability directly incorporated into GoCD by the GoCD Core Team.
    • +
  • December 2020: Commercial support for GoCD ends, as does Thoughtworks-funded development and maintenance of GoCD.
    • +
+ +

How is GoCD currently being maintained?

+ +

As of February 2023, maintainer access to GoCD currently sits with a handful of folks that are either current or ex-Thoughtworks employees, +including some of those originally part of the GoCD core team within Thoughtworks Studios. In practice, active +contributions are coming from a much more limited set of folks - solely within their free time.

+ +

This very small contributor team has completed 3-4 relatively minor releases per year throughout 2021 and 2022, +mainly focused around security-related updates, bug fixes and minor enhancements.

+ +

Does Thoughtworks continue to sponsor GoCD?

+ +

For now, Thoughtworks still graciously provides funding for the website & build infrastructure of GoCD, along with +code signing certificates, and a single commercially licensed component required for Windows support. This is +done on a goodwill basis, and there is no official agreement with or promise to the community regarding this support.

+ +

Does GoCD have active ongoing feature development?

+ +

At time of writing, there is no dedicated team actively contributing to GoCD feature development or major enhancements. +There is also no ongoing funding behind open source contributions to GoCD, and GoCD has a very small contributor community.

+ +

In the current state, this makes it unlikely that GoCD will receive major enhancements or changes in the foreseeable +future, unless there is a large further increase in contributions by users, organizations or other members of the community.

+ +

Is GoCD end-of-life? Abandoned? Should GoCD be considered deprecated?

+ +

GoCD is neither officially end-of-life, nor fully abandoned - but it's fair to say that its development is not thriving +either.

+ +

As to deprecation, generally this is a decision that you should make within your specific context. If GoCD meets your +particular needs and functions as you would like in your environment with its current feature set and user experience, +and the risks are acceptable to you, you should feel free to continue to use it - as with any free & open source software.

+ +

What happened to moving GoCD to an open source foundation?

+ +

There was an attempt to move GoCD over to an open source foundation. Based on initial +conversations, the Linux Foundation and the Apache Software Foundation were interested and would likely have accepted GoCD. +However, that effort is currently dormant. We realized that given the small contributor base, the move to a foundation +would not change the situation significantly. The potential challenge around funding the build and release infrastructure +would remain. The legal effort to make that change would have not been in line with the value of that change. That effort +could be restarted at a later time.

+ +

Is it risky to continue to use GoCD from a security standpoint?

+ +

Maybe? That depends on your assessment of risk. The security policy +has some important caveats, but a balanced assessment of risk for open source software generally includes assessment of +the vibrancy of the software's community.

+ +

Here are some additional aspects to consider:

+ +

The "good" news:

+ +
    +
  • We believe GoCD was built with solid security principles in mind that have generally stood the test of time.
    • +
  • Software dependencies incorporated within GoCD are generally still under active development, and thus being +patched/updated. These are being incorporated into new GoCD releases without major issue.
    • +
  • GoCD runs on and is built/test using modern, maintained language runtimes (Java 17 LTS, NodeJS 20 LTS, Ruby 3.1)
    • +
  • GoCD continues to have good compatibility with latest operating systems, which can be extended to its supported +Docker images.
    • +
+ +

The "neutral" news:

+ +
    +
  • With GoCD, we do not maintain/patch old releases of GoCD. +In general, GoCD has always maintained robust backwards compatibility and sign-posted removals/deprecations in advance +with an expectation that folks will move forward to the latest release.
    • +
+ +

The "not-so-good" news:

+ +
    +
  • GoCD has a significant number of plugins, many different supported operating systems, many Docker image variants, a number +of languages used across the codebase and many different features that make it difficult for a small team to support. +Keeping on top of all of these requires non-trivial effort, and is likely not indefinitely sustainable with the current +contributor/maintainer community size.
    • +
  • +

    At time of writing (updated: December 2023), GoCD does depend on some libraries/frameworks which require significant effort to upgrade, but are +end-of-life, and thus present some level of ongoing risk. If a major vulnerability is discovered in these libraries/frameworks +that affects GoCD it will either require an urgent upgrade, or forking and patching of those libraries/frameworks. The +community is not well placed to manage this kind of development. To help you assess risk, at time of writing, they include (but may not be limited to)

    + +
      +
    • Spring Framework 4.3 (EOL December 2020)
      • +
    • Spring Security 4.2 (EOL October 2020)
      • +
    • Hibernate ORM 3.6 (EOL February 2012)
      • +
    • A small part of the UI relies on +
        +
      • AngularJS 1.0 - plugin view templating support (EOL November 2013)
        • +
      • jQuery 1.7 - stage and build/job detail views (subsequent upgraded in GoCD 23.4.0)
        • +
      • PrototypeJS 1.6 - stage and build/job detail views (subsequently replaced with jQuery in GoCD 23.5.0)
        • +
      +
      • +
    +
    • +
+ +

How can my organization or myself help with maintenance of GoCD?

+ +

You can learn how to contribute here and check out the resources available for getting started.

+ +

Should I migrate away from GoCD?

+ +

Paraphrasing from the original announcement – +you should assess your needs and select the best tool for you. GoCD will be available as an open source project for use in the future. +Thoughtworks and the GoCD maintainers will not be providing alternative tools recommendations or migration support. +Different tools in this space offer different levels of modeling capabilities and features.

+ +

What's the best way to migrate away from GoCD?

+ +

GoCD has a reasonably comprehensive set of APIs you can use to export pipeline configuration as a starting point for +partially automated migration. If you don't use pipelines as code techniques, +you might want to start with using the APIs to get all pipeline groups +and then get pipeline config for each pipeline for conversion to your +target tool.

+ +

GoCD is great! But this doesn't seem like a great situation?

+ +

We think GoCD is great too. And we agree the maintenance situation is not great either. Come encourage us and help us out on the +forums, or GitHub.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02/13/gocd-project-status/index.html b/pr-1714/2023/02/13/gocd-project-status/index.html new file mode 100644 index 000000000..2f4ab2603 --- /dev/null +++ b/pr-1714/2023/02/13/gocd-project-status/index.html @@ -0,0 +1,353 @@ + + + + + + + + + + + + + + + + GoCD project status in 2023 + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ + + + + + +
+
+ + + +
+

GoCD project status in 2023

+

Chad Wilson & Aravind SV

+

+

+
+ +
+

A couple of years have passed since Thoughtworks-funded development on GoCD ended. A number of folks have asked about +GoCD's general project, maintenance, development and support status - along with some speculation. While some of this +has been discussed in the GoCD forums over time, we thought it might help to add +some clarity for users here.

+ +

We hope for this to give a fair summary of the current state so you can make the best choice for you or your organization.

+ +

The following represents the opinions solely of the writers (Chad Wilson & +Aravind SV) in their personal capacity contributing to GoCD maintenance, and not an official position +of Thoughtworks.

+ +

TL;DR

+ +

As of early 2023, GoCD has a very small open-source maintainer group who are still driving a limited amount of bug fixes, +minor enhancements, periodic releases and otherwise supporting the wider community.

+ +

Since January 2021, GoCD has had no organizational backing behind development, nor a commercial/enterprise support offering.

+ +

Background

+ +

Here's a brief history of how we got here:

+ +
    +
  • 2007: GoCD was originally developed as a commercial, closed-sourced product named Cruise by Thoughtworks Studios, +as an evolution of CruiseControl, the first continuous integration server. +In contrast to CruiseControl, GoCD's design instead focused on supporting continuous delivery with complex workflows, +rather than purely supporting the build automation at the core of continuous integration practices.
    • +
  • 2010: Cruise was renamed to Go. (later slightly adjusted to GoCD to disambiguate from the increasingly popular golang language)
    • +
  • 2011: The Go Community Edition is made license-free, easing use for folks in many settings.
    • +
  • 2014: GoCD was open-sourced, with certain features (including +support) remaining commercial closed source features requiring licensing from Thoughtworks.
    • +
  • November 2019: Thoughtworks announces the plans for full transfer of GoCD to the community +and end of the commercial support offering.
    • +
  • May 2020: Previously commercial features/plugins are all open-sourced or capability directly incorporated into GoCD by the GoCD Core Team.
    • +
  • December 2020: Commercial support for GoCD ends, as does Thoughtworks-funded development and maintenance of GoCD.
    • +
+ +

How is GoCD currently being maintained?

+ +

As of February 2023, maintainer access to GoCD currently sits with a handful of folks that are either current or ex-Thoughtworks employees, +including some of those originally part of the GoCD core team within Thoughtworks Studios. In practice, active +contributions are coming from a much more limited set of folks - solely within their free time.

+ +

This very small contributor team has completed 3-4 relatively minor releases per year throughout 2021 and 2022, +mainly focused around security-related updates, bug fixes and minor enhancements.

+ +

Does Thoughtworks continue to sponsor GoCD?

+ +

For now, Thoughtworks still graciously provides funding for the website & build infrastructure of GoCD, along with +code signing certificates, and a single commercially licensed component required for Windows support. This is +done on a goodwill basis, and there is no official agreement with or promise to the community regarding this support.

+ +

Does GoCD have active ongoing feature development?

+ +

At time of writing, there is no dedicated team actively contributing to GoCD feature development or major enhancements. +There is also no ongoing funding behind open source contributions to GoCD, and GoCD has a very small contributor community.

+ +

In the current state, this makes it unlikely that GoCD will receive major enhancements or changes in the foreseeable +future, unless there is a large further increase in contributions by users, organizations or other members of the community.

+ +

Is GoCD end-of-life? Abandoned? Should GoCD be considered deprecated?

+ +

GoCD is neither officially end-of-life, nor fully abandoned - but it's fair to say that its development is not thriving +either.

+ +

As to deprecation, generally this is a decision that you should make within your specific context. If GoCD meets your +particular needs and functions as you would like in your environment with its current feature set and user experience, +and the risks are acceptable to you, you should feel free to continue to use it - as with any free & open source software.

+ +

What happened to moving GoCD to an open source foundation?

+ +

There was an attempt to move GoCD over to an open source foundation. Based on initial +conversations, the Linux Foundation and the Apache Software Foundation were interested and would likely have accepted GoCD. +However, that effort is currently dormant. We realized that given the small contributor base, the move to a foundation +would not change the situation significantly. The potential challenge around funding the build and release infrastructure +would remain. The legal effort to make that change would have not been in line with the value of that change. That effort +could be restarted at a later time.

+ +

Is it risky to continue to use GoCD from a security standpoint?

+ +

Maybe? That depends on your assessment of risk. The security policy +has some important caveats, but a balanced assessment of risk for open source software generally includes assessment of +the vibrancy of the software's community.

+ +

Here are some additional aspects to consider:

+ +

The "good" news:

+ +
    +
  • We believe GoCD was built with solid security principles in mind that have generally stood the test of time.
    • +
  • Software dependencies incorporated within GoCD are generally still under active development, and thus being +patched/updated. These are being incorporated into new GoCD releases without major issue.
    • +
  • GoCD runs on and is built/test using modern, maintained language runtimes (Java 17 LTS, NodeJS 20 LTS, Ruby 3.1)
    • +
  • GoCD continues to have good compatibility with latest operating systems, which can be extended to its supported +Docker images.
    • +
+ +

The "neutral" news:

+ +
    +
  • With GoCD, we do not maintain/patch old releases of GoCD. +In general, GoCD has always maintained robust backwards compatibility and sign-posted removals/deprecations in advance +with an expectation that folks will move forward to the latest release.
    • +
+ +

The "not-so-good" news:

+ +
    +
  • GoCD has a significant number of plugins, many different supported operating systems, many Docker image variants, a number +of languages used across the codebase and many different features that make it difficult for a small team to support. +Keeping on top of all of these requires non-trivial effort, and is likely not indefinitely sustainable with the current +contributor/maintainer community size.
    • +
  • +

    At time of writing (updated: December 2023), GoCD does depend on some libraries/frameworks which require significant effort to upgrade, but are +end-of-life, and thus present some level of ongoing risk. If a major vulnerability is discovered in these libraries/frameworks +that affects GoCD it will either require an urgent upgrade, or forking and patching of those libraries/frameworks. The +community is not well placed to manage this kind of development. To help you assess risk, at time of writing, they include (but may not be limited to)

    + +
      +
    • Spring Framework 4.3 (EOL December 2020)
      • +
    • Spring Security 4.2 (EOL October 2020)
      • +
    • Hibernate ORM 3.6 (EOL February 2012)
      • +
    • A small part of the UI relies on +
        +
      • AngularJS 1.0 - plugin view templating support (EOL November 2013)
        • +
      • jQuery 1.7 - stage and build/job detail views (subsequent upgraded in GoCD 23.4.0)
        • +
      • PrototypeJS 1.6 - stage and build/job detail views (subsequently replaced with jQuery in GoCD 23.5.0)
        • +
      +
      • +
    +
    • +
+ +

How can my organization or myself help with maintenance of GoCD?

+ +

You can learn how to contribute here and check out the resources available for getting started.

+ +

Should I migrate away from GoCD?

+ +

Paraphrasing from the original announcement – +you should assess your needs and select the best tool for you. GoCD will be available as an open source project for use in the future. +Thoughtworks and the GoCD maintainers will not be providing alternative tools recommendations or migration support. +Different tools in this space offer different levels of modeling capabilities and features.

+ +

What's the best way to migrate away from GoCD?

+ +

GoCD has a reasonably comprehensive set of APIs you can use to export pipeline configuration as a starting point for +partially automated migration. If you don't use pipelines as code techniques, +you might want to start with using the APIs to get all pipeline groups +and then get pipeline config for each pipeline for conversion to your +target tool.

+ +

GoCD is great! But this doesn't seem like a great situation?

+ +

We think GoCD is great too. And we agree the maintenance situation is not great either. Come encourage us and help us out on the +forums, or GitHub.

+ +
+
+
+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02/13/index.html b/pr-1714/2023/02/13/index.html new file mode 100644 index 000000000..660387bfa --- /dev/null +++ b/pr-1714/2023/02/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/02/index.html b/pr-1714/2023/02/index.html new file mode 100644 index 000000000..1eedaa8fa --- /dev/null +++ b/pr-1714/2023/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/2023/index.html b/pr-1714/2023/index.html new file mode 100644 index 000000000..4b3413210 --- /dev/null +++ b/pr-1714/2023/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/SEdaily.html b/pr-1714/SEdaily.html new file mode 100644 index 000000000..0bfdedea2 --- /dev/null +++ b/pr-1714/SEdaily.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=sedaily_2017_podcast&utm_medium=sedaily_podcast&utm_source=sedaily_podcast&utm_content=sed_podcast&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/SEdaily/index.html b/pr-1714/SEdaily/index.html new file mode 100644 index 000000000..19e7ea981 --- /dev/null +++ b/pr-1714/SEdaily/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=sedaily_2017_podcast&utm_medium=sedaily_podcast&utm_source=sedaily_podcast&utm_content=sed_podcast&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/adwords.txt b/pr-1714/adwords.txt new file mode 100644 index 000000000..500ade381 --- /dev/null +++ b/pr-1714/adwords.txt @@ -0,0 +1 @@ +GooGhywoiu9839t543j0s7543uw1. Please add jemarley@thoughtworks.com to AdWords account 248-377-5440 with Admin access - Date 31 July 2018. \ No newline at end of file diff --git a/pr-1714/analytics-feedback.html b/pr-1714/analytics-feedback.html new file mode 100644 index 000000000..838fb999b --- /dev/null +++ b/pr-1714/analytics-feedback.html @@ -0,0 +1,141 @@ + + + + + + + + + + + + + + + + Analytics Feedback + + + + + + + + + +
+
+ + + +
+ +
+ + + + +
+
+

Registration is now closed.

+

Thank you for your interest. Our registration for GoCD Analytics Plugin feedback is now closed. If you are interested in GoCD Analytics, you can sign up our free 30 day trial.

+

Want other ways to win GoCD gifts? We are assembling a research group to help us better understand user behavior in the continuous delivery space. You can take our short survey for the chance to join our CD research group for the future studies.

+
+
+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/analytics-feedback/index.html b/pr-1714/analytics-feedback/index.html new file mode 100644 index 000000000..fa4499677 --- /dev/null +++ b/pr-1714/analytics-feedback/index.html @@ -0,0 +1,141 @@ + + + + + + + + + + + + + + + + Analytics Feedback + + + + + + + + + +
+
+ + + +
+ +
+ + + + +
+
+

Registration is now closed.

+

Thank you for your interest. Our registration for GoCD Analytics Plugin feedback is now closed. If you are interested in GoCD Analytics, you can sign up our free 30 day trial.

+

Want other ways to win GoCD gifts? We are assembling a research group to help us better understand user behavior in the continuous delivery space. You can take our short survey for the chance to join our CD research group for the future studies.

+
+
+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/analytics.html b/pr-1714/analytics.html new file mode 100644 index 000000000..01fd50ffb --- /dev/null +++ b/pr-1714/analytics.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Improve your GoCD pipelines with the analytics plugin + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + +
+
+ +
+
+
+
+

Get insights into
your GoCD pipelines

+
+
+
+
+
+
+
+ + +
+ + +
+ +
+ +
+
+ + +
+
+

Use metrics to improve your software delivery process

+
    +
  • See, track and analyze your end-to-end cycle time
    • +
  • Real time visibility into your deployment pipelines
    • +
  • Identify bottlenecks of your delivery process
    • +
  • Optimize your resources for best throughput
    • +
+
+ Download Plugin + View Documentation +
+
+
+
+
+
+
+
+
+ GoCD Build Time Graph +
+
+
+

See, track, and analyze your end-to-end cycle time

+

+ GoCD's Analytics plugin provides insights into your entire path to production. It tracks the end-to-end time + of your value stream map, and helps you answer questions like "what is the throughput" and "how long will + this take to reach the customer" more accurately. Read + more. +

+
+
+
+
+
+ GoCD Value Stream Map +
+
+
+

Real-time visibility into your release pipelines

+

+ GoCD's analytics plugin gives real time visibility into your pipelines. Metrics like pipeline build times, + wait times and mean time to recovery are at your fingertips. +

+
+
+
+
+
+ GoCD Pipeline Utilization Chart +
+
+
+

Identify bottlenecks of your process

+

+ GoCD provides both in-context pipeline analytics and top-level metrics to illuminate bottlenecks in your + deployment process and help you streamline it. +

+
+
+
+
+
+ GoCD Agent Utilization Chart +
+
+
+

Optimize your resources for best throughput

+

+ Which jobs are the slowest? Which agents have the longest wait time? GoCD’s analytics plugin answers these + questions and more, helping you optimize your resources for best throughput. +

+
+
+
+
+
+
+

"The GoCD Analytics Plugin provides a great way for teams to assess and improve the effectiveness of their + deployment pipelines. Having used GoCD with multiple distributed teams, I know that having rapid insights into + timings and utilization for build & deployment can be a big enabler for teams. The GoCD Analytics Plugin is + a ‘must’ for serious teams in the enterprise." +
+ Matthew Skelton, Head of Consulting, Conflux

+
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/analytics/index.html b/pr-1714/analytics/index.html new file mode 100644 index 000000000..e56d2f025 --- /dev/null +++ b/pr-1714/analytics/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + + + Improve your GoCD pipelines with the analytics plugin + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + +
+
+ +
+
+
+
+

Get insights into
your GoCD pipelines

+
+
+
+
+
+
+
+ + +
+ + +
+ +
+ +
+
+ + +
+
+

Use metrics to improve your software delivery process

+
    +
  • See, track and analyze your end-to-end cycle time
    • +
  • Real time visibility into your deployment pipelines
    • +
  • Identify bottlenecks of your delivery process
    • +
  • Optimize your resources for best throughput
    • +
+
+ Download Plugin + View Documentation +
+
+
+
+
+
+
+
+
+ GoCD Build Time Graph +
+
+
+

See, track, and analyze your end-to-end cycle time

+

+ GoCD's Analytics plugin provides insights into your entire path to production. It tracks the end-to-end time + of your value stream map, and helps you answer questions like "what is the throughput" and "how long will + this take to reach the customer" more accurately. Read + more. +

+
+
+
+
+
+ GoCD Value Stream Map +
+
+
+

Real-time visibility into your release pipelines

+

+ GoCD's analytics plugin gives real time visibility into your pipelines. Metrics like pipeline build times, + wait times and mean time to recovery are at your fingertips. +

+
+
+
+
+
+ GoCD Pipeline Utilization Chart +
+
+
+

Identify bottlenecks of your process

+

+ GoCD provides both in-context pipeline analytics and top-level metrics to illuminate bottlenecks in your + deployment process and help you streamline it. +

+
+
+
+
+
+ GoCD Agent Utilization Chart +
+
+
+

Optimize your resources for best throughput

+

+ Which jobs are the slowest? Which agents have the longest wait time? GoCD’s analytics plugin answers these + questions and more, helping you optimize your resources for best throughput. +

+
+
+
+
+
+
+

"The GoCD Analytics Plugin provides a great way for teams to assess and improve the effectiveness of their + deployment pipelines. Having used GoCD with multiple distributed teams, I know that having rapid insights into + timings and utilization for build & deployment can be a big enabler for teams. The GoCD Analytics Plugin is + a ‘must’ for serious teams in the enterprise." +
+ Matthew Skelton, Head of Consulting, Conflux

+
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/arrested.html b/pr-1714/arrested.html new file mode 100644 index 000000000..f8149077f --- /dev/null +++ b/pr-1714/arrested.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=arrested_ops_2017&utm_medium=podcast&utm_source=podcast_arrested&utm_content=go_website&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/arrested/index.html b/pr-1714/arrested/index.html new file mode 100644 index 000000000..c04f6df85 --- /dev/null +++ b/pr-1714/arrested/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=arrested_ops_2017&utm_medium=podcast&utm_source=podcast_arrested&utm_content=go_website&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf b/pr-1714/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf new file mode 100644 index 000000000..35acda2fa Binary files /dev/null and b/pr-1714/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf differ diff --git a/pr-1714/assets/font-awesome/fontawesome-webfont-28b78224.woff b/pr-1714/assets/font-awesome/fontawesome-webfont-28b78224.woff new file mode 100644 index 000000000..400014a4b Binary files /dev/null and b/pr-1714/assets/font-awesome/fontawesome-webfont-28b78224.woff differ diff --git a/pr-1714/assets/font-awesome/fontawesome-webfont-98a8aa5c.svg b/pr-1714/assets/font-awesome/fontawesome-webfont-98a8aa5c.svg new file mode 100644 index 000000000..855c845e5 --- /dev/null +++ b/pr-1714/assets/font-awesome/fontawesome-webfont-98a8aa5c.svg @@ -0,0 +1,2671 @@ + + + + +Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016 + By ,,, +Copyright Dave Gandy 2016. All rights reserved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 b/pr-1714/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 new file mode 100644 index 000000000..4d13fc604 Binary files /dev/null and b/pr-1714/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 differ diff --git a/pr-1714/assets/font-awesome/fontawesome-webfont-d980c2ce.eot b/pr-1714/assets/font-awesome/fontawesome-webfont-d980c2ce.eot new file mode 100644 index 000000000..e9f60ca95 Binary files /dev/null and b/pr-1714/assets/font-awesome/fontawesome-webfont-d980c2ce.eot differ diff --git a/pr-1714/assets/gocd-brand-styleguide.zip b/pr-1714/assets/gocd-brand-styleguide.zip new file mode 100644 index 000000000..7a8a3c068 Binary files /dev/null and b/pr-1714/assets/gocd-brand-styleguide.zip differ diff --git a/pr-1714/assets/images/Go_logo-063a2295.png b/pr-1714/assets/images/Go_logo-063a2295.png new file mode 100644 index 000000000..e1c080737 Binary files /dev/null and b/pr-1714/assets/images/Go_logo-063a2295.png differ diff --git a/pr-1714/assets/images/Go_watermark_logo-c6c0c15b.svg b/pr-1714/assets/images/Go_watermark_logo-c6c0c15b.svg new file mode 100644 index 000000000..003cd94ee --- /dev/null +++ b/pr-1714/assets/images/Go_watermark_logo-c6c0c15b.svg @@ -0,0 +1,14 @@ + + + + + + + + diff --git a/pr-1714/assets/images/acceptnace-test-build-time-6e0b8af7.png b/pr-1714/assets/images/acceptnace-test-build-time-6e0b8af7.png new file mode 100644 index 000000000..763a9b8fa Binary files /dev/null and b/pr-1714/assets/images/acceptnace-test-build-time-6e0b8af7.png differ diff --git a/pr-1714/assets/images/add_pipeline-65d0b8ef.gif b/pr-1714/assets/images/add_pipeline-65d0b8ef.gif new file mode 100644 index 000000000..caefa119f Binary files /dev/null and b/pr-1714/assets/images/add_pipeline-65d0b8ef.gif differ diff --git a/pr-1714/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg b/pr-1714/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg new file mode 100644 index 000000000..b66162241 Binary files /dev/null and b/pr-1714/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg differ diff --git a/pr-1714/assets/images/analytics-feedback/1053-devops-9230560f.jpg b/pr-1714/assets/images/analytics-feedback/1053-devops-9230560f.jpg new file mode 100644 index 000000000..444ec9431 Binary files /dev/null and b/pr-1714/assets/images/analytics-feedback/1053-devops-9230560f.jpg differ diff --git a/pr-1714/assets/images/analytics-feedback/1053-future-81b38bba.jpg b/pr-1714/assets/images/analytics-feedback/1053-future-81b38bba.jpg new file mode 100644 index 000000000..ad1742786 Binary files /dev/null and b/pr-1714/assets/images/analytics-feedback/1053-future-81b38bba.jpg differ diff --git a/pr-1714/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg b/pr-1714/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg new file mode 100644 index 000000000..5d56581f9 Binary files /dev/null and b/pr-1714/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg differ diff --git a/pr-1714/assets/images/author-mohan-2781e880.png b/pr-1714/assets/images/author-mohan-2781e880.png new file mode 100644 index 000000000..e4b847682 Binary files /dev/null and b/pr-1714/assets/images/author-mohan-2781e880.png differ diff --git a/pr-1714/assets/images/author-placeholder-b138532c.png b/pr-1714/assets/images/author-placeholder-b138532c.png new file mode 100644 index 000000000..2a26d30d1 Binary files /dev/null and b/pr-1714/assets/images/author-placeholder-b138532c.png differ diff --git a/pr-1714/assets/images/author-wei-f31c41e4.jpg b/pr-1714/assets/images/author-wei-f31c41e4.jpg new file mode 100644 index 000000000..57c55dc42 Binary files /dev/null and b/pr-1714/assets/images/author-wei-f31c41e4.jpg differ diff --git a/pr-1714/assets/images/bg-pattern-470c69ee.png b/pr-1714/assets/images/bg-pattern-470c69ee.png new file mode 100644 index 000000000..9afda79fe Binary files /dev/null and b/pr-1714/assets/images/bg-pattern-470c69ee.png differ diff --git a/pr-1714/assets/images/blog/Permissions1-0658062a.png b/pr-1714/assets/images/blog/Permissions1-0658062a.png new file mode 100644 index 000000000..cf0f9d2e0 Binary files /dev/null and b/pr-1714/assets/images/blog/Permissions1-0658062a.png differ diff --git a/pr-1714/assets/images/blog/Pipeline1-c8a7b4f0.png b/pr-1714/assets/images/blog/Pipeline1-c8a7b4f0.png new file mode 100644 index 000000000..7d2b910bd Binary files /dev/null and b/pr-1714/assets/images/blog/Pipeline1-c8a7b4f0.png differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg b/pr-1714/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg new file mode 100644 index 000000000..f52798385 Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/add-performance-testing-to-your-continuous-delivery-pipeline-f09d6a66.jpg b/pr-1714/assets/images/blog/add-performance-testing/add-performance-testing-to-your-continuous-delivery-pipeline-f09d6a66.jpg new file mode 100644 index 000000000..bbec6bf2a Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/add-performance-testing-to-your-continuous-delivery-pipeline-f09d6a66.jpg differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg b/pr-1714/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg new file mode 100644 index 000000000..406c3e691 Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg b/pr-1714/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg new file mode 100644 index 000000000..60133157e Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg b/pr-1714/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg new file mode 100644 index 000000000..3ad1d962a Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg differ diff --git a/pr-1714/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg b/pr-1714/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg new file mode 100644 index 000000000..21ec29795 Binary files /dev/null and b/pr-1714/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg differ diff --git a/pr-1714/assets/images/blog/agent-bootstrapper-upgrade-for-plugins/summary_image-925c9056.png b/pr-1714/assets/images/blog/agent-bootstrapper-upgrade-for-plugins/summary_image-925c9056.png new file mode 100644 index 000000000..35e8b7961 Binary files /dev/null and b/pr-1714/assets/images/blog/agent-bootstrapper-upgrade-for-plugins/summary_image-925c9056.png differ diff --git a/pr-1714/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png b/pr-1714/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png new file mode 100644 index 000000000..bae8672e2 Binary files /dev/null and b/pr-1714/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png differ diff --git a/pr-1714/assets/images/blog/agents-environments/pipeline-with-environment-agents-4cefb1b7.jpeg b/pr-1714/assets/images/blog/agents-environments/pipeline-with-environment-agents-4cefb1b7.jpeg new file mode 100644 index 000000000..f46f9c78b Binary files /dev/null and b/pr-1714/assets/images/blog/agents-environments/pipeline-with-environment-agents-4cefb1b7.jpeg differ diff --git a/pr-1714/assets/images/blog/architecting-continuous-delivery/architecting-continuous-delivery-hero-25ac88c4.jpg b/pr-1714/assets/images/blog/architecting-continuous-delivery/architecting-continuous-delivery-hero-25ac88c4.jpg new file mode 100644 index 000000000..7b590e192 Binary files /dev/null and b/pr-1714/assets/images/blog/architecting-continuous-delivery/architecting-continuous-delivery-hero-25ac88c4.jpg differ diff --git a/pr-1714/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png b/pr-1714/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png new file mode 100644 index 000000000..2b2ef8496 Binary files /dev/null and b/pr-1714/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png differ diff --git a/pr-1714/assets/images/blog/architecting-continuous-delivery/ice-cream-test-anti-pattern-32612565.png b/pr-1714/assets/images/blog/architecting-continuous-delivery/ice-cream-test-anti-pattern-32612565.png new file mode 100644 index 000000000..9fd043218 Binary files /dev/null and b/pr-1714/assets/images/blog/architecting-continuous-delivery/ice-cream-test-anti-pattern-32612565.png differ diff --git a/pr-1714/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png b/pr-1714/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png new file mode 100644 index 000000000..77a756089 Binary files /dev/null and b/pr-1714/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png differ diff --git a/pr-1714/assets/images/blog/architecting-continuous-delivery/the-deployment-pipeline-6ed8f669.png b/pr-1714/assets/images/blog/architecting-continuous-delivery/the-deployment-pipeline-6ed8f669.png new file mode 100644 index 000000000..c55ae7a35 Binary files /dev/null and b/pr-1714/assets/images/blog/architecting-continuous-delivery/the-deployment-pipeline-6ed8f669.png differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/are-you-ready-for-CD-info-hero-ab1ff875.png b/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/are-you-ready-for-CD-info-hero-ab1ff875.png new file mode 100644 index 000000000..656149b20 Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/are-you-ready-for-CD-info-hero-ab1ff875.png differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/ready-for-continous-delivery-infographic-5f550770.png b/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/ready-for-continous-delivery-infographic-5f550770.png new file mode 100644 index 000000000..e62d1124c Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continous-delivery-infographic/ready-for-continous-delivery-infographic-5f550770.png differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/feedback_loops-93f9a552.jpg b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/feedback_loops-93f9a552.jpg new file mode 100644 index 000000000..7a131d4c4 Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/feedback_loops-93f9a552.jpg differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_delivery_feedback_loops-cb9bdbe3.png b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_delivery_feedback_loops-cb9bdbe3.png new file mode 100644 index 000000000..b8d3299d9 Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_delivery_feedback_loops-cb9bdbe3.png differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_integration_feedback_loops-8325bf92.png b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_integration_feedback_loops-8325bf92.png new file mode 100644 index 000000000..e6202880b Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_integration_feedback_loops-8325bf92.png differ diff --git a/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/woodline-02b5f243.jpeg b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/woodline-02b5f243.jpeg new file mode 100644 index 000000000..f780d544d Binary files /dev/null and b/pr-1714/assets/images/blog/are-you-ready-for-continuous-delivery/woodline-02b5f243.jpeg differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png b/pr-1714/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png new file mode 100644 index 000000000..5e6d898f4 Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png b/pr-1714/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png new file mode 100644 index 000000000..e565397de Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/github-login-18b74573.png b/pr-1714/assets/images/blog/authentication-plugins/github-login-18b74573.png new file mode 100644 index 000000000..73d5f55a5 Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/github-login-18b74573.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png b/pr-1714/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png new file mode 100644 index 000000000..95270e628 Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/login-page-b00e9881.png b/pr-1714/assets/images/blog/authentication-plugins/login-page-b00e9881.png new file mode 100644 index 000000000..dc8c1f769 Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/login-page-b00e9881.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png b/pr-1714/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png new file mode 100644 index 000000000..68ad058cc Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png differ diff --git a/pr-1714/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png b/pr-1714/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png new file mode 100644 index 000000000..323969ab7 Binary files /dev/null and b/pr-1714/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png differ diff --git a/pr-1714/assets/images/blog/beginners-guide-cd/beginners-guide-cd-header-d0a7319f.jpg b/pr-1714/assets/images/blog/beginners-guide-cd/beginners-guide-cd-header-d0a7319f.jpg new file mode 100644 index 000000000..d94221b7d Binary files /dev/null and b/pr-1714/assets/images/blog/beginners-guide-cd/beginners-guide-cd-header-d0a7319f.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/beginnings_pipelines_hero-ebbdcaab.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/beginnings_pipelines_hero-ebbdcaab.jpg new file mode 100644 index 000000000..d3fdcbee7 Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/beginnings_pipelines_hero-ebbdcaab.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg new file mode 100644 index 000000000..fea7f0a62 Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg new file mode 100644 index 000000000..bcf493bb2 Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg new file mode 100644 index 000000000..3a5917211 Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg new file mode 100644 index 000000000..10e76b59b Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg new file mode 100644 index 000000000..d23bdac6f Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg differ diff --git a/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg new file mode 100644 index 000000000..dd9c8068e Binary files /dev/null and b/pr-1714/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg differ diff --git a/pr-1714/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg b/pr-1714/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg new file mode 100644 index 000000000..bab3b4ac2 Binary files /dev/null and b/pr-1714/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg differ diff --git a/pr-1714/assets/images/blog/blue-green/dns-9ac8588f.jpeg b/pr-1714/assets/images/blog/blue-green/dns-9ac8588f.jpeg new file mode 100644 index 000000000..50d4255eb Binary files /dev/null and b/pr-1714/assets/images/blog/blue-green/dns-9ac8588f.jpeg differ diff --git a/pr-1714/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg b/pr-1714/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg new file mode 100644 index 000000000..725d99c96 Binary files /dev/null and b/pr-1714/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg differ diff --git a/pr-1714/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg b/pr-1714/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg new file mode 100644 index 000000000..2b5ee272d Binary files /dev/null and b/pr-1714/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg differ diff --git a/pr-1714/assets/images/blog/build-propagation/fan-in-fan-out-774eac6e.jpeg b/pr-1714/assets/images/blog/build-propagation/fan-in-fan-out-774eac6e.jpeg new file mode 100644 index 000000000..15b8fb1db Binary files /dev/null and b/pr-1714/assets/images/blog/build-propagation/fan-in-fan-out-774eac6e.jpeg differ diff --git a/pr-1714/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg b/pr-1714/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg new file mode 100644 index 000000000..1e806dec4 Binary files /dev/null and b/pr-1714/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg differ diff --git a/pr-1714/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg b/pr-1714/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg new file mode 100644 index 000000000..4a70b8eea Binary files /dev/null and b/pr-1714/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg differ diff --git a/pr-1714/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg b/pr-1714/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg new file mode 100644 index 000000000..5201cb8eb Binary files /dev/null and b/pr-1714/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg differ diff --git a/pr-1714/assets/images/blog/cd-confession-gocd/automate-everything-gocd-e047261e.jpeg b/pr-1714/assets/images/blog/cd-confession-gocd/automate-everything-gocd-e047261e.jpeg new file mode 100644 index 000000000..fd8c8d26e Binary files /dev/null and b/pr-1714/assets/images/blog/cd-confession-gocd/automate-everything-gocd-e047261e.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-confession-gocd/continuous-delivery-confessions-gocd-5d3dbaab.png b/pr-1714/assets/images/blog/cd-confession-gocd/continuous-delivery-confessions-gocd-5d3dbaab.png new file mode 100644 index 000000000..825b61abf Binary files /dev/null and b/pr-1714/assets/images/blog/cd-confession-gocd/continuous-delivery-confessions-gocd-5d3dbaab.png differ diff --git a/pr-1714/assets/images/blog/cd-confession-snapci/continuous-delivery-confessions-snapci-de12716b.png b/pr-1714/assets/images/blog/cd-confession-snapci/continuous-delivery-confessions-snapci-de12716b.png new file mode 100644 index 000000000..1928f4693 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-confession-snapci/continuous-delivery-confessions-snapci-de12716b.png differ diff --git a/pr-1714/assets/images/blog/cd-confessions-mingle/cd-confessions-mingle-hero-2b7da0fe.jpg b/pr-1714/assets/images/blog/cd-confessions-mingle/cd-confessions-mingle-hero-2b7da0fe.jpg new file mode 100644 index 000000000..e5e6dbda8 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-confessions-mingle/cd-confessions-mingle-hero-2b7da0fe.jpg differ diff --git a/pr-1714/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png b/pr-1714/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png new file mode 100644 index 000000000..77a756089 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png differ diff --git a/pr-1714/assets/images/blog/cd-considerations/5-consideration-microservices-gocd-12ad175f.jpg b/pr-1714/assets/images/blog/cd-considerations/5-consideration-microservices-gocd-12ad175f.jpg new file mode 100644 index 000000000..df4ea643d Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/5-consideration-microservices-gocd-12ad175f.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-considerations/environments-plan-e0ff13b0.jpeg b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/environments-plan-e0ff13b0.jpeg new file mode 100644 index 000000000..22d440449 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/environments-plan-e0ff13b0.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-considerations/hotfix-process-fef37152.jpeg b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/hotfix-process-fef37152.jpeg new file mode 100644 index 000000000..8cec03232 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/hotfix-process-fef37152.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-considerations/test-strategy-0cde2295.jpeg b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/test-strategy-0cde2295.jpeg new file mode 100644 index 000000000..201d07e94 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-considerations/test-strategy-0cde2295.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-microservices-configuration-strategy-95389633.jpg b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-configuration-strategy-95389633.jpg new file mode 100644 index 000000000..69aa85d82 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-configuration-strategy-95389633.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-microservices-environment-strategy-0cce5b32.jpg b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-environment-strategy-0cce5b32.jpg new file mode 100644 index 000000000..18373a357 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-environment-strategy-0cce5b32.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/cd-microservices-remediation-strategy-b0bee309.jpg b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-remediation-strategy-b0bee309.jpg new file mode 100644 index 000000000..482c08d58 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/cd-microservices-remediation-strategy-b0bee309.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg b/pr-1714/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg new file mode 100644 index 000000000..69aa85d82 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/continuous-delivery-remediation-strategy-d02def00.jpeg b/pr-1714/assets/images/blog/cd-considerations/continuous-delivery-remediation-strategy-d02def00.jpeg new file mode 100644 index 000000000..9d02c916f Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/continuous-delivery-remediation-strategy-d02def00.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png b/pr-1714/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png new file mode 100644 index 000000000..7a949f975 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png differ diff --git a/pr-1714/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg b/pr-1714/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg new file mode 100644 index 000000000..22d440449 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png b/pr-1714/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png new file mode 100644 index 000000000..3902603d1 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png differ diff --git a/pr-1714/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png b/pr-1714/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png new file mode 100644 index 000000000..0ace00361 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png differ diff --git a/pr-1714/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg b/pr-1714/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg new file mode 100644 index 000000000..8cec03232 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg b/pr-1714/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg new file mode 100644 index 000000000..20f19fffa Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg b/pr-1714/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg new file mode 100644 index 000000000..b7674b3ee Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg b/pr-1714/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg new file mode 100644 index 000000000..201d07e94 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg b/pr-1714/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg new file mode 100644 index 000000000..0a983e70a Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg differ diff --git a/pr-1714/assets/images/blog/cd-considerations/toss.txt b/pr-1714/assets/images/blog/cd-considerations/toss.txt new file mode 100644 index 000000000..79a8839f4 --- /dev/null +++ b/pr-1714/assets/images/blog/cd-considerations/toss.txt @@ -0,0 +1 @@ +throw this away diff --git a/pr-1714/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png b/pr-1714/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png new file mode 100644 index 000000000..2a7e5c50c Binary files /dev/null and b/pr-1714/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/cd-hacks-gocd-materials-a91363d7.jpg b/pr-1714/assets/images/blog/cd-hacks/cd-hacks-gocd-materials-a91363d7.jpg new file mode 100644 index 000000000..c78099ab2 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/cd-hacks-gocd-materials-a91363d7.jpg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg b/pr-1714/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg new file mode 100644 index 000000000..4c2b35ec7 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png b/pr-1714/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png new file mode 100644 index 000000000..f688d1b3c Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png b/pr-1714/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png new file mode 100644 index 000000000..a73391abc Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-add-auth-ldap-397c6a4c.png b/pr-1714/assets/images/blog/cd-hacks/gocd-add-auth-ldap-397c6a4c.png new file mode 100644 index 000000000..473eb49e5 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-add-auth-ldap-397c6a4c.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-authorize-config-ldap-2440fa39.gif b/pr-1714/assets/images/blog/cd-hacks/gocd-authorize-config-ldap-2440fa39.gif new file mode 100644 index 000000000..b5a2cdb8c Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-authorize-config-ldap-2440fa39.gif differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-2-089da79f.png b/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-2-089da79f.png new file mode 100644 index 000000000..b4c421df4 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-2-089da79f.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-f8aef3b8.png b/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-f8aef3b8.png new file mode 100644 index 000000000..6b5f3a9b9 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-create-artifact-store-f8aef3b8.png differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg b/pr-1714/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg new file mode 100644 index 000000000..814bea317 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif b/pr-1714/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif new file mode 100644 index 000000000..ac65a72fb Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif differ diff --git a/pr-1714/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg b/pr-1714/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg new file mode 100644 index 000000000..80082c1d5 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/google-container-registry-artifact-store-034f7207.jpg b/pr-1714/assets/images/blog/cd-hacks/google-container-registry-artifact-store-034f7207.jpg new file mode 100644 index 000000000..36046358c Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/google-container-registry-artifact-store-034f7207.jpg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg b/pr-1714/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg new file mode 100644 index 000000000..c27125dab Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg differ diff --git a/pr-1714/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg b/pr-1714/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg new file mode 100644 index 000000000..cc7b837df Binary files /dev/null and b/pr-1714/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg b/pr-1714/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg new file mode 100644 index 000000000..ac6c7af4f Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png b/pr-1714/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png new file mode 100644 index 000000000..dfc2dd9ca Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg b/pr-1714/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg new file mode 100644 index 000000000..d005fb8f3 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/cd-metrics-example-pipelines-11f24e33.png b/pr-1714/assets/images/blog/cd-metrics/cd-metrics-example-pipelines-11f24e33.png new file mode 100644 index 000000000..394c80f1d Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/cd-metrics-example-pipelines-11f24e33.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/cd-metrics-lead-time-1e8d759a.jpg b/pr-1714/assets/images/blog/cd-metrics/cd-metrics-lead-time-1e8d759a.jpg new file mode 100644 index 000000000..04b7b7e96 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/cd-metrics-lead-time-1e8d759a.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png b/pr-1714/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png new file mode 100644 index 000000000..a38e20256 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg b/pr-1714/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg new file mode 100644 index 000000000..803b0e5fd Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png b/pr-1714/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png new file mode 100644 index 000000000..917a5ae8a Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg b/pr-1714/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg new file mode 100644 index 000000000..eb4fdec56 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/lead-time-workflow-analytics-91e6cc27.png b/pr-1714/assets/images/blog/cd-metrics/lead-time-workflow-analytics-91e6cc27.png new file mode 100644 index 000000000..bfe99c2ba Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/lead-time-workflow-analytics-91e6cc27.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png b/pr-1714/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png new file mode 100644 index 000000000..61e375dcd Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg b/pr-1714/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg new file mode 100644 index 000000000..f35171f02 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/metrics-continuous-delivery-header-85a81e8b.jpg b/pr-1714/assets/images/blog/cd-metrics/metrics-continuous-delivery-header-85a81e8b.jpg new file mode 100644 index 000000000..d0b6a4ee7 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/metrics-continuous-delivery-header-85a81e8b.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/throughput-f47c6623.jpg b/pr-1714/assets/images/blog/cd-metrics/throughput-f47c6623.jpg new file mode 100644 index 000000000..803b0e5fd Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/throughput-f47c6623.jpg differ diff --git a/pr-1714/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png b/pr-1714/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png new file mode 100644 index 000000000..f4cf72175 Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png differ diff --git a/pr-1714/assets/images/blog/cd-metrics/throughput-manual-feaec385.png b/pr-1714/assets/images/blog/cd-metrics/throughput-manual-feaec385.png new file mode 100644 index 000000000..997dd4e0f Binary files /dev/null and b/pr-1714/assets/images/blog/cd-metrics/throughput-manual-feaec385.png differ diff --git a/pr-1714/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg b/pr-1714/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg new file mode 100644 index 000000000..695dbfe2d Binary files /dev/null and b/pr-1714/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg differ diff --git a/pr-1714/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png b/pr-1714/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png new file mode 100644 index 000000000..b835f124b Binary files /dev/null and b/pr-1714/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png differ diff --git a/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-1-e172b0b5.png b/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-1-e172b0b5.png new file mode 100644 index 000000000..087dfc93c Binary files /dev/null and b/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-1-e172b0b5.png differ diff --git a/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-2-77162996.png b/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-2-77162996.png new file mode 100644 index 000000000..b2b9a8f11 Binary files /dev/null and b/pr-1714/assets/images/blog/cloning-templates/trigger-with-options-2-77162996.png differ diff --git a/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-5f550770.png b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-5f550770.png new file mode 100644 index 000000000..e62d1124c Binary files /dev/null and b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-5f550770.png differ diff --git a/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-hero-ab1ff875.png b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-hero-ab1ff875.png new file mode 100644 index 000000000..656149b20 Binary files /dev/null and b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-hero-ab1ff875.png differ diff --git a/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continuous-delivery-vs-continuous-deployment-infographic-305dd620.png b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continuous-delivery-vs-continuous-deployment-infographic-305dd620.png new file mode 100644 index 000000000..82ff59aca Binary files /dev/null and b/pr-1714/assets/images/blog/continous-delivery-vs-deployment-infographic/continuous-delivery-vs-continuous-deployment-infographic-305dd620.png differ diff --git a/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part1-hero-16be1e69.jpg b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part1-hero-16be1e69.jpg new file mode 100644 index 000000000..312b3d742 Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part1-hero-16be1e69.jpg differ diff --git a/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part2-hero-c606477c.jpg b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part2-hero-c606477c.jpg new file mode 100644 index 000000000..e6624712e Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part2-hero-c606477c.jpg differ diff --git a/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part3-hero-a7e89092.jpg b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part3-hero-a7e89092.jpg new file mode 100644 index 000000000..de88656ca Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part3-hero-a7e89092.jpg differ diff --git a/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part4-hero-d6b73c08.jpg b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part4-hero-d6b73c08.jpg new file mode 100644 index 000000000..10d340614 Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part4-hero-d6b73c08.jpg differ diff --git a/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part5-hero-3db5a75f.jpg b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part5-hero-3db5a75f.jpg new file mode 100644 index 000000000..3f37a761c Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part5-hero-3db5a75f.jpg differ diff --git a/pr-1714/assets/images/blog/continuous-deployment-strategies/blue-green-deployments-d73adc69.jpeg b/pr-1714/assets/images/blog/continuous-deployment-strategies/blue-green-deployments-d73adc69.jpeg new file mode 100644 index 000000000..dbe6fa4b7 Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-deployment-strategies/blue-green-deployments-d73adc69.jpeg differ diff --git a/pr-1714/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg b/pr-1714/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg new file mode 100644 index 000000000..18e0069bd Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg differ diff --git a/pr-1714/assets/images/blog/continuous-deployment-strategies/continuous-deployment-hero-9ab88d57.jpg b/pr-1714/assets/images/blog/continuous-deployment-strategies/continuous-deployment-hero-9ab88d57.jpg new file mode 100644 index 000000000..e1c99fc32 Binary files /dev/null and b/pr-1714/assets/images/blog/continuous-deployment-strategies/continuous-deployment-hero-9ab88d57.jpg differ diff --git a/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_oven-6a40663e.png b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_oven-6a40663e.png new file mode 100644 index 000000000..9fe340264 Binary files /dev/null and b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_oven-6a40663e.png differ diff --git a/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_paint-11210336.png b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_paint-11210336.png new file mode 100644 index 000000000..35d1006d8 Binary files /dev/null and b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_paint-11210336.png differ diff --git a/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_recorded-8850667e.png b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_recorded-8850667e.png new file mode 100644 index 000000000..a8f17a360 Binary files /dev/null and b/pr-1714/assets/images/blog/deploy-now/but_it_just_needs_recorded-8850667e.png differ diff --git a/pr-1714/assets/images/blog/deploy-now/continuous_delivery_security_testing_pipeline-af8f0e84.png b/pr-1714/assets/images/blog/deploy-now/continuous_delivery_security_testing_pipeline-af8f0e84.png new file mode 100644 index 000000000..93b72dc04 Binary files /dev/null and b/pr-1714/assets/images/blog/deploy-now/continuous_delivery_security_testing_pipeline-af8f0e84.png differ diff --git a/pr-1714/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png b/pr-1714/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png new file mode 100644 index 000000000..1616e240c Binary files /dev/null and b/pr-1714/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png differ diff --git a/pr-1714/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png b/pr-1714/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png new file mode 100644 index 000000000..c9cd82cae Binary files /dev/null and b/pr-1714/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png b/pr-1714/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png new file mode 100644 index 000000000..af5411932 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead-1bb6cb32.png b/pr-1714/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead-1bb6cb32.png new file mode 100644 index 000000000..21218ef87 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead-1bb6cb32.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png b/pr-1714/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png new file mode 100644 index 000000000..5c62f059f Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png b/pr-1714/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png new file mode 100644 index 000000000..120ca5c26 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png b/pr-1714/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png new file mode 100644 index 000000000..fc0369e96 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/package_cmd_label-2f8c10da.png b/pr-1714/assets/images/blog/dotnet-core-gocd/package_cmd_label-2f8c10da.png new file mode 100644 index 000000000..59ce1a6e1 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/package_cmd_label-2f8c10da.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png new file mode 100644 index 000000000..690dc668d Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-as-material-d5920f88.png b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-as-material-d5920f88.png new file mode 100644 index 000000000..010e47345 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-as-material-d5920f88.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png new file mode 100644 index 000000000..3ab36e5a4 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-passed-build-35fe20dd.png b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-passed-build-35fe20dd.png new file mode 100644 index 000000000..fd2950555 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-passed-build-35fe20dd.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-stage-job-acb12e4f.png b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-stage-job-acb12e4f.png new file mode 100644 index 000000000..e93ad59f8 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/pipeline-stage-job-acb12e4f.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png b/pr-1714/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png new file mode 100644 index 000000000..35664d105 Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png differ diff --git a/pr-1714/assets/images/blog/dotnet-core-gocd/value-stream-map-73b88bd3.png b/pr-1714/assets/images/blog/dotnet-core-gocd/value-stream-map-73b88bd3.png new file mode 100644 index 000000000..c61c7582f Binary files /dev/null and b/pr-1714/assets/images/blog/dotnet-core-gocd/value-stream-map-73b88bd3.png differ diff --git a/pr-1714/assets/images/blog/driving-change-devops/cannot-buy-devops-you-can-sell-devops-28115ba7.jpg b/pr-1714/assets/images/blog/driving-change-devops/cannot-buy-devops-you-can-sell-devops-28115ba7.jpg new file mode 100644 index 000000000..4238e0282 Binary files /dev/null and b/pr-1714/assets/images/blog/driving-change-devops/cannot-buy-devops-you-can-sell-devops-28115ba7.jpg differ diff --git a/pr-1714/assets/images/blog/driving-change-devops/driving-change-devops-hero-a5d5b1d4.jpg b/pr-1714/assets/images/blog/driving-change-devops/driving-change-devops-hero-a5d5b1d4.jpg new file mode 100644 index 000000000..2f8aad74d Binary files /dev/null and b/pr-1714/assets/images/blog/driving-change-devops/driving-change-devops-hero-a5d5b1d4.jpg differ diff --git a/pr-1714/assets/images/blog/driving-change-devops/part-2-cant-buy-devops-48f30921.jpg b/pr-1714/assets/images/blog/driving-change-devops/part-2-cant-buy-devops-48f30921.jpg new file mode 100644 index 000000000..da1106bea Binary files /dev/null and b/pr-1714/assets/images/blog/driving-change-devops/part-2-cant-buy-devops-48f30921.jpg differ diff --git a/pr-1714/assets/images/blog/driving-change-devops/spreading-devops-adoption-4387ffdb.jpg b/pr-1714/assets/images/blog/driving-change-devops/spreading-devops-adoption-4387ffdb.jpg new file mode 100644 index 000000000..dcb9cafa3 Binary files /dev/null and b/pr-1714/assets/images/blog/driving-change-devops/spreading-devops-adoption-4387ffdb.jpg differ diff --git a/pr-1714/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg b/pr-1714/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg new file mode 100644 index 000000000..4853d7d53 Binary files /dev/null and b/pr-1714/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg differ diff --git a/pr-1714/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg b/pr-1714/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg new file mode 100644 index 000000000..280eb42a3 Binary files /dev/null and b/pr-1714/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg differ diff --git a/pr-1714/assets/images/blog/end-to-end-kubernetes/end-to-end-kubernetes-hero-a52d8df4.jpg b/pr-1714/assets/images/blog/end-to-end-kubernetes/end-to-end-kubernetes-hero-a52d8df4.jpg new file mode 100644 index 000000000..f446a2e3e Binary files /dev/null and b/pr-1714/assets/images/blog/end-to-end-kubernetes/end-to-end-kubernetes-hero-a52d8df4.jpg differ diff --git a/pr-1714/assets/images/blog/feature-branch/extract-template-cfd29320.png b/pr-1714/assets/images/blog/feature-branch/extract-template-cfd29320.png new file mode 100644 index 000000000..060638b43 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/extract-template-cfd29320.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/failed-build-bb7a251d.png b/pr-1714/assets/images/blog/feature-branch/failed-build-bb7a251d.png new file mode 100644 index 000000000..4631cfd7d Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/failed-build-bb7a251d.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/mature-ci-cd-setup-f94937bf.png b/pr-1714/assets/images/blog/feature-branch/mature-ci-cd-setup-f94937bf.png new file mode 100644 index 000000000..9618097c9 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/mature-ci-cd-setup-f94937bf.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/plugins-loaded-9903d601.png b/pr-1714/assets/images/blog/feature-branch/plugins-loaded-9903d601.png new file mode 100644 index 000000000..086fa98f0 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/plugins-loaded-9903d601.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png b/pr-1714/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png new file mode 100644 index 000000000..039fe9697 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/replace-material-2-afc048ab.png b/pr-1714/assets/images/blog/feature-branch/replace-material-2-afc048ab.png new file mode 100644 index 000000000..a241af8c6 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/replace-material-2-afc048ab.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/setup-90ad35f1.png b/pr-1714/assets/images/blog/feature-branch/setup-90ad35f1.png new file mode 100644 index 000000000..9ac661fd2 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/setup-90ad35f1.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/trigger-build-aa3c586e.png b/pr-1714/assets/images/blog/feature-branch/trigger-build-aa3c586e.png new file mode 100644 index 000000000..4bfb4dc84 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/trigger-build-aa3c586e.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png b/pr-1714/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png new file mode 100644 index 000000000..24ee0a702 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/update-status-2-f94045e6.png b/pr-1714/assets/images/blog/feature-branch/update-status-2-f94045e6.png new file mode 100644 index 000000000..0949b5694 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/update-status-2-f94045e6.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/vsm-59138517.png b/pr-1714/assets/images/blog/feature-branch/vsm-59138517.png new file mode 100644 index 000000000..6b98fae32 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/vsm-59138517.png differ diff --git a/pr-1714/assets/images/blog/feature-branch/with_prs-6626da92.png b/pr-1714/assets/images/blog/feature-branch/with_prs-6626da92.png new file mode 100644 index 000000000..d6829d535 Binary files /dev/null and b/pr-1714/assets/images/blog/feature-branch/with_prs-6626da92.png differ diff --git a/pr-1714/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg b/pr-1714/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg new file mode 100644 index 000000000..f5c19a3e4 Binary files /dev/null and b/pr-1714/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg differ diff --git a/pr-1714/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png b/pr-1714/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png new file mode 100644 index 000000000..b7217b373 Binary files /dev/null and b/pr-1714/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png differ diff --git a/pr-1714/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png b/pr-1714/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png new file mode 100644 index 000000000..531d4b59d Binary files /dev/null and b/pr-1714/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png differ diff --git a/pr-1714/assets/images/blog/github-integration/github-issue-link-in-build-cause-e5aa4891.png b/pr-1714/assets/images/blog/github-integration/github-issue-link-in-build-cause-e5aa4891.png new file mode 100644 index 000000000..52a3e6e0f Binary files /dev/null and b/pr-1714/assets/images/blog/github-integration/github-issue-link-in-build-cause-e5aa4891.png differ diff --git a/pr-1714/assets/images/blog/github-integration/github-issue-link-in-compare-pipeline-2f73a0c6.png b/pr-1714/assets/images/blog/github-integration/github-issue-link-in-compare-pipeline-2f73a0c6.png new file mode 100644 index 000000000..f6ddc8346 Binary files /dev/null and b/pr-1714/assets/images/blog/github-integration/github-issue-link-in-compare-pipeline-2f73a0c6.png differ diff --git a/pr-1714/assets/images/blog/github-integration/github-issues-integration-639bff5d.png b/pr-1714/assets/images/blog/github-integration/github-issues-integration-639bff5d.png new file mode 100644 index 000000000..63f6d68c5 Binary files /dev/null and b/pr-1714/assets/images/blog/github-integration/github-issues-integration-639bff5d.png differ diff --git a/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/dieamond-problem-6c3b1401.png b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/dieamond-problem-6c3b1401.png new file mode 100644 index 000000000..16af92864 Binary files /dev/null and b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/dieamond-problem-6c3b1401.png differ diff --git a/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-architecture-f39bda5b.png b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-architecture-f39bda5b.png new file mode 100644 index 000000000..94c9c3ddd Binary files /dev/null and b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-architecture-f39bda5b.png differ diff --git a/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-fanIn-4f7b1e3b.png b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-fanIn-4f7b1e3b.png new file mode 100644 index 000000000..67fe5b50a Binary files /dev/null and b/pr-1714/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-fanIn-4f7b1e3b.png differ diff --git a/pr-1714/assets/images/blog/go-moving-to-open-source/gocd-website-as-of-feb-2014-from-archive.org-214753b0.png b/pr-1714/assets/images/blog/go-moving-to-open-source/gocd-website-as-of-feb-2014-from-archive.org-214753b0.png new file mode 100644 index 000000000..647d01712 Binary files /dev/null and b/pr-1714/assets/images/blog/go-moving-to-open-source/gocd-website-as-of-feb-2014-from-archive.org-214753b0.png differ diff --git a/pr-1714/assets/images/blog/go_14_1_announcement/1_Without_Curl-f0795e21.png b/pr-1714/assets/images/blog/go_14_1_announcement/1_Without_Curl-f0795e21.png new file mode 100644 index 000000000..e2bc98c1d Binary files /dev/null and b/pr-1714/assets/images/blog/go_14_1_announcement/1_Without_Curl-f0795e21.png differ diff --git a/pr-1714/assets/images/blog/go_14_1_announcement/2_With_Curl-ccd04a54.png b/pr-1714/assets/images/blog/go_14_1_announcement/2_With_Curl-ccd04a54.png new file mode 100644 index 000000000..0ca8f9f96 Binary files /dev/null and b/pr-1714/assets/images/blog/go_14_1_announcement/2_With_Curl-ccd04a54.png differ diff --git a/pr-1714/assets/images/blog/gocd-and-java-licenses/gocd-java-licenses-header-og-30168501.jpg b/pr-1714/assets/images/blog/gocd-and-java-licenses/gocd-java-licenses-header-og-30168501.jpg new file mode 100644 index 000000000..a9c26d0e7 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-and-java-licenses/gocd-java-licenses-header-og-30168501.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-in-2016/9777304813_645817bfdf_h_small_cropped-f28ca58c.jpg b/pr-1714/assets/images/blog/gocd-in-2016/9777304813_645817bfdf_h_small_cropped-f28ca58c.jpg new file mode 100644 index 000000000..340dbd010 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-in-2016/9777304813_645817bfdf_h_small_cropped-f28ca58c.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg b/pr-1714/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg new file mode 100644 index 000000000..340dbd010 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-jenkins/gocd-over-jenkins-hero-e727f77f.jpg b/pr-1714/assets/images/blog/gocd-jenkins/gocd-over-jenkins-hero-e727f77f.jpg new file mode 100644 index 000000000..a93e54556 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-jenkins/gocd-over-jenkins-hero-e727f77f.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/GoCD-deploying-kubernetes-0635fbee.svg b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/GoCD-deploying-kubernetes-0635fbee.svg new file mode 100644 index 000000000..1948b2f53 --- /dev/null +++ b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/GoCD-deploying-kubernetes-0635fbee.svg @@ -0,0 +1,414 @@ + + 890-pipeline-illo-edit-outline + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/gocd-kubernetes-helm-chart-hero-71d9973f.jpg b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/gocd-kubernetes-helm-chart-hero-71d9973f.jpg new file mode 100644 index 000000000..6ed791e42 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/gocd-kubernetes-helm-chart-hero-71d9973f.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-1b4c4e55.png b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-1b4c4e55.png new file mode 100644 index 000000000..f394c2062 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-1b4c4e55.png differ diff --git a/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-c15ee8f8.svg b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-c15ee8f8.svg new file mode 100644 index 000000000..e8d1b07ac --- /dev/null +++ b/pr-1714/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-c15ee8f8.svg @@ -0,0 +1,248 @@ + + + + + + + + + + + + + + + + + + + 890-K8_ILLO_outline_revision + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/blog/gocd-snap-at-devops-enterprise-summit/summary_image-32888e61.png b/pr-1714/assets/images/blog/gocd-snap-at-devops-enterprise-summit/summary_image-32888e61.png new file mode 100644 index 000000000..6e09a924a Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-snap-at-devops-enterprise-summit/summary_image-32888e61.png differ diff --git a/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-2-c7d8ebf4.png b/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-2-c7d8ebf4.png new file mode 100644 index 000000000..213bd7fab Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-2-c7d8ebf4.png differ diff --git a/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png b/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png new file mode 100644 index 000000000..2911477bd Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png differ diff --git a/pr-1714/assets/images/blog/gocd-usage-analytics/notification-773fb524.png b/pr-1714/assets/images/blog/gocd-usage-analytics/notification-773fb524.png new file mode 100644 index 000000000..f0627ecaa Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-usage-analytics/notification-773fb524.png differ diff --git a/pr-1714/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg b/pr-1714/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg new file mode 100644 index 000000000..465baf4ac Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png b/pr-1714/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png new file mode 100644 index 000000000..ce3ad3087 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png differ diff --git a/pr-1714/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png b/pr-1714/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png new file mode 100644 index 000000000..d8bf1427d Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png differ diff --git a/pr-1714/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png b/pr-1714/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png new file mode 100644 index 000000000..c6a1b7845 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png differ diff --git a/pr-1714/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png b/pr-1714/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png new file mode 100644 index 000000000..8cc64bb62 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png differ diff --git a/pr-1714/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png b/pr-1714/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png new file mode 100644 index 000000000..82f0c1f67 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png differ diff --git a/pr-1714/assets/images/blog/gocd-vs-spinnaker/concerns-CD-workflow-b113290e.jpeg b/pr-1714/assets/images/blog/gocd-vs-spinnaker/concerns-CD-workflow-b113290e.jpeg new file mode 100644 index 000000000..2675bea7e Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-vs-spinnaker/concerns-CD-workflow-b113290e.jpeg differ diff --git a/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vs-spinnaker-hero-66a667cb.jpg b/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vs-spinnaker-hero-66a667cb.jpg new file mode 100644 index 000000000..2af32f521 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vs-spinnaker-hero-66a667cb.jpg differ diff --git a/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png b/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png new file mode 100644 index 000000000..9b8f5f5f1 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png differ diff --git a/pr-1714/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png b/pr-1714/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png new file mode 100644 index 000000000..ec6cea962 Binary files /dev/null and b/pr-1714/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png differ diff --git a/pr-1714/assets/images/blog/hardly-anyone-knows-cd/01_CD_the_idea_low-res-aa3d8a60.jpg b/pr-1714/assets/images/blog/hardly-anyone-knows-cd/01_CD_the_idea_low-res-aa3d8a60.jpg new file mode 100644 index 000000000..b1a10ac03 Binary files /dev/null and b/pr-1714/assets/images/blog/hardly-anyone-knows-cd/01_CD_the_idea_low-res-aa3d8a60.jpg differ diff --git a/pr-1714/assets/images/blog/hello-world-with-go/media_1394063203663-defb74a5.png b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063203663-defb74a5.png new file mode 100644 index 000000000..13a1aceb2 Binary files /dev/null and b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063203663-defb74a5.png differ diff --git a/pr-1714/assets/images/blog/hello-world-with-go/media_1394063238598-cc4cd6e6.png b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063238598-cc4cd6e6.png new file mode 100644 index 000000000..dbd3d4222 Binary files /dev/null and b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063238598-cc4cd6e6.png differ diff --git a/pr-1714/assets/images/blog/hello-world-with-go/media_1394063327989-43ac29c7.png b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063327989-43ac29c7.png new file mode 100644 index 000000000..dadb7ef7d Binary files /dev/null and b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063327989-43ac29c7.png differ diff --git a/pr-1714/assets/images/blog/hello-world-with-go/media_1394063391538-70cbaf26.png b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063391538-70cbaf26.png new file mode 100644 index 000000000..676658cd8 Binary files /dev/null and b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063391538-70cbaf26.png differ diff --git a/pr-1714/assets/images/blog/hello-world-with-go/media_1394063534943-251780ef.png b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063534943-251780ef.png new file mode 100644 index 000000000..ead6d324a Binary files /dev/null and b/pr-1714/assets/images/blog/hello-world-with-go/media_1394063534943-251780ef.png differ diff --git a/pr-1714/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg b/pr-1714/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg new file mode 100644 index 000000000..856e470d4 Binary files /dev/null and b/pr-1714/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg differ diff --git a/pr-1714/assets/images/blog/high-centered-team/truck-149df877.jpg b/pr-1714/assets/images/blog/high-centered-team/truck-149df877.jpg new file mode 100644 index 000000000..03c2b684a Binary files /dev/null and b/pr-1714/assets/images/blog/high-centered-team/truck-149df877.jpg differ diff --git a/pr-1714/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg b/pr-1714/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg new file mode 100644 index 000000000..99b3e535a Binary files /dev/null and b/pr-1714/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg differ diff --git a/pr-1714/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg b/pr-1714/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg new file mode 100644 index 000000000..5d2f7b48d Binary files /dev/null and b/pr-1714/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg differ diff --git a/pr-1714/assets/images/blog/hotfix-rollback/prod-pipeline-hotfix-stage-5455face.jpeg b/pr-1714/assets/images/blog/hotfix-rollback/prod-pipeline-hotfix-stage-5455face.jpeg new file mode 100644 index 000000000..764b730a0 Binary files /dev/null and b/pr-1714/assets/images/blog/hotfix-rollback/prod-pipeline-hotfix-stage-5455face.jpeg differ diff --git a/pr-1714/assets/images/blog/how-implement-continuous-delivery-enterprise-java-middleware/summary_image-9864dd87.png b/pr-1714/assets/images/blog/how-implement-continuous-delivery-enterprise-java-middleware/summary_image-9864dd87.png new file mode 100644 index 000000000..4b683a17f Binary files /dev/null and b/pr-1714/assets/images/blog/how-implement-continuous-delivery-enterprise-java-middleware/summary_image-9864dd87.png differ diff --git a/pr-1714/assets/images/blog/how-to-avoid-brittle-code/how-to-avoid-brittle-code-083942f0.jpg b/pr-1714/assets/images/blog/how-to-avoid-brittle-code/how-to-avoid-brittle-code-083942f0.jpg new file mode 100644 index 000000000..ae42189f1 Binary files /dev/null and b/pr-1714/assets/images/blog/how-to-avoid-brittle-code/how-to-avoid-brittle-code-083942f0.jpg differ diff --git a/pr-1714/assets/images/blog/importance-cd-pipelines/Fast-Feedback-First-3e39eb55.png b/pr-1714/assets/images/blog/importance-cd-pipelines/Fast-Feedback-First-3e39eb55.png new file mode 100644 index 000000000..231cc8b2f Binary files /dev/null and b/pr-1714/assets/images/blog/importance-cd-pipelines/Fast-Feedback-First-3e39eb55.png differ diff --git a/pr-1714/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg b/pr-1714/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg new file mode 100644 index 000000000..30b0d5f3f Binary files /dev/null and b/pr-1714/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg differ diff --git a/pr-1714/assets/images/blog/importance-cd-pipelines/importance_pipelines_hero-58d38841.jpg b/pr-1714/assets/images/blog/importance-cd-pipelines/importance_pipelines_hero-58d38841.jpg new file mode 100644 index 000000000..7920b65ce Binary files /dev/null and b/pr-1714/assets/images/blog/importance-cd-pipelines/importance_pipelines_hero-58d38841.jpg differ diff --git a/pr-1714/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg b/pr-1714/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg new file mode 100644 index 000000000..4f7e6ac82 Binary files /dev/null and b/pr-1714/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg differ diff --git a/pr-1714/assets/images/blog/issues/Circle-icons-caution-c3010dc6.svg b/pr-1714/assets/images/blog/issues/Circle-icons-caution-c3010dc6.svg new file mode 100644 index 000000000..12fee87da --- /dev/null +++ b/pr-1714/assets/images/blog/issues/Circle-icons-caution-c3010dc6.svg @@ -0,0 +1,95 @@ + + + +image/svg+xml \ No newline at end of file diff --git a/pr-1714/assets/images/blog/issues/issue-0621ef4e.png b/pr-1714/assets/images/blog/issues/issue-0621ef4e.png new file mode 100644 index 000000000..298897581 Binary files /dev/null and b/pr-1714/assets/images/blog/issues/issue-0621ef4e.png differ diff --git a/pr-1714/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png b/pr-1714/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png new file mode 100644 index 000000000..04e259034 Binary files /dev/null and b/pr-1714/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png differ diff --git a/pr-1714/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png b/pr-1714/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png new file mode 100644 index 000000000..486861333 Binary files /dev/null and b/pr-1714/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png differ diff --git a/pr-1714/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg b/pr-1714/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg new file mode 100644 index 000000000..a35061517 --- /dev/null +++ b/pr-1714/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg @@ -0,0 +1,105 @@ + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/blog/manage-agents-with-docker/small_h-7876947e.png b/pr-1714/assets/images/blog/manage-agents-with-docker/small_h-7876947e.png new file mode 100644 index 000000000..06f6b9a46 Binary files /dev/null and b/pr-1714/assets/images/blog/manage-agents-with-docker/small_h-7876947e.png differ diff --git a/pr-1714/assets/images/blog/manage-build-versions/manage-build-versions-hero-c20cdce6.jpg b/pr-1714/assets/images/blog/manage-build-versions/manage-build-versions-hero-c20cdce6.jpg new file mode 100644 index 000000000..b81aa91f7 Binary files /dev/null and b/pr-1714/assets/images/blog/manage-build-versions/manage-build-versions-hero-c20cdce6.jpg differ diff --git a/pr-1714/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg b/pr-1714/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg new file mode 100644 index 000000000..600cb2023 Binary files /dev/null and b/pr-1714/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg differ diff --git a/pr-1714/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg b/pr-1714/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg new file mode 100644 index 000000000..1e3990b91 Binary files /dev/null and b/pr-1714/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg differ diff --git a/pr-1714/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg b/pr-1714/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg new file mode 100644 index 000000000..3c863a9ed Binary files /dev/null and b/pr-1714/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg differ diff --git a/pr-1714/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png b/pr-1714/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png new file mode 100644 index 000000000..1c7db2667 Binary files /dev/null and b/pr-1714/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png differ diff --git a/pr-1714/assets/images/blog/mark-failfast1-076157dd.png b/pr-1714/assets/images/blog/mark-failfast1-076157dd.png new file mode 100644 index 000000000..d851e5dd5 Binary files /dev/null and b/pr-1714/assets/images/blog/mark-failfast1-076157dd.png differ diff --git a/pr-1714/assets/images/blog/mark-failfast2-39e40b5e.png b/pr-1714/assets/images/blog/mark-failfast2-39e40b5e.png new file mode 100644 index 000000000..078a0f7c9 Binary files /dev/null and b/pr-1714/assets/images/blog/mark-failfast2-39e40b5e.png differ diff --git a/pr-1714/assets/images/blog/mark-failfast3-3b0c6e47.png b/pr-1714/assets/images/blog/mark-failfast3-3b0c6e47.png new file mode 100644 index 000000000..726713e76 Binary files /dev/null and b/pr-1714/assets/images/blog/mark-failfast3-3b0c6e47.png differ diff --git a/pr-1714/assets/images/blog/mark-failfast4-af0026ee.png b/pr-1714/assets/images/blog/mark-failfast4-af0026ee.png new file mode 100644 index 000000000..ce1355e10 Binary files /dev/null and b/pr-1714/assets/images/blog/mark-failfast4-af0026ee.png differ diff --git a/pr-1714/assets/images/blog/mark-failfast5-d9d38b33.png b/pr-1714/assets/images/blog/mark-failfast5-d9d38b33.png new file mode 100644 index 000000000..0db8f585a Binary files /dev/null and b/pr-1714/assets/images/blog/mark-failfast5-d9d38b33.png differ diff --git a/pr-1714/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd-d04ddb52.jpg b/pr-1714/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd-d04ddb52.jpg new file mode 100644 index 000000000..2f1db818a Binary files /dev/null and b/pr-1714/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd-d04ddb52.jpg differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/CD-pipeline-f6e59dd8.png b/pr-1714/assets/images/blog/mobile-app-cd-gocd/CD-pipeline-f6e59dd8.png new file mode 100644 index 000000000..a8c5d600a Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/CD-pipeline-f6e59dd8.png differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png b/pr-1714/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png new file mode 100644 index 000000000..afa608757 Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/breaking-down-monolith-tests-c699a617.png b/pr-1714/assets/images/blog/mobile-app-cd-gocd/breaking-down-monolith-tests-c699a617.png new file mode 100644 index 000000000..da8f19d6d Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/breaking-down-monolith-tests-c699a617.png differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/gocd-labels-601cf430.png b/pr-1714/assets/images/blog/mobile-app-cd-gocd/gocd-labels-601cf430.png new file mode 100644 index 000000000..834158421 Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/gocd-labels-601cf430.png differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/mobile-gocd-hero-7e8b965c.jpg b/pr-1714/assets/images/blog/mobile-app-cd-gocd/mobile-gocd-hero-7e8b965c.jpg new file mode 100644 index 000000000..57032b04d Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/mobile-gocd-hero-7e8b965c.jpg differ diff --git a/pr-1714/assets/images/blog/mobile-app-cd-gocd/sonarqube-quality-96da80f3.png b/pr-1714/assets/images/blog/mobile-app-cd-gocd/sonarqube-quality-96da80f3.png new file mode 100644 index 000000000..3db64407e Binary files /dev/null and b/pr-1714/assets/images/blog/mobile-app-cd-gocd/sonarqube-quality-96da80f3.png differ diff --git a/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/affinitywall-3a2cf6af.jpg b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/affinitywall-3a2cf6af.jpg new file mode 100644 index 000000000..2aa881aab Binary files /dev/null and b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/affinitywall-3a2cf6af.jpg differ diff --git a/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/delivery-wordcloud-6fd91655.jpg b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/delivery-wordcloud-6fd91655.jpg new file mode 100644 index 000000000..5a4cd8a92 Binary files /dev/null and b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/delivery-wordcloud-6fd91655.jpg differ diff --git a/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/deployment-wordcloud-5df3e112.jpg b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/deployment-wordcloud-5df3e112.jpg new file mode 100644 index 000000000..78d6c5549 Binary files /dev/null and b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/deployment-wordcloud-5df3e112.jpg differ diff --git a/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/no-one-can-agree-ci-cd-hero-693779a7.jpg b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/no-one-can-agree-ci-cd-hero-693779a7.jpg new file mode 100644 index 000000000..d580b84f6 Binary files /dev/null and b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/no-one-can-agree-ci-cd-hero-693779a7.jpg differ diff --git a/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/tools-5f584a98.jpg b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/tools-5f584a98.jpg new file mode 100644 index 000000000..708a58e75 Binary files /dev/null and b/pr-1714/assets/images/blog/no-one-agrees-define-ci-cd/tools-5f584a98.jpg differ diff --git a/pr-1714/assets/images/blog/pipeline-pattern-info/deployment-pipeline-pattern-infographic-3156c1d7.png b/pr-1714/assets/images/blog/pipeline-pattern-info/deployment-pipeline-pattern-infographic-3156c1d7.png new file mode 100644 index 000000000..6b602ef01 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-pattern-info/deployment-pipeline-pattern-infographic-3156c1d7.png differ diff --git a/pr-1714/assets/images/blog/pipeline-pattern-info/pipeline-pattern-info-hero-ab1ff875.png b/pr-1714/assets/images/blog/pipeline-pattern-info/pipeline-pattern-info-hero-ab1ff875.png new file mode 100644 index 000000000..656149b20 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-pattern-info/pipeline-pattern-info-hero-ab1ff875.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png b/pr-1714/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png new file mode 100644 index 000000000..b642855eb Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png b/pr-1714/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png new file mode 100644 index 000000000..948d21373 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png b/pr-1714/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png new file mode 100644 index 000000000..acd664400 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png b/pr-1714/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png new file mode 100644 index 000000000..dd50167b0 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png b/pr-1714/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png new file mode 100644 index 000000000..5b65446b7 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png differ diff --git a/pr-1714/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png b/pr-1714/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png new file mode 100644 index 000000000..a9db07269 Binary files /dev/null and b/pr-1714/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png differ diff --git a/pr-1714/assets/images/blog/pipelines-as-code/pipelines-as-code-hero-a3209f2b.jpg b/pr-1714/assets/images/blog/pipelines-as-code/pipelines-as-code-hero-a3209f2b.jpg new file mode 100644 index 000000000..07f767a86 Binary files /dev/null and b/pr-1714/assets/images/blog/pipelines-as-code/pipelines-as-code-hero-a3209f2b.jpg differ diff --git a/pr-1714/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png b/pr-1714/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png new file mode 100644 index 000000000..1ad5413e0 Binary files /dev/null and b/pr-1714/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png differ diff --git a/pr-1714/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png b/pr-1714/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png new file mode 100644 index 000000000..64241d1c6 Binary files /dev/null and b/pr-1714/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png differ diff --git a/pr-1714/assets/images/blog/plugin-settings/list-plugin-37a71798.png b/pr-1714/assets/images/blog/plugin-settings/list-plugin-37a71798.png new file mode 100644 index 000000000..dffb7fa84 Binary files /dev/null and b/pr-1714/assets/images/blog/plugin-settings/list-plugin-37a71798.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/go-cd-after-devops-a582c350.png b/pr-1714/assets/images/blog/product-manager-guide/go-cd-after-devops-a582c350.png new file mode 100644 index 000000000..63663f50c Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/go-cd-after-devops-a582c350.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/go-cd-before-devops-e2b4d0e9.png b/pr-1714/assets/images/blog/product-manager-guide/go-cd-before-devops-e2b4d0e9.png new file mode 100644 index 000000000..856a14177 Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/go-cd-before-devops-e2b4d0e9.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-delivery-6041ff84.png b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-delivery-6041ff84.png new file mode 100644 index 000000000..08b1a6bf1 Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-delivery-6041ff84.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-deployment-4d9c957d.png b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-deployment-4d9c957d.png new file mode 100644 index 000000000..bb297375d Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-deployment-4d9c957d.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-integration-0f4a50c1.png b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-integration-0f4a50c1.png new file mode 100644 index 000000000..2cde6ab15 Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/go-cd-continuous-integration-0f4a50c1.png differ diff --git a/pr-1714/assets/images/blog/product-manager-guide/product-manager-guide-hero-f291ec0f.jpg b/pr-1714/assets/images/blog/product-manager-guide/product-manager-guide-hero-f291ec0f.jpg new file mode 100644 index 000000000..b8ebb88b2 Binary files /dev/null and b/pr-1714/assets/images/blog/product-manager-guide/product-manager-guide-hero-f291ec0f.jpg differ diff --git a/pr-1714/assets/images/blog/replacing-gocd/replacing-gocd-with-gocd-c2db4202.jpg b/pr-1714/assets/images/blog/replacing-gocd/replacing-gocd-with-gocd-c2db4202.jpg new file mode 100644 index 000000000..eb20efbf7 Binary files /dev/null and b/pr-1714/assets/images/blog/replacing-gocd/replacing-gocd-with-gocd-c2db4202.jpg differ diff --git a/pr-1714/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg b/pr-1714/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg new file mode 100644 index 000000000..360f3ef88 Binary files /dev/null and b/pr-1714/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg differ diff --git a/pr-1714/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg b/pr-1714/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg new file mode 100644 index 000000000..6841c7245 Binary files /dev/null and b/pr-1714/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg differ diff --git a/pr-1714/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg b/pr-1714/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg new file mode 100644 index 000000000..200e35ef2 Binary files /dev/null and b/pr-1714/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg differ diff --git a/pr-1714/assets/images/blog/run-x-instance/1-021212d2.png b/pr-1714/assets/images/blog/run-x-instance/1-021212d2.png new file mode 100644 index 000000000..2d4653c14 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/1-021212d2.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/10-fe33e252.png b/pr-1714/assets/images/blog/run-x-instance/10-fe33e252.png new file mode 100644 index 000000000..f7551e901 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/10-fe33e252.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/11-1-b8855dee.png b/pr-1714/assets/images/blog/run-x-instance/11-1-b8855dee.png new file mode 100644 index 000000000..090b05452 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/11-1-b8855dee.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/11-2-19aa7f49.png b/pr-1714/assets/images/blog/run-x-instance/11-2-19aa7f49.png new file mode 100644 index 000000000..b258deec5 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/11-2-19aa7f49.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/2-9cb7bf31.png b/pr-1714/assets/images/blog/run-x-instance/2-9cb7bf31.png new file mode 100644 index 000000000..a9b9c73a0 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/2-9cb7bf31.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/3-41b700d0.png b/pr-1714/assets/images/blog/run-x-instance/3-41b700d0.png new file mode 100644 index 000000000..a13fb5584 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/3-41b700d0.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/4-2-53ddc6c0.png b/pr-1714/assets/images/blog/run-x-instance/4-2-53ddc6c0.png new file mode 100644 index 000000000..d0063fc36 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/4-2-53ddc6c0.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/4-9650ff39.png b/pr-1714/assets/images/blog/run-x-instance/4-9650ff39.png new file mode 100644 index 000000000..c0290f046 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/4-9650ff39.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/5-6da0dd74.png b/pr-1714/assets/images/blog/run-x-instance/5-6da0dd74.png new file mode 100644 index 000000000..724f1c4a8 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/5-6da0dd74.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/6-40adc5ae.png b/pr-1714/assets/images/blog/run-x-instance/6-40adc5ae.png new file mode 100644 index 000000000..52f19638f Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/6-40adc5ae.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/7-016f6a36.png b/pr-1714/assets/images/blog/run-x-instance/7-016f6a36.png new file mode 100644 index 000000000..b4250130e Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/7-016f6a36.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/8-b478f0af.png b/pr-1714/assets/images/blog/run-x-instance/8-b478f0af.png new file mode 100644 index 000000000..2e2cc3e5b Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/8-b478f0af.png differ diff --git a/pr-1714/assets/images/blog/run-x-instance/9-9d8fd047.png b/pr-1714/assets/images/blog/run-x-instance/9-9d8fd047.png new file mode 100644 index 000000000..1cca36754 Binary files /dev/null and b/pr-1714/assets/images/blog/run-x-instance/9-9d8fd047.png differ diff --git a/pr-1714/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png b/pr-1714/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png new file mode 100644 index 000000000..4ca6957ef Binary files /dev/null and b/pr-1714/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png differ diff --git a/pr-1714/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png b/pr-1714/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png new file mode 100644 index 000000000..4e6465ba5 Binary files /dev/null and b/pr-1714/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png differ diff --git a/pr-1714/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png b/pr-1714/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png new file mode 100644 index 000000000..8ee61cbf8 Binary files /dev/null and b/pr-1714/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png differ diff --git a/pr-1714/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png b/pr-1714/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png new file mode 100644 index 000000000..861ca8e5b Binary files /dev/null and b/pr-1714/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png differ diff --git a/pr-1714/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png b/pr-1714/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png new file mode 100644 index 000000000..1dd7fcf06 Binary files /dev/null and b/pr-1714/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png differ diff --git a/pr-1714/assets/images/blog/security-devops-minimizing-risk/security-devops-hero-3e9a0f07.jpg b/pr-1714/assets/images/blog/security-devops-minimizing-risk/security-devops-hero-3e9a0f07.jpg new file mode 100644 index 000000000..0e21d910e Binary files /dev/null and b/pr-1714/assets/images/blog/security-devops-minimizing-risk/security-devops-hero-3e9a0f07.jpg differ diff --git a/pr-1714/assets/images/blog/serverless-continuous-delivery/serverless-continuous-delivery-hero-4a1b2ac1.jpg b/pr-1714/assets/images/blog/serverless-continuous-delivery/serverless-continuous-delivery-hero-4a1b2ac1.jpg new file mode 100644 index 000000000..f074bb663 Binary files /dev/null and b/pr-1714/assets/images/blog/serverless-continuous-delivery/serverless-continuous-delivery-hero-4a1b2ac1.jpg differ diff --git a/pr-1714/assets/images/blog/serverless-continuous-delivery/traditional-vs-serverless-ee2afc44.jpeg b/pr-1714/assets/images/blog/serverless-continuous-delivery/traditional-vs-serverless-ee2afc44.jpeg new file mode 100644 index 000000000..b47dccd1e Binary files /dev/null and b/pr-1714/assets/images/blog/serverless-continuous-delivery/traditional-vs-serverless-ee2afc44.jpeg differ diff --git a/pr-1714/assets/images/blog/set-up-a-go-dev-environment/summary_image-33c07d56.png b/pr-1714/assets/images/blog/set-up-a-go-dev-environment/summary_image-33c07d56.png new file mode 100644 index 000000000..cadbc3110 Binary files /dev/null and b/pr-1714/assets/images/blog/set-up-a-go-dev-environment/summary_image-33c07d56.png differ diff --git a/pr-1714/assets/images/blog/source-code-for-go-now-available/summary_image-05a17ee5.png b/pr-1714/assets/images/blog/source-code-for-go-now-available/summary_image-05a17ee5.png new file mode 100644 index 000000000..e2732d67b Binary files /dev/null and b/pr-1714/assets/images/blog/source-code-for-go-now-available/summary_image-05a17ee5.png differ diff --git a/pr-1714/assets/images/blog/sriram-buildpromo1-1cbd5825.png b/pr-1714/assets/images/blog/sriram-buildpromo1-1cbd5825.png new file mode 100644 index 000000000..47f168c3a Binary files /dev/null and b/pr-1714/assets/images/blog/sriram-buildpromo1-1cbd5825.png differ diff --git a/pr-1714/assets/images/blog/sriram-package1-8fa6fb41.png b/pr-1714/assets/images/blog/sriram-package1-8fa6fb41.png new file mode 100644 index 000000000..98fa5f33b Binary files /dev/null and b/pr-1714/assets/images/blog/sriram-package1-8fa6fb41.png differ diff --git a/pr-1714/assets/images/blog/sriram-peg1_0-6dafffb1.png b/pr-1714/assets/images/blog/sriram-peg1_0-6dafffb1.png new file mode 100644 index 000000000..45cd67f1b Binary files /dev/null and b/pr-1714/assets/images/blog/sriram-peg1_0-6dafffb1.png differ diff --git a/pr-1714/assets/images/blog/sriram-peg2-9f490080.png b/pr-1714/assets/images/blog/sriram-peg2-9f490080.png new file mode 100644 index 000000000..c80661ab4 Binary files /dev/null and b/pr-1714/assets/images/blog/sriram-peg2-9f490080.png differ diff --git a/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg b/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg new file mode 100644 index 000000000..2f8aad74d Binary files /dev/null and b/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg differ diff --git a/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg b/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg new file mode 100644 index 000000000..8eb9f38eb Binary files /dev/null and b/pr-1714/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg differ diff --git a/pr-1714/assets/images/blog/tracingprod1-1c3ed7f0.png b/pr-1714/assets/images/blog/tracingprod1-1c3ed7f0.png new file mode 100644 index 000000000..69da4fa38 Binary files /dev/null and b/pr-1714/assets/images/blog/tracingprod1-1c3ed7f0.png differ diff --git a/pr-1714/assets/images/blog/upcoming-API-changes/summary_image-40154615.png b/pr-1714/assets/images/blog/upcoming-API-changes/summary_image-40154615.png new file mode 100644 index 000000000..107f702df Binary files /dev/null and b/pr-1714/assets/images/blog/upcoming-API-changes/summary_image-40154615.png differ diff --git a/pr-1714/assets/images/blog/using-go-cd-with-custom-certificates/summary_image-55b6cd48.png b/pr-1714/assets/images/blog/using-go-cd-with-custom-certificates/summary_image-55b6cd48.png new file mode 100644 index 000000000..43b00eac3 Binary files /dev/null and b/pr-1714/assets/images/blog/using-go-cd-with-custom-certificates/summary_image-55b6cd48.png differ diff --git a/pr-1714/assets/images/blog/using-windows-powershell-tasks/PowerShell_5.0_icon-af7bd014.png b/pr-1714/assets/images/blog/using-windows-powershell-tasks/PowerShell_5.0_icon-af7bd014.png new file mode 100644 index 000000000..789bf7228 Binary files /dev/null and b/pr-1714/assets/images/blog/using-windows-powershell-tasks/PowerShell_5.0_icon-af7bd014.png differ diff --git a/pr-1714/assets/images/blog/using-windows-powershell-tasks/SOURCE_LOCATION.txt b/pr-1714/assets/images/blog/using-windows-powershell-tasks/SOURCE_LOCATION.txt new file mode 100644 index 000000000..434cb1aeb --- /dev/null +++ b/pr-1714/assets/images/blog/using-windows-powershell-tasks/SOURCE_LOCATION.txt @@ -0,0 +1,2 @@ +Location: https://upload.wikimedia.org/wikipedia/commons/2/2f/PowerShell_5.0_icon.png +Licence: Public Domain diff --git a/pr-1714/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png new file mode 100644 index 000000000..b8f399ae6 Binary files /dev/null and b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png differ diff --git a/pr-1714/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png new file mode 100644 index 000000000..300674f5d Binary files /dev/null and b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png differ diff --git a/pr-1714/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png new file mode 100644 index 000000000..21b3f0278 Binary files /dev/null and b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png differ diff --git a/pr-1714/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png new file mode 100644 index 000000000..e8d67a7bf Binary files /dev/null and b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png differ diff --git a/pr-1714/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png new file mode 100644 index 000000000..17f7f1987 Binary files /dev/null and b/pr-1714/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png differ diff --git a/pr-1714/assets/images/blog/whats-new-gocd/gocd-analytics-vsm-a734be3e.png b/pr-1714/assets/images/blog/whats-new-gocd/gocd-analytics-vsm-a734be3e.png new file mode 100644 index 000000000..7ba167d3b Binary files /dev/null and b/pr-1714/assets/images/blog/whats-new-gocd/gocd-analytics-vsm-a734be3e.png differ diff --git a/pr-1714/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif b/pr-1714/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif new file mode 100644 index 000000000..675e5db8a Binary files /dev/null and b/pr-1714/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif differ diff --git a/pr-1714/assets/images/blog/whats-new-gocd/gocd-java-licensing-30168501.jpg b/pr-1714/assets/images/blog/whats-new-gocd/gocd-java-licensing-30168501.jpg new file mode 100644 index 000000000..a9c26d0e7 Binary files /dev/null and b/pr-1714/assets/images/blog/whats-new-gocd/gocd-java-licensing-30168501.jpg differ diff --git a/pr-1714/assets/images/blog/whats-new-gocd/gocd-new-features-99a2019c.jpg b/pr-1714/assets/images/blog/whats-new-gocd/gocd-new-features-99a2019c.jpg new file mode 100644 index 000000000..48d60a9bf Binary files /dev/null and b/pr-1714/assets/images/blog/whats-new-gocd/gocd-new-features-99a2019c.jpg differ diff --git a/pr-1714/assets/images/blog/why-we-moved-from-go-cd-to-gocd-io/please-standy-by-8a8b64b2.jpg b/pr-1714/assets/images/blog/why-we-moved-from-go-cd-to-gocd-io/please-standy-by-8a8b64b2.jpg new file mode 100644 index 000000000..d3c5beee5 Binary files /dev/null and b/pr-1714/assets/images/blog/why-we-moved-from-go-cd-to-gocd-io/please-standy-by-8a8b64b2.jpg differ diff --git a/pr-1714/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg b/pr-1714/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg new file mode 100644 index 000000000..0e635e7ad Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg differ diff --git a/pr-1714/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg b/pr-1714/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg new file mode 100644 index 000000000..0573132eb Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg differ diff --git a/pr-1714/assets/images/campaign/analytics/pipeline1-8ac70cb4.png b/pr-1714/assets/images/campaign/analytics/pipeline1-8ac70cb4.png new file mode 100644 index 000000000..33860d10a Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/pipeline1-8ac70cb4.png differ diff --git a/pr-1714/assets/images/campaign/analytics/util1-fb757c80.png b/pr-1714/assets/images/campaign/analytics/util1-fb757c80.png new file mode 100644 index 000000000..9e9c376ac Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/util1-fb757c80.png differ diff --git a/pr-1714/assets/images/campaign/analytics/vsm1-13668439.jpg b/pr-1714/assets/images/campaign/analytics/vsm1-13668439.jpg new file mode 100644 index 000000000..e65056dad Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/vsm1-13668439.jpg differ diff --git a/pr-1714/assets/images/campaign/analytics/waittime1-7b27dbc4.png b/pr-1714/assets/images/campaign/analytics/waittime1-7b27dbc4.png new file mode 100644 index 000000000..ce301d788 Binary files /dev/null and b/pr-1714/assets/images/campaign/analytics/waittime1-7b27dbc4.png differ diff --git a/pr-1714/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg b/pr-1714/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg new file mode 100644 index 000000000..e175a6db4 Binary files /dev/null and b/pr-1714/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg differ diff --git a/pr-1714/assets/images/campaign/cd101/cd101-banner-4869e4af.png b/pr-1714/assets/images/campaign/cd101/cd101-banner-4869e4af.png new file mode 100644 index 000000000..a84c05f15 Binary files /dev/null and b/pr-1714/assets/images/campaign/cd101/cd101-banner-4869e4af.png differ diff --git a/pr-1714/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png b/pr-1714/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png new file mode 100644 index 000000000..a0a4dc9ad Binary files /dev/null and b/pr-1714/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png differ diff --git a/pr-1714/assets/images/campaign/cd101/cd101-banner2-fed55b97.png b/pr-1714/assets/images/campaign/cd101/cd101-banner2-fed55b97.png new file mode 100644 index 000000000..9fb71b42f Binary files /dev/null and b/pr-1714/assets/images/campaign/cd101/cd101-banner2-fed55b97.png differ diff --git a/pr-1714/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf b/pr-1714/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf new file mode 100644 index 000000000..252878b03 Binary files /dev/null and b/pr-1714/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf differ diff --git a/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-analytics-banner-6764ab2f.jpg b/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-analytics-banner-6764ab2f.jpg new file mode 100644 index 000000000..9287f482f Binary files /dev/null and b/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-analytics-banner-6764ab2f.jpg differ diff --git a/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf b/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf new file mode 100644 index 000000000..be7f0ea77 Binary files /dev/null and b/pr-1714/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf differ diff --git a/pr-1714/assets/images/campaign/ebook-cd-analytics/w-analytics-mockup-c8c186cc.png b/pr-1714/assets/images/campaign/ebook-cd-analytics/w-analytics-mockup-c8c186cc.png new file mode 100644 index 000000000..71fbfd8c5 Binary files /dev/null and b/pr-1714/assets/images/campaign/ebook-cd-analytics/w-analytics-mockup-c8c186cc.png differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg b/pr-1714/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg new file mode 100644 index 000000000..e6f10cbea Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_1-be2fe817.png b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_1-be2fe817.png new file mode 100644 index 000000000..401273fbe Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_1-be2fe817.png differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_2-95655f15.png b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_2-95655f15.png new file mode 100644 index 000000000..68c713ef8 Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_2-95655f15.png differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_3-59bccaf1.png b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_3-59bccaf1.png new file mode 100644 index 000000000..29e8352cc Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/771-spot_illo_3-59bccaf1.png differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg b/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg new file mode 100644 index 000000000..9c70b4ff2 Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg b/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg new file mode 100644 index 000000000..9ba6512fe Binary files /dev/null and b/pr-1714/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg differ diff --git a/pr-1714/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg b/pr-1714/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg new file mode 100644 index 000000000..c0fd3633d --- /dev/null +++ b/pr-1714/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg @@ -0,0 +1,37 @@ + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg b/pr-1714/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg new file mode 100644 index 000000000..4630ea996 --- /dev/null +++ b/pr-1714/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg b/pr-1714/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg new file mode 100644 index 000000000..f0237be30 --- /dev/null +++ b/pr-1714/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg @@ -0,0 +1,13 @@ + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/adblock-6fed935d.svg b/pr-1714/assets/images/campaign/enterprise/adblock-6fed935d.svg new file mode 100644 index 000000000..dc4932082 --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/adblock-6fed935d.svg @@ -0,0 +1,32 @@ + + Asset 1 + + + + + + + + + + + + + + + + + + + + + + + + Please turn offadblockersto see oursignup form. + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/business-611be55b.svg b/pr-1714/assets/images/campaign/enterprise/business-611be55b.svg new file mode 100644 index 000000000..ed3cea77b --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/business-611be55b.svg @@ -0,0 +1,29 @@ + + + + + + + + + + + + + + + 870-business copy 3 + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg b/pr-1714/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg new file mode 100644 index 000000000..6c8eed045 Binary files /dev/null and b/pr-1714/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg differ diff --git a/pr-1714/assets/images/campaign/enterprise/ec2-b607824f.svg b/pr-1714/assets/images/campaign/enterprise/ec2-b607824f.svg new file mode 100644 index 000000000..3fc4c9c90 --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/ec2-b607824f.svg @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + + + + + ec2 + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg new file mode 100644 index 000000000..0462ff0a6 Binary files /dev/null and b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg differ diff --git a/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg new file mode 100644 index 000000000..dc21be161 Binary files /dev/null and b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg differ diff --git a/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg new file mode 100644 index 000000000..4e13cc62b Binary files /dev/null and b/pr-1714/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg differ diff --git a/pr-1714/assets/images/campaign/enterprise/postgres-82a803cd.svg b/pr-1714/assets/images/campaign/enterprise/postgres-82a803cd.svg new file mode 100644 index 000000000..33109b15a --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/postgres-82a803cd.svg @@ -0,0 +1,21 @@ + + + + + + + + + + 870-postgres copy 2 + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/security-2897cd2a.svg b/pr-1714/assets/images/campaign/enterprise/security-2897cd2a.svg new file mode 100644 index 000000000..f7da9ee26 --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/security-2897cd2a.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + security + + + diff --git a/pr-1714/assets/images/campaign/enterprise/support-8ca9a904.svg b/pr-1714/assets/images/campaign/enterprise/support-8ca9a904.svg new file mode 100644 index 000000000..dcbc61f57 --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/support-8ca9a904.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + + + + 870-support copy + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg b/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg new file mode 100644 index 000000000..1260c24ba --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg @@ -0,0 +1,665 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg b/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg new file mode 100644 index 000000000..c80bb4208 --- /dev/null +++ b/pr-1714/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg @@ -0,0 +1,507 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg b/pr-1714/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg new file mode 100644 index 000000000..53974d766 Binary files /dev/null and b/pr-1714/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg differ diff --git a/pr-1714/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg b/pr-1714/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg new file mode 100644 index 000000000..8070fb74b Binary files /dev/null and b/pr-1714/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg differ diff --git a/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg b/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg new file mode 100644 index 000000000..3d7db9347 Binary files /dev/null and b/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg differ diff --git a/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg b/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg new file mode 100644 index 000000000..76c3c22e1 Binary files /dev/null and b/pr-1714/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg differ diff --git a/pr-1714/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg b/pr-1714/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg new file mode 100644 index 000000000..e8d1b07ac --- /dev/null +++ b/pr-1714/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg @@ -0,0 +1,248 @@ + + + + + + + + + + + + + + + + + + + 890-K8_ILLO_outline_revision + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg b/pr-1714/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg new file mode 100644 index 000000000..457c59e02 --- /dev/null +++ b/pr-1714/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg @@ -0,0 +1,508 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg b/pr-1714/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg new file mode 100644 index 000000000..fb4b754b5 Binary files /dev/null and b/pr-1714/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg differ diff --git a/pr-1714/assets/images/contact-section-background-a4da15b4.jpg b/pr-1714/assets/images/contact-section-background-a4da15b4.jpg new file mode 100644 index 000000000..3f4be8af0 Binary files /dev/null and b/pr-1714/assets/images/contact-section-background-a4da15b4.jpg differ diff --git a/pr-1714/assets/images/customer-logos/ancestry-fa92ee57.jpg b/pr-1714/assets/images/customer-logos/ancestry-fa92ee57.jpg new file mode 100644 index 000000000..ff80d0089 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/ancestry-fa92ee57.jpg differ diff --git a/pr-1714/assets/images/customer-logos/autotrader-4dec0c58.jpg b/pr-1714/assets/images/customer-logos/autotrader-4dec0c58.jpg new file mode 100644 index 000000000..c64c1f7b2 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/autotrader-4dec0c58.jpg differ diff --git a/pr-1714/assets/images/customer-logos/barclaycard-86f6dd22.jpg b/pr-1714/assets/images/customer-logos/barclaycard-86f6dd22.jpg new file mode 100644 index 000000000..cf62a4422 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/barclaycard-86f6dd22.jpg differ diff --git a/pr-1714/assets/images/customer-logos/bt-fe7c6f66.jpg b/pr-1714/assets/images/customer-logos/bt-fe7c6f66.jpg new file mode 100644 index 000000000..997027771 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/bt-fe7c6f66.jpg differ diff --git a/pr-1714/assets/images/customer-logos/haufe-e5b70aab.jpg b/pr-1714/assets/images/customer-logos/haufe-e5b70aab.jpg new file mode 100644 index 000000000..e947993e8 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/haufe-e5b70aab.jpg differ diff --git a/pr-1714/assets/images/customer-logos/hoovers-80eda3f2.jpg b/pr-1714/assets/images/customer-logos/hoovers-80eda3f2.jpg new file mode 100644 index 000000000..ea8bcd575 Binary files /dev/null and b/pr-1714/assets/images/customer-logos/hoovers-80eda3f2.jpg differ diff --git a/pr-1714/assets/images/customer-logos/medidata-b4b4285b.jpg b/pr-1714/assets/images/customer-logos/medidata-b4b4285b.jpg new file mode 100644 index 000000000..0a004e91c Binary files /dev/null and b/pr-1714/assets/images/customer-logos/medidata-b4b4285b.jpg differ diff --git a/pr-1714/assets/images/customer-logos/nike-8f9e91cd.jpg b/pr-1714/assets/images/customer-logos/nike-8f9e91cd.jpg new file mode 100644 index 000000000..9e70f7acb Binary files /dev/null and b/pr-1714/assets/images/customer-logos/nike-8f9e91cd.jpg differ diff --git a/pr-1714/assets/images/deploy-any-version-d66b0f45.png b/pr-1714/assets/images/deploy-any-version-d66b0f45.png new file mode 100644 index 000000000..9df3e1cfe Binary files /dev/null and b/pr-1714/assets/images/deploy-any-version-d66b0f45.png differ diff --git a/pr-1714/assets/images/dld-deb-c037d30e.svg b/pr-1714/assets/images/dld-deb-c037d30e.svg new file mode 100644 index 000000000..554542829 --- /dev/null +++ b/pr-1714/assets/images/dld-deb-c037d30e.svg @@ -0,0 +1 @@ +Asset 7 \ No newline at end of file diff --git a/pr-1714/assets/images/dld-docker-54779d1e.svg b/pr-1714/assets/images/dld-docker-54779d1e.svg new file mode 100644 index 000000000..fc54ed5ca --- /dev/null +++ b/pr-1714/assets/images/dld-docker-54779d1e.svg @@ -0,0 +1,13 @@ + + + + + + + + + + + + + \ No newline at end of file diff --git a/pr-1714/assets/images/dld-k8s-df3afe16.svg b/pr-1714/assets/images/dld-k8s-df3afe16.svg new file mode 100644 index 000000000..bedd3b88e --- /dev/null +++ b/pr-1714/assets/images/dld-k8s-df3afe16.svg @@ -0,0 +1,84 @@ + + + + + + + + + + image/svg+xml + + + + + + + + + + + + diff --git a/pr-1714/assets/images/dld-osx-cd5f0631.svg b/pr-1714/assets/images/dld-osx-cd5f0631.svg new file mode 100644 index 000000000..97ed91186 --- /dev/null +++ b/pr-1714/assets/images/dld-osx-cd5f0631.svg @@ -0,0 +1,4 @@ + + + + \ No newline at end of file diff --git a/pr-1714/assets/images/dld-rpm-2d7d4dd6.svg b/pr-1714/assets/images/dld-rpm-2d7d4dd6.svg new file mode 100644 index 000000000..9afbec3bf --- /dev/null +++ b/pr-1714/assets/images/dld-rpm-2d7d4dd6.svg @@ -0,0 +1,9 @@ + + + + + + + \ No newline at end of file diff --git a/pr-1714/assets/images/dld-win-fa0f769a.svg b/pr-1714/assets/images/dld-win-fa0f769a.svg new file mode 100644 index 000000000..cbb5e3e1f --- /dev/null +++ b/pr-1714/assets/images/dld-win-fa0f769a.svg @@ -0,0 +1 @@ +Asset 3 \ No newline at end of file diff --git a/pr-1714/assets/images/dld-zip-073204d1.svg b/pr-1714/assets/images/dld-zip-073204d1.svg new file mode 100644 index 000000000..1648bcfdd --- /dev/null +++ b/pr-1714/assets/images/dld-zip-073204d1.svg @@ -0,0 +1 @@ +Asset 6 \ No newline at end of file diff --git a/pr-1714/assets/images/elastic-agents-bg-d6debd33.jpg b/pr-1714/assets/images/elastic-agents-bg-d6debd33.jpg new file mode 100644 index 000000000..0d0b0480c Binary files /dev/null and b/pr-1714/assets/images/elastic-agents-bg-d6debd33.jpg differ diff --git a/pr-1714/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png b/pr-1714/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png new file mode 100644 index 000000000..d6eeb1f6d Binary files /dev/null and b/pr-1714/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png differ diff --git a/pr-1714/assets/images/enterprise-sales-al-aef0859e.jpg b/pr-1714/assets/images/enterprise-sales-al-aef0859e.jpg new file mode 100644 index 000000000..c2ad4200c Binary files /dev/null and b/pr-1714/assets/images/enterprise-sales-al-aef0859e.jpg differ diff --git a/pr-1714/assets/images/enterprise-sales-craig-535f8939.jpg b/pr-1714/assets/images/enterprise-sales-craig-535f8939.jpg new file mode 100644 index 000000000..63bf92ae4 Binary files /dev/null and b/pr-1714/assets/images/enterprise-sales-craig-535f8939.jpg differ diff --git a/pr-1714/assets/images/enterprise-sales-rupesh-67d31c82.jpg b/pr-1714/assets/images/enterprise-sales-rupesh-67d31c82.jpg new file mode 100644 index 000000000..098300c9d Binary files /dev/null and b/pr-1714/assets/images/enterprise-sales-rupesh-67d31c82.jpg differ diff --git a/pr-1714/assets/images/external-link-728fc441.svg b/pr-1714/assets/images/external-link-728fc441.svg new file mode 100644 index 000000000..b18f652ed --- /dev/null +++ b/pr-1714/assets/images/external-link-728fc441.svg @@ -0,0 +1,12 @@ + + + + Slice 1 + Created with Sketch. + + + + + + + \ No newline at end of file diff --git a/pr-1714/assets/images/favicon.ico b/pr-1714/assets/images/favicon.ico new file mode 100644 index 000000000..fab7ad966 Binary files /dev/null and b/pr-1714/assets/images/favicon.ico differ diff --git a/pr-1714/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png b/pr-1714/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png new file mode 100644 index 000000000..e924c0808 Binary files /dev/null and b/pr-1714/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png differ diff --git a/pr-1714/assets/images/getting-started/a-custom-tab-in-action-6bd08a14.png b/pr-1714/assets/images/getting-started/a-custom-tab-in-action-6bd08a14.png new file mode 100644 index 000000000..36400663f Binary files /dev/null and b/pr-1714/assets/images/getting-started/a-custom-tab-in-action-6bd08a14.png differ diff --git a/pr-1714/assets/images/getting-started/adding-a-fetch-artifact-task-143fc605.png b/pr-1714/assets/images/getting-started/adding-a-fetch-artifact-task-143fc605.png new file mode 100644 index 000000000..4100c197c Binary files /dev/null and b/pr-1714/assets/images/getting-started/adding-a-fetch-artifact-task-143fc605.png differ diff --git a/pr-1714/assets/images/getting-started/adding-an-artifact-533dbc7e.png b/pr-1714/assets/images/getting-started/adding-an-artifact-533dbc7e.png new file mode 100644 index 000000000..7fd8b1617 Binary files /dev/null and b/pr-1714/assets/images/getting-started/adding-an-artifact-533dbc7e.png differ diff --git a/pr-1714/assets/images/getting-started/agents-5dab5e8b.png b/pr-1714/assets/images/getting-started/agents-5dab5e8b.png new file mode 100644 index 000000000..271e27e92 Binary files /dev/null and b/pr-1714/assets/images/getting-started/agents-5dab5e8b.png differ diff --git a/pr-1714/assets/images/getting-started/autocompletion-of-the-pipeline-dependency-material-351e8d25.png b/pr-1714/assets/images/getting-started/autocompletion-of-the-pipeline-dependency-material-351e8d25.png new file mode 100644 index 000000000..8771ba955 Binary files /dev/null and b/pr-1714/assets/images/getting-started/autocompletion-of-the-pipeline-dependency-material-351e8d25.png differ diff --git a/pr-1714/assets/images/getting-started/build-pipeline-ae429bf1.png b/pr-1714/assets/images/getting-started/build-pipeline-ae429bf1.png new file mode 100644 index 000000000..af31e2715 Binary files /dev/null and b/pr-1714/assets/images/getting-started/build-pipeline-ae429bf1.png differ diff --git a/pr-1714/assets/images/getting-started/check-that-the-material-exists-dcaf841d.png b/pr-1714/assets/images/getting-started/check-that-the-material-exists-dcaf841d.png new file mode 100644 index 000000000..d09f9dd7b Binary files /dev/null and b/pr-1714/assets/images/getting-started/check-that-the-material-exists-dcaf841d.png differ diff --git a/pr-1714/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png b/pr-1714/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png new file mode 100644 index 000000000..deb79408f Binary files /dev/null and b/pr-1714/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png differ diff --git a/pr-1714/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png b/pr-1714/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png new file mode 100644 index 000000000..fe375090d Binary files /dev/null and b/pr-1714/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png differ diff --git a/pr-1714/assets/images/getting-started/custom-command-ea9f5535.png b/pr-1714/assets/images/getting-started/custom-command-ea9f5535.png new file mode 100644 index 000000000..9dae4b5e4 Binary files /dev/null and b/pr-1714/assets/images/getting-started/custom-command-ea9f5535.png differ diff --git a/pr-1714/assets/images/getting-started/dependent-pipelines-in-a-valuestream-map-06de9ca9.png b/pr-1714/assets/images/getting-started/dependent-pipelines-in-a-valuestream-map-06de9ca9.png new file mode 100644 index 000000000..19a96748a Binary files /dev/null and b/pr-1714/assets/images/getting-started/dependent-pipelines-in-a-valuestream-map-06de9ca9.png differ diff --git a/pr-1714/assets/images/getting-started/dependent-pipelines-on-the-dashboard-4695ac92.png b/pr-1714/assets/images/getting-started/dependent-pipelines-on-the-dashboard-4695ac92.png new file mode 100644 index 000000000..d744ed1c6 Binary files /dev/null and b/pr-1714/assets/images/getting-started/dependent-pipelines-on-the-dashboard-4695ac92.png differ diff --git a/pr-1714/assets/images/getting-started/display-the-contents-of-the-fetched-artifact-6c894245.png b/pr-1714/assets/images/getting-started/display-the-contents-of-the-fetched-artifact-6c894245.png new file mode 100644 index 000000000..c02a421ec Binary files /dev/null and b/pr-1714/assets/images/getting-started/display-the-contents-of-the-fetched-artifact-6c894245.png differ diff --git a/pr-1714/assets/images/getting-started/env-variables-322e76d2.png b/pr-1714/assets/images/getting-started/env-variables-322e76d2.png new file mode 100644 index 000000000..03fe66649 Binary files /dev/null and b/pr-1714/assets/images/getting-started/env-variables-322e76d2.png differ diff --git a/pr-1714/assets/images/getting-started/fetching-artifacts-from-ancestor-pipelines-c5ce9341.png b/pr-1714/assets/images/getting-started/fetching-artifacts-from-ancestor-pipelines-c5ce9341.png new file mode 100644 index 000000000..4127c168b Binary files /dev/null and b/pr-1714/assets/images/getting-started/fetching-artifacts-from-ancestor-pipelines-c5ce9341.png differ diff --git a/pr-1714/assets/images/getting-started/first-pipeline-paused-99e91c88.png b/pr-1714/assets/images/getting-started/first-pipeline-paused-99e91c88.png new file mode 100644 index 000000000..3c5bf0848 Binary files /dev/null and b/pr-1714/assets/images/getting-started/first-pipeline-paused-99e91c88.png differ diff --git a/pr-1714/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png b/pr-1714/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png new file mode 100644 index 000000000..b762a4158 Binary files /dev/null and b/pr-1714/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png differ diff --git a/pr-1714/assets/images/getting-started/image17-dc293a0b.png b/pr-1714/assets/images/getting-started/image17-dc293a0b.png new file mode 100644 index 000000000..e6059bf24 Binary files /dev/null and b/pr-1714/assets/images/getting-started/image17-dc293a0b.png differ diff --git a/pr-1714/assets/images/getting-started/initial-job-and-task-ad6e3eca.png b/pr-1714/assets/images/getting-started/initial-job-and-task-ad6e3eca.png new file mode 100644 index 000000000..67761fd33 Binary files /dev/null and b/pr-1714/assets/images/getting-started/initial-job-and-task-ad6e3eca.png differ diff --git a/pr-1714/assets/images/getting-started/job-output-394d7a4a.png b/pr-1714/assets/images/getting-started/job-output-394d7a4a.png new file mode 100644 index 000000000..664d86299 Binary files /dev/null and b/pr-1714/assets/images/getting-started/job-output-394d7a4a.png differ diff --git a/pr-1714/assets/images/getting-started/job-run-details-b5eacb09.png b/pr-1714/assets/images/getting-started/job-run-details-b5eacb09.png new file mode 100644 index 000000000..ae2d0e19d Binary files /dev/null and b/pr-1714/assets/images/getting-started/job-run-details-b5eacb09.png differ diff --git a/pr-1714/assets/images/getting-started/materials-2a974162.png b/pr-1714/assets/images/getting-started/materials-2a974162.png new file mode 100644 index 000000000..024e22e7b Binary files /dev/null and b/pr-1714/assets/images/getting-started/materials-2a974162.png differ diff --git a/pr-1714/assets/images/getting-started/move-the-fetch-artifact-task-to-the-top-68961f7f.png b/pr-1714/assets/images/getting-started/move-the-fetch-artifact-task-to-the-top-68961f7f.png new file mode 100644 index 000000000..d52ec8e1d Binary files /dev/null and b/pr-1714/assets/images/getting-started/move-the-fetch-artifact-task-to-the-top-68961f7f.png differ diff --git a/pr-1714/assets/images/getting-started/name-your-pipeline-cbbe9c97.png b/pr-1714/assets/images/getting-started/name-your-pipeline-cbbe9c97.png new file mode 100644 index 000000000..195fac0c9 Binary files /dev/null and b/pr-1714/assets/images/getting-started/name-your-pipeline-cbbe9c97.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/10a-pipeline-building-dashboard-c22c699b.png b/pr-1714/assets/images/getting-started/part-1/10a-pipeline-building-dashboard-c22c699b.png new file mode 100644 index 000000000..f29ce7ec2 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/10a-pipeline-building-dashboard-c22c699b.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/11a-pipeline-finished-new-dashboard-91e8dfbe.png b/pr-1714/assets/images/getting-started/part-1/11a-pipeline-finished-new-dashboard-91e8dfbe.png new file mode 100644 index 000000000..2ff08432d Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/11a-pipeline-finished-new-dashboard-91e8dfbe.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/12-information-about-the-stage-21da9f48.png b/pr-1714/assets/images/getting-started/part-1/12-information-about-the-stage-21da9f48.png new file mode 100644 index 000000000..e00eed72d Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/12-information-about-the-stage-21da9f48.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/13-output-of-job-4fce197c.png b/pr-1714/assets/images/getting-started/part-1/13-output-of-job-4fce197c.png new file mode 100644 index 000000000..f09c20dac Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/13-output-of-job-4fce197c.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/14-environment-variables-34b793b1.png b/pr-1714/assets/images/getting-started/part-1/14-environment-variables-34b793b1.png new file mode 100644 index 000000000..e00f8f64b Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/14-environment-variables-34b793b1.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/15-job-run-details-e55dd48f.png b/pr-1714/assets/images/getting-started/part-1/15-job-run-details-e55dd48f.png new file mode 100644 index 000000000..16d7f096a Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/15-job-run-details-e55dd48f.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/1gocd-new-pipeline-page-e94f7b2c.png b/pr-1714/assets/images/getting-started/part-1/1gocd-new-pipeline-page-e94f7b2c.png new file mode 100644 index 000000000..c96a1624c Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/1gocd-new-pipeline-page-e94f7b2c.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/2-agents-page-ee212887.png b/pr-1714/assets/images/getting-started/part-1/2-agents-page-ee212887.png new file mode 100644 index 000000000..2c1953ed5 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/2-agents-page-ee212887.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/3-step-1-a772fe86.png b/pr-1714/assets/images/getting-started/part-1/3-step-1-a772fe86.png new file mode 100644 index 000000000..c3604a7dc Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/3-step-1-a772fe86.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/4-step-2a-9f39d601.png b/pr-1714/assets/images/getting-started/part-1/4-step-2a-9f39d601.png new file mode 100644 index 000000000..08002310f Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/4-step-2a-9f39d601.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/5-step-2b-a50afb00.png b/pr-1714/assets/images/getting-started/part-1/5-step-2b-a50afb00.png new file mode 100644 index 000000000..94bc68c74 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/5-step-2b-a50afb00.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/6-step-3a-7189499d.png b/pr-1714/assets/images/getting-started/part-1/6-step-3a-7189499d.png new file mode 100644 index 000000000..1eba5e0e6 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/6-step-3a-7189499d.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/7-step-3b-9bcde35c.png b/pr-1714/assets/images/getting-started/part-1/7-step-3b-9bcde35c.png new file mode 100644 index 000000000..e220187cc Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/7-step-3b-9bcde35c.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/8-step-3c-1bfdef0f.png b/pr-1714/assets/images/getting-started/part-1/8-step-3c-1bfdef0f.png new file mode 100644 index 000000000..cc76e54c7 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/8-step-3c-1bfdef0f.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/9-pipeline-paused-0facb989.png b/pr-1714/assets/images/getting-started/part-1/9-pipeline-paused-0facb989.png new file mode 100644 index 000000000..4ee27453f Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-1/9-pipeline-paused-0facb989.png differ diff --git a/pr-1714/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg b/pr-1714/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg new file mode 100644 index 000000000..3c0517eb6 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg @@ -0,0 +1,1755 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg b/pr-1714/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg new file mode 100644 index 000000000..ffab0cb77 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg @@ -0,0 +1,127 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg b/pr-1714/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg new file mode 100644 index 000000000..c1d4766b3 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg @@ -0,0 +1,1230 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-2/1-pipeline-configuration-page-08907387.png b/pr-1714/assets/images/getting-started/part-2/1-pipeline-configuration-page-08907387.png new file mode 100644 index 000000000..966d05f8d Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/1-pipeline-configuration-page-08907387.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/10-adding-fetch-artifact-cd85c5b4.png b/pr-1714/assets/images/getting-started/part-2/10-adding-fetch-artifact-cd85c5b4.png new file mode 100644 index 000000000..e03a561f7 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/10-adding-fetch-artifact-cd85c5b4.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/11-details-can-be-autocompleted-3378453b.png b/pr-1714/assets/images/getting-started/part-2/11-details-can-be-autocompleted-3378453b.png new file mode 100644 index 000000000..b7c5c901b Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/11-details-can-be-autocompleted-3378453b.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/12-move-the-fetch-artifact-to-top-18eeeed5.png b/pr-1714/assets/images/getting-started/part-2/12-move-the-fetch-artifact-to-top-18eeeed5.png new file mode 100644 index 000000000..6ee3dc25c Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/12-move-the-fetch-artifact-to-top-18eeeed5.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/13-contents-of-fetch-artifact-d389e3d3.png b/pr-1714/assets/images/getting-started/part-2/13-contents-of-fetch-artifact-d389e3d3.png new file mode 100644 index 000000000..3ed5f1a0c Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/13-contents-of-fetch-artifact-d389e3d3.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/14-tasks-should-look-like-this-b45c1798.png b/pr-1714/assets/images/getting-started/part-2/14-tasks-should-look-like-this-b45c1798.png new file mode 100644 index 000000000..187b99949 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/14-tasks-should-look-like-this-b45c1798.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/15-output-of-fetched-artifact-974958e8.png b/pr-1714/assets/images/getting-started/part-2/15-output-of-fetched-artifact-974958e8.png new file mode 100644 index 000000000..586be166d Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/15-output-of-fetched-artifact-974958e8.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/16-ancestor-artifacts-vsm-142de56a.png b/pr-1714/assets/images/getting-started/part-2/16-ancestor-artifacts-vsm-142de56a.png new file mode 100644 index 000000000..a4ca6e777 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/16-ancestor-artifacts-vsm-142de56a.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/17-fetch-from-ancestor-pipeline-074da703.png b/pr-1714/assets/images/getting-started/part-2/17-fetch-from-ancestor-pipeline-074da703.png new file mode 100644 index 000000000..693b50e05 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/17-fetch-from-ancestor-pipeline-074da703.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/18-custom-tab-configure-e1e878c6.png b/pr-1714/assets/images/getting-started/part-2/18-custom-tab-configure-e1e878c6.png new file mode 100644 index 000000000..6659eb44c Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/18-custom-tab-configure-e1e878c6.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/19-custom-tab-in-action-a2c1dcac.png b/pr-1714/assets/images/getting-started/part-2/19-custom-tab-in-action-a2c1dcac.png new file mode 100644 index 000000000..19a32ae16 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/19-custom-tab-in-action-a2c1dcac.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/2-pipeline-dependency-material-73c42e70.png b/pr-1714/assets/images/getting-started/part-2/2-pipeline-dependency-material-73c42e70.png new file mode 100644 index 000000000..806811852 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/2-pipeline-dependency-material-73c42e70.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/3-autocompletion-pipeline-material-1737f4e3.png b/pr-1714/assets/images/getting-started/part-2/3-autocompletion-pipeline-material-1737f4e3.png new file mode 100644 index 000000000..e748d72e0 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/3-autocompletion-pipeline-material-1737f4e3.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/4-create-downstream-pipeline-ae7713c5.png b/pr-1714/assets/images/getting-started/part-2/4-create-downstream-pipeline-ae7713c5.png new file mode 100644 index 000000000..e5eae05d4 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/4-create-downstream-pipeline-ae7713c5.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/5-dependent-pipeline-dashboard-19905315.png b/pr-1714/assets/images/getting-started/part-2/5-dependent-pipeline-dashboard-19905315.png new file mode 100644 index 000000000..8e79588ba Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/5-dependent-pipeline-dashboard-19905315.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/6-value-stream-map-8a14c25b.png b/pr-1714/assets/images/getting-started/part-2/6-value-stream-map-8a14c25b.png new file mode 100644 index 000000000..48fb464b3 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/6-value-stream-map-8a14c25b.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/7-adding-artifact-977cd8a3.png b/pr-1714/assets/images/getting-started/part-2/7-adding-artifact-977cd8a3.png new file mode 100644 index 000000000..1d6c8f1d0 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/7-adding-artifact-977cd8a3.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/8-artifacts-tab-2a423239.png b/pr-1714/assets/images/getting-started/part-2/8-artifacts-tab-2a423239.png new file mode 100644 index 000000000..42bad3d8b Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/8-artifacts-tab-2a423239.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/9-contents-of-artifact-52748cf0.png b/pr-1714/assets/images/getting-started/part-2/9-contents-of-artifact-52748cf0.png new file mode 100644 index 000000000..97cf9c77c Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-2/9-contents-of-artifact-52748cf0.png differ diff --git a/pr-1714/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg b/pr-1714/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg new file mode 100644 index 000000000..bed1e9da2 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg @@ -0,0 +1,181 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-3/1-gateways-to-vsm-0e9d70b0.png b/pr-1714/assets/images/getting-started/part-3/1-gateways-to-vsm-0e9d70b0.png new file mode 100644 index 000000000..f7fa62ad6 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-3/1-gateways-to-vsm-0e9d70b0.png differ diff --git a/pr-1714/assets/images/getting-started/part-3/2-vsm-of-production-pipeline-80c78046.png b/pr-1714/assets/images/getting-started/part-3/2-vsm-of-production-pipeline-80c78046.png new file mode 100644 index 000000000..bf0d7b455 Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-3/2-vsm-of-production-pipeline-80c78046.png differ diff --git a/pr-1714/assets/images/getting-started/part-3/3-vsm-of-build-pipeline-8b12b538.png b/pr-1714/assets/images/getting-started/part-3/3-vsm-of-build-pipeline-8b12b538.png new file mode 100644 index 000000000..705f97f2e Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-3/3-vsm-of-build-pipeline-8b12b538.png differ diff --git a/pr-1714/assets/images/getting-started/part-3/4-pinned-vsm-with-links-8f4c5d92.png b/pr-1714/assets/images/getting-started/part-3/4-pinned-vsm-with-links-8f4c5d92.png new file mode 100644 index 000000000..925f4afdd Binary files /dev/null and b/pr-1714/assets/images/getting-started/part-3/4-pinned-vsm-with-links-8f4c5d92.png differ diff --git a/pr-1714/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg b/pr-1714/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg new file mode 100644 index 000000000..e822ce4c9 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg @@ -0,0 +1,500 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg b/pr-1714/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg new file mode 100644 index 000000000..577859572 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg @@ -0,0 +1,1276 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-3/fan-out-b5681eff.svg b/pr-1714/assets/images/getting-started/part-3/fan-out-b5681eff.svg new file mode 100644 index 000000000..5a0c58be7 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-3/fan-out-b5681eff.svg @@ -0,0 +1,186 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg b/pr-1714/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg new file mode 100644 index 000000000..69163d5e5 --- /dev/null +++ b/pr-1714/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg @@ -0,0 +1,279 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/getting-started/pipeline-3968f530.png b/pr-1714/assets/images/getting-started/pipeline-3968f530.png new file mode 100644 index 000000000..12f2187d3 Binary files /dev/null and b/pr-1714/assets/images/getting-started/pipeline-3968f530.png differ diff --git a/pr-1714/assets/images/getting-started/pipeline-building-17e80a92.png b/pr-1714/assets/images/getting-started/pipeline-building-17e80a92.png new file mode 100644 index 000000000..b0851002f Binary files /dev/null and b/pr-1714/assets/images/getting-started/pipeline-building-17e80a92.png differ diff --git a/pr-1714/assets/images/getting-started/pipeline-finished-6ab859f9.png b/pr-1714/assets/images/getting-started/pipeline-finished-6ab859f9.png new file mode 100644 index 000000000..fd4a8d57d Binary files /dev/null and b/pr-1714/assets/images/getting-started/pipeline-finished-6ab859f9.png differ diff --git a/pr-1714/assets/images/getting-started/production-pipeline-5136d4e0.png b/pr-1714/assets/images/getting-started/production-pipeline-5136d4e0.png new file mode 100644 index 000000000..2674010ab Binary files /dev/null and b/pr-1714/assets/images/getting-started/production-pipeline-5136d4e0.png differ diff --git a/pr-1714/assets/images/getting-started/stage-information-0040c9a6.png b/pr-1714/assets/images/getting-started/stage-information-0040c9a6.png new file mode 100644 index 000000000..ce336a79b Binary files /dev/null and b/pr-1714/assets/images/getting-started/stage-information-0040c9a6.png differ diff --git a/pr-1714/assets/images/getting-started/start-adding-a-pipeline-dependency-material-bb980ccf.png b/pr-1714/assets/images/getting-started/start-adding-a-pipeline-dependency-material-bb980ccf.png new file mode 100644 index 000000000..110086e4b Binary files /dev/null and b/pr-1714/assets/images/getting-started/start-adding-a-pipeline-dependency-material-bb980ccf.png differ diff --git a/pr-1714/assets/images/getting-started/the-artifacts-tab-every-job-will-have-one-44b45466.png b/pr-1714/assets/images/getting-started/the-artifacts-tab-every-job-will-have-one-44b45466.png new file mode 100644 index 000000000..844926ba8 Binary files /dev/null and b/pr-1714/assets/images/getting-started/the-artifacts-tab-every-job-will-have-one-44b45466.png differ diff --git a/pr-1714/assets/images/getting-started/the-contents-of-the-artifact-d796debe.png b/pr-1714/assets/images/getting-started/the-contents-of-the-artifact-d796debe.png new file mode 100644 index 000000000..d3cee28f1 Binary files /dev/null and b/pr-1714/assets/images/getting-started/the-contents-of-the-artifact-d796debe.png differ diff --git a/pr-1714/assets/images/getting-started/the-details-can-be-autocompleted-20f3be0c.png b/pr-1714/assets/images/getting-started/the-details-can-be-autocompleted-20f3be0c.png new file mode 100644 index 000000000..2f1b03495 Binary files /dev/null and b/pr-1714/assets/images/getting-started/the-details-can-be-autocompleted-20f3be0c.png differ diff --git a/pr-1714/assets/images/getting-started/the-output-the-artifact-is-fetched-and-displayed-9191ccc5.png b/pr-1714/assets/images/getting-started/the-output-the-artifact-is-fetched-and-displayed-9191ccc5.png new file mode 100644 index 000000000..9a4a3ae51 Binary files /dev/null and b/pr-1714/assets/images/getting-started/the-output-the-artifact-is-fetched-and-displayed-9191ccc5.png differ diff --git a/pr-1714/assets/images/getting-started/this-is-how-the-tasks-should-look-like-01685645.png b/pr-1714/assets/images/getting-started/this-is-how-the-tasks-should-look-like-01685645.png new file mode 100644 index 000000000..c0e85fd1f Binary files /dev/null and b/pr-1714/assets/images/getting-started/this-is-how-the-tasks-should-look-like-01685645.png differ diff --git a/pr-1714/assets/images/getting-started/this-is-pipeline-06738393.png b/pr-1714/assets/images/getting-started/this-is-pipeline-06738393.png new file mode 100644 index 000000000..1f9230fe9 Binary files /dev/null and b/pr-1714/assets/images/getting-started/this-is-pipeline-06738393.png differ diff --git a/pr-1714/assets/images/getting-started/use-the-predefined-stage-job-62a795ea.png b/pr-1714/assets/images/getting-started/use-the-predefined-stage-job-62a795ea.png new file mode 100644 index 000000000..287132f27 Binary files /dev/null and b/pr-1714/assets/images/getting-started/use-the-predefined-stage-job-62a795ea.png differ diff --git a/pr-1714/assets/images/go-banner-1-904dd546.jpg b/pr-1714/assets/images/go-banner-1-904dd546.jpg new file mode 100644 index 000000000..e1d291f22 Binary files /dev/null and b/pr-1714/assets/images/go-banner-1-904dd546.jpg differ diff --git a/pr-1714/assets/images/go-banner-3de3d3a0.jpg b/pr-1714/assets/images/go-banner-3de3d3a0.jpg new file mode 100644 index 000000000..dab3e010a Binary files /dev/null and b/pr-1714/assets/images/go-banner-3de3d3a0.jpg differ diff --git a/pr-1714/assets/images/go-banner-desktop-aac7fdc4.jpg b/pr-1714/assets/images/go-banner-desktop-aac7fdc4.jpg new file mode 100644 index 000000000..d0d73a258 Binary files /dev/null and b/pr-1714/assets/images/go-banner-desktop-aac7fdc4.jpg differ diff --git a/pr-1714/assets/images/go-banner-phone-30701141.jpg b/pr-1714/assets/images/go-banner-phone-30701141.jpg new file mode 100644 index 000000000..9787df1d9 Binary files /dev/null and b/pr-1714/assets/images/go-banner-phone-30701141.jpg differ diff --git a/pr-1714/assets/images/go-banner-phone.jpg-4b6f8001.png b/pr-1714/assets/images/go-banner-phone.jpg-4b6f8001.png new file mode 100644 index 000000000..ebf18cfdd Binary files /dev/null and b/pr-1714/assets/images/go-banner-phone.jpg-4b6f8001.png differ diff --git a/pr-1714/assets/images/go-banner-tablet-b5881e67.jpg b/pr-1714/assets/images/go-banner-tablet-b5881e67.jpg new file mode 100644 index 000000000..82d853faa Binary files /dev/null and b/pr-1714/assets/images/go-banner-tablet-b5881e67.jpg differ diff --git a/pr-1714/assets/images/go-cd-QA-pipeline-64230cf5.png b/pr-1714/assets/images/go-cd-QA-pipeline-64230cf5.png new file mode 100644 index 000000000..1ef90e235 Binary files /dev/null and b/pr-1714/assets/images/go-cd-QA-pipeline-64230cf5.png differ diff --git a/pr-1714/assets/images/go-gauge-report-54cc286b.png b/pr-1714/assets/images/go-gauge-report-54cc286b.png new file mode 100644 index 000000000..b04a29ea9 Binary files /dev/null and b/pr-1714/assets/images/go-gauge-report-54cc286b.png differ diff --git a/pr-1714/assets/images/go-gauge-specs-3d290b06.png b/pr-1714/assets/images/go-gauge-specs-3d290b06.png new file mode 100644 index 000000000..5c0842b9a Binary files /dev/null and b/pr-1714/assets/images/go-gauge-specs-3d290b06.png differ diff --git a/pr-1714/assets/images/go-logo-small-0cc554b3.png b/pr-1714/assets/images/go-logo-small-0cc554b3.png new file mode 100644 index 000000000..ddb7733ae Binary files /dev/null and b/pr-1714/assets/images/go-logo-small-0cc554b3.png differ diff --git a/pr-1714/assets/images/go.cd_Compare-Builds-33d3164a.svg b/pr-1714/assets/images/go.cd_Compare-Builds-33d3164a.svg new file mode 100644 index 000000000..25085082a --- /dev/null +++ b/pr-1714/assets/images/go.cd_Compare-Builds-33d3164a.svg @@ -0,0 +1,157 @@ + + + + + + + + + + + + + + + + + + + P1.31 + P1.32 + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_Deploy-any-version-anytime-d2db9a66.svg b/pr-1714/assets/images/go.cd_Deploy-any-version-anytime-d2db9a66.svg new file mode 100644 index 000000000..c5d32f9e9 --- /dev/null +++ b/pr-1714/assets/images/go.cd_Deploy-any-version-anytime-d2db9a66.svg @@ -0,0 +1,182 @@ + + + + + + + + + + + + + + + + + + 1 + + . + + 8 + 1 + + . + + 9 + 1 + + . + + 7 + 2 + + . + + 0 + + 1.6 + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_Model-complex-workflows-0eb00251.svg b/pr-1714/assets/images/go.cd_Model-complex-workflows-0eb00251.svg new file mode 100644 index 000000000..425721ddc --- /dev/null +++ b/pr-1714/assets/images/go.cd_Model-complex-workflows-0eb00251.svg @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg b/pr-1714/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg new file mode 100644 index 000000000..466f56e10 --- /dev/null +++ b/pr-1714/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_agent-e1db9f64.png b/pr-1714/assets/images/go.cd_agent-e1db9f64.png new file mode 100644 index 000000000..aaeaad965 Binary files /dev/null and b/pr-1714/assets/images/go.cd_agent-e1db9f64.png differ diff --git a/pr-1714/assets/images/go.cd_blog-about-gocd-cbc119dd.svg b/pr-1714/assets/images/go.cd_blog-about-gocd-cbc119dd.svg new file mode 100644 index 000000000..cc3c2a162 --- /dev/null +++ b/pr-1714/assets/images/go.cd_blog-about-gocd-cbc119dd.svg @@ -0,0 +1,148 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_changes-a75c578f.svg b/pr-1714/assets/images/go.cd_changes-a75c578f.svg new file mode 100644 index 000000000..596838e7d --- /dev/null +++ b/pr-1714/assets/images/go.cd_changes-a75c578f.svg @@ -0,0 +1,138 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_code-5d7d3f74.svg b/pr-1714/assets/images/go.cd_code-5d7d3f74.svg new file mode 100644 index 000000000..7d328e269 --- /dev/null +++ b/pr-1714/assets/images/go.cd_code-5d7d3f74.svg @@ -0,0 +1,138 @@ + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_community-a7895dc9.svg b/pr-1714/assets/images/go.cd_community-a7895dc9.svg new file mode 100644 index 000000000..be3cd24d7 --- /dev/null +++ b/pr-1714/assets/images/go.cd_community-a7895dc9.svg @@ -0,0 +1,176 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_decide-66f54e71.svg b/pr-1714/assets/images/go.cd_decide-66f54e71.svg new file mode 100644 index 000000000..06f19952f --- /dev/null +++ b/pr-1714/assets/images/go.cd_decide-66f54e71.svg @@ -0,0 +1,138 @@ + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_dev-documentation-2f137096.svg b/pr-1714/assets/images/go.cd_dev-documentation-2f137096.svg new file mode 100644 index 000000000..75205b163 --- /dev/null +++ b/pr-1714/assets/images/go.cd_dev-documentation-2f137096.svg @@ -0,0 +1,162 @@ + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg b/pr-1714/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg new file mode 100644 index 000000000..a49b90a66 --- /dev/null +++ b/pr-1714/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_fork-e81f9737.svg b/pr-1714/assets/images/go.cd_fork-e81f9737.svg new file mode 100644 index 000000000..641679d70 --- /dev/null +++ b/pr-1714/assets/images/go.cd_fork-e81f9737.svg @@ -0,0 +1,143 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_form-cb660f66.svg b/pr-1714/assets/images/go.cd_form-cb660f66.svg new file mode 100644 index 000000000..166493787 --- /dev/null +++ b/pr-1714/assets/images/go.cd_form-cb660f66.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_gitter-8f5a1c91.svg b/pr-1714/assets/images/go.cd_gitter-8f5a1c91.svg new file mode 100644 index 000000000..44dd479bd --- /dev/null +++ b/pr-1714/assets/images/go.cd_gitter-8f5a1c91.svg @@ -0,0 +1,129 @@ + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_gocd-on-github-1b93b87e.svg b/pr-1714/assets/images/go.cd_gocd-on-github-1b93b87e.svg new file mode 100644 index 000000000..72c8d39d4 --- /dev/null +++ b/pr-1714/assets/images/go.cd_gocd-on-github-1b93b87e.svg @@ -0,0 +1,322 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_installation-bcefac0e.svg b/pr-1714/assets/images/go.cd_installation-bcefac0e.svg new file mode 100644 index 000000000..432cafeff --- /dev/null +++ b/pr-1714/assets/images/go.cd_installation-bcefac0e.svg @@ -0,0 +1,169 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_join-community-939c83d9.svg b/pr-1714/assets/images/go.cd_join-community-939c83d9.svg new file mode 100644 index 000000000..b47e77d8e --- /dev/null +++ b/pr-1714/assets/images/go.cd_join-community-939c83d9.svg @@ -0,0 +1,150 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg b/pr-1714/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg new file mode 100644 index 000000000..31dda06e3 --- /dev/null +++ b/pr-1714/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg @@ -0,0 +1,177 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_mailing-list-5daf2f9a.svg b/pr-1714/assets/images/go.cd_mailing-list-5daf2f9a.svg new file mode 100644 index 000000000..cd48984eb --- /dev/null +++ b/pr-1714/assets/images/go.cd_mailing-list-5daf2f9a.svg @@ -0,0 +1,165 @@ + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_merge-eabd7739.svg b/pr-1714/assets/images/go.cd_merge-eabd7739.svg new file mode 100644 index 000000000..e6f54ac36 --- /dev/null +++ b/pr-1714/assets/images/go.cd_merge-eabd7739.svg @@ -0,0 +1,137 @@ + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_other-resources-50299cf1.svg b/pr-1714/assets/images/go.cd_other-resources-50299cf1.svg new file mode 100644 index 000000000..cfa4954f9 --- /dev/null +++ b/pr-1714/assets/images/go.cd_other-resources-50299cf1.svg @@ -0,0 +1,143 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png b/pr-1714/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png new file mode 100644 index 000000000..cbf60f0c7 Binary files /dev/null and b/pr-1714/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png differ diff --git a/pr-1714/assets/images/go.cd_pipelines-materials-e64b8575.svg b/pr-1714/assets/images/go.cd_pipelines-materials-e64b8575.svg new file mode 100644 index 000000000..022e8adf6 --- /dev/null +++ b/pr-1714/assets/images/go.cd_pipelines-materials-e64b8575.svg @@ -0,0 +1,336 @@ + + + + + + + Pipeline + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Stage 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Stage 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Stage 3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Material 1 + + + + Material 2 + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_plugins-a7a0b91f.svg b/pr-1714/assets/images/go.cd_plugins-a7a0b91f.svg new file mode 100644 index 000000000..6422c87b0 --- /dev/null +++ b/pr-1714/assets/images/go.cd_plugins-a7a0b91f.svg @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg b/pr-1714/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg new file mode 100644 index 000000000..74c6ecb15 --- /dev/null +++ b/pr-1714/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg @@ -0,0 +1,172 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_pull-request-b418521e.svg b/pr-1714/assets/images/go.cd_pull-request-b418521e.svg new file mode 100644 index 000000000..c667997e8 --- /dev/null +++ b/pr-1714/assets/images/go.cd_pull-request-b418521e.svg @@ -0,0 +1,141 @@ + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_roadmap-a4ec26c2.svg b/pr-1714/assets/images/go.cd_roadmap-a4ec26c2.svg new file mode 100644 index 000000000..8c49282f5 --- /dev/null +++ b/pr-1714/assets/images/go.cd_roadmap-a4ec26c2.svg @@ -0,0 +1,149 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg b/pr-1714/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg new file mode 100644 index 000000000..9d14025cb --- /dev/null +++ b/pr-1714/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_server-aff636b1.png b/pr-1714/assets/images/go.cd_server-aff636b1.png new file mode 100644 index 000000000..00a67ce0f Binary files /dev/null and b/pr-1714/assets/images/go.cd_server-aff636b1.png differ diff --git a/pr-1714/assets/images/go.cd_server-and-agents-8a7f4cd3.svg b/pr-1714/assets/images/go.cd_server-and-agents-8a7f4cd3.svg new file mode 100644 index 000000000..2cad7bd1f --- /dev/null +++ b/pr-1714/assets/images/go.cd_server-and-agents-8a7f4cd3.svg @@ -0,0 +1,193 @@ + + + + + + + + + Agent 1 + + + + + + Agent 2 + + + + + + Agent 3 + + + + + + + + + + + GoCD server + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg b/pr-1714/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg new file mode 100644 index 000000000..2387cc422 --- /dev/null +++ b/pr-1714/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_stage-jobs-tasks-a58d5b3b.svg b/pr-1714/assets/images/go.cd_stage-jobs-tasks-a58d5b3b.svg new file mode 100644 index 000000000..f58545157 --- /dev/null +++ b/pr-1714/assets/images/go.cd_stage-jobs-tasks-a58d5b3b.svg @@ -0,0 +1,418 @@ + + + + + +This is a Pipeline + +Stage 1 + + + JoB + + + + Task + ant -Dmodule=A compile + + + + + + Task + rake create_docs + + + + + + Task + create_package.sh + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + JoB + + + + + Task + ant -Dmodule=A compile + + + + + + Task + rake create_docs + + + + + + Task + create_package.sh + + + + + + + + + + + + + + + + + + + +Stage 2 + + + + + + JoB + + + + + Task + ant -Dmodule=A compile + + + + + + Task + rake create_docs + + + + + + Task + create_package.sh + + + + + + + + + + + + + + + + + + + + + + + JoB + + + + + Task + ant -Dmodule=A compile + + + + + + Task + rspec spec mpdule-A + + + + + + + + + + + + + + + + + + JoB + + + + + Task + ant -Dmodule=A compile + + + + + + Task + rake create_docs + + + + + + Task + create_package.sh + + + + + + + + + + + + + + + + + + + + + +These jobs will run in parallel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stage 2 +Stage 3 + diff --git a/pr-1714/assets/images/go.cd_test-gocd-d32d8061.svg b/pr-1714/assets/images/go.cd_test-gocd-d32d8061.svg new file mode 100644 index 000000000..4fdb4fbfb --- /dev/null +++ b/pr-1714/assets/images/go.cd_test-gocd-d32d8061.svg @@ -0,0 +1,156 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_trust-your-team-ae0d921b.svg b/pr-1714/assets/images/go.cd_trust-your-team-ae0d921b.svg new file mode 100644 index 000000000..5423f7e44 --- /dev/null +++ b/pr-1714/assets/images/go.cd_trust-your-team-ae0d921b.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_user-documentation-36dc7dba.svg b/pr-1714/assets/images/go.cd_user-documentation-36dc7dba.svg new file mode 100644 index 000000000..174a38a73 --- /dev/null +++ b/pr-1714/assets/images/go.cd_user-documentation-36dc7dba.svg @@ -0,0 +1,172 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_user-group-a35f5dac.svg b/pr-1714/assets/images/go.cd_user-group-a35f5dac.svg new file mode 100644 index 000000000..8bc4d7b85 --- /dev/null +++ b/pr-1714/assets/images/go.cd_user-group-a35f5dac.svg @@ -0,0 +1,150 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_want-to-do-4b72b9b7.svg b/pr-1714/assets/images/go.cd_want-to-do-4b72b9b7.svg new file mode 100644 index 000000000..06dfc65c2 --- /dev/null +++ b/pr-1714/assets/images/go.cd_want-to-do-4b72b9b7.svg @@ -0,0 +1,152 @@ + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go.cd_why-go-plugins-f59a63a3.svg b/pr-1714/assets/images/go.cd_why-go-plugins-f59a63a3.svg new file mode 100644 index 000000000..7526531d6 --- /dev/null +++ b/pr-1714/assets/images/go.cd_why-go-plugins-f59a63a3.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/go_logo-5b5ca9e1.svg b/pr-1714/assets/images/go_logo-5b5ca9e1.svg new file mode 100644 index 000000000..50d5ede16 --- /dev/null +++ b/pr-1714/assets/images/go_logo-5b5ca9e1.svg @@ -0,0 +1,42 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/gocd-watermark-b94da563.svg b/pr-1714/assets/images/gocd-watermark-b94da563.svg new file mode 100644 index 000000000..094af8850 --- /dev/null +++ b/pr-1714/assets/images/gocd-watermark-b94da563.svg @@ -0,0 +1,23 @@ + + + + Group 6 + Created with Sketch. + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/pr-1714/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg b/pr-1714/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg new file mode 100644 index 000000000..b1caee527 Binary files /dev/null and b/pr-1714/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg differ diff --git a/pr-1714/assets/images/halftone_gradient_background-9042b7fc.jpg b/pr-1714/assets/images/halftone_gradient_background-9042b7fc.jpg new file mode 100644 index 000000000..5b0c4fc71 Binary files /dev/null and b/pr-1714/assets/images/halftone_gradient_background-9042b7fc.jpg differ diff --git a/pr-1714/assets/images/help/community-301af89c.svg b/pr-1714/assets/images/help/community-301af89c.svg new file mode 100644 index 000000000..56daada99 --- /dev/null +++ b/pr-1714/assets/images/help/community-301af89c.svg @@ -0,0 +1,142 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/help/docs-4b296108.svg b/pr-1714/assets/images/help/docs-4b296108.svg new file mode 100644 index 000000000..5572c2e92 --- /dev/null +++ b/pr-1714/assets/images/help/docs-4b296108.svg @@ -0,0 +1,159 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/help/intro-5ae8c318.svg b/pr-1714/assets/images/help/intro-5ae8c318.svg new file mode 100644 index 000000000..6f4aa95cd --- /dev/null +++ b/pr-1714/assets/images/help/intro-5ae8c318.svg @@ -0,0 +1,107 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/home/cloud-native-de09706b.svg b/pr-1714/assets/images/home/cloud-native-de09706b.svg new file mode 100644 index 000000000..57320d8f1 --- /dev/null +++ b/pr-1714/assets/images/home/cloud-native-de09706b.svg @@ -0,0 +1,226 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/home/complex-workflow-66e3fca0.svg b/pr-1714/assets/images/home/complex-workflow-66e3fca0.svg new file mode 100644 index 000000000..10f3735c0 --- /dev/null +++ b/pr-1714/assets/images/home/complex-workflow-66e3fca0.svg @@ -0,0 +1,217 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/home/end-to-end-e50a03a0.svg b/pr-1714/assets/images/home/end-to-end-e50a03a0.svg new file mode 100644 index 000000000..c33dda488 --- /dev/null +++ b/pr-1714/assets/images/home/end-to-end-e50a03a0.svg @@ -0,0 +1,187 @@ + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/home/pipe_bkgd-564e4ebb.jpg b/pr-1714/assets/images/home/pipe_bkgd-564e4ebb.jpg new file mode 100644 index 000000000..b9a021e2a Binary files /dev/null and b/pr-1714/assets/images/home/pipe_bkgd-564e4ebb.jpg differ diff --git a/pr-1714/assets/images/home/traceability-1b39450a.svg b/pr-1714/assets/images/home/traceability-1b39450a.svg new file mode 100644 index 000000000..e94d32645 --- /dev/null +++ b/pr-1714/assets/images/home/traceability-1b39450a.svg @@ -0,0 +1,205 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/home/ui_illo-647c5fa8.svg b/pr-1714/assets/images/home/ui_illo-647c5fa8.svg new file mode 100644 index 000000000..9ef74bfad --- /dev/null +++ b/pr-1714/assets/images/home/ui_illo-647c5fa8.svg @@ -0,0 +1 @@ +Asset 2 \ No newline at end of file diff --git a/pr-1714/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg b/pr-1714/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg new file mode 100644 index 000000000..03435e892 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg @@ -0,0 +1,91 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg b/pr-1714/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg new file mode 100644 index 000000000..c14a3d495 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg @@ -0,0 +1,90 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_community-0ebe9afa.svg b/pr-1714/assets/images/icons/go.cd_community-0ebe9afa.svg new file mode 100644 index 000000000..4b8babfdf --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_community-0ebe9afa.svg @@ -0,0 +1,124 @@ + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_compare-builds-a87196c2.svg b/pr-1714/assets/images/icons/go.cd_compare-builds-a87196c2.svg new file mode 100644 index 000000000..3dbef2f10 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_compare-builds-a87196c2.svg @@ -0,0 +1,123 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg b/pr-1714/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg new file mode 100644 index 000000000..13033fa43 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg b/pr-1714/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg new file mode 100644 index 000000000..426a83b4b --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg @@ -0,0 +1,174 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_join-community-61198ca4.svg b/pr-1714/assets/images/icons/go.cd_join-community-61198ca4.svg new file mode 100644 index 000000000..02897541a --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_join-community-61198ca4.svg @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg b/pr-1714/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg new file mode 100644 index 000000000..dc664cf77 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg @@ -0,0 +1,125 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg b/pr-1714/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg new file mode 100644 index 000000000..e7176dd55 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg @@ -0,0 +1,96 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_plugins-d2b1494a.svg b/pr-1714/assets/images/icons/go.cd_plugins-d2b1494a.svg new file mode 100644 index 000000000..c03c403a3 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_plugins-d2b1494a.svg @@ -0,0 +1,88 @@ + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg b/pr-1714/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg new file mode 100644 index 000000000..dcc9a7687 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg @@ -0,0 +1,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg b/pr-1714/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg new file mode 100644 index 000000000..504e7c0eb --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg @@ -0,0 +1,205 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_security-d3942ad4.svg b/pr-1714/assets/images/icons/go.cd_security-d3942ad4.svg new file mode 100644 index 000000000..2361e0786 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_security-d3942ad4.svg @@ -0,0 +1,96 @@ + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg b/pr-1714/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg new file mode 100644 index 000000000..dfe756765 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg b/pr-1714/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg new file mode 100644 index 000000000..7c58e7225 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg @@ -0,0 +1,127 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg b/pr-1714/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg new file mode 100644 index 000000000..5299731d3 --- /dev/null +++ b/pr-1714/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/image01-453d1ed1.png b/pr-1714/assets/images/image01-453d1ed1.png new file mode 100644 index 000000000..eb639e65a Binary files /dev/null and b/pr-1714/assets/images/image01-453d1ed1.png differ diff --git a/pr-1714/assets/images/image02-7cb7c1f3.png b/pr-1714/assets/images/image02-7cb7c1f3.png new file mode 100644 index 000000000..e5ac7600b Binary files /dev/null and b/pr-1714/assets/images/image02-7cb7c1f3.png differ diff --git a/pr-1714/assets/images/image03-da3d56f1.png b/pr-1714/assets/images/image03-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1714/assets/images/image03-da3d56f1.png differ diff --git a/pr-1714/assets/images/image07-77a88407.png b/pr-1714/assets/images/image07-77a88407.png new file mode 100644 index 000000000..7486f2520 Binary files /dev/null and b/pr-1714/assets/images/image07-77a88407.png differ diff --git a/pr-1714/assets/images/image08-da3d56f1.png b/pr-1714/assets/images/image08-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1714/assets/images/image08-da3d56f1.png differ diff --git a/pr-1714/assets/images/image09-da3d56f1.png b/pr-1714/assets/images/image09-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1714/assets/images/image09-da3d56f1.png differ diff --git a/pr-1714/assets/images/image10-554cdcff.png b/pr-1714/assets/images/image10-554cdcff.png new file mode 100644 index 000000000..b08715e33 Binary files /dev/null and b/pr-1714/assets/images/image10-554cdcff.png differ diff --git a/pr-1714/assets/images/inner-banner-bg-5a21fadc.jpg b/pr-1714/assets/images/inner-banner-bg-5a21fadc.jpg new file mode 100644 index 000000000..1944de848 Binary files /dev/null and b/pr-1714/assets/images/inner-banner-bg-5a21fadc.jpg differ diff --git a/pr-1714/assets/images/lightbox-arrow-e5c1fbd9.svg b/pr-1714/assets/images/lightbox-arrow-e5c1fbd9.svg new file mode 100644 index 000000000..a69f8e2c6 --- /dev/null +++ b/pr-1714/assets/images/lightbox-arrow-e5c1fbd9.svg @@ -0,0 +1,11 @@ + + + + + + + + diff --git a/pr-1714/assets/images/lightbox-close-3acf70e4.svg b/pr-1714/assets/images/lightbox-close-3acf70e4.svg new file mode 100644 index 000000000..779a3c73d --- /dev/null +++ b/pr-1714/assets/images/lightbox-close-3acf70e4.svg @@ -0,0 +1,12 @@ + + + + + + + + + diff --git a/pr-1714/assets/images/middleman-logo-257e02f7.svg b/pr-1714/assets/images/middleman-logo-257e02f7.svg new file mode 100644 index 000000000..98ef9fc3a --- /dev/null +++ b/pr-1714/assets/images/middleman-logo-257e02f7.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/pr-1714/assets/images/model-complex-worklflows-8b2fd43e.jpg b/pr-1714/assets/images/model-complex-worklflows-8b2fd43e.jpg new file mode 100644 index 000000000..991090b61 Binary files /dev/null and b/pr-1714/assets/images/model-complex-worklflows-8b2fd43e.jpg differ diff --git a/pr-1714/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png b/pr-1714/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png new file mode 100644 index 000000000..091c89743 Binary files /dev/null and b/pr-1714/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png differ diff --git a/pr-1714/assets/images/pipeline_subscribe-028c93fa.jpg b/pr-1714/assets/images/pipeline_subscribe-028c93fa.jpg new file mode 100644 index 000000000..2d8d0d1c5 Binary files /dev/null and b/pr-1714/assets/images/pipeline_subscribe-028c93fa.jpg differ diff --git a/pr-1714/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg b/pr-1714/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg new file mode 100644 index 000000000..ec37b677a Binary files /dev/null and b/pr-1714/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg differ diff --git a/pr-1714/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg b/pr-1714/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg new file mode 100644 index 000000000..e901d35b9 --- /dev/null +++ b/pr-1714/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg @@ -0,0 +1,92 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg b/pr-1714/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg new file mode 100644 index 000000000..36baee4f8 --- /dev/null +++ b/pr-1714/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/pipelines-as-code/k8s-acf3f006.svg b/pr-1714/assets/images/pipelines-as-code/k8s-acf3f006.svg new file mode 100644 index 000000000..fad07ac62 --- /dev/null +++ b/pr-1714/assets/images/pipelines-as-code/k8s-acf3f006.svg @@ -0,0 +1,97 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg b/pr-1714/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg new file mode 100644 index 000000000..980efdecf --- /dev/null +++ b/pr-1714/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1714/assets/images/pipelines-as-code/pipelines-as-code-banner-2d9a5b61.jpg b/pr-1714/assets/images/pipelines-as-code/pipelines-as-code-banner-2d9a5b61.jpg new file mode 100644 index 000000000..e76431ab7 Binary files /dev/null and b/pr-1714/assets/images/pipelines-as-code/pipelines-as-code-banner-2d9a5b61.jpg differ diff --git a/pr-1714/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif b/pr-1714/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif new file mode 100644 index 000000000..381e57aca Binary files /dev/null and b/pr-1714/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif differ diff --git a/pr-1714/assets/images/placeholder-3f95a996.jpg b/pr-1714/assets/images/placeholder-3f95a996.jpg new file mode 100644 index 000000000..45f37b9d1 Binary files /dev/null and b/pr-1714/assets/images/placeholder-3f95a996.jpg differ diff --git a/pr-1714/assets/images/plugins-4ae2cffd.png b/pr-1714/assets/images/plugins-4ae2cffd.png new file mode 100644 index 000000000..c7d20a63c Binary files /dev/null and b/pr-1714/assets/images/plugins-4ae2cffd.png differ diff --git a/pr-1714/assets/images/promote-trusted-artifacts-bb483c0c.png b/pr-1714/assets/images/promote-trusted-artifacts-bb483c0c.png new file mode 100644 index 000000000..4d80d1484 Binary files /dev/null and b/pr-1714/assets/images/promote-trusted-artifacts-bb483c0c.png differ diff --git a/pr-1714/assets/images/releases/15.1/15_1_console_log_timestamp-d475e063.png b/pr-1714/assets/images/releases/15.1/15_1_console_log_timestamp-d475e063.png new file mode 100644 index 000000000..3cf23168d Binary files /dev/null and b/pr-1714/assets/images/releases/15.1/15_1_console_log_timestamp-d475e063.png differ diff --git a/pr-1714/assets/images/releases/15.1/15_1_github_pr-4d2a6ba4.png b/pr-1714/assets/images/releases/15.1/15_1_github_pr-4d2a6ba4.png new file mode 100644 index 000000000..51c33ba4f Binary files /dev/null and b/pr-1714/assets/images/releases/15.1/15_1_github_pr-4d2a6ba4.png differ diff --git a/pr-1714/assets/images/releases/15.1/15_1_new_pipeline_label-e4efa9b7.png b/pr-1714/assets/images/releases/15.1/15_1_new_pipeline_label-e4efa9b7.png new file mode 100644 index 000000000..15135e566 Binary files /dev/null and b/pr-1714/assets/images/releases/15.1/15_1_new_pipeline_label-e4efa9b7.png differ diff --git a/pr-1714/assets/images/releases/15.1/15_1_old_pipeline_label-9b431eaf.png b/pr-1714/assets/images/releases/15.1/15_1_old_pipeline_label-9b431eaf.png new file mode 100644 index 000000000..e14435196 Binary files /dev/null and b/pr-1714/assets/images/releases/15.1/15_1_old_pipeline_label-9b431eaf.png differ diff --git a/pr-1714/assets/images/releases/15.2/console-log-color-9cb3f569.png b/pr-1714/assets/images/releases/15.2/console-log-color-9cb3f569.png new file mode 100644 index 000000000..3047bbff5 Binary files /dev/null and b/pr-1714/assets/images/releases/15.2/console-log-color-9cb3f569.png differ diff --git a/pr-1714/assets/images/releases/15.3/update-check-bell-224e93de.png b/pr-1714/assets/images/releases/15.3/update-check-bell-224e93de.png new file mode 100644 index 000000000..20515ab66 Binary files /dev/null and b/pr-1714/assets/images/releases/15.3/update-check-bell-224e93de.png differ diff --git a/pr-1714/assets/images/releases/15.3/update-check-info-e75610b1.png b/pr-1714/assets/images/releases/15.3/update-check-info-e75610b1.png new file mode 100644 index 000000000..c696bce10 Binary files /dev/null and b/pr-1714/assets/images/releases/15.3/update-check-info-e75610b1.png differ diff --git a/pr-1714/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png b/pr-1714/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png new file mode 100644 index 000000000..cf3f03227 Binary files /dev/null and b/pr-1714/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png differ diff --git a/pr-1714/assets/images/releases/16.10/agents-page-old-9d4fe063.png b/pr-1714/assets/images/releases/16.10/agents-page-old-9d4fe063.png new file mode 100644 index 000000000..31a8c0c6d Binary files /dev/null and b/pr-1714/assets/images/releases/16.10/agents-page-old-9d4fe063.png differ diff --git a/pr-1714/assets/images/releases/16.12/agents-page-b520368d.png b/pr-1714/assets/images/releases/16.12/agents-page-b520368d.png new file mode 100644 index 000000000..8abb6ef58 Binary files /dev/null and b/pr-1714/assets/images/releases/16.12/agents-page-b520368d.png differ diff --git a/pr-1714/assets/images/releases/16.12/elastic-profiles-add-new-eb4f88a3.png b/pr-1714/assets/images/releases/16.12/elastic-profiles-add-new-eb4f88a3.png new file mode 100644 index 000000000..64b54fb9d Binary files /dev/null and b/pr-1714/assets/images/releases/16.12/elastic-profiles-add-new-eb4f88a3.png differ diff --git a/pr-1714/assets/images/releases/16.12/new-theme-912e9418.png b/pr-1714/assets/images/releases/16.12/new-theme-912e9418.png new file mode 100644 index 000000000..1b8ca1d9d Binary files /dev/null and b/pr-1714/assets/images/releases/16.12/new-theme-912e9418.png differ diff --git a/pr-1714/assets/images/releases/16.3/git-shallow-clone-e82e142c.png b/pr-1714/assets/images/releases/16.3/git-shallow-clone-e82e142c.png new file mode 100644 index 000000000..d7e094e24 Binary files /dev/null and b/pr-1714/assets/images/releases/16.3/git-shallow-clone-e82e142c.png differ diff --git a/pr-1714/assets/images/releases/16.9/quickeditbutton-78e54c92.png b/pr-1714/assets/images/releases/16.9/quickeditbutton-78e54c92.png new file mode 100644 index 000000000..84366bfb0 Binary files /dev/null and b/pr-1714/assets/images/releases/16.9/quickeditbutton-78e54c92.png differ diff --git a/pr-1714/assets/images/releases/16.9/quickeditpage-126e6d7a.png b/pr-1714/assets/images/releases/16.9/quickeditpage-126e6d7a.png new file mode 100644 index 000000000..2cc08d64d Binary files /dev/null and b/pr-1714/assets/images/releases/16.9/quickeditpage-126e6d7a.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/pipeline-run-duration-in-vsm-4d3bffed.png b/pr-1714/assets/images/releases/17.11.0/pipeline-run-duration-in-vsm-4d3bffed.png new file mode 100644 index 000000000..55a8d084d Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/pipeline-run-duration-in-vsm-4d3bffed.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-dashboard-ca369c86.png b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-dashboard-ca369c86.png new file mode 100644 index 000000000..9aef5711f Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-dashboard-ca369c86.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-job-details-header-41ce0456.png b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-job-details-header-41ce0456.png new file mode 100644 index 000000000..d6a4bac7e Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-job-details-header-41ce0456.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-stage-details-1590a797.png b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-stage-details-1590a797.png new file mode 100644 index 000000000..6702b06db Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-stage-details-1590a797.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-4d3bffed.png b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-4d3bffed.png new file mode 100644 index 000000000..55a8d084d Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-4d3bffed.png differ diff --git a/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-header-95afe224.png b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-header-95afe224.png new file mode 100644 index 000000000..1a6dc6c4d Binary files /dev/null and b/pr-1714/assets/images/releases/17.11.0/vsm-explicit-link-vsm-header-95afe224.png differ diff --git a/pr-1714/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png b/pr-1714/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png new file mode 100644 index 000000000..610690ffd Binary files /dev/null and b/pr-1714/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png differ diff --git a/pr-1714/assets/images/releases/17.2.0/template-permissions-73dc5171.png b/pr-1714/assets/images/releases/17.2.0/template-permissions-73dc5171.png new file mode 100644 index 000000000..aa96f6f88 Binary files /dev/null and b/pr-1714/assets/images/releases/17.2.0/template-permissions-73dc5171.png differ diff --git a/pr-1714/assets/images/releases/17.3.0/build_status-96febef4.png b/pr-1714/assets/images/releases/17.3.0/build_status-96febef4.png new file mode 100644 index 000000000..e8076ba41 Binary files /dev/null and b/pr-1714/assets/images/releases/17.3.0/build_status-96febef4.png differ diff --git a/pr-1714/assets/images/releases/17.3.0/elastic_agent_icon-1e562032.png b/pr-1714/assets/images/releases/17.3.0/elastic_agent_icon-1e562032.png new file mode 100644 index 000000000..23b303613 Binary files /dev/null and b/pr-1714/assets/images/releases/17.3.0/elastic_agent_icon-1e562032.png differ diff --git a/pr-1714/assets/images/releases/17.3.0/stage_with_symbols-4c8d52df.png b/pr-1714/assets/images/releases/17.3.0/stage_with_symbols-4c8d52df.png new file mode 100644 index 000000000..c32cf8dd5 Binary files /dev/null and b/pr-1714/assets/images/releases/17.3.0/stage_with_symbols-4c8d52df.png differ diff --git a/pr-1714/assets/images/releases/17.4.0/border-31151e37.png b/pr-1714/assets/images/releases/17.4.0/border-31151e37.png new file mode 100644 index 000000000..053c1a716 Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/border-31151e37.png differ diff --git a/pr-1714/assets/images/releases/17.4.0/errors-a3128474.png b/pr-1714/assets/images/releases/17.4.0/errors-a3128474.png new file mode 100644 index 000000000..d76f715da Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/errors-a3128474.png differ diff --git a/pr-1714/assets/images/releases/17.4.0/expand_logs-49fa414c.gif b/pr-1714/assets/images/releases/17.4.0/expand_logs-49fa414c.gif new file mode 100644 index 000000000..a0fbf2c41 Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/expand_logs-49fa414c.gif differ diff --git a/pr-1714/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png b/pr-1714/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png new file mode 100644 index 000000000..f5f3070d0 Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png differ diff --git a/pr-1714/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif b/pr-1714/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif new file mode 100644 index 000000000..809b75653 Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif differ diff --git a/pr-1714/assets/images/releases/17.4.0/timestamp-99c7c6d3.png b/pr-1714/assets/images/releases/17.4.0/timestamp-99c7c6d3.png new file mode 100644 index 000000000..db7037d54 Binary files /dev/null and b/pr-1714/assets/images/releases/17.4.0/timestamp-99c7c6d3.png differ diff --git a/pr-1714/assets/images/releases/17.5.0/auth-config-e288de5a.png b/pr-1714/assets/images/releases/17.5.0/auth-config-e288de5a.png new file mode 100644 index 000000000..9e2779378 Binary files /dev/null and b/pr-1714/assets/images/releases/17.5.0/auth-config-e288de5a.png differ diff --git a/pr-1714/assets/images/releases/17.5.0/role-config-4127629c.png b/pr-1714/assets/images/releases/17.5.0/role-config-4127629c.png new file mode 100644 index 000000000..828b4ce12 Binary files /dev/null and b/pr-1714/assets/images/releases/17.5.0/role-config-4127629c.png differ diff --git a/pr-1714/assets/images/releases/17.5.0/security-menu-d1aed431.png b/pr-1714/assets/images/releases/17.5.0/security-menu-d1aed431.png new file mode 100644 index 000000000..fd7a6d1d2 Binary files /dev/null and b/pr-1714/assets/images/releases/17.5.0/security-menu-d1aed431.png differ diff --git a/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-1-5a8314bf.png b/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-1-5a8314bf.png new file mode 100644 index 000000000..49c4db2e8 Binary files /dev/null and b/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-1-5a8314bf.png differ diff --git a/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-2-41be5dda.png b/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-2-41be5dda.png new file mode 100644 index 000000000..33b2076db Binary files /dev/null and b/pr-1714/assets/images/releases/17.6.0/improve-timestamp-rendering-2-41be5dda.png differ diff --git a/pr-1714/assets/images/releases/17.6.0/rerun-failed-jobs-182f21d2.png b/pr-1714/assets/images/releases/17.6.0/rerun-failed-jobs-182f21d2.png new file mode 100644 index 000000000..8c2dec28b Binary files /dev/null and b/pr-1714/assets/images/releases/17.6.0/rerun-failed-jobs-182f21d2.png differ diff --git a/pr-1714/assets/images/releases/17.9.0/edit-pipeline-from-vsm-008fac52.png b/pr-1714/assets/images/releases/17.9.0/edit-pipeline-from-vsm-008fac52.png new file mode 100644 index 000000000..0a9338bdc Binary files /dev/null and b/pr-1714/assets/images/releases/17.9.0/edit-pipeline-from-vsm-008fac52.png differ diff --git a/pr-1714/assets/images/releases/17.9.0/elastic-agent-grouping-by-plugin-id-3f70396b.png b/pr-1714/assets/images/releases/17.9.0/elastic-agent-grouping-by-plugin-id-3f70396b.png new file mode 100644 index 000000000..28785c1e5 Binary files /dev/null and b/pr-1714/assets/images/releases/17.9.0/elastic-agent-grouping-by-plugin-id-3f70396b.png differ diff --git a/pr-1714/assets/images/releases/18.10.0/environments-under-admin-e89c15f6.gif b/pr-1714/assets/images/releases/18.10.0/environments-under-admin-e89c15f6.gif new file mode 100644 index 000000000..90a1945ed Binary files /dev/null and b/pr-1714/assets/images/releases/18.10.0/environments-under-admin-e89c15f6.gif differ diff --git a/pr-1714/assets/images/releases/18.12.0/admin_menu-6be5be5a.png b/pr-1714/assets/images/releases/18.12.0/admin_menu-6be5be5a.png new file mode 100644 index 000000000..c8ae092a0 Binary files /dev/null and b/pr-1714/assets/images/releases/18.12.0/admin_menu-6be5be5a.png differ diff --git a/pr-1714/assets/images/releases/18.12.0/config_repo-8810e00d.png b/pr-1714/assets/images/releases/18.12.0/config_repo-8810e00d.png new file mode 100644 index 000000000..fd2c4ca0c Binary files /dev/null and b/pr-1714/assets/images/releases/18.12.0/config_repo-8810e00d.png differ diff --git a/pr-1714/assets/images/releases/18.12.0/elastic_profile_jobs-d50b21a6.png b/pr-1714/assets/images/releases/18.12.0/elastic_profile_jobs-d50b21a6.png new file mode 100644 index 000000000..bdc74c245 Binary files /dev/null and b/pr-1714/assets/images/releases/18.12.0/elastic_profile_jobs-d50b21a6.png differ diff --git a/pr-1714/assets/images/releases/18.2.0/elastic-agent-plugin-status-report-1ad2f3fc.png b/pr-1714/assets/images/releases/18.2.0/elastic-agent-plugin-status-report-1ad2f3fc.png new file mode 100644 index 000000000..d108509e2 Binary files /dev/null and b/pr-1714/assets/images/releases/18.2.0/elastic-agent-plugin-status-report-1ad2f3fc.png differ diff --git a/pr-1714/assets/images/releases/18.2.0/elastic-agent-status-report-66a6779c.png b/pr-1714/assets/images/releases/18.2.0/elastic-agent-status-report-66a6779c.png new file mode 100644 index 000000000..b79c5b4b4 Binary files /dev/null and b/pr-1714/assets/images/releases/18.2.0/elastic-agent-status-report-66a6779c.png differ diff --git a/pr-1714/assets/images/releases/18.2.0/new-dashboard-4720d938.png b/pr-1714/assets/images/releases/18.2.0/new-dashboard-4720d938.png new file mode 100644 index 000000000..fb8c911f2 Binary files /dev/null and b/pr-1714/assets/images/releases/18.2.0/new-dashboard-4720d938.png differ diff --git a/pr-1714/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png b/pr-1714/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png new file mode 100644 index 000000000..7c06af9e6 Binary files /dev/null and b/pr-1714/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png differ diff --git a/pr-1714/assets/images/releases/18.3.0/plugin-error-warning-messages-0bbd0095.png b/pr-1714/assets/images/releases/18.3.0/plugin-error-warning-messages-0bbd0095.png new file mode 100644 index 000000000..a2682b37d Binary files /dev/null and b/pr-1714/assets/images/releases/18.3.0/plugin-error-warning-messages-0bbd0095.png differ diff --git a/pr-1714/assets/images/releases/18.7.0/data-sharing-ae8581cb.png b/pr-1714/assets/images/releases/18.7.0/data-sharing-ae8581cb.png new file mode 100644 index 000000000..65f91edfc Binary files /dev/null and b/pr-1714/assets/images/releases/18.7.0/data-sharing-ae8581cb.png differ diff --git a/pr-1714/assets/images/releases/18.7.0/loading-screen-d4d02113.png b/pr-1714/assets/images/releases/18.7.0/loading-screen-d4d02113.png new file mode 100644 index 000000000..4296932ed Binary files /dev/null and b/pr-1714/assets/images/releases/18.7.0/loading-screen-d4d02113.png differ diff --git a/pr-1714/assets/images/releases/18.8.0/by-pipeline-status-898e5dee.gif b/pr-1714/assets/images/releases/18.8.0/by-pipeline-status-898e5dee.gif new file mode 100644 index 000000000..8d0624e6a Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/by-pipeline-status-898e5dee.gif differ diff --git a/pr-1714/assets/images/releases/18.8.0/create-new-view-cf4e737f.gif b/pr-1714/assets/images/releases/18.8.0/create-new-view-cf4e737f.gif new file mode 100644 index 000000000..57828884a Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/create-new-view-cf4e737f.gif differ diff --git a/pr-1714/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif b/pr-1714/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif new file mode 100644 index 000000000..c2f4a4983 Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif differ diff --git a/pr-1714/assets/images/releases/18.8.0/data-sharing-721f77da.png b/pr-1714/assets/images/releases/18.8.0/data-sharing-721f77da.png new file mode 100644 index 000000000..9e04764e4 Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/data-sharing-721f77da.png differ diff --git a/pr-1714/assets/images/releases/18.8.0/only-building-and-failed-pipelines-b8590063.gif b/pr-1714/assets/images/releases/18.8.0/only-building-and-failed-pipelines-b8590063.gif new file mode 100644 index 000000000..fe23db514 Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/only-building-and-failed-pipelines-b8590063.gif differ diff --git a/pr-1714/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif b/pr-1714/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif new file mode 100644 index 000000000..42d7a170f Binary files /dev/null and b/pr-1714/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif differ diff --git a/pr-1714/assets/images/releases/19.1.0/config-spa-error-3c12e3b4.png b/pr-1714/assets/images/releases/19.1.0/config-spa-error-3c12e3b4.png new file mode 100644 index 000000000..ec89b4cf5 Binary files /dev/null and b/pr-1714/assets/images/releases/19.1.0/config-spa-error-3c12e3b4.png differ diff --git a/pr-1714/assets/images/releases/19.1.0/pipeline-export-111479b7.gif b/pr-1714/assets/images/releases/19.1.0/pipeline-export-111479b7.gif new file mode 100644 index 000000000..f33445adb Binary files /dev/null and b/pr-1714/assets/images/releases/19.1.0/pipeline-export-111479b7.gif differ diff --git a/pr-1714/assets/images/releases/19.1.0/server-maintenance-mode-9b7eb7ce.gif b/pr-1714/assets/images/releases/19.1.0/server-maintenance-mode-9b7eb7ce.gif new file mode 100644 index 000000000..5637f312a Binary files /dev/null and b/pr-1714/assets/images/releases/19.1.0/server-maintenance-mode-9b7eb7ce.gif differ diff --git a/pr-1714/assets/images/releases/19.1.0/users_management-6344f05c.png b/pr-1714/assets/images/releases/19.1.0/users_management-6344f05c.png new file mode 100644 index 000000000..258f74b21 Binary files /dev/null and b/pr-1714/assets/images/releases/19.1.0/users_management-6344f05c.png differ diff --git a/pr-1714/assets/images/releases/19.10.0/new-agents-page-elastic-agents-4ff88a93.png b/pr-1714/assets/images/releases/19.10.0/new-agents-page-elastic-agents-4ff88a93.png new file mode 100644 index 000000000..f412aff7f Binary files /dev/null and b/pr-1714/assets/images/releases/19.10.0/new-agents-page-elastic-agents-4ff88a93.png differ diff --git a/pr-1714/assets/images/releases/19.10.0/new-agents-page-static-agents-36c50ab2.png b/pr-1714/assets/images/releases/19.10.0/new-agents-page-static-agents-36c50ab2.png new file mode 100644 index 000000000..f8bfdb995 Binary files /dev/null and b/pr-1714/assets/images/releases/19.10.0/new-agents-page-static-agents-36c50ab2.png differ diff --git a/pr-1714/assets/images/releases/19.11.0/environments-page-8e483812.png b/pr-1714/assets/images/releases/19.11.0/environments-page-8e483812.png new file mode 100644 index 000000000..31f15714c Binary files /dev/null and b/pr-1714/assets/images/releases/19.11.0/environments-page-8e483812.png differ diff --git a/pr-1714/assets/images/releases/19.11.0/pipelines-page-312b6290.png b/pr-1714/assets/images/releases/19.11.0/pipelines-page-312b6290.png new file mode 100644 index 000000000..074377860 Binary files /dev/null and b/pr-1714/assets/images/releases/19.11.0/pipelines-page-312b6290.png differ diff --git a/pr-1714/assets/images/releases/19.11.0/server-config-page-cf024239.png b/pr-1714/assets/images/releases/19.11.0/server-config-page-cf024239.png new file mode 100644 index 000000000..c69498b08 Binary files /dev/null and b/pr-1714/assets/images/releases/19.11.0/server-config-page-cf024239.png differ diff --git a/pr-1714/assets/images/releases/19.11.0/templates-page-cdfccb06.png b/pr-1714/assets/images/releases/19.11.0/templates-page-cdfccb06.png new file mode 100644 index 000000000..2e8a25864 Binary files /dev/null and b/pr-1714/assets/images/releases/19.11.0/templates-page-cdfccb06.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/agent-job-run-history-a5954e57.png b/pr-1714/assets/images/releases/19.12.0/agent-job-run-history-a5954e57.png new file mode 100644 index 000000000..43aa66053 Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/agent-job-run-history-a5954e57.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/agent-job-state-transition-993dae0a.png b/pr-1714/assets/images/releases/19.12.0/agent-job-state-transition-993dae0a.png new file mode 100644 index 000000000..9309fd53d Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/agent-job-state-transition-993dae0a.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png b/pr-1714/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png new file mode 100644 index 000000000..7824b1c39 Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/elastic-profile-0d215002.png b/pr-1714/assets/images/releases/19.12.0/elastic-profile-0d215002.png new file mode 100644 index 000000000..1d70aa14e Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/elastic-profile-0d215002.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/landing-page-77146027.png b/pr-1714/assets/images/releases/19.12.0/landing-page-77146027.png new file mode 100644 index 000000000..e8cac420a Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/landing-page-77146027.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/pipeline-activity-23b57419.png b/pr-1714/assets/images/releases/19.12.0/pipeline-activity-23b57419.png new file mode 100644 index 000000000..4be15a7a4 Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/pipeline-activity-23b57419.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/pipeline-activity-comment-d715f3e2.png b/pr-1714/assets/images/releases/19.12.0/pipeline-activity-comment-d715f3e2.png new file mode 100644 index 000000000..8810f5677 Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/pipeline-activity-comment-d715f3e2.png differ diff --git a/pr-1714/assets/images/releases/19.12.0/read-only-pipeline-859d7dec.png b/pr-1714/assets/images/releases/19.12.0/read-only-pipeline-859d7dec.png new file mode 100644 index 000000000..6a88b1717 Binary files /dev/null and b/pr-1714/assets/images/releases/19.12.0/read-only-pipeline-859d7dec.png differ diff --git a/pr-1714/assets/images/releases/19.2.0/admin-access-token-70620ea3.gif b/pr-1714/assets/images/releases/19.2.0/admin-access-token-70620ea3.gif new file mode 100644 index 000000000..61c9c3605 Binary files /dev/null and b/pr-1714/assets/images/releases/19.2.0/admin-access-token-70620ea3.gif differ diff --git a/pr-1714/assets/images/releases/19.2.0/config_repo_improvements-af73b808.png b/pr-1714/assets/images/releases/19.2.0/config_repo_improvements-af73b808.png new file mode 100644 index 000000000..9254e53f9 Binary files /dev/null and b/pr-1714/assets/images/releases/19.2.0/config_repo_improvements-af73b808.png differ diff --git a/pr-1714/assets/images/releases/19.2.0/personal-access-token-4768f301.gif b/pr-1714/assets/images/releases/19.2.0/personal-access-token-4768f301.gif new file mode 100644 index 000000000..adbc47404 Binary files /dev/null and b/pr-1714/assets/images/releases/19.2.0/personal-access-token-4768f301.gif differ diff --git a/pr-1714/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png b/pr-1714/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png new file mode 100644 index 000000000..395a57d75 Binary files /dev/null and b/pr-1714/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png differ diff --git a/pr-1714/assets/images/releases/19.2.0/user-management-spa-7977dd9a.gif b/pr-1714/assets/images/releases/19.2.0/user-management-spa-7977dd9a.gif new file mode 100644 index 000000000..58c7fc44c Binary files /dev/null and b/pr-1714/assets/images/releases/19.2.0/user-management-spa-7977dd9a.gif differ diff --git a/pr-1714/assets/images/releases/19.3.0/backup-2504b1e5.png b/pr-1714/assets/images/releases/19.3.0/backup-2504b1e5.png new file mode 100644 index 000000000..a14277e0b Binary files /dev/null and b/pr-1714/assets/images/releases/19.3.0/backup-2504b1e5.png differ diff --git a/pr-1714/assets/images/releases/19.3.0/elastic_profile-51501be1.png b/pr-1714/assets/images/releases/19.3.0/elastic_profile-51501be1.png new file mode 100644 index 000000000..f9dc83bc6 Binary files /dev/null and b/pr-1714/assets/images/releases/19.3.0/elastic_profile-51501be1.png differ diff --git a/pr-1714/assets/images/releases/19.6.0/secret-config-spa-cda210eb.gif b/pr-1714/assets/images/releases/19.6.0/secret-config-spa-cda210eb.gif new file mode 100644 index 000000000..505d0f3f3 Binary files /dev/null and b/pr-1714/assets/images/releases/19.6.0/secret-config-spa-cda210eb.gif differ diff --git a/pr-1714/assets/images/releases/19.8.0/new-pipeline-wizard-b98bde85.gif b/pr-1714/assets/images/releases/19.8.0/new-pipeline-wizard-b98bde85.gif new file mode 100644 index 000000000..ae711b6f8 Binary files /dev/null and b/pr-1714/assets/images/releases/19.8.0/new-pipeline-wizard-b98bde85.gif differ diff --git a/pr-1714/assets/images/releases/20.1.0/pipeline_grp_edit-ac8877a7.png b/pr-1714/assets/images/releases/20.1.0/pipeline_grp_edit-ac8877a7.png new file mode 100644 index 000000000..ce1c0a53e Binary files /dev/null and b/pr-1714/assets/images/releases/20.1.0/pipeline_grp_edit-ac8877a7.png differ diff --git a/pr-1714/assets/images/releases/20.3.0/comparison_spa-085ed386.png b/pr-1714/assets/images/releases/20.3.0/comparison_spa-085ed386.png new file mode 100644 index 000000000..eefef324c Binary files /dev/null and b/pr-1714/assets/images/releases/20.3.0/comparison_spa-085ed386.png differ diff --git a/pr-1714/assets/images/releases/20.3.0/package_repository_spa-9ac4e2cd.png b/pr-1714/assets/images/releases/20.3.0/package_repository_spa-9ac4e2cd.png new file mode 100644 index 000000000..9ca1887dd Binary files /dev/null and b/pr-1714/assets/images/releases/20.3.0/package_repository_spa-9ac4e2cd.png differ diff --git a/pr-1714/assets/images/releases/20.3.0/pluggable_scm_spa-32d3f3ac.png b/pr-1714/assets/images/releases/20.3.0/pluggable_scm_spa-32d3f3ac.png new file mode 100644 index 000000000..033dfab5a Binary files /dev/null and b/pr-1714/assets/images/releases/20.3.0/pluggable_scm_spa-32d3f3ac.png differ diff --git a/pr-1714/assets/images/releases/20.4.0/pipeline-config-spa-68c3e3f8.gif b/pr-1714/assets/images/releases/20.4.0/pipeline-config-spa-68c3e3f8.gif new file mode 100644 index 000000000..e8743f001 Binary files /dev/null and b/pr-1714/assets/images/releases/20.4.0/pipeline-config-spa-68c3e3f8.gif differ diff --git a/pr-1714/assets/images/releases/20.5.0/template_authorization_spa-e6c515e8.png b/pr-1714/assets/images/releases/20.5.0/template_authorization_spa-e6c515e8.png new file mode 100644 index 000000000..9462b3484 Binary files /dev/null and b/pr-1714/assets/images/releases/20.5.0/template_authorization_spa-e6c515e8.png differ diff --git a/pr-1714/assets/images/releases/20.6.0/pipeline_as_code_wizard-f66fe5df.png b/pr-1714/assets/images/releases/20.6.0/pipeline_as_code_wizard-f66fe5df.png new file mode 100644 index 000000000..3d4e694ef Binary files /dev/null and b/pr-1714/assets/images/releases/20.6.0/pipeline_as_code_wizard-f66fe5df.png differ diff --git a/pr-1714/assets/images/releases/20.7.0/stage_overview-0e769ece.gif b/pr-1714/assets/images/releases/20.7.0/stage_overview-0e769ece.gif new file mode 100644 index 000000000..09f3d2b09 Binary files /dev/null and b/pr-1714/assets/images/releases/20.7.0/stage_overview-0e769ece.gif differ diff --git a/pr-1714/assets/images/releases/20.8.0/materials_spa-3c79018e.gif b/pr-1714/assets/images/releases/20.8.0/materials_spa-3c79018e.gif new file mode 100644 index 000000000..0db362bb2 Binary files /dev/null and b/pr-1714/assets/images/releases/20.8.0/materials_spa-3c79018e.gif differ diff --git a/pr-1714/assets/images/releases/20.8.0/stage_overview-5293c27c.png b/pr-1714/assets/images/releases/20.8.0/stage_overview-5293c27c.png new file mode 100644 index 000000000..12301b4a1 Binary files /dev/null and b/pr-1714/assets/images/releases/20.8.0/stage_overview-5293c27c.png differ diff --git a/pr-1714/assets/images/releases/20.9.0/preference_page-31d0b157.png b/pr-1714/assets/images/releases/20.9.0/preference_page-31d0b157.png new file mode 100644 index 000000000..2838cf5bb Binary files /dev/null and b/pr-1714/assets/images/releases/20.9.0/preference_page-31d0b157.png differ diff --git a/pr-1714/assets/images/releases/20.9.0/stage_instances-62e0f62d.png b/pr-1714/assets/images/releases/20.9.0/stage_instances-62e0f62d.png new file mode 100644 index 000000000..9ed4b29b4 Binary files /dev/null and b/pr-1714/assets/images/releases/20.9.0/stage_instances-62e0f62d.png differ diff --git a/pr-1714/assets/images/releases/20.9.0/stage_overview-347bb105.png b/pr-1714/assets/images/releases/20.9.0/stage_overview-347bb105.png new file mode 100644 index 000000000..fd5720ff2 Binary files /dev/null and b/pr-1714/assets/images/releases/20.9.0/stage_overview-347bb105.png differ diff --git a/pr-1714/assets/images/releases/21.1.0/config_repo_webhook-a1e13cb6.png b/pr-1714/assets/images/releases/21.1.0/config_repo_webhook-a1e13cb6.png new file mode 100644 index 000000000..c53d70fb4 Binary files /dev/null and b/pr-1714/assets/images/releases/21.1.0/config_repo_webhook-a1e13cb6.png differ diff --git a/pr-1714/assets/images/releases/23.1.0/personalization_config-5bb66d39.png b/pr-1714/assets/images/releases/23.1.0/personalization_config-5bb66d39.png new file mode 100644 index 000000000..c9d4a1322 Binary files /dev/null and b/pr-1714/assets/images/releases/23.1.0/personalization_config-5bb66d39.png differ diff --git a/pr-1714/assets/images/rss-icon-d175b643.png b/pr-1714/assets/images/rss-icon-d175b643.png new file mode 100644 index 000000000..29fc01483 Binary files /dev/null and b/pr-1714/assets/images/rss-icon-d175b643.png differ diff --git a/pr-1714/assets/images/screenshots/agents-a2ea5e8d.png b/pr-1714/assets/images/screenshots/agents-a2ea5e8d.png new file mode 100644 index 000000000..ede6adbd2 Binary files /dev/null and b/pr-1714/assets/images/screenshots/agents-a2ea5e8d.png differ diff --git a/pr-1714/assets/images/screenshots/console-timestamp-5541d6ce.png b/pr-1714/assets/images/screenshots/console-timestamp-5541d6ce.png new file mode 100644 index 000000000..10afd1248 Binary files /dev/null and b/pr-1714/assets/images/screenshots/console-timestamp-5541d6ce.png differ diff --git a/pr-1714/assets/images/screenshots/dashboard-fa9a3fa2.png b/pr-1714/assets/images/screenshots/dashboard-fa9a3fa2.png new file mode 100644 index 000000000..0e9d9d262 Binary files /dev/null and b/pr-1714/assets/images/screenshots/dashboard-fa9a3fa2.png differ diff --git a/pr-1714/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg b/pr-1714/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg new file mode 100644 index 000000000..512807c82 Binary files /dev/null and b/pr-1714/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg differ diff --git a/pr-1714/assets/images/screenshots/thumb/console-with-timestamps-dpr-2-c597ddc1.jpg b/pr-1714/assets/images/screenshots/thumb/console-with-timestamps-dpr-2-c597ddc1.jpg new file mode 100644 index 000000000..6ce217fe3 Binary files /dev/null and b/pr-1714/assets/images/screenshots/thumb/console-with-timestamps-dpr-2-c597ddc1.jpg differ diff --git a/pr-1714/assets/images/screenshots/thumb/dashboard-one-red-dpr-2-16cd5841.jpg b/pr-1714/assets/images/screenshots/thumb/dashboard-one-red-dpr-2-16cd5841.jpg new file mode 100644 index 000000000..dceda6fcc Binary files /dev/null and b/pr-1714/assets/images/screenshots/thumb/dashboard-one-red-dpr-2-16cd5841.jpg differ diff --git a/pr-1714/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg b/pr-1714/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg new file mode 100644 index 000000000..3187de483 Binary files /dev/null and b/pr-1714/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg differ diff --git a/pr-1714/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg b/pr-1714/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg new file mode 100644 index 000000000..f317464cb Binary files /dev/null and b/pr-1714/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg differ diff --git a/pr-1714/assets/images/screenshots/vsm-795421ee.png b/pr-1714/assets/images/screenshots/vsm-795421ee.png new file mode 100644 index 000000000..3f00516bd Binary files /dev/null and b/pr-1714/assets/images/screenshots/vsm-795421ee.png differ diff --git a/pr-1714/assets/images/see-how-things-really-work-39fbef93.png b/pr-1714/assets/images/see-how-things-really-work-39fbef93.png new file mode 100644 index 000000000..abd234cea Binary files /dev/null and b/pr-1714/assets/images/see-how-things-really-work-39fbef93.png differ diff --git a/pr-1714/assets/images/see-how-things-work-ff28c0ec.png b/pr-1714/assets/images/see-how-things-work-ff28c0ec.png new file mode 100644 index 000000000..b3ac82315 Binary files /dev/null and b/pr-1714/assets/images/see-how-things-work-ff28c0ec.png differ diff --git a/pr-1714/assets/images/texture-bg-2-9c21c423.jpg b/pr-1714/assets/images/texture-bg-2-9c21c423.jpg new file mode 100644 index 000000000..5e5d57662 Binary files /dev/null and b/pr-1714/assets/images/texture-bg-2-9c21c423.jpg differ diff --git a/pr-1714/assets/images/texture-bg-35f0b9ad.jpg b/pr-1714/assets/images/texture-bg-35f0b9ad.jpg new file mode 100644 index 000000000..b90aa9ae6 Binary files /dev/null and b/pr-1714/assets/images/texture-bg-35f0b9ad.jpg differ diff --git a/pr-1714/assets/images/texture-bg-grey-8c7af6fc.jpg b/pr-1714/assets/images/texture-bg-grey-8c7af6fc.jpg new file mode 100644 index 000000000..7ba93c876 Binary files /dev/null and b/pr-1714/assets/images/texture-bg-grey-8c7af6fc.jpg differ diff --git a/pr-1714/assets/images/timestamps-in-console-logs-example-eb317f14.png b/pr-1714/assets/images/timestamps-in-console-logs-example-eb317f14.png new file mode 100644 index 000000000..b484fcb21 Binary files /dev/null and b/pr-1714/assets/images/timestamps-in-console-logs-example-eb317f14.png differ diff --git a/pr-1714/assets/images/version-bg-ad19c611.png b/pr-1714/assets/images/version-bg-ad19c611.png new file mode 100644 index 000000000..e2c8c469b Binary files /dev/null and b/pr-1714/assets/images/version-bg-ad19c611.png differ diff --git a/pr-1714/assets/images/video.mov b/pr-1714/assets/images/video.mov new file mode 100644 index 000000000..02b91ddba Binary files /dev/null and b/pr-1714/assets/images/video.mov differ diff --git a/pr-1714/assets/images/videos/go-command-repo-4cd595b8.jpg b/pr-1714/assets/images/videos/go-command-repo-4cd595b8.jpg new file mode 100644 index 000000000..f45960875 Binary files /dev/null and b/pr-1714/assets/images/videos/go-command-repo-4cd595b8.jpg differ diff --git a/pr-1714/assets/images/videos/go-failed-smoke-test-82510d2b.jpg b/pr-1714/assets/images/videos/go-failed-smoke-test-82510d2b.jpg new file mode 100644 index 000000000..fea0d5141 Binary files /dev/null and b/pr-1714/assets/images/videos/go-failed-smoke-test-82510d2b.jpg differ diff --git a/pr-1714/assets/images/videos/go-fan-out-fan-dda14cdd.jpg b/pr-1714/assets/images/videos/go-fan-out-fan-dda14cdd.jpg new file mode 100644 index 000000000..aed4e6ddd Binary files /dev/null and b/pr-1714/assets/images/videos/go-fan-out-fan-dda14cdd.jpg differ diff --git a/pr-1714/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg b/pr-1714/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg new file mode 100644 index 000000000..a6e2d14e0 Binary files /dev/null and b/pr-1714/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg differ diff --git a/pr-1714/assets/images/videos/go-linking-dependencies-f51246fd.jpg b/pr-1714/assets/images/videos/go-linking-dependencies-f51246fd.jpg new file mode 100644 index 000000000..9841122f5 Binary files /dev/null and b/pr-1714/assets/images/videos/go-linking-dependencies-f51246fd.jpg differ diff --git a/pr-1714/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg b/pr-1714/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg new file mode 100644 index 000000000..32c62d3c8 Binary files /dev/null and b/pr-1714/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg differ diff --git a/pr-1714/assets/images/videos/go-value-stream-map-d215777c.jpg b/pr-1714/assets/images/videos/go-value-stream-map-d215777c.jpg new file mode 100644 index 000000000..d1d146e1d Binary files /dev/null and b/pr-1714/assets/images/videos/go-value-stream-map-d215777c.jpg differ diff --git a/pr-1714/assets/images/vms-build-time-7ae5af26.jpg b/pr-1714/assets/images/vms-build-time-7ae5af26.jpg new file mode 100644 index 000000000..f1150508e Binary files /dev/null and b/pr-1714/assets/images/vms-build-time-7ae5af26.jpg differ diff --git a/pr-1714/assets/javascripts/all-10e8d5d5.js b/pr-1714/assets/javascripts/all-10e8d5d5.js new file mode 100644 index 000000000..a54da4b87 --- /dev/null +++ b/pr-1714/assets/javascripts/all-10e8d5d5.js @@ -0,0 +1,34 @@ +function writeText(t){return new Promise(function(e,n){function i(e){e.clipboardData.setData("text/plain",t),e.preventDefault(),r=!0}var r=!1;document.addEventListener("copy",i),document.execCommand("copy"),document.removeEventListener("copy",i),r?e():n()})}function additionalArch(t){return Object.keys(t).filter(function(t){return t.startsWith("server-")}).map(function(t){return t.substring("server-".length)})}function showPopup(){$(".banner-fixed-bottom").addClass("show-banner")}!function(t,e){"object"==typeof exports&&"undefined"!=typeof module?e():"function"==typeof define&&define.amd?define(e):e()}(0,function(){"use strict";function t(t){var e=this.constructor;return this.then(function(n){return e.resolve(t()).then(function(){return n})},function(n){return e.resolve(t()).then(function(){return e.reject(n)})})}function e(t){return!(!t||"undefined"==typeof t.length)}function n(){}function i(t){if(!(this instanceof i))throw new TypeError("Promises must be constructed via new");if("function"!=typeof t)throw new TypeError("not a function");this._state=0,this._handled=!1,this._value=undefined,this._deferreds=[],u(t,this)}function r(t,e){for(;3===t._state;)t=t._value;0!==t._state?(t._handled=!0,i._immediateFn(function(){var n=1===t._state?e.onFulfilled:e.onRejected;if(null!==n){var i;try{i=n(t._value)}catch(t){return void s(e.promise,t)}o(e.promise,i)}else(1===t._state?o:s)(e.promise,t._value)})):t._deferreds.push(e)}function o(t,e){try{if(e===t)throw new TypeError("A promise cannot be resolved with itself.");if(e&&("object"==typeof e||"function"==typeof e)){var n=e.then;if(e instanceof i)return t._state=3,t._value=e,void a(t);if("function"==typeof n)return void u(function(t,e){return function(){t.apply(e,arguments)}}(n,e),t)}t._state=1,t._value=e,a(t)}catch(e){s(t,e)}}function s(t,e){t._state=2,t._value=e,a(t)}function a(t){2===t._state&&0===t._deferreds.length&&i._immediateFn(function(){t._handled||i._unhandledRejectionFn(t._value)});for(var e=0,n=t._deferreds.length;n>e;e++)r(t,t._deferreds[e]);t._deferreds=null}function u(t,e){var n=!1;try{t(function(t){n||(n=!0,o(e,t))},function(t){n||(n=!0,s(e,t))})}catch(t){if(n)return;n=!0,s(e,t)}}var c=setTimeout;i.prototype["catch"]=function(t){return this.then(null,t)},i.prototype.then=function(t,e){var i=new this.constructor(n);return r(this,new function(t,e,n){this.onFulfilled="function"==typeof t?t:null,this.onRejected="function"==typeof e?e:null,this.promise=n}(t,e,i)),i},i.prototype["finally"]=t,i.all=function(t){return new i(function(n,i){function r(t,e){try{if(e&&("object"==typeof e||"function"==typeof e)){var a=e.then;if("function"==typeof a)return void a.call(e,function(e){r(t,e)},i)}o[t]=e,0==--s&&n(o)}catch(t){i(t)}}if(!e(t))return i(new TypeError("Promise.all accepts an array"));var o=Array.prototype.slice.call(t);if(0===o.length)return n([]);for(var s=o.length,a=0;o.length>a;a++)r(a,o[a])})},i.resolve=function(t){return t&&"object"==typeof t&&t.constructor===i?t:new i(function(e){e(t)})},i.reject=function(t){return new i(function(e,n){n(t)})},i.race=function(t){return new i(function(n,r){if(!e(t))return r(new TypeError("Promise.race accepts an array"));for(var o=0,s=t.length;s>o;o++)i.resolve(t[o]).then(n,r)})},i._immediateFn="function"==typeof setImmediate&&function(t){setImmediate(t)}||function(t){c(t,0)},i._unhandledRejectionFn=function(t){void 0!==console&&console&&console.warn("Possible Unhandled Promise Rejection:",t)};var l=function(){if("undefined"!=typeof self)return self;if("undefined"!=typeof window)return window;if("undefined"!=typeof global)return global;throw Error("unable to locate global object")}();"Promise"in l?l.Promise.prototype["finally"]||(l.Promise.prototype["finally"]=t):l.Promise=i});var _self="undefined"!=typeof window?window:"undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?self:{},Prism=function(t){function e(t,e,n,i,r){this.type=t,this.content=e,this.alias=n,this.length=0|(i||"").length,this.greedy=!!r}var n=/\blang(?:uage)?-([\w-]+)\b/i,i=0,r={manual:t.Prism&&t.Prism.manual,disableWorkerMessageHandler:t.Prism&&t.Prism.disableWorkerMessageHandler,util:{encode:function(t){return t instanceof e?new e(t.type,r.util.encode(t.content),t.alias):Array.isArray(t)?t.map(r.util.encode):t.replace(/&/g,"&").replace(/t.length)return;if(!(x instanceof e)){if(m&&b!=n.length-1){if(p.lastIndex=w,!(T=p.exec(t)))break;for(var S=T.index+(d?T[1].length:0),k=T.index+T[0].length,C=b,E=w,_=n.length;C<_&&(E"+i.content+""},!t.document)return t.addEventListener&&(r.disableWorkerMessageHandler||t.addEventListener("message",function(e){var n=JSON.parse(e.data),i=n.language,o=n.code,s=n.immediateClose;t.postMessage(r.highlight(o,r.languages[i],i)),s&&t.close()},!1)),r;var o=document.currentScript||[].slice.call(document.getElementsByTagName("script")).pop();return o&&(r.filename=o.src,r.manual||o.hasAttribute("data-manual")||("loading"!==document.readyState?window.requestAnimationFrame?window.requestAnimationFrame(r.highlightAll):window.setTimeout(r.highlightAll,16):document.addEventListener("DOMContentLoaded",r.highlightAll))),r}(_self);"undefined"!=typeof module&&module.exports&&(module.exports=Prism),"undefined"!=typeof global&&(global.Prism=Prism),function(t){var e="\\b(?:BASH|BASHOPTS|BASH_ALIASES|BASH_ARGC|BASH_ARGV|BASH_CMDS|BASH_COMPLETION_COMPAT_DIR|BASH_LINENO|BASH_REMATCH|BASH_SOURCE|BASH_VERSINFO|BASH_VERSION|COLORTERM|COLUMNS|COMP_WORDBREAKS|DBUS_SESSION_BUS_ADDRESS|DEFAULTS_PATH|DESKTOP_SESSION|DIRSTACK|DISPLAY|EUID|GDMSESSION|GDM_LANG|GNOME_KEYRING_CONTROL|GNOME_KEYRING_PID|GPG_AGENT_INFO|GROUPS|HISTCONTROL|HISTFILE|HISTFILESIZE|HISTSIZE|HOME|HOSTNAME|HOSTTYPE|IFS|INSTANCE|JOB|LANG|LANGUAGE|LC_ADDRESS|LC_ALL|LC_IDENTIFICATION|LC_MEASUREMENT|LC_MONETARY|LC_NAME|LC_NUMERIC|LC_PAPER|LC_TELEPHONE|LC_TIME|LESSCLOSE|LESSOPEN|LINES|LOGNAME|LS_COLORS|MACHTYPE|MAILCHECK|MANDATORY_PATH|NO_AT_BRIDGE|OLDPWD|OPTERR|OPTIND|ORBIT_SOCKETDIR|OSTYPE|PAPERSIZE|PATH|PIPESTATUS|PPID|PS1|PS2|PS3|PS4|PWD|RANDOM|REPLY|SECONDS|SELINUX_INIT|SESSION|SESSIONTYPE|SESSION_MANAGER|SHELL|SHELLOPTS|SHLVL|SSH_AUTH_SOCK|TERM|UID|UPSTART_EVENTS|UPSTART_INSTANCE|UPSTART_JOB|UPSTART_SESSION|USER|WINDOWID|XAUTHORITY|XDG_CONFIG_DIRS|XDG_CURRENT_DESKTOP|XDG_DATA_DIRS|XDG_GREETER_DATA_DIR|XDG_MENU_PREFIX|XDG_RUNTIME_DIR|XDG_SEAT|XDG_SEAT_PATH|XDG_SESSION_DESKTOP|XDG_SESSION_ID|XDG_SESSION_PATH|XDG_SESSION_TYPE|XDG_VTNR|XMODIFIERS)\\b",n={environment:{pattern:RegExp("\\$"+e),alias:"constant"},variable:[{pattern:/\$?\(\([\s\S]+?\)\)/,greedy:!0,inside:{variable:[{pattern:/(^\$\(\([\s\S]+)\)\)/,lookbehind:!0},/^\$\(\(/],number:/\b0x[\dA-Fa-f]+\b|(?:\b\d+\.?\d*|\B\.\d+)(?:[Ee]-?\d+)?/,operator:/--?|-=|\+\+?|\+=|!=?|~|\*\*?|\*=|\/=?|%=?|<<=?|>>=?|<=?|>=?|==?|&&?|&=|\^=?|\|\|?|\|=|\?|:/,punctuation:/\(\(?|\)\)?|,|;/}},{pattern:/\$\((?:\([^)]+\)|[^()])+\)|`[^`]+`/,greedy:!0,inside:{variable:/^\$\(|^`|\)$|`$/}},{pattern:/\$\{[^}]+\}/,greedy:!0,inside:{operator:/:[-=?+]?|[!\/]|##?|%%?|\^\^?|,,?/,punctuation:/[\[\]]/,environment:{pattern:RegExp("(\\{)"+e),lookbehind:!0,alias:"constant"}}},/\$(?:\w+|[#?*!@$])/],entity:/\\(?:[abceEfnrtv\\"]|O?[0-7]{1,3}|x[0-9a-fA-F]{1,2}|u[0-9a-fA-F]{4}|U[0-9a-fA-F]{8})/};t.languages.bash={shebang:{pattern:/^#!\s*\/.*/,alias:"important"},comment:{pattern:/(^|[^"{\\$])#.*/,lookbehind:!0},"function-name":[{pattern:/(\bfunction\s+)\w+(?=(?:\s*\(?:\s*\))?\s*\{)/,lookbehind:!0,alias:"function"},{pattern:/\b\w+(?=\s*\(\s*\)\s*\{)/,alias:"function"}],"for-or-select":{pattern:/(\b(?:for|select)\s+)\w+(?=\s+in\s)/,alias:"variable",lookbehind:!0},"assign-left":{pattern:/(^|[\s;|&]|[<>]\()\w+(?=\+?=)/,inside:{environment:{pattern:RegExp("(^|[\\s;|&]|[<>]\\()"+e),lookbehind:!0,alias:"constant"}},alias:"variable",lookbehind:!0},string:[{pattern:/((?:^|[^<])<<-?\s*)(\w+?)\s*(?:\r?\n|\r)(?:[\s\S])*?(?:\r?\n|\r)\2/,lookbehind:!0,greedy:!0,inside:n},{pattern:/((?:^|[^<])<<-?\s*)(["'])(\w+)\2\s*(?:\r?\n|\r)(?:[\s\S])*?(?:\r?\n|\r)\3/,lookbehind:!0,greedy:!0},{pattern:/(["'])(?:\\[\s\S]|\$\([^)]+\)|`[^`]+`|(?!\1)[^\\])*\1/,greedy:!0,inside:n}],environment:{pattern:RegExp("\\$?"+e),alias:"constant"},variable:n.variable,"function":{pattern:/(^|[\s;|&]|[<>]\()(?:add|apropos|apt|aptitude|apt-cache|apt-get|aspell|automysqlbackup|awk|basename|bash|bc|bconsole|bg|bzip2|cal|cat|cfdisk|chgrp|chkconfig|chmod|chown|chroot|cksum|clear|cmp|column|comm|cp|cron|crontab|csplit|curl|cut|date|dc|dd|ddrescue|debootstrap|df|diff|diff3|dig|dir|dircolors|dirname|dirs|dmesg|du|egrep|eject|env|ethtool|expand|expect|expr|fdformat|fdisk|fg|fgrep|file|find|fmt|fold|format|free|fsck|ftp|fuser|gawk|git|gparted|grep|groupadd|groupdel|groupmod|groups|grub-mkconfig|gzip|halt|head|hg|history|host|hostname|htop|iconv|id|ifconfig|ifdown|ifup|import|install|ip|jobs|join|kill|killall|less|link|ln|locate|logname|logrotate|look|lpc|lpr|lprint|lprintd|lprintq|lprm|ls|lsof|lynx|make|man|mc|mdadm|mkconfig|mkdir|mke2fs|mkfifo|mkfs|mkisofs|mknod|mkswap|mmv|more|most|mount|mtools|mtr|mutt|mv|nano|nc|netstat|nice|nl|nohup|notify-send|npm|nslookup|op|open|parted|passwd|paste|pathchk|ping|pkill|pnpm|popd|pr|printcap|printenv|ps|pushd|pv|quota|quotacheck|quotactl|ram|rar|rcp|reboot|remsync|rename|renice|rev|rm|rmdir|rpm|rsync|scp|screen|sdiff|sed|sendmail|seq|service|sftp|sh|shellcheck|shuf|shutdown|sleep|slocate|sort|split|ssh|stat|strace|su|sudo|sum|suspend|swapon|sync|tac|tail|tar|tee|time|timeout|top|touch|tr|traceroute|tsort|tty|umount|uname|unexpand|uniq|units|unrar|unshar|unzip|update-grub|uptime|useradd|userdel|usermod|users|uudecode|uuencode|v|vdir|vi|vim|virsh|vmstat|wait|watch|wc|wget|whereis|which|who|whoami|write|xargs|xdg-open|yarn|yes|zenity|zip|zsh|zypper)(?=$|[)\s;|&])/,lookbehind:!0},keyword:{pattern:/(^|[\s;|&]|[<>]\()(?:if|then|else|elif|fi|for|while|in|case|esac|function|select|do|done|until)(?=$|[)\s;|&])/,lookbehind:!0},builtin:{pattern:/(^|[\s;|&]|[<>]\()(?:\.|:|break|cd|continue|eval|exec|exit|export|getopts|hash|pwd|readonly|return|shift|test|times|trap|umask|unset|alias|bind|builtin|caller|command|declare|echo|enable|help|let|local|logout|mapfile|printf|read|readarray|source|type|typeset|ulimit|unalias|set|shopt)(?=$|[)\s;|&])/,lookbehind:!0,alias:"class-name"},"boolean":{pattern:/(^|[\s;|&]|[<>]\()(?:true|false)(?=$|[)\s;|&])/,lookbehind:!0},"file-descriptor":{pattern:/\B&\d\b/,alias:"important"},operator:{pattern:/\d?<>|>\||\+=|==?|!=?|=~|<<[<-]?|[&\d]?>>|\d?[<>]&?|&[>&]?|\|[&|]?|<=?|>=?/,inside:{"file-descriptor":{pattern:/^\d/,alias:"important"}}},punctuation:/\$?\(\(?|\)\)?|\.\.|[{}[\];\\]/,number:{pattern:/(^|\s)(?:[1-9]\d*|0)(?:[.,]\d+)?\b/,lookbehind:!0}};for(var i=["comment","function-name","for-or-select","assign-left","string","environment","function","keyword","builtin","boolean","file-descriptor","operator","punctuation","number"],r=n.variable[1].inside,o=0;o/,lookbehind:!0},{pattern:/(^|[^`])#.*/,lookbehind:!0}],string:[{pattern:/"(?:`[\s\S]|[^`"])*"/,greedy:!0,inside:{"function":{pattern:/(^|[^`])\$\((?:\$\(.*?\)|(?!\$\()[^\r\n)])*\)/,lookbehind:!0,inside:{}}}},{pattern:/'(?:[^']|'')*'/,greedy:!0}],namespace:/\[[a-z](?:\[(?:\[[^\]]*]|[^\[\]])*]|[^\[\]])*]/i,"boolean":/\$(?:true|false)\b/i,variable:/\$\w+\b/i,"function":[/\b(?:Add-(?:Computer|Content|History|Member|PSSnapin|Type)|Checkpoint-Computer|Clear-(?:Content|EventLog|History|Item|ItemProperty|Variable)|Compare-Object|Complete-Transaction|Connect-PSSession|ConvertFrom-(?:Csv|Json|StringData)|Convert-Path|ConvertTo-(?:Csv|Html|Json|Xml)|Copy-(?:Item|ItemProperty)|Debug-Process|Disable-(?:ComputerRestore|PSBreakpoint|PSRemoting|PSSessionConfiguration)|Disconnect-PSSession|Enable-(?:ComputerRestore|PSBreakpoint|PSRemoting|PSSessionConfiguration)|Enter-PSSession|Exit-PSSession|Export-(?:Alias|Clixml|Console|Csv|FormatData|ModuleMember|PSSession)|ForEach-Object|Format-(?:Custom|List|Table|Wide)|Get-(?:Alias|ChildItem|Command|ComputerRestorePoint|Content|ControlPanelItem|Culture|Date|Event|EventLog|EventSubscriber|FormatData|Help|History|Host|HotFix|Item|ItemProperty|Job|Location|Member|Module|Process|PSBreakpoint|PSCallStack|PSDrive|PSProvider|PSSession|PSSessionConfiguration|PSSnapin|Random|Service|TraceSource|Transaction|TypeData|UICulture|Unique|Variable|WmiObject)|Group-Object|Import-(?:Alias|Clixml|Csv|LocalizedData|Module|PSSession)|Invoke-(?:Command|Expression|History|Item|RestMethod|WebRequest|WmiMethod)|Join-Path|Limit-EventLog|Measure-(?:Command|Object)|Move-(?:Item|ItemProperty)|New-(?:Alias|Event|EventLog|Item|ItemProperty|Module|ModuleManifest|Object|PSDrive|PSSession|PSSessionConfigurationFile|PSSessionOption|PSTransportOption|Service|TimeSpan|Variable|WebServiceProxy)|Out-(?:Default|File|GridView|Host|Null|Printer|String)|Pop-Location|Push-Location|Read-Host|Receive-(?:Job|PSSession)|Register-(?:EngineEvent|ObjectEvent|PSSessionConfiguration|WmiEvent)|Remove-(?:Computer|Event|EventLog|Item|ItemProperty|Job|Module|PSBreakpoint|PSDrive|PSSession|PSSnapin|TypeData|Variable|WmiObject)|Rename-(?:Computer|Item|ItemProperty)|Reset-ComputerMachinePassword|Resolve-Path|Restart-(?:Computer|Service)|Restore-Computer|Resume-(?:Job|Service)|Save-Help|Select-(?:Object|String|Xml)|Send-MailMessage|Set-(?:Alias|Content|Date|Item|ItemProperty|Location|PSBreakpoint|PSDebug|PSSessionConfiguration|Service|StrictMode|TraceSource|Variable|WmiInstance)|Show-(?:Command|ControlPanelItem|EventLog)|Sort-Object|Split-Path|Start-(?:Job|Process|Service|Sleep|Transaction)|Stop-(?:Computer|Job|Process|Service)|Suspend-(?:Job|Service)|Tee-Object|Test-(?:ComputerSecureChannel|Connection|ModuleManifest|Path|PSSessionConfigurationFile)|Trace-Command|Unblock-File|Undo-Transaction|Unregister-(?:Event|PSSessionConfiguration)|Update-(?:FormatData|Help|List|TypeData)|Use-Transaction|Wait-(?:Event|Job|Process)|Where-Object|Write-(?:Debug|Error|EventLog|Host|Output|Progress|Verbose|Warning))\b/i,/\b(?:ac|cat|chdir|clc|cli|clp|clv|compare|copy|cp|cpi|cpp|cvpa|dbp|del|diff|dir|ebp|echo|epal|epcsv|epsn|erase|fc|fl|ft|fw|gal|gbp|gc|gci|gcs|gdr|gi|gl|gm|gp|gps|group|gsv|gu|gv|gwmi|iex|ii|ipal|ipcsv|ipsn|irm|iwmi|iwr|kill|lp|ls|measure|mi|mount|move|mp|mv|nal|ndr|ni|nv|ogv|popd|ps|pushd|pwd|rbp|rd|rdr|ren|ri|rm|rmdir|rni|rnp|rp|rv|rvpa|rwmi|sal|saps|sasv|sbp|sc|select|set|shcm|si|sl|sleep|sls|sort|sp|spps|spsv|start|sv|swmi|tee|trcm|type|write)\b/i],keyword:/\b(?:Begin|Break|Catch|Class|Continue|Data|Define|Do|DynamicParam|Else|ElseIf|End|Exit|Filter|Finally|For|ForEach|From|Function|If|InlineScript|Parallel|Param|Process|Return|Sequence|Switch|Throw|Trap|Try|Until|Using|Var|While|Workflow)\b/i,operator:{pattern:/(\W?)(?:!|-(eq|ne|gt|ge|lt|le|sh[lr]|not|b?(?:and|x?or)|(?:Not)?(?:Like|Match|Contains|In)|Replace|Join|is(?:Not)?|as)\b|-[-=]?|\+[+=]?|[*\/%]=?)/i,lookbehind:!0},punctuation:/[|{}[\];(),.]/},e=t.string[0].inside;e["boolean"]=t["boolean"],e.variable=t.variable,e["function"].inside=t}(),function(t,e){"object"==typeof module&&"object"==typeof module.exports?module.exports=t.document?e(t,!0):function(t){if(!t.document)throw new Error("jQuery requires a window with a document");return e(t)}:e(t)}("undefined"!=typeof window?window:this,function(t,e){function n(t){var e=!!t&&"length"in t&&t.length,n=ft.type(t);return"function"!==n&&!ft.isWindow(t)&&("array"===n||0===e||"number"==typeof e&&e>0&&e-1 in t)}function i(t,e,n){if(ft.isFunction(e))return ft.grep(t,function(t,i){return!!e.call(t,i,t)!==n});if(e.nodeType)return ft.grep(t,function(t){return t===e!==n});if("string"==typeof e){if(kt.test(e))return ft.filter(e,t,n);e=ft.filter(e,t)}return ft.grep(t,function(t){return ft.inArray(t,e)>-1!==n})}function r(t,e){do{t=t[e]}while(t&&1!==t.nodeType);return t}function o(t){var e={};return ft.each(t.match(Pt)||[],function(t,n){e[n]=!0}),e}function s(){it.addEventListener?(it.removeEventListener("DOMContentLoaded",a),t.removeEventListener("load",a)):(it.detachEvent("onreadystatechange",a),t.detachEvent("onload",a))}function a(){(it.addEventListener||"load"===t.event.type||"complete"===it.readyState)&&(s(),ft.ready())}function u(t,e,n){if(void 0===n&&1===t.nodeType){var i="data-"+e.replace(Lt,"-$1").toLowerCase();if("string"==typeof(n=t.getAttribute(i))){try{n="true"===n||"false"!==n&&("null"===n?null:+n+""===n?+n:It.test(n)?ft.parseJSON(n):n)}catch(t){}ft.data(t,e,n)}else n=void 0}return n}function c(t){var e;for(e in t)if(("data"!==e||!ft.isEmptyObject(t[e]))&&"toJSON"!==e)return!1;return!0}function l(t,e,n,i){if(At(t)){var r,o,s=ft.expando,a=t.nodeType,u=a?ft.cache:t,c=a?t[s]:t[s]&&s;if(c&&u[c]&&(i||u[c].data)||void 0!==n||"string"!=typeof e)return c||(c=a?t[s]=nt.pop()||ft.guid++:s),u[c]||(u[c]=a?{}:{toJSON:ft.noop}),"object"!=typeof e&&"function"!=typeof e||(i?u[c]=ft.extend(u[c],e):u[c].data=ft.extend(u[c].data,e)),o=u[c],i||(o.data||(o.data={}),o=o.data),void 0!==n&&(o[ft.camelCase(e)]=n),"string"==typeof e?null==(r=o[e])&&(r=o[ft.camelCase(e)]):r=o,r}}function h(t,e,n){if(At(t)){var i,r,o=t.nodeType,s=o?ft.cache:t,a=o?t[ft.expando]:ft.expando;if(s[a]){if(e&&(i=n?s[a]:s[a].data)){ft.isArray(e)?e=e.concat(ft.map(e,ft.camelCase)):e in i?e=[e]:(e=ft.camelCase(e),e=e in i?[e]:e.split(" ")),r=e.length;for(;r--;)delete i[e[r]];if(n?!c(i):!ft.isEmptyObject(i))return}(n||(delete s[a].data,c(s[a])))&&(o?ft.cleanData([t],!0):ht.deleteExpando||s!=s.window?delete s[a]:s[a]=void 0)}}}function p(t,e,n,i){var r,o=1,s=20,a=i?function(){return i.cur()}:function(){return ft.css(t,e,"")},u=a(),c=n&&n[3]||(ft.cssNumber[e]?"":"px"),l=(ft.cssNumber[e]||"px"!==c&&+u)&&jt.exec(ft.css(t,e));if(l&&l[3]!==c){c=c||l[3],n=n||[],l=+u||1;do{o=o||".5",l/=o,ft.style(t,e,l+c)}while(o!==(o=a()/u)&&1!==o&&--s)}return n&&(l=+l||+u||0,r=n[1]?l+(n[1]+1)*n[2]:+n[2],i&&(i.unit=c,i.start=l,i.end=r)),r}function f(t){var e=qt.split("|"),n=t.createDocumentFragment();if(n.createElement)for(;e.length;)n.createElement(e.pop());return n}function d(t,e){var n,i,r=0,o="undefined"!=typeof t.getElementsByTagName?t.getElementsByTagName(e||"*"):"undefined"!=typeof t.querySelectorAll?t.querySelectorAll(e||"*"):void 0;if(!o)for(o=[],n=t.childNodes||t;null!=(i=n[r]);r++)!e||ft.nodeName(i,e)?o.push(i):ft.merge(o,d(i,e));return void 0===e||e&&ft.nodeName(t,e)?ft.merge([t],o):o}function m(t,e){for(var n,i=0;null!=(n=t[i]);i++)ft._data(n,"globalEval",!e||ft._data(e[i],"globalEval"))}function g(t){Ht.test(t.type)&&(t.defaultChecked=t.checked)}function v(t,e,n,i,r){for(var o,s,a,u,c,l,h,p=t.length,v=f(e),y=[],b=0;p>b;b++)if((s=t[b])||0===s)if("object"===ft.type(s))ft.merge(y,s.nodeType?[s]:s);else if(Ut.test(s)){for(u=u||v.appendChild(e.createElement("div")),c=(Ft.exec(s)||["",""])[1].toLowerCase(),h=Wt[c]||Wt._default,u.innerHTML=h[1]+ft.htmlPrefilter(s)+h[2],o=h[0];o--;)u=u.lastChild;if(!ht.leadingWhitespace&&zt.test(s)&&y.push(e.createTextNode(zt.exec(s)[0])),!ht.tbody)for(s="table"!==c||Vt.test(s)?""!==h[1]||Vt.test(s)?0:u:u.firstChild,o=s&&s.childNodes.length;o--;)ft.nodeName(l=s.childNodes[o],"tbody")&&!l.childNodes.length&&s.removeChild(l);for(ft.merge(y,u.childNodes),u.textContent="";u.firstChild;)u.removeChild(u.firstChild);u=v.lastChild}else y.push(e.createTextNode(s));for(u&&v.removeChild(u),ht.appendChecked||ft.grep(d(y,"input"),g),b=0;s=y[b++];)if(i&&ft.inArray(s,i)>-1)r&&r.push(s);else if(a=ft.contains(s.ownerDocument,s),u=d(v.appendChild(s),"script"),a&&m(u),n)for(o=0;s=u[o++];)Bt.test(s.type||"")&&n.push(s);return u=null,v}function y(){return!0}function b(){return!1}function w(){try{return it.activeElement}catch(t){}}function x(t,e,n,i,r,o){var s,a;if("object"==typeof e){"string"!=typeof n&&(i=i||n,n=void 0);for(a in e)x(t,a,n,i,e[a],o);return t}if(null==i&&null==r?(r=n,i=n=void 0):null==r&&("string"==typeof n?(r=i,i=void 0):(r=i,i=n,n=void 0)),!1===r)r=b;else if(!r)return t;return 1===o&&(s=r,r=function(t){return ft().off(t),s.apply(this,arguments)},r.guid=s.guid||(s.guid=ft.guid++)),t.each(function(){ft.event.add(this,e,r,i,n)})}function S(t,e){return ft.nodeName(t,"table")&&ft.nodeName(11!==e.nodeType?e:e.firstChild,"tr")?t.getElementsByTagName("tbody")[0]||t.appendChild(t.ownerDocument.createElement("tbody")):t}function k(t){return t.type=(null!==ft.find.attr(t,"type"))+"/"+t.type,t}function C(t){var e=ie.exec(t.type);return e?t.type=e[1]:t.removeAttribute("type"),t}function E(t,e){if(1===e.nodeType&&ft.hasData(t)){var n,i,r,o=ft._data(t),s=ft._data(e,o),a=o.events;if(a){delete s.handle,s.events={};for(n in a)for(i=0,r=a[n].length;r>i;i++)ft.event.add(e,n,a[n][i])}s.data&&(s.data=ft.extend({},s.data))}}function _(t,e){var n,i,r;if(1===e.nodeType){if(n=e.nodeName.toLowerCase(),!ht.noCloneEvent&&e[ft.expando]){r=ft._data(e);for(i in r.events)ft.removeEvent(e,i,r.handle);e.removeAttribute(ft.expando)}"script"===n&&e.text!==t.text?(k(e).text=t.text,C(e)):"object"===n?(e.parentNode&&(e.outerHTML=t.outerHTML),ht.html5Clone&&t.innerHTML&&!ft.trim(e.innerHTML)&&(e.innerHTML=t.innerHTML)):"input"===n&&Ht.test(t.type)?(e.defaultChecked=e.checked=t.checked,e.value!==t.value&&(e.value=t.value)):"option"===n?e.defaultSelected=e.selected=t.defaultSelected:"input"!==n&&"textarea"!==n||(e.defaultValue=t.defaultValue)}}function T(t,e,n,i){e=ot.apply([],e);var r,o,s,a,u,c,l=0,h=t.length,p=h-1,f=e[0],m=ft.isFunction(f);if(m||h>1&&"string"==typeof f&&!ht.checkClone&&ne.test(f))return t.each(function(r){var o=t.eq(r);m&&(e[0]=f.call(this,r,o.html())),T(o,e,n,i)});if(h&&(c=v(e,t[0].ownerDocument,!1,t,i),r=c.firstChild,1===c.childNodes.length&&(c=r),r||i)){for(a=ft.map(d(c,"script"),k),s=a.length;h>l;l++)o=c,l!==p&&(o=ft.clone(o,!0,!0),s&&ft.merge(a,d(o,"script"))),n.call(t[l],o,l);if(s)for(u=a[a.length-1].ownerDocument,ft.map(a,C),l=0;s>l;l++)o=a[l],Bt.test(o.type||"")&&!ft._data(o,"globalEval")&&ft.contains(u,o)&&(o.src?ft._evalUrl&&ft._evalUrl(o.src):ft.globalEval((o.text||o.textContent||o.innerHTML||"").replace(re,"")));c=r=null}return t}function P(t,e,n){for(var i,r=e?ft.filter(e,t):t,o=0;null!=(i=r[o]);o++)n||1!==i.nodeType||ft.cleanData(d(i)),i.parentNode&&(n&&ft.contains(i.ownerDocument,i)&&m(d(i,"script")),i.parentNode.removeChild(i));return t}function O(t,e){var n=ft(e.createElement(t)).appendTo(e.body),i=ft.css(n[0],"display");return n.detach(),i}function N(t){var e=it,n=ue[t];return n||(n=O(t,e),"none"!==n&&n||(ae=(ae||ft(" + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/contributor-license-agreement/index.html b/pr-1714/contributor-license-agreement/index.html new file mode 100644 index 000000000..a51ddaab4 --- /dev/null +++ b/pr-1714/contributor-license-agreement/index.html @@ -0,0 +1,249 @@ + + + + + + + + + + + + + + + + Contribute - Contributor License Agreement (CLA) | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+
+

What's this all about then?

+

By agreeing to this Contributor License Agreement (CLA), you are saying that you give Thoughtworks (a major sponsor of Go development) permission to distribute your contributions (or the contributions of your organization's employees) under the terms of Thoughtworks' choice. You are also promising that you have the necessary rights to give Thoughtworks this permission. In return for this, Thoughtworks is promising to you that if it distributes your contributions, Thoughtworks will distribute them under an OSI-approved open source license. The CLA also says that you do not make any warranties or have any support obligations regarding your contributions.

+

The legal stuff

+

This CONTRIBUTOR LICENSE AGREEMENT ("Agreement") by and between Thoughtworks, Inc. ("Thoughtworks"), with offices at + 200 E. Randolph Street, 25th Floor, Chicago, Illinois 60601, and you (the + "Contributor").

+

This Agreement is a modified version and mashup of the Apache Individual Contributor License + Agreement and the Apache Corporate CLA. [Respect.]

+

Recitals

+

A. + The Contributor wishes to submit Contributions to Thoughtworks or to authorize + Contributions submitted by its employees to Thoughtworks, and to grant copyright and patent + licenses to such Contributions.

+

B. + This Agreement does not change the Contributor's right to use its Contributions for any + other purpose. + C. + Except for the licenses granted herein and with respect to recipients of software + distributed by Thoughtworks, the Contributor reserves all right, title, and interest in and to its + Contributions.

+

Agreement

+ 
The parties hereto hereby agree as follows:
+        1. Definitions.
+
+        (a) As used in this Agreement, "You" (or "Your") means the copyright owner or legal
+        entity authorized by the copyright owner that is making this Agreement with Thoughtworks. For
+        legal entities, the entity making a Contribution and all other entities that control, are controlled
+        by, or are under common control with that entity are considered to be a single Contributor.
+
+        (b) As used in the Agreement, "control" means (i) the power, direct or indirect, to cause
+        the direction or management of such entity, whether by contract or otherwise, or (ii) ownership
+        of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such
+        entity.
+
+        (c) As used in the Agreement, "Contribution" means the code, documentation or other
+        original works of authorship expressly identified in Schedule B, as well as any original work of
+        authorship, including any modifications or additions to an existing work, that is intentionally
+        submitted by You to Thoughtworks for inclusion in, or documentation of, any of the products
+        owned or managed by Thoughtworks (the "Work").
+
+        (d) As used in the Agreement, "submitted" means any form of electronic, verbal, or
+        written communication sent to Thoughtworks or its representatives, including but not limited
+        to communication on electronic mailing lists, source code control systems, and issue tracking
+        systems that are managed by, or on behalf of, Thoughtworks for the purpose of discussing and
+        improving the Work, but excluding communication that is conspicuously marked or otherwise
+        designated in writing by You as "Not a Contribution."
+
+        2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You
+        hereby grant to Thoughtworks and to recipients of software distributed by Thoughtworks a
+        perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license
+        to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and
+        distribute Your Contributions and such derivative works.
+
+        3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby
+        grant to Thoughtworks and to recipients of software distributed by Thoughtworks a perpetual,
+        worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section)
+        patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer
+        the Work, where such license applies only to those patent claims licensable by You that are
+        necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s)
+        with the Work to which such Contribution(s) was submitted. If any entity institutes patent
+        litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit)
+        alleging that your Contribution, or the Work to which you have contributed, constitutes direct
+        or contributory patent infringement, then any patent licenses granted to that entity under this
+        Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
+
+        4. Entitled to Grant Licenses. You represent that You are legally entitled to grant the above
+        licenses. As applicable, 1) You represent further that each employee of the organization
+        designated on Schedule A below (or in a subsequent written modification to that Schedule) is
+        authorized to submit Contributions on behalf of the organization; or 2) if your employer(s) has
+        rights to intellectual property that you create that includes your Contributions, you represent
+        that you have received permission to make Contributions on behalf of that employer, that your
+        employer has waived such rights for your Contributions to Thoughtworks, or that your employer
+        has executed a separate Contributor License Agreement with Thoughtworks.
+
+        5. Original Creation. You represent that Your Contribution is Your original creation. If any
+        part of Your Contribution is not Your original creation, You represent that Your Contribution
+        submissions include complete details of any third-party license or other restriction (including,
+        but not limited to, related patents and trademarks) of which you are personally aware and which
+        are associated with any part of Your Contributions.
+
+        6. No Warranties. You are not expected to provide support for Your Contributions, except
+        to the extent You desire to provide support. You may provide support for free, for a fee,
+        or not at all. Unless required by applicable law or agreed to in writing, you provide your
+        contributions on an "as is" basis, without warranties or conditions of any kind, either express or
+        implied, including, without limitation, any warranties or conditions of title, non-infringement,
+        merchantability, or fitness for a particular purpose.
+
+        7. On Behalf of a Third-Party. Should You wish to submit work that is not Your original
+        creation, You may submit it to Thoughtworks separately from any Contribution, identifying the
+        complete details of its source and of any license or other restriction (including, but not limited
+        to, related patents, trademarks, and license agreements) of which you are personally aware, and
+        conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".
+
+        8. Thoughtworks' Obligation. In return for the grants and representations You have made in
+        this Agreement, Thoughtworks agrees that if Thoughtworks distributes your Contributions,
+        Thoughtworks will distribute Your Contributions under an OSI-approved open source license.
+
+        9. Miscellaneous. You agree to notify Thoughtworks of any facts or circumstances of which
+        you become aware that would make the representations You have made in this Agreement
+        inaccurate in any respect. It is your responsibility to notify Thoughtworks when any change is
+        required to the list of designated employees authorized to submit Contributions on behalf of the
+        organization, or to the organization's point of contact with Thoughtworks, if applicable.
+        IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the
+        date first set forth above.
+
+

+ THOUGHTWORKS, INC.
+ By: Rebecca Parsons
+ Title: Chief Technology Officer
+ Signed: /Rebecca Parsons/ +

+

Thoughtworks Privacy Policy

+

Let's do this!

+

If you're OK with the above then fill in the form below.

+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/documentation.html b/pr-1714/documentation.html new file mode 100644 index 000000000..007a2d779 --- /dev/null +++ b/pr-1714/documentation.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the https://docs.gocd.org page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/documentation/index.html b/pr-1714/documentation/index.html new file mode 100644 index 000000000..007a2d779 --- /dev/null +++ b/pr-1714/documentation/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the https://docs.gocd.org page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/download.html b/pr-1714/download.html new file mode 100644 index 000000000..08357c00c --- /dev/null +++ b/pr-1714/download.html @@ -0,0 +1,513 @@ + + + + + + + + + + + + + + + + Download for Free - Server and Agent | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+ +
+
+
+
+ + + +
+
+ + + + +
+
+ +
+ +
+
+
+
+ + + + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/download/index.html b/pr-1714/download/index.html new file mode 100644 index 000000000..6bc926088 --- /dev/null +++ b/pr-1714/download/index.html @@ -0,0 +1,513 @@ + + + + + + + + + + + + + + + + Download for Free - Server and Agent | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+ +
+
+
+
+ + + +
+
+ + + + +
+
+ +
+ +
+
+
+
+ + + + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/ebook-cd-analytics.html b/pr-1714/ebook-cd-analytics.html new file mode 100644 index 000000000..81c5667ed --- /dev/null +++ b/pr-1714/ebook-cd-analytics.html @@ -0,0 +1,173 @@ + + + + + + + + + + + + + + + + Free Guide - Actionable Continuous Delivery Metrics | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + Download the CD101 eBook + +
+
+ +
+
+ +
+
+

Free Guide: Use Metrics to Improve Your CD Process

+
+
+ +
+
+ Download the CD Analytics eBook +
+ +
+

Want to deliver faster? Want to recover from failures more quickly? Want to improve your cycle time?

+ +

This Actionable Continuous Delivery Metrics eBook will provide you insight into your software delivery pipeline, and help you to improve your delivery and team processes. Inside you will find: +

+ +
    +
  • Why measuring and monitoring your CD pipeline is important
    • +
  • What metrics matters when improving your path to production
    • +
  • A guide to using metrics to improve your CD process
    • +
+
+
+ +
+
+ Download Free eBook +
+
+ Download Plugin +
+
+ +
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/ebook-cd-analytics/index.html b/pr-1714/ebook-cd-analytics/index.html new file mode 100644 index 000000000..88d65fc36 --- /dev/null +++ b/pr-1714/ebook-cd-analytics/index.html @@ -0,0 +1,173 @@ + + + + + + + + + + + + + + + + Free Guide - Actionable Continuous Delivery Metrics | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + Download the CD101 eBook + +
+
+ +
+
+ +
+
+

Free Guide: Use Metrics to Improve Your CD Process

+
+
+ +
+
+ Download the CD Analytics eBook +
+ +
+

Want to deliver faster? Want to recover from failures more quickly? Want to improve your cycle time?

+ +

This Actionable Continuous Delivery Metrics eBook will provide you insight into your software delivery pipeline, and help you to improve your delivery and team processes. Inside you will find: +

+ +
    +
  • Why measuring and monitoring your CD pipeline is important
    • +
  • What metrics matters when improving your path to production
    • +
  • A guide to using metrics to improve your CD process
    • +
+
+
+ +
+
+ Download Free eBook +
+
+ Download Plugin +
+
+ +
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/elastic-agents.html b/pr-1714/elastic-agents.html new file mode 100644 index 000000000..e12b78e5d --- /dev/null +++ b/pr-1714/elastic-agents.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + + + + + Elastic Agents + + + + + + + + + +
+
+ + + +
+ +
+ + + + + +
+
+

OPEN SOURCE PLUGINS

+

+ GoCD has several community supported plugins, allowing you to connect to and configure your agents on both + physical and cloud environments. +

+ +
    +
  • +

    Docker

    +

    + GoCD Elastic agent plugin for Docker +

    +
    • + +
  • +

    + Docker Swarm +

    +

    + GoCD Elastic agent plugin for Docker Swarm +

    +
    • +
+
    +
  • +

    + Kubernetes +

    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. +

    +
    • + +
  • +

    + OpenStack +

    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. +

    +
    • + +
+ Get Started +
+
+ + +
+
+
    +
  • +

    + Run elastic agents on Amazon ECS +

    +

    + You can configure how many EC2 instances to bring up or reuse, how many ECS elastic agents within these EC2 to + bring up, what AMI to use for the EC2 instance, the instance type, security groups, the Docker image for the + ECS container and memory limits etc. +

    +
    • + +
  • +

    + Run elastic agents on Windows Azure +

    +

    + You can configure the plugin to use a Azure virtual network, resource group and region. The elastic profiles + can be configured to use an image from Azure marketplace or a custom image from your subscription. You can + configure the size of the VM, disk space and more. +

    +
    • +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/elastic-agents/index.html b/pr-1714/elastic-agents/index.html new file mode 100644 index 000000000..6d940ebc1 --- /dev/null +++ b/pr-1714/elastic-agents/index.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + + + + + Elastic Agents + + + + + + + + + +
+
+ + + +
+ +
+ + + + + +
+
+

OPEN SOURCE PLUGINS

+

+ GoCD has several community supported plugins, allowing you to connect to and configure your agents on both + physical and cloud environments. +

+ +
    +
  • +

    Docker

    +

    + GoCD Elastic agent plugin for Docker +

    +
    • + +
  • +

    + Docker Swarm +

    +

    + GoCD Elastic agent plugin for Docker Swarm +

    +
    • +
+
    +
  • +

    + Kubernetes +

    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. +

    +
    • + +
  • +

    + OpenStack +

    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. +

    +
    • + +
+ Get Started +
+
+ + +
+
+
    +
  • +

    + Run elastic agents on Amazon ECS +

    +

    + You can configure how many EC2 instances to bring up or reuse, how many ECS elastic agents within these EC2 to + bring up, what AMI to use for the EC2 instance, the instance type, security groups, the Docker image for the + ECS container and memory limits etc. +

    +
    • + +
  • +

    + Run elastic agents on Windows Azure +

    +

    + You can configure the plugin to use a Azure virtual network, resource group and region. The elastic profiles + can be configured to use an image from Azure marketplace or a custom image from your subscription. You can + configure the size of the VM, disk space and more. +

    +
    • +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/enterprise-campaign.html b/pr-1714/enterprise-campaign.html new file mode 100644 index 000000000..9e4892b67 --- /dev/null +++ b/pr-1714/enterprise-campaign.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/enterprise-campaign/index.html b/pr-1714/enterprise-campaign/index.html new file mode 100644 index 000000000..9e5ceb085 --- /dev/null +++ b/pr-1714/enterprise-campaign/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/enterprise.html b/pr-1714/enterprise.html new file mode 100644 index 000000000..9e4892b67 --- /dev/null +++ b/pr-1714/enterprise.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/enterprise/index.html b/pr-1714/enterprise/index.html new file mode 100644 index 000000000..9e5ceb085 --- /dev/null +++ b/pr-1714/enterprise/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/enterprise/thoughtworks-go-extensions-eula.html b/pr-1714/enterprise/thoughtworks-go-extensions-eula.html new file mode 100644 index 000000000..b9b2fa007 --- /dev/null +++ b/pr-1714/enterprise/thoughtworks-go-extensions-eula.html @@ -0,0 +1,436 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+
+
This page was redirected from https://www.thoughtworks.com/go/thoughtworks-go-extensions-eula/
+
+
+

Thoughtworks Go Extensions
End User License Agreement

+
+
+ +
+
+ THIS IS A “CLICKWRAP AGREEMENT”, BY INSTALLING OR USING THIS PRODUCT, THE INDIVIDUAL DOING SO GUARANTEES THAT HE + OR SHE IS AUTHORIZED TO ENTER INTO THIS AGREEMENT WITH THOUGHTWORKS ON BEHALF OF LICENSEE, THAT HE OR SHE HAS + READ AND UNDERSTANDS THE TERMS OF THIS AGREEMENT AND THAT LICENSEE AGREES TO BE BOUND BY THIS AGREEMENT. IF + LICENSEE DOES NOT AGREE TO THE TERMS OF THIS AGREEMENT, LICENSEE MUST NOT INSTALL, USE OR ALLOW THE INSTALLATION + OR USE OF THIS PRODUCT. + +
    +
  1. +
    DEFINED TERMS:
    +
      +
    1. Agreement means this THOUGHTWORKS GO EXTENSIONS END USER LICENSE AGREEMENT + together + with the applicable Go Support Schedule. +
      2. +
    2. Authorized Use means use of the Product in accordance with the terms of this + Agreement and as + specified in the Go Support Schedule, if any. +
      3. +
    3. Licensee means the person or entity (real or legal) exercising rights granted + by Thoughtworks + under this Agreement, who is identified in the Go Support Schedule as Customer. Where Licensee + is a legal entity, Licensee includes any currently existing or future entity which controls, is + controlled by, or is under common control with Licensee, where “control” means (a) the direct or + indirect power to control the management and direction of such entity, whether by ownership, + contract, or otherwise, or (b) ownership of fifty percent (50%) or more of the outstanding + shares, ownership of a controlling interest, or beneficial ownership of such entity. +
      4. +
    4. Order Documents include (but are not limited to) the following documents: + Invoices, Purchase + Orders, Requisitions, or other similar documents that memorialize a licensing transaction + between Licensee and Thoughtworks, which specify the price, Product, quantity and type of + Authorized Users, and the Term. +
      5. +
    5. Product means the add-ons to Go listed on the website + https://www.thoughtworks.com/products/go-continuous-delivery/, but excluding Third Party + Software. +
      6. +
    6. Term means the term of the applicable Go Support Schedule.
      7. +
    7. Third-Party Software means third-party computer software licensed to + Thoughtworks, which is + distributed with the Product. +
      8. +
    8. Thoughtworks means Thoughtworks, Inc., a Delaware Corporation, located at 200 + E. Randolph St., + 25th Floor, Chicago, Illinois 60601, United States of America. +
      9. +
    +
    2. +
  2. +
    GRANT OF LICENSE
    + +

    During the Term, and subject to Licensee having paid and continuing to pay the applicable + Support Fees set forth in the Go Support Schedule, and complying with the terms and + conditions of this Agreement, Thoughtworks hereby grants Licensee a non-exclusive, + non-transferable, non-assignable limited license to use the Product for the Authorized Use. + With respect to the Product, the terms of this Agreement supersede and replace any terms + contained in any preexisting agreement between Thoughtworks and Licensee. With respect to + Third-Party Software, the terms of the third-party licenses applicable to the Third-Party + Software govern the use of such Third-Party Software by Licensee.

    + +

    Licensee may make additional copies of the Product as necessary for archival or backup + purposes, provided that Licensee reproduces and includes all copyright, trademark, logo or + other proprietary notices on every copy in the same form in which they appear in or on the + original copies provided to Licensee by Thoughtworks.

    + +

    Licensee may not distribute, sub-license, translate, reverse-engineer, decompile, or + disassemble the Product (including Third-Party Software) or the source code, or attempt to + derive the source code in any other way, save and only to the extent any foregoing + restriction is prohibited by applicable law or to the extent as may be permitted by the + terms of the licenses applicable to the Third-Party Software; modify the Product or merge + all, or any part, of the product or the code into another program; or remove, modify or + alter any Thoughtworks copyright, trademark, logo, or other proprietary mark or notice from + any part of the Product or source code.

    +
    3. +
  3. +
    TERM OF LICENSE
    +

    This license shall begin on the Effective Date of the applicable Go Support Schedule and continue for + the Term subject to earlier termination by either Thoughtworks or Licensee in accordance with this + Agreement.

    +
    4. +
  4. +
    LICENSEE'S OBLIGATIONS
    +

    Licensee shall ensure that its use of the Product is only for the Authorized Use. Licensee shall not + distribute the Product. Licensee shall take reasonable security measures to prevent any prohibited + activities under Section 2 of this Agreement.

    +
    5. +
  5. +
    INTELLECTUAL PROPERTY & CONFIDENTIALITY
    +

    Thoughtworks hereby reserves all rights not explicitly granted in this Agreement. The Product + contains copyrighted material, trade secrets and other valuable confidential and proprietary + information owned by Thoughtworks. This license confers no right, title, or ownership interest in or + to any copyright, trademark, logo, or trade name of Thoughtworks and all associated intellectual + property rights are retained by Thoughtworks.

    6. +
  6. +
    LIMITED WARRANTY & LIABILITY
    +

    a) Thoughtworks provides the Product “as is” and “as available” without warranty of any kind, either + express or implied, including but not limited to, the implied warranties of merchantability, + satisfactory quality, and fitness for a particular purpose. Thoughtworks does not warrant that the + functions contained in the Product will meet Licensee’s requirements, or that the operation of the + Product will be uninterrupted or error or defect free, or that defects in the Product will be + corrected.

    + +

    b) Under no circumstances, including negligence, shall Thoughtworks be liable for any lost profits, + loss of data, cost of procurement of substitute software, goods or services, or special, indirect, + incidental or consequential loss or damages, either in contract or tort, arising out of or in + connection with this Agreement or that result from the use or inability to use the Product, even if + Thoughtworks is advised of the possibility. In addition, in no event shall Thoughtworks’ total + liability for all damages, losses and causes of action exceed the amount paid by Licensee under the + applicable Go Support Schedule. To the extent that liability for death or personal injury caused by + its negligence, caused by fraudulent misrepresentation or deceit, or any other liability that may + not be excluded or limited by applicable law, Thoughtworks does not exclude or limit its + liability.

    + +

    c) The Parties agree that the limitations on and exclusions of liability listed in this Section 6 + were freely negotiated and are an integral part of the bargain, in that the Product would not have + been available for the same price and under the same terms and conditions had such limitations on + and exclusions of liability not been included in this Agreement.

    + +

    d) To the extent the foregoing warranty disclaimer or limitation of liability is not allowed by + applicable law, then the liability of Thoughtworks, and Licensee’s remedy, shall be limited to, at + Thoughtworks’ option: (i) the re-supply of any defective Product; or (ii) the payment to Licensee of + US$50.00 (fifty United States Dollars).

    7. +
  7. +
    INTELLECTUAL PROPERTY INDEMNIFICATION
    +

    a) Thoughtworks will defend or settle, at its expense, any action brought against Licensee based upon + the claim that the Product, when used in accordance with this Agreement, knowingly and directly + infringes an issued U.S. patent or registered copyright; provided, however, that: (i) Licensee notifies + Thoughtworks promptly in writing of any such claim; (ii) Licensee does not enter into any settlement related to + any claim without Thoughtworks' prior written consent; (iii) Thoughtworks has sole control of any claim and all + related settlement negotiations; and (iv) as requested, Licensee provides Thoughtworks with all + information and assistance necessary to settle or defend the claim.

    + +

    (b) If the Product becomes, or may, in the opinion of Thoughtworks, become the subject of a claim of + infringement of any third party intellectual property right, Thoughtworks may, at its option, and as + Licensee’s exclusive remedy: (i) procure the right for Licensee to use the Product; (ii) replace or + modify the Product to make it non-infringing; or (iii) make a payment to Licensee of US$50.00 (fifty + United States Dollars).

    + +

    (c) Licensee will defend or settle, at Licensee’s expense, any action brought against Thoughtworks + based upon the claim that any modifications Licensee makes to the Product or any combination of the + Product with software or other items not approved by Thoughtworks infringes or violates any third party + intellectual property right; provided, however, that Thoughtworks comply with the same requirements outlined in + subsections (i)-(iv) of Subparagraph (a).

    + +

    (d) Notwithstanding anything herein to the contrary, Thoughtworks shall have no obligation to defend + Licensee or to pay Licensee’s costs, damages or attorney’s fees, or have any liability whatsoever, + for any claim resulting from or attributable to any modifications to the Product or any combination of the + Product with other with products or other items not approved by Thoughtworks or any failure to implement an + update to the Product or if Licensee is otherwise not using the Product in accordance with this + Agreement.

    8. + +
  8. +
    BREACH, CURE, AND TERMINATION OF THE AGREEMENT
    +

    Thoughtworks can terminate this Agreement in the event of breach by Licensee. Breach by Licensee + includes: 1) the failure to prevent unauthorized use or distribution of the Product; 2) accessing, using, + modifying, or distributing Third-Party Software independently of the Product and without permission; 3) + nonpayment, or 4) any other activity that violates this Agreement. Thoughtworks may terminate this Agreement + immediately upon giving notice to Licensee if after giving Licensee written notice that it is in breach of the + Agreement, Licensee fails to cure the breach within seven (7) days of receipt of the notice; except + that in the case of Licensee’s failure to pay Support Fees or comply with Section 2, Thoughtworks reserves + the right to terminate this Agreement immediately and without notice or opportunity to cure. In the event of + termination of this Agreement: a) all outstanding License Fees and any other amounts owed by + Licensee are immediately due and payable; and b) all license rights (including without limitation the perpetual + license) granted to Licensee under this Agreement and in relation to the Product are revoked and the Licensee + must destroy all copies of the Product. If Licensee terminates the applicable Go Support Schedule, then + this Agreement shall automatically terminate.

    9. + +
  9. +
    EXPORT
    +

    Licensee acknowledges that this Product may be subject to export controls or restrictions by the + United States or other countries or territories and Licensee hereby certifies that Licensee is not located + in Cuba, Iran, North Korea, Sudan, or Syria. Additionally, Licensee affirms that, to Licensee’s knowledge, + Licensee is not included on any list that would cause Thoughtworks' provision of this Product to Licensee to + be prohibited by the laws or regulations of the United States, including the Department of Commerce’s + ("DOC") Denied Persons, Entities, and Unverified Lists; the U.S. Department of State’s Debarred List; or on + the U.S. Department of Treasury’s lists of Specially Designated Nationals, Specially Designated Narcotics + Traffickers, or Specially Designated Terrorists. Licensee agrees to comply with all applicable + export and re-export control laws and regulations, including the Export Administration Regulations ("EAR") + maintained by the U.S. Department of Commerce.

    +
    10. + +
  10. +
    ASSIGNMENT
    +

    Licensee may not assign its rights under this Agreement except in the case of a change in control of + Licensee, including merger or sale. Licensee must give Thoughtworks 60 days written notice of any + such assignment. Thoughtworks may assign its rights and obligations under this agreement for any reason + and without the consent of Licensee.

    +
    11. + +
  11. +
    SEVERABILITY
    +

    Each provision of this Agreement shall be interpreted in such a manner as to be effective and valid + under applicable law. The invalidity or unenforceability of any provision of this Agreement shall in no + way affect the validity or enforceability of any other provision hereof. Any invalid or unenforceable provision + shall be deemed severed from this Agreement and the balance of this Agreement shall be construed and + enforced as if this Agreement did not contain the particular provisions(s) held to be invalid or unenforceable + and so as to effect the original intent of the parties hereto.

    +
    12. + +
  12. +
    GOVERNING LAW
    +

    This Agreement shall be deemed executed in the State of Delaware, U.S.A., and shall be governed by + and construed in accordance with the laws of the State of Delaware, without regard to choice of law or + conflict of law principles. For purposes of enforcement of arbitration awards, equitable relief, or if for + any other reason litigation is permissible under this agreement, each party hereby irrevocably agrees to the + exclusive personal jurisdiction and venue of any court located in the State of Delaware.

    13. + +
  13. +
    NO WAIVER
    +

    No failure or delay by either party in exercising any right, power, or privilege granted under this + Agreement shall operate as a waiver thereof, nor shall any single or partial exercise thereof + preclude any other or further exercise thereof or the exercise of any right, power or privilege granted under + this Agreement. The knowing waiver of a Breach of this Agreement or the failure of a party to exercise + any right under this Agreement shall in no event constitute a waiver as to any other breach, whether similar + or dissimilar in nature, or prevent the exercise of any right under this Agreement.

    +
    14. + +
  14. +
    SURVIVAL
    +

    The provisions of Sections 4, 5, 6, 7, 9, 11, 12, 14, 15, 17, 18 and 19 shall survive the + cancellation or termination of this Agreement. All other provisions of this Agreement, which by their terms or + import are intended to survive such cancellation or termination, shall survive.

    +
    15. + +
  15. +
    NO THIRD-PARTY BENEFICIARIES
    +

    This Agreement may only be enforced by the parties hereto and their respective successors and assigns + and there are no third-party beneficiaries to this Agreement.

    +
    16. + +
  16. +
    AMENDMENT
    +

    This Agreement can only be modified by mutual written assent of the parties. The parties agree that + the terms on either party’s purchase order, invoice or other business forms are not binding on the other + party and shall not be of any effect whatsoever and may not affect, alter, or modify the terms and + conditions of this Agreement unless they are expressly incorporated into a formal written agreement signed by both + parties.

    +
    17. + +
  17. +
    U.S. FEDERAL PROCUREMENT REQUIREMENTS
    +

    PURSUANT TO FAR 52.212-5(E) AND/OR FAR 52.244-6, FOR ANY ORDER DOCUMENTS REFERENCING A SPECIFIC U.S. + GOVERNMENT PRIME CONTRACT, ALL APPLICABLE PROCUREMENT REGULATIONS REQUIRED BY FEDERAL STATUTE OR + REGULATION TO BE INSERTED IN U.S. GOVERNMENT SUBCONTRACTS APPLY, INCLUDING BUT NOT LIMITED TO 52.203-13, + CONTRACTOR CODE OF BUSINESS ETHICS AND CONDUCT, FAR 52.203-15, WHISTLEBLOWER PROTECTIONS UNDER THE AMERICAN + RECOVERY AND REINVESTMENT ACT OF 2009, FAR 52.219-8 - UTILIZATION OF SMALL BUSINESS CONCERNS, FAR 52.222-26 - + EQUAL OPPORTUNITY, FAR 52.222-35 - EQUAL OPPORTUNITY FOR SPECIAL DISABLED VETERANS, VETERANS OF THE + VIETNAM ERA, AND OTHER ELIGIBLE VETERANS, FAR 52.222-36 - AFFIRMATIVE ACTION FOR WORKERS WITH DISABILITIES, FAR + 52.222-39 - NOTIFICATION OF EMPLOYEE RIGHTS CONCERNING PAYMENT OF UNION DUES OR FEES, FAR 52.222-41 - SERVICE + CONTRACT ACT OF 1965, FAR 52.222-50 – COMBATING TRAFFICKING IN PERSONS, FAR 52.222-51, EXEMPTION FROM + APPLICATION OF THE SERVICE CONTRACT ACT TO CONTRACTS FOR MAINTENANCE, CALIBRATION, OR REPAIR OF CERTAIN EQUIPMENT – + REQUIREMENTS, FAR 52.222-53, EXEMPTION FROM APPLICATION OF THE SERVICE CONTRACT ACT TO CONTRACTS FOR + CERTAIN SERVICE – REQUIREMENTS, FAR 52.222-54, EMPLOYMENT ELIGIBILITY VERIFICATION, FAR 52.226-6, PROMOTING + EXCESS FOOD DONATION TO NONPROFIT ORGANIZATIONS, FAR 52.247-64 - PREFERENCE FOR PRIVATELY OWNED U.S. FLAG + COMMERCIAL VESSELS (AS REQUIRED IN ACCORDANCE WITH PARAGRAPH (D) OF FAR CLAUSE 52.247-64. THESE + PROVISIONS HAVE THE SAME FORCE AND EFFECT AS IF THEY WERE STATED IN THEIR FULL TEXT.

    +
    18. + +
  18. +
    U.S. GOVERNMENT RIGHTS
    +

    IF YOU ARE A US GOVERNMENT ENTITY THEN YOU SHOULD BE AWARE THAT THE SOFTWARE IS A “COMMERCIAL ITEM,” + AS THAT TERM IS DEFINED IN 48 CFR 2.101, CONSISTING OF “COMMERCIAL COMPUTER SOFTWARE” AND “COMMERCIAL + COMPUTER SOFTWARE DOCUMENTATION,” AS SUCH TERMS ARE USED IN 48 CFR 12.212. CONSISTENT WITH 48 CFR 12.212 AND + 48 CFR 227.7202-1 AND 227.7202-4, ALL SUCH CUSTOMERS ACQUIRE THE SOFTWARE WITH ONLY THOSE RIGHTS SET FORTH + HEREIN. THE TERMS OF THIS LICENSE ARE SUBJECT TO 48 CFR 52.227-19. THE USE, DUPLICATION, OR DISCLOSURE BY + THE US GOVERNMENT OF THE SOFTWARE IS SUBJECT TO RESTRICTIONS AS PROVIDED IN 48 CFR 12.211 AND 12.212, 48 + CFR 52.227-19, 48 CFR 252.227-7015, AS APPLICABLE.

    + +

    THIS COMMERCIAL SOFTWARE AND COMMERCIAL COMPUTER SOFTWARE DOCUMENTATION WAS DEVELOPED ENTIRELY AT + PRIVATE EXPENSE AND IS PROVIDED WITH RESTRICTED RIGHTS TO UNITED STATES GOVERNMENT AGENCIES IN ACCORDANCE + WITH THE TERMS OF THIS AGREEMENT, FAR 12.212 AND DFARS 227.7202 FOR COMMERCIAL TECHNICAL DATA. THE + RESTRICTIONS SET FORTH IN FAR 12.211 AND FOR DOD AGENCIES DFARS 252.227-7015 SHALL ALSO APPLY. DATA FIRST PRODUCED IN + THE PERFORMANCE OF WORK UNDER THIS AGREEMENT IS PROVIDED TO U.S. GOVERNMENT AGENCIES IN ACCORDANCE WITH + FAR 52.227-14(B)(1)(I). THESE PROVISIONS HAVE THE SAME FORCE AND EFFECT AS IF THEY WERE STATED IN THEIR + FULL TEXT.

    +
    19. + +
  19. +
    ENTIRE AGREEMENT
    +

    This Agreement, the Go Support Schedule and the applicable Order Documents (if any), constitute the + entire agreement between the parties with respect to the subject matter hereof, and supersedes and replaces + all prior or contemporaneous understandings, representations, communications, or agreements, written or + oral, including any additional or contrary terms contained in any Licensee purchase order or other + procurement document, regarding the Product or in any way related to Thoughtworks intellectual property rights + in the Product. In the event of a conflict between the terms of this Thoughtworks Go Extensions End User + License Agreement and the Thoughtworks Support Services General Terms located at + https://www.thoughtworks.com/products/go-continuous-delivery/thoughtworks-support-services-general-terms, + then solely with respect to Thoughtworks’ supply and Licensee’s use of the Product, the terms of + this Thoughtworks Go Extensions End User License Agreement shall control.

    +
    20. + +
+
+
+ +
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/enterprise/thoughtworks-go-extensions-eula/index.html b/pr-1714/enterprise/thoughtworks-go-extensions-eula/index.html new file mode 100644 index 000000000..4444e3b5a --- /dev/null +++ b/pr-1714/enterprise/thoughtworks-go-extensions-eula/index.html @@ -0,0 +1,436 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+
+
This page was redirected from https://www.thoughtworks.com/go/thoughtworks-go-extensions-eula/
+
+
+

Thoughtworks Go Extensions
End User License Agreement

+
+
+ +
+
+ THIS IS A “CLICKWRAP AGREEMENT”, BY INSTALLING OR USING THIS PRODUCT, THE INDIVIDUAL DOING SO GUARANTEES THAT HE + OR SHE IS AUTHORIZED TO ENTER INTO THIS AGREEMENT WITH THOUGHTWORKS ON BEHALF OF LICENSEE, THAT HE OR SHE HAS + READ AND UNDERSTANDS THE TERMS OF THIS AGREEMENT AND THAT LICENSEE AGREES TO BE BOUND BY THIS AGREEMENT. IF + LICENSEE DOES NOT AGREE TO THE TERMS OF THIS AGREEMENT, LICENSEE MUST NOT INSTALL, USE OR ALLOW THE INSTALLATION + OR USE OF THIS PRODUCT. + +
    +
  1. +
    DEFINED TERMS:
    +
      +
    1. Agreement means this THOUGHTWORKS GO EXTENSIONS END USER LICENSE AGREEMENT + together + with the applicable Go Support Schedule. +
      2. +
    2. Authorized Use means use of the Product in accordance with the terms of this + Agreement and as + specified in the Go Support Schedule, if any. +
      3. +
    3. Licensee means the person or entity (real or legal) exercising rights granted + by Thoughtworks + under this Agreement, who is identified in the Go Support Schedule as Customer. Where Licensee + is a legal entity, Licensee includes any currently existing or future entity which controls, is + controlled by, or is under common control with Licensee, where “control” means (a) the direct or + indirect power to control the management and direction of such entity, whether by ownership, + contract, or otherwise, or (b) ownership of fifty percent (50%) or more of the outstanding + shares, ownership of a controlling interest, or beneficial ownership of such entity. +
      4. +
    4. Order Documents include (but are not limited to) the following documents: + Invoices, Purchase + Orders, Requisitions, or other similar documents that memorialize a licensing transaction + between Licensee and Thoughtworks, which specify the price, Product, quantity and type of + Authorized Users, and the Term. +
      5. +
    5. Product means the add-ons to Go listed on the website + https://www.thoughtworks.com/products/go-continuous-delivery/, but excluding Third Party + Software. +
      6. +
    6. Term means the term of the applicable Go Support Schedule.
      7. +
    7. Third-Party Software means third-party computer software licensed to + Thoughtworks, which is + distributed with the Product. +
      8. +
    8. Thoughtworks means Thoughtworks, Inc., a Delaware Corporation, located at 200 + E. Randolph St., + 25th Floor, Chicago, Illinois 60601, United States of America. +
      9. +
    +
    2. +
  2. +
    GRANT OF LICENSE
    + +

    During the Term, and subject to Licensee having paid and continuing to pay the applicable + Support Fees set forth in the Go Support Schedule, and complying with the terms and + conditions of this Agreement, Thoughtworks hereby grants Licensee a non-exclusive, + non-transferable, non-assignable limited license to use the Product for the Authorized Use. + With respect to the Product, the terms of this Agreement supersede and replace any terms + contained in any preexisting agreement between Thoughtworks and Licensee. With respect to + Third-Party Software, the terms of the third-party licenses applicable to the Third-Party + Software govern the use of such Third-Party Software by Licensee.

    + +

    Licensee may make additional copies of the Product as necessary for archival or backup + purposes, provided that Licensee reproduces and includes all copyright, trademark, logo or + other proprietary notices on every copy in the same form in which they appear in or on the + original copies provided to Licensee by Thoughtworks.

    + +

    Licensee may not distribute, sub-license, translate, reverse-engineer, decompile, or + disassemble the Product (including Third-Party Software) or the source code, or attempt to + derive the source code in any other way, save and only to the extent any foregoing + restriction is prohibited by applicable law or to the extent as may be permitted by the + terms of the licenses applicable to the Third-Party Software; modify the Product or merge + all, or any part, of the product or the code into another program; or remove, modify or + alter any Thoughtworks copyright, trademark, logo, or other proprietary mark or notice from + any part of the Product or source code.

    +
    3. +
  3. +
    TERM OF LICENSE
    +

    This license shall begin on the Effective Date of the applicable Go Support Schedule and continue for + the Term subject to earlier termination by either Thoughtworks or Licensee in accordance with this + Agreement.

    +
    4. +
  4. +
    LICENSEE'S OBLIGATIONS
    +

    Licensee shall ensure that its use of the Product is only for the Authorized Use. Licensee shall not + distribute the Product. Licensee shall take reasonable security measures to prevent any prohibited + activities under Section 2 of this Agreement.

    +
    5. +
  5. +
    INTELLECTUAL PROPERTY & CONFIDENTIALITY
    +

    Thoughtworks hereby reserves all rights not explicitly granted in this Agreement. The Product + contains copyrighted material, trade secrets and other valuable confidential and proprietary + information owned by Thoughtworks. This license confers no right, title, or ownership interest in or + to any copyright, trademark, logo, or trade name of Thoughtworks and all associated intellectual + property rights are retained by Thoughtworks.

    6. +
  6. +
    LIMITED WARRANTY & LIABILITY
    +

    a) Thoughtworks provides the Product “as is” and “as available” without warranty of any kind, either + express or implied, including but not limited to, the implied warranties of merchantability, + satisfactory quality, and fitness for a particular purpose. Thoughtworks does not warrant that the + functions contained in the Product will meet Licensee’s requirements, or that the operation of the + Product will be uninterrupted or error or defect free, or that defects in the Product will be + corrected.

    + +

    b) Under no circumstances, including negligence, shall Thoughtworks be liable for any lost profits, + loss of data, cost of procurement of substitute software, goods or services, or special, indirect, + incidental or consequential loss or damages, either in contract or tort, arising out of or in + connection with this Agreement or that result from the use or inability to use the Product, even if + Thoughtworks is advised of the possibility. In addition, in no event shall Thoughtworks’ total + liability for all damages, losses and causes of action exceed the amount paid by Licensee under the + applicable Go Support Schedule. To the extent that liability for death or personal injury caused by + its negligence, caused by fraudulent misrepresentation or deceit, or any other liability that may + not be excluded or limited by applicable law, Thoughtworks does not exclude or limit its + liability.

    + +

    c) The Parties agree that the limitations on and exclusions of liability listed in this Section 6 + were freely negotiated and are an integral part of the bargain, in that the Product would not have + been available for the same price and under the same terms and conditions had such limitations on + and exclusions of liability not been included in this Agreement.

    + +

    d) To the extent the foregoing warranty disclaimer or limitation of liability is not allowed by + applicable law, then the liability of Thoughtworks, and Licensee’s remedy, shall be limited to, at + Thoughtworks’ option: (i) the re-supply of any defective Product; or (ii) the payment to Licensee of + US$50.00 (fifty United States Dollars).

    7. +
  7. +
    INTELLECTUAL PROPERTY INDEMNIFICATION
    +

    a) Thoughtworks will defend or settle, at its expense, any action brought against Licensee based upon + the claim that the Product, when used in accordance with this Agreement, knowingly and directly + infringes an issued U.S. patent or registered copyright; provided, however, that: (i) Licensee notifies + Thoughtworks promptly in writing of any such claim; (ii) Licensee does not enter into any settlement related to + any claim without Thoughtworks' prior written consent; (iii) Thoughtworks has sole control of any claim and all + related settlement negotiations; and (iv) as requested, Licensee provides Thoughtworks with all + information and assistance necessary to settle or defend the claim.

    + +

    (b) If the Product becomes, or may, in the opinion of Thoughtworks, become the subject of a claim of + infringement of any third party intellectual property right, Thoughtworks may, at its option, and as + Licensee’s exclusive remedy: (i) procure the right for Licensee to use the Product; (ii) replace or + modify the Product to make it non-infringing; or (iii) make a payment to Licensee of US$50.00 (fifty + United States Dollars).

    + +

    (c) Licensee will defend or settle, at Licensee’s expense, any action brought against Thoughtworks + based upon the claim that any modifications Licensee makes to the Product or any combination of the + Product with software or other items not approved by Thoughtworks infringes or violates any third party + intellectual property right; provided, however, that Thoughtworks comply with the same requirements outlined in + subsections (i)-(iv) of Subparagraph (a).

    + +

    (d) Notwithstanding anything herein to the contrary, Thoughtworks shall have no obligation to defend + Licensee or to pay Licensee’s costs, damages or attorney’s fees, or have any liability whatsoever, + for any claim resulting from or attributable to any modifications to the Product or any combination of the + Product with other with products or other items not approved by Thoughtworks or any failure to implement an + update to the Product or if Licensee is otherwise not using the Product in accordance with this + Agreement.

    8. + +
  8. +
    BREACH, CURE, AND TERMINATION OF THE AGREEMENT
    +

    Thoughtworks can terminate this Agreement in the event of breach by Licensee. Breach by Licensee + includes: 1) the failure to prevent unauthorized use or distribution of the Product; 2) accessing, using, + modifying, or distributing Third-Party Software independently of the Product and without permission; 3) + nonpayment, or 4) any other activity that violates this Agreement. Thoughtworks may terminate this Agreement + immediately upon giving notice to Licensee if after giving Licensee written notice that it is in breach of the + Agreement, Licensee fails to cure the breach within seven (7) days of receipt of the notice; except + that in the case of Licensee’s failure to pay Support Fees or comply with Section 2, Thoughtworks reserves + the right to terminate this Agreement immediately and without notice or opportunity to cure. In the event of + termination of this Agreement: a) all outstanding License Fees and any other amounts owed by + Licensee are immediately due and payable; and b) all license rights (including without limitation the perpetual + license) granted to Licensee under this Agreement and in relation to the Product are revoked and the Licensee + must destroy all copies of the Product. If Licensee terminates the applicable Go Support Schedule, then + this Agreement shall automatically terminate.

    9. + +
  9. +
    EXPORT
    +

    Licensee acknowledges that this Product may be subject to export controls or restrictions by the + United States or other countries or territories and Licensee hereby certifies that Licensee is not located + in Cuba, Iran, North Korea, Sudan, or Syria. Additionally, Licensee affirms that, to Licensee’s knowledge, + Licensee is not included on any list that would cause Thoughtworks' provision of this Product to Licensee to + be prohibited by the laws or regulations of the United States, including the Department of Commerce’s + ("DOC") Denied Persons, Entities, and Unverified Lists; the U.S. Department of State’s Debarred List; or on + the U.S. Department of Treasury’s lists of Specially Designated Nationals, Specially Designated Narcotics + Traffickers, or Specially Designated Terrorists. Licensee agrees to comply with all applicable + export and re-export control laws and regulations, including the Export Administration Regulations ("EAR") + maintained by the U.S. Department of Commerce.

    +
    10. + +
  10. +
    ASSIGNMENT
    +

    Licensee may not assign its rights under this Agreement except in the case of a change in control of + Licensee, including merger or sale. Licensee must give Thoughtworks 60 days written notice of any + such assignment. Thoughtworks may assign its rights and obligations under this agreement for any reason + and without the consent of Licensee.

    +
    11. + +
  11. +
    SEVERABILITY
    +

    Each provision of this Agreement shall be interpreted in such a manner as to be effective and valid + under applicable law. The invalidity or unenforceability of any provision of this Agreement shall in no + way affect the validity or enforceability of any other provision hereof. Any invalid or unenforceable provision + shall be deemed severed from this Agreement and the balance of this Agreement shall be construed and + enforced as if this Agreement did not contain the particular provisions(s) held to be invalid or unenforceable + and so as to effect the original intent of the parties hereto.

    +
    12. + +
  12. +
    GOVERNING LAW
    +

    This Agreement shall be deemed executed in the State of Delaware, U.S.A., and shall be governed by + and construed in accordance with the laws of the State of Delaware, without regard to choice of law or + conflict of law principles. For purposes of enforcement of arbitration awards, equitable relief, or if for + any other reason litigation is permissible under this agreement, each party hereby irrevocably agrees to the + exclusive personal jurisdiction and venue of any court located in the State of Delaware.

    13. + +
  13. +
    NO WAIVER
    +

    No failure or delay by either party in exercising any right, power, or privilege granted under this + Agreement shall operate as a waiver thereof, nor shall any single or partial exercise thereof + preclude any other or further exercise thereof or the exercise of any right, power or privilege granted under + this Agreement. The knowing waiver of a Breach of this Agreement or the failure of a party to exercise + any right under this Agreement shall in no event constitute a waiver as to any other breach, whether similar + or dissimilar in nature, or prevent the exercise of any right under this Agreement.

    +
    14. + +
  14. +
    SURVIVAL
    +

    The provisions of Sections 4, 5, 6, 7, 9, 11, 12, 14, 15, 17, 18 and 19 shall survive the + cancellation or termination of this Agreement. All other provisions of this Agreement, which by their terms or + import are intended to survive such cancellation or termination, shall survive.

    +
    15. + +
  15. +
    NO THIRD-PARTY BENEFICIARIES
    +

    This Agreement may only be enforced by the parties hereto and their respective successors and assigns + and there are no third-party beneficiaries to this Agreement.

    +
    16. + +
  16. +
    AMENDMENT
    +

    This Agreement can only be modified by mutual written assent of the parties. The parties agree that + the terms on either party’s purchase order, invoice or other business forms are not binding on the other + party and shall not be of any effect whatsoever and may not affect, alter, or modify the terms and + conditions of this Agreement unless they are expressly incorporated into a formal written agreement signed by both + parties.

    +
    17. + +
  17. +
    U.S. FEDERAL PROCUREMENT REQUIREMENTS
    +

    PURSUANT TO FAR 52.212-5(E) AND/OR FAR 52.244-6, FOR ANY ORDER DOCUMENTS REFERENCING A SPECIFIC U.S. + GOVERNMENT PRIME CONTRACT, ALL APPLICABLE PROCUREMENT REGULATIONS REQUIRED BY FEDERAL STATUTE OR + REGULATION TO BE INSERTED IN U.S. GOVERNMENT SUBCONTRACTS APPLY, INCLUDING BUT NOT LIMITED TO 52.203-13, + CONTRACTOR CODE OF BUSINESS ETHICS AND CONDUCT, FAR 52.203-15, WHISTLEBLOWER PROTECTIONS UNDER THE AMERICAN + RECOVERY AND REINVESTMENT ACT OF 2009, FAR 52.219-8 - UTILIZATION OF SMALL BUSINESS CONCERNS, FAR 52.222-26 - + EQUAL OPPORTUNITY, FAR 52.222-35 - EQUAL OPPORTUNITY FOR SPECIAL DISABLED VETERANS, VETERANS OF THE + VIETNAM ERA, AND OTHER ELIGIBLE VETERANS, FAR 52.222-36 - AFFIRMATIVE ACTION FOR WORKERS WITH DISABILITIES, FAR + 52.222-39 - NOTIFICATION OF EMPLOYEE RIGHTS CONCERNING PAYMENT OF UNION DUES OR FEES, FAR 52.222-41 - SERVICE + CONTRACT ACT OF 1965, FAR 52.222-50 – COMBATING TRAFFICKING IN PERSONS, FAR 52.222-51, EXEMPTION FROM + APPLICATION OF THE SERVICE CONTRACT ACT TO CONTRACTS FOR MAINTENANCE, CALIBRATION, OR REPAIR OF CERTAIN EQUIPMENT – + REQUIREMENTS, FAR 52.222-53, EXEMPTION FROM APPLICATION OF THE SERVICE CONTRACT ACT TO CONTRACTS FOR + CERTAIN SERVICE – REQUIREMENTS, FAR 52.222-54, EMPLOYMENT ELIGIBILITY VERIFICATION, FAR 52.226-6, PROMOTING + EXCESS FOOD DONATION TO NONPROFIT ORGANIZATIONS, FAR 52.247-64 - PREFERENCE FOR PRIVATELY OWNED U.S. FLAG + COMMERCIAL VESSELS (AS REQUIRED IN ACCORDANCE WITH PARAGRAPH (D) OF FAR CLAUSE 52.247-64. THESE + PROVISIONS HAVE THE SAME FORCE AND EFFECT AS IF THEY WERE STATED IN THEIR FULL TEXT.

    +
    18. + +
  18. +
    U.S. GOVERNMENT RIGHTS
    +

    IF YOU ARE A US GOVERNMENT ENTITY THEN YOU SHOULD BE AWARE THAT THE SOFTWARE IS A “COMMERCIAL ITEM,” + AS THAT TERM IS DEFINED IN 48 CFR 2.101, CONSISTING OF “COMMERCIAL COMPUTER SOFTWARE” AND “COMMERCIAL + COMPUTER SOFTWARE DOCUMENTATION,” AS SUCH TERMS ARE USED IN 48 CFR 12.212. CONSISTENT WITH 48 CFR 12.212 AND + 48 CFR 227.7202-1 AND 227.7202-4, ALL SUCH CUSTOMERS ACQUIRE THE SOFTWARE WITH ONLY THOSE RIGHTS SET FORTH + HEREIN. THE TERMS OF THIS LICENSE ARE SUBJECT TO 48 CFR 52.227-19. THE USE, DUPLICATION, OR DISCLOSURE BY + THE US GOVERNMENT OF THE SOFTWARE IS SUBJECT TO RESTRICTIONS AS PROVIDED IN 48 CFR 12.211 AND 12.212, 48 + CFR 52.227-19, 48 CFR 252.227-7015, AS APPLICABLE.

    + +

    THIS COMMERCIAL SOFTWARE AND COMMERCIAL COMPUTER SOFTWARE DOCUMENTATION WAS DEVELOPED ENTIRELY AT + PRIVATE EXPENSE AND IS PROVIDED WITH RESTRICTED RIGHTS TO UNITED STATES GOVERNMENT AGENCIES IN ACCORDANCE + WITH THE TERMS OF THIS AGREEMENT, FAR 12.212 AND DFARS 227.7202 FOR COMMERCIAL TECHNICAL DATA. THE + RESTRICTIONS SET FORTH IN FAR 12.211 AND FOR DOD AGENCIES DFARS 252.227-7015 SHALL ALSO APPLY. DATA FIRST PRODUCED IN + THE PERFORMANCE OF WORK UNDER THIS AGREEMENT IS PROVIDED TO U.S. GOVERNMENT AGENCIES IN ACCORDANCE WITH + FAR 52.227-14(B)(1)(I). THESE PROVISIONS HAVE THE SAME FORCE AND EFFECT AS IF THEY WERE STATED IN THEIR + FULL TEXT.

    +
    19. + +
  19. +
    ENTIRE AGREEMENT
    +

    This Agreement, the Go Support Schedule and the applicable Order Documents (if any), constitute the + entire agreement between the parties with respect to the subject matter hereof, and supersedes and replaces + all prior or contemporaneous understandings, representations, communications, or agreements, written or + oral, including any additional or contrary terms contained in any Licensee purchase order or other + procurement document, regarding the Product or in any way related to Thoughtworks intellectual property rights + in the Product. In the event of a conflict between the terms of this Thoughtworks Go Extensions End User + License Agreement and the Thoughtworks Support Services General Terms located at + https://www.thoughtworks.com/products/go-continuous-delivery/thoughtworks-support-services-general-terms, + then solely with respect to Thoughtworks’ supply and Licensee’s use of the Product, the terms of + this Thoughtworks Go Extensions End User License Agreement shall control.

    +
    20. + +
+
+
+ +
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/enterprise/thoughtworks-support-services-general-terms.html b/pr-1714/enterprise/thoughtworks-support-services-general-terms.html new file mode 100644 index 000000000..174c2a4b1 --- /dev/null +++ b/pr-1714/enterprise/thoughtworks-support-services-general-terms.html @@ -0,0 +1,377 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+
+
This page was redirected from https://www.thoughtworks.com/go/thoughtworks-support-services-general-terms/
+ +
+
+

Thoughtworks Support Services
General Terms

+
+
+ +
+
+
    +
  1. +
    Definitions
    + + The following words shall have the following meanings when used in this Agreement: + +
      +
    1. Business Day shall mean, Monday through Friday in the location of Customer s principal place of business, except for Thoughtworks Holidays.
      2. +
    2. Business Hours shall mean, 9:00AM 5:00PM in the location of Customer s principal place of business.
      3. +
    3. Documentation shall mean the user manual, specifications and explanations of functionality distributed with the Software or made available online by Thoughtworks.
      4. +
    4. Initial Target Response Period means the time period starting from the time that an Issue is first logged with Thoughtworks and concluding when Thoughtworks provides the Response.
      5. +
    5. Issue(s) shall mean a failure of the Software to materially conform to the specifications described in the Documentation and which has been logged to Thoughtworks as an issue via an issue ticket tracking system.
      6. +
    6. Named Contact means the individual(s) designated by Customer to act as the primary point of contact between Thoughtworks and Customer. Any Named Contact may be changed by giving Thoughtworks ten (10) business days prior written notice, via email to support@thoughtworks.com. Named Contacts must be trained and proficient in the operation of the Software.
      7. +
    7. Out-of-Scope shall mean Issues (a) determined not to be related to the Software, (b) attributable to third party software or hardware, (c) caused by any of the following: use of the Software on unsupported platforms (such as browser, OS, and networking); use of the Software on hardware/software configurations that do not meet the system requirements specified by Thoughtworks; failure resulting from misapplication or abnormal use as determined by the user instruction, manual or specification provided by Thoughtworks or virus introduced by third parties or Customer, any repair, adjustment, alteration, or modification of the Software without Thoughtworks prior written consent (the availability of macros, macro development capabilities, plugins, APIs and certain Software source code shall not be deemed to be Thoughtworks consent to any repair, adjustment, alteration or modification of the Software for purposes of Maintenance and Support); environmental issues outside of Thoughtworks control, including without limitation network and file system permissions, network topology or CPU capacity. For further clarity with regard to plugins for the Software, as a general matter, plugins for the Software are not Thoughtworks software; plugins are written by third parties and are distributed under license from the copyright holder. In addition, notwithstanding who the copyright holder is, if Thoughtworks makes plugins available for download, these plugins are made available as is and as available , without warranties of any kind, either express or implied, including but not limited to the implied warranties of merchantability, satisfactory quality, and fitness for a particular purpose. Thoughtworks does not endorse, recommend or provide support for any plugins other than the officially maintained Thoughtworks plugins; and Thoughtworks accepts no responsibility with regard to functionality, bugs, data loss, security or any other problem associated with plugins that are not officially maintained by Thoughtworks. You can see which plugins are officially maintained by Thoughtworks at https://www.gocd.org/plugins/.
      8. +
    8. Response shall mean the first report delivered to Customer by Thoughtworks after an Issue has been received.
      9. +
    9. Software shall mean the source and object code of a version of the open source software known as Go, distributed by Thoughtworks, which is designated by Thoughtworks as an Extended Support Version and has been provided to the public by Thoughtworks within the 6 months prior to the Issue being logged to Thoughtworks as an issue via an issue ticket tracking system.
      10. +
    10. Term shall mean collectively, the Initial Term and all Renewal Terms hereunder.
      11. +
    11. Third-Party shall mean a party other than Thoughtworks.
      12. +
    12. Thoughtworks Holidays means the days listed at https://support.thoughtworks.com/entries/53932200-Support-Holiday-Schedule.
      13. +
    13. Workaround shall mean a change in the procedures followed or input parameters supplied by Customer to avoid the Issue and to provide a result similar or identical to the operation of the Software as if the Issue had not occurred.
      14. +
    +
    2. + +
  2. +
    Services
    + + Thoughtworks will use reasonable efforts to respond to the Issue from the Named Contacts within the Initial Response + Period below. All Support will be provided in the English language, only. Customer shall provide Thoughtworks with all + reasonably requested assistance to enable Thoughtworks to understand Customer's Software and hardware configuration and + to recreate the Issue in a test environment. + +
    +
    + Service level + Premium +
    + +
    + Forums use + Yes +
    + +
    + Web Portal Case Management + Yes +
    + +
    + Knowledge Base access + Yes +
    + +
    + Support Channels + + Web Portal
    + Email
    + Phone
    + Remote +     +
    + +
    + Initial Target Response Period for Urgent Severity Issues + Within 1 Business Hour +
    + +
    + Initial Target Response Period for High Severity Issue + Within 2 Business Hours +
    + +
    + Initial Target Response Period for Normal Severity Issue + Within 4 Business Hours +
    + +
    + Initial Target Response Period for Low Severity Issue + Within 8 Business Hours +
    + +
    + Support Hours + + Standard Business Hours
    + (24 x 5 for Urgent Severity Issue) +     +
    + +
    + Named Contacts + 4 +
    + +
    + Number of Monthly Support Incidents + Unlimited +
    + +
    + Urgent Bug Escalation & Hot Fix + Yes +
    +
    + +

    Issue Severity definitions:

    + +

    An "Urgent Severity Issue" causes i) the Software to be completely unusable or inoperable and ii) no workaround exists.

    + +

    A "High Severity Issue" causes i) a critical function in the Software to be impeded or restricted and ii) no workaround exists.

    + +

    A "Normal Severity Issue" is an Issue that i) causes the Software to demonstrate a failure preventing the normal use of certain function(s) and ii) a reasonable workaround exists.

    + +

    A "Low Severity Issue" is an Issue that i) does not impede normal function of the Software but may be an inconvenience or ii) is a limitation or defect in a function or of the Software that is not an Urgent, High or Normal Severity Issue and iii) a practical workaround is available for an indefinite period of time.

    +
    3. + +
  3. +
    Term and Termination
    + +
      +
    1. Term. The term of this Agreement shall be as set forth in the applicable Support Schedule.
      2. +
    2. Non-Renewal. Any renewal of this Agreement shall be as set forth in the applicable Support Schedule.
      3. +
    3. Material Breach. With the exception of monetary breaches as described in Section 3.4, either party may terminate this Agreement upon fourteen (14) days written notice in the event of a breach of any other material provision of this Agreement by the other party, provided that, during such fourteen (14) day period, the breaching party fails to cure such breach.
      4. +
    4. Monetary Breach. If a party fails to make a monetary payment as specified in this Agreement, the non-breaching party shall notify the other party of such failure and if the breaching party fails to cure such breach within five (5) days, the non-breaching party may terminate this Agreement.
      5. +
    +
    4. + +
  4. +
    Fees, Invoices, Payment Taxes
    + +
      +
    1. Fees. Support Fees are those fees set forth in the applicable Support Schedule and payable by Customer to Thoughtworks in consideration of Thoughtworks' provision of the services described in the applicable Support Schedule. Thoughtworks reserves the right to alter the Support Fees by providing Customer with written notice at least ninety (90) days prior to the annual renewal date.
      2. +
    2. Invoices. Thoughtworks shall invoice Customer annually for Support Fees and in advance for all pre-approved Expenses. Any such invoice shall be payable by check or wire transfer or ACH within the time set forth in the applicable Support Schedule. Late payments shall accrue interest at a rate of the lesser of one and one-half percent (1.5%) per month or the highest rate allowed by law.
      3. +
    3. Expenses. Thoughtworks shall not incur any expenses without Customer's prior written approval. Customer shall reimburse Thoughtworks for all pre-approved materials and reasonable out-of-pocket expenses it incurs in connection with the performance of its obligations under this Agreement ("Expenses").
      4. +
    4. Taxes. There shall be added to the charges provided for in this Agreement amounts equal to any taxes, whether federal, state, or local, however designated, that may be validly levied or based upon this Agreement or upon the software, hardware, and Services furnished hereunder, excluding, however, taxes based on or measured by Thoughtworks' net income, and any taxes or amounts in lieu thereof paid or payable by Thoughtworks in respect of the foregoing. Taxes payable by Customer shall be billed as separate items on Thoughtworks' invoices and shall not be included in Thoughtworks' fees or prices. Customer shall have the right to have Thoughtworks contest with the imposing jurisdiction, at Customer's expense, any such taxes that Customer deems are improperly levied.
      5. +
    +
    5. + +
  5. +
    Warranties, Indemnity and Liability
    + +
      +
    1. Warranty. Thoughtworks warrants that all Services will be performed in a professional manner with due care, skill and diligence using qualified professional personnel.
      2. +
    2. Malicious Code. Thoughtworks shall not transmit to Customer, or cause any Customer system to be exposed to any viruses, worms, time bombs, Trojan horses or other harmful or malicious code, files, scripts, agents or programs ("Malicious Code"). Thoughtworks shall notify Customer in writing and in reasonable detail immediately upon becoming aware of Thoughtworks transmitting any Malicious Code to a Customer system, Thoughtworks shall cooperate with Customer, at Thoughtworks' expense, to assist Customer with removal of the Malicious Code and repair any corrupted files or data.
      3. +
    3. Remedy. As Customer's sole and exclusive remedy for breach of this warranty, Thoughtworks will re-perform the defective Services in a manner that confirms with the warranty in Section 5.1 of this Agreement, at no additional cost to Customer.
      4. +
    4. Disclaimer. EXCEPT AS OTHERWISE STATED IN THIS AGREEMENT, THE SERVICES ARE PROVIDED "AS-IS" AND AS AVAILABLE, WITH NO WARRANTY OF ANY KIND, AND THOUGHTWORKS, ON BEHALF OF ITSELF AND ITS LICENSORS AND SUPPLIERS, EXPRESSLY DISCLAIMS ANY WARRANTY AND CONDITIONS OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, ACCURACY, OR NON-INFRINGEMENT AND THOUGHTWORKS AND ITS SUPPLIERS AND LICENSORS DO NOT GUARANTEE AND DO NOT PROMISE ANY SPECIFIC RESULTS FROM THE USE OF THE SERVICES. THOUGHTWORKS DOES NOT WARRANT THAT THE SERVICES WILL MEET CUSTOMER'S REQUIREMENTS, OR THAT THE SERVICES WILL BE UNINTERRUPTED OR ERROR OR DEFECT FREE, OR THAT DEFECTS IN THE SERVICES WILL BE CORRECTED.
      5. +
    5. Indemnity. Thoughtworks will defend or settle, at its expense, any action brought against Customer based upon the claim that the Services, when used in accordance with this Agreement, infringe an issued U.S. patent or registered copyright; provided, however, that: (i) Customer notifies Thoughtworks promptly in writing of any such claim; (ii) Customer does not enter into any settlement related to any claim without Thoughtworks' prior written consent; (iii) Thoughtworks has sole control of any claim and all related settlement negotiations; and (iv) as requested, Customer provides Thoughtworks with all information and assistance necessary to settle or defend the claim.
      6. +
    6. + Liability. +
        +
      1. UNDER NO CIRCUMSTANCES, INCLUDING NEGLIGENCE, SHALL EITHER PARTY BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, COST OF PROCUREMENT OF SUBSTITUTE SOFTWARE, GOODS OR SERVICES, OR SPECIAL, INDIRECT, INCIDENTAL OR CONSEQUENTIAL LOSS OR DAMAGES, EITHER IN CONTRACT OR TORT, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR THAT RESULT FROM THE USE OR INABILITY TO USE THE SERVICES, EVEN IF THOUGHTWORKS IS ADVISED OF THE POSSIBILITY. IN ADDITION, IN NO EVENT SHALL EITHER PARTY'S TOTAL LIABILITY FOR ALL DAMAGES, LOSSES AND CAUSES OF ACTION EXCEED THE AMOUNT PAID OR TO BE PAID BY CUSTOMER UNDER THIS AGREEMENT. TO THE EXTENT THAT LIABILITY FOR DEATH OR PERSONAL INJURY CAUSED BY ITS NEGLIGENCE, CAUSED BY FRAUDULENT MISREPRESENTATION OR DECEIT, OR ANY OTHER LIABILITY THAT MAY NOT BE EXCLUDED OR LIMITED BY APPLICABLE LAW, NEITHER PARTY EXCLUDES OR LIMIT ITS LIABILITY.
        2. +
      2. The Parties agree that the limitations on and exclusions of liability listed in this Section 5 were freely negotiated and are an integral part of the bargain, in that the Services would not have been available for the same price and under the same terms and conditions had such limitations on and exclusions of liability not been included in this Agreement.
        3. +
      3. To the extent the foregoing warranty disclaimer or limitation of liability is not allowed by applicable law, then the liability of Thoughtworks, and Customer's remedy, shall be limited to, at Thoughtworks' option: (i) the re-supply of any defective Services; or (ii) the refund of any Support Fees paid by Customer for the period within which defective Services were performed.
        4. +
      +
      7. +
    +
    6. + +
  6. +
    Confidential Information
    + +
      +
    1. + Definitions. +
        +
      1. As used in this Agreement, "Confidential Information" means all information, and all documents and other tangible materials and things which record it, relating to, or used in either party's business, whether or not Trade Secret Information (as defined below), and whether owned by either party, any of their clients, or any third party vendor, which is not generally known to the public, or to either party's or their clients' competitors, and was disclosed to either party to this Agreement by the other party. Confidential Information includes, without limitation, the following especially sensitive types of information which are owned or used by either party, or owned by either party's clients, or third party vendors: (1) business channels, business plans, product development and marketing plans, advertising programs, and planning and merchandising strategies; (2) technical information, including formulae, pricing information, processes and methods of production; (3) Trade Secret Information (as defined hereafter), manuals, ideas, know-how, research-in-progress, work-in-progress, prototypes, and the like; (4) the identity, purchase and payment patterns of, and special relations with, customers and prospective customers; (5) the identity, net prices and credit terms of, and special relations with, suppliers and shippers; (6) computer programs, software, computer systems, computer logic, algorithms, individual computer designed features, computer or software features, methods, processes, program or system documentation, data, object codes and source codes and system or software design criteria; (7) business records and financial information; (8) information relating to hiring procedures and assessments; (9) personally identifiable information of employees; and (9) any other information or documents which either party reasonably regards as being confidential.
        2. +
      2. As used in the Agreement, "Trade Secret Information" means Confidential Information, and all documents and other tangible materials and things which record it, and which: (1) has economic value, actual or potential, from not being known by others who could obtain economic value from its disclosure or use; and (2) is the subject of reasonable efforts to maintain its secrecy.
        3. +
      3. Excluded Information. Confidential Information does not include information which: (i) is in or comes into the public domain other than as a result of a disclosure by the party hereto to whom it was disclosed pursuant to this Agreement (the "Receiving Party"), (ii) was known or within Receiving Party's possession prior to its being furnished by or on behalf of the other party hereto (the "Disclosing Party"), (iii) becomes available to the Receiving Party from a source other than the Disclosing Party or any of its representatives, provided that such source is not, to the Receiving Party's knowledge, bound by an obligation of confidentiality to the Disclosing Party or any other party with respect to such information, or (iv) was independently developed by the Receiving Party without reference to the Disclosing Party's Confidential Information.
        4. +
      4. Use and Disclosure. The parties will use Confidential Information of the other party solely for the purposes of evaluating the advisability of an engagement or in the course of the engagement itself, shall keep it confidential, and will not, except as set forth in the following paragraph, disclose any of the other party's Confidential Information in any manner whatsoever. Nothing in this Agreement is intended to grant any rights under any patent, copyright or other intellectual property rights of any party in favor of the other, nor shall this Agreement be construed to grant any party any rights in or to either party's Confidential Information, except the limited right to use such Confidential Information in connection with the proposed relationship between the parties.
        5. +
      5. Further Exceptions. Either party may disclose Confidential Information without being in violation of this Agreement under any of the following circumstances: (i) with the prior written consent of the Disclosing Party; (ii) to its employees, representatives, consultants or agents, solely for the purpose of assisting the Receiving Party with the engagement, but only if such person has been informed of the confidential nature of the Confidential Information and is obligated to maintain its confidentiality; or (iii) as required by law, legal process or the rules of any applicable stock exchange, in which event the Receiving Party shall give the Disclosing Party prompt notice thereof so that the Disclosing Party may seek a protective order and/or waive the duty of nondisclosure (except to the extent that the Receiving Party's provision of such notice would cause it to violate a court order or other legal requirement); provided that in the absence of such order or waiver, if the Receiving Party or any such representative shall, in the opinion of its counsel, stand liable for contempt or suffer other censure or penalty for failure to disclose, disclosure pursuant to the order of such tribunal may be made by the Receiving Party or its representative without liability hereunder.
        6. +
      6. Return of Information. At any time upon request of a Disclosing Party for any reason, the Receiving Party will promptly destroy or deliver to the Disclosing Party all documents (and all copies thereof) furnished to the Receiving Party by or on behalf of the Disclosing Party, and all documents created by the Receiving Party in reliance on documents and information furnished to the Receiving Party by or on behalf of the Disclosing Party. Notwithstanding the return of the Confidential Information the Receiving Party will continue to be bound by its obligations of confidentiality and non-use hereunder. Provided the Receiving Party continues to comply with this Agreement, the Receiving Party may retain any Confidential Information that: (a) is included in any back ups made in the ordinary course of its business which are not capable of ready search and deletion; (b) the Receiving Party is required by law or any Regulatory Requirement to retain, or needs to retain to defend itself in any proceeding being brought or threatened against it at the time the Confidential Information must be returned or destroyed; or (c) the Receiving Party is required to retain for its own reasonable internal credit, risk, insurance, taxation or record-keeping purposes.
        7. +
      7. Injunctive Relief. It is agreed that the unauthorized disclosure or use of any Confidential Information will cause immediate or irreparable injury to the parties, and that the parties cannot be adequately compensated for such injury in monetary damages. The parties therefore acknowledge and agree that, in such event, either party shall be entitled to any temporary or permanent injunctive relief necessary to prevent such unauthorized disclosure or use, or threat of disclosure or use.
        8. +
      +
      2. +
    +
    7. + +
  7. +
    Intellectual Property
    + +
      +
    1. Ownership of Existing Intellectual Property. Except as expressly stated in this Agreement, the ownership of the Intellectual Property Rights of each of the Parties as at the date of commencement of this Agreement shall not be affected by this Agreement.
      2. +
    2. Ownership of Services and Grant of License. Thoughtworks retains all right, title and interest in and to the Services, including but not limited to any computer software source or object code, ideas, concepts, know-how, methods, documentation, manuals, charts, diagrams, screen displays, schematics, blueprints or drawings that are used, developed or provided to Customer in the course of providing the Services to Customer under this Agreement. Customer agrees that Customer shall assign to Thoughtworks all right, title, and interest in and to the Services including but not limited to any computer software source or object code, ideas, concepts, know-how, methods, documentation, manuals, charts, diagrams, screen displays, schematics, blueprints or drawings that are created in connection with the performance of the Services.
      3. +
    3. Residual Rights. Both parties acknowledge and agree that each party shall retain ownership of, and shall have the unrestricted right to use, any general knowledge, skills, and experience, and any ideas, concepts, know-how, techniques, designs, generalized frameworks, models, and artifacts ("Residual Rights"), which such party obtains in the course of fulfilling its obligations under this Agreement.
      4. +
    +
    8. + +
  8. +
    Export
    + +

    Customer represents that it is not located in Cuba, Iran, North Korea, Sudan, or Syria and Customer shall not export or re-export any Services rendered by Thoughtworks under this Agreement to Cuba, Iran, North Korea, Sudan, or Syria. Additionally, Customer affirms that, to Customer's knowledge, Customer is not included on any list that would cause Thoughtworks' export of the Services to Customer to be prohibited by the laws or regulations of the United States, including the Department of Commerce's ("DOC") Denied Persons, Entities, and Unverified Lists; the U.S. Department of State's Debarred List; or on the U.S. Department of Treasury's lists of Specially Designated Nationals, Specially Designated Narcotics Traffickers, or Specially Designated Terrorists. Customer agrees to indemnify, to the fullest extent permitted by law, Thoughtworks from and against any fines or penalties that may arise as a result of any breach by Customer of this provision.

    +
    9. + +
  9. +
    Assignment
    + +

    Customer may not assign its rights under this Agreement except in the case of a change in control of Customer, including merger or sale. Customer must give Thoughtworks sixty (60) days prior written notice of any such assignment. Thoughtworks may assign its rights and obligations under this agreement for any reason and without the consent of Customer.

    +
    10. + +
  10. +
    Severability
    + +

    Each provision of this Agreement shall be interpreted in such a manner as to be effective and valid under applicable law. The invalidity or unenforceability of any provision of this Agreement shall in no way affect the validity or enforceability of any other provision hereof. Any invalid or unenforceable provision shall be deemed severed from this Agreement and the balance of this Agreement shall be construed and enforced as if this Agreement did not contain the particular provisions(s) held to be invalid or unenforceable and so as to effect the original intent of the parties hereto.

    +
    11. + +
  11. +
    Disputes and Governing Law
    + +
      +
    1. Any controversy or dispute between the parties shall be settled first by negotiation between a Customer Named Contact and the Thoughtworks Support Manager. In the event the representatives are unable to resolve the dispute within ninety (90) days, the parties agree to elevate the dispute to their respective Presidents or equivalent officer. If, after sixty (60) days, the parties are still unable to resolve the dispute, the Parties shall participate in mediation pursuant to the then-current JAMS International Mediation Rules. If mediation is unsuccessful, then the Parties will resolve the dispute by binding arbitration before a single, mutually agreed upon arbitrator with at least ten (10) years of experience in the field of software support services, regardless of the amount in dispute. The arbitration shall be administered by the American Arbitration Association in accordance with its Commercial Arbitration Rules, except as set forth herein. The decision and award of the arbitrator shall be final and binding and the award so rendered may be entered in any court having jurisdiction thereof. The arbitration shall be held in Chicago, Illinois. No damages excluded by or in excess of any damage limitations set forth in this Agreement, including punitive or other non-compensatory damages, shall be awarded. Nothing herein contained shall bar the right of either party to obtain equitable relief from a court of law or equity with regard to a claim under the Confidentiality Agreement.
      2. +
    2. This Agreement shall be deemed executed in the State of Delaware, U.S.A., and shall be governed by and construed in accordance with the laws of the State of Delaware, without regard to choice of law or conflict of law principles. For purposes of enforcement of arbitration awards, equitable relief, or if for any other reason litigation is permissible under this agreement, each party hereby irrevocably agrees to the exclusive personal jurisdiction and venue of any court located in the State of Delaware.
      3. +
    +
    12. + +
  12. +
    No Waiver
    + +

    No failure or delay by either party in exercising any right, power, or privilege granted under this Agreement shall operate as a waiver thereof, nor shall any single or partial exercise thereof preclude any other or further exercise thereof or the exercise of any right, power or privilege granted under this Agreement. The knowing waiver of a Breach of this Agreement or the failure of a party to exercise any right under this Agreement shall in no event constitute a waiver as to any other breach, whether similar or dissimilar in nature, or prevent the exercise of any right under this Agreement.

    +
    13. + +
  13. +
    Amendment
    + +

    This Agreement can only be modified by mutual written assent of the parties. The parties agree that the terms on either party's purchase order, invoice or other business forms are not binding on the other party and shall not be of any effect whatsoever and may not affect, alter, or modify the terms and conditions of this Agreement unless they are expressly incorporated into a formal written agreement signed by both parties.

    +
    14. + +
  14. +
    Independent Contractor
    + +

    For all purposes hereof and in the performance of its obligations under this Agreement, Thoughtworks is and shall remain an independent contractor and nothing in this Agreement shall be deemed or construed to create an employer/employee, joint venture or partnership relationship between Thoughtworks and Customer. Nothing herein shall be deemed or construed to create an employment relationship between Customer and any employee, agent or independent contractor of Thoughtworks. Neither party shall have any authority to insure any obligations on behalf of the other party or to make any promise, representation or contract of any nature on behalf of the other party.

    +
    15. +
+
+
+ +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/enterprise/thoughtworks-support-services-general-terms/index.html b/pr-1714/enterprise/thoughtworks-support-services-general-terms/index.html new file mode 100644 index 000000000..a9b5ea3c0 --- /dev/null +++ b/pr-1714/enterprise/thoughtworks-support-services-general-terms/index.html @@ -0,0 +1,377 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+
+
This page was redirected from https://www.thoughtworks.com/go/thoughtworks-support-services-general-terms/
+ +
+
+

Thoughtworks Support Services
General Terms

+
+
+ +
+
+
    +
  1. +
    Definitions
    + + The following words shall have the following meanings when used in this Agreement: + +
      +
    1. Business Day shall mean, Monday through Friday in the location of Customer s principal place of business, except for Thoughtworks Holidays.
      2. +
    2. Business Hours shall mean, 9:00AM 5:00PM in the location of Customer s principal place of business.
      3. +
    3. Documentation shall mean the user manual, specifications and explanations of functionality distributed with the Software or made available online by Thoughtworks.
      4. +
    4. Initial Target Response Period means the time period starting from the time that an Issue is first logged with Thoughtworks and concluding when Thoughtworks provides the Response.
      5. +
    5. Issue(s) shall mean a failure of the Software to materially conform to the specifications described in the Documentation and which has been logged to Thoughtworks as an issue via an issue ticket tracking system.
      6. +
    6. Named Contact means the individual(s) designated by Customer to act as the primary point of contact between Thoughtworks and Customer. Any Named Contact may be changed by giving Thoughtworks ten (10) business days prior written notice, via email to support@thoughtworks.com. Named Contacts must be trained and proficient in the operation of the Software.
      7. +
    7. Out-of-Scope shall mean Issues (a) determined not to be related to the Software, (b) attributable to third party software or hardware, (c) caused by any of the following: use of the Software on unsupported platforms (such as browser, OS, and networking); use of the Software on hardware/software configurations that do not meet the system requirements specified by Thoughtworks; failure resulting from misapplication or abnormal use as determined by the user instruction, manual or specification provided by Thoughtworks or virus introduced by third parties or Customer, any repair, adjustment, alteration, or modification of the Software without Thoughtworks prior written consent (the availability of macros, macro development capabilities, plugins, APIs and certain Software source code shall not be deemed to be Thoughtworks consent to any repair, adjustment, alteration or modification of the Software for purposes of Maintenance and Support); environmental issues outside of Thoughtworks control, including without limitation network and file system permissions, network topology or CPU capacity. For further clarity with regard to plugins for the Software, as a general matter, plugins for the Software are not Thoughtworks software; plugins are written by third parties and are distributed under license from the copyright holder. In addition, notwithstanding who the copyright holder is, if Thoughtworks makes plugins available for download, these plugins are made available as is and as available , without warranties of any kind, either express or implied, including but not limited to the implied warranties of merchantability, satisfactory quality, and fitness for a particular purpose. Thoughtworks does not endorse, recommend or provide support for any plugins other than the officially maintained Thoughtworks plugins; and Thoughtworks accepts no responsibility with regard to functionality, bugs, data loss, security or any other problem associated with plugins that are not officially maintained by Thoughtworks. You can see which plugins are officially maintained by Thoughtworks at https://www.gocd.org/plugins/.
      8. +
    8. Response shall mean the first report delivered to Customer by Thoughtworks after an Issue has been received.
      9. +
    9. Software shall mean the source and object code of a version of the open source software known as Go, distributed by Thoughtworks, which is designated by Thoughtworks as an Extended Support Version and has been provided to the public by Thoughtworks within the 6 months prior to the Issue being logged to Thoughtworks as an issue via an issue ticket tracking system.
      10. +
    10. Term shall mean collectively, the Initial Term and all Renewal Terms hereunder.
      11. +
    11. Third-Party shall mean a party other than Thoughtworks.
      12. +
    12. Thoughtworks Holidays means the days listed at https://support.thoughtworks.com/entries/53932200-Support-Holiday-Schedule.
      13. +
    13. Workaround shall mean a change in the procedures followed or input parameters supplied by Customer to avoid the Issue and to provide a result similar or identical to the operation of the Software as if the Issue had not occurred.
      14. +
    +
    2. + +
  2. +
    Services
    + + Thoughtworks will use reasonable efforts to respond to the Issue from the Named Contacts within the Initial Response + Period below. All Support will be provided in the English language, only. Customer shall provide Thoughtworks with all + reasonably requested assistance to enable Thoughtworks to understand Customer's Software and hardware configuration and + to recreate the Issue in a test environment. + +
    +
    + Service level + Premium +
    + +
    + Forums use + Yes +
    + +
    + Web Portal Case Management + Yes +
    + +
    + Knowledge Base access + Yes +
    + +
    + Support Channels + + Web Portal
    + Email
    + Phone
    + Remote +     +
    + +
    + Initial Target Response Period for Urgent Severity Issues + Within 1 Business Hour +
    + +
    + Initial Target Response Period for High Severity Issue + Within 2 Business Hours +
    + +
    + Initial Target Response Period for Normal Severity Issue + Within 4 Business Hours +
    + +
    + Initial Target Response Period for Low Severity Issue + Within 8 Business Hours +
    + +
    + Support Hours + + Standard Business Hours
    + (24 x 5 for Urgent Severity Issue) +     +
    + +
    + Named Contacts + 4 +
    + +
    + Number of Monthly Support Incidents + Unlimited +
    + +
    + Urgent Bug Escalation & Hot Fix + Yes +
    +
    + +

    Issue Severity definitions:

    + +

    An "Urgent Severity Issue" causes i) the Software to be completely unusable or inoperable and ii) no workaround exists.

    + +

    A "High Severity Issue" causes i) a critical function in the Software to be impeded or restricted and ii) no workaround exists.

    + +

    A "Normal Severity Issue" is an Issue that i) causes the Software to demonstrate a failure preventing the normal use of certain function(s) and ii) a reasonable workaround exists.

    + +

    A "Low Severity Issue" is an Issue that i) does not impede normal function of the Software but may be an inconvenience or ii) is a limitation or defect in a function or of the Software that is not an Urgent, High or Normal Severity Issue and iii) a practical workaround is available for an indefinite period of time.

    +
    3. + +
  3. +
    Term and Termination
    + +
      +
    1. Term. The term of this Agreement shall be as set forth in the applicable Support Schedule.
      2. +
    2. Non-Renewal. Any renewal of this Agreement shall be as set forth in the applicable Support Schedule.
      3. +
    3. Material Breach. With the exception of monetary breaches as described in Section 3.4, either party may terminate this Agreement upon fourteen (14) days written notice in the event of a breach of any other material provision of this Agreement by the other party, provided that, during such fourteen (14) day period, the breaching party fails to cure such breach.
      4. +
    4. Monetary Breach. If a party fails to make a monetary payment as specified in this Agreement, the non-breaching party shall notify the other party of such failure and if the breaching party fails to cure such breach within five (5) days, the non-breaching party may terminate this Agreement.
      5. +
    +
    4. + +
  4. +
    Fees, Invoices, Payment Taxes
    + +
      +
    1. Fees. Support Fees are those fees set forth in the applicable Support Schedule and payable by Customer to Thoughtworks in consideration of Thoughtworks' provision of the services described in the applicable Support Schedule. Thoughtworks reserves the right to alter the Support Fees by providing Customer with written notice at least ninety (90) days prior to the annual renewal date.
      2. +
    2. Invoices. Thoughtworks shall invoice Customer annually for Support Fees and in advance for all pre-approved Expenses. Any such invoice shall be payable by check or wire transfer or ACH within the time set forth in the applicable Support Schedule. Late payments shall accrue interest at a rate of the lesser of one and one-half percent (1.5%) per month or the highest rate allowed by law.
      3. +
    3. Expenses. Thoughtworks shall not incur any expenses without Customer's prior written approval. Customer shall reimburse Thoughtworks for all pre-approved materials and reasonable out-of-pocket expenses it incurs in connection with the performance of its obligations under this Agreement ("Expenses").
      4. +
    4. Taxes. There shall be added to the charges provided for in this Agreement amounts equal to any taxes, whether federal, state, or local, however designated, that may be validly levied or based upon this Agreement or upon the software, hardware, and Services furnished hereunder, excluding, however, taxes based on or measured by Thoughtworks' net income, and any taxes or amounts in lieu thereof paid or payable by Thoughtworks in respect of the foregoing. Taxes payable by Customer shall be billed as separate items on Thoughtworks' invoices and shall not be included in Thoughtworks' fees or prices. Customer shall have the right to have Thoughtworks contest with the imposing jurisdiction, at Customer's expense, any such taxes that Customer deems are improperly levied.
      5. +
    +
    5. + +
  5. +
    Warranties, Indemnity and Liability
    + +
      +
    1. Warranty. Thoughtworks warrants that all Services will be performed in a professional manner with due care, skill and diligence using qualified professional personnel.
      2. +
    2. Malicious Code. Thoughtworks shall not transmit to Customer, or cause any Customer system to be exposed to any viruses, worms, time bombs, Trojan horses or other harmful or malicious code, files, scripts, agents or programs ("Malicious Code"). Thoughtworks shall notify Customer in writing and in reasonable detail immediately upon becoming aware of Thoughtworks transmitting any Malicious Code to a Customer system, Thoughtworks shall cooperate with Customer, at Thoughtworks' expense, to assist Customer with removal of the Malicious Code and repair any corrupted files or data.
      3. +
    3. Remedy. As Customer's sole and exclusive remedy for breach of this warranty, Thoughtworks will re-perform the defective Services in a manner that confirms with the warranty in Section 5.1 of this Agreement, at no additional cost to Customer.
      4. +
    4. Disclaimer. EXCEPT AS OTHERWISE STATED IN THIS AGREEMENT, THE SERVICES ARE PROVIDED "AS-IS" AND AS AVAILABLE, WITH NO WARRANTY OF ANY KIND, AND THOUGHTWORKS, ON BEHALF OF ITSELF AND ITS LICENSORS AND SUPPLIERS, EXPRESSLY DISCLAIMS ANY WARRANTY AND CONDITIONS OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, ACCURACY, OR NON-INFRINGEMENT AND THOUGHTWORKS AND ITS SUPPLIERS AND LICENSORS DO NOT GUARANTEE AND DO NOT PROMISE ANY SPECIFIC RESULTS FROM THE USE OF THE SERVICES. THOUGHTWORKS DOES NOT WARRANT THAT THE SERVICES WILL MEET CUSTOMER'S REQUIREMENTS, OR THAT THE SERVICES WILL BE UNINTERRUPTED OR ERROR OR DEFECT FREE, OR THAT DEFECTS IN THE SERVICES WILL BE CORRECTED.
      5. +
    5. Indemnity. Thoughtworks will defend or settle, at its expense, any action brought against Customer based upon the claim that the Services, when used in accordance with this Agreement, infringe an issued U.S. patent or registered copyright; provided, however, that: (i) Customer notifies Thoughtworks promptly in writing of any such claim; (ii) Customer does not enter into any settlement related to any claim without Thoughtworks' prior written consent; (iii) Thoughtworks has sole control of any claim and all related settlement negotiations; and (iv) as requested, Customer provides Thoughtworks with all information and assistance necessary to settle or defend the claim.
      6. +
    6. + Liability. +
        +
      1. UNDER NO CIRCUMSTANCES, INCLUDING NEGLIGENCE, SHALL EITHER PARTY BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, COST OF PROCUREMENT OF SUBSTITUTE SOFTWARE, GOODS OR SERVICES, OR SPECIAL, INDIRECT, INCIDENTAL OR CONSEQUENTIAL LOSS OR DAMAGES, EITHER IN CONTRACT OR TORT, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR THAT RESULT FROM THE USE OR INABILITY TO USE THE SERVICES, EVEN IF THOUGHTWORKS IS ADVISED OF THE POSSIBILITY. IN ADDITION, IN NO EVENT SHALL EITHER PARTY'S TOTAL LIABILITY FOR ALL DAMAGES, LOSSES AND CAUSES OF ACTION EXCEED THE AMOUNT PAID OR TO BE PAID BY CUSTOMER UNDER THIS AGREEMENT. TO THE EXTENT THAT LIABILITY FOR DEATH OR PERSONAL INJURY CAUSED BY ITS NEGLIGENCE, CAUSED BY FRAUDULENT MISREPRESENTATION OR DECEIT, OR ANY OTHER LIABILITY THAT MAY NOT BE EXCLUDED OR LIMITED BY APPLICABLE LAW, NEITHER PARTY EXCLUDES OR LIMIT ITS LIABILITY.
        2. +
      2. The Parties agree that the limitations on and exclusions of liability listed in this Section 5 were freely negotiated and are an integral part of the bargain, in that the Services would not have been available for the same price and under the same terms and conditions had such limitations on and exclusions of liability not been included in this Agreement.
        3. +
      3. To the extent the foregoing warranty disclaimer or limitation of liability is not allowed by applicable law, then the liability of Thoughtworks, and Customer's remedy, shall be limited to, at Thoughtworks' option: (i) the re-supply of any defective Services; or (ii) the refund of any Support Fees paid by Customer for the period within which defective Services were performed.
        4. +
      +
      7. +
    +
    6. + +
  6. +
    Confidential Information
    + +
      +
    1. + Definitions. +
        +
      1. As used in this Agreement, "Confidential Information" means all information, and all documents and other tangible materials and things which record it, relating to, or used in either party's business, whether or not Trade Secret Information (as defined below), and whether owned by either party, any of their clients, or any third party vendor, which is not generally known to the public, or to either party's or their clients' competitors, and was disclosed to either party to this Agreement by the other party. Confidential Information includes, without limitation, the following especially sensitive types of information which are owned or used by either party, or owned by either party's clients, or third party vendors: (1) business channels, business plans, product development and marketing plans, advertising programs, and planning and merchandising strategies; (2) technical information, including formulae, pricing information, processes and methods of production; (3) Trade Secret Information (as defined hereafter), manuals, ideas, know-how, research-in-progress, work-in-progress, prototypes, and the like; (4) the identity, purchase and payment patterns of, and special relations with, customers and prospective customers; (5) the identity, net prices and credit terms of, and special relations with, suppliers and shippers; (6) computer programs, software, computer systems, computer logic, algorithms, individual computer designed features, computer or software features, methods, processes, program or system documentation, data, object codes and source codes and system or software design criteria; (7) business records and financial information; (8) information relating to hiring procedures and assessments; (9) personally identifiable information of employees; and (9) any other information or documents which either party reasonably regards as being confidential.
        2. +
      2. As used in the Agreement, "Trade Secret Information" means Confidential Information, and all documents and other tangible materials and things which record it, and which: (1) has economic value, actual or potential, from not being known by others who could obtain economic value from its disclosure or use; and (2) is the subject of reasonable efforts to maintain its secrecy.
        3. +
      3. Excluded Information. Confidential Information does not include information which: (i) is in or comes into the public domain other than as a result of a disclosure by the party hereto to whom it was disclosed pursuant to this Agreement (the "Receiving Party"), (ii) was known or within Receiving Party's possession prior to its being furnished by or on behalf of the other party hereto (the "Disclosing Party"), (iii) becomes available to the Receiving Party from a source other than the Disclosing Party or any of its representatives, provided that such source is not, to the Receiving Party's knowledge, bound by an obligation of confidentiality to the Disclosing Party or any other party with respect to such information, or (iv) was independently developed by the Receiving Party without reference to the Disclosing Party's Confidential Information.
        4. +
      4. Use and Disclosure. The parties will use Confidential Information of the other party solely for the purposes of evaluating the advisability of an engagement or in the course of the engagement itself, shall keep it confidential, and will not, except as set forth in the following paragraph, disclose any of the other party's Confidential Information in any manner whatsoever. Nothing in this Agreement is intended to grant any rights under any patent, copyright or other intellectual property rights of any party in favor of the other, nor shall this Agreement be construed to grant any party any rights in or to either party's Confidential Information, except the limited right to use such Confidential Information in connection with the proposed relationship between the parties.
        5. +
      5. Further Exceptions. Either party may disclose Confidential Information without being in violation of this Agreement under any of the following circumstances: (i) with the prior written consent of the Disclosing Party; (ii) to its employees, representatives, consultants or agents, solely for the purpose of assisting the Receiving Party with the engagement, but only if such person has been informed of the confidential nature of the Confidential Information and is obligated to maintain its confidentiality; or (iii) as required by law, legal process or the rules of any applicable stock exchange, in which event the Receiving Party shall give the Disclosing Party prompt notice thereof so that the Disclosing Party may seek a protective order and/or waive the duty of nondisclosure (except to the extent that the Receiving Party's provision of such notice would cause it to violate a court order or other legal requirement); provided that in the absence of such order or waiver, if the Receiving Party or any such representative shall, in the opinion of its counsel, stand liable for contempt or suffer other censure or penalty for failure to disclose, disclosure pursuant to the order of such tribunal may be made by the Receiving Party or its representative without liability hereunder.
        6. +
      6. Return of Information. At any time upon request of a Disclosing Party for any reason, the Receiving Party will promptly destroy or deliver to the Disclosing Party all documents (and all copies thereof) furnished to the Receiving Party by or on behalf of the Disclosing Party, and all documents created by the Receiving Party in reliance on documents and information furnished to the Receiving Party by or on behalf of the Disclosing Party. Notwithstanding the return of the Confidential Information the Receiving Party will continue to be bound by its obligations of confidentiality and non-use hereunder. Provided the Receiving Party continues to comply with this Agreement, the Receiving Party may retain any Confidential Information that: (a) is included in any back ups made in the ordinary course of its business which are not capable of ready search and deletion; (b) the Receiving Party is required by law or any Regulatory Requirement to retain, or needs to retain to defend itself in any proceeding being brought or threatened against it at the time the Confidential Information must be returned or destroyed; or (c) the Receiving Party is required to retain for its own reasonable internal credit, risk, insurance, taxation or record-keeping purposes.
        7. +
      7. Injunctive Relief. It is agreed that the unauthorized disclosure or use of any Confidential Information will cause immediate or irreparable injury to the parties, and that the parties cannot be adequately compensated for such injury in monetary damages. The parties therefore acknowledge and agree that, in such event, either party shall be entitled to any temporary or permanent injunctive relief necessary to prevent such unauthorized disclosure or use, or threat of disclosure or use.
        8. +
      +
      2. +
    +
    7. + +
  7. +
    Intellectual Property
    + +
      +
    1. Ownership of Existing Intellectual Property. Except as expressly stated in this Agreement, the ownership of the Intellectual Property Rights of each of the Parties as at the date of commencement of this Agreement shall not be affected by this Agreement.
      2. +
    2. Ownership of Services and Grant of License. Thoughtworks retains all right, title and interest in and to the Services, including but not limited to any computer software source or object code, ideas, concepts, know-how, methods, documentation, manuals, charts, diagrams, screen displays, schematics, blueprints or drawings that are used, developed or provided to Customer in the course of providing the Services to Customer under this Agreement. Customer agrees that Customer shall assign to Thoughtworks all right, title, and interest in and to the Services including but not limited to any computer software source or object code, ideas, concepts, know-how, methods, documentation, manuals, charts, diagrams, screen displays, schematics, blueprints or drawings that are created in connection with the performance of the Services.
      3. +
    3. Residual Rights. Both parties acknowledge and agree that each party shall retain ownership of, and shall have the unrestricted right to use, any general knowledge, skills, and experience, and any ideas, concepts, know-how, techniques, designs, generalized frameworks, models, and artifacts ("Residual Rights"), which such party obtains in the course of fulfilling its obligations under this Agreement.
      4. +
    +
    8. + +
  8. +
    Export
    + +

    Customer represents that it is not located in Cuba, Iran, North Korea, Sudan, or Syria and Customer shall not export or re-export any Services rendered by Thoughtworks under this Agreement to Cuba, Iran, North Korea, Sudan, or Syria. Additionally, Customer affirms that, to Customer's knowledge, Customer is not included on any list that would cause Thoughtworks' export of the Services to Customer to be prohibited by the laws or regulations of the United States, including the Department of Commerce's ("DOC") Denied Persons, Entities, and Unverified Lists; the U.S. Department of State's Debarred List; or on the U.S. Department of Treasury's lists of Specially Designated Nationals, Specially Designated Narcotics Traffickers, or Specially Designated Terrorists. Customer agrees to indemnify, to the fullest extent permitted by law, Thoughtworks from and against any fines or penalties that may arise as a result of any breach by Customer of this provision.

    +
    9. + +
  9. +
    Assignment
    + +

    Customer may not assign its rights under this Agreement except in the case of a change in control of Customer, including merger or sale. Customer must give Thoughtworks sixty (60) days prior written notice of any such assignment. Thoughtworks may assign its rights and obligations under this agreement for any reason and without the consent of Customer.

    +
    10. + +
  10. +
    Severability
    + +

    Each provision of this Agreement shall be interpreted in such a manner as to be effective and valid under applicable law. The invalidity or unenforceability of any provision of this Agreement shall in no way affect the validity or enforceability of any other provision hereof. Any invalid or unenforceable provision shall be deemed severed from this Agreement and the balance of this Agreement shall be construed and enforced as if this Agreement did not contain the particular provisions(s) held to be invalid or unenforceable and so as to effect the original intent of the parties hereto.

    +
    11. + +
  11. +
    Disputes and Governing Law
    + +
      +
    1. Any controversy or dispute between the parties shall be settled first by negotiation between a Customer Named Contact and the Thoughtworks Support Manager. In the event the representatives are unable to resolve the dispute within ninety (90) days, the parties agree to elevate the dispute to their respective Presidents or equivalent officer. If, after sixty (60) days, the parties are still unable to resolve the dispute, the Parties shall participate in mediation pursuant to the then-current JAMS International Mediation Rules. If mediation is unsuccessful, then the Parties will resolve the dispute by binding arbitration before a single, mutually agreed upon arbitrator with at least ten (10) years of experience in the field of software support services, regardless of the amount in dispute. The arbitration shall be administered by the American Arbitration Association in accordance with its Commercial Arbitration Rules, except as set forth herein. The decision and award of the arbitrator shall be final and binding and the award so rendered may be entered in any court having jurisdiction thereof. The arbitration shall be held in Chicago, Illinois. No damages excluded by or in excess of any damage limitations set forth in this Agreement, including punitive or other non-compensatory damages, shall be awarded. Nothing herein contained shall bar the right of either party to obtain equitable relief from a court of law or equity with regard to a claim under the Confidentiality Agreement.
      2. +
    2. This Agreement shall be deemed executed in the State of Delaware, U.S.A., and shall be governed by and construed in accordance with the laws of the State of Delaware, without regard to choice of law or conflict of law principles. For purposes of enforcement of arbitration awards, equitable relief, or if for any other reason litigation is permissible under this agreement, each party hereby irrevocably agrees to the exclusive personal jurisdiction and venue of any court located in the State of Delaware.
      3. +
    +
    12. + +
  12. +
    No Waiver
    + +

    No failure or delay by either party in exercising any right, power, or privilege granted under this Agreement shall operate as a waiver thereof, nor shall any single or partial exercise thereof preclude any other or further exercise thereof or the exercise of any right, power or privilege granted under this Agreement. The knowing waiver of a Breach of this Agreement or the failure of a party to exercise any right under this Agreement shall in no event constitute a waiver as to any other breach, whether similar or dissimilar in nature, or prevent the exercise of any right under this Agreement.

    +
    13. + +
  13. +
    Amendment
    + +

    This Agreement can only be modified by mutual written assent of the parties. The parties agree that the terms on either party's purchase order, invoice or other business forms are not binding on the other party and shall not be of any effect whatsoever and may not affect, alter, or modify the terms and conditions of this Agreement unless they are expressly incorporated into a formal written agreement signed by both parties.

    +
    14. + +
  14. +
    Independent Contractor
    + +

    For all purposes hereof and in the performance of its obligations under this Agreement, Thoughtworks is and shall remain an independent contractor and nothing in this Agreement shall be deemed or construed to create an employer/employee, joint venture or partnership relationship between Thoughtworks and Customer. Nothing herein shall be deemed or construed to create an employment relationship between Customer and any employee, agent or independent contractor of Thoughtworks. Neither party shall have any authority to insure any obligations on behalf of the other party or to make any promise, representation or contract of any nature on behalf of the other party.

    +
    15. +
+
+
+ +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/events.html b/pr-1714/events.html new file mode 100644 index 000000000..9e4892b67 --- /dev/null +++ b/pr-1714/events.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/events/index.html b/pr-1714/events/index.html new file mode 100644 index 000000000..9e5ceb085 --- /dev/null +++ b/pr-1714/events/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/feed.xml b/pr-1714/feed.xml new file mode 100644 index 000000000..dcdaaad77 --- /dev/null +++ b/pr-1714/feed.xml @@ -0,0 +1,122 @@ + + + GoCD + Continuous Delivery + http://localhost:4567/blog + + + 2023-02-13T00:00:00Z + + GoCD Team + + + GoCD project status in 2023 + + http://localhost:4567/2023/02/13/gocd-project-status.html + 2023-02-13T00:00:00Z + 2023-02-13T00:00:00Z + + Chad Wilson & Aravind SV + + What's happening with the GoCD project in 2023? + + + GoCD and the Log4j vulnerability - CVE-2021-44228 + + http://localhost:4567/2021/12/14/log4j-vulnerability.html + 2021-12-14T00:00:00Z + 2021-12-14T00:00:00Z + + Aravind SV + + The linked GitHub discussion has more information. + + + Restore Backup for GoCD on Kubernetes + + http://localhost:4567/2020/10/11/restore-backup-for-gocd-on-kubernetes.html + 2020-10-11T00:00:00Z + 2020-10-11T00:00:00Z + + Guest post by Abilash Rajasekaran + + Restore Backup for GoCD on Kubernetes. + + + Perform Backup for GoCD on Kubernetes + + http://localhost:4567/2020/10/11/perform-backup-for-gocd-on-kubernetes.html + 2020-10-11T00:00:00Z + 2020-10-11T00:00:00Z + + Guest post by Abilash Rajasekaran + + Perform Backup for GoCD on Kubernetes. + + + GoCD on Kubernetes using Terraform + + http://localhost:4567/2020/04/14/gocd-on-kubernetes-using-terraform.html + 2020-04-14T00:00:00Z + 2020-04-14T00:00:00Z + + Guest post by Abilash Rajasekaran + + Use Terraform scripts to setup GoCD on Google Kubernetes Engine in minutes. + + + Configuring GoCD Agents in Kubernetes + + http://localhost:4567/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html + 2019-09-17T00:00:00Z + 2019-09-17T00:00:00Z + + Mohamed Najiullah + + If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry. + + + Configuring Google Container Registry (GCR) as an Artifact Store in GoCD + + http://localhost:4567/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html + 2019-08-05T00:00:00Z + 2019-08-05T00:00:00Z + + Mohamed Najiullah + + If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry. + + + Running Dockerized GoCD Containers as Non Root + + http://localhost:4567/2019/06/25/GoCD-non-root-containers.html + 2019-06-25T00:00:00Z + 2019-06-25T00:00:00Z + + GoCD Team + + To provide addition security against container(s) achieving escalated permissions on the host node, GoCD supports running container(s) using a Non root user. + + + Effect of Java licensing changes on GoCD + + http://localhost:4567/2019/05/21/official-stance-on-java.html + 2019-05-21T00:00:00Z + 2019-05-21T00:00:00Z + + GoCD Team + + Due to Java licensing changes by Oracle, GoCD's support for Java is changing. + + + Installing and Configuring GoCD on GKE using Helm + + http://localhost:4567/2019/05/14/installing-configuring-gocd-gke-using-helm.html + 2019-05-14T00:00:00Z + 2019-05-14T00:00:00Z + + Mohamed Najiullah + + Understand the steps needed to install and configure GoCD on GKE using Helm while looking at the possibility of migrating your CI/CD infrastructure to Kubernetes + + diff --git a/pr-1714/feed/rss.xml b/pr-1714/feed/rss.xml new file mode 100644 index 000000000..36e72dcd5 --- /dev/null +++ b/pr-1714/feed/rss.xml @@ -0,0 +1,122 @@ + + + GoCD + Continuous Delivery + http://localhost:4567/blog + + + 2023-02-13T00:00:00Z + + GoCD Team + + + GoCD project status in 2023 + + http://localhost:4567/2023/02/13/gocd-project-status.html + 2023-02-13T00:00:00Z + 2023-02-13T00:00:00Z + + Chad Wilson & Aravind SV + + What's happening with the GoCD project in 2023? + + + GoCD and the Log4j vulnerability - CVE-2021-44228 + + http://localhost:4567/2021/12/14/log4j-vulnerability.html + 2021-12-14T00:00:00Z + 2021-12-14T00:00:00Z + + Aravind SV + + The linked GitHub discussion has more information. + + + Restore Backup for GoCD on Kubernetes + + http://localhost:4567/2020/10/11/restore-backup-for-gocd-on-kubernetes.html + 2020-10-11T00:00:00Z + 2020-10-11T00:00:00Z + + Guest post by Abilash Rajasekaran + + Restore Backup for GoCD on Kubernetes. + + + Perform Backup for GoCD on Kubernetes + + http://localhost:4567/2020/10/11/perform-backup-for-gocd-on-kubernetes.html + 2020-10-11T00:00:00Z + 2020-10-11T00:00:00Z + + Guest post by Abilash Rajasekaran + + Perform Backup for GoCD on Kubernetes. + + + GoCD on Kubernetes using Terraform + + http://localhost:4567/2020/04/14/gocd-on-kubernetes-using-terraform.html + 2020-04-14T00:00:00Z + 2020-04-14T00:00:00Z + + Guest post by Abilash Rajasekaran + + Use Terraform scripts to setup GoCD on Google Kubernetes Engine in minutes. + + + Configuring GoCD Agents in Kubernetes + + http://localhost:4567/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html + 2019-09-17T00:00:00Z + 2019-09-17T00:00:00Z + + Mohamed Najiullah + + If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry. + + + Configuring Google Container Registry (GCR) as an Artifact Store in GoCD + + http://localhost:4567/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html + 2019-08-05T00:00:00Z + 2019-08-05T00:00:00Z + + Mohamed Najiullah + + If your pipelines involve creating a docker image and pushing it to a registry/repository, you can use the above steps to create an Artifact Store with that registry. + + + Running Dockerized GoCD Containers as Non Root + + http://localhost:4567/2019/06/25/GoCD-non-root-containers.html + 2019-06-25T00:00:00Z + 2019-06-25T00:00:00Z + + GoCD Team + + To provide addition security against container(s) achieving escalated permissions on the host node, GoCD supports running container(s) using a Non root user. + + + Effect of Java licensing changes on GoCD + + http://localhost:4567/2019/05/21/official-stance-on-java.html + 2019-05-21T00:00:00Z + 2019-05-21T00:00:00Z + + GoCD Team + + Due to Java licensing changes by Oracle, GoCD's support for Java is changing. + + + Installing and Configuring GoCD on GKE using Helm + + http://localhost:4567/2019/05/14/installing-configuring-gocd-gke-using-helm.html + 2019-05-14T00:00:00Z + 2019-05-14T00:00:00Z + + Mohamed Najiullah + + Understand the steps needed to install and configure GoCD on GKE using Helm while looking at the possibility of migrating your CI/CD infrastructure to Kubernetes + + diff --git a/pr-1714/getting-started.html b/pr-1714/getting-started.html new file mode 100644 index 000000000..0c54ce1a6 --- /dev/null +++ b/pr-1714/getting-started.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the getting-started/part-1/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/getting-started/index.html b/pr-1714/getting-started/index.html new file mode 100644 index 000000000..460a29d09 --- /dev/null +++ b/pr-1714/getting-started/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the part-1/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/getting-started/part-1.html b/pr-1714/getting-started/part-1.html new file mode 100644 index 000000000..9bd90205e --- /dev/null +++ b/pr-1714/getting-started/part-1.html @@ -0,0 +1,472 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part One | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

If you do not have GoCD installed, please download and follow the installation checklist.

+ Download GoCD + +

Part 1

+
+

Concept 1: Server and agents

+
+ GoCD Server mapped to three agents +
+

+ In the GoCD ecosystem, the server is the one that controls everything. It provides the user interface to users + of the system and provides work for the agents to do. The agents are the ones that do any work (run commands, + do deployments, etc) that is configured by the users or administrators of the system. +

+

+ The server does not do any user-specified "work" on its own. It will not run any commands or do + deployments. That is the reason you need a GoCD Server and at least one GoCD Agent installed before you + proceed. +

+
+ +

+ Once you have them installed and running, you should see a screen similar to this, if you navigate to the home + page in a web browser (defaults to: http://localhost:8153): +

+
+ GoCD new pipeline page +
GoCD's new pipeline page
+
+ +

+ If you have installed the GoCD Agent properly and click on the "Agents" link in the header, you should see an + idle GoCD agent waiting (as shown below). If you do not, head over to the + troubleshooting page to + figure out why. +

+
+ GoCD Agent page +
Agents page
+
+ +

+ Congratulations! You're on your way to using GoCD. If you now click "Pipelines", you'll get back to the "Add + pipeline" screen you saw earlier. +

+ +

Creating a pipeline

+

Before creating a pipeline, it might help to know what it is and concepts around it.

+ +
+

Concept 2: Pipelines and materials

+
+ Multiple materials mapped to a Pipeline with multiple stages within it +
+

+ A pipeline, in GoCD, is a representation of workflow or a part of a workflow. For instance, if you are trying + to automatically run tests, build an installer and then deploy an application to a test environment, then + those steps can be modeled as a pipeline. GoCD provides different modeling constructs within a pipeline, such + as stages, jobs and tasks. We will see these in more detail soon. For the purpose of this part of the guide, + you need to know that a pipeline can be configured to run a command or set of commands. +

+

+ Another equally important concept is that of a material. A material is a cause for a pipeline to "trigger" or + to start doing what it is configured to do. Typically, a material is a source control repository (like Git, + Subversion, etc) and any new commit to the repository is a cause for the pipeline to trigger. A pipeline needs + to have at least one material and can have as many materials of different kinds as you want. +

+

+ The concept of a pipeline is extremely central to Continuous Delivery. Together with the concepts of stages, + jobs and tasks, GoCD provides important modeling blocks which allow you to build up very complex workflows, + and get feedback quicker. You'll learn more about GoCD pipelines and Deployment pipelines in the upcoming + parts of this guide. In case you cannot wait, Martin Fowler has a nice and succinct + article here. +

+
+ +

+ Now, back at the "Add pipeline" screen, let's provide the pipeline a name, without spaces, and ignore the "Pipeline Group" field for now. +

+
+ Step 1 - Screen to name your pipeline +
Step 1: Name our pipeline
+
+ +

+ Pressing "Next" will take you to step 2, which can be used to configure a material. +

+
+ Step 2 A - Screen to choose a material +
Step 2a: Point it to a material - Where to look for changes?
+
+ +

+ You can choose your own material here [1], or use a Git repository + available on GitHub for this guide. The URL of that repository + is: https://github.com/gocd-contrib/getting-started-repo.git. You + can change "Material Type" to "Git" and provide the URL in the "URL" textbox. If you now click on the "Check + Connection" button, it should tell you everything is OK. +

+
+ Step 2 B - Checking that the material exists +
Step 2b: Check that the material exists
+
+ +

+ This step assumes that you have git installed on the GoCD Server and Agent. Like git, any other commands you + need for running your scripts need to be installed on the GoCD Agent nodes. +

+

+ If you had trouble with this step, and it failed, take a look at the + troubleshooting page in the + documentation. If everything went well, press "Next" to be taken to step 3, which deals with stages, jobs and + tasks. +

+
+ Step 3 A - Use the predefined stage and job +
Step 3a: Use the predefined stage and job for now
+
+ +

+ Since a stage name and a job name are populated, and in the interest of quickly achieving our goal of creating + and running a pipeline in GoCD, let us delay understanding the (admittedly very important) concepts of stage and + job and focus on a task instead. Scrolling down a bit, you'll see the "Initial Job and Task" + section. +

+
+ Step 3 B - Take a closer look at the initial job and task +
Step 3b: Take a closer look at the initial job and task
+
+ +

+ Since we don't want to use "Ant" right now, let's change the "Task Type" to "More...". You should see a screen + like this: +

+
+ Step 3 C - Choose a custom command +
Step 3c: Choose a custom command
+
+ +

+ Change the text of the "Command" text box to "./build" (that is, dot forward-slash build) and press + "Finish". If all went well, you just created your first pipeline! Leaving you in a screen similar to the one + shown below. +

+
+ Your first pipeline (paused) +
Your first pipeline (paused)
+
+ +

+ Helpfully, the pipeline has been paused for you (see the pause button and the text next to it, right next to + the pipeline name). This allows you to make more changes to the pipeline before it triggers. Usually, pipeline + administrators can take this opportunity to add more stages, jobs, etc. and model their pipelines better. For + the purpose of this guide, let's just un-pause this pipeline and get it to run. Click on the blue "pause" + button and then click on the "Pipelines" link in the header. +

+

+ If you give it a minute, you'll see your pipeline building (yellow) and then finish successfully (green): +

+
+ The pipeline is building +
The pipeline is building
+
+ +
+ The pipeline finished successfully +
The pipeline finished successfully
+
+ +

Clicking on the bright green bar will show you information about the stage:

+
+ Information about the stage +
Information about the stage
+
+ +

and then clicking on the job will take you to the actual task and show you what it did:

+
+ The output of the job run +
The output of the job run
+
+ +

+ Scrolling up a bit, you can see it print out the environment variables for the task and the details of the agent + this task ran on (remember "Concept 1"?). +

+
+ The environment variables used for the job +
The environment variables used for the job
+
+ +
+ Job run details +
Job run details
+
+ +
+

Concept 3: Agent prepares to do some work

+

+ Did you notice the lines at the top of the build which said: "Start updating files at revision ..."? This is the agent + preparing to run the job configured. Every material configured for that pipeline will be updated to the correct + revision, so that it is consistent with the rest of the pipeline and the system as a whole. +

+

+ Once the material is checked out (if it is the first time it is ever used) and updated to the correct revision, it will + be available for use in a task. That is the reason the build script, "./build" was available without you having to do + anything. It is found inside the configured Git + repository material. +

+

+ In this case, we had only one material, and so we could use it as "./build". If you had configured more materials, you'd + need to provide a working directory for each material and would have had to use the script as "./material1/build" (for + instance). +

+

+ Notice that the GoCD Agent independently checks out the repository, meaning that the version control systems of your + materials (Git, SVN, etc) need to be available on the GoCD Agent as well. +

+
+ +

+ Now that you have a basic idea of a pipeline and what it does, let's understand more about its components. +

+ +
+

Concept 4: Stages, jobs and tasks

+
+ GoCD Pipeline with multiple stages within running multiple jobs each +
+ +

+ A pipeline consists of one or more "stages", each stage consists of one or more "jobs" and each job is made up of one or + more "tasks". All of these are modeling constructs within a pipeline. Starting from the smallest piece: +

+
+
Task
+
+ A task is typically a command which is configured to run as a part of the job it is in. Not every task needs + to be a simple command, since tasks can be plugins. In this guide, the "./build" that was configured to run + was a task. GoCD has Ant, NAnt and Rake tasks as built-in tasks, but has many more optional plugins which can + be installed. The most versatile built-in task is the one that was used in this guide, which is the "Custom + Command". Whenever anyone asks the question, "Can GoCD run <application-x>?, the answer is always "Yes", + because it can always be executed as a custom command. +
+
+
+
Job
+
+ A job is a sequential collection of tasks. Each task in a job is run one after the other, and in its default + configuration, if a task fails, none of the tasks following that one get executed. The job is then considered to have + "failed". The most important aspect of a job is that a single agent has to pick up and finish a job. So, you can be + guaranteed that all tasks in a job run on the same agent. +
+
+
+
Stage
+
+ A stage is a collection of jobs, but the jobs are not sequential. They can be picked up in any order and so, they + have to be independent of each other. This crucial distinction between how a job is composed of its tasks (sequential) + and how a stage is composed of its jobs (non-sequential) is what provides built-in parallelizability in GoCD. Since jobs + in a stage are independent of each other, they will all be started together, when a stage starts. Assuming that you have + enough agents started and not busy, then every job in a stage can run on a different agent at the same time, potentially + speeding up your build by a lot. +
+
+

+ Circling back to the pipeline we created in this guide: The pipeline had one stage called "defaultStage" and one job in + that stage called "defaultJob" and had only one task in that - a custom command task, which ran: "./build". +

+
+ +

+ This is just the tip of the iceberg in terms of GoCD's features and capabilities. In the upcoming parts of this guide, + you will learn more about some more of GoCD's core features, such as fan-in, fan-out, artifact promotion, pipeline + dependencies, value stream maps and more. +

+

+ Let's start, in Part 2 of this guide, where you can learn about pipeline dependencies and artifacts. +

+ +

Notes:

+
+

+ [1] + If you're used to using Git or any version control system used by GoCD, you can clone your repository locally and + provide that path instead of using the repository on GitHub used in this guide. That way, you can make commits to + your repository and see pipelines triggering because of them. +

+
+ +
+ Next +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/getting-started/part-1/index.html b/pr-1714/getting-started/part-1/index.html new file mode 100644 index 000000000..90a982709 --- /dev/null +++ b/pr-1714/getting-started/part-1/index.html @@ -0,0 +1,472 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part One | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

If you do not have GoCD installed, please download and follow the installation checklist.

+ Download GoCD + +

Part 1

+
+

Concept 1: Server and agents

+
+ GoCD Server mapped to three agents +
+

+ In the GoCD ecosystem, the server is the one that controls everything. It provides the user interface to users + of the system and provides work for the agents to do. The agents are the ones that do any work (run commands, + do deployments, etc) that is configured by the users or administrators of the system. +

+

+ The server does not do any user-specified "work" on its own. It will not run any commands or do + deployments. That is the reason you need a GoCD Server and at least one GoCD Agent installed before you + proceed. +

+
+ +

+ Once you have them installed and running, you should see a screen similar to this, if you navigate to the home + page in a web browser (defaults to: http://localhost:8153): +

+
+ GoCD new pipeline page +
GoCD's new pipeline page
+
+ +

+ If you have installed the GoCD Agent properly and click on the "Agents" link in the header, you should see an + idle GoCD agent waiting (as shown below). If you do not, head over to the + troubleshooting page to + figure out why. +

+
+ GoCD Agent page +
Agents page
+
+ +

+ Congratulations! You're on your way to using GoCD. If you now click "Pipelines", you'll get back to the "Add + pipeline" screen you saw earlier. +

+ +

Creating a pipeline

+

Before creating a pipeline, it might help to know what it is and concepts around it.

+ +
+

Concept 2: Pipelines and materials

+
+ Multiple materials mapped to a Pipeline with multiple stages within it +
+

+ A pipeline, in GoCD, is a representation of workflow or a part of a workflow. For instance, if you are trying + to automatically run tests, build an installer and then deploy an application to a test environment, then + those steps can be modeled as a pipeline. GoCD provides different modeling constructs within a pipeline, such + as stages, jobs and tasks. We will see these in more detail soon. For the purpose of this part of the guide, + you need to know that a pipeline can be configured to run a command or set of commands. +

+

+ Another equally important concept is that of a material. A material is a cause for a pipeline to "trigger" or + to start doing what it is configured to do. Typically, a material is a source control repository (like Git, + Subversion, etc) and any new commit to the repository is a cause for the pipeline to trigger. A pipeline needs + to have at least one material and can have as many materials of different kinds as you want. +

+

+ The concept of a pipeline is extremely central to Continuous Delivery. Together with the concepts of stages, + jobs and tasks, GoCD provides important modeling blocks which allow you to build up very complex workflows, + and get feedback quicker. You'll learn more about GoCD pipelines and Deployment pipelines in the upcoming + parts of this guide. In case you cannot wait, Martin Fowler has a nice and succinct + article here. +

+
+ +

+ Now, back at the "Add pipeline" screen, let's provide the pipeline a name, without spaces, and ignore the "Pipeline Group" field for now. +

+
+ Step 1 - Screen to name your pipeline +
Step 1: Name our pipeline
+
+ +

+ Pressing "Next" will take you to step 2, which can be used to configure a material. +

+
+ Step 2 A - Screen to choose a material +
Step 2a: Point it to a material - Where to look for changes?
+
+ +

+ You can choose your own material here [1], or use a Git repository + available on GitHub for this guide. The URL of that repository + is: https://github.com/gocd-contrib/getting-started-repo.git. You + can change "Material Type" to "Git" and provide the URL in the "URL" textbox. If you now click on the "Check + Connection" button, it should tell you everything is OK. +

+
+ Step 2 B - Checking that the material exists +
Step 2b: Check that the material exists
+
+ +

+ This step assumes that you have git installed on the GoCD Server and Agent. Like git, any other commands you + need for running your scripts need to be installed on the GoCD Agent nodes. +

+

+ If you had trouble with this step, and it failed, take a look at the + troubleshooting page in the + documentation. If everything went well, press "Next" to be taken to step 3, which deals with stages, jobs and + tasks. +

+
+ Step 3 A - Use the predefined stage and job +
Step 3a: Use the predefined stage and job for now
+
+ +

+ Since a stage name and a job name are populated, and in the interest of quickly achieving our goal of creating + and running a pipeline in GoCD, let us delay understanding the (admittedly very important) concepts of stage and + job and focus on a task instead. Scrolling down a bit, you'll see the "Initial Job and Task" + section. +

+
+ Step 3 B - Take a closer look at the initial job and task +
Step 3b: Take a closer look at the initial job and task
+
+ +

+ Since we don't want to use "Ant" right now, let's change the "Task Type" to "More...". You should see a screen + like this: +

+
+ Step 3 C - Choose a custom command +
Step 3c: Choose a custom command
+
+ +

+ Change the text of the "Command" text box to "./build" (that is, dot forward-slash build) and press + "Finish". If all went well, you just created your first pipeline! Leaving you in a screen similar to the one + shown below. +

+
+ Your first pipeline (paused) +
Your first pipeline (paused)
+
+ +

+ Helpfully, the pipeline has been paused for you (see the pause button and the text next to it, right next to + the pipeline name). This allows you to make more changes to the pipeline before it triggers. Usually, pipeline + administrators can take this opportunity to add more stages, jobs, etc. and model their pipelines better. For + the purpose of this guide, let's just un-pause this pipeline and get it to run. Click on the blue "pause" + button and then click on the "Pipelines" link in the header. +

+

+ If you give it a minute, you'll see your pipeline building (yellow) and then finish successfully (green): +

+
+ The pipeline is building +
The pipeline is building
+
+ +
+ The pipeline finished successfully +
The pipeline finished successfully
+
+ +

Clicking on the bright green bar will show you information about the stage:

+
+ Information about the stage +
Information about the stage
+
+ +

and then clicking on the job will take you to the actual task and show you what it did:

+
+ The output of the job run +
The output of the job run
+
+ +

+ Scrolling up a bit, you can see it print out the environment variables for the task and the details of the agent + this task ran on (remember "Concept 1"?). +

+
+ The environment variables used for the job +
The environment variables used for the job
+
+ +
+ Job run details +
Job run details
+
+ +
+

Concept 3: Agent prepares to do some work

+

+ Did you notice the lines at the top of the build which said: "Start updating files at revision ..."? This is the agent + preparing to run the job configured. Every material configured for that pipeline will be updated to the correct + revision, so that it is consistent with the rest of the pipeline and the system as a whole. +

+

+ Once the material is checked out (if it is the first time it is ever used) and updated to the correct revision, it will + be available for use in a task. That is the reason the build script, "./build" was available without you having to do + anything. It is found inside the configured Git + repository material. +

+

+ In this case, we had only one material, and so we could use it as "./build". If you had configured more materials, you'd + need to provide a working directory for each material and would have had to use the script as "./material1/build" (for + instance). +

+

+ Notice that the GoCD Agent independently checks out the repository, meaning that the version control systems of your + materials (Git, SVN, etc) need to be available on the GoCD Agent as well. +

+
+ +

+ Now that you have a basic idea of a pipeline and what it does, let's understand more about its components. +

+ +
+

Concept 4: Stages, jobs and tasks

+
+ GoCD Pipeline with multiple stages within running multiple jobs each +
+ +

+ A pipeline consists of one or more "stages", each stage consists of one or more "jobs" and each job is made up of one or + more "tasks". All of these are modeling constructs within a pipeline. Starting from the smallest piece: +

+
+
Task
+
+ A task is typically a command which is configured to run as a part of the job it is in. Not every task needs + to be a simple command, since tasks can be plugins. In this guide, the "./build" that was configured to run + was a task. GoCD has Ant, NAnt and Rake tasks as built-in tasks, but has many more optional plugins which can + be installed. The most versatile built-in task is the one that was used in this guide, which is the "Custom + Command". Whenever anyone asks the question, "Can GoCD run <application-x>?, the answer is always "Yes", + because it can always be executed as a custom command. +
+
+
+
Job
+
+ A job is a sequential collection of tasks. Each task in a job is run one after the other, and in its default + configuration, if a task fails, none of the tasks following that one get executed. The job is then considered to have + "failed". The most important aspect of a job is that a single agent has to pick up and finish a job. So, you can be + guaranteed that all tasks in a job run on the same agent. +
+
+
+
Stage
+
+ A stage is a collection of jobs, but the jobs are not sequential. They can be picked up in any order and so, they + have to be independent of each other. This crucial distinction between how a job is composed of its tasks (sequential) + and how a stage is composed of its jobs (non-sequential) is what provides built-in parallelizability in GoCD. Since jobs + in a stage are independent of each other, they will all be started together, when a stage starts. Assuming that you have + enough agents started and not busy, then every job in a stage can run on a different agent at the same time, potentially + speeding up your build by a lot. +
+
+

+ Circling back to the pipeline we created in this guide: The pipeline had one stage called "defaultStage" and one job in + that stage called "defaultJob" and had only one task in that - a custom command task, which ran: "./build". +

+
+ +

+ This is just the tip of the iceberg in terms of GoCD's features and capabilities. In the upcoming parts of this guide, + you will learn more about some more of GoCD's core features, such as fan-in, fan-out, artifact promotion, pipeline + dependencies, value stream maps and more. +

+

+ Let's start, in Part 2 of this guide, where you can learn about pipeline dependencies and artifacts. +

+ +

Notes:

+
+

+ [1] + If you're used to using Git or any version control system used by GoCD, you can clone your repository locally and + provide that path instead of using the repository on GitHub used in this guide. That way, you can make commits to + your repository and see pipelines triggering because of them. +

+
+ +
+ Next +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/getting-started/part-2.html b/pr-1714/getting-started/part-2.html new file mode 100644 index 000000000..29d3319a5 --- /dev/null +++ b/pr-1714/getting-started/part-2.html @@ -0,0 +1,510 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part Two | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

+ In Part 1 of this guide, the concepts of GoCD Server, GoCD Agents, + pipelines, materials, stages, jobs and tasks were introduced. You were also able to get a simple pipeline with + a single stage, job and task each working. +

+ +

+ Let us continue, in this part, by learning about pipelines as materials, about artifacts and about custom + tabs. +

+ +

Using a pipeline as a material

+

+ Instead of using a source code repository on GitHub as a material, it is possible to use a stage of any + pipeline as a material for another pipeline. This seemingly simple feature provides a lot of power. This + allows pipelines to be chained together, allowing very complex workflows to be modeled well and is a basis for + the more advanced features in GoCD, such as Value Stream Map (VSM) and fan-in/fan-out. +

+ +
+

Concept 5: Pipeline Dependency Material

+ +
+ GoCD Pipeline Dependency Material +
+ +

+ A pipeline dependency material links pipelines together. The pipeline which has the material which points to another + pipeline is called the "Downstream Pipeline". The actual pipeline which is the dependency material is called the + "Upstream Pipeline". Even though it is called a "Pipeline Dependency" the real dependency is to a stage in an + upstream pipeline. +

+ +

+ As soon as that stage completes successfully, the first stage of each of the configured downstream pipelines triggers. + If the stage does not complete successfully, its configured downstream pipelines do not trigger. +

+ +

+ In the image above, as soon as "Stage 2" of "UpstreamPipeline" completes successfully, "DownstreamPipeline1" + starts. Concurrently, "Stage 3" of "UpstreamPipeline" also starts. +

+
+ +

+ Let's see how we can get a pipeline dependency to work. Clicking on "Admin" and then "Pipelines" takes you to + the "Pipeline Configuration" page which lists all the pipelines in the system. It looks like this: +

+ +
+ Pipeline Configuration page +
Pipeline Configuration page
+
+ +
    +
  1. Create another pipeline, using the "Create a new pipeline within this group" link.
    2. +
  2. Name this new pipeline "MySecondPipeline" and click "Next" to reach step 2, to choose a material.
    3. +
  3. Choose "Pipeline" as the Material Type, and you'll be in a screen like the one below.
    4. +
+ +
+ Start adding a pipeline dependency material +
Start adding a pipeline dependency material
+
+ +

+ As soon as you start typing the name of your first pipeline in the "Pipeline [Stage]" textbox, it will + autocomplete and give you the name of the first pipeline and the only stage that is in it. Selecting that will + link these two pipelines together. +

+
+ Autocompletion of the pipeline dependency material +
Autocompletion of the pipeline dependency material
+
+ +

Click "Next" and choose some task in the "Initial Job and Task" section and click "Finish".

+
+ Create the downstream pipeline +
Create the downstream pipeline
+
+ +

+ That's it! You'll now have a pipeline which will run when un-pause. Un-pause it and let it finish. This is how + it will look on the Pipelines list (dashboard) when finished. +

+
+ Dependent pipelines on the dashboard +
Dependent pipelines on the dashboard
+
+ +

+ That doesn't look very different. But, this allows for some powerful features such as fan-in, fan-out and the + ValueStream Map (VSM), which we will learn about in Part 3. Click + on the label of the "MyFirstPipeline" (the part highlightedin the image above) for a sneak peek at a small + Value Stream Map. +

+ +
+ Dependent pipelines in a Value Stream Map +
Dependent pipelines in a Value Stream Map
+
+ +

You now know how to chain pipelines together. Let's now learn about artifacts, which are very useful when used with pipeline dependencies.

+ +

Publishing, fetching and using artifacts

+ +

A very important aspect of GoCD is the way it handles artifacts.

+ +
+

Concept 6: Artifact

+ +

+ An artifact in GoCD is a file or directory which is most often produced during the run of a pipeline. Every job in a + pipeline can be configured to publish its own set of artifacts and GoCD will ensure that these artifacts are moved from + the Agent where it is created, to the Server and stored there, so that it can be retrieved at any time. +

+ +

+ Typically, artifacts are created during a job run, by one of the tasks. Some examples of artifacts are: Test reports, + coverage reports, installers, documentation, meta information about the build process itself and anything else that + needs to be stored after a pipeline has finished. +

+ +

+ These artifacts, published by a job, can be fetched and used by any downstream pipeline or any + stage after the one that produced the artifact in the same pipeline, using a special task called a "Fetch Artifact" + task. If you recall from "Concept 4" in part 1, jobs are independent of each other. So, a job in the same stage as + another job that produced an artifact cannot use that artifact. It needs to be used in a stage after that one. +

+
+ +

+ Let's see how to publish an artifact. In the upstream pipeline, "MyFirstPipeline", let's first declare an + artifact. The build script used throughout this guide creates a file called "my-artifact.html" after it + finishes. We can use that as the artifact for this example. +

+ +
    +
  1. Go to "Admin" -> "Pipelines" and the select the stage, "defaultStage" and then the job, "defaultJob".
    2. +
  2. Click on the "Artifacts" tab in the job.
    3. +
  3. Enter "my-artifact.html" as the artifact source.
    4. +
  4. Leave the "Destination" box empty for now.
    5. +
+ +
+ Adding an artifact +
Adding an artifact
+
+ +

+ Since we have chosen to leave the "Destination" empty, and that means that the artifact will be accessible at the root, + by its own name. We have also chosen the type as "Build Artifact", to signify that it is not a "Test Artifact". Marking + it as a "Test Artifact" means that GoCD will try and parse the file as a test report and if it can, it will use it in + the test aggregation reporting it does. Typically, you'll want to use "Build Artifact" for installers, binaries, + documentation, etc. +

+ +

+ After saving this change, retrigger "MyFirstPipeline" by going to the pipeline dashboard and clicking on the play button + against it. Once it is finished, going to the "Artifacts" tab of the pipeline run shows you the artifact for that + run. Every run of that pipeline, from now on, will have that artifact. +

+ +
+ The artifacts tab - Every job will have one +
The artifacts tab - Every job will have one
+
+ +

Clicking on it will show you its contents:

+ +
+ The contents of the artifact - It is stored on the Go C D Server +
The contents of the artifact - It is stored on the GoCD Server
+
+ +

Fetching and using artifacts

+ +

+ We can now use this artifact in any downstream pipeline, or any subsequent stage of the same pipeline. Let's fetch this + artifact in the pipeline "MySecondPipeline" and display it as a part of the output. To do this, we go to the task + configuration section of the "defaultJob" job inside the "defaultStage" stage of "MySecondPipeline" pipeline, and add a + "Fetch Artifact" task. +

+ +
+ Adding a Fetch Artifact task +
Adding a "Fetch Artifact" task
+
+ +
+ The details can be autocompleted +
The details can be autocompleted
+
+ +

+ Once you provide all the details and click save, you can move the "Fetch Artifact" task above, so that it is + done first. Then, for this demonstration, let us display the fetched file in a "Custom Command" task. +

+
+ Move the fetch artifact task to the top +
Move the fetch artifact task to the top
+
+ +

+ After it is moved up, you can edit the "Custom Command" task to output the contents of the file (for instance). If you + are running this on Windows, use "type" instead of "cat": +

+ +
+ Display the contents of the fetched artifact +
Display the contents of the fetched artifact
+
+ +
+ This is how the tasks should look like +
This is how the tasks should look like
+
+ +

+ Running "MySecondPipeline" now will show you the contents of the file created in "MyFirstPipeline" and fetched + as an artifact. The importance of fetching an artifact this way is that GoCD will ensure that the correct + version of the artifact will be fetched and provided to the job in "MySecondPipeline". +

+ +

+ If more instances of "MyFirstPipeline" ran (because it is fast) while "MySecondPipeline" has run fewer times, + GoCD will ensure that every time "MySecondPipeline" runs, the correct (and compatible) version of the artifact + is fetched and used. When you now check the output of the pipeline, you should see something like this: +

+ +
+ The output - The artifact is fetched and displayed +
The output - The artifact is fetched and displayed
+
+ +
+

Concept 7: Ancestor artifacts and building artifacts only once

+ +

+ In GoCD, you can even fetch artifacts from pipelines which are not immediately downstream of the pipeline which produces + an artifact. It can be fetched from any pipeline which is downstream, however many levels that is. So, with a Value + Stream Map like this: +

+ +
+ Value Stream Map +
+ +

+ The pipeline "MyFifthPipeline" can be configured to fetch an artifact from "MyFirstPipeline" like this: +

+ +
+ Fetching artifacts from ancestor pipelines +
Fetching artifacts from ancestor pipelines
+
+ +

+ GoCD will complete the name of the pipeline and the path through the upstream pipelines for you and you can then use an + artifact from an ancestor pipeline in a downstream pipeline. +

+ +

+ The ability to do this is important because of how artifacts are expected to be used in a Continuous Delivery + pipeline. A core concept of CD is "Only Build Your Binaries Once". This prevents problems such as inconsistencies + between a binary which went through various levels of testing and a new "duplicate binary" which is released after being + built on a box which has a slightly different environment. So, the ability to move an artifact between pipelines and + more importantly, knowing that it is the same binary being used (GoCD ensures that) is important. +

+ +

+ We can then take the same binary across different kinds of tests, getting more confident about it as it progresses + through the pipelines, eventually reaching a production-deployment pipeline, knowing that the binary that is getting + deployed is the same as the one that went through tests. +

+
+ +

Custom tabs

+ +

+ The final part of this guide introduces the concept of a custom tab. A question that gets asked all the time + is: "Does GoCD integrate with <application-x> and show its output?". The answer is usually: "Yes, as + long as that application can generate a report or output that needs to be shown". Here is the concept: +

+ +
+

Concept 8: Custom tab

+ +

+ A custom tab in GoCD is a way of showing an artifact as a user-defined tab at the job level. Any file which + is published as an artifact by a job can be shown. Usually, these are HTML files, with images. The GoCD + Server will serve these files from its internal artifact repository. +

+
+ +

+ Let's use the example artifact we had used earlier as a custom tab. To do that, let's go to the configuration + of "MyFirstPipeline" and then to the "Custom Tab" section of the "defaultJob" and create one. It should look + like this: +

+
+ Configuring a custom tab +
Configuring a custom tab
+
+ +

+ That's it! If you now go to the pipeline, and navigate to the job "defaultJob", you'll see a custom tab called + "SomeCustomName". Clicking on it will show you the artifact for that run of the pipeline. +

+ +
+ A custom tab in action +
A custom tab in action
+
+ +

+ This can be used to integrate with coverage tools, unit test reports and anything else which creates an + artifact. +

+ +

+ In this part of the guide, you learnt about pipeline dependencies, artifacts and custom tabs. In + Part 3 of this guide, we dive deeper into the Value Stream Map and into + the powerful fan-in and fan-out concepts. +

+ +
+ Previous + Next +
+ +
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/getting-started/part-2/index.html b/pr-1714/getting-started/part-2/index.html new file mode 100644 index 000000000..10ae9d899 --- /dev/null +++ b/pr-1714/getting-started/part-2/index.html @@ -0,0 +1,510 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part Two | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

+ In Part 1 of this guide, the concepts of GoCD Server, GoCD Agents, + pipelines, materials, stages, jobs and tasks were introduced. You were also able to get a simple pipeline with + a single stage, job and task each working. +

+ +

+ Let us continue, in this part, by learning about pipelines as materials, about artifacts and about custom + tabs. +

+ +

Using a pipeline as a material

+

+ Instead of using a source code repository on GitHub as a material, it is possible to use a stage of any + pipeline as a material for another pipeline. This seemingly simple feature provides a lot of power. This + allows pipelines to be chained together, allowing very complex workflows to be modeled well and is a basis for + the more advanced features in GoCD, such as Value Stream Map (VSM) and fan-in/fan-out. +

+ +
+

Concept 5: Pipeline Dependency Material

+ +
+ GoCD Pipeline Dependency Material +
+ +

+ A pipeline dependency material links pipelines together. The pipeline which has the material which points to another + pipeline is called the "Downstream Pipeline". The actual pipeline which is the dependency material is called the + "Upstream Pipeline". Even though it is called a "Pipeline Dependency" the real dependency is to a stage in an + upstream pipeline. +

+ +

+ As soon as that stage completes successfully, the first stage of each of the configured downstream pipelines triggers. + If the stage does not complete successfully, its configured downstream pipelines do not trigger. +

+ +

+ In the image above, as soon as "Stage 2" of "UpstreamPipeline" completes successfully, "DownstreamPipeline1" + starts. Concurrently, "Stage 3" of "UpstreamPipeline" also starts. +

+
+ +

+ Let's see how we can get a pipeline dependency to work. Clicking on "Admin" and then "Pipelines" takes you to + the "Pipeline Configuration" page which lists all the pipelines in the system. It looks like this: +

+ +
+ Pipeline Configuration page +
Pipeline Configuration page
+
+ +
    +
  1. Create another pipeline, using the "Create a new pipeline within this group" link.
    2. +
  2. Name this new pipeline "MySecondPipeline" and click "Next" to reach step 2, to choose a material.
    3. +
  3. Choose "Pipeline" as the Material Type, and you'll be in a screen like the one below.
    4. +
+ +
+ Start adding a pipeline dependency material +
Start adding a pipeline dependency material
+
+ +

+ As soon as you start typing the name of your first pipeline in the "Pipeline [Stage]" textbox, it will + autocomplete and give you the name of the first pipeline and the only stage that is in it. Selecting that will + link these two pipelines together. +

+
+ Autocompletion of the pipeline dependency material +
Autocompletion of the pipeline dependency material
+
+ +

Click "Next" and choose some task in the "Initial Job and Task" section and click "Finish".

+
+ Create the downstream pipeline +
Create the downstream pipeline
+
+ +

+ That's it! You'll now have a pipeline which will run when un-pause. Un-pause it and let it finish. This is how + it will look on the Pipelines list (dashboard) when finished. +

+
+ Dependent pipelines on the dashboard +
Dependent pipelines on the dashboard
+
+ +

+ That doesn't look very different. But, this allows for some powerful features such as fan-in, fan-out and the + ValueStream Map (VSM), which we will learn about in Part 3. Click + on the label of the "MyFirstPipeline" (the part highlightedin the image above) for a sneak peek at a small + Value Stream Map. +

+ +
+ Dependent pipelines in a Value Stream Map +
Dependent pipelines in a Value Stream Map
+
+ +

You now know how to chain pipelines together. Let's now learn about artifacts, which are very useful when used with pipeline dependencies.

+ +

Publishing, fetching and using artifacts

+ +

A very important aspect of GoCD is the way it handles artifacts.

+ +
+

Concept 6: Artifact

+ +

+ An artifact in GoCD is a file or directory which is most often produced during the run of a pipeline. Every job in a + pipeline can be configured to publish its own set of artifacts and GoCD will ensure that these artifacts are moved from + the Agent where it is created, to the Server and stored there, so that it can be retrieved at any time. +

+ +

+ Typically, artifacts are created during a job run, by one of the tasks. Some examples of artifacts are: Test reports, + coverage reports, installers, documentation, meta information about the build process itself and anything else that + needs to be stored after a pipeline has finished. +

+ +

+ These artifacts, published by a job, can be fetched and used by any downstream pipeline or any + stage after the one that produced the artifact in the same pipeline, using a special task called a "Fetch Artifact" + task. If you recall from "Concept 4" in part 1, jobs are independent of each other. So, a job in the same stage as + another job that produced an artifact cannot use that artifact. It needs to be used in a stage after that one. +

+
+ +

+ Let's see how to publish an artifact. In the upstream pipeline, "MyFirstPipeline", let's first declare an + artifact. The build script used throughout this guide creates a file called "my-artifact.html" after it + finishes. We can use that as the artifact for this example. +

+ +
    +
  1. Go to "Admin" -> "Pipelines" and the select the stage, "defaultStage" and then the job, "defaultJob".
    2. +
  2. Click on the "Artifacts" tab in the job.
    3. +
  3. Enter "my-artifact.html" as the artifact source.
    4. +
  4. Leave the "Destination" box empty for now.
    5. +
+ +
+ Adding an artifact +
Adding an artifact
+
+ +

+ Since we have chosen to leave the "Destination" empty, and that means that the artifact will be accessible at the root, + by its own name. We have also chosen the type as "Build Artifact", to signify that it is not a "Test Artifact". Marking + it as a "Test Artifact" means that GoCD will try and parse the file as a test report and if it can, it will use it in + the test aggregation reporting it does. Typically, you'll want to use "Build Artifact" for installers, binaries, + documentation, etc. +

+ +

+ After saving this change, retrigger "MyFirstPipeline" by going to the pipeline dashboard and clicking on the play button + against it. Once it is finished, going to the "Artifacts" tab of the pipeline run shows you the artifact for that + run. Every run of that pipeline, from now on, will have that artifact. +

+ +
+ The artifacts tab - Every job will have one +
The artifacts tab - Every job will have one
+
+ +

Clicking on it will show you its contents:

+ +
+ The contents of the artifact - It is stored on the Go C D Server +
The contents of the artifact - It is stored on the GoCD Server
+
+ +

Fetching and using artifacts

+ +

+ We can now use this artifact in any downstream pipeline, or any subsequent stage of the same pipeline. Let's fetch this + artifact in the pipeline "MySecondPipeline" and display it as a part of the output. To do this, we go to the task + configuration section of the "defaultJob" job inside the "defaultStage" stage of "MySecondPipeline" pipeline, and add a + "Fetch Artifact" task. +

+ +
+ Adding a Fetch Artifact task +
Adding a "Fetch Artifact" task
+
+ +
+ The details can be autocompleted +
The details can be autocompleted
+
+ +

+ Once you provide all the details and click save, you can move the "Fetch Artifact" task above, so that it is + done first. Then, for this demonstration, let us display the fetched file in a "Custom Command" task. +

+
+ Move the fetch artifact task to the top +
Move the fetch artifact task to the top
+
+ +

+ After it is moved up, you can edit the "Custom Command" task to output the contents of the file (for instance). If you + are running this on Windows, use "type" instead of "cat": +

+ +
+ Display the contents of the fetched artifact +
Display the contents of the fetched artifact
+
+ +
+ This is how the tasks should look like +
This is how the tasks should look like
+
+ +

+ Running "MySecondPipeline" now will show you the contents of the file created in "MyFirstPipeline" and fetched + as an artifact. The importance of fetching an artifact this way is that GoCD will ensure that the correct + version of the artifact will be fetched and provided to the job in "MySecondPipeline". +

+ +

+ If more instances of "MyFirstPipeline" ran (because it is fast) while "MySecondPipeline" has run fewer times, + GoCD will ensure that every time "MySecondPipeline" runs, the correct (and compatible) version of the artifact + is fetched and used. When you now check the output of the pipeline, you should see something like this: +

+ +
+ The output - The artifact is fetched and displayed +
The output - The artifact is fetched and displayed
+
+ +
+

Concept 7: Ancestor artifacts and building artifacts only once

+ +

+ In GoCD, you can even fetch artifacts from pipelines which are not immediately downstream of the pipeline which produces + an artifact. It can be fetched from any pipeline which is downstream, however many levels that is. So, with a Value + Stream Map like this: +

+ +
+ Value Stream Map +
+ +

+ The pipeline "MyFifthPipeline" can be configured to fetch an artifact from "MyFirstPipeline" like this: +

+ +
+ Fetching artifacts from ancestor pipelines +
Fetching artifacts from ancestor pipelines
+
+ +

+ GoCD will complete the name of the pipeline and the path through the upstream pipelines for you and you can then use an + artifact from an ancestor pipeline in a downstream pipeline. +

+ +

+ The ability to do this is important because of how artifacts are expected to be used in a Continuous Delivery + pipeline. A core concept of CD is "Only Build Your Binaries Once". This prevents problems such as inconsistencies + between a binary which went through various levels of testing and a new "duplicate binary" which is released after being + built on a box which has a slightly different environment. So, the ability to move an artifact between pipelines and + more importantly, knowing that it is the same binary being used (GoCD ensures that) is important. +

+ +

+ We can then take the same binary across different kinds of tests, getting more confident about it as it progresses + through the pipelines, eventually reaching a production-deployment pipeline, knowing that the binary that is getting + deployed is the same as the one that went through tests. +

+
+ +

Custom tabs

+ +

+ The final part of this guide introduces the concept of a custom tab. A question that gets asked all the time + is: "Does GoCD integrate with <application-x> and show its output?". The answer is usually: "Yes, as + long as that application can generate a report or output that needs to be shown". Here is the concept: +

+ +
+

Concept 8: Custom tab

+ +

+ A custom tab in GoCD is a way of showing an artifact as a user-defined tab at the job level. Any file which + is published as an artifact by a job can be shown. Usually, these are HTML files, with images. The GoCD + Server will serve these files from its internal artifact repository. +

+
+ +

+ Let's use the example artifact we had used earlier as a custom tab. To do that, let's go to the configuration + of "MyFirstPipeline" and then to the "Custom Tab" section of the "defaultJob" and create one. It should look + like this: +

+
+ Configuring a custom tab +
Configuring a custom tab
+
+ +

+ That's it! If you now go to the pipeline, and navigate to the job "defaultJob", you'll see a custom tab called + "SomeCustomName". Clicking on it will show you the artifact for that run of the pipeline. +

+ +
+ A custom tab in action +
A custom tab in action
+
+ +

+ This can be used to integrate with coverage tools, unit test reports and anything else which creates an + artifact. +

+ +

+ In this part of the guide, you learnt about pipeline dependencies, artifacts and custom tabs. In + Part 3 of this guide, we dive deeper into the Value Stream Map and into + the powerful fan-in and fan-out concepts. +

+ +
+ Previous + Next +
+ +
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/getting-started/part-3.html b/pr-1714/getting-started/part-3.html new file mode 100644 index 000000000..085fe41c3 --- /dev/null +++ b/pr-1714/getting-started/part-3.html @@ -0,0 +1,426 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part Three | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

+ In Part 1 of this guide, the concepts of GoCD Server, GoCD Agents, + pipelines, materials, stages, jobs and tasks were introduced. You were also able to get a simple pipeline + with a single stage, job and task each working. +

+ +

+ In Part 2, you learnt about using pipelines as materials + (dependency materials), artifacts and custom tabs. +

+ +

Let us continue, in this part, by learning about the Value Stream Map (VSM) and about fan-in and fan-out.

+ +

Value Stream Map (VSM)

+ +
+

Concept 9: Value Stream Map (VSM)

+ +

+ The Value Stream Map is the full end-to-end (from commits to production) view across pipelines, and maps to + the concept of a "Continuous Delivery Pipeline" or "Deployment Pipeline", in the book, "Continuous Delivery" + by Jez Humble and David Farley. In their book, a couple of different views of a Deployment Pipeline are + presented: +

+ +
+ Deployment Pipeline view shows that as you go closer to production, the confidence of the build's production readiness increases +
+ The idea is that, as you go closer to production, the confidence of the build's production readiness + increases. (Image © Humble, Farley) +
+
+ +
+ Image depicts the interactions between source code repositories, artifact repositories and different stages of the Deployment Pipeline. +
+ This depicts the interactions between source code repositories, artifact repositories and different stages + of the Deployment Pipeline. (Image © Humble, Farley) +
+
+ +

+ A corresponding representation of a Value Stream Map in GoCD looks like this: +

+ +
+ Go C D Value Stream Map representing the stages of deployment pipeline +
+ +

+ There are some unfortunate differences in naming between GoCD and the book. What is termed as a "Stage of a Deployment + Pipeline" in the book is called a "Pipeline" in GoCD. The "Deployment Pipeline" (end-to-end) is called the "Value + Stream Map". In the rest of this guide, the term "Pipeline" will refer to a GoCD Pipeline and the term "Stage" will + refer to a "Stage of a GoCD pipeline". +

+ +

+ Interestingly, Jez Humble was the first product manager of GoCD, and was around while these naming decisions were + made. Rumour has it that he regrets the choice of the overloaded term, "Pipeline". :) +

+ +

+ The previously defined concepts of a Pipeline, Artifact and Pipeline Dependency (chaining of pipelines) come + together to enable a true end-to-end Deployment Pipeline, which is known as a Value Stream Map (VSM) in GoCD. The + ability to do this, and so this concept is important because: +

+ +
    +
  1. + Abstraction: It is a level of abstraction in modeling, and allows you to hide (by default) what + is going on underneath and not have to know the details unless you need to. It helps talk about and reason about + your end-to-end workflow at a different level. +
    2. +
  2. + Build once: This allows artifacts to be propagated through the pipelines. As mentioned in the + Artifact concept definition, this enables an important CD concept, "Only Build Your Binaries Once". +
    3. +
  3. + Parallelization: This provides another approach to parallelize your workflow. In the example + above, the User Acceptance Pipeline and the Capacity Testing Pipeline can run simultaneously, providing quicker + feedback. This will be discussed later in this guide, in the Fan-In/Fan-Out section. +
    4. +
  4. + Traceability: This provides true auditability and traceability, all the way from a commit to + production. You know exactly what went into production. +
    5. +
+
+ +

+ To use a Value Stream Map in GoCD, you don't really need to do anything. If you have pipelines which use + pipeline dependencies, then you can always get a VSM at the click of a button. Here is a dashboard view of + pipelines which map to the example shown in the concept. Clicking on the VSM link (marked in red boxes) in any of + the pipeline tiles shows the VSM from the perspective of that pipeline: +

+
+ The labels of pipelines - gateways to VSM +
Navigating to the VSM
+
+ +

Clicking on the VSM link of the "Production" pipeline takes you to its Value Stream Map, in which all of its upstream + pipelines and their source control materials are shown.

+ +
+ VSM from the view of the Production pipeline +
VSM from the view of the "Production" pipeline
+
+ +

+ Clicking on the VSM link of the "Build" pipeline, either from the dashboard or the VSM view above, takes you to a + similar view with the perspective of the "Build" pipeline instance. It is shown below. You can + see that the source material of "CapacityTesting" pipeline is not shown, because it is not directly downstream + of the "Build" pipeline. +

+ +
+ VSM from the view of the Build pipeline +
VSM from the view of the "Build" pipeline
+
+ +

+ Now, that we know about the VSM, let's delve a little deeper into powerful concepts called fan-in and fan-out, + which the VSM visualizes. +

+ +

Fan-Out and Fan-In

+ +

Let's start with the basic concepts and then use an example to understand this further.

+ +
+

Concept 10: Fan-Out and Fan-In

+ +

Fan-Out

+ +

+ A pipeline "X" can be said to fan-out to downstream pipelines, when there are multiple downstream pipelines + for which pipeline "X" is a dependency. It looks like this: +

+ +
+ Pipeline fanning out to downstream pipelines +
+

+ Similarly, a source material can be said to fan-out to downstream pipelines: +

+ +
+ Source Material fanning out to downstream pipelines +
+

+ This brings in the advantages of parallelization and quicker feedback, which is a key goal of Continuous Delivery. As + long as there are enough agents available, all three downstream dependencies will trigger together and can run + together. +

+ +

Fan-In

+ +

+ Opposite of fan-out. When multiple dependencies are used by a single pipeline, then the dependencies are + said to fan-in to the pipeline. It looks like this: +

+ +
+ image shows multiple dependencies used by a single pipeline as fanning in to the pipeline +
+ +

+ In this example, there is a fan-in at the Production pipeline, from its two upstream pipelines and the git + material. Similarly, there is a fan-in at the CapacityTesting pipeline. The important aspect of fan-in is + not that there are multiple dependencies upstream, but the way that the pipeline is triggered, by ensuring + that all of its dependencies are consistent in version, when the pipeline runs. This ensures correctness of + the build, and quicker feedback through elimination of spurious builds. +

+
+ +

+ Let's bring back an earlier VSM view, from the Production pipeline perspective, with the links leading into + the Production pipeline emphasized a bit, by pinning it: +

+ +
+ VSM with links pinned - showing fan-in +
VSM with links pinned - showing fan-in
+
+ +

+ In this setup, the Build pipeline is said to fan-out to the UserAcceptance and CapacityTesting pipelines, and + the git material, UserAcceptance pipeline, and CapacityTesting pipeline are said to fan-in to the Production + pipeline. From a terminology perspective, that might make sense. But what does it really mean? Why is it + important? +

+ +

+ To understand that, let's consider what should happen when a commit (say C1) is made to the git material + shown. Even though the Production pipeline has a direct dependency on the git material, it should not be + triggered automatically. The correct order of triggering of pipelines is: +

+ +
    +
  1. Build pipeline - with commit C1 (let's say the pipeline label of this is "Build_1").
    2. +
  2. Once it succeeds, both UserAcceptance and CapacityTesting pipelines with "Build_1" as their dependency (say "UA_1" and "CT_1").
    3. +
  3. Once they succeed, Production pipeline with git commit C1, pipeline dependency UA_1, and pipeline dependency CT_1.
    4. +
+ +

+ This ordering and consistency of versioning is what GoCD with fan-out and fan-in will ensure. There are two + main reasons for this to be considered very important: +

+ +
    +
  1. +

    + Correctness: Without fan-in, if the CapacityTesting pipeline was slow and UserAcceptance + pipeline was fast, then the Production pipeline could have been triggered with an old version of + CapacityTesting pipeline and a new version of UserAcceptance pipeline. Imagine deploying to Production + without really knowing that all upstream dependent pipelines have not finished successfully! +

    + +

    + A very important part of fan-out and fan-in is that a downstream pipeline will always figure out + the correct upstream dependency versions, including repository materials, unless it is manually forced by + a user not to. +

    + +

    + Similarly, any artifacts fetched from any upstream pipeline, however many levels up, is guaranteed to be + consistent and correct. This means that the right revision of those artifacts will be fetched, + irrespective of any other runs of that pipeline that may have run after. +

    +
    2. + +
  2. + Quicker feedback: By eliminating spurious builds which should never have been built (using + wrong dependencies), fan-in provides quicker feedback. Similarly, fan-out allows multiple independent + downstream pipelines to run simultaneously, providing quicker feedback. +
    3. +
+ +

+ This has been a bit of a whirlwind tour of some of GoCD's concepts and ideas. To learn more about all the + other features and how to use them, head on over to the GoCD + documentation page. +

+ +
+ Previous +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/getting-started/part-3/index.html b/pr-1714/getting-started/part-3/index.html new file mode 100644 index 000000000..d87ed6a2c --- /dev/null +++ b/pr-1714/getting-started/part-3/index.html @@ -0,0 +1,426 @@ + + + + + + + + + + + + + + + + Help - Getting Started with GoCD Part Three | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Introduction to GoCD

+
+
+ +
+
+ +
+ + +
+ +
+
+

+ In Part 1 of this guide, the concepts of GoCD Server, GoCD Agents, + pipelines, materials, stages, jobs and tasks were introduced. You were also able to get a simple pipeline + with a single stage, job and task each working. +

+ +

+ In Part 2, you learnt about using pipelines as materials + (dependency materials), artifacts and custom tabs. +

+ +

Let us continue, in this part, by learning about the Value Stream Map (VSM) and about fan-in and fan-out.

+ +

Value Stream Map (VSM)

+ +
+

Concept 9: Value Stream Map (VSM)

+ +

+ The Value Stream Map is the full end-to-end (from commits to production) view across pipelines, and maps to + the concept of a "Continuous Delivery Pipeline" or "Deployment Pipeline", in the book, "Continuous Delivery" + by Jez Humble and David Farley. In their book, a couple of different views of a Deployment Pipeline are + presented: +

+ +
+ Deployment Pipeline view shows that as you go closer to production, the confidence of the build's production readiness increases +
+ The idea is that, as you go closer to production, the confidence of the build's production readiness + increases. (Image © Humble, Farley) +
+
+ +
+ Image depicts the interactions between source code repositories, artifact repositories and different stages of the Deployment Pipeline. +
+ This depicts the interactions between source code repositories, artifact repositories and different stages + of the Deployment Pipeline. (Image © Humble, Farley) +
+
+ +

+ A corresponding representation of a Value Stream Map in GoCD looks like this: +

+ +
+ Go C D Value Stream Map representing the stages of deployment pipeline +
+ +

+ There are some unfortunate differences in naming between GoCD and the book. What is termed as a "Stage of a Deployment + Pipeline" in the book is called a "Pipeline" in GoCD. The "Deployment Pipeline" (end-to-end) is called the "Value + Stream Map". In the rest of this guide, the term "Pipeline" will refer to a GoCD Pipeline and the term "Stage" will + refer to a "Stage of a GoCD pipeline". +

+ +

+ Interestingly, Jez Humble was the first product manager of GoCD, and was around while these naming decisions were + made. Rumour has it that he regrets the choice of the overloaded term, "Pipeline". :) +

+ +

+ The previously defined concepts of a Pipeline, Artifact and Pipeline Dependency (chaining of pipelines) come + together to enable a true end-to-end Deployment Pipeline, which is known as a Value Stream Map (VSM) in GoCD. The + ability to do this, and so this concept is important because: +

+ +
    +
  1. + Abstraction: It is a level of abstraction in modeling, and allows you to hide (by default) what + is going on underneath and not have to know the details unless you need to. It helps talk about and reason about + your end-to-end workflow at a different level. +
    2. +
  2. + Build once: This allows artifacts to be propagated through the pipelines. As mentioned in the + Artifact concept definition, this enables an important CD concept, "Only Build Your Binaries Once". +
    3. +
  3. + Parallelization: This provides another approach to parallelize your workflow. In the example + above, the User Acceptance Pipeline and the Capacity Testing Pipeline can run simultaneously, providing quicker + feedback. This will be discussed later in this guide, in the Fan-In/Fan-Out section. +
    4. +
  4. + Traceability: This provides true auditability and traceability, all the way from a commit to + production. You know exactly what went into production. +
    5. +
+
+ +

+ To use a Value Stream Map in GoCD, you don't really need to do anything. If you have pipelines which use + pipeline dependencies, then you can always get a VSM at the click of a button. Here is a dashboard view of + pipelines which map to the example shown in the concept. Clicking on the VSM link (marked in red boxes) in any of + the pipeline tiles shows the VSM from the perspective of that pipeline: +

+
+ The labels of pipelines - gateways to VSM +
Navigating to the VSM
+
+ +

Clicking on the VSM link of the "Production" pipeline takes you to its Value Stream Map, in which all of its upstream + pipelines and their source control materials are shown.

+ +
+ VSM from the view of the Production pipeline +
VSM from the view of the "Production" pipeline
+
+ +

+ Clicking on the VSM link of the "Build" pipeline, either from the dashboard or the VSM view above, takes you to a + similar view with the perspective of the "Build" pipeline instance. It is shown below. You can + see that the source material of "CapacityTesting" pipeline is not shown, because it is not directly downstream + of the "Build" pipeline. +

+ +
+ VSM from the view of the Build pipeline +
VSM from the view of the "Build" pipeline
+
+ +

+ Now, that we know about the VSM, let's delve a little deeper into powerful concepts called fan-in and fan-out, + which the VSM visualizes. +

+ +

Fan-Out and Fan-In

+ +

Let's start with the basic concepts and then use an example to understand this further.

+ +
+

Concept 10: Fan-Out and Fan-In

+ +

Fan-Out

+ +

+ A pipeline "X" can be said to fan-out to downstream pipelines, when there are multiple downstream pipelines + for which pipeline "X" is a dependency. It looks like this: +

+ +
+ Pipeline fanning out to downstream pipelines +
+

+ Similarly, a source material can be said to fan-out to downstream pipelines: +

+ +
+ Source Material fanning out to downstream pipelines +
+

+ This brings in the advantages of parallelization and quicker feedback, which is a key goal of Continuous Delivery. As + long as there are enough agents available, all three downstream dependencies will trigger together and can run + together. +

+ +

Fan-In

+ +

+ Opposite of fan-out. When multiple dependencies are used by a single pipeline, then the dependencies are + said to fan-in to the pipeline. It looks like this: +

+ +
+ image shows multiple dependencies used by a single pipeline as fanning in to the pipeline +
+ +

+ In this example, there is a fan-in at the Production pipeline, from its two upstream pipelines and the git + material. Similarly, there is a fan-in at the CapacityTesting pipeline. The important aspect of fan-in is + not that there are multiple dependencies upstream, but the way that the pipeline is triggered, by ensuring + that all of its dependencies are consistent in version, when the pipeline runs. This ensures correctness of + the build, and quicker feedback through elimination of spurious builds. +

+
+ +

+ Let's bring back an earlier VSM view, from the Production pipeline perspective, with the links leading into + the Production pipeline emphasized a bit, by pinning it: +

+ +
+ VSM with links pinned - showing fan-in +
VSM with links pinned - showing fan-in
+
+ +

+ In this setup, the Build pipeline is said to fan-out to the UserAcceptance and CapacityTesting pipelines, and + the git material, UserAcceptance pipeline, and CapacityTesting pipeline are said to fan-in to the Production + pipeline. From a terminology perspective, that might make sense. But what does it really mean? Why is it + important? +

+ +

+ To understand that, let's consider what should happen when a commit (say C1) is made to the git material + shown. Even though the Production pipeline has a direct dependency on the git material, it should not be + triggered automatically. The correct order of triggering of pipelines is: +

+ +
    +
  1. Build pipeline - with commit C1 (let's say the pipeline label of this is "Build_1").
    2. +
  2. Once it succeeds, both UserAcceptance and CapacityTesting pipelines with "Build_1" as their dependency (say "UA_1" and "CT_1").
    3. +
  3. Once they succeed, Production pipeline with git commit C1, pipeline dependency UA_1, and pipeline dependency CT_1.
    4. +
+ +

+ This ordering and consistency of versioning is what GoCD with fan-out and fan-in will ensure. There are two + main reasons for this to be considered very important: +

+ +
    +
  1. +

    + Correctness: Without fan-in, if the CapacityTesting pipeline was slow and UserAcceptance + pipeline was fast, then the Production pipeline could have been triggered with an old version of + CapacityTesting pipeline and a new version of UserAcceptance pipeline. Imagine deploying to Production + without really knowing that all upstream dependent pipelines have not finished successfully! +

    + +

    + A very important part of fan-out and fan-in is that a downstream pipeline will always figure out + the correct upstream dependency versions, including repository materials, unless it is manually forced by + a user not to. +

    + +

    + Similarly, any artifacts fetched from any upstream pipeline, however many levels up, is guaranteed to be + consistent and correct. This means that the right revision of those artifacts will be fetched, + irrespective of any other runs of that pipeline that may have run after. +

    +
    2. + +
  2. + Quicker feedback: By eliminating spurious builds which should never have been built (using + wrong dependencies), fan-in provides quicker feedback. Similarly, fan-out allows multiple independent + downstream pipelines to run simultaneously, providing quicker feedback. +
    3. +
+ +

+ This has been a bit of a whirlwind tour of some of GoCD's concepts and ideas. To learn more about all the + other features and how to use them, head on over to the GoCD + documentation page. +

+ +
+ Previous +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/glossary.html b/pr-1714/glossary.html new file mode 100644 index 000000000..edb43c220 --- /dev/null +++ b/pr-1714/glossary.html @@ -0,0 +1,209 @@ + + + + + + + + + + + + + + + + Continuous Delivery Dictionary | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+ GoCD and Jenkins +
+ +
+
+ +
+ +
+
+

Continuous Delivery Dictionary

+

This is a Continuous Delivery Dictionary.

+
+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
KeywordDefinition
CD pipelineA CD (continuous delivery) pipeline is also known as a deployment pipeline. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production. Deployments can occur manually or automatically (see continuous deployment)
+ Build pipelineAlso known as a deployment pipeline or a CD pipeline.
Deployment pipeline + A deployment pipeline consists of multiple stages, each of which will be run in order. If a stage fails, then the pipeline is considered failed and the following stages will not be started. This prevents bugs from being deployed into production. +
Pipelines as codePipelines as code allows you to configure your pipeline outside of your continuous delivery environment. +
Continuous deploymentContinuous Deployment, often confused with continuous delivery, is simply a deployment that is done automatically.
Trunk based development + Trunk based development requires all code changes to always be integrated into their main line, also known as trunk or master, the main branch of the source repository. Others do branch-based development when individually developers will have their own branches, or teams will have branches for different features. +
+ Branch based development + Branch based development, also known as feature branching, occurs when individual developers or teams will work on their own isolated branches when building new features. This is an anti-pattern to the best practices of continuous integration. + +
+ Value stream mapValue Stream Map helps you visualize your CI/CD workflow. It allows you to trace a commit from when it is checked in up to when it is deployed.The Value Stream Map (VSM) is an end-to-end view of a pipeline, its upstream dependencies and the downstream pipelines it triggers. +
+ + + +
+
+
+ + Get Started with GoCD +
+
+
+ + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/glossary/index.html b/pr-1714/glossary/index.html new file mode 100644 index 000000000..8d0f20121 --- /dev/null +++ b/pr-1714/glossary/index.html @@ -0,0 +1,209 @@ + + + + + + + + + + + + + + + + Continuous Delivery Dictionary | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+ GoCD and Jenkins +
+ +
+
+ +
+ +
+
+

Continuous Delivery Dictionary

+

This is a Continuous Delivery Dictionary.

+
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
KeywordDefinition
CD pipelineA CD (continuous delivery) pipeline is also known as a deployment pipeline. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production. Deployments can occur manually or automatically (see continuous deployment)
+ Build pipelineAlso known as a deployment pipeline or a CD pipeline.
Deployment pipeline + A deployment pipeline consists of multiple stages, each of which will be run in order. If a stage fails, then the pipeline is considered failed and the following stages will not be started. This prevents bugs from being deployed into production. +
Pipelines as codePipelines as code allows you to configure your pipeline outside of your continuous delivery environment. +
Continuous deploymentContinuous Deployment, often confused with continuous delivery, is simply a deployment that is done automatically.
Trunk based development + Trunk based development requires all code changes to always be integrated into their main line, also known as trunk or master, the main branch of the source repository. Others do branch-based development when individually developers will have their own branches, or teams will have branches for different features. +
+ Branch based development + Branch based development, also known as feature branching, occurs when individual developers or teams will work on their own isolated branches when building new features. This is an anti-pattern to the best practices of continuous integration. + +
+ Value stream mapValue Stream Map helps you visualize your CI/CD workflow. It allows you to trace a commit from when it is checked in up to when it is deployed.The Value Stream Map (VSM) is an end-to-end view of a pipeline, its upstream dependencies and the downstream pipelines it triggers. +
+
+ + +
+
+
+ + Get Started with GoCD +
+
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/gocdvsjenkins.html b/pr-1714/gocdvsjenkins.html new file mode 100644 index 000000000..1f79d32bf --- /dev/null +++ b/pr-1714/gocdvsjenkins.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the 2017/04/25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/gocdvsjenkins/index.html b/pr-1714/gocdvsjenkins/index.html new file mode 100644 index 000000000..fa6c8ef3b --- /dev/null +++ b/pr-1714/gocdvsjenkins/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../2017/04/25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/googlebac7590bd2b477d8.html b/pr-1714/googlebac7590bd2b477d8.html new file mode 100644 index 000000000..08979ab31 --- /dev/null +++ b/pr-1714/googlebac7590bd2b477d8.html @@ -0,0 +1 @@ +google-site-verification: googlebac7590bd2b477d8.html \ No newline at end of file diff --git a/pr-1714/googlebac7590bd2b477d8/index.html b/pr-1714/googlebac7590bd2b477d8/index.html new file mode 100644 index 000000000..08979ab31 --- /dev/null +++ b/pr-1714/googlebac7590bd2b477d8/index.html @@ -0,0 +1 @@ +google-site-verification: googlebac7590bd2b477d8.html \ No newline at end of file diff --git a/pr-1714/govsjenkins.html b/pr-1714/govsjenkins.html new file mode 100644 index 000000000..1f79d32bf --- /dev/null +++ b/pr-1714/govsjenkins.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the 2017/04/25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/govsjenkins/index.html b/pr-1714/govsjenkins/index.html new file mode 100644 index 000000000..fa6c8ef3b --- /dev/null +++ b/pr-1714/govsjenkins/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../2017/04/25/gocd-over-jenkins/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/help.html b/pr-1714/help.html new file mode 100644 index 000000000..8c2572d61 --- /dev/null +++ b/pr-1714/help.html @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + + + Getting Started Guide | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+ +
+
+

Getting Help with GoCD

+
+ +

Introduction to GoCD Guide

+
+ Setup your first Pipeline +
+

Quickly build your first pipeline while learning key GoCD concepts.

+ + +

GoCD Documentation

+
+ GoCD Concepts Guide +
+

Information on how to set up, use, and administer GoCD can be found here.

+ +
+
+
+ +
+
+

Get Involved with the GoCD Community

+

+ A huge part of GoCD's success as an OSS product has been the support of a very active + community. We encourage you to join in the discussions to both learn and contribute. +

+
+ +

GoCD User Group

+
+ User Group +
+

Join the ongoing GoCD community chat +

+ + +

GoCD on GitHub

+
+ Github Repo +
+

Review open bugs or log a new one

+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/help/index.html b/pr-1714/help/index.html new file mode 100644 index 000000000..98095e548 --- /dev/null +++ b/pr-1714/help/index.html @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + + + Getting Started Guide | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+ +
+
+

Getting Help with GoCD

+
+ +

Introduction to GoCD Guide

+
+ Setup your first Pipeline +
+

Quickly build your first pipeline while learning key GoCD concepts.

+ + +

GoCD Documentation

+
+ GoCD Concepts Guide +
+

Information on how to set up, use, and administer GoCD can be found here.

+ +
+
+
+ +
+
+

Get Involved with the GoCD Community

+

+ A huge part of GoCD's success as an OSS product has been the support of a very active + community. We encourage you to join in the discussions to both learn and contribute. +

+
+ +

GoCD User Group

+
+ User Group +
+

Join the ongoing GoCD community chat +

+ + +

GoCD on GitHub

+
+ Github Repo +
+

Review open bugs or log a new one

+ +
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/index.html b/pr-1714/index.html new file mode 100644 index 000000000..2da907943 --- /dev/null +++ b/pr-1714/index.html @@ -0,0 +1,247 @@ + + + + + + + + + + + + + + + + Open Source Continuous Delivery and Release Automation Server | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + + + + GoCD project status in 2023 (blog) + +
+
+
+
+

End to End Visualization

+
+ End to End Visualization +
+

GoCD’s value stream map shows your entire path to production in a single view. Easily navigate across jobs, spot inefficiencies, and optimize your process. +
No plugin required, out of box CD.

+
+
+
+ End to End Visualisation +
+
+
+ +
+
+
+ Cloud Native +
+
+ +
+

Cloud Native Deployments

+
+ Cloud Native +
+

GoCD streamlines your CD workflow on popular cloud environments such as Kubernetes, Docker, AWS and more.

+
+
+ +
+
+

Complex Workflow Modeling

+
+ Complex Workflow Modeling +
+

GoCD excels at modeling complex CD workflows for fast feedback with its modeling constructs, parallel execution and dependency management. +
No plugin required, out of box CD.

+
+ +
+
+ Complex Workflow Modeling +
+
+
+ +
+
+
+ Advanced Traceability +
+
+ +
+

Advanced Traceability

+
+ Advanced Traceability +
+

GoCD helps you troubleshoot a broken pipeline by tracking every change from commit to deploy in real time. Compare content - both files and commit messages - across any two arbitrary builds. +
No plugin required, out of box CD.

+
+
+
+
+ +
+
+
+
+
+ GoCD open source plugins +
+ +
+

Plugins

+

+ GoCD integrates with many popular external tools and services via its extensible plugin architecture. We have put a lot of thought into making sure GoCD upgrades are painless and non-breaking even when you are using plugins. + There are numerous high-quality, curated plugins currently available. Something you don’t see? GoCD's plugin API makes it easy to write your own. +

+
+
+ +
+
+ GoCD open source community +
+ +
+

Community

+

+ Through our active forum, users and contributors share best practices and openly discuss a wide range of topics including GoCD and continuous delivery how-tos. To join in the conversation visit our Google group + or if you'd prefer Markdown, try GitHub Discussions. +

+
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/infoq.html b/pr-1714/infoq.html new file mode 100644 index 000000000..3de7f75a3 --- /dev/null +++ b/pr-1714/infoq.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=infoq_2016_q4&utm_medium=podcast_infoq&utm_source=podcast_infoq&utm_content=go_download&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/infoq/index.html b/pr-1714/infoq/index.html new file mode 100644 index 000000000..fb99bde38 --- /dev/null +++ b/pr-1714/infoq/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=infoq_2016_q4&utm_medium=podcast_infoq&utm_source=podcast_infoq&utm_content=go_download&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/jenkins.html b/pr-1714/jenkins.html new file mode 100644 index 000000000..8bbab27c0 --- /dev/null +++ b/pr-1714/jenkins.html @@ -0,0 +1,197 @@ + + + + + + + + + + + + + + + + The differences between GoCD and Jenkins | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+ GoCD and Jenkins +
+ +
+
+ +
+ +
+
+

The differences between GoCD and Jenkins

+

If you are doing or want to do continuous delivery, you should be using GoCD, a solid Jenkins alternative. GoCD suits both beginners and those highly experienced in building deployment pipelines. If you want to utilize a vast plugin catalog to automate a variety of things then Jenkins might be a better fit for you. Here’s a high level comparison between GoCD and Jenkins.

+
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

GoCDJenkins
PhilosophyGoCD is a best-of-breed tool for Continuous Delivery (CD).Jenkins is a general purpose automation tool and is built for Continuous Integration(CI).
Plugins
GoCD aims to support the most common CD scenarios out of the box without any plugin installation.Extensibility is core to Jenkins. Its flexibility attributes itself to plugins being critical to Jenkins’ functionality. So it depends heavily on plugins for pretty much any use case.
Continuous DeliveryGoCD was built on the principles of Continuous Delivery. This is visible in its abstractions as pipeline is a first class concept. GoCD also encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns, you will generally find a single, well-known, well-tested answer.With Jenkins 2.0, CD is implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile combinations of plugins.
Continuous IntegrationAlthough GoCD is built specifically with CD in mind, it has sophisticated features for continuous integration.Jenkins is built for CI. Anything beyond that, requires plugins.
Getting StartedIf you are are new to CD and deployment pipelines, GoCD’s getting started tutorial is a big help. It will teach you the key deployment pipeline patterns while you learn how GoCD works.Jenkins 2.0 has a helpful getting started experience by providing a wizard to guide you through plugin installation. This wizard includes a default set of common plugins and prompting you to setup your first build. But this won’t prevent you from needing an in depth understanding of the plugins to create the correct plugin mix for your use case.
+
+ + +
+
+
+ + Get Started with GoCD +
+
+
+ + +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/jenkins/index.html b/pr-1714/jenkins/index.html new file mode 100644 index 000000000..8908f608f --- /dev/null +++ b/pr-1714/jenkins/index.html @@ -0,0 +1,197 @@ + + + + + + + + + + + + + + + + The differences between GoCD and Jenkins | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+ GoCD and Jenkins +
+ +
+
+ +
+ +
+
+

The differences between GoCD and Jenkins

+

If you are doing or want to do continuous delivery, you should be using GoCD, a solid Jenkins alternative. GoCD suits both beginners and those highly experienced in building deployment pipelines. If you want to utilize a vast plugin catalog to automate a variety of things then Jenkins might be a better fit for you. Here’s a high level comparison between GoCD and Jenkins.

+
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

GoCDJenkins
PhilosophyGoCD is a best-of-breed tool for Continuous Delivery (CD).Jenkins is a general purpose automation tool and is built for Continuous Integration(CI).
Plugins
GoCD aims to support the most common CD scenarios out of the box without any plugin installation.Extensibility is core to Jenkins. Its flexibility attributes itself to plugins being critical to Jenkins’ functionality. So it depends heavily on plugins for pretty much any use case.
Continuous DeliveryGoCD was built on the principles of Continuous Delivery. This is visible in its abstractions as pipeline is a first class concept. GoCD also encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns, you will generally find a single, well-known, well-tested answer.With Jenkins 2.0, CD is implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile combinations of plugins.
Continuous IntegrationAlthough GoCD is built specifically with CD in mind, it has sophisticated features for continuous integration.Jenkins is built for CI. Anything beyond that, requires plugins.
Getting StartedIf you are are new to CD and deployment pipelines, GoCD’s getting started tutorial is a big help. It will teach you the key deployment pipeline patterns while you learn how GoCD works.Jenkins 2.0 has a helpful getting started experience by providing a wizard to guide you through plugin installation. This wizard includes a default set of common plugins and prompting you to setup your first build. But this won’t prevent you from needing an in depth understanding of the plugins to create the correct plugin mix for your use case.
+
+ + +
+
+
+ + Get Started with GoCD +
+
+
+ + +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/kubernetes.html b/pr-1714/kubernetes.html new file mode 100644 index 000000000..f8f16f80d --- /dev/null +++ b/pr-1714/kubernetes.html @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + Continuous Delivery on Kubernetes with GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + +
+
+ +
+ +
+ +
+

CONTINUOUS DELIVERY
ON KUBERNETES WITH GoCD

+
+ +
+ +
+

GET STARTED NOW

+
+ + + +
+

GoCD HELM CHART

+
+ +
+
+ +
+
+
+

Visualize and Model
Complex Workflows

+

GoCD supports continuous delivery out of the box with its built-in pipelines, advanced traceability and value stream visualization. With GoCD, you can easily model, orchestrate and visualize complex workflows from end to end. GoCD supports modern infrastructure and cloud deployments.

+
+
+ GoCD Value Stream Map +
+
+ +
+
+ +
+
+
+
+

GoCD’s Native Integrations for Kubernetes

+

GoCD gives you the flexibility to effectively represent CD pipelines that model your organization’s processes. Kubernetes gives you a highly programmable delivery infrastructure platform. Together they provide the premiere continuous delivery tool on modern infrastructure.

+

With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly. The GoCD Kubernetes integration allows you to model Docker-based build workflows more effectively.

+
+
+
+
+ +
+
+ +
+
+ GoCD Value Stream Map +
+
+ +
+ +
+

Run GoCD Natively on Kubernetes

+
    +
  • GoCD Helm chart with official GoCD Docker images makes setup simple
    • +
  • GoCD installs as a Kubernetes native application allowing for ease of operations
    • +
  • Ease of maintenance with simple upgrade process using Helm
    • +
+
+ + +
+

Build Infrastructure Scales Elastically

+
    +
  • Introduces a new elastic agent for Kubernetes that dynamically scales GoCD agents
    • +
  • The elastic agent uses Kubernetes conventions to scale as needed
    • +
  • GoCD agents now support Docker in Docker, eliminating the need for specialized setup on agents
    • +
+
+ +
+

Model Deployments to Kubernetes

+
    +
  • Model deployments for your containerized applications to Kubernetes
    • +
  • First class integration with Docker registries
    • +
  • Compose, track, and visualize deployments on Kubernetes
    • +
+
+
+ +
+
+
+ +
+

Get Started with GoCD on Kubernetes

+
+ +
+

GET STARTED NOW

+
+ + +
+

GoCD HELM CHART

+
+ +
+
+ + +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/kubernetes/index.html b/pr-1714/kubernetes/index.html new file mode 100644 index 000000000..219145584 --- /dev/null +++ b/pr-1714/kubernetes/index.html @@ -0,0 +1,243 @@ + + + + + + + + + + + + + + + + Continuous Delivery on Kubernetes with GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ + +
+
+ +
+ +
+ +
+

CONTINUOUS DELIVERY
ON KUBERNETES WITH GoCD

+
+ +
+ +
+

GET STARTED NOW

+
+ + + +
+

GoCD HELM CHART

+
+ +
+
+ +
+
+
+

Visualize and Model
Complex Workflows

+

GoCD supports continuous delivery out of the box with its built-in pipelines, advanced traceability and value stream visualization. With GoCD, you can easily model, orchestrate and visualize complex workflows from end to end. GoCD supports modern infrastructure and cloud deployments.

+
+
+ GoCD Value Stream Map +
+
+ +
+
+ +
+
+
+
+

GoCD’s Native Integrations for Kubernetes

+

GoCD gives you the flexibility to effectively represent CD pipelines that model your organization’s processes. Kubernetes gives you a highly programmable delivery infrastructure platform. Together they provide the premiere continuous delivery tool on modern infrastructure.

+

With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly. The GoCD Kubernetes integration allows you to model Docker-based build workflows more effectively.

+
+
+
+
+ +
+
+ +
+
+ GoCD Value Stream Map +
+
+ +
+ +
+

Run GoCD Natively on Kubernetes

+
    +
  • GoCD Helm chart with official GoCD Docker images makes setup simple
    • +
  • GoCD installs as a Kubernetes native application allowing for ease of operations
    • +
  • Ease of maintenance with simple upgrade process using Helm
    • +
+
+ + +
+

Build Infrastructure Scales Elastically

+
    +
  • Introduces a new elastic agent for Kubernetes that dynamically scales GoCD agents
    • +
  • The elastic agent uses Kubernetes conventions to scale as needed
    • +
  • GoCD agents now support Docker in Docker, eliminating the need for specialized setup on agents
    • +
+
+ +
+

Model Deployments to Kubernetes

+
    +
  • Model deployments for your containerized applications to Kubernetes
    • +
  • First class integration with Docker registries
    • +
  • Compose, track, and visualize deployments on Kubernetes
    • +
+
+
+ +
+
+
+ +
+

Get Started with GoCD on Kubernetes

+
+ +
+

GET STARTED NOW

+
+ + +
+

GoCD HELM CHART

+
+ +
+
+ + +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/learn-more/why-go.html b/pr-1714/learn-more/why-go.html new file mode 100644 index 000000000..18d267c9d --- /dev/null +++ b/pr-1714/learn-more/why-go.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../why-gocd/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/learn-more/why-go/index.html b/pr-1714/learn-more/why-go/index.html new file mode 100644 index 000000000..618b443e0 --- /dev/null +++ b/pr-1714/learn-more/why-go/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../../why-gocd/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability.html b/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability.html new file mode 100644 index 000000000..e7bc9119d --- /dev/null +++ b/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability.html @@ -0,0 +1,161 @@ + + + + + + + + + + + + + + + + Script to generate patched go.jar for deserialization vulnerability + + + + + + + + + +
+
+ + + +
+ +
+ + +
+

The patches mentioned on the blog post about +the deserialization vulnerability were generated using this script, written by the GoCD Team. You can verify it yourself +and run it. The final checksums will not match because the process of zipping it will include timestamps.

+ +
#!/bin/bash
+
+backup_file="go.backup.$(date +%s).for-commons-collections-exploit.jar"
+log_file="go.jar.for-commons-collections-exploit.log"
+
+echo "Logs will be in: $log_file"
+exec >"$log_file" 2>&1
+
+set -x -e -o pipefail
+cd "$(dirname "$0")"
+
+cp go.jar "$backup_file"
+unzip -d go-jar go.jar
+
+(cd go-jar/defaultFiles/; unzip -d cruise-war cruise.war)
+zip -d go-jar/defaultFiles/cruise-war/WEB-INF/lib/commons-collections-3.1.jar \
+    org/apache/commons/collections/functors/InvokerTransformer.class
+(cd go-jar/defaultFiles/cruise-war; zip -f ../cruise.war WEB-INF/lib/commons-collections-3.1.jar)
+
+(cd go-jar/defaultFiles/; unzip -d agent-jar agent.jar)
+zip -d go-jar/defaultFiles/agent-jar/lib/commons-collections-3.2.jar \
+    org/apache/commons/collections/functors/InvokerTransformer.class
+(cd go-jar/defaultFiles/agent-jar; zip -f ../agent.jar lib/commons-collections-3.2.jar)
+
+(cd go-jar; zip -f ../go.jar defaultFiles/cruise.war)
+(cd go-jar; zip -f ../go.jar defaultFiles/agent.jar)
+
+rm -rf go-jar
+
+diff <(unzip -lv go.jar) <(unzip -lv "$backup_file") || true
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability/index.html b/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability/index.html new file mode 100644 index 000000000..885c5a79a --- /dev/null +++ b/pr-1714/misc/generate-patched-jar-for-deserialization-vulnerability/index.html @@ -0,0 +1,161 @@ + + + + + + + + + + + + + + + + Script to generate patched go.jar for deserialization vulnerability + + + + + + + + + +
+
+ + + +
+ +
+ + +
+

The patches mentioned on the blog post about +the deserialization vulnerability were generated using this script, written by the GoCD Team. You can verify it yourself +and run it. The final checksums will not match because the process of zipping it will include timestamps.

+ +
#!/bin/bash
+
+backup_file="go.backup.$(date +%s).for-commons-collections-exploit.jar"
+log_file="go.jar.for-commons-collections-exploit.log"
+
+echo "Logs will be in: $log_file"
+exec >"$log_file" 2>&1
+
+set -x -e -o pipefail
+cd "$(dirname "$0")"
+
+cp go.jar "$backup_file"
+unzip -d go-jar go.jar
+
+(cd go-jar/defaultFiles/; unzip -d cruise-war cruise.war)
+zip -d go-jar/defaultFiles/cruise-war/WEB-INF/lib/commons-collections-3.1.jar \
+    org/apache/commons/collections/functors/InvokerTransformer.class
+(cd go-jar/defaultFiles/cruise-war; zip -f ../cruise.war WEB-INF/lib/commons-collections-3.1.jar)
+
+(cd go-jar/defaultFiles/; unzip -d agent-jar agent.jar)
+zip -d go-jar/defaultFiles/agent-jar/lib/commons-collections-3.2.jar \
+    org/apache/commons/collections/functors/InvokerTransformer.class
+(cd go-jar/defaultFiles/agent-jar; zip -f ../agent.jar lib/commons-collections-3.2.jar)
+
+(cd go-jar; zip -f ../go.jar defaultFiles/cruise.war)
+(cd go-jar; zip -f ../go.jar defaultFiles/agent.jar)
+
+rm -rf go-jar
+
+diff <(unzip -lv go.jar) <(unzip -lv "$backup_file") || true
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/next-release.html b/pr-1714/next-release.html new file mode 100644 index 000000000..27aeb4e28 --- /dev/null +++ b/pr-1714/next-release.html @@ -0,0 +1,188 @@ + + + + + + + + + + + + + + + + Next release of GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+ +
+

+ This page contains the release notes for the next version of GoCD +

+ +
+
    +
  • (latest)
    • +
+ +
+

(next)

+
+
+

some feature

+ +

Some info abt the feature

+ +

Other Improvements

+ +

Bug fixes

+ +

API

+ +
    +
  • The API change log can be found here.
    • +
  • The Plugin API change log can be found here.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+
+
+ +
+
+ + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/next-release/index.html b/pr-1714/next-release/index.html new file mode 100644 index 000000000..206e25219 --- /dev/null +++ b/pr-1714/next-release/index.html @@ -0,0 +1,188 @@ + + + + + + + + + + + + + + + + Next release of GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+ +
+

+ This page contains the release notes for the next version of GoCD +

+ +
+
    +
  • (latest)
    • +
+ +
+

(next)

+
+
+

some feature

+ +

Some info abt the feature

+ +

Other Improvements

+ +

Bug fixes

+ +

API

+ +
    +
  • The API change log can be found here.
    • +
  • The Plugin API change log can be found here.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+
+
+ +
+
+ + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/partners.html b/pr-1714/partners.html new file mode 100644 index 000000000..9e4892b67 --- /dev/null +++ b/pr-1714/partners.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/partners/index.html b/pr-1714/partners/index.html new file mode 100644 index 000000000..9e5ceb085 --- /dev/null +++ b/pr-1714/partners/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/pipelines-as-code.html b/pr-1714/pipelines-as-code.html new file mode 100644 index 000000000..417790d8c --- /dev/null +++ b/pr-1714/pipelines-as-code.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Pipeline Configuration as Code + + + + + + + + + +
+
+ + + +
+ +
+ + + + +
+
+
+ GoCD plus Kubernetes +

Native Kubernetes Integration

+ +

+ GoCD gives you the flexibility to effectively represent CD pipelines that model your organization’s processes. + Kubernetes gives you a highly programmable delivery infrastructure platform. Together they provide the premiere + continuous delivery tool on modern infrastructure. +

+
+ +
+ illustration of elastic agents +

Elastic Agents

+ +

+ Elastic Agents, also known as on-demand agents, are the worker bees of GoCD. Scale them up and shut them down + as needed, giving you both flexibility and cost savings. We provide elastic agents for Docker, K8s, AWs and + other popular cloud providers. +

+
+ +
+ illustration of a cloud connected by wires +

Deployment Options

+ +

+ Deployment options exist for all the major cloud services, including Docker. With our official Docker images, + you can create GoCD workflows with ease and deploy +

+
+ +
+ illustration of a window in GoCD +

Modern Interface

+ +

+ GoCD’s dashboard improvements make it easy for large organizations to manage hundreds (or thousands) of + pipelines. You can personalize your dashboards with pipeline groups and create custom tabs for future use. +

+
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/pipelines-as-code/index.html b/pr-1714/pipelines-as-code/index.html new file mode 100644 index 000000000..0e3286631 --- /dev/null +++ b/pr-1714/pipelines-as-code/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Pipeline Configuration as Code + + + + + + + + + +
+
+ + + +
+ +
+ + + + +
+
+
+ GoCD plus Kubernetes +

Native Kubernetes Integration

+ +

+ GoCD gives you the flexibility to effectively represent CD pipelines that model your organization’s processes. + Kubernetes gives you a highly programmable delivery infrastructure platform. Together they provide the premiere + continuous delivery tool on modern infrastructure. +

+
+ +
+ illustration of elastic agents +

Elastic Agents

+ +

+ Elastic Agents, also known as on-demand agents, are the worker bees of GoCD. Scale them up and shut them down + as needed, giving you both flexibility and cost savings. We provide elastic agents for Docker, K8s, AWs and + other popular cloud providers. +

+
+ +
+ illustration of a cloud connected by wires +

Deployment Options

+ +

+ Deployment options exist for all the major cloud services, including Docker. With our official Docker images, + you can create GoCD workflows with ease and deploy +

+
+ +
+ illustration of a window in GoCD +

Modern Interface

+ +

+ GoCD’s dashboard improvements make it easy for large organizations to manage hundreds (or thousands) of + pipelines. You can personalize your dashboards with pipeline groups and create custom tabs for future use. +

+
+
+ +
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/plugins.html b/pr-1714/plugins.html new file mode 100644 index 000000000..464a08a3e --- /dev/null +++ b/pr-1714/plugins.html @@ -0,0 +1,1883 @@ + + + + + + + + + + + + + + + + Supported Plugins | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Plugins

+
+
+ +
+
+
+
+

+ Below is a list of current plugins for GoCD. These include plugins contributed by the community (that are not + bundled with the GoCD Server). Please refer to the plugin user guide and the + plugin's own documentation to know more about plugin installation. +

+ +

+ If there is a plugin that you want but do not see, write your own using the GoCD Plugin API. If you are working on a plugin and would like + it to be included in this page, open a pull request. +

+
+
+ +

+ Plugins that were originally written by Thoughtworks, and are now maintained by the core GoCD Team are tagged with a GoCD logo icon. All others are community-written and could be unmaintained (tread carefully). +

+ +
+
    +
  • + Analytics plugins >= GoCD v18.1 +
    • +
  • + Artifact plugins >= GoCD v18.7 +
    • +
  • + Authorization plugins >= GoCD v17.5 +
    • +
  • + Configuration Repository >= GoCD v16.7 +
    • +
  • + Elastic agents plugins >= GoCD v16.8 +
    • +
  • + Notification plugins +
    • +
  • + Package repository plugins >= GoCD v13.3 +
    • +
  • + SCM plugins +
    • +
  • + Secrets plugins >= GoCD v19.6 +
    • +
  • + Task plugins >= GoCD v14.1 +
    • +
+ +
+

+ Analytics plugins >= GoCD v18.1 +

+ +
+
+ +
+
+

+ Artifact plugins >= GoCD v18.7 +

+ +
+
+
    + +
  • + +
    + +
    Docker Registry Artifact Plugin
    +

    + The docker registry artifact plugin provides a way to push and pull docker images on GoCD + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    S3 Artifact Plugin
    +

    + The S3 artifact plugin provides a way to publish and fetch artifacts to/from AWS S3 + Read more +

    + by + Diogo Oliveira + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Authorization plugins >= GoCD v17.5 +

+ +
+
+
    + +
  • + +
    + +
    File based plugin
    +

    + Bundled plugin to support password file based authentication. + Read more +

    + by + Thoughtworks Inc. + +
    +
    + Bundled with GoCD +
    +
    • +
  • + +
    + +
    LDAP/AD Authentication plugin
    +

    + Bundled plugin to support LDAP/AD authentication. + Read more +

    + by + Thoughtworks Inc. + +
    +
    + Bundled with GoCD +
    +
    • +
  • + +
    + +
    LDAP/AD Authorization Plugin
    +

    + Extends the bundled GoCD LDAP/AD Plugin to provide both authentication and authorization, allowing mapping of users from LDAP/AD groups to GoCD roles. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitHub OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using GitHub or GitHub Enterprise. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Google OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using a Google account. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Google IAP header authorization plugin
    +

    + Allows users to login in GoCD using Google IAP headers + Read more +

    + by + Sentry + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Okta OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using an Okta account. + Read more +

    + by + Svetlin Zamfirov + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitLab OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using GitLab or GitLab Enterprise. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Guest Login Authentication plugin
    +

    + The plugin allows user to login in GoCD as a guest user + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Keycloak OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using an Keycloak account. + Read more +

    + by + Kleber Rocha + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Configuration Repository >= GoCD v16.7 +

+ +
+
+
    + +
  • + +
    + +
    gocd-json-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in JSON. + Read more +

    + by + Tomasz Setkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-yaml-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in YAML. + Read more +

    + by + Tomasz Setkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-groovy-dsl-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in Groovy. + Read more +

    + by + Ketan Padegaonkar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-jsonnet-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in Jsonnet. + Read more +

    + by + Sentry + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Elastic agents plugins >= GoCD v16.8 +

+ +
+
+
    + +
  • + +
    + +
    ECS Elastic Agent
    +

    + GoCD Elastic Agent Plugin for Amazon Elastic Container Service + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Microsoft Azure Elastic Agent
    +

    + GoCD Elastic Agent Plugin for bringing up GoCD agents on Microsoft Azure virtual machines. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Docker
    +

    + GoCD Elastic agent plugin for Docker + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Docker Swarm
    +

    + GoCD Elastic agent plugin for Docker Swarm + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic Agent plugin for Kubernetes
    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic Agent plugin for OpenStack
    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents within OpenStack + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Marathon
    +

    + GoCD Elastic agent plugin for Marathon + Read more +

    + by + Piksel, Ltd. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for AWS EC2
    +

    + GoCD Elastic agent plugin for AWS EC2 + Read more +

    + by + Continuum Security, S.L. + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Notification plugins +

+ +
+
+
    + +
  • + +
    + +
    AWS SNS Notifier
    +

    + Plugin that sends build notifications to AWS SNS (Simple Notification Service) + Read more +

    + by + Paul Lalonde + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Email Notifier
    +

    + A plugin to send email notifications. + Read more +

    + by + Srinivas Upadhy + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Slack Build Notifier
    +

    + Plugin to get build notifications on Slack. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitHub Pull Request Status Notifier
    +

    + A plugin to update GitHub Pull Requests with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Stash Pull Request Status Notifier
    +

    + A plugin to update Stash Pull Requests with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Gerrit Change Set Status Notifier
    +

    + A plugin to update Gerrit Change Sets with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Riemann Notification
    +

    + Plugin that sends Riemann notifications on build status + Read more +

    + by + Robin Ridler + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Spark Build Notifier
    +

    + Plugin to get build notifications on Cisco Spark. + Read more +

    + by + Nathan Glover + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    MicroFocus ALM Octane GoCD CI Plugin
    +

    + This plugin integrates GoCD with MicroFocus ALM Octane, enabling ALM Octane to display GoCD pipelines, trigger pipeline runs, and track build and test run results, as well as committed changes. + Read more +

    + by + MicroFocus + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Rocket.Chat Build Notifier
    +

    + Notification plugin which sends build failures to RocketChat + Read more +

    + by + Tomasz Sętkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GChat Notifier plugin
    +

    + Sends GChat messages on specific pipeline stage state changes via webhook. + Read more +

    + by + IONOS SE + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Package repository plugins >= GoCD v13.3 +

+ +
+
+ +
+
+

+ SCM plugins +

+ +
+
+
    + +
  • + +
    + +
    Git Path Material
    +

    + Plugin that watches sub-directories/sub-paths of Git repositories, better supporting monorepos. + Read more +

    + by + Thoughtworks Opensource + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Git Feature Branches
    +

    + Plugin that builds feature branches from Git repositories. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Github Pull Requests
    +

    + Plugin that builds Pull Requests for project from Github. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Stash Pull Requests
    +

    + Plugin that builds Pull Requests for project from Stash. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Gerrit Change Set
    +

    + Plugin that builds Change Sets for project from Gerrit. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build BitKeeper Pull Requests
    +

    + Plugin that polls a BitKeeper repository for pull requests and triggers a build for each of them. + Read more +

    + by + Bhupendrakumar Piprava + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Artifactory SCM
    +

    + Plugin that lets you download several versions of an artifact from Artifactory. + Read more +

    + by + Christoph Nenning + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    FTP Server SCM
    +

    + Plugin that downloads the source codes/files from FTP Server from a configured directory path. + Read more +

    + by + Sekhar Rangam + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Secrets plugins >= GoCD v19.6 +

+ +
+
+
    + +
  • + +
    + +
    GoCD file based Secrets Plugin
    +

    + Bundled plugin which allows secrets to be stored/retrived from an external file. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Secrets Plugin for Vault
    +

    + GoCD Secrets Plugin which uses Vault as the secret manager. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    AWS Secrets Manager plugin for GoCD
    +

    + This is a GoCD Secrets Plugin which allows users to use AWS Secrets Manager as a secret manager for GoCD. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Kubernetes based Secrets Plugin
    +

    + This is a GoCD Secrets Plugin which allows users to use Kubernetes Secrets as a secret manager for GoCD. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Task plugins >= GoCD v14.1 +

+ +
+
+
    + +
  • + +
    + +
    Powershell Task
    +

    + Task to run Powershell based builds. + Read more +

    + by + Manoj Mahalingam + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Script Executor Task Plugin
    +

    + Simple plugin to allow running scripts in GoCD (with syntactic sugar support for config repositories) + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Publish to S3
    +

    + Task plugin to publish artifacts to Amazon S3 + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Fetch from S3
    +

    + Task plugin to fetch artifacts from Amazon S3 + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Docker task
    +

    + Task plugin to build an image, run commands against it, and push to a registry. Each step is optional. + Read more +

    + by + Manoj Mahalingam + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Gradle Task plugin
    +

    + Task plugin for running Gradle builds + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Health Check Task plugin
    +

    + Task plugin for delaying the build till the application becomes healthy + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    SBT Task plugin
    +

    + Task plugin for running SBT builds + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Slack Task plugin
    +

    + Send custom messages to Slack from Go CD jobs + Read more +

    + by + Juha Siponen + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Scalastyle Github Pull Request plugin
    +

    + Comments on Github pull requests with a summary of scalastyle results + Read more +

    + by + Jenny Beckett + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Artifactory Plugin
    +

    + Uploads Artifacts to JFrog Artifactory + Read more +

    + by + EAIESB + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Diawi Uploader Plugin
    +

    + Publish artifacts to https://www.diawi.com/ + Read more +

    + by + + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Dunner - Docker Task Runner Plugin
    +

    + Execute tasks inside Docker using Dunner, the docker task runner. + Read more +

    + by + LeopardsLab Community + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    CMake
    +

    + Build cmake based projects. + Read more +

    + by + Joel Bodenmann + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    MLFlow repository poller & fetcher
    +

    + Plugin to poll and fetch models from MLFlow as a model repository + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+
+
+ +
+
+

+ Note: Plugins for GoCD are distributed under license from the copyright holder. In addition, + notwithstanding who the copyright holder is, all plugins on this page are made available for download "as is + and as available" without support or warranties of any kind, either express or implied, including but not + limited to the implied warranties of merchantability, satisfactory quality, and fitness for a particular + purpose. +

+
+
+
+
+ + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/plugins/index.html b/pr-1714/plugins/index.html new file mode 100644 index 000000000..76115851d --- /dev/null +++ b/pr-1714/plugins/index.html @@ -0,0 +1,1883 @@ + + + + + + + + + + + + + + + + Supported Plugins | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Plugins

+
+
+ +
+
+
+
+

+ Below is a list of current plugins for GoCD. These include plugins contributed by the community (that are not + bundled with the GoCD Server). Please refer to the plugin user guide and the + plugin's own documentation to know more about plugin installation. +

+ +

+ If there is a plugin that you want but do not see, write your own using the GoCD Plugin API. If you are working on a plugin and would like + it to be included in this page, open a pull request. +

+
+
+ +

+ Plugins that were originally written by Thoughtworks, and are now maintained by the core GoCD Team are tagged with a GoCD logo icon. All others are community-written and could be unmaintained (tread carefully). +

+ +
+
    +
  • + Analytics plugins >= GoCD v18.1 +
    • +
  • + Artifact plugins >= GoCD v18.7 +
    • +
  • + Authorization plugins >= GoCD v17.5 +
    • +
  • + Configuration Repository >= GoCD v16.7 +
    • +
  • + Elastic agents plugins >= GoCD v16.8 +
    • +
  • + Notification plugins +
    • +
  • + Package repository plugins >= GoCD v13.3 +
    • +
  • + SCM plugins +
    • +
  • + Secrets plugins >= GoCD v19.6 +
    • +
  • + Task plugins >= GoCD v14.1 +
    • +
+ +
+

+ Analytics plugins >= GoCD v18.1 +

+ +
+
+ +
+
+

+ Artifact plugins >= GoCD v18.7 +

+ +
+
+
    + +
  • + +
    + +
    Docker Registry Artifact Plugin
    +

    + The docker registry artifact plugin provides a way to push and pull docker images on GoCD + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    S3 Artifact Plugin
    +

    + The S3 artifact plugin provides a way to publish and fetch artifacts to/from AWS S3 + Read more +

    + by + Diogo Oliveira + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Authorization plugins >= GoCD v17.5 +

+ +
+
+
    + +
  • + +
    + +
    File based plugin
    +

    + Bundled plugin to support password file based authentication. + Read more +

    + by + Thoughtworks Inc. + +
    +
    + Bundled with GoCD +
    +
    • +
  • + +
    + +
    LDAP/AD Authentication plugin
    +

    + Bundled plugin to support LDAP/AD authentication. + Read more +

    + by + Thoughtworks Inc. + +
    +
    + Bundled with GoCD +
    +
    • +
  • + +
    + +
    LDAP/AD Authorization Plugin
    +

    + Extends the bundled GoCD LDAP/AD Plugin to provide both authentication and authorization, allowing mapping of users from LDAP/AD groups to GoCD roles. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitHub OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using GitHub or GitHub Enterprise. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Google OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using a Google account. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Google IAP header authorization plugin
    +

    + Allows users to login in GoCD using Google IAP headers + Read more +

    + by + Sentry + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Okta OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using an Okta account. + Read more +

    + by + Svetlin Zamfirov + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitLab OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using GitLab or GitLab Enterprise. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Guest Login Authentication plugin
    +

    + The plugin allows user to login in GoCD as a guest user + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Keycloak OAuth authorization plugin
    +

    + The plugin allows user to login in GoCD using an Keycloak account. + Read more +

    + by + Kleber Rocha + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Configuration Repository >= GoCD v16.7 +

+ +
+
+
    + +
  • + +
    + +
    gocd-json-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in JSON. + Read more +

    + by + Tomasz Setkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-yaml-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in YAML. + Read more +

    + by + Tomasz Setkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-groovy-dsl-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in Groovy. + Read more +

    + by + Ketan Padegaonkar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    gocd-jsonnet-config-plugin
    +

    + A plugin to keep pipelines and environments configuration in source-control in Jsonnet. + Read more +

    + by + Sentry + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Elastic agents plugins >= GoCD v16.8 +

+ +
+
+
    + +
  • + +
    + +
    ECS Elastic Agent
    +

    + GoCD Elastic Agent Plugin for Amazon Elastic Container Service + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Microsoft Azure Elastic Agent
    +

    + GoCD Elastic Agent Plugin for bringing up GoCD agents on Microsoft Azure virtual machines. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Docker
    +

    + GoCD Elastic agent plugin for Docker + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Docker Swarm
    +

    + GoCD Elastic agent plugin for Docker Swarm + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic Agent plugin for Kubernetes
    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents on a Kubernetes cluster on demand. + Read more +

    + by + Thoughtworks Inc. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic Agent plugin for OpenStack
    +

    + GoCD Elastic Agent plugin for bringing up GoCD agents within OpenStack + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for Marathon
    +

    + GoCD Elastic agent plugin for Marathon + Read more +

    + by + Piksel, Ltd. + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Elastic agent plugin for AWS EC2
    +

    + GoCD Elastic agent plugin for AWS EC2 + Read more +

    + by + Continuum Security, S.L. + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Notification plugins +

+ +
+
+
    + +
  • + +
    + +
    AWS SNS Notifier
    +

    + Plugin that sends build notifications to AWS SNS (Simple Notification Service) + Read more +

    + by + Paul Lalonde + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Email Notifier
    +

    + A plugin to send email notifications. + Read more +

    + by + Srinivas Upadhy + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Slack Build Notifier
    +

    + Plugin to get build notifications on Slack. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GitHub Pull Request Status Notifier
    +

    + A plugin to update GitHub Pull Requests with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Stash Pull Request Status Notifier
    +

    + A plugin to update Stash Pull Requests with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Gerrit Change Set Status Notifier
    +

    + A plugin to update Gerrit Change Sets with build status. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Riemann Notification
    +

    + Plugin that sends Riemann notifications on build status + Read more +

    + by + Robin Ridler + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Spark Build Notifier
    +

    + Plugin to get build notifications on Cisco Spark. + Read more +

    + by + Nathan Glover + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    MicroFocus ALM Octane GoCD CI Plugin
    +

    + This plugin integrates GoCD with MicroFocus ALM Octane, enabling ALM Octane to display GoCD pipelines, trigger pipeline runs, and track build and test run results, as well as committed changes. + Read more +

    + by + MicroFocus + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Rocket.Chat Build Notifier
    +

    + Notification plugin which sends build failures to RocketChat + Read more +

    + by + Tomasz Sętkowski + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GChat Notifier plugin
    +

    + Sends GChat messages on specific pipeline stage state changes via webhook. + Read more +

    + by + IONOS SE + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Package repository plugins >= GoCD v13.3 +

+ +
+
+ +
+
+

+ SCM plugins +

+ +
+
+
    + +
  • + +
    + +
    Git Path Material
    +

    + Plugin that watches sub-directories/sub-paths of Git repositories, better supporting monorepos. + Read more +

    + by + Thoughtworks Opensource + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Git Feature Branches
    +

    + Plugin that builds feature branches from Git repositories. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Github Pull Requests
    +

    + Plugin that builds Pull Requests for project from Github. + Read more +

    + by + Ashwanth Kumar + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Stash Pull Requests
    +

    + Plugin that builds Pull Requests for project from Stash. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build Gerrit Change Set
    +

    + Plugin that builds Change Sets for project from Gerrit. + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Build BitKeeper Pull Requests
    +

    + Plugin that polls a BitKeeper repository for pull requests and triggers a build for each of them. + Read more +

    + by + Bhupendrakumar Piprava + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Artifactory SCM
    +

    + Plugin that lets you download several versions of an artifact from Artifactory. + Read more +

    + by + Christoph Nenning + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    FTP Server SCM
    +

    + Plugin that downloads the source codes/files from FTP Server from a configured directory path. + Read more +

    + by + Sekhar Rangam + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Secrets plugins >= GoCD v19.6 +

+ +
+
+
    + +
  • + +
    + +
    GoCD file based Secrets Plugin
    +

    + Bundled plugin which allows secrets to be stored/retrived from an external file. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Secrets Plugin for Vault
    +

    + GoCD Secrets Plugin which uses Vault as the secret manager. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    AWS Secrets Manager plugin for GoCD
    +

    + This is a GoCD Secrets Plugin which allows users to use AWS Secrets Manager as a secret manager for GoCD. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    GoCD Kubernetes based Secrets Plugin
    +

    + This is a GoCD Secrets Plugin which allows users to use Kubernetes Secrets as a secret manager for GoCD. + Read more +

    + by + GoCD Contributors + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+

+ Task plugins >= GoCD v14.1 +

+ +
+
+
    + +
  • + +
    + +
    Powershell Task
    +

    + Task to run Powershell based builds. + Read more +

    + by + Manoj Mahalingam + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Script Executor Task Plugin
    +

    + Simple plugin to allow running scripts in GoCD (with syntactic sugar support for config repositories) + Read more +

    + by + Srinivas Upadhya + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Publish to S3
    +

    + Task plugin to publish artifacts to Amazon S3 + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Fetch from S3
    +

    + Task plugin to fetch artifacts from Amazon S3 + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Docker task
    +

    + Task plugin to build an image, run commands against it, and push to a registry. Each step is optional. + Read more +

    + by + Manoj Mahalingam + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Gradle Task plugin
    +

    + Task plugin for running Gradle builds + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Health Check Task plugin
    +

    + Task plugin for delaying the build till the application becomes healthy + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    SBT Task plugin
    +

    + Task plugin for running SBT builds + Read more +

    + by + jmnarloch + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Slack Task plugin
    +

    + Send custom messages to Slack from Go CD jobs + Read more +

    + by + Juha Siponen + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Scalastyle Github Pull Request plugin
    +

    + Comments on Github pull requests with a summary of scalastyle results + Read more +

    + by + Jenny Beckett + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Artifactory Plugin
    +

    + Uploads Artifacts to JFrog Artifactory + Read more +

    + by + EAIESB + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Diawi Uploader Plugin
    +

    + Publish artifacts to https://www.diawi.com/ + Read more +

    + by + + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    Dunner - Docker Task Runner Plugin
    +

    + Execute tasks inside Docker using Dunner, the docker task runner. + Read more +

    + by + LeopardsLab Community + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    CMake
    +

    + Build cmake based projects. + Read more +

    + by + Joel Bodenmann + +
    +
    +
    + + Download +
    +
    +
    • +
  • + +
    + +
    MLFlow repository poller & fetcher
    +

    + Plugin to poll and fetch models from MLFlow as a model repository + Read more +

    + by + Indix + +
    +
    +
    + + Download +
    +
    +
    • + +
  • +
    + + +
    Want to contribute?
    + Write a plugin +
    +
    • +
+
+
+
+
+ +
+
+

+ Note: Plugins for GoCD are distributed under license from the copyright holder. In addition, + notwithstanding who the copyright holder is, all plugins on this page are made available for download "as is + and as available" without support or warranties of any kind, either express or implied, including but not + limited to the implied warranties of merchantability, satisfactory quality, and fitness for a particular + purpose. +

+
+
+
+
+ + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/podcastinit.html b/pr-1714/podcastinit.html new file mode 100644 index 000000000..35db181b6 --- /dev/null +++ b/pr-1714/podcastinit.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=podcastinit_2017&utm_medium=podcast&utm_source=podcast_audio&utm_content=go_website&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/podcastinit/index.html b/pr-1714/podcastinit/index.html new file mode 100644 index 000000000..a0b91cf30 --- /dev/null +++ b/pr-1714/podcastinit/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=podcastinit_2017&utm_medium=podcast&utm_source=podcast_audio&utm_content=go_website&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/recode.html b/pr-1714/recode.html new file mode 100644 index 000000000..3569acedb --- /dev/null +++ b/pr-1714/recode.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=recode_podcast_q1_2017&utm_medium=podcast_recode&utm_source=podcast_recode&utm_content=go_cd&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/recode/index.html b/pr-1714/recode/index.html new file mode 100644 index 000000000..c00c23c74 --- /dev/null +++ b/pr-1714/recode/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=recode_podcast_q1_2017&utm_medium=podcast_recode&utm_source=podcast_recode&utm_content=go_cd&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/releases.html b/pr-1714/releases.html new file mode 100644 index 000000000..f125b8a16 --- /dev/null +++ b/pr-1714/releases.html @@ -0,0 +1,6929 @@ + + + + + + + + + + + + + + + + Releases - Version notes | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+ +
+

+ Check out "Enhancements" and "Bug fixes" for specific versions of GoCD below. As always, feel free to tell us what you think, or file a bug on GitHub. +

+

+ We try our best to credit all contributors. Apologies if we miss you out. Let us know and we will change this. + Thanks to everyone for contributing patches, feature requests, reporting issues and participating in various discussions. +

+ + +
+
    +
  • 24.3.0 (latest)
    • +
  • 24.2.0
    • +
  • 24.1.0
    • +
  • 23.5.0
    • +
  • 23.4.0
    • +
  • 23.3.0
    • +
  • 23.2.0
    • +
  • 23.1.0
    • +
  • 22.3.0
    • +
  • 22.2.0
    • +
  • 22.1.0
    • +
  • 21.4.0
    • +
  • 21.3.0
    • +
  • 21.2.0
    • +
  • 21.1.0
    • +
  • 20.10.0
    • +
  • 20.9.0
    • +
  • 20.8.0
    • +
  • 20.7.0
    • +
  • 20.6.0
    • +
  • 20.5.0
    • +
  • 20.4.0
    • +
  • 20.3.0
    • +
  • 20.2.0
    • +
  • 20.1.0
    • +
  • 19.12.0
    • +
  • 19.11.0
    • +
  • 19.10.0
    • +
  • 19.9.0
    • +
  • 19.8.0
    • +
  • 19.7.0
    • +
  • 19.6.0
    • +
  • 19.5.0
    • +
  • 19.4.0
    • +
  • 19.3.0
    • +
  • 19.2.0
    • +
  • 19.1.0
    • +
  • 18.12.0
    • +
  • 18.11.0
    • +
  • 18.10.0
    • +
  • 18.9.0
    • +
  • 18.8.0
    • +
  • 18.7.0
    • +
  • 18.6.0
    • +
  • 18.5.0
    • +
  • 18.4.0
    • +
  • 18.3.0
    • +
  • 18.2.0
    • +
  • 18.1.0
    • +
  • 17.12.0
    • +
  • 17.11.0
    • +
  • 17.10.0
    • +
  • 17.9.0
    • +
  • 17.8.0
    • +
  • 17.7.0
    • +
  • 17.6.0
    • +
  • 17.5.0
    • +
  • 17.4.0
    • +
  • 17.3.0
    • +
  • 17.2.0
    • +
  • 17.1.0
    • +
  • 16.12.0
    • +
  • 16.11.0
    • +
  • 16.10.0
    • +
  • 16.9.0
    • +
  • 16.8.0
    • +
  • 16.7.0
    • +
  • 16.6.0
    • +
  • 16.5.0
    • +
  • 16.4.0
    • +
  • 16.3.0
    • +
  • 16.2.1
    • +
  • 16.2.0
    • +
  • 16.1.0
    • +
  • 15.3.1
    • +
  • 15.3.0
    • +
  • 15.2.0
    • +
  • 15.1.0
    • +
  • 14.4.0
    • +
  • 14.3.0
    • +
  • 14.2.0
    • +
  • 14.1.0
    • +
+ +
+

24.3.0 (latest)

+
+
+

This release is a minor maintenance and bug-fix release.

+ +

Enhancements

+ +
    +
  • #12953 - Bundle latest Java 21.0.4 release with non-Linux installers & containers
    • +
+ +

Bug fixes

+ +
    +
  • #12943 - Show password button not working properly while creating new config repo
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.3.0 and + Plugin API changelog for 24.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, ysf465639310

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

24.2.0

+
+
+

This release is a maintenance and bug-fix release.

+ +

Java 21 support

+ +

GoCD is now built with, tested against and distributed with Java 21 LTS. Java 17 remains the minimum supported version +for bring-your-own-JRE setups. There were no specific changes needed to support Java 21, so the prior release 24.1.0 +can be considered the first version that supports Java 21.

+ +

Windows installers no longer signed

+ +

Windows installers were previously code-signed with a "proper" Thoughtworks-issued OV code-signing certificate from +DigiCert that avoided Windows SmartScreen prompts. Due to both certificate cost and changes in requirements for OV +code-signing certificates (to have hardware-managed keys), in the short term this is no longer sustainable for GoCD. +Therefore installers are not be signed from 24.2.0 onwards.

+ +

GoCD can still be installed on Windows subsequent to this change, however users will need to review and accept +warnings from Windows during installation. Note that runtime binaries are still signed as before, such as the Java +runtime and service wrapper binaries; so this change only affects installation - not runtime.

+ +

If you have a suggestion of approach to reinstate Windows code signing for a open-source project with limited funding, +or know other projects which have done so, please reach out!

+ +

Enhancements

+ +
    +
  • #12762 - Build, test and package GoCD with Java 21 LTS by default
    • +
  • #12792 - Make JRE dependencies from RPM and Debian packages optional/recommended
    • +
  • #12761, #12828 - Add AlmaLinux 9 based GoCD agent image to replace CentOS Stream
    • +
  • Starting this release, AlmaLinux based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #12765 - Tasks on gocd-agent-docker-dind:v24.1.0 image cannot interact with Docket socket by default
    • +
+ +

Security fixes

+ +

While we don't regularly release new GoCD versions to address container image dependencies, this release patches git +binaries within container images due to CVE-2024-32002 +and several other issues of particular concern to a build/deploy automation tool such as GoCD. You can read more about +the issues on the GitHub Blog. Note that +at time of release, Debian images have not had the most critical patch backported +to Debian 11 or 12, so the gocd-agent-debian variants for 24.2.0 are still vulnerable. Ubuntu variants are all patched +as are Alpine and Wolfi variants.

+ +

We regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.2.0 and + Plugin API changelog for 24.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, K. S. Ernest (iFire) Lee, Matthias Kraaz, Tewfik Ghariani, nichivo

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

24.1.0

+
+
+

This release is a maintenance and bug-fix release, although there are several potentially breaking changes to be aware of:

+ +
    +
  • Links are no longer force-opened in new tabs
    • +
  • Java 17 is now the minimum supported version
    • +
  • Server container image is now based on Wolfi OS
    • +
+ +

Links are no longer force-opened in new tabs

+ +

A long-standing frustration with GoCD's UI is that it used to open new tabs for links, partly to avoid losing your +place on the main dashboard when investigating an individual stage/job. However, browsers are now much better at remembering +the "back" state; and the previous behaviour was confusing & frustrating.

+ +

From now on control will be returned to users - for a new tab to be opened (foreground or background) in most cases +users will need to use the browser/OS specific key combination or middle-click equivalent to do so.

+ +

If you are interested in making this a configurable option to add back the old behaviour, +discussion or pull requests are welcome.

+ +

Java 17 is now the minimum supported version

+ +

Java 17 was released in September 2021, and has had complete support within GoCD since version 22.1.0, over 2 years ago. +Since then it has been packaged with both GoCD container images & installers by default.

+ +

This has proven to be be very stable, so to reduce maintenance overhead we are now making Java 17 the minimum supported +version.

+ +

If you are aiming for minimal agent/server downtime in an upgrade to GoCD 24.1.0+, you can do so by following:

+ +
    +
  1. Ensure your existing agents are running with Java 17+. +
      +
    • If your agents are using GoCD 22.1.0+ from official GoCD containers or packages (RPM, deb)s there is nothing extra to do. These already package and run Java 17+.
      • +
    • If your agents are using GoCD 22.1.0+ from other install approaches, they are already Java 17-compatible, if your server is 21.4.0+. Ensure they are running with Java 17+.
      • +
    +
    2. +
  2. Ensure your existing server is running with Java 17+. +
      +
    • If your server is using GoCD 22.1.0+ from official GoCD containers or packages (RPM, deb)s there is nothing extra to do. These already package and run Java 17+.
      • +
    • If your server is using GoCD 21.4.0+ from other install approaches, is is already Java 17-compatible, if your server is 21.4.0+. Ensure they are running with Java 17+.
      • +
    +
    3. +
  3. Upgrade your server to GoCD 24.1.0 without worry about Java issues. +
      +
    • Older agents running Java 17+ will re-start automatically against a GoCD 24.1.0 server.
      • +
    • You can now validate your installation and agents are working fine.
      • +
    +
    4. +
  4. (Optionally) You can now upgrade your agents to GoCD 24.1.0 whenever you choose. +
      +
    • Technically GoCD agent installs are only a "bootstrapper" which downloads the matching agent code from the server for +each release. It is wise to avoid too much discrepancy in versions to make upgrades (like this one!) easier, but it is +not critical.
      • +
    +
    5. +
+ +

If you have issues, downgrades back to 22.1.0+ should be fine - there have been no breaking database or configuration +changes within these versions. If you have any further queries/issues, please ask on GitHub Discussions or the Google Group.

+ +

Server container image is now based on Wolfi OS

+ +

The GoCD server container has always been based on a minimal Linux distribution, previously Alpine Linux, +but from 24.1.0 has been switched to Wolfi OS. Wolfi OS is a similarly minimal, +security-oriented (un)distro from the folks at Chainguard which is +optimized for supply-chain security - +and unlike the musl-based Alpine uses glibc, similar to most other distributions.

+ +

Unfortunately, the use of Alpine has always posed difficulties due to its musl libc base. Most of the time this is an +irrelevant detail to users, however it has posed issues for GoCD packaging of Java runtime environments & providing aarch64 +availability for a variety of reasons stemming from GoCD's dependencies. While GoCD has applied relatively stable +workarounds to support Alpine, these are not recommended and have prevented providing a default GoCD server container +image for aarch64/arm64 architectures off-the-shelf.

+ +

Wolfi uses the same apk package manager as Alpine, with conventional package names, and although packages cannot be +used across the two OSes, the transition should be easy for most folks. The image is now multi-architecture (amd64/x64 and aarch64/arm64) +making it usable out-of-the-box within arm64 cloud instances and Apple Silicon Macs.

+ +

If you build a child container from the gocd-server container, from 24.1.0 +you will need to review your Dockerfile to check that:

+ +
    +
  • any additional packages you need to install are available for Wolfi.
    • +
  • any pre-compiled binaries specifically compiled for musl should be switched to glibc variants
    • +
+ +

There has previously been a non-officially documented multi-arch server image based on CentOS Stream, +which was the only option on aarch64. This will be removed, as it is unnecessary now we have a glibc-based image. +If you were using this, please switch back to gocd/gocd-server rather than gocd/gocd-server-centos-*.

+ +

Agent container image changes

+ +
    +
  1. A Wolfi-based agent image is now available, matching the +server image. This will become the default recommended agent image for container-based elastic agents.
    2. +
  2. The Alpine agent images will now become a rolling distribution within the gocd-agent-alpine +repository. This means that the repository will not change for each Alpine release (3.18, 3.19 etc) any longer. Alpine releases new +versions each 6 months while maintaining very good compatibility, and maintaining different repositories added unnecessary +maintenance overhead. Each GoCD release will be based on the latest compatible Alpine release, mirroring how gocd-agent-docker-dind +has always been released. GoCD 23.5.0 will be the last version released under version specific repos (3.16, 3.17, 3.18, 3.19).
    3. +
  3. CentOS Stream 8 and 9 +based container images will be discontinued after 24.1.0. While these images are stable and well-maintained, they are +not as widely used other images, and as a distribution upstream of RHEL, Rocky, Alma etc, CentOS Stream has not +proved to get an appropriate level of security/maintenance patches for dependencies, nor the official security +bulletins needed for containers tools to accurate scan the images. If you are using these images, and would prefer a +Red Hat/RHEL-like image, please open an issue!. We are open to bring back an +Alma or Rocky-based image to meet the needs of those who want to keep their agent containers within the RHEL ecosystem.
    4. +
+ +

Windows installers no longer signed after 24.1.0

+ +

Windows installers were previously code-signed with a "proper" Thoughtworks-issued OV code-signing certificate from +DigiCert that avoided Windows SmartScreen prompts. Due to both certificate cost and changes in requirements for OV +code-signing certificates (to have hardware-managed keys), in the short term this is no longer sustainable for GoCD. +Therefore installers will likely not be signed from 24.2.0 onwards when the existing certificate expires.

+ +

GoCD can still be installed on Windows subsequent to this change, however users will need to review and accept +warnings from Windows during installation. Note that runtime binaries are still signed as before, such as the Java +runtime and service wrapper binaries; so this change only affects installation - not runtime.

+ +

If you have a suggestion of approach to reinstate Windows code signing for a open-source project with limited funding, +or know other projects which have done so, please reach out!

+ +

Enhancements

+ +
    +
  • #10520 - Change GoCD to no longer force links to open in new windows/tabs.
    • +
  • #12415 - Change baseline to require Java 17 minimum.
    • +
  • #12500 - Replace Alpine with Wolfi as primary server container image, consolidating Alpine agent images.
    • +
  • #12710 - Bundle latest Java 17.0.11 release with non-Linux installers & containers
    • +
  • #12712 - Add deb/rpm aarch64 support by replacing bundled x64 JRE with arch-independent package deps
    • +
  • Starting this release, Wolfi based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 24.04 (Noble Numbat) based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #4011 - RPM packages do not install on RHEL unless SELinux is disabled
    • +
  • #12440 - Installing Chromium on Alpine 3.18 gocd docker agent causes agent crash loop
    • +
  • #12535 - Improve performance of agents API responses and dashboard stage modal
    • +
  • #12616 - Improve performance when working with large numbers of server health warnings/errors
    • +
+ +

Security fixes

+ +

This release fixes CVE-2024-28866, a theoretical +vulnerability which has not shown to be practically exploitable. Thank you to Aviv Keller (RedYetiDev) for +discovering and responsibly disclosing this issue.

+ +

We regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.1.0 and + Plugin API changelog for 24.1.0.

+ +

Contributors

+ +

Aravind SV, Aviv Keller / RedYetiDev, Chad Wilson, Matthias Kraaz, Tim Borrowdale, brewpark

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.5.0

+
+
+

This release is a maintenance and bug-fix release.

+ +

Enhancements

+ +
    +
  • #12353 - Starting this release, Alpine 3.19 based container images for GoCD Agent are available.
    • +
  • #12353 - Build the default GoCD Server image on Alpine 3.19
    • +
  • #12212 - Make template selector dropdowns alphabetically sorted
    • +
+ +

Bug fixes

+ +
    +
  • #12220 - Console view toolbar not shown after scrolling on v23.4.0
    • +
  • #12305 - Unable to pick stage from Add Material menu in Chrome on MacOS Sonoma
    • +
  • #12389 - Fix disappearing second+ stages on VSM view after clicking a stage
    • +
  • #12392 - Correct display of "cancelled by" for stage runs other than that being viewed
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.5.0 and + Plugin API changelog for 23.5.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Chris Gillatt, Lewis Jales-Huggins

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.4.0

+
+
+

This release is mainly a maintenance and bug-fix release.

+ +

Jetty web server upgrade

+ +

GoCD relies internally upon the Eclipse Jetty web server, which was +upgraded from v9 to v10 in this release.

+ +

If you customise the configuration of the web server via config/jetty.xml or by overriding the Java system property +jetty.xml.file.name, note that any custom configuration will be overridden to ensure compatibility with the new version. +After upgrading, shut down your GoCD server and merge back your custom changes from a backup of your config directory +/ Jetty configuration. You can review the changes to jetty.xml here.

+ +

Enhancements

+ +
    +
  • #12120 - Bundle latest Java 17.0.9 release with non-Linux installers & containers
    • +
  • #12147 - Speed agent bootstrapping by reducing agent dependencies
    • +
  • #12051 - Remove subversion & mercurial from default container images
    • +
+ +

Bug fixes

+ +
    +
  • #11868, #11893 - Server config can have boolean attributes unintentionally toggled by server at GoCD startup
    • +
  • #11819 - Agent links from stage details jobs tab no longer work since 23.2.0
    • +
  • #11866 - GoCD 23.2/23.3 breaks agent mTLS connectivity when private key is encrypted/passphrase protected
    • +
  • #11969 - GoCD Agent on Java 20+ cant talk to server on Java 17
    • +
  • #12107 - Improve error logging during agent token acquisition failures
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

If you use GoCD container images, note that this release rebuilds GoCD images to include +fixes to curl CVE-2023-38545 across all supported platforms.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.4.0 and + Plugin API changelog for 23.4.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Mai-Khattab, Victor Sollerhed, jprogin, k-c-p

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.3.0

+
+
+

This release is a maintenance release to address a couple of unintended regressions in the 23.2.0 release.

+ +

Bug fixes

+ +
    +
  • #11790 - Stage History pagination links are broken on 23.2.0
    • +
  • #11783 - Build detail timestamp icon is missing on 23.2.0
    • +
  • #11797 - Some plugin config/report views have missing icons on 23.2.0
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.3.0 and + Plugin API changelog for 23.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.2.0

+
+
+
+ NOTE: An issue was discovered with 23.2.0 which prevents UI navigation via Stage History to older stage runs in + the history when you're already viewing the detail of an individual stage (Stage Details view). + + Please upgrade to 23.3.0 instead, which resolves this issue. +
+
+

This release is mainly a maintenance and bug-fix release.

+ +

Minor changes that may affect plugins

+ +

There have been some changes made to GoCD's UI dependencies to improve loading times which may unintentionally affect +certain plugins' views. If you notice a visual problem with a plugin view after +updating to 23.2.0, please update to the latest released version of the plugin, and if the issue persists please open an +issue on the plugin's GitHub repository.

+ +

A small number of third-party community-authored authorization plugins may no longer be compatible if they have not +been updated to declare compatibility with the 2.0 extension API +and still use the outdated extension version 1.0 deprecated in 2019. +All known popular plugins maintained by the community have been updated, so please update your plugins and open an issue +with the plugin author if you notice a plugin version compatibility error preventing the plugin from loading.

+ +

GoCD Agent DIND container image start-up is now more conservative

+ +

The GoCD agent "docker-in-docker" image +semantics were changed to ensure that the Docker daemon has started correctly before starting the +GoCD agent.

+ +

This aligns behavior with the upstream official docker:dind image +and resolves a race condition in #11378 that can cause docker-related tasks on GoCD agents to fail +due to improvements in GoCD agent work pick-up speed in recent releases.

+ +

Prior to GoCD 23.2.0, if the daemon failed to start the agent would continue to work without it. Docker commands within +tasks would fail, however the agent would continue. If you were accidentally relying on this behaviour (e.g due to running +the agent without the privileged flag, without the appropriate Kubernetes securityContext, or without +mounting the host's docker.sock into the container correctly), you will need to update your agent start +scripts or elastic agent profile to ensure the daemon has the correct container privileges, OR switch to a non-DIND +agent image such as a plain Alpine image.

+ +

Keep in mind that you only need to use a DIND agent image if you are relying on docker-in-docker or docker-out-of-docker +approaches to build or run nested or sibling containers within your agent host. If you want a drop-in replacement, we +recommend that you use an off-the-shelf GoCD Agent Alpine image, or if you need the Docker CLI (without daemon) +build your own custom child image, augmenting with apk add docker-cli or similar tooling.

+ +

Enhancements

+ +
    +
  • #11629, #11633 - Ability to store/retrieve session state within GoCD plugins to facilitate increased security OAuth2/OIDC
    • +
  • #11693 - Starting this release, Debian 12 / Bookworm based container images for GoCD Agent are available.
    • +
  • #11578 - Starting this release, Alpine 3.18 based container images for GoCD Agent are available.
    • +
  • #11578 - Build the default GoCD Server image on Alpine 3.18
    • +
  • #11405 - Reduce size/security attack surface of CentOS Stream 9 based container images (requires use of microdnf instead of dnf)
    • +
  • #11472, #11449, #11473, #11626, #11627, #11625 - Increase UI loading speed by reducing bundle size
    • +
  • #11535 - Improve pipeline config tab switch confirmation dialog message
    • +
  • #11663 - Improve user experience when managing Pluggable SCMs with Auto Update
    • +
  • #11664 - Improve error messages during config repo material validation
    • +
  • #11634 - Allow server wrapper-properties customisation within server container images
    • +
+ +

Bug fixes

+ +
    +
  • #11378, #11406 - gocd-agent-docker-dind:v23.1.0 image can sometimes fail docker tasks run after agent start
    • +
  • #11548 - go-agent 23.1.0 does not start when system tmp dir has a noexec mount
    • +
  • #11376 - Remove unnecessary bloat within CentOS 7 arm64 agent container image
    • +
  • #11544 - Pipeline config deep links from Pluggable SCMs and Elastic Agents don't work as expected
    • +
  • #11399 - GoCD Artifacts tab doesn't show artifacts whose name starts with a dot
    • +
  • #11773 - Fix import of nant_path from nant config repo tasks
    • +
  • #11772 - Fix export to config repo of fetch artifact tasks without pipeline name set
    • +
  • #11652 - Fix font display consistency across views
    • +
  • #2822 - Fix logging ERROR noise from url rewriting logic
    • +
  • #11513 - Remove misleading reporting of agent "creating properties" in console logs
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.2.0 and + Plugin API changelog for 23.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, FeltIP, James McNee, Jeroen Oortwijn, Ketan Padegaonkar, Marc Ende

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.1.0

+
+
+

Dashboard personalization enhancements

+ +

Personalized views allowing filters for failed or building stages now also allow inclusion of Cancelled or Paused pipelines.

+ +

Personalize Dashboard to show only cancelled or paused pipelines

+ +

Yum Repo Poller Plugin no longer bundled by default

+ +

Due to both its uncommon use and improvement of agent bootstrap speeds the Yum/RPM/DNF Repository Poller Plugin +is no longer bundled with GoCD from 23.1.0 onwards.

+ +

All plugins impose a marginal startup cost for the server and certain plugins also +to all agents. Since it is also currently difficult to override bundled plugins in some GoCD setups, the team have +decided to stop bundling this particular plugin.

+ +

If you rely upon this plugin, follow these upgrade steps:

+ +
    +
  1. download the latest version of the plugin from GitHub
    2. +
  2. install the plugin as an external plugin (see plugin user guide)
    3. +
  3. upgrade your server to 23.1.0
    4. +
+ +

You needn't worry about:

+ +
    +
  • Starting your old server version with the external plugin added. GoCD will ignore it, and prefer the bundled plugin until you upgrade.
    • +
  • Loss of configuration while starting your server on 23.1.0 before adding the plugin back. Your config will be retained, + however your server will not function correctly, and certain pipelines will not be editable until you restore the plugin + and restart your server, which you should do as soon as possible.
    • +
+ +

As always, we recommend that you take a backup before upgrading.

+ +

Other Enhancements

+ +
    +
  • #11341 - Starting this release, Ubuntu, Debian and CentOS based container images are built multi-platform for both amd64 and arm64/aarch64 (example)
    • +
  • #11053 - Starting this release, Alpine 3.17 based container images for GoCD Agent are available.
    • +
  • #11053 - Build the default GoCD Server image on Alpine 3.17
    • +
  • #8544 - Validate and enable GoCD server/agent install on Linux ARM / aarch64 system architecture
    • +
  • #11286 - Improve agent work pickup speed with an exponential rather than fixed 10s backoff
    • +
  • #11100 - Guard against out-of-memory errors when handling extremely long log lines from build task output
    • +
  • #11275, #11285 - Improve artifact upload speed with buffer tweaks
    • +
  • #11205 - Simplify & improve agent operating system complete name determination
    • +
  • #11295 - Improve agent logging to avoid confusing double-timestamps
    • +
  • #11048 - Improve logging of server output to assist with backup debugging
    • +
  • #11296 - Improve container logging to avoid cut-off lines due to log buffering
    • +
+ +

Bug fixes

+ +
    +
  • #266, #11159 - GoCD doesnt correctly parse minified JUnit XML produced by pytest
    • +
  • #4469, #11317 - Agent Error occurred during loop NullPointerException: Cannot invoke "org.apache.http.Header.getValue()" because "md5Header" is null
    • +
  • #11222 - Fix occasional issues with container start stalling or crashing due to process wrapper issues
    • +
  • #10669 - Dragging outside of the pipeline config web config dialogs can close the dialog without saving
    • +
  • #11004 - Dead docs link on dashboard personalization page
    • +
  • #11047 - Fix error messages on failure to launch DB backup process
    • +
  • #11070 - Fix build label handling on VSM and job detail pages
    • +
  • #11141 - Check server identity by default when talking SMTP over TLS
    • +
  • #11134 - Stage History API fails with DB error on MySQL 8
    • +
  • #11260 - Loading materials admin page creates syntax error on MySQL 8
    • +
+ +

Security fixes

+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by infoatb and CC Bomber, Kitri BoB (tunaf). +Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Additionally, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.1.0 and + Plugin API changelog for 23.1.0.

+ +

Contributors

+ +

Aravind SV, CC Bomber Kitri BoB (tunaf), Chad Wilson, Christian Butcher, Ketan Padegaonkar, Kim Sullivan, Sandro Heinzelmann, iantra, infoatb

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.3.0

+
+
+

Changes

+ +
    +
  • #10759 - Improve agent start-up time during agent-to-server version synchronization
    • +
  • #10924 - Bundle latest Java 17.0.5 patch release with non-Linux installers & containers
    • +
  • Starting this release, MacOS Apple Silicon (arm64/aarch64) installers and +test-drive experience are available.
    • +
  • Starting this release, CentOS Stream 9 based docker images for GoCD Server are available.
    • +
+ +

Bug fixes

+ +
    +
  • #8999 - Agents page layout has overlapping backgrounds on Chromium-based browsers
    • +
  • #10736 - GoCD 22.2.0 broke display of timestamps in plugin Elastic Agent Status Reports
    • +
  • #10837 - Job History sidebar dropdown does not display timestamps for previous job runs
    • +
  • #10891 - Build labels are truncated in pipeline activity page
    • +
  • #10937 - Support API logs a lot of noisy errors on Java 16+
    • +
  • #10943 - Fetch Artifact task doesn't provide correct suggestions when switching stages on pipeline config
    • +
  • #10982 - Fix Postgres backups via pg_dump on Windows
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

This release does upgrade a number of important internal components, some of which were EOL. We do not have evidence that +the previously vulnerable dependencies pose any specific risk in GoCD's usage, however we endeavour to minimise +dependency drift.

+ +

Since we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 22.3.0 and + Plugin API changelog for 22.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Chantry C, Jeroen Oortwijn, Ketan Padegaonkar, Lewis Jales-Huggins, pan Jacek

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.2.0

+
+
+

Changes

+ +
    +
  • #10613 - Bundle latest Java 17
    • +
  • #10518 - Build the default GoCD Server image on Alpine 3.16
    • +
  • Starting this release, Alpine 3.16 based docker images for GoCD Agent are available.
    • +
  • Starting this release, CentOS Stream 9 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 22.04 (Jammy Jellyfish) based docker images for GoCD Agent are available.
    • +
+ +

Security fixes

+ +

In this release, permissions were restricted further on Windows installer GoCD server & agent folders. Thank you to +s7331 for responsibly disclosing this issue.

+ +

Additionally, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

Bug fixes

+ +
    +
  • #4173 - On Windows, custom commands with spaces in path fail
    • +
  • #8986 - Git Material authentication fails for second user on the same repository
    • +
  • #9153 - Git Material credentials cannot be changed
    • +
  • #9509 - Unable to render VSM page when dependent pipelines are deleted or renamed
    • +
  • #9964 - Can't add user into a role (and other admin functions) behind CloudFlare minification proxy
    • +
  • #10036 - HTTP 500 when using external authorization plugins and GoCD site urls are blank
    • +
  • #10440 - Windows installer does not exit as intended on downgrade attempts
    • +
  • #10441 - Fix compatibility with JDK 11.0.15+ and 17.0.3+ during server configuration upgrades
    • +
  • #10555 - Misleading error message logged when agents have connectivity issues with GoCD Server
    • +
  • #10566 - Job Instance API does not return job state transitions as documented
    • +
  • #10610 - Custom tabs do not resize correctly to use window height as intended
    • +
  • #10648 - Plugin Admin page can display stale information after plugins are upgraded
    • +
  • #10668 - Fetch External (plugin) Artifact task gives generic Unprocessable Entity error for failing plugin validations
    • +
  • #10675 - Stage Details statistics graph page navigation broken on Chrome/Chromium
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 22.2.0 and Plugin API changelog for 22.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Christian Butcher, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Shakir Shakiel, s7331

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.1.0

+
+
+

Security fixes

+ +

This release has important security fixes and upgrades to a number of internal components.

+ +

This is an especially important upgrade due to two remote code execution vulnerabilities that could allow existing authenticated +users with malicious intent to trigger remote code execution on the GoCD Server, within

+ + + +

If you are unable to upgrade immediately, you can mitigate the high severity issues by

+ +
    +
  1. removing any authorization configurations for the bundled LDAP Authentication plugin +
      +
    • if LDAP login is required, consider migrating your configuration to a patched (v4.2.0-73+) version of the LDAP Authorization Plugin, which supports both authentication and (optional) authorization
      • +
    +
    2. +
  2. uninstalling the hg/Mercurial binary from the underlying GoCD Server operating system or Docker image
    3. +
+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by Alessio Della Libera (of the Snyk Security Team), +Alexey Solovyev (solev9ev) and SuperXX (Xiao Xiong). Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Java 17 support

+ +

This release includes compatibility changes within the GoCD Server to support Java 17.

+ +

Java 16+ includes a number of restrictions on access to Java Runtime internals that required either GoCD changes or +specific "opt-outs" to be included in GoCD server's start-up arguments. Currently, there are no opt-outs known +to be required on GoCD agents.

+ +

If you use the regular GoCD start-up scripts, and/or the packaged Java Runtime Environments with our installers and/or +Docker images, there is nothing extra you should need to do to run with Java 16+. +
+

+ +
Plugin compatibility with Java 17
+

GoCD has many plugins and while we have sanity checked many, it is not practical for us to test every plugin. +Plugins are also constrained by these Java Runtime restrictions, and if they either rely on access to Java Runtime +internals or use libraries that do so, they may experience issues.

+ +

If you experience issues with a plugin, or GoCD Server or a GoCD Agent

+ +
    +
  • try working around the issue by following this guide
    • +
  • please report the issue, including a full stack trace from the logs +
      +
    • for plugin issues, on the relevant plugin's GitHub repository (these are linked from the Author of each plugin in Admin -> Plugins)
      • +
    • for GoCD Server/Agent issues, on our GitHub issues
      • +
    +
    • +
  • if you are not sure if a plugin or GoCD is at fault, feel free to start a discussion in our GitHub discussions +or via the GoCD Google Group
    • +
+ +

Changes

+ +
    +
  • #9818 - Upgrade GoCD to run and build with Java 17
    • +
  • #10025 - Build the default GoCD Server image on Alpine 3.15
    • +
  • #10153 - Drop source/target compatibility back to Java 11 LTS
    • +
  • #10071 - Support Bitbucket push webhooks that contain multiple changes
    • +
+ +

Bug fixes

+ +
    +
  • #9002 - Cannot input multiple lines for Perforce material view
    • +
  • #9927 - Clean working directory sometimes fails on POSIX file systems with GoCD 21.3
    • +
  • #10086 - GoCD Server fails to start when commit GPG signing is enabled at system/user level
    • +
  • #10169 - Correct message displayed when agents are stuck cancelling jobs
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 22.1.0 and Plugin API changelog for 22.1.0.

+ +

Contributors

+ +

Alessio Della Libera (of the Snyk Security Team), Alexey Solovyev (solev9ev), Aravind SV, Chad Wilson, Ganesh S Patil, Jeroen Oortwijn, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Sandro Heinzelmann, SuperXX (Xiao Xiong)

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.4.0

+
+
+

Preparation for Java 17

+ +

This release focuses on internal changes, dependency upgrades and build/test automation changes required for GoCD to support Java 17. Since Java 17 is a long-term-support (LTS) release and Java 16 is now end-of-life, we intend to skip specific validation against Java 16.

+ +

While we are not quite ready, most required changes are part of the 21.4.0 release, so we expect experimental builds to be made available soon in preparation for a subsequent release.

+ +

Security Fixes

+ +

This release improves GoCD's security posture further by

+ +
    +
  • correcting a reflected XSS issue on API error responses. Thank you to dmxjon (aka DiMaX) for responsibly disclosing this issue.
    • +
  • upgrading a number of internal components, some of which have known vulnerabilities.
    • +
+ +

We do not have evidence that the upgraded dependencies pose any specific risk in GoCD's usage, however we endeavour to minimise dependency drift.

+ +

Changes

+ +
    +
  • #9828 - Build the default GoCD Server image on Alpine 3.14
    • +
  • #9966 - Migrate CentOS 8 Agent and Server images to CentOS Stream
    • +
  • #9922 - Base Debian agent images on "slim" variants
    • +
  • Starting this release, Alpine 3.15 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Debian 11 based docker images for GoCD Agent are available.
    • +
+ +

Bug Fixes

+ +
    +
  • #9914 - GoCD Server on MacOS not running with packaged JRE by default
    • +
  • #9992 - Remove broken "more…" link from Job Detail pages
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.4.0 and Plugin API changelog for 21.4.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, dmxjon (aka DiMaX)

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.3.0

+
+
+

Security Fixes

+ +

This release has important security fixes and upgrades to lots of internal components. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

The Business Continuity feature has been disabled as a part of these changes. If you are not able to upgrade immediately, please make sure to disable the route /add-on/business-continuity/* while you make plans to upgrade.

+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by Simon Scannell, Thomas Chauchefoin, and Paul Gerste of SonarSource. Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Changes

+ +
    +
  • All materials URLs for Git, Mercurial, Subversion and TFS materials will now need to start with an alphanumeric character or a /. Please open a GitHub issue if this is a problem for you. There is a temporary flag available for this change.
    • +
  • #9662 - Remove "Failures" tab in Job Details page.
    • +
  • #9797 - Build the default GoCD Server image on Alpine 3.13.
    • +
  • Starting this release, Alpine 3.14 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 20.04 based docker images for GoCD Agent are available.
    • +
+ +

Upcoming changes

+ +

GoCD doesn't yet work with Java 16+. The upgrade to Java 16 requires quite a few changes, which will be attempted in the near future. Given changes in the Java ecosystem (such as Adoptium not providing a JRE any more), we might need to re-think sticking with the latest JVM and maybe consider LTS releases.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.3.0 and Plugin API changelog for 21.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Hussein Kadiri, Mahesh Panchaksharaiah, Marques Lee, Paul Gerste, Simon Scannell, Thomas Chauchefoin

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.2.0

+
+
+

Security Fixes

+ +

This release has important security fixes. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

Changes

+ +
    +
  • #9086 - Bundle latest Java 15
    • +
  • Starting this release, Alpine 3.13 based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #8899 - "Config Changed" diff marks lines containing dash (-) as removed
    • +
  • #9073 - Add missing Content-Type check
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.2.0 and Plugin API changelog for 21.2.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.1.0

+
+
+

Security Fixes

+ +

This release has important security fixes pertaining to Agent-Server communication. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

These security vulnerabilities were responsibly disclosed by Denis Andzakovic. We want to give users some time to upgrade, before providing more details about the vulnerabilities.

+ +

Webhook support for Config Repositories

+ +

Starting GoCD 21.1.0, the config repositories can be refreshed or updated via a webhook trigger. The config repositories page will now showcase the URL required to configure the same (if auto update has been turned off).

+ +
+ Config Repositories with webhook +
+ +

Improvements

+ +
    +
  • #8900 - Improve UX - add search functionality on page
    • +
+ +

Bug fixes

+ +
    +
  • #8915 - Repeated logging: Could not find file config/cipher and config/go.feature.toggles
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.1.0 and Plugin API changelog for 21.1.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.10.0

+
+
+

Improvements

+ +
    +
  • 85a721b - Improve UI performance by increasing the polling interval if the window is in background.
    • +
  • #8729 - Modal UX improvements: for validation failures, errors indicated next to the save button
    • +
+ +

Bug fixes

+ +
    +
  • #8730 - Unexplained performance degradation/lock-ups after 20.5.0 to 20.8.0 upgrade
    • +
  • #8741 - Pipeline Activity column headings not aligned with progress blobs
    • +
  • #8767 - Agents API is slow when there are too many secure variables in GoCD environment
    • +
  • #8774 - Agent resource tags are case-sensitive when referenced from a job
    • +
  • #8775 - Make ignore_for_scheduling field read-only on pipeline config edit SPA, for configs from Config Repo
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.10.0 and Plugin API changelog for 20.10.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Shakir Shakiel, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.9.0

+
+
+

Preference Page

+

As part of the ongoing UI/UX refresh for improving the user experience, the Prefernce page has been rewritten to keep it in sync with other pages, while retaining existing functionality. Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ Preference page +
+ +

Stage Overview on VSM Page

+ +

Staring this release, the users can view the stage overview on VSM page. Earlier, it was available on the Dashboard and Pipeline Activity Page.

+ +
+ Stage overview on VSM page +
+ +

In case of stage re-runs, the stage overview now provides an option to view previous stage runs.

+ +
+ Stage instances on stage overview +
+ +

Other Improvements

+ +
    +
  • #1926 - Job Timeout should apply even when the job could not be assigned to an agent
    • +
  • #5787 - Ability to start server in maintenance mode
    • +
  • #8170 - Support for webhook integration with Pluggable SCM materials
    • +
  • #8592 - Add secrets support in elastic agent configurations
    • +
  • #8599 - Load GoCD configurations from config repositories on GoCD startup
    • +
  • #8667 - Auto Update of Config Repo materials can be turned off now
    • +
+ +

Bug fixes

+ +
    +
  • #8542 - Changes to global Plugin Material Config and Package Config does not reflect on pipeline materials
    • +
  • #8594 - Feeds API for scheduled jobs will return jobs only for pipeline which can be viewed by the user
    • +
  • #8601 - Solve issue around missing SCMs coming from config repo
    • +
  • #8623 - Fix the check connection button text on pluggable scm modal
    • +
  • #8628 - Do not run database migration for server in standby
    • +
  • #8643 - Elastic Agent Plugin always migrates the old plugin settings
    • +
  • #8650 - Fixed the git version mismatch between error message and actual check
    • +
  • #8653 - Fixed the issue of Duplicate SCM on config repo parsing
    • +
  • #8655 - Do not purge the config repo defined structures cache on polled fetch on Config Repo Page
    • +
  • #8685 - Minor Pipeline Comparison UI regressions introduced in 20.3.0
    • +
  • #8624 - Fix - Postgres with SSL throws "PSQLException: SSL error: null"
    • +
+ +

Removal

+ +
    +
  • The CentOS 6 based docker image for GoCD Agent has been removed. CentOS 6 has reached end-of-life in Nov 2020. Please use an image based on a newer version of the CentOS.
    • +
  • The Alpine 3.9 based docker image for GoCD Agent has been removed. Alpine 3.9 has reached end-of-life in Nov 2020. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.9.0 and Plugin API changelog for 20.9.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.8.0

+
+
+

Materials Page

+ +

We have introduced a new Materials Page which lists all the configured materials. The page provides an ability to trigger a material update. For each material you can view the modifications with a corresponding link to VSM.

+ +
+ Materials SPA +
+ +

Support for Branch and Pull Requests

+ +

The GoCD Groovy DSL Configuration Plugin adds support for PR and branches in the latest version of the plugin. The plugin provides an ability to templatize a pipeline or an entire workflow to run your builds against each branch and PR. Once a template is defined, the plugin scans the configured repository at a regular interval and for each available branch/PR it builds the corresponding pipelines.

+ +

Refer to the plugin documentation for comprehensive examples to use this feature.

+ +

Stage Overview on Pipeline Activity Page

+ +

Staring this release, the users can utilize the stage overview on Pipeline Activity page. Earlier, it was only available on the Dashboard.

+ +
+ Stage overview on pipeline activity +
+ +

Other Improvements

+ +
    +
  • #3962 - Support allowlist for pluggable SCM materials
    • +
  • #8234 - Support for secrets management interpolation on Pluggable SCM materials
    • +
  • #8367 - Add support for denylist for plugin materials on the edit material popup
    • +
  • #8522 - Exponential backoff material update in case of failures
    • +
  • #8558 - Add support for secrets in Package configurations
    • +
+ +

Bug fixes

+ +
    +
  • #8490 - Invalid stage settings link on stage overview when a pipeline is defined from a template
    • +
  • #8492 - ConfigRepoPlugin should decrypt all of the configuration properties when including them in the request.
    • +
  • #8502 - Dashboard UI issue: Repeated trigger buttons
    • +
  • #8511 - Allow group admin users to check connection for Pluggable SCM config
    • +
  • #8524 - Test Connection with ## in Repository URL doesn't work in Pipeline Wizard
    • +
  • #8525 - Backup breaks when WRAPPER_CONF_DIR is not set
    • +
  • #8540 - Fix job rerun icon positioning on stage overview
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.8.0 and Plugin API changelog for 20.8.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.7.0

+
+
+

Dashboard Improvements

+ +

In this release, there have been significant improvements to the GoCD dashboard UX:

+ +
    +
  • We have introduced a new stage overview which provides users with quick access to stage details on the dashboard. The stage overview provides information about all the jobs in a stage, gives an option to re-run jobs and to quickly access the job console from the dashboard.
    • +
  • The GoCD dashboard now provides an ability to trigger manual stages.
    • +
+ +
+ Quick stage overview on dashboard +
+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.12 based docker images for GoCD Agent are available.
    • +
  • The bundled yum package material plugin has been updated to work on RHEL 8
    • +
  • #8411 - Allow only admins and pipeline group admins to perform check connection on pipeline materials.
    • +
+ +

Bug fixes

+ +
    +
  • #8416 - Agent SSL Verification with reverse proxy fails
    • +
  • #8427 - Agents going Lost Contact after a while and warnings in the server about remoteBuildRepository
    • +
  • #8460 - Mask authentication credentials in urls on materials tab on pipeline config edit page
    • +
  • #8463 - Fail to perform any GoCD updates due to invalid config repository configuration
    • +
  • #8464 - Added validation for null arguments for exec command
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.7.0 and Plugin API changelog for 20.7.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.6.0

+
+
+

New Pipeline as code wizard

+ +

The Pipeline as code wizard makes it easier for users to define and generate pipeline definitions using the config repo plugin of their choice.

+ +
+ Pipeline as code wizard +
+ +

SSL support - Breaking Changes

+ +

In GoCD 20.2.0 we had announced the removal of support for TLS on port 8154 using a self-signed certificate. To minimize disruptions, GoCD temporarily provided an option to enable the TLS port.

+ +

With this release, GOCD no longer supports configuring TLS within GoCD and will stop bringing up TLS on port 8154. If you have temporarily enabled TLS, and if the agents are configured to use the TLS port 8154 they will have to reconfigured to use port 8153, else the agent will stop connecting to the server.

+ +

Business Continuity

+ +

GoCD had a failover mechanism to decrease the impact of server failure. This feature was available as part of the paid offering through the Business Continuity Addon. +As part of open sourcing all the commercial components, the Business continuity feature has been incorporated into GoCD core. Please refer to the documentation to know more about the Business Continuity feature.

+ +

Data Sharing

+ +

The Data Sharing feature has been removed from GoCD.

+ +

Other Improvements

+ +
    +
  • #8210 - Allow git material to honor a refSpec as the branch name
    • +
  • #8263 - Better naming for whitelist/blacklist options
    • +
  • #6722 - Showcase a help component for concepts on all SPAs
    • +
  • #8315 - Show help text when plugin role selector is disabled on Roles SPA
    • +
  • #8327 - Show branch name on materials table
    • +
+ +

Bug fixes

+ +
    +
  • #8231 - Fix rule circumvention issue that allows partials from config-repository to be merged even if rules are violated
    • +
  • #8314 - Fix Users update API to return appropriate status code on update user failure
    • +
  • #8298 - Fix duplicate error message from the Stage Trigger API
    • +
  • #8335 - Fix NPE issue while using access token which has reference to invalid authorization configuration
    • +
  • #8345 - Stale response while using Stage History API
    • +
  • #8350 - Resolve secret params during check connection
    • +
  • #8308 - Validate empty tasks in a job
    • +
  • #8261 - Added toggle icon to view the text while editing for secure environment variables
    • +
  • #8141 - Improvements and Bug Fixes on Pipeline Config SPA
    • +
  • #8361 - Add client side validations for environment variables on Pipeline Config SPA
    • +
+ +

Removal

+ +
    +
  • The Debian 8 (jessie) based docker image for GoCD Agent has been removed. Debian 8 (jessie) has reached end-of-life in June 2020. Please use an image based on a newer version of the Debian.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.6.0 and Plugin API changelog for 20.6.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.5.0

+
+
+

Support for multiple databases

+ +

GoCD 20.5.0, while continuing to use H2 as the default database, introduces support for PostgreSQL without a need for the (previously used) commercial addon. As part of these changes GoCD moved away from using the unmaintained dbdeploy to liquibase for automated database migrations. These changes require a one-time manual migration of the GoCD database running on versions <= 20.4.0 to one compliant with GoCD 20.5.0 and beyond, even if you decide not to migrate to PostgreSQL.

+ +

Please refer to the GoCD Database migration document for steps to migrate your database.

+ +

UI/UX refresh

+ +

As part of the ongoing UI/UX refresh for improving the user experience, the Templates Authorization page has been rewritten to keep it in sync with other pages, while retaining existing functionality.

+ +
+ Template Authorization +
+ +

Other Improvements

+ +
    +
  • #150 - Agents API (on GoCD server side) provides information about Agent and Agent Bootstrapper versions.
    • +
  • #8127 - Improved performance of pipeline edit on Environments page
    • +
  • #8114 - Agents API to force kill tasks on an agent stuck in Building(Cancelled) state.
    • +
  • #8223 - Improved help text in UI for artifact cleanup options.
    • +
+ +

Bug fixes

+ +
    +
  • #8220 - Fixed bug when adding notifications using the Notification Filters API.
    • +
+ +

Deprecations

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.5.0 and Plugin API changelog for 20.5.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.4.0

+
+
+

Default permissions on new pipeline groups

+ +

Starting from 20.4.0, all pipeline groups with no explicit permissions setup can only be viewed and operated by GoCD system administrators. Earlier, such pipeline groups could be viewed and operated by every valid user. This changes it to be secure by default.

+ +

UI/UX refresh

+ +

As part of the ongoing UI/UX refresh for improving the user experience, the Pipeline Config edit page has been rewritten to keep it in sync with other pages, while retaining existing functionality. Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ Pipeline Config Edit +
+ +

Other Improvements

+ +
    +
  • #8118 - Update Package and Pluggable SCM page to support auto_update
    • +
  • #8140 - Improving config repository error message while parsing related to rules
    • +
+ +

Bug fixes

+ +
    +
  • #8119 - Adding a package material via Package page causes the pipeline to fail
    • +
  • #8132 - Fixed Template API update failure when parameter resolution has errors
    • +
+ +

Deprecations

+ +
    +
  • The Alpine 3.8 based docker image for GoCD Agent has been removed. Alpine 3.8 has reached end-of-life in May 2020. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.4.0 and Plugin API changelog for 20.4.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.3.0

+
+
+

New Pluggable SCMs Page

+ +

We have introduced a new Pluggable SCMs page to create and manage Plugin Materials.

+ +
+ Pluggable SCMs page +
+ +

UI/UX refresh

+ +

As part of our ongoing UI/UX refresh for improving the user experience, we have rewritten the Packages and Comparisons page to keep it in sync with other pages and retaining the existing functionality.

+ +

Packages Page

+ +
+ Package Repository page +
+ +

Comparison Page

+ +
+ Comparison page +
+ +

Other Improvements

+ +
    +
  • #2947 - Custom SCM material plugins do not show up in the list of materials when creating a new pipeline
    • +
  • #7022 - Pipeline creation wizard missing package material type
    • +
  • #7860 - Pipelines page: disable delete for pipelines with dependent pipelines
    • +
  • #7889 - [Performace Improvement] Remove unnecessary group by cause while loading dashboard pipeline
    • +
+ +

Bug fixes

+ +
    +
  • #2197 - Incorrect error message for invalid template name
    • +
  • #7865 - PipelineConfig Create API: ensures pipeline group name check is case-insensitive
    • +
  • #7903 - Maintenance mode message not showed in some pages
    • +
  • #7982 - Fix fingerprint generation for Plugin and Package materials
    • +
  • #8012 - PipelineConfig API: incorrect error mapping for stage authorization errors
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.3.0 and Plugin API changelog for 20.3.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.2.0

+
+
+

Support for Rules on Config Repositories (Pipeline as Code)

+ +

In order to provide fine-grained access control over the entities that are created by a config repository, GoCD adds support for defining rules on config repositories that specifies which environments, pipeline groups, pipelines the repository can refer to. +Please refer to the Specifying rules on Config Repository for more information.

+ +

Changes to SSL Support

+

There are important changes to how GoCD handles SSL support. If you are upgrading to GoCD 20.2.0, agents will have to be reconfigured to connect to the server. Please read the GoCD SSL Changes for more information.

+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.11 and CentOS 8 based docker images for GoCD Server are available.
    • +
  • #6031 - Improve Pipeline Material auto update mismatch error
    • +
  • #7736 - Improvements to wrapper properties examples
    • +
  • #7748 - Improve Logging - Add plugin load/update/remove logs
    • +
  • #7713 - Provide additional information about GoCD deprecated APIs
    • +
  • #3194 - Add the possibility to retrieve template parameters through the template API
    • +
+ +

Bug fixes

+ +
    +
  • #7737 - Fixed issue with moving pipeline between groups
    • +
  • #7676 - Fixed invalid run_instance_count during pipeline export
    • +
  • #7822 - Missing response body error when submitted Pipeline JSON has duplicate job name error
    • +
  • #7824 - Pipeline Config API does not return any error message for invalid job resources
    • +
  • #7830 - Don't showcase pending agents in edit agents modal
    • +
  • #7853 - Improve search on Config Repository SPA
    • +
  • #7709 - Leading space in commit message breaks material modification check
    • +
  • #7752 - Modification check failed for material: special characters are not allowed
    • +
  • #3103 - Missing parameter in dependent pipeline leads to unknown error in template configuration
    • +
  • #7747 - Operate permission cannot View pipeline group
    • +
+ +

Breaking Changes

+ + + +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.2.0 and Plugin API changelog for 20.2.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.1.0

+
+
+

Improvements to Role Based Access Control

+ +

As part of GoCD release v19.11.0, GoCD roles were enhanced to support granular authorization.

+ +

This release adds support to configure access permissions for cluster profiles and elastic agent profiles. Support for other GoCD entities will be added in subsequent releases.

+ +

Please refer to the Policy Documentation for Elastic Agent Configurations for more information.

+ +

UI/UX refresh

+ +

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages:

+ +

Pipeline Group Authorization Edit Page

+ +
+ Pipeline Group Authorization Edit Page +
+ +

Support for Postgres 10 and above

+ +

From this release the commercial GoCD PostgreSQL Addon will support Postgres version 10, 11 and 12.

+ +

Note: As per earlier announcement this Addon is expected to be open sourced in Q2 of 2020.

+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.11 based docker images for GoCD Agent are available.
    • +
  • #1364 - Introduce Get Job Instance API
    • +
  • #2990 - Make 'material name' accessible through Pipeline instance API
    • +
  • #3326 - History APIs for pipeline/stage/job instances should allow defining page size
    • +
  • #5717 - Showcase config repository validation errors on separate line
    • +
  • #7560 - Enable job settings link in elastic agent profile usages modal for pipelines coming from config-repos
    • +
  • #7575 - Expose current agent resources as GO_AGENT_RESOURCES environment variable
    • +
+ +

Bug fixes

+ +
    +
  • #7498 - Handle failing stage status animation
    • +
  • #7472 - Cancelled icon is not rendered for cancelled jobs on stage details page
    • +
  • #7509 - Config Repositories does not refresh when an elastic profile is added
    • +
  • #7534 - Pipeline Group API update gives 200 even when a non-existent role is passed
    • +
  • #7557 - Unable to run commands with multi-line arguments configured via UI
    • +
  • #7572 - Dashboard UI not updating on pipeline group authorization updates
    • +
  • #7603 - CPU Spike while visiting Elastic Agents Configuration page
    • +
  • #7654 - Fix for 19.12.0 upgrade failures if pipeline label contains package material name.
    • +
  • #7656 - Pipeline Group Admin should receive a 403 on create pipeline if the group specified does not exist
    • +
+ +

Deprecations

+ +
    +
  • The Alpine 3.7 based docker image for GoCD Agent has been removed. Alpine 3.7 has reached end-of-life in Nov 2019. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.1.0 and Plugin API changelog for 20.1.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole, Zamfir Catalin Alexandru

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.12.0

+
+
+

Read Only View for Config Repository Pipelines

+ +

Earlier users had to visit the source control repository to know the pipeline settings of the pipelines defined on config repository. Now, Users will now be able to view configurations of pipelines defined via config repositories in read-only mode within the GoCD application.

+ +
+ Read Only View for Config Repository Pipeline +
+ +

Improvements to Role Based Access Control

+ +

As part of GoCD release v19.11.0, GoCD added support to configure access permissions to environments using policies at a granular level. +This release adds support to configure access permissions for config repositories. Support for other GoCD entities will be added in subsequent releases.

+ +

UI/UX refresh

+ +

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages:

+ +

Elastic Agent Configuration Page

+ +
+ Elastic Agent Configuration Landing Page +
+ +
+ Elastic Agent Configuration Cluster Profile Page +
+ +
+ Elastic Agent Configuration Elastic Profile Page +
+ +

Pipeline Activity Page

+ +
+ Pipeline Activity Page +
+ +
+ Pipeline Activity Comment Page +
+ +

Agent Job Run History Page

+ +
+ Agent Job Run History Page +
+ +
+ Agent Job State Transition Page +
+ +

Other Improvements

+
    +
  • #7321 - Introduce Pipeline Comment feature to allow users commenting on a pipeline instance. Please refer to the documentation to know more about pipeline comment feature.
    • +
  • #7229 - Performance improvements to Pipeline Config updates through UI.
    • +
  • #3370 - Add pipeline group name to environment variable context during build assignment.
    • +
  • #7402 - Allow users to rename pipeline group via API.
    • +
  • #7370 - Environment SPA Improvements.
    • +
  • #7372 - Add Confirmation modal on server config SPA while switching tabs.
    • +
  • #7375 - Open new read only templates page upon clicking view templates from pipeline configurations page.
    • +
  • #7374 - Improve agent's API error message.
    • +
  • #6897 - Guess webhook repo url for ssh urls.
    • +
+ +

Bug fixes

+ +
    +
  • #7481 - Fix persistence issue with secure environment variables of an environment.
    • +
  • #7432 - Show error message when entity does not exist on SPAs.
    • +
  • #7356 - Show appropriate error message for disabled pipeline edit icon on templates SPA.
    • +
  • #7357 - Fix read only templates view jump issue.
    • +
  • #7359 - Disable deleting environments defined in config repository through API.
    • +
  • #7345 - Fix export pipeline to generate valid configuration for pipelines consisting of package repository materials.
    • +
  • #7373 - Fix project management configuration persistence issue.
    • +
  • #7415 - Allow users to cancel stage on maintainance mode page.
    • +
  • #7423 - Show validation error message for on cancel task.
    • +
  • #7456 - Fix loading issues with config repository SPA.
    • +
  • #7468 - Show appropriate error message when user does not have permissions to edit pipeline configurations.
    • +
  • #6363 - Show appropriate error message when pipeline does not exists on edit pipeline configurations page.
    • +
  • #7442 - Fix issue with positioning of tool tip in users management page.
    • +
  • #7336 - Add missing Send Test Email option on Email Configuration SPA.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.12.0 and Plugin API changelog for 19.12.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Andrew Bentley, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.11.0

+
+
+
+ Issue with Environment Variables of Environment: There is a known issue with GoCD release v19.11.0: Github issue #7481 causing the secure environment variables defined in an environment not to be persisted on the server. There is a GoCD release v19.12.0, which fixes this issue. It is recommended to use 19.12.0 (or above) installers. + +
+
+ + Users on GoCD release v19.11.0 are recommended to use the alternatives mentioned as part of the Github Comment to avoid this issue. + +
+
+ + Updated: Monday 23 DEC at 11:00:00 UTC 2019 +
+ +

Role Based Access Control

+ +

Traditionally, a Role in GoCD is a group of users. With this release, we are enhancing the purpose of Roles. Roles can now be used to control the access of different entities in GoCD, which earlier were accessible only by System Administrators.

+ +

System Adminstrators can configure permissions for a given role using policies at a granular level. This release adds support to configure access to environments, support for more entities will be added in subsequent releases.

+ +

Read the GoCD Policy documentation for more details.

+ +

UI/UX refresh

+

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages,

+ +

Server Configuration Page

+
+ New Server Configuration Page +
+ +

Environments Page

+
+ New Environments Page +
+ +

Templates Page

+
+ New Templates Page +
+ +

Pipelines Page

+
+ New Pipelines Page +
+ +

Other Improvments

+ +
    +
  • #7229 - Performance improvements to Pipeline Config updates through UI.
    • +
  • #6956 - Added support to load multiple plugins as a bundle.
    • +
+ +

Bug fixes

+ +
    +
  • #7296 - Fix issue with mounting directories as docker volume, if directories already exist
    • +
  • #7281 - Fix for Agents page constant shuffle.
    • +
  • #7285 - Fixed issue with weird lines showing up on agents table
    • +
  • #7138 - Fix for Agent Job History order inconsistency
    • +
  • #7212 - Error messages on agents SPA not getting displayed.
    • +
  • #2048 - Fixed issue with incorrect job cancel, in case of canceling run on all agent job
    • +
  • #7172 - Set JVM Properties in docker-gocd-agent-ubuntu
    • +
  • #7177 - Show appropriate error when user does not have permissions to operate on a pipeline or pipeline group.
    • +
  • #6754 - Fix for systemd not detected on Amazon Linux 2
    • +
  • #7301 - Include wrapper-config files to the GoCD backup process
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.11.0 and Plugin API changelog for 19.11.0.

+ +

Security

+ +

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. +In this release, a security issue responsibly disclosed by Wasin Sae-ngow was fixed.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Antonio Masucci, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Riko Stave, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.10.0

+
+
+

Database cleanup

+ +
+ Please make sure that a GoCD server backup is taken before upgrading to 19.10.0. +
+ +


+ +

There are some unnecessary data in the GoCD database which will be removed upon the first server start after upgrading to 19.10.0. +This cleanup will be done only for completed jobs and will remove historical data related to environment variables, artifact plans, resources and job-related metadata. +This will not affect any information in GoCD's configuration file.

+ +

Depending on the size of your database, you may experience some delay during startup while the data is being removed from the database. Please do not kill the GoCD server until the database upgrade completes. +If you do end up killing it, you might need to restore the database from the backup taken before this upgrade.

+ +
    +
  • 7d5d01f - Delete cruft from the DB for jobs that are completed.
    • +
+ +

Improved Agents page

+ +

Agents page has been improved in this release. Now it will have 2 tabs - Static and Elastic - for easy viewing and searching of static and elastic agents.

+ +
+ New Agents page - Static agents +
+ +
+ New Agents page - Elastic agents +
+ +

Optional upstream dependencies

+ +

Introduced ignore_for_scheduling flag at the pipeline dependency level to improve GoCD's ability to model pipelines, as described in this issue. +This flag allows run of an upstream pipeline to be ignored by the downstream pipeline. +This is useful in cases where a downstream pipeline has multiple materials and wants to have fine-grained control over which materials cause it to run. Previously, this was available only for SCM materials (like git, mercurial, etc). This flag is available on the material edit page, Pipeline Config API and the bundled JSON/YAML config repo plugins.

+ +

Other Improvements

+ +
    +
  • Starting this release, CentOS 8 based images for GoCD Agent are available
    • +
  • 2c93195 - Bundle Java 13 for all installers.
    • +
  • #4756 - Provide an option to sort by duration on the job run history page
    • +
  • #6289 - Expose scm material url and branch as environment variables to tasks
    • +
  • #6602 - Dashboard will show an info icon instead of settings icon for pipeline-as-code pipelines
    • +
  • #7113 - Added 'group' property to Get Pipeline Config API
    • +
  • #7155 - Added support for 'group' attribute in Update Pipeline Config API
    • +
+ +

Bug fixes

+ +
    +
  • #7002 - Honour hostname in agent autoregister properties
    • +
  • #7037 - Bring back UUID support in SVN post commit hook API
    • +
  • #7064 - Authorization config update API should not need id value
    • +
  • #7067 - Fix for Notification preferences not persisted
    • +
  • #7068 - Enable email support link is pointing to wrong link under preferences tab
    • +
  • #7107 - Fix for job details page error if agent is not yet assigned
    • +
  • #7126 - Fixed no response on deleting an auth config
    • +
+ +

Deprecations

+ +
    +
  • Starting this release, Fedora based docker image for GoCD Agent will not be published. Users can continue to use the older images and the agent will get auto-upgraded.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.10.0 and Plugin API changelog for 19.10.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Rodny, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.9.0

+
+
+

Support for Java 8 and 10 removed

+ +

Support for Java 8 and 10 has been dropped from this release. This is in line with our official stance on Java we announced earlier this year post the Java Licensing Changes.

+ +

Starting 19.9.0, GoCD Server and Agent would only support Java 11 or 12. Support for Java 13 will be introduced soon. GoCD installers from 19.6.0 come with Java Runtime pre-bundled, so users no longer need to install it separately.

+ +

Users might need to upgrade the GoCD Agent Bootstrapper. More information can be found here

+ +

Other Improvements

+ +
    +
  • #911 - Moved agent configuration out of the main xml configuration.
    • +
  • #6919 - Improve performance of artifact download and digesting.
    • +
+ +

Bug fixes

+ +
    +
  • 4c54c9b - Fix git failure on CentOS 7 based GoCD agent docker images.
    • +
  • #6918 - Error on opening on job details in the absence of cluster profile
    • +
  • #6942 - Rules reordering not working on edit of secret config
    • +
  • #6952 - GoCD page suddenly asking for client certificate
    • +
  • #6968 - Materials API return 404 for existing materials and modifications in 19.8.0
    • +
  • #6973 - Ignore unknown properties while upgrading plugin profile configuration
    • +
  • #6979 - Add missing working directory replacement during agent duplication
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.9.0 and Plugin API changelog for 19.9.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Saurabh Mistry, Sebastian Goral, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.8.0

+
+
+

New Pipeline Creation Wizard

+ +

We have introduced a new simplified pipeline creation wizard as part of our ongoing UI/UX refresh for improving the user experience.

+ +

Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ New Pipeline Creation Wizard +
+ +

Introduce support for latest API version

+ +

GoCD’s APIs are versioned. Accessing an API endpoint requires providing a version number as part of the Accept header. GoCD now allows accessing the latest version of an API by omitting the version number in the header. For instance, you can use Accept: application/vnd.go.cd+json instead of Accept: application/vnd.go.cd.v3+json. More information can be found on GitHub issue #6620.

+ +

Ability to trigger a stage only if the previous stage has succeeded

+ +

Introduced the attribute allowOnlyOnSuccess for approval at stage level. If the attribute is set to true, the stage can be manually triggered only if the previous stage (if there is one) has resulted in success. More information can be found on GitHub issue #6294.

+ +

Java 8 and 10 deprecation

+ +

Support for Java 8 and 10 will be removed in the next release of GoCD. GoCD installers come with Java Runtime pre-bundled, so users no longer need to install it separately. +The removal of Java versions is in line with the Java Licensing Changes we had announced earlier this year in this blog post.

+ +

Other Improvements

+ +
    +
  • Starting this release, Debian Buster (10) based images for GoCD Agent are available.
    • +
  • 08f7b6e - Slim down the windows installer sizes.
    • +
  • #6688 - Allow plugins to execute javascript as part of angular plugin view
    • +
  • #6802 - Add git, hg, svn, p4 version info to support output
    • +
  • #6826 - Optimized GoCD server and agent docker image size
    • +
  • #6832 - Synchronize user info with external sources
    • +
+ +

Bug fixes

+ +
    +
  • 6731045 - Fixed issue with analytics not loading up if AdBlock is enabled. A new version of analytics plugin has been released. Users will have to update to the same.
    • +
  • 35021fb - Fix jetty warning on agent connection.
    • +
  • fc61beb - Fix the DIND image. Now the docker service is started using root user.
    • +
  • f10025b - On uninstall, cleanup temp dirs that are left behind by server process.
    • +
  • #5587 - Re-running failed jobs leaves a warning with null exception in the logs
    • +
  • #6376 - Rerun old stage failing without providing console output
    • +
  • #6409 - No indication of failure when subsequent stages are run after material config is changed post first stage run
    • +
  • #6640 - Pipeline pause message is not shown completely on dashboard
    • +
  • #6682 - Environments Get API does not honor If-None-Match header
    • +
  • #6727 - Template Authorization API returns 404
    • +
  • #6815 - Fix for world-writable files in go-agent and go-server packages.
    • +
  • #6827 - Upgrading GoCD linux packages from 19.7.0 to 19.8.0 overwrites wrapper-properties.conf file
    • +
  • #6855 - GoCD server emits "Weak cipher suite" warnings on startup
    • +
  • #6879 - Sync environments when a config repo is deleted
    • +
  • #6892 - Fixed issue with GoCD installation on Windows
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.8.0 and Plugin API changelog for 19.8.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.7.0

+
+
+
+ Windows Installer Issue: There is a known issue with the fresh install of 19.7.0 windows installers: GitHub issue #6892. There is a 19.8.0 release, which fixes this issue. It is recommended to use 19.8.0 windows installers. + +
+
+ + Updated: Friday 06 SEP at 07:25:00 UTC 2019 +
+ +

Bug Fixes

+ +
    +
  • #6666 - Fixes issue with GoCD server/agent not automatically starting on a server restart.
    • +
  • #6674 - Fixes issues with migrating user defined Environment Variables on upgrade to 19.6.0
    • +
  • #6677 - Disable directory listing for assets directory.
    • +
  • #6684 - Bring back GO_ENVIRONMENT_NAME environment variable as part of Job Console.
    • +
  • #6690 - Fixes issue with dependency on sysvinit-tools for RPM distros.
    • +
  • #6699 - Allow exiting running GoCD docker containers by sending SIGINT ctrl-c signal.
    • +
+ +

Versions of Java this release of GoCD works with

+
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 has been deprecated. The support for the same will be removed in a release scheduled for November 2019.
    • +
  • The Plugin Info API version 5 has been deprecated. This version will be removed in a release scheduled for Sept 2019. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline config API version 7 has been deprecated. This version will be removed in a release scheduled for Oct 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned get all materials API has been deprecated in favor of get all materials API v1. This version will be removed in a release scheduled for Oct 2019.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.6.0

+
+
+
+ Known issues: There are two known issues with the 19.6.0 installers: GitHub issue #6666 and GitHub issue #6674 with workarounds mentioned in the issues. There is is a 19.7.0 release, which fixes these issues. It is recommended to upgrade directly to 19.7.0. + +
+
+ Windows Installer Issue: There is a known issue with the fresh install of 19.6.0 windows installers: GitHub issue #6892. There is a 19.8.0 release, which fixes this issue. It is recommended to use 19.8.0 windows installers. +
+
+ + Updated: Friday 06 SEP at 07:25:00 UTC 2019 +
+ +

Secrets Management

+ +

We have enhanced support for managing secrets in GoCD. GoCD now provides an ability to refer to secrets defined in an external Secret Manager. With this, apart from referring to secrets, users can manage permissions for these secrets and rotate them without any changes to GoCD configuration.

+ +

Support for Secrets Management is provided using plugins. We have introduced a new secrets extension using which plugin authors can write a plugin to support a Secret Manager of their choice. We have built a File based Secret Management plugin which is bundled along with GoCD.

+ +

Please refer to the Secret Management Documentation for more information.

+ +
+ Secret Management SPA +
+ +

GoCD Installer Changes

+ +

There is some variation in how GoCD server and agents across multiple different operating systems and installer types need to be managed by system admins. To reduce the maintenance overhead and cognitive load, all the installers have undergone varying degrees of changes.

+ +
+ If you are an existing GoCD user upgrading from an older version of GoCD, please read about the changes before performing an upgrade. Users installing GoCD for the first time should not be affected. +
+ +

Running Dockerized GoCD Containers as Non Root

+ +

Starting from this release, GoCD containers run as non-root user, by default. The Dockerized GoCD application will run as go:root (uid:1000, gid:0) user instead of running as root:root (uid:0, gid:0). For more information, checkout Running Dockerized GoCD Containers as Non Root blog post.

+ +

Simpler HTTP authentication for agent-server communication

+ +

Historically, GoCD agent server communication required SSL/TLS mutual authentication using X509 certificates. GoCD version 19.6 disables mutual TLS by default. This will allow GoCD administrators to terminate agent-server communication at load balancers or reverse proxies.

+ +

To turn on the old behavior and enable mutual TLS, set the environment variable GO_USE_TOKEN_AUTH to false.

+ +

Versions of Java this release of GoCD works with

+
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.10 based docker images for GoCD Agent are available.
    • +
  • #6567 - Order pipeline group names in alphabetical order when cloning a pipeline.
    • +
  • #6225 - Introduce stage building animation on dashboard.
    • +
  • #6471 - Display pipelines and environments defined by config repository.
    • +
  • #6423 - Collect Metrics for Trial XP in GoCD as part of GoCD data sharing.
    • +
+ +

Security

+ +

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. +In this release, a security issue responsibly disclosed by Heinrich was fixed.

+ +

Bug fixes

+ +
    +
  • #6628 - Fix internal server error on consuming Packages Index API.
    • +
  • #6630 - Fix internal server error on consuming Package Repositories Index API.
    • +
  • #6615 - Fix Job requiring elastic agent starves forever in case of multiple reschedule.
    • +
  • #6468 - Shouldn't allow to save pipeline config with empty template.
    • +
  • #6328 - Cancel the scheduled elastic agent jobs on GoCD upgrade from version prior to 19.3.0.
    • +
  • #6565 - Show spinner in modal when performing save/update.
    • +
  • #6547 - Update footer banner message when server is in maintenance mode.
    • +
  • #6017 - Improved error messages in APIs consuming environment variables.
    • +
  • #6350 - Show Raw console logs of a building job.
    • +
  • 2ad7510 - fixed subversion SASL auth error when subversion material use the svn protocol.
    • +
+ +

New Deprecations

+ +
    +
  • The Plugin Info API version 5 has been deprecated. This version will be removed in a release scheduled for Sept 2019. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline config API version 7 has been deprecated. This version will be removed in a release scheduled for Oct 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned get all materials API has been deprecated in favor of get all materials API v1. This version will be removed in a release scheduled for Oct 2019.
    • +
+ +

Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 has been deprecated. The support for the same will be removed in a release scheduled for November 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • The Fedora 28 based docker image for GoCD Agent has been removed. Fedora 28 has reached end-of-life in June 2019. Please use an image based on a newer version of the Fedora.
    • +
  • The Stage History unversioned API has been removed. Version 1 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been removed. Version 6 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.5.0

+
+
+

Replacing X.509 with simpler HTTPs token-based authentication for Agent-Server Communication - Beta feature

+ +

This is a beta feature: agent-server commnication can be toggled to use token-based authentication instead of self-signed X.509 certificates from the GoCD server. +To enable token-based auth, set the environment variable GO_USE_TOKEN_AUTH on the GoCD agent to true.

+ +

With token-based authentication enabled, agents can use load balancers or reverse proxy DNS names and not GoCD server DNS/IP. It is also not required to expose port 8154 on the GoCD server. TLS termination can happen at the reverse proxy instead.

+ +

Other Improvements

+ + + +

Bug fixes

+ +
    +
  • #6295 - Improved errors UI in Config Repo.
    • +
  • #5667 - Do not validate plugin properties while deleting a plugin profile entity.
    • +
  • #6278 - All rails APIs return strong Etag.
    • +
  • #6337 - Start Docker deamon process for dind image.
    • +
  • #6325 - Supress warnings thrown in server logs when a user visits job console of jobs either not assigned or not started writing to console.
    • +
+ +

Versions of Java this release of GoCD works with

+ +
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

Please refer to this blog post for GoCD official stance on supported Java versions.

+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking Changes

+ +
    +
  • The Dashboard API version 2 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been removed. Fedora 28 has reached end-of-life in June 2019. Please use an image based on a newer version of the Fedora.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.4.0

+
+
+

Improved Git and Mercurial material configurations

+ +

Introduced username and password (or encryptedPassword) attributes on Git and Mercurial materials. Users can now use these fields to setup credentials in a secure manner, instead of putting credentials in the URL. The YAML, JSON and Groovy config repo plugins have been updated to allow these additional fields on material definitions.

+ +

Users can also utilize the newly introduced branch attribute on Mercurial materials to specify the branch instead of specifying in the URL.

+ +
+ Users are advised to move their credentials from the URLs into these attributes. This allows passwords to be encrypted and stored in the configuration. +
+


+
+ Changing the material configuration will be treated as a new material for the corresponding pipeline, which in turn will trigger the pipeline. +
+ +

Introduced support for Java 12

+ +

Starting this release, GoCD has now added support for Java 12. All the docker images and installers for Windows and OSX are bundled with a supported version of Java (not necessarily 12).

+ +

Please refer to this blog post for our official stance on supported Java versions going forward.

+ +

Versions of Java this release of GoCD works with

+ +
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • Starting this release, Fedora 30 based docker images for GoCD Agent are available.
    • +
  • #6131 - Show the affected pipelines in Server Health Messages when material update fails.
    • +
  • #6245 - Remove redundant pluginId attribute from agentProfile tag.
    • +
  • #5923 - Improve logging for Access Token API requests.
    • +
+ +

Bug fixes

+ +
    +
  • #6216 - Fix encryption API to honour "go.encryption.api.max.requests" system property.
    • +
  • #6030 - Modification check failed for material for pipelines that polling is disabled and or are paused.
    • +
  • #6143 - Config Save successfully completes without updating the changes.
    • +
  • #6304 - Allow editing pipelines, agents and env vars for environment with special characters in name.
    • +
  • #6228 - Personal access tokens taking too long to generate.
    • +
  • #6030 - Server health message noise for disabled or paused pipelines with failed modification checks
    • +
  • A security fix regarding GoCD cruise-config.xml save has been identified and fixed in the current release. Users are advised to update their GoCD servers to the latest version.
    • +
+ +

New Deprecations

+ +
    +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 7 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 and Java 10 has been deprecated. The support for the same will be removed in a release scheduled for September 2019.
    • +
+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Dashboard API version 2 has been deprecated. This version will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • TFS workspace location on GoCD agents has been changed to be a server workspace, rather than a local workspace. See: #5427 - for more information. This can affect users who use TFS materials.
    • +
  • The Alpine 3.6 based docker image for GoCD Agent has been removed. Alpine 3.6 has reached end-of-life in May 2019. Please use an image based on a newer version of the Alpine.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.3.0

+
+
+

Multi-cluster support for Elastic Agent

+ +

Now elastic agent can be created in different cluster based on the cluster profile. Elastic Profiles SPA is updated to reflect cluster profiles and elastic agent profiles.

+ +
+ Cluster Support +
+ +

To know more about about Cluster Profiles click here.

+ +

Introduced elastic agent extension v5 to support cluster profiles. For more info refer Elastic Agent Plugin Endpoint documentation.

+ +
+ Upgrade instructions: In order to perform a graceful upgrade, it's advised to use the maintenance mode to make sure that all running elastic agent jobs have finished, before upgrading to 19.3.0 or a later release of GoCD. If not, you might need to cancel any previously started elastic agent jobs after the upgrade. +
+ +

Improved Backup SPA

+ +

SPA is updated to show real-time progress of your GoCD server backup.

+
+ Backup SPA +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • #6036 - Improvements to the user management page.
    • +
  • #2123 - Git shallow clone will also apply to submodules.
    • +
  • #6190 - Improved login page design and added a logout page.
    • +
  • #5885 - Provided an option to create pipeline within a group from dashboard.
    • +
  • #5978 - Added webhook endpoint for hosted bitbucket servers.
    • +
  • #6043 - Allow reordering of pipelines from config repositories. This adds an optional display_order property for pipelines defined in config repositories, which allow you to order pipelines.
    • +
  • Improve consistency of some error messages generated by GoCD server.
    • +
  • macOS installers will no longer ship as osx .app files. The installers now ship as a zip file, with a shell script. We believe this provides much better flexibility and allows users to run the GoCD agent and server in a location of their choice.
    • +
+ +

Bug fixes

+ +
    +
  • #5956 - Fixed issue with environments API incorrectly rendering encrypted variables as ****** instead of the correct encrypted value.
    • +
  • #5886 - Do not allow assigning an agent to an environment defined in config repository environment.
    • +
  • #5968 - Fix spurious e.map is not a function javascript error for notifications.
    • +
  • #5974 - Unable to expand/collapse environments with name containing special characters.
    • +
  • #5962 - GoCD shows HTTP Basic Auth dialog when after user is logged out.
    • +
  • #6011 - Fix errors with parsing git log when coloring is turned on using .gitconfig.
    • +
  • #5967 - Environments api will accept either encrypted_value or value.
    • +
  • #3635 - GoCD can update git submodules if a custom name is provided for one.
    • +
  • #5973 - Fixed issue with expanding environment panel with name containing special characters
    • +
+ +

New Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Dashboard API version 2 has been deprecated. This version will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
  • The Alpine 3.6 based docker image for GoCD Agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • The Elastic Agent Profiles API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it. With the introduction of support for clusters all Elastic Agent Profiles need to be associated with a cluster. Since version 1 of the API does not support clusters, as an exception this API had to be removed without deprecation.
    • +
  • The Dashboard API version 1 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Users API version 2 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been removed in favor of Get Stage Instance API v1.
    • +
  • The Ubuntu 14.04 based docker image for GoCD Agent has been removed. Ubuntu 14.04 has reached end-of-life in April 2019. Please use an image based on a newer version of the Ubuntu.
    • +
  • The elastic agent plugin extension version 3 has been removed. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. Users should upgrade their plugins to the latest version to see these new features.
    • +
  • GoCD will now require minimum git version 1.9. This has been done to improve support for cloning git submodules.
    • +
  • For Pipelines using git materials, ignored files will also be cleaned from the working directory. The command has been changed to git clean -dffx instead of git clean -dff.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Ketan Sangle, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sandro Heinzelmann, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.2.0

+
+
+

Access Tokens

+ +

We have introduced support for personal access tokens. GoCD users can now generate tokens through the application or the Access Token API and use them to access the GoCD APIs rather than passing their username & password. The tokens inherit the privileges of the user who created them.

+ +

Personal Access Token:

+
+ Personal Access Token +
+


+ +

Access Token Management

+
+ Admin Access Token +
+


+ +

To know more about about Access Tokens click here.

+ +

Github Oauth, GitLab Oauth and LDAP authorization plugins are migrated to authorization extension v2 to support access token based authentication for APIs. Please provide feedback/ideas by opening a GitHub issue on respective repository.

+ +

Google Oauth plugin is upgraded to use authorization extension v2 however it does not have support for access token based API authentication.

+ +

Improved pipeline pause information

+

Paused pipelines now show the time at which they were paused, along with the reason for pausing.

+ +
+ Pipeline Info when Paused +
+


+ +

New User Management Page

+

We have rewritten the User summary page, now known as User Management, to improve the user experience. Please provide feedback / ideas by opening a GitHub issue

+ +
+ User Management SPA +
+


+ +

Config Repo Improvements

+ +
    +
  • b2c6384 - Reparse and merge ConfigRepos on any change in Config Repo configuration. (#5792)
    • +
  • ed02069 - Allow users to configure empty secure environment variables.
    • +
  • 738f763 - Better error messages on Config Repo SPA in case of invalid ID.
    • +
  • d9d3c0a - Expand the Config Repo panels that are in an error state. (#5650)
    • +
  • #5756 - Added support to add global SCMs through config repo.
    • +
  • #5579 - Introduced Config Repo preflight API v1 endpoint.
    • +
+ +
+ Config repo improvements +
+ +

API Improvements

+ + + +

Authorization extension version 2

+ +
    +
  • 32cfcc5 - Introduced Authorization Extension version 2.
    • +
+ +

Other Improvements

+ +
    +
  • 3317123 - Show maintenance mode updated by timestamp along with date. (#5786)
    • +
  • 2b64f3f - Better error messages on plugins page when an installed plugin is incompatible with the GoCD server. (#5614)
    • +
  • 6a560ee - Display pause timestamp on the dashboard when a pipeline is paused. (#5719)
    • +
  • 2665b54 - Show agents assigned to environments via config repository. (#5761)
    • +
  • 3317123 - Added time stamp for the last triggered maintenance mode. (#5786)
    • +
+ +

Bug fixes

+ +
    +
  • 9a1eaf3 - Do not remove MaterialHealthStateScope for Config Repo materials. (#5651)
    • +
  • ba49547 - Disable job settings link for pipelines defined in Config Repo on elastic profiles page. (#5604)
    • +
  • 3f2fc49 - Made status report button state on elastic profiles page consistent with the status report button on plugins page. (#5776)
    • +
  • 6c4da91 - Fixed environments api version 2 etag generation issue. (#5807)
    • +
  • 38e68d0 - Render console log containing new line character ("\n"). (#5037)
    • +
  • #5705 - Fix for high CPU usage on console logs/tests page.
    • +
  • #5897 - Killing agent via stop command honors the process ID.
    • +
  • #5788 - Fixed back button navigation on dashboard.
    • +
+ +

New Deprecations

+
    +
  • The Fedora 28 based docker image for gocd agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
  • The Dashboard API v2 has been deprecated. This version of the API will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Deprecations

+
    +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in a release scheduled for April 2019. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Dashboard API v1 has been deprecated. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been deprecated in favor of Get Stage Instance API v1. This version will be removed in a release scheduled for April 2019.
    • +
  • The Users API v2 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Ubuntu 14.04 based docker image for gocd agent has been deprecated and will not be built after April 2019 release of GoCD. This will be done as Ubuntu 14.04 will reach end-of-life in April 2019.
    • +
  • The Alpine 3.6 based docker image for gocd agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • f12cbf3 - Remove the pipeline quick edit SPA.
    • +
  • 74e4e3c - Support for DES was deprecated as part of 18.7.0 release in favor of AES. The support for DES is removed as part of this release. Users who have defined encrypted values in their configuration repositories should update them to use AES encryption. (#5646)
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sanjana Bayya, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.1.0

+
+
+

GoCD Maintenance mode

+ +

GoCD maintenance mode can be utilized by the GoCD system administrator to safely restart or upgrade the GoCD server without having any running jobs reschedule when the server is back up. Initiating maintenance mode will cause various sub-systems of GoCD to stop working making sure server is not performing any operation.

+ +
+ Maintenance Mode Feature +
+


+ +

To know more about about GoCD Maintenance Mode click here.

+ +

Improved Pipeline as Code experience.

+ +

Continuing on the road towards improving GoCD's pipelines as code / config repositories experience, this release introduces the ability to export a GoCD pipeline to a format which can be used by the config repository plugins (for instance, YAML or JSON plugins). You can then check in these pipeline definitions to a repository and remove them from GoCD's config.

+ +
+ Pipeline Export Feature +
+


+ +

More improvements to this feature are in pipeline. Add your feedback or suggestions here

+ +
    +
  • 45aab5e - Show validation errors on config repo SPA. (#5711)
    • +
+ +
+ Config SPA Error +
+


+ +
    +
  • 6c88929 - Performance improvement to loading multiple Config Repos on server restart. (#5663)
    • +
+ +

API Improvements

+ + + +

Plugin API improvements

+ +
    +
  • b851373 - Adding Server version information in v2 ServerInfoProcessor. (#5686)
    • +
+ +

Other Improvements

+ +
    +
  • d6f7b49 - Allow user to override server keystore password using system environment. (#5592)
    • +
  • 51919ab - Set extra properties for the agent, from server. (#5666)
    • +
  • 143054f - Plugin Info request processor versioning. (#5654)
    • +
  • 792ae61 - Show cancelled by on the dashboard on hovering over a stage. (#5683)
    • +
  • a06b497 - Improved performance of Envrionments API. (#5698)
    • +
+ +

Bug fixes

+ +
    +
  • 9a1eaf3 - Do not remove MaterialHealthStateScope for config repo materials. (#5651)
    • +
  • 773b68d - Fix for header issue on edit pipeline. (#5596)
    • +
  • e6fd8f7 - Show error on delete when artifact store is referred in pipelines. (#5634)
    • +
  • 90e2523 - Plugin settings modal show save failure error. (#5645)
    • +
  • ee08190 - Decrease z-index to make admin menu render on top of console controls. (#5659)
    • +
  • a9812de - Toggle TFS workspace location on agent. (#5427)
    • +
  • c647a96 - Artifact store delete message was not visible on error.
    • +
  • 70f9448 - Updated clone auth config message to use newly created auth config id.
    • +
+ +

Deprecations

+ +
    +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in a release scheduled for April 2019. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Dashboard API v1 has been deprecated. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been deprecated in favor of Get Stage Instance API v1. This version will be removed in a release scheduled for April 2019.
    • +
  • The Users API v2 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Ubuntu 14.04 based docker image for gocd agent has been deprecated and will not be built after April 2019 release of GoCD. This will be done as Ubuntu 14.04 will reach end-of-life in April 2019.
    • +
  • The Alpine 3.6 based docker image for gocd agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • f12cbf3 - Remove the pipeline quick edit spa.
    • +
  • 74e4e3c - Support for DES was deprecated as part of 18.7.0 release in favor of AES.The support for DES is removed as part of this release. Users who have defined encrypted values in their configuration repositories should update them to use AES encryption. (#5646)
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Eric Cheung, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sanjana Bayya, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.12.0

+
+
+

Manage Config Repositories through UI

+ +

We have added a new Config Repositories page. This page lists existing config repos and allows CRUD (Create-Read-Update-Delete) operations for a config repo. This page has the ability to show errors and allows users to force a check of the repository.

+ +
+ Config Repositories Page +
+


+ +

UI/UX Improvements

+ +

The Elastic agent profiles page now provides the ability to view jobs configured for an elastic profile.

+ +
+ Elastic Profile List Jobs +
+


+ +

Admin Menu has been improved for better accessibility.

+ +
+ Admin Menu +
+ +

Other Improvements

+
    +
  • 0a15ede - Performance improvement to loading multiple Config Repos on server restart. (#5010)
    • +
  • df76be9 - GoCD Admins can now configure the server to set HSTS header as part of HTTPs response. (#5557) Refer docs for configuring the header.
    • +
+ +

API Improvements

+ + + +

Security

+

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. In this release, a security issue responsibly disclosed by Jake +and Imran Siddiqui was fixed.

+ +

Bug fixes

+ +
    +
  • cb9ab57 - Fixed an issue where the first personalization tab showed all pipelines on page load. (#5512)
    • +
  • bbeebad - Fix for email notification not sent on job cancellation due to timeout. (#5370)
    • +
  • 0efb7d0 - Allow javascript to be executed in the plugin settings modal. (#4797)
    • +
  • b00b026 - Fixed links pointing to pipeline dependency graph. (#5535)
    • +
+ +

Installer Changes

+ +
    +
  • +

    OSX installers are now bundled with adoptopenjdk JRE 8, commit 6814d48 - fixes an issue with Server and Agent not working on JRE >=9. (#3934)

    +
    • +
  • +

    Support for Java 11 was introduced in 18.10.0. Windows installers have been changed to bundle with OpenJDK 11.

    +
    • +
+ +

Deprecations

+ +
    +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Dashboard API v1 has been deprecated in this release. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking Changes

+ +
    +
  • Windows installers are now bundled with OpenJDK 11. In absence of 32 bit JDK distributions from OpenJDK we have stopped providing 32 bit windows installers from this release.
    • +
  • With this release there will be limited support for IE11. Visual bugs can be expected on this browser.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Armin G Jazi, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Sana Jahan, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.11.0

+
+
+

Improvements

+ +
    +
  • 7203cb3 - Allow artifact plugins to introduce new environment variables to be used by subsequent tasks. (#5188)
    • +
+ +

Performance Improvements

+ +
    +
  • In this release, users with ~100 or above agents will see a significant performance improvement on the agents page and when invoking the agents API. In 18.10, due to upgrading some libraries to support Java 9 (and beyond) there were some performance regressions with the agents page (and the agents API).
    • +
  • 451cef0 - Improve performance of some pipeline lookups in the database by removing a cast operation.
    • +
  • dcf69b0 - Do not lookup pipelines by both label and counter, prefer a counter. (#5256)
    • +
  • f0d1a6e - Use byte arrays (instead of strings) to represent the config XML. This improves performance of some of the admin pages and also quickly renders large configuration XML.
    • +
+ +

New APIs

+ +

Introduced APIs to

+ + + +

Bug fixes

+ +
    +
  • ad87a7c - Ensure that the GoCD server health check API returns an HTTP 200 OK status code when backup is in progress. (#5416)
    • +
  • 69e4b39 - Render the dashboard again after backup is completed. (#5391)
    • +
  • 98853a2 - Fix a NullPointerException in the logs when a pipeline that is building is removed from the config file.
    • +
  • aabbf06 - Fix 500 server error when calling pipeline config API by ensuring that the default artifact directory is not null. (#5342)
    • +
  • 6fddce6 - Prevent console logs of cancelled jobs running on elastic agents from being lost. (#5325)
    • +
  • e95e88b - Agent will ensure that plugins are loaded before performing any jobs. (#5169)
    • +
  • 49d7413 - Do not send email notification if user account is disabled. (#5277)
    • +
  • 13be966 - Re-enable pipeline operation buttons on dashboard if pipeline trigger fails. (#5153)
    • +
+ +

Docker Images

+ +

We have added support for the GoCD agents for Fedora-28 and Fedora-29.

+ +

Deprecations

+ +
    +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return an AES cipher-text and users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
+ +

Breaking Changes

+ +
    +
  • The alpine 3.5 based docker image for GoCD agent has been removed since alpine 3.5 has reached end of life.
    • +
  • The Template Config API v3 has been removed. Version 4 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline Config API v5 has been removed. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Feeds API for getting a Stage no longer supports the pipeline_label URL parameter. Users should use the pipeline_counter parameter instead.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Sana Jahan, Steven Streisguth, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.10.0

+
+
+

Support for Java 10 and 11

+ +

While we continue to support Java 8, GoCD has now added support for Java 10 and 11. With Oracle moving towards a 6 month cadence for newer releases we are evaluating the process to keep in sync with the new cadence. Watch this space for more information in the coming releases.

+ +

Environments Page

+ +

Originally the Environments page grouped the pipelines by environment with an option for admins to edit the environment. With the introduction of the new pipeline dashboard users have an option to group the pipelines by Pipeline Group or Environment.

+ +

With this release we have moved the environments page under the Admin tab. This page lists all the configured environments with an option to edit them.

+ +
+ Environments page moved under Admin tab +
+ +

Elastic Agent Extension V4

+ +

Upgraded the Elastic Agent Extension to Version 4. With this version GoCD notifies the plugin on completion of Job +run by an elastic agent.

+ +

New APIs

+ + + +

Improvements

+ +
    +
  • 69559f9 - Added support for referencing Environment Variable in Pipeline Label. (#5180)
    • +
  • 1ed99a0 - Allow non-admins to view all analytics other than dashboard analytics. (#5237)
    • +
+ +

Bug fixes

+ +
    +
  • 7b83e68 - Validate fetch artifact config before save. (#5202)
    • +
  • 9f17781 - Set status 503 when backup is in progress. (#5222)
    • +
  • fa31d58 - Fix for email notification filter not acknowledging 'Only if it contains my check-ins'. (#5238)
    • +
  • 1cce495 - Fix ETag computation for DataSharing Settings API. (#5184)
    • +
  • 0349a02 - Timer triggered pipelines are not scheduled on a standby server. (#5234)
    • +
+ +

Deprecations

+ +
    +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for November 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for November 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
+ +

Breaking Changes

+ +
    +
  • We have stopped building ubuntu 12.04 based docker image for gocd agent as ubuntu 12.04 is now end-of-life.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Danilo Sato, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kosta Welke, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Ravi Ranjan, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.9.0

+
+
+

Backups on a schedule

+ +

This release allows performing a backup on schedule. GoCD now allows executing a script once the backup completes. This feature removes the need for GoCD administrators to execute and monitor custom "cron-like" jobs to ensure that backups are completed.

+ +

For example: Users can now add the following snippet to the config XML to perform a backup once a night at 10pm on weekdays and call the /usr/local/bin/upload-to-s3 script after the backup is done:

+ +
<server>
+  ...
+  <backup schedule="0 0 22 ? * MON-FRI" 
+          postBackupScript="/usr/local/bin/upload-to-s3"
+          emailOnSuccess="false"
+          emailOnFailure="true"/>
+</server>
+
+ +

Analytics Extension V2

+ +

Upgraded the Analytics Extension to Version 2. This version adds support for showing analytics on the Agents and Value Stream Map(VSM) page.

+ +

Notification Extension V4

+ +

Version 4 of the Notification Extension enchances the existing Stage Status notification message to include the material fingerprint. It also provides details of previous stage(if any) responsible for triggering the current stage.

+ +

Bug fixes

+ +
    +
  • 8e0966d - Fixed scroll behaviour of filter tabs on the dashboard when navigating using the tabs dropdown. (#5097)
    • +
  • 0fdfe21 - Fix the search box width on the add/edit views modal on the dashboard.
    • +
+ +

Deprecations

+ +
    +
  • The ubuntu 12.04 based docker image for gocd agent has been deprecated and will not be built in the upcoming releases of GoCD. This is done because ubuntu 12.04 is now end-of-life.
    • +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.8.0

+
+
+

Flexible & Personalized Dashboard

+ +

We have made several improvements to the pipeline view on the new dashboard to make it more personal and relevant to our users.

+ +

Group pipelines either by pipeline groups or environments

+ +
+ grouping by environment or pipeline group name +
+


+ Create personalizations based on your preference

+ +
+ create new personalization view +
+


+ +

Make views more relevant by showing only those pipelines that are building or failed

+ +
+ show only building and failed pipelines +
+


+ +

Re-order views to your liking

+ +
+ reorder views +
+


+ +

Accessibility Improvements

+ +

We have made some accessibility improvements which makes it easier for people +using screenreaders to use the new dashboard.

+ +

Data Sharing Update

+ +

As of this release (18.8), GoCD collects information regarding jobs run by elastic agents and pipelines added through config repo. These metrics help us gauge the effectiveness of the pipeline as code feature and elastic agent plugins.

+ +
+ Data Sharing +
+


+ +

New APIs

+ + + +

Improvements

+ +
    +
  • 1ca78a3 - Improve log messages at server startup when plugins are not configured.
    • +
  • #5041 - Pipelines created via the PipelineConfig API are not paused by default now
    • +
  • GoCD server image is now updated to alpine 3.8.
    • +
  • Published 2 new GoCD agent images for docker based on alpine 3.8 and ubuntu 18.04.
    • +
+ +

Performance Improvements

+ +
    +
  • #4965 - Improve performance of config saves when config repositories are configured.
    • +
+ +

Breaking changes

+ +
    +
  • GoCD is no longer an OAuth provider. This integration was primarily used for integration with Mingle and the commercial business-continuity addon. Users who have been using GoCD's OAuth provider for the commercial business-continuity addon should read the business-continuity release notes before upgrading their GoCD servers.
    • +
+ +

Bug fixes

+ +
    +
  • d5fd967 - Fetch artifact task should support ./ as source directory for backward compatability. (#4810)
    • +
  • #4971 - Do not expose gocd server class-loader to a plugin.
    • +
  • #5020 - Request logging broken after loading indicator was introduced in version 18.7.0.
    • +
  • #3390 - Deleting pipeline config via API don't notify scheduleService to cancel job
    • +
  • dfa0d22 - Fixed config repo cloning using API. (#5013)
    • +
+ +

Deprecations

+ +
    +
  • The ubuntu 12.04 based docker image for gocd agent has been deprecated and will not be built in the upcoming releases of GoCD. This is done because ubuntu 12.04 is now end-of-life.
    • +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Anisha Roofi, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dilip Nandakumar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Noah Huppert, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Reuben James, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Victor Sollerhed, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.7.0

+
+
+

External Artifacts

+ +

Introduced support for publishing and fetching artifacts from an external artifacts store.

+ +
    +
  • We have introduced a new Artifacts Plugin Extension for plugin authors to write plugins which support artifact stores of their choice.
    • +
  • Introduced Artifact Plugin for Docker Registry to store and fetch docker images from the docker registry.
    • +
+ +

Better encryption

+

We have moved towards using AES for encryption/decryption over DES. All DES cipher-text in cruise-config.xml will be migrated to AES cipher-text. Support for DES is retained to handle DES cipher-texts configured in config-repos. DES encryption is deprecated, check the deprecation notes for more details.

+ +

Data Sharing

+

GoCD now shares some (non-personally identifiable) information about the instance, to help improve the experience and performance. All GoCD system administrators will see a notification message about it and will have a chance to review the information sent and make a decision about it.

+ +
+ GoCD Data Sharing +
+ +

New Loading... screen

+

The GoCD server now starts up into a "Loading …" screen early on in the process. So, if you have scripts waiting on the port to be open, instead use the server health API, which will succeed with an HTTP status of 200 once the server is up. Till then, it'll fail with an HTTP status of 503.

+ +
+ Loading Screen +
+ +

API Improvements

+ + + +

Bug fixes

+ +
    +
  • 9edcd29 - Fixed issue with webhook authentication. (#4945)
    • +
  • db8652b - This fixes issue with analytics not showing up on GoCD instance running on Windows. (#4923)
    • +
  • 941d93f - Fixed an issue with Jobs being hung when agent goes to missing state. (#4823)
    • +
  • 3a1933d - Fixed infinite redirect issue for password and web based plugin. (#4853)
    • +
  • eb7c461 - Fix for Agent not honoring GO_AGENT_LOG_DIR directive in service_mode. (#4718)
    • +
  • 44264c3 - Fixed an issue with VSM pin showing incorrectly. (#3775)
    • +
  • 0d18844 - Fixed missing Stage detail page link for a failing Stage. (#4909)
    • +
+ +

Breaking changes

+
    +
  • As of release 18.2.0 the following (unversioned) APIs had been deprecated and have been removed in 18.7.0. + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • The Plugin Info API v3 deprecated in 18.3.0 has been removed in 18.7.0. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Deprecations

+
    +
  • With the introduction of AES for encryption/decryption in this release, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated as of this release. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated as of this release. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan, ralcini

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.6.0

+
+
+

Improvements

+ +
    +
  • 3541529 - Upgrade to TFS SDK version 14.118.0.
    • +
  • ebdfb7d - Do not log server info at shutdown.
    • +
+ +

Library upgrades

+ +

In order to move towards supporting JRE version 9 and upwards, this release upgrades several libraries used by GoCD, including spring, hibernate, mybatis. See #4785, #4749 and #4768.

+ +

Breaking changes

+ +
    +
  • APIs now respond with an HTTP status code 403(Forbidden) instead of the 401(Unauthorized) when authenticated users are not authorized to view or perform operations on a resource.
    • +
  • URLs containing any un-normalized paths (/../, ./ and /.), semicolon (; and %3B), encoded forward-slash (%2F), backslash (\, %5C), encoded percent (%25) will be rejected.
    • +
  • The pipeline config API version 3 and version 4 have been removed. Please use version 5 of the pipeline config API.
    • +
  • The elastic agent plugin extension version 1 and (a development version 2) has been removed. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features. Users using ECS plugin >= 4.0.0, docker swarm plugin >= 3.0.0, docker plugin >= 0.9.0 and kubernetes elastic agent >= 1.0.0 need not upgrade.
    • +
+ +

Bug fixes

+ +
    +
  • #4737 - Secure variables that were not masked in task plugins are now masked properly.
    • +
  • #4805 - Pipeline history page pagination was broken.
    • +
  • #4757 - Fix Mac installer to use Java 1.8 only.
    • +
  • #4751 - Fix incorrect cache key generation.
    • +
  • #4746 - Fix issue with user preferences page on Microsoft Edge browser.
    • +
  • #4338 - QuickEdit does not allow delete of only stage in pipeline.
    • +
  • #4775 - Dashboard UI rendering duplicate pipeline information.
    • +
  • 5eb1121 - Fix the roles configuration link in the admin dropdown menu.
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for July 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.5.0

+
+
+

Bug fixes

+ +
    +
  • #4724 - Fixed issue with duplicate pipeline instances showing on dashboard due to config-save operations via different methods.
    • +
  • #4727 - Fix spaces in template message in quick edit view.
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.4.0

+
+
+

+ Previously, there was a warning about not upgrading to 18.4. In 18.5, an issue around pipelines created using the pipeline config API showing twice on the dashboard was fixed. We haven't been able to replicate issue #4723 around pipelines created using JSON and YAML plugins, we suspect it might be an issue with the individual's setup. [Updated: 2018 May 11, 11:45 UTC] +

+ +

Performance fix

+ +

This release primarily addresses performance issue caused by a config save, which slows down several requests because of a long-running database query executed in order to update the dashboard.

+ +

We have performed some optimizations in order to significantly reduce the number of SQL calls executed. Read more about it at #4706 and #4705.

+ +

Improvements

+ +
    +
  • #4664 - Improved logging on GoCD server when agent registration fails.
    • +
  • #4610 - Add an origin attribute on fetch task. The origin attribute indicates where to fetch the artifact from. For all artifacts fetched from the gocd server, the value is 'gocd'
    • +
  • #4630 - Upgrade jetty to version 9.4.9.
    • +
+ +

Bug fixes

+ +
    +
  • #4675 - Server side timestamps are rendered properly when daylight saving is in effect.
    • +
  • #4691 - Allow logged in users to access PluginInfos API.
    • +
  • #4673 - Allow null environment variable value in config repo plugins.
    • +
  • #3908 - Allow admin to change selected user in the User summary page.
    • +
  • #4690 - Fixed some issues with case-insensitive renames of pipeline names.
    • +
  • #4698 - Do not truncate long pipeline name.
    • +
  • #4682 - Do not send a HTTP basic authentication challenge for API requests sent by the browser over AJAX.
    • +
+ +

Bundled plugins

+ +
    +
  • Upgraded the bundled LDAP authentication plugin to version 1.0.2. See the plugin CHANGELOG for more details.
    • +
  • Upgraded the bundled file based authentication plugin to version 1.0.2. See the plugin CHANGELOG for more details.
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for June 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated as part of 18.2.0 and will be removed in a release scheduled for June 2018. Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent plugin extension version 1 and (a development verion 2) has been deprecated. These versions will be removed in a release scheduled for June 2018. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking changes

+ + + +

Known Issues

+ +
    +
  • There are a few known minor issues when triggering pipelines on the new dashboard: +
      +
    • #4647 - Trigger buttons do not get disabled if the pipeline was force triggered and material update is in progress
      • +
    • #4452 - Horizontal scroll appears in Trigger With Options Materials popup
      • +
    • #4481 - CCTray corner cases: NullPointerException because of a pipeline not being in the config when the dashboard looks to update itself.
      • +
    +
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.3.0

+
+
+

New Dashboard Page out of Beta

+

After we released the improved GoCD Dashboard (beta) in 18.2.0, we made several bug fixes and performance improvements based on feedback from our users. The GoCD dashboard improves performance for large GoCD instances with thousands of pipelines. In 18.3.0, we have replaced the older version of the dashboard with this improved dashboard which will be available as the default option to all GoCD users.

+ +
+ new dashboard page +
+ +

Enhancements to GoCD's Plugin Architecture

+

We have been working on a few improvements to our plugin architecture.

+ +

Support for adding plugin alerts to GoCD's Errors and Warnings section: +GoCD provides an ability for plugins to add Error and Warning messages. These messages will show up along with the GoCD's own Errors and Warnings. Plugins now have an ability to notify users with any plugin error or warning messages which shows up in GoCD.

+ +
+ Errors and Warnings from Plugins +
+ +

Multiple Extension Support for Plugins: +Plugins can now implement multiple extensions. This will allow plugin developers to create a single plugin to support multiple extensions which complement each other. E.g This would allow one to write a new GitHub PR workflow plugin with both SCM and Notification extensions.

+ +

The plugin info API v4 has been introduced to represent plugins which implement multiple extensions. The two changes are:

+ +
    +
  • "type" is no longer at plugin level. It's at an extension level.
    • +
  • "extension_info" was an attribute. It's now a list called "extensions".
    • +
+ +

Notification Extension V3: +Introduced Version 3 of Notification Extension. This version adds a new message to notify agent state changes.

+ +

Analytics Extension Point: +There is a new analytics extension point which allows analytics to be embedded into GoCD. We are continuing to work on it and you'll hear more about it soon.

+ +

Docker Images

+

A new Docker image GoCD Agent is available for Debian 9.

+ +

Improvements

+
    +
  • #4644 - Environments page no longer lists the pipeline instances, this page is only for listing the available environments and editing them.
    • +
  • #4617 - Ability to turn-off logging of JVM-args and Environment variables to STDERR on GoCD Agent and Server startup.
    • +
  • #4607 - Remove flash filter from agent remoting endpoint
    • +
  • #4278 - Change in Build and Test Artifact XML representation
    • +
  • #4559 - Upgraded Objenesis library to fix performance issues around object cloning.
    • +
  • #4557 - Plugin settings api improvements
    • +
  • #4435 - Add the blacklist textarea to other scm materials in the pipeline creation wizard
    • +
  • #4432 - Setting up one listener per notification plugin to avoid one plugin interfering with others
    • +
  • #4521 - Update config-repo yaml plugin to 0.6.2
    • +
+ +

Bug fixes

+
    +
  • #4656 - Serialise lastBuildTime for CCTray in UTC with timezone
    • +
  • #4466 - Make JSON output invalid on error
    • +
  • #4569 - Update mail sender with mailhost config every time while performing backup.
    • +
  • #4474 - Fixed issue with SPAs popping up a login dialog after session timeout
    • +
  • #4542 - Fix plugin logging concurrency issue
    • +
  • #4496 - Show only pipelines that the user has admin permissions to extract a template.
    • +
  • #4501 - Ensure cancelled stage has lastTransitionedTime.
    • +
+ +

Deprecations

+
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for June 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated as part of 18.2.0 and will be removed in a release scheduled for June 2018. Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent plugin extension version 1 and (a development verion 2) has been deprecated. These versions will be removed in a release scheduled for June 2018. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • +

    The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.

    +
    • +
  • The Agent Docker Image for Debian 7 is deprecated as part of 18.3.0 and will be removed in a release scheduled for May 2018. Users should upgrade to a newer version of the Debian image.
    • +
+ +

Breaking changes

+ + +

Known Issues

+
    +
  • There are a few known minor issues when triggering pipelines on the new dashboard: +
      +
    • #4647 - Trigger buttons do not get disabled if the pipeline was force triggered and material update is in progress
      • +
    • #4452 - Horizontal scroll appears in Trigger With Options Materials popup
      • +
    • #4481 - CCTray corner cases: NullPointerException because of a pipeline not being in the config when the dashboard looks to update itself.
      • +
    +
    • +
  • +

    There is a known issue with API authentication:

    + +

    API requests that wait for a authentication challenge before sending the credentials in the Authorization header fail with 401. +This is due to a bug introduced in the pull request #4585 - 'SPAs - redirect to login page if unauthorized'. +The bug essentially responded with a 401 http response before the WWW-Authenticate header could be added. More details can be found in the github issue #4682.

    +
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Christoph Burgmer, Ganesh S Patil, Isabelle Carter, John Eismeier, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rafael Nunes, Rajiesh N, Senthil R, Steven Streisguth, Ted Timmons, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.2.0

+
+
+

New Dashboard Page (Beta)

+ +
+ new dashboard page + New Dashboard Page +
+ +

This release of GoCD ships with a 'preview' version of the new dashboard page (can be accessed using '/go/dashboard'). This improves performance for large GoCD instances with thousands of pipelines. It does so by:

+ +
    +
  • keeping track of the state of the dashboard in memory (instead of being pulled from the DB).
    • +
  • rendering the response as a JSON (instead of HTML). This improves the rendering time by several hundred times on the server.
    • +
  • a javascript based frontend that is several thousand times faster on large instances, reducing the CPU usage of your browser. Your laptop battery will thank you. :)
    • +
  • reduces the polling rate when the dashboard is shown in a browser tab that is hidden.
    • +
+ +
+

Please report any issues that you observe on GitHub issues. This new dashboard will replace the existing dashboard in one of the upcoming releases of GoCD.

+
+ +

This feature can be turned off by executing:

+ +
curl https://your-go-server/go/api/admin/feature_toggles/quicker_dashboard_key \
+  -d toggle_value=off \
+  -H 'Confirm:true' \
+  -u username:password
+
+ +

Elastic Agent Status Report

+ +
+ elastic agent status report + Elastic Agent Status Report +
+ +

To make it easier to see information about your elastic agent and check logs in case of issues, elastic agent plugins can now provide an elastic agent status report. This report is available from the agents page, and from the job detail page. Docker, Docker Swarm, and Amazon ECS plugins implement this status report feature.

+ +

Elastic Agent Plugin Status Report

+ +
+ elastic agent plugin status report + Elastic Agent Plugin Status Report +
+ +

To make it easier to see information about elastic agent cluster, elastic agent plugins can provide a report about all running agents and the state of the cluster. This report is available from the plugins page. Docker, Docker Swarm, and Amazon ECS plugins implement this status report feature.

+ +

API Improvements

+ +
    +
  • +

    612c66a - Introduction of pipeline pause api and unpause api. (#4076).

    + +

    The old pause/unpause APIs have been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    b52aff7 - Introduction of pipeline unlock API. (#4237).

    + +

    The old pipeline unlock API has been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    666b206 - Introduction of pipeline schedule API. (#4319).

    + +

    The old pipeline schedule API has been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    6dfa18f - Introduction of server health messages API. (#4256).

    + +

    This endpoint will render the warnings and errors that were earlier visible only when clicking on the "errors and warnings" modal on the GoCD server

    +
    • +
  • +

    0353bb6 - Introduction of Template Authorization API. (#3081).

    +
    • +
  • +

    9c4829e - Support gitlab@ urls for gitlab webhooks. (#4211)

    + +

    Many GitLab installations use gitlab@ as a git user. This was once a default user for GitLab installs. Due to this the urls for ssh connections from gitlab can include this user.

    +
    • +
+ +

Improvements

+ +
    +
  • Introduce environment variables GO_MATERIAL_HAS_CHANGED and GO_MATERIAL_${material name or dest}_HAS_CHANGED to indicate if materials have changed from the previous pipeline run, and if materials have changed, which materials have changed. Read more about these variables in the help documentation.
    • +
+ +

Docker images

+ +

We have introduced the GoCD Agent Docker in Docker image. This can be used to run the docker related tasks such as building a docker image, pushing to a registry etc. Advanced use-cases include containerizing the application and running tests using DInD.

+ +

Read more about changes with docker images for the server docker image and agent docker image.

+ +

Bug fixes

+ +
    +
  • +

    With the introduction of the server health messages API, we can now show server health messages on some of the pages introduced in the last several releases, viz. roles, authorization configuration, agents, elastic profiles, plugin settings.

    +
    • +
  • +

    #3899 - Fixed an infinite redirect issue when logging in using web based authentication plugins

    +
    • +
  • +

    #3926 - Handle console logs better with utf-8 encoding

    +
    • +
  • +

    157f12d - Enforce http(s) URL scheme for tracking tools. (#4356)

    + +

    This will add an http:// prefix to tracking tool links that do not start with http:// or https://.

    +
    • +
  • +

    The plugin settings request is supported for the SCM and Package repository extensions on the plugins SPA. The plugin settings that can be configured for scm and package repo plugins are made use of only on the server side.

    +
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2 the following (unversioned) APIs have been deprecated and will be removed in 18.5 (scheduled to be released in May 2018): + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated and will be removed in 18.5 (scheduled to be released in May 2018). Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent api version 1 and (a development verion 2) has been deprecated. These versions will be removed in 18.5 (scheduled to be released in May 2018). Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.3.0 (scheduled to be released in March 2018).
    • +
+ +

Breaking changes

+ +
    +
  • Version 1 of the users api has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
+ +

Known issues

+ +
    +
  • There are a few known issues when triggering pipelines using the trigger with options feature on the new dashboard: +
      +
    • #4488 - If for a material no revision selected on trigger with options, schedules with latest revision
      • +
    • #4489 - If invalid revision specified do not trigger pipeline
      • +
    • #4448 - Pipeline with lock behavior specified continues to be locked after run completion under certain conditions
      • +
    +
    • +
+ +

Contributors

+ +

Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Charles Bryant, Christian Lövsund, Don Stewart, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Paul Thomas, Rajiesh N, Senthil R, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

18.1.0

+
+
+

Bug Fixes

+
    +
  • f9ad399 - Validate roles assigned to stage authorization on template update through API. (#4185) #4176
    • +
  • 63d7d0f - Test artifacts configured using config-repo is uploaded to GoCD server's build artifacts' default location. (#4083) #4071
    • +
  • 1442a09 - Get Pipeline Config API failed to find pipeline for remote configured pipelines. (#4010) #4008
    • +
  • addf343 - Fix path of logback-include.xml. (#4145)
    • +
  • d409d23 - Fix whitelist in configrepo hg material. (#4191)
    • +
  • 8971a71 - Do not allow agent to register with duplicate elastic agent id. (#4133)
    • +
+ +

Docker Images

+
    +
  • Published an updated GoCD Server and Agent docker image for the latest version of Alpine (3.7)
    • +
+ +

Breaking Changes

+ + +

Deprecations

+
    +
  • As of release 17.11, version 1 of the users API is deprecated. This version of the API will be removed in 18.2.0 release (scheduled to be released in February 2018). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.2 (scheduled to be released in February 2018).
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.12.0

+
+
+

UX Changes

+
    +
  • +

    0e92610 - Newer plugins page. (#4030).

    + +

    As a part of an ongoing UI/UX refresh, we have introduced the new plugins page:

    +
    • +
+ +
+ Plugins SPA +
+ +

Other Improvements

+
    +
  • +

    0ee52b3 - Disallow an authenticated user from re-authentication. (#3940)

    + +

    With this change, an authenticated user is re-directed to home page on trying to access the login page.

    +
    • +
  • +

    6fda2f5 - Add new unlock behavior. (#3943) #106

    + +

    As a part of this change, two types of locking behavior are introduced:

    + +
      +
    • +

      Run single instance of pipeline at a time ("Lock behavior: Unlock when finished")

      +
      • +
    • +

      Run single instance of pipeline and lock on failure ("Lock behavior: Lock on failure")

      +
      • +
    + +

    More information can be found in the docs.

    +
    • +
  • +

    979fa50 - Addition of pipeline count information to about page. (#3960)

    +
    • +
+ +

Bug Fixes

+
    +
  • ab1ccf8 - Fix config file validation to not use file system to validate paths. This caused issues in certain cases where the server working directories were using symlinks. (#4026) #3984
    • +
  • 6660a1b - Show 'console log not available' error in build details page's console tab when console.log file is not available. (#3998) #3773 #3650
    • +
  • e48d958 - Fixes console.log file not being available at server if websocket connection is closed while waiting for logs. (#3999) #3986
    • +
  • ee992e6 - Fixes issue in agent zip installers in which agents fail to register if their log directories' path have spaces in them. (#3976) #3966
    • +
  • e6c9b3a - Fixes issue with stale cache being used in CCtray which caused users associated with plugin-roles to not see pipelines which they were authorized to see otherwise. (#3955) #3954
    • +
  • 449cbc3 - Allows overriding default Go server ports when using windows service. (#4038) #3982
    • +
+ +

Security Fixes

+
    +
  • +

    488712d - Token based approach for agent registration. (#4014)

    + +
      +
    • Adds a new endpoint to get token from server in exchange of agent uuid. The token for a given agent is issued for unknown agents only - already registered or pending agents cannot request for a token.
      • +
    • Agent requests for a token before registration if required. This token is stored on agent's disk and reused for registration calls.
      • +
    + +

    Note: As a result of this fix, Go-lang agents need to be updated to work with GoCD server versions 17.12 or higher, else the agent's registration would fail. +Golang agent users can follow up with the author on this issue.

    +
    • +
+ +

API Changes

+ + +

Docker Images

+
    +
  • Addition of ability to run custom scripts while starting up the gocd-server or gocd-agent using the official GoCD docker images. #46
    • +
+ +

Breaking Changes

+
    +
  • +

    cdf6722 - Remove code related to starting vncserver. (#4028) #4005

    + +

    Alternatives to using the VNC flag are mentioned in this comment.

    +
    • +
+ +

Deprecations

+
    +
  • As of release 17.11, version 1 of the users API is deprecated. This version of the API will be removed in 18.1.0 release (scheduled to be released in January 2018). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.5, authentication plugin endpoints have been deprecated. Support for these plugins will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. The following plugins are affected by this deprecation: + +
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.2 (scheduled to be released in February 2018).
    • +
  • As of release 17.9, version 2 of the plugin info API is deprecated. This version of the API will be removed in 18.1.0 release (scheduled to be released in January 2018). Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, EugenMayer, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Senthil R, Szymon Chojnacki, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.11.0

+
+
+

UX Changes

+
    +
  • +

    67f1605 - Find Value Stream Map (VSM) more easily and show pipeline run duration in VSM. (#3705) (#3858)

    + +

    Pipeline instances have an explicit link to VSM across the application for better discoverability.

    + +
    + Explicit vsm link in dashboard +
    + +

    Pipeline run duration shown in VSM:

    +
    + Pipeline run duration in VSM +
    +
    • +
+

Improvements

+ +
    +
  • a8d09f3 - Added support for parameters and template references in config repo pipelines. (#3851) (#3849)
    • +
  • 36b675e - Added support for bitbucket webhook. (#3862)
    • +
  • 6320d55 - Added support for gitlab webhook. (#3862)
    • +
  • 2cb4c00 - GoCD Server session timeout has been made configurable. (#3856) (docs)
    • +
  • e51f3b6 - GoCD Agent supports configuring proxies. (#995)
    • +
+ +

Breaking Changes

+
    +
  • +

    f501efc - Move over to logback from log4j for logging. (#3831)

    + +
      +
    • Switching to logback solves a number of logging related issues such as #3588, #3557 and #3403
      • +
    • The users should now configure logging using corresponding logback.xml instead of log4j.properties for both server and agents (docs).
      • +
    • This has been marked as a breaking change since GoCD would no longer honour log4j.properties file. Users managing log4j.properties file externally would have to update their scripts to use the logback.xml instead.
      • +
    +
    • +
  • +

    Support for phusion based docker server and agent images have been removed this release. We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04

    +
    • +
+ +

Performance Fixes

+
    +
  • eb7305e - Fixes memory leak issue in agent-bootstrapper/launcher caused by server upgrades. (#3792)
    • +
+ +

Bug Fixes

+
    +
  • cef6649 - Fixes a race condition during Job reschedule. (#3891)
    • +
  • a1f9945 - Improves checksums for agent jar(s) download. (#3884)
    • +
  • 4db7e52 - Does not show the settings icon for config repo pipelines on VSM. (#3892) (#3881)
    • +
  • 686c76d - Fixes issue with users authenticated using WebBasedAuthentication not assigned the right permissions. (#3878)
    • +
+ +

API Changes

+ + +

Docker Images

+
    +
  • We have made a few changes to the GoCD Server (Changelog) and the GoCD Agent (Changelog) Docker images.
    • +
+ +

Deprecations

+ + +

Note

+
    +
  • With release 17.5.0 support for in-built password file and LDAP/AD authentication had been deprecated. In this release support for this has been removed in favour of the bundled LDAP and Password File plugins respectively.
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Drew J. Sonne, Emily Luke, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mikhail Advani, Naveen Bhaskar, Rajiesh N, Senthil R, stayclassychicago, Suzie Prince, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.10.0

+
+
+

Important: After the 17.9 release, we made an announcement asking users to hold off upgrading their GoCD instance. We found an issue (#3834) affecting a small set of users. This release provides a fix for the same.

+ +

Critical Bug Fixes

+
    +
  • 05598d8 - Unable to start the server after 17.9.0 upgrade. (#3834)
    • +
+ +

Other Changes

+
    +
  • 176ebc2 - Fix for no plugins visible after 17.9.0 upgrade. (#3829)
    • +
+ +

Docker Images

+ + +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Roman Gorodeckij, Senthil R, Suzie Prince, Varsha Varadarajan

+ +

Note

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ + +
+
+

17.9.0

+
+
+
Sep 11 13:00 UTC 2017: We are investigating an issue (#3834) with upgrades affecting a small number of users. Please hold off on upgrading to 17.9.0 until further notice.
+ +

Improvements

+
    +
  • +

    928c585 - Grouping elastic profile by plugin ID. (#3772)

    + +

    We have created an organized view of the elastic agent profiles. Now, you can view them by the type of elastic agent plugin (Docker Swarm, OpenStack, ECS etc.), making it easier to find a particular profile.

    + +
    + Group elastic profile by plugin id +
    +
    • +
  • +

    1c1f2fe - Administrators can choose to edit a Pipeline with one-click from the Value Stream Map.

    + +
    + Edit pipeline from VSM +
    +
    • +
  • +

    ca7c3fa - Addition of a request processor to allow plugin authors to query information from the GoCD server. (#3401)

    +
    • +
+ +

API Changes

+ + +

Bug Fixes

+ +
    +
  • +

    4c9e3c9 - Removed memory leaks from agent bootstrapper.

    + +

    GoCD agents are designed to automatically upgrade themselves when the GoCD server is upgraded. This requires the currently running agent to release all resources before exiting and handing over control to a newer version of the agent process. There were some file system resource and memory leaks that have been identified which affect versions of go-agent bootstrapper between 17.4 and 17.8. We recommend that users either upgrade their gocd server and agent versions to the latest version, or restart the agent process to release any memory and filesystem resources that may be locked by the agent process.

    +
    • +
  • e538ba0 - Check if agent is disabled before job assignment.
    • +
  • d47180f - Addition of a few more fields to materials form which is used in creation of pipelines.
    • +
  • 8f6cc6c - Send request headers from server to plugins.
    • +
  • 0eab696 - Stage and job related warnings should not be logged for a rerun stage/job. (#3753)
    • +
  • 8f66499 - Fixes select all bug on admin edit in environment page. (#3737)
    • +
  • 793d198 - Redirect authenticated user to home page on re-authentication.
    • +
+ +

Docker Images

+
    +
  • GoCD images make logs available to docker by writing them to STDOUT. Users can access the logs anytime by executing   docker logs   in both server and agent containers.
    • +
  • We've launched an updated GoCD Agent docker image for the latest version of Alpine (3.6)
    • +
+ +

Breaking Changes

+

If you are using the commercial Amazon ECS Elastic Agent Plugin, upgrading to GoCD 17.9.0 would require a plugin upgrade to V2.0.0.

+ +

Deprecations

+
    +
  • As of release 17.9, version 2 of the plugin info API is deprecated. This version of the API will be removed in 17.12.0 release (scheduled to be released in December 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.5, authentication plugin endpoints have been deprecated. Support for this plugin will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. +
    Authentication plugins
    + +
    • +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.10 release (scheduled to be released in October 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other actions necessary.

    +
    • +
  • As of 17.8, the phusion based docker server and agent images are deprecated in favour of the new docker server and agent images. Support for the phusion images will be removed in 17.11.0 (scheduled to be released in November 2017). We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Other Changes

+
    +
  • dc39953 - Config repo change attribute "plugin" to "pluginId". (#3672)
    • +
  • 3c9a8f1 - Addition of a toggle to make pipeline quick edit page as a default page. (#3722)
    • +
  • 19210e4 - Always open console tab when job name is clicked. (#3742)
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Pedro Carriço, Rajiesh N, Senthil R, Stephen Murby, Suzie Prince, Tim Brown, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.8.0

+
+
+

Pipeline as Code

+ +

With this release, GoCD supports Pipeline as code, out of the box. We've bundled the JSON config repo plugin and the YAML config repo plugin with the GoCD server. +A shout out to our core contributor Tomasz Sętkowski for maintaining these plugins.

+ +

Amazon ECS Elastic Agent Plugin

+ +

Thoughtworks now offers a new commercial plugin which allows you to run elastic agents on Amazon ECS. The plugin takes care of spinning up and shutting down EC2 instances based on the need of your deployment pipeline. For more information about this, click here.

+ +

Improvements

+ +
    +
  • 1ccb029 - Ensure order of auth_config is used to authenticate users. (#3608)
    • +
  • 36d546e - Removed support for Team Foundation Server 2010. Users can continue to use GoCD with TFS 2012, 2013, 2015 and Visual Studio Team Services.
    • +
  • d7c4d16 - Display pause text in pipeline history. (#2784)
    • +
  • 52ac924 - Save agent hostname and ip address as part of build history. This information will be displayed on the job details page for all kinds of agents. (#3368)
    • +
+ +

Docker Images

+ +
    +
  • Some improvements have been made to reduce the size of the docker GoCD server image. Please check the changelog here.
    • +
  • Some improvements have been made to create slimmer docker GoCD agent images. Please check the changelog here. +We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other action necessary.

    +
    • +
  • As of 17.5, authentication plugin endpoints have been deprecated. Support for this plugin will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. +
    Authentication plugins
    + +
    • +
  • As of 17.8, the phusion based docker server and agent images are deprecated in favour of the new docker server and agent images. Support for the phusion images will be removed in 17.11.0. + We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Huimin Li, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kyle Olivo, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Suzie Prince, Tomasz Sętkowski, Varsha Varadarajan, Victor Nascimento

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.7.0

+
+
+

Security Fixes

+ +

Important: This release comes on the back of 17.6.0 as we have identified a critical security vulnerability with 17.5.0 and 17.6.0. If you are on 17.5.0 or 17.6.0, please upgrade immediately to this version to keep your GoCD server secure. We want to give sometime for users to upgrade before disclosing the details of the vulnerability.

+ + +
+
+

17.6.0

+
+
+

Important

+ +

There has been a critical security vulnerability identified with this release, fixes for the same have been provided in 17.7.0. If you are on 17.6.0, please upgrade immediately to 17.7.0 to keep your GoCD sever and agent secure.

+ +

Security Fixes

+ +

This release has critical security fixes to prevent CSRF, XSS and Session hijacking exploits. We highly recommend users to upgrade to keep your GoCD server and agent secure. +Thanks 4cad for reporting these issues.

+ +

Improvements

+ +
    +
  • +

    42c681d - Added option to skip agent startup on windows. (#3577)

    + +

    This adds a /START_AGENT=NO to prevent the agent service from starting up when performing a headless installation on windows. See the documentation for more details.

    +
    • +
  • +

    2c95a10 - Improve timestamp rendering on some pages. (#3574)

    + +

    This improves the timestamp rendering on the job details, stage details and pipeline compare pages. You will now see timestamps in your local timezone.

    + +
    + Improve timestamp rendering +
    + +
    + Improve timestamp rendering +
    +
    • +
  • +

    9450dba - Add a "Rerun Failed" button to rerun failed jobs. (#3570)

    + +
    + Rerun failed jobs +
    +
    • +
  • +

    The in-built password file authentication plugin now supports bcrypt, which is a stronger password hashing function. GoCD server administrators should migrate SHA1 passwords to use bcrypt instead.

    +
    • +
+ +

API Enhancements

+ +
    +
  • Introduced a GitHub webhook API to accept push events on a GitHub repository or repositories in a GitHub organization.
    • +
+ +

Bug Fixes

+ +
    +
  • +

    88f1678 - Disable trigger with options button for view user in the environments page. (#3602)

    +
    • +
  • +

    dba8212 - Javascript error when saving user preferences. (#3576)

    +
    • +
  • +

    30615dc - Reduce the amount of plugins that an agent downloads and initializes. (#3584)

    + +

    This should reduce the amount of data an agent downloads when a plugin is installed, or the server is upgraded. This will also help reduce the amount of memory used by the GoCD agent process.

    +
    • +
+ +

Breaking Changes

+ +
    +
  • +

    8dfb1a9 - Removed Environments Config API v1. (#3606)

    + +

    Version 1 of the Environment Config API was deprecated in 17.3. Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other action necessary.

    +
    • +
  • +

    The Authorization Plugin endpoints were introduced as an extension to the existing Authentication Plugin endpoints, with this Authentication Plugin endpoint were deprecated as of 17.5.0. Support for this plugin would be removed in 18.1 (scheduled to be release in January 2018). Plugin developers are encouraged to migrate their plugins to use the new Authorization Plugins.

    +
    Authentication plugins
    + +
    • +
+ +

Contributors

+ +

Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Drew Sonne, Jyoti Singh, Kerry Wilson, Ketan Padegaonkar, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Sean Escriva, Stephen Murby, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.5.0

+
+
+

Important

+ +

There has been a critical security vulnerability identified with this release, fixes for the same have been provided in 17.7.0. If you are on 17.5.0, please upgrade immediately to 17.7.0 to keep your GoCD sever and agent secure.

+ +

Authorization Plugin

+ +

Authorization Plugin extension was released as beta in GoCD 17.2.0, over the last couple of releases there has been more work done around fine tuning the endpoint. With this release we are taking the Authorization Plugin endpoint out of beta.

+ +

Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading GoCD. Refer to the Authorization Plugin Endpoint documentation for the latest changes.

+ +

The built-in LDAP and password file based authentication mechanisms have been deprecated and disabled in favor of separate plugins which implement the new Authorization Plugin extensions. The new plugins provide more functionality, with the benefit of allowing users to customize the behavior of these plugins. These plugins are bundled with the GoCD server, so no action will be required from users. Existing passwordFile and ldap configuration would be migrated to make use of these plugins.

+ +
    +
  • +

    LDAP/AD authentication plugin

    + +

    The bundled LDAP/AD authentication plugin will now allow users to connect to and authenticate with multiple LDAP/AD servers in their organizations. Early adopters of this plugin using the experimental build will have to make changes to their config. Refer to the plugin changelog to see the changes between experimental release to latest stable release.

    +
    • +
  • +

    Password File Authentication Plugin

    + +

    The bundled Password File Authentication Plugin currently supports only SHA1 hashed passwords, but support for other hashing functions is on its way.

    +
    • +
+ +

There are 2 new sets of pages that allows configuring the authorization plugins and mapping of GoCD roles to users.

+ +
+ GoCD Security Menu +
+ +
+ Example LDAP server configuration +
Example LDAP connection configuration
+
+ +
+ Example GoCD role to LDAP group mapping +
Example GoCD role to LDAP group mapping
+
+ +

API Enhancements

+ + + +

Bug Fixes

+ +
    +
  • +

    9cec83f - Stop very large file systems (EFS) from being identified as having no space. (#3426)

    + +

    Large filesystems like EFS, have an amount of storage that exceeds what can be addressed with a java long type (263-1). Any storage space greater than 263-1, will be shown to be 263-1.

    +
    • +
  • +

    2b06534 - Pipeline not getting unlocked upon a successful run. (#3497)

    + +

    Fixed a issue of pipelines not getting unlocked even upon a successful run of the last stage during a race condition.

    +
    • +
  • +

    26bfeab - Avoid catastrophic regex backtracking during config save. (#3551)

    + +

    Fixed an issue to avoid catastrophic regex backtracking during xsd validation of custom task command.

    +
    • +
  • +

    2a21e7c - Using UTF-8 to read console to fix encoding issue. (#3486)

    +
    • +
  • +

    e89fdb6 - CCTray permission bug fix. (#3516)

    + +

    Allow users to see all pipelines in CCTray when no global superadmins are setup to make the behavior consistent with dashboard.

    +
    • +
+ +

Breaking Changes

+ +
    +
  • +

    bd64d11 - Removed Templates API v2. (#3441)

    + +

    Version 2 of the Templates API was deprecated in 17.1. Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    Support for in-built password file and LDAP/AD authentication have been deprecated as of this release. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017).

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API was deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    The Authorization Plugin endpoints were introduced as an extension to the existing Authentication Plugin endpoints, with this we are deprecating the Authentication Plugin endpoint. Support for this plugin would be removed in 18.1 (scheduled to be release in January 2018). Plugin developers are encouraged to migrate their plugins to use the new Authorization Plugins.

    +
    Authentication plugins
    + +
    • +
+ +

Contributors

+ +

Ankit Srivastava, Aravind SV, Badri J, Bhupendrakumar Piprava, Chris Northwood, David Rice, Emily Luke, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kyle Olivo, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Rajiesh N, Suzie Prince, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.4.0

+
+
+

UI Enhancements

+ +
    +
  • d6d59fb - Enhanced console log view with an option to expand/collapse outputs of comamnds. (#3199) +
    + Foldable Console Logs +
    +
    • +
  • +

    a4d669c - Full screen mode for console logs. (#3293)

    + +
    + Full screen mode +
    +
    • +
  • +

    8bcc3c7 - Add toggles to timestamps. (#3199)

    + +
    + Timestamp toggle +
    +
    • +
  • +

    f4a3b07 - Job run history dropdown. (#3299)

    + +
    + Job Run History dropdown +
    +
    • +
  • +

    87b223c - Errors/warnings box in the header. (#3378)

    + +
    + Errors/warnings box +
    +
    • +
  • +

    b9e1c20 - Colored border to bottom of job details header. (#3408)

    + +
    + Job Deail header border +
    +
    • +
+ +

Authorization Plugin (Beta)

+ +

There has been more work done around fine tuning the Authorization Plugin endpoints, as part of this some of the plugin API calls have changed. Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading Go. Refer Authorization Plugin Endpoint documentation for the latest changes.

+ +
    +
  • eddecb7 - Verify Connection API response has status, message and errors. (#3395)
    • +
+ +

Performance Improvements

+ +
    +
  • 11f19db - Moving pipeline state to a separate table which for now contains locked information about the pipeline. Read locks is held only if we are loading the state from db. (#3204)
    • +
+ +

Other Improvements

+ +
    +
  • 0ac7678 - Displaying pipeline schedule time as localtime on dashboard, environments page and pipeline-history page. Users can hover over it to see timezone information. (#3417)
    • +
  • d13f81a - Switch agent-bootstrapper to use the new logging mechanism. The bootstrapper now has its own agent-bootstrapper-log4j.properties file under the config directory. (#3267)
    • +
  • 567820c - Switch agent-launcher to use the new logging mechanism. The launcher now has its own agent-launcher-log4j.properties file under the config directory.
    • +
  • b1af25f - Display plugin name instead of plugin id in the dropdown in the elastic agent profiles page. (#3324)
    • +
+ +

Bug Fixes

+ +
    +
  • ba510ad - Server now checks if the elastic agent is brought up by the same plugin as was expected by the scheduled elastic job during assignment. (#3418)
    • +
  • b0f4359 - Handle pluggable task view when task plugin is missing. (#3320)
    • +
  • 404002e - Render the elastic agent icon only if the plugin info exists for the elastic agent. (#3314)
    • +
+ +

Security Fixes

+ +
    +
  • 51de8bc - Encrypting secure variables for Elastic Agent plugin settings. (#3356)
    • +
+ +

Breaking Changes

+ +
    +
  • #3267 - On GoCD agents installed on windows or if using the zip installers, logs will now be written to logs directory instead of the working directory. This would be a breaking change only if there are custom scripts relying on the logs location.
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • +

    As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.5 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API was deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Docker Images and AMIs

+ +
    +
  • The GoCD server docker image is now alpine based with support for volume mounts. +
      +
    • To find out what changed in the docker server image, please refer to the changelog.
      • +
    +
    • +
  • You can download the docker images for GoCD agents across the following operating systems - CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04 +
      +
    • To find out what changed in the docker agent images, please refer to the changelog.
      • +
    +
    • +
  • We have an Amazon Linux based AMI for the GoCD Server making it very simple to launch GoCD server on your AWS EC2 instance.
    • +
  • We have an Amazon Linux based AMI for a demo GoCD Server and Agent making it very simple to get started with GoCD on your AWS EC2 instance.
    • +
+ +

Feedback is appreciated. Please log your feedback or issues on github for the following -

+ + + +

Contributors

+ +

Ankit Srivastava, Aravind SV, Badri Janakiraman, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Lubaina R, Mahesh Panchaksharaiah, Markandan R, Marques Lee, Rajiesh N, Suzie Prince, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.3.0

+
+
+

UI Enhancements

+ +
    +
  • 320f223 - Enhanched job/stage status accessibility with addition of symbols to signify stage and job statuses. (#3233) +
    + Stage and Task Symbols +
    +
    • +
  • cfc778e - Build status indicator moved from build summary to breadcrumb toolbar. (#3270) +
    + Build Status +
    +
    • +
  • 5478a54 - Agents page improvement for better identification of elastic agents by addition of icon related to the type of agent in use. (#3276) +
    + Elastic Agent Icon +
    +
    • +
+ +

API Enhancements

+ +

6986dcc - Added v2 of Environment Config API with support to PATCH environment-variables. (#3080)

+ +

Authorization Plugin (Beta)

+ +

There has been more work done around fine tuning the Authorization Plugin endpoints, as part of this some of the plugin API calls have changed. Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading Go. Refer Authorization Plugin Endpoint documentation for the latest changes.

+ +

Other Improvements

+ +
    +
  • 262c107 - Pipeline Quick Edit, disable edit until save completes. (#3266)
    • +
+ +

Bug Fixes

+ +
    +
  • 8224568 - This fixes 17.2.0 upgrade failures in cases where cruise_config xml had encrypted values with spaces. (#3244)
    • +
  • 4db0550 - Agents page retain sort order across page refresh. (#3226)
    • +
  • 73e0292 - Elastic Agents, fixed reduntant agent creation calls to the plugin. (#3193)
    • +
  • 5d75f45 - Agents page memory leak fix. (#3217)
    • +
+ +

Breaking Changes

+ +
    +
  • On GoCD servers installed on windows or if using the zip installers, logs will now be written to logs directory instead of the working directory. This would be a breaking change only if there are custom scripts relying on the logs location.
    • +
  • The gocd/gocd-server docker image now uses alpine as the base image.
    • +
  • The gocd/gocd-server docker image no longer recognizes the latest tag. Please use docker pull gocd/gocd-server:v17.3.0 instead.
    • +
  • The gocd/gocd-agent docker image no longer exists. We have a variety of agent images for different distributions.
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • +

    As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API is deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Docker Images and AMIs

+ +
    +
  • The GoCD server docker image is now alpine based with support for volume mounts, with this going forward there will be no more support for phusion based images.
    • +
  • You can download the docker images for GoCD agents across the following operating systems - CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
  • We have also introduced an Amazon Linux based AMI for the GoCD Server making it very simple to launch GoCD server on your AWS EC2 instance.
    • +
+ +

Feedback is appreciated. Please log your feedback or issues on github for the following -

+ + + +

Contributors

+ +

Ankit Srivastava, Aravind SV, Barrow KwanBhupendrakumar Piprava, Etienne Dysli Metref, Ganesh S Patil, Isabelle Carter, Junaid Shah, Jyoti Singh, Karel Bemelmans, Ketan Padegaonkar, Kiera Radman, Kyle Olivo, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh Narayanan, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.2.0

+
+
+

Authorization Plugin Endpoint (beta)

+ +

GoCD currently supports password-file, LDAP and plugin based authentication.

+ +

In addition to authentication, GoCD offers authorization by restricting certain operations to specific users and groups of users ("roles").

+ +

Without the use of authorization plugins, roles can only be managed through GoCD and it does not provide an ability to use roles defined in systems used for authentication (for example in LDAP groups). With this limitation, administrators need to configure roles in multiples places.

+ +

The introduction of the authorization plugin endpoint (Beta) allows GoCD to delegate both authentication and authorization of users to plugins. The plugins will have the flexibility to use any identity service providers like LDAP, Google, GitHub etc.

+ +

Authorization Plugin Endpoint (beta) documentation is available. We have built LDAP Authentication plugin using the Authorization Plugin Endpoint, this plugin supports only authentication. We would recommend developers to write plugins which support both authentication and authorization and provide us feedback to enhance this endpoint.

+ +

Feature Enhancements

+ +
    +
  • +

    c088435 - Template Authorization UI and API enhancements.

    + +
      +
    • All pipeline group admins by default provided view permission to templates. Super admin can restrict this access.
      • +
    • Super admin can provide template view access to users/roles.
      • +
    • Allow template admins to delete templates via UI and API
      • +
    + +
    + Template Permissions +
    +
    • +
+ +

Other Improvements

+ +
    +
  • 3b9f54b - Go server/agent services do not get started on a new installation for debian and rpm based installations in order to allow users to make configuration changes before starting them up. (#3119)
    • +
+ +

Bug Fixes

+ +
    +
  • 7ddf84e - User search functionality - Search through plugins implementing AuthenticationExtension. (#3107)
    • +
  • ad1a118 - Sort resources and environments alphabetically on agents page selector dropdown. (#3134)
    • +
  • Multiple UI fixes on the old and new themes.
    • +
+ +

Security Fixes

+ +
    +
  • a837fc0 - Ensures passwords in git or hg material url's is masked before logging or using in server health message. (#3171)
    • +
+ +

Breaking changes

+ + + +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aravind SV, Bhupendrakumar Piprava, Dmitry Ledentsov, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kyle Olivo, Lubaina R, Mahesh Panchaksharaiah, Markandan R, NaveenBhaskar, Rajiesh Narayanan, Stephen Gran, Sumanth Kumar Mora, Varsha Varadarajan, cnenning

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.1.0

+
+
+

Performance Improvement

+ +
    +
  • +

    2ae7fdb - Full config save optimization. (#2912)

    + +

    Optimization to full config save through UI and API to give significant improvements in the config save time. Our performance runs show full config save times reduced by half.

    +
    • +
+ +

API Enhancements

+ + + +

Plugin enhancements

+ + +

Other Improvements

+ +
    +
  • c094e90 - Added environment variables to the server api page. (#3073)
    • +
  • 0802c7e - Added CPU time in api/support for the threads. (#3006)
    • +
  • c749c47 - Added a link to pipeline settings in the pipeline history page. (#2939)
    • +
+ +

Bug Fixes

+ +
    +
  • Multiple UI fixes and tweaks on the new theme that was introduced in 16.12.
    • +
  • e9611f8 - Refresh ElasticAgent-OperatingSystem and ElasticAgent-UsableSpace while initializing the runtimeInfo. (#3078)
    • +
  • b66bddc - Refactor agent controller to switch between http and websockets. (#2864)
    • +
  • c26f118 - Mask password entered for materials of type svn, tfs, perforce. (#2937)
    • +
  • 4b684ee - Provide template admin authorization to users within a role. (#2989)
    • +
  • df85694 - Additional validations for templates API. (#3035)
    • +
+ +

Breaking changes

+ +
    +
  • +

    920b7ee - Removed support for Java 7.

    + +

    Starting with the 17.1 release of GoCD, Server and Agents will only run with Java 8. Users are encouraged to upgrade to the latest release of GoCD with Java 8.

    + +

    Windows installations of GoCD need not install Java 8 separately since the Windows installer comes bundled with a JRE. However this may require users to upgrade the agent installer on Windows.

    + +

    If you have trouble while upgrading to Go version 17.1, please take a look at the + troubleshooting page in the + documentation.

    +
    • +
  • +

    7a48c1a - Removed GoCD OpenSocial Gadget (Card activity tab) and Pipeline Dashboard Widget in Mingle. (#1908)

    + +

    As of release 16.12, the OpenSocial gadgets was deprecated. This feature is now removed because of a couple of reasons — + (a) there's not enough evidence of many users using this feature in a way that'll impact their usage of GoCD + (b) the underlying implementation framework (Apache Shindig) hasn't been maintained for quite some time and contained several security vulnerabilities.

    +
    • +
  • +

    7274d23 - Removed Version 2 and 3 of the Agents API. (#2984)

    + +

    As of release 16.12, version 2 and version 3 of the Agents API was deprecated. Version 2 of Agents API was introduced in 15.3.0 and version 3 of the API was introduced in 16.8. These versions of the API have been removed in favor of version 4 of this API. This API is backward compatible, and users are encouraged to use it.

    +
    • +
  • +

    1e48c42 - Removed Templates API Version 1.

    + +

    As of release 16.11, version 1 of the Templates API was deprecated. Users are encouraged to use Version 3 of the API which is backward compatible with Version 1.

    +
    • +
  • +

    f2ac6b1 - Removed support for text based API support log. (#2975)

    +
    • +
  • +

    da61c2b - Removed old Agents page. (#3015)

    +
    • +
+ +

Deprecations

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • As of release 16.12, git versions older than 1.9 are deprecated. Support for git versions older than 1.9 will be stopped in 17.2 (scheduled to be released in February 2017). Users are recommended to upgrade git on the GoCD server and agents (if git is used as a material). We are aware that the linux distributions have an older version of git installed by default. Please refer to this to upgrade git.
    • +
  • As of release 16.12, version 1 of the Plugin Info API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.1, version 2 of the Templates API is deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 of the Pipeline Config API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 3 of this API is backward compatible, and users are encouraged to use it.
    • +
  • +

    As of release 16.7, Java API based Go Plugins have been deprecated. Support for running these plugins will be removed in 17.2 (scheduled to be released in February 2017). Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins.

    + +

    Below is the list of plugins that will stop working in 17.2.

    + +

    Note: The GoCD team has built a shim that allows migration of all plugins with minimal change. We are actively working with plugin authors to ensure that these plugins are migrated over in time for 17.2.

    + +

    Package plugins

    + + + +

    Task plugins

    + + +
    • +
+ +

Contributors

+ +

Alison Polton-Simon, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, Markandan R, Naveen Bhaskar, Padma Mullagiri, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Setkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.12.0

+
+
+

UI Refresh

+ +

The entire application has been refreshed to sport a flat look.

+ +

If you have feedback or issues with the new look please log them at GitHub.

+ +
+ New Theme +
+ +

Agents Page

+ +

A brand new snappy and light-weight replacement for viewing and managing agents!

+ +

The old page is still available as a toggle. +If you have feedback or issues with the new agents page please log them at GitHub.

+ +
+ Agents Page +
+ +

Elastic Agents

+ +

Elastic agents is now a fully supported feature in GoCD.

+ +

To be able to use elastic agents, you should install an existing elastic-agent plugin, or write your own. Once the plugin is installed you must configure an "elastic agent profile" that you can associate with the jobs that require elastic agents.

+ +
+ Create Elastic Profile +
+ +

TFS Upgrade

+ +

We have upgraded to TEE SDK 14.0.3. Users will now be able to use GoCD with TFS 2012, 2013, 2015 and Visual Studio Team Services. Please file an issue if you're having issues connecting to TFS repositories. Earlier versions of TFS are no longer supported and may not work.

+ +

Pipeline Edit Link

+ +

Users can now directly navigate to the pipeline settings page from the stage and job detail page.

+ +

API Enhancements

+ +
    +
  • 8952af2 - API to manage packages.
    • +
  • e599a23 - API to manage package repositories.
    • +
  • 9aabf48 - Introduced version 2 of Plugin Info API to provide complete metadata for plugin type package-repository and icons for plugins that provide it.
    • +
+ +

Other Improvements

+ +
    +
  • fddc9fe - Improve performance of downloading of agent jars on a server upgrade. (#2813)
    • +
  • 5387e21 - Handling cleanup of agent and launcher jars from previous version of agent during an upgrade. (#2789)
    • +
  • +

    b97b635 - Generate additional windows installers to be able to package 32 bit and 64 bit JRE.

    + +

    There are two flavors of Server and Agent installers for Windows, one packaged with 64 bit JRE and the other with 32 bit JRE. 32-bit JREs only allow up-to 2GB of memory. Because large GoCD servers usually need more than 2GB of heap size, we recommend using a Server with 64 bit JRE. Agents should continue to use 32 bit JRE unless required.

    +
    • +
  • +

    b763d31 - Generate SHA-256 webserver certs instead of SHA-1. (#2842)

    + +

    The self-signed web-server certificate that GoCD generates is now a SHA-256 certificate instead of a SHA-1 certificate. SHA1 certificates have been deprecated by most browser vendors and users will start to see a warning in their browsers.

    + +

    Any new installations of GoCD will generate a SHA-256 certificate. For existing installations, users should remove the file config/keystore to allow GoCD to regenerate a new server certificate. Depending on your end-to-end transport security settings you may need to configure the -rootCertFile argument to the GoCD agent.

    +
    • +
+ +

Bug Fixes

+ +
    +
  • b34da2d - Bug fixes to ensure that git gc on the config repository works as expected.
    • +
  • a34c6dc - Allow dots in the repository and package id. (#2844)
    • +
  • Miscellaneous fixes to the new quick edit and agents pages.
    • +
+ +

Library upgrades

+ +
    +
  • 4aa1c56 - Bump JRuby to 1.7.26 from 1.7.11.
    • +
  • f4bce94 - Upgrading JGit to 4.5.0.201609210915-r.
    • +
+ +

Breaking changes

+ +
    +
  • +

    5052154 - Removed Pipeline Config API V1. This API was deprecated since 16.7 and has been replaced with version 3. Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    Microsoft Internet Explorer versions older than 11 are no longer supported. Please use IE 11 or higher. Microsoft Edge is recommended.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • We shall be stopping support for git versions older than 1.9 in three months time (Feb 2017). Users are recommended to upgrade git on the GoCD server and agents (if git is used as a material). We are aware that the linux distributions have an older version of git installed by default. Please refer to this to upgrade git.
    • +
  • The GoCD api support page http://your-server:8153/go/api/support supports JSON and plain-text outputs. JSON has been the default since release 16.6. We will be removing the plain-text output in release 17.1 (scheduled to be released in Jan 2017). It is much simpler to consume the JSON output than the plain-text output.
    • +
  • As of release 16.12, the OpenSocial gadgets have been deprecated. This feature will be removed in 17.1 (scheduled to be released in Jan 2017). This has been done for a few of reasons — +(a) there's not enough evidence of many users using this feature in a way that'll impact their usage of GoCD +(b) the underlying implementation framework (Apache Shindig) hasn't been maintained for quite some time and contain several security vulnerabilities.
    • +
  • As of release 16.12, version 1 of the Plugin Info API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.11, version 1 of the Templates API is deprecated. This version of the API will be removed in 17.1 release (scheduled to be released in Jan 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 and version 3 of the Agents API is deprecated. Version 2 of Agents API was introduced in 15.3.0 and version 3 of the API was introduced in 16.8. These versions of the API will be removed in 17.1 release (scheduled to be released in Jan 2017). Version 4 of this API is backward compatible, and users are encouraged to use it.
    • +
  • As of release 16.5, Java 7 support was deprecated. Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). GoCD works great with Java 8, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 of the Pipeline Config API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 3 of this API is backward compatible, and users are encouraged to use it.
    • +
  • +

    As of release 16.7, Java API based Go Plugins have been deprecated. Support for running these plugins will be removed in 17.1 (scheduled to be released in January 2017). Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins.

    + +

    Below is the list of plugins that will stop working in 17.1.

    + +

    Note: The GoCD team has built a shim that allows migration of all plugins with minimal change. We are actively working with plugin authors to ensure that these plugins are migrated over in time for 17.1.

    + +

    Package plugins

    + + + +

    Task plugins

    + + +
    • +
+ +

Contributors

+ +

Alison Polton-Simon, Aravind SV, Bhupendrakumar Piprava, ByteFlinger, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, Markandan R, Naveen Bhaskar, Padma Mullagiri, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Setkowski, Varsha Varadarajan, Walmyr (wlsf82 on GitHub), Zabil Cheriya Maliackal

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.11.0

+
+
+

API enhancements

+ +

fb24522 - Added new API to manage elastic agent profiles.

+ +

Quick Edit (Beta) Changes/Fixes

+ +

1a345c0 - Working directory validation on the new pipeline config page.

+

e116274 - Added tooltip for material filter input.

+

761b411 - Show server side timer validation on new pipeline config page.

+ +

Bug fixes

+ +

ec51570 - Do not raise an exception when duplicate modifications are seen in the database.

+

40999af - Improve handling of weak etags with deflate.

+

c69c1c4 - Having fixed-delay does not honour the git gc cron.

+

4509fe7 - Fixing VSM show more link.

+

e3d3360 - Allow pipeline group admins to create or update SCMs.

+

d646cfc - Added a blank check for build tasks' attributes.

+

5a54b2b - Change current directory of agent's batch file in windows 8.

+

008f4f4 - Fix the checkbox to allow known users to login in server configuration page.

+

e49cac1 - Handling empty responses from package material plugins.

+ +

Breaking changes

+ +

No breaking changes in this release.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Alison Polton-Simon, Aravind SV, ByteFlinger, Ganesh S Patil, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Sętkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.10.0

+
+
+

Agents page (Beta)

+ +

This is a new page for managing agents, which should feel a lot more light weight and snappier than the existing agents page.

+ +

We would really appreciate your feedback to make this page better. If you notice any issues or bugs with this page, please submit a bug report on GitHub

+ +
+ Beta Agents Page +
+ +

How do I use this?

+ +

Click on the "Check out the new agents page" on the agents page that you're familiar with.

+ +
+ Old Agents Page +
+
+

Known issues

+

#2735 - Agents Bulk update API: Enabling a pending agent returns 400 bad request

+ +

Improvements

+ +

53d0d42 - Show details about linux distribution flavors and versions. (#2608)

+

cc69476 - Filter for pipeline history view. (#2391)

+ +

API enhancements

+ +

687d454 - Added new API to manage pipeline templates. (#2233)

+

f8ab50a - Added PATCH support for environments update API, this will allow you to specify pipelines and agents that should be added and/or removed in a single API call.

+

09c864e - Added Agents API V4. This adds a 'build_details' property with relevant links to the job that is currently building on the agent.

+ +

Bug fixes

+ +

2d8ec07 - Spaces are not trimmed from environment variables. (#1411)

+

845ee9b - Tweak the agent registration protocol a bit. (#2558)

+

ee9cdae - Escape the jar URL to allow symbols such as # (needed when running GoCD on Mesos).

+ +

Security fixes

+ +

1f2a189 - Do not display the value of secure environment variable in templates view. (#2652)

+ +

Performance improvements

+ +

53ab276 - Removed an extra post merge validation. (#2594)

+ +

Breaking changes

+ +

No breaking changes in this release

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Aravind SV, Ganesh S Patil, Juhi Jariwala, Ketan Padegaonkar, Mahesh Panchaksharaiah, Matt Devlin (Mdevlin4 on GitHub), Sumanth Kumar Mora, Naveen Bhaskar, Rajiesh Narayanan, Tim Anderegg, Tomasz Sętkowski, Varsha Varadarajan, Venkata Jaswanth, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.9.0

+
+
+

Quick Edit (Beta)

+ +

Currently, editing a pipeline means navigating through multiple pages (and page refreshes), for modifying stages, jobs with tabs for options and environment variables, etc. Quick edit to make it smoother.

+ +

With this feature, you can change a pipeline's materials/stages/jobs/tasks simultaneously and update it as single operation. This feature also uses the new pipeline config API to make your configuration changes quicker.

+ +How do I use this? + +

Click on "Quick Edit" button on the pipeline edit page.

+ +
+ Quick edit +
+ +

Click on "Normal Edit" button to get back to old edit page.

+
+ Quick edit +
+ +Why is this beta? + +

We are working on adding few missing features like:

+ +
    +

  • Package materials (like yum, maven, artifactory plugins)

    • +

  • Pipeline template editing, pipelines that use templates can only update Pipeline Settings +and Materials

    • +
+ +Known issues? + +

Missing API validation for a few attributes, they are tracked below:

+ +
    +

  • Pipeline Config API: Stage operate permission user not validated (#2629)

    • +

  • Pipeline Config API: Validation missing for parameter name used in the custom task argument (#2628)

    • +

  • Missing validation errors on pipeline_config API (#2553)

    • +
+ +What's next? + +

We really appreciate your feedback to make this page better.

+ +

Going forward, once all the features are in, we plan to use this page as the default view for modifying configuration.

+ +

Submit your feedback by creating github issue at https://github.com/gocd/gocd/issues

+ +

API Enhancements

+

d662685 - Provided Git and git-gc stats in the support api. (#2578)

+ +

Library upgrades

+

973cbf2 - Upgraded jetty minor version to 9.2.18.v20160721.

+

74b8b47 - Upgraded logging jars.

+ +

Bug fixes

+

dc78601 - Added validation of the encryptedPassword attribute of password aware materials - SVN, P4, TFS.

+ +

Security Fixes

+

faa6a2a - Removed displaying url's from the not found page. (#2584)

+

ca7ff9c - Changed the package material check-connection request from GET to POST. (#2550)

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Ganesh S Patil, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh Narayanan, Sumanth Kumar Mora, Tomasz Sętkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.8.0

+
+
+

Beta Feature - Elastic agents

+ +

+The new extension point allows the gocd server (with the help of plugins) to spin up and shut down agents on demand. +This extension point allows plugin developers to write plugins that allow GoCD to hook into and leverage various technologies +like Docker, AWS, +GCE, Kubernetes. +

+ +

+Developers can start building their own elastic agent plugins by forking the +skeleton plugin +and looking at a sample docker plugin +as an example reference implementation. The plugin API documentation can be found here. +

+ +

API Enhancements

+

ee281ec - Added v3 of agents API to render (read-only) elastic agent attributes.

+ +

Security Fixes

+

d8cd812 - Disallowed directory listing of certain folders on the GoCD server.

+

d05746b - Added a friendlier error message on failing to send test email.

+

fb32102 - Disallowed Plugin Interact endpoint for non Authentication Plugins.

+

4d871a6 - Add cache control and pragma header to login page.

+ +

Breaking Changes

+

e7bb87b - Added a custom header to the Create Backup API.

+

914974d - Added a custom header for the Create Artifact API.

+ +

Performance fixes

+

670df79 - Re-use SSL connections by specifying a user principal as part of all remoting connections.

+

4c472e1 - Used fixed delay instead rate execution of agent ping thread.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support was deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
  • + As of release 16.7, version 1 of the Pipeline Config API was deprecated. + This version of the API will be removed in 16.10 release (scheduled to be released in Oct 2016). + Version 2 of this API is backward compatible, and users are encouraged to use it. +
    • +
  • + As of release 16.7, Java API based Go Plugins have been deprecated. + Support for running these plugins will be removed in 17.1 (scheduled to be released in January 2017). + Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins. +
    • +
+ +

For GoCD developers

+

8806f6b - Added a vagrant file to allow local development and testing of GoCD.

+ +

Contributors

+

+Aravind SV, Ganesh Patil, Jyoti Singh, Ken Mugrage, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, norcnorc, Rajiesh Narayanan, Sumanth M, Tomasz Setkowski, Varsha Varadarajan, Zabil Cheriya Maliackal +

+

Security researchers

+

https://hackerone.com/gocd/thanks

+

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.7.0

+
+
+

GoCD configuration under SCM (a.k.a Config repositories)

+ +

+ Manage pipeline configurations from one or more source-control repositories (think "git repository") and modify them externally. + You can find more details about it here, + and watch a quick demo of this feature here. +

+ +

Known issues

+

Upgrading the agent to 16.7.0 before upgrading the server is known to cause issues. Users are advised to first upgrade the server to 16.7.0 before they upgrade the agent.

+

In case you are seeing issues with the agent not starting up after the upgrade, please see this comment.

+ +

Important bug fixes

+

3e88caf - Windows Installer fixes.

+ +

Improvements

+

b283b42 - Display the correct ip-address of agents running on virtualized instances or containers. (#1657)

+ +

API enhancements

+

34e05b6 - New API for viewing, creating and editing Pluggable SCMs. (#1508)

+

642d7f4 - New API for creating and editing environments. (#966)

+

79c7168 - New API for bulk updating agents. (#2340)

+

99e2707 - New API for viewing Plugin Information. (#1873)

+

d4a7639 - Support for updating whitelists using pipeline configuration API.

+ +

Security fixes

+

103340c - Upgraded all agent-server communication to use HTTPS by default. Read more about how to improve security of your GoCD setup.

+

3d2afad - Pluggable tasks secure configurations are encrypted before saving to xml configuration. (#903)

+

657feb3 - Added missing security headers on a few pages to activate web browser protection.

+

6909484 - Escaped the error message in the repositories page. (XSS).

+ +

Breaking changes

+

f58e900 - Removed Agents API v1, users should use version 2 of the. Agents API

+

5602048 - Removed old backup API, users should user version 1 of the. Backup API

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

For GoCD developers

+

d395806 - Migrated build scripts to Gradle.

+ +

Contributors

+

Aravind SV, adeshmukh-sf, Dominic Tootell, Ganesh Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, norcnorc, Rajiesh Narayanan, Sumanth M, + Ted Sheibar, Tomasz Sętkowski, Varsha Varadarajan, Venkata Jaswanth, Viktor Sadovnikov, Zabil Cheriya Maliackal

+ +

Security researchers

+https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.6.0

+
+
+

Whitelist support for SCM materials

+ +

#2314 - Handling the triggering of a pipeline for monolithic repositories using a whitelist.

+

For example, in a repository 'baz' with folders/projects 'foo/bar' and 'foo/qux' one +can trigger the pipeline only on changes to 'foo/bar' by configuring it as a whitelisted folder.

+ +

API Enhancements

+ +

#2240 - Added a URL endpoint to grab a snapshot of the GoCD config git repository. +For example, backup the config repo 'config-repository' using:

+ +
git clone https://ci.example.com/go/api/config-repository.git
+ +

#2283 - Changed the existing API /api/support to return information in JSON format for easier parsing. +This end point also returns more information to identify performance bottlenecks.

+ +

#2239 - Added a version API to get the version of Go server.

+ +

Performance Improvements

+ +

#2248 - Improved page load performance across the board.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support was deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
+ +

Upcoming Feature - Config in a repository

+

+This release also adds foundation for reading pipeline configuration from the material's repository. +This feature is still in development and more details can be found +here. +

+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Thanks to + Aravind SV, + Carlos Villela, + Ganesh S Patil, + Joakim Lahtinen, + Jyoti Singh, + Ketan Padegaonkar, + Lubaina Rangwala, + Mahesh Panchaksharaiah, + Marina, + Naveen Bhaskar, + Paul Nilsson, + Rajiesh Narayanan, + Ted Sheibar, + Tomasz Sętkowski, + Varsha V, + Xiao Li, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.5.0

+
+
+

Support for Java 8

+ +

+We've graduated from being Java 8 compatible to officially supporting it! +You can see our journey to this milestone +here. +

+ +

+GoCD will continue to support Java 7 till release 17.1 scheduled for January 2017. Post that, we will exclusively support Java 8. We recommend that you plan for and upgrade to Java 8 (for both GoCD server and agents) before the 17.1 release. +

+ +

Performance

+ +

#2145 - Handle large modifications made to SCM materials without memory issues on the agent.

+ +

Materials

+

Fixes around handling git rebase

+ +

#2110 - Fix automatic build loop after a git rebase.

+

#985 - Fix git history rewrite causing errors.

+ +

User interface

+ +

#2136 - Warnings on VSM if pipeline is built with incompatible revisions.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support is deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Thanks to + Aravind SV, + Brett Cave, + Ganesh S Patil, + Jen Marley, + Jyoti Singh, + Ketan Padegaonkar, + Moritz Lenz, + Mahesh Panchaksharaiah, + Naveen Bhaskar, + Rajiesh Narayanan, + Tomasz Sętkowski, + Varsha V, + vmignot, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.4.0

+
+
+

Security

+ +

+ Important: There are several security fixes to prevent XSS, CSRF and remote execution exploits. We highly recommend this upgrade to keep your GoCD server and agent secure. +

+ +

Performance

+ +

#2106 - Handle eviction/expiry of composite-keys from GoCache.

+ +

Note

+ +

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Special thanks again to drrb for reporting and verifying all of the security vulnerabilities in this release. +

+ +

+ Thanks to + Aravind SV, + Austin Guest, + David Rice, + Ganesh S Patil, + Jen Marley, + Jyoti Singh, + Juhi Jariwala, + Ketan Padegaonkar, + Mahesh Panchaksharaiah, + Naveen Bhaskar, + Rajiesh Narayanan, + Rami, + Varsha V, + WPC, + Xiao Li, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.3.0

+
+
+

Security

+

Important: This release fixes several XSS and CSRF vulnerabilities which can be exploited in earlier versions. As the changes are extensive, patches for older releases will not be provided. We recommend all users to upgrade to this version to safeguard your GoCD server.

+

These security vulnerabilities were responsibly disclosed by drrb. We want to give users some time to upgrade, before providing more details about the vulnerabilities. We will work with drrb on the specifics of providing these details, soon.

+

Notable features

+
Materials
+ +
+ GoCD shallow clone for git +
+
Configuration
+ +
Installers
+ +

API changes

+

The following APIs now require an extra request header Confirm: true (due to security-related changes):

+ +

Deprecations

+
    +
  • +

    The old java API-based plugin extensions for tasks and package repositories has been deprecated. Developers are encouraged to use the new JSON message-based APIs to author plugins.

    +

    These APIs will be removed in the September release of GoCD.

    +
    • +
  • +

    In light of downward trend in Solaris installers, we are now considering a timeline to stop providing Solaris installers for GoCD. Users can continue to use the generic zip files to run GoCD on Solaris. However the support for Solaris will be on a best-effort basis.

    +

    We will stop providing Solaris installers from the July release of GoCD.

    +
    • +
+

Note

+

A more comprehensive list of changes for this release can be found here.

+

Contributors

+

Special thanks to drrb for reporting and verifying all of the security vulnerabilities in this release.

+

Thanks to Andre Moeller, Aravind SV, bradeac, Chris Northwood, Daniel Somerfield, David Rice, Dmitry Ledentsov, Fredrik Wendt, Glenn Lewis, Jan Fabry, Jovan Alleyne, Jyoti Singh, Juhi Jariwala, Juha Siponen, Ketan Padegaonkar, Mahesh Panchaksharaiah, Rajiesh Narayanan, Tomasz Sętkowski, Varsha V, WPC, Xiao Li, Zabil C.M for making GoCD better!

+ +
+
+

16.2.1

+
+
+

+ Important: 16.2 has been removed from the downloads page because it had an issue which caused problems while installing windows agents. +

+
Fixes
+ + +
+
+

16.2.0

+
+
+

What's new in GoCD 16.2

+
Features and bug fixes
+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+

Contributors

+

+ Aravind SV, + Graham Christensen, + Jyoti Singh, + Juhi Jariwala, + Ketan Padegaonkar, + Mahesh Panchaksharaiah, + Mark Crossfield, + Rajiesh Narayanan, + Tomasz Sętkowski, + Varsha V, + WPC, + Xiao Li, + Zabil C.M +

+ +
+
+

16.1.0

+
+
+

What's new in GoCD 16.1

+

+ We are moving to a more regular release schedule, and so you might see releases with mostly issues fixed, while bigger level features are in progress across releases. +

+
Important features and bug fixes in this release -
+ +

Note

+

+ The comprehensive list of changes for this release can be found here. +

+

Thanks!

+

Tomasz Setkowski, Sean Escriva for making this release of GoCD better!

+ +
+
+

15.3.1

+
+
+

What's new in GoCD 15.3.1

+

Important: 15.3.1 has been removed from the downloads page because it had an issue which could have caused problems during configuration save. The issue + mentioned is fixed in 16.1.0. The rest of the issues mentioned below are a part of 16.1.0 as well. We highly recommend upgrading to 16.1.0.

+
Important bug fixes in this release -
+ +

Note

+

+ The comprehensive list of changes for this release can be found here. +

+ +
+
+

15.3.0

+
+
+

New API for editing pipelines

+

+ A convenience JSON HAL compliant API for modifying pipelines. Check + api.gocd.org for usage details. +

+

Get informed about updates

+

+ A new version of Go CD is released every few months, with this feature you'll now be notified about the latest supported release (if you are running an older version). +

+

+ Bell icon on the top nav bar +

+

+ Release notification appears on hovering over the bell icon +

+

Other notable features

+ +

Important bug fixes

+ +

Note

+

+ The comprehensive list of changes for this release can be found + here. +

+

Thanks!

+

Tomasz Setkowski, Steve Hill, Alex Schwartz, Pooja R, Srinivas Upadhya, Xiao Li, Sandy Gordon, Arun Kumar, Björn Andersson, Federica Luraschi, Graham Christensen, Parker Shelton, Justin, Max Griffiths, Ashok Gowtham M, Massood, Ben Overmyer,James M. Greene, Ashwanth Kumar, Jakub Narloch, Alex Voitau, Joakim Wånggren, Paul Clarkin, X O and markuswehrle for making Go better. +

+ +
+
+

15.2.0

+
+
+

Improvements to the console log

+

+ GoCD now supports rendering of ANSI color codes to show you much more beautiful console logs. Additionally, Go will automatically follow the logs as your build produces it, very much like your favorite terminal program. +

+
+ Console log coloring +
+
Authentication end-point
+

+ With the newly exposed authentication end-point, Go users can now add custom authentication schemes through plugins. Read the blog + post for details. +

+
+ GoCD Login Page with Git Hub icon +
+
Setup hostname when auto-registering agents
+

+ You can now specify a property agent.auto.register.hostname to setup the hostname when + auto-registering an agent. +

+

API Improvements

+

+ Go's APIs are fairly old, have inconsistent and unpredictable content types (csv, xml, json, plain text). +

+

+ We have now migrated the + Agents API, + Users API, + Backups API to use JSON hypermedia API (using JSON+HAL). +

+

Going forward, we would like to announce an ongoing effort to improve and migrate existing APIs to use something that is more modern, easy to discover, learn and build API clients for.

+

Learn more about the new API on our new api documentation site.

+

Other notable features

+
    +
  • #194 - Allow secure variables (environment) on environments, stages and jobs.
    • +
  • #1121 - Ability for plugins to CRUD global configuration.
    • +
  • #958 - API method for renaming agent.
    • +
  • #264 - Agent API to assign resource.
    • +
  • #1261 - Port over Users API.
    • +
  • #1292 - Port over Backup API.
    • +
  • #1087 - Switching to Jetty 9 by default
    • +
  • #1210 - SSL connection errors/warnings with modern browsers
    • +
  • #1306 - Upgrade jre packaged with windows installers to java 7u79
    • +
+

Bug fixes

+
    +
  • #68 - Re-scheduled pipeline does not show the updated Agent IP details on the Job details page
    • +
  • #1089 - Re-scheduled Jobs not being marked as completed on completion
    • +
  • #1060 - Assets (and content) could be served as gzip
    • +
  • #1061 - UTF-8 characters not getting displayed correctly when the job is running or when it is rescheduled
    • +
  • #1291 and #1249 - Fan-in performance improvements.
    • +
  • #1039 - Fix for relative root paths in SVN 1.5+ externals.
    • +
  • #1109 - XSS vulnerability on user settings page.
    • +
  • #1219 - XSS vulnerability via SCM commit messages.
    • +
  • #649 - Destination folder inside flyweight gets deleted in case a material is specified twice in the config (with and without destination).
    • +
  • #1297 - UI fix to display file in artifact tab if it contains only blank spaces as file name.
    • +
  • #1199 - Could not fetch artifact with '+' symbol in filename
    • +
  • #1012 - Unable to change configuration after making one of the pipelines use a template
    • +
  • #1201 - Session tracking mode changed to be cookie only
    • +
+

Note

+

The comprehensive list of changes for this release can be found here.

+

Thanks!

+

+ @ctorpe, @thenathanjones, + @nfisher, @paulclarkin, @skarlso for making Go better. +

+ +
+
+

15.1.0

+
+
+

New plugin endpoint for "Materials"

+

This new plugin endpoint introduced in 15.1 allows Go's already long list of source code materials to be extended without making changes to the core!

+

Support for this endpoint brought along support for GitHub pull requests, contributed by an external contributor @ashwanthkumar (so exciting!), with support from a Go core contributor, @srinivasupadhya. + You'll never need to wish that Go supported your favorite kind of material repository, you can implement support for it yourself! +

+

+ You can see all the SCM material plugins on the Go Community plugins. See how to write one, here. +

+

+ Here's how the GitHub pull requests plugin looks in action (below). Read more about it in this blog post. Watch out for more improvements in the UI around this area. +

+
+ GitHub Pull Request with GitHub poller and notification plugins +
+

New plugin endpoint for "Notifications"

+

Continuing on the path of opening up different parts of Go for extension, Go 15.1 introduces a new plugin endpoint for notifications. At this point, Go notifies the plugin of changes in the status of every stage, as it happens! This allows + for quite a lot of use cases, and we are excited to see plugins written against this endpoint even before release (yay, open source!).

+

@matt-richardson has written a really nice generic notification plugin, which sends build notifications to any websocket listener! @ashwanthkumar has written a great plugin to notify Slack about build status changes. @srinivasupadhya has written a couple of nice notification plugins to update pull request statuses in GitHub and Atlassian + Stash.

+

You can see all of those plugins on the Go Community plugins page/plugins/index.html. See how to write one yourself, here.

+

Pipeline label shortening

+

This contribution by @alexschwartz helps declutter the Go Dashboard, by allowing the pipeline label to be trimmed, per material. This feature is really useful when dealing with unwieldy 40 character + SHAs in pipelines with git/mercurial materials in them. This feature allows this:

+
+ Old long pipeline labels +
+

to be changed into this:

+
+ New short pipeline labels +
+

Read more about this feature in the documentation.

+

Timestamps in console logs

+

Starting from Go 15.1, Go's console logs will have timestamps for every line. This is very useful for finding out long-running parts of tasks. Here's how it looks:

+
+ Console log timestamps +
+
More ...
+

This release is filled with many other notable features, changes and fixes, such as:

+
    +
  • #848 - Support for Mercurial versions 2.0 and greater.
    • +
  • #781 - Post-commit hook for Mercurial (contribution by Go team alumnus, @sachinsudheendra).
    • +
  • #768 - A beta feature to upload plugins directly from within the Go plugins tab (contribution by @pwen and @pamo).
    • +
  • #700 - Run multiple agents as services - for Linux (contribution by @bernardn).
    • +
  • #400 - Large part of a long-pending upgrade from Jetty 6 to Jetty 9 (turned off, by default in 15.1 - Waiting for some performance fixes on Jetty's side).
    • +
  • #104 - Agents do not restart because of a server restart, any more (plugin sync issue fixed).
    • +
  • #725 - Pipeline instance information through APIs.
    • +
  • #941 - Small improvement around config save -Look for a lot more around this area soon!
    • +
  • #877 - Performance improvements around CCTray and APIs.
    • +
+ +
+
+

14.4.0

+
+
+

New Features

+
    +
  • 719 - JSON message based Plugin APIs (docs - package, + task) +
    • +
  • 44 - Revise how new pipelines appear under 'Personalize'. Thanks @mmb for the contribution. (docs) +
    • +
  • 699 - Users can comment on pipeline run history. (docs)
    Note: This feature needs some improvements + listed here. Therefore the feature is turned 'off' for this release. To turn 'on' the feature, see details. + Thanks @mmb, @gajwani,@fkotsian & @bsnchancontribution. +
    • +
+

Bug Fixes

+
    +
  • 716 - Multiline commit comments don't trigger notifications. Thanks @mythgarr for the contribution.
    • +
  • 360 - Unable to 'clean working directory' when recursive symlinks are present. Also, improved logging for error scenario. Thanks @mmb & @gajwani for the contribution.
    • +
  • 770 - 'Check connection' for package materials fails in 'new pipeline creation' wizard when there are many other task plugins registered.
    • +
+

Others

+
    +
  • 688 - Change command error stream prefix to STDERR. Thanks @mmb for the contribution.
    • +
  • 769 - Remove unnecessary logging from test environment. Thanks @hammerdr for the contribution.
    • +
+ +
+
+

14.3.0

+
+
+

New Features

+ +

Enhancements

+
    +
  • 435 - Value Stream Map for a commit. (docs) +
    • +
  • 466 - Setting up e-mail notifications is now easier with 'any pipeline' and 'any stage' options. Thanks @lcs777 for the contribution. (docs) +
    • +
  • 460 - Enhanced search which hide pipelines. Thanks @ciotlosm for the contribution.
    • +
  • 310 - Plugin logger now allows logging exceptions. Thanks @tusharm for the contribution. +
    • +
+

Tech Debt

+
    +
  • + 130 - Upgrade Rails 2.3.14 to 4.0.4. Thanks @juniorz for your ideas and contributions during the early days of migration. +
    • +
  • 401 - Moved four database tables to Hibernate from iBatis. Not something we expected to get a PR for, kudos to @RikTyer for this one. +
    • +
+

Bug Fixes

+
    +
  • 315 - Pipeline label was not getting resolved in case of auto trigger.
    • +
  • 403 - If Go server has firewall restrictions on outgoing connections, Xml test artifacts with dtd specified used to cause problems while uploading.
    • +
  • 469 - Fixed logged in session timeout. Thanks @greenmoss for reporting the issue.
    • +
  • 297 - Resource and personalise drop-downs were not showing up properly on some versions of chrome.
    • +
  • 482 - In Value Stream Map, material circle was not being rendered properly. Thanks @dvarchev for investigating and sending a patch.
    • +
  • 548 - Polling and builds used to fail when a git submodule URL changed. Thanks @mmb for the contribution.
    • +
  • 314 - Don't allow leading/trailing spaces in commands. Thanks @sahilm for the patch. +
    • +
  • 525 - Output working directory in console output and when polling fails. Thanks @mmb for the patch. +
    • +
+
Other
+ + +
+
+

14.2.0

+
+
+

Enhancements

+
    +
  • 190 - Git post commit hook to trigger Go pipeline. +
    • +
  • 271 - Make card activity gadget work with mingle saas instance. +
    • +
  • 185 - Adding a layer of database connection configurations. +
    • +
  • 203 - Adding verbosity to exception message while loading DatabaseProvider. +
    • +
  • 114 - Move OSX packaging from ant to buildr. +
    • +
+

Bug Fixes

+
    +
  • 286 - Go server logs for mac installers are not coming up. +
    • +
  • 196 - Cannot save a job which has colon (:) in its Nant Path. +
    • +
  • 223 - Large artifact fail to upload.
    • +
  • 246 - Pipeline history view flashes for long pipelines. +
    • +
  • 91 - The pipeline activity page does not show the revision completely even on hovering on it. +
    • +
+

Others

+
    +
  • 213 - Removing unused filter code.
    • +
+ +
+
+

14.1.0

+
+
+

Enhancements

+
    +
  • Added capability to create a Task plugin.
    • +
+

Bug Fixes

+
    +
  • Fixed a corner case issue around job reschedule.
    • +
  • Fixed issue where SVN post-commit hook was not passing along credentials.
    • +
  • Fixed issue with adding users via UI with a . (dot) in the username.
    • +
  • Go Agent handles UnknownHostException by substituting host name with a generated name.
    • +
  • Task running executables in the working directory should now be prefixed with ./.
    • +
+ +
+
+
+
+ +
+
+ + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/releases/index.html b/pr-1714/releases/index.html new file mode 100644 index 000000000..305606c64 --- /dev/null +++ b/pr-1714/releases/index.html @@ -0,0 +1,6929 @@ + + + + + + + + + + + + + + + + Releases - Version notes | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+ +
+

+ Check out "Enhancements" and "Bug fixes" for specific versions of GoCD below. As always, feel free to tell us what you think, or file a bug on GitHub. +

+

+ We try our best to credit all contributors. Apologies if we miss you out. Let us know and we will change this. + Thanks to everyone for contributing patches, feature requests, reporting issues and participating in various discussions. +

+ + +
+
    +
  • 24.3.0 (latest)
    • +
  • 24.2.0
    • +
  • 24.1.0
    • +
  • 23.5.0
    • +
  • 23.4.0
    • +
  • 23.3.0
    • +
  • 23.2.0
    • +
  • 23.1.0
    • +
  • 22.3.0
    • +
  • 22.2.0
    • +
  • 22.1.0
    • +
  • 21.4.0
    • +
  • 21.3.0
    • +
  • 21.2.0
    • +
  • 21.1.0
    • +
  • 20.10.0
    • +
  • 20.9.0
    • +
  • 20.8.0
    • +
  • 20.7.0
    • +
  • 20.6.0
    • +
  • 20.5.0
    • +
  • 20.4.0
    • +
  • 20.3.0
    • +
  • 20.2.0
    • +
  • 20.1.0
    • +
  • 19.12.0
    • +
  • 19.11.0
    • +
  • 19.10.0
    • +
  • 19.9.0
    • +
  • 19.8.0
    • +
  • 19.7.0
    • +
  • 19.6.0
    • +
  • 19.5.0
    • +
  • 19.4.0
    • +
  • 19.3.0
    • +
  • 19.2.0
    • +
  • 19.1.0
    • +
  • 18.12.0
    • +
  • 18.11.0
    • +
  • 18.10.0
    • +
  • 18.9.0
    • +
  • 18.8.0
    • +
  • 18.7.0
    • +
  • 18.6.0
    • +
  • 18.5.0
    • +
  • 18.4.0
    • +
  • 18.3.0
    • +
  • 18.2.0
    • +
  • 18.1.0
    • +
  • 17.12.0
    • +
  • 17.11.0
    • +
  • 17.10.0
    • +
  • 17.9.0
    • +
  • 17.8.0
    • +
  • 17.7.0
    • +
  • 17.6.0
    • +
  • 17.5.0
    • +
  • 17.4.0
    • +
  • 17.3.0
    • +
  • 17.2.0
    • +
  • 17.1.0
    • +
  • 16.12.0
    • +
  • 16.11.0
    • +
  • 16.10.0
    • +
  • 16.9.0
    • +
  • 16.8.0
    • +
  • 16.7.0
    • +
  • 16.6.0
    • +
  • 16.5.0
    • +
  • 16.4.0
    • +
  • 16.3.0
    • +
  • 16.2.1
    • +
  • 16.2.0
    • +
  • 16.1.0
    • +
  • 15.3.1
    • +
  • 15.3.0
    • +
  • 15.2.0
    • +
  • 15.1.0
    • +
  • 14.4.0
    • +
  • 14.3.0
    • +
  • 14.2.0
    • +
  • 14.1.0
    • +
+ +
+

24.3.0 (latest)

+
+
+

This release is a minor maintenance and bug-fix release.

+ +

Enhancements

+ +
    +
  • #12953 - Bundle latest Java 21.0.4 release with non-Linux installers & containers
    • +
+ +

Bug fixes

+ +
    +
  • #12943 - Show password button not working properly while creating new config repo
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.3.0 and + Plugin API changelog for 24.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, ysf465639310

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

24.2.0

+
+
+

This release is a maintenance and bug-fix release.

+ +

Java 21 support

+ +

GoCD is now built with, tested against and distributed with Java 21 LTS. Java 17 remains the minimum supported version +for bring-your-own-JRE setups. There were no specific changes needed to support Java 21, so the prior release 24.1.0 +can be considered the first version that supports Java 21.

+ +

Windows installers no longer signed

+ +

Windows installers were previously code-signed with a "proper" Thoughtworks-issued OV code-signing certificate from +DigiCert that avoided Windows SmartScreen prompts. Due to both certificate cost and changes in requirements for OV +code-signing certificates (to have hardware-managed keys), in the short term this is no longer sustainable for GoCD. +Therefore installers are not be signed from 24.2.0 onwards.

+ +

GoCD can still be installed on Windows subsequent to this change, however users will need to review and accept +warnings from Windows during installation. Note that runtime binaries are still signed as before, such as the Java +runtime and service wrapper binaries; so this change only affects installation - not runtime.

+ +

If you have a suggestion of approach to reinstate Windows code signing for a open-source project with limited funding, +or know other projects which have done so, please reach out!

+ +

Enhancements

+ +
    +
  • #12762 - Build, test and package GoCD with Java 21 LTS by default
    • +
  • #12792 - Make JRE dependencies from RPM and Debian packages optional/recommended
    • +
  • #12761, #12828 - Add AlmaLinux 9 based GoCD agent image to replace CentOS Stream
    • +
  • Starting this release, AlmaLinux based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #12765 - Tasks on gocd-agent-docker-dind:v24.1.0 image cannot interact with Docket socket by default
    • +
+ +

Security fixes

+ +

While we don't regularly release new GoCD versions to address container image dependencies, this release patches git +binaries within container images due to CVE-2024-32002 +and several other issues of particular concern to a build/deploy automation tool such as GoCD. You can read more about +the issues on the GitHub Blog. Note that +at time of release, Debian images have not had the most critical patch backported +to Debian 11 or 12, so the gocd-agent-debian variants for 24.2.0 are still vulnerable. Ubuntu variants are all patched +as are Alpine and Wolfi variants.

+ +

We regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.2.0 and + Plugin API changelog for 24.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, K. S. Ernest (iFire) Lee, Matthias Kraaz, Tewfik Ghariani, nichivo

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

24.1.0

+
+
+

This release is a maintenance and bug-fix release, although there are several potentially breaking changes to be aware of:

+ +
    +
  • Links are no longer force-opened in new tabs
    • +
  • Java 17 is now the minimum supported version
    • +
  • Server container image is now based on Wolfi OS
    • +
+ +

Links are no longer force-opened in new tabs

+ +

A long-standing frustration with GoCD's UI is that it used to open new tabs for links, partly to avoid losing your +place on the main dashboard when investigating an individual stage/job. However, browsers are now much better at remembering +the "back" state; and the previous behaviour was confusing & frustrating.

+ +

From now on control will be returned to users - for a new tab to be opened (foreground or background) in most cases +users will need to use the browser/OS specific key combination or middle-click equivalent to do so.

+ +

If you are interested in making this a configurable option to add back the old behaviour, +discussion or pull requests are welcome.

+ +

Java 17 is now the minimum supported version

+ +

Java 17 was released in September 2021, and has had complete support within GoCD since version 22.1.0, over 2 years ago. +Since then it has been packaged with both GoCD container images & installers by default.

+ +

This has proven to be be very stable, so to reduce maintenance overhead we are now making Java 17 the minimum supported +version.

+ +

If you are aiming for minimal agent/server downtime in an upgrade to GoCD 24.1.0+, you can do so by following:

+ +
    +
  1. Ensure your existing agents are running with Java 17+. +
      +
    • If your agents are using GoCD 22.1.0+ from official GoCD containers or packages (RPM, deb)s there is nothing extra to do. These already package and run Java 17+.
      • +
    • If your agents are using GoCD 22.1.0+ from other install approaches, they are already Java 17-compatible, if your server is 21.4.0+. Ensure they are running with Java 17+.
      • +
    +
    2. +
  2. Ensure your existing server is running with Java 17+. +
      +
    • If your server is using GoCD 22.1.0+ from official GoCD containers or packages (RPM, deb)s there is nothing extra to do. These already package and run Java 17+.
      • +
    • If your server is using GoCD 21.4.0+ from other install approaches, is is already Java 17-compatible, if your server is 21.4.0+. Ensure they are running with Java 17+.
      • +
    +
    3. +
  3. Upgrade your server to GoCD 24.1.0 without worry about Java issues. +
      +
    • Older agents running Java 17+ will re-start automatically against a GoCD 24.1.0 server.
      • +
    • You can now validate your installation and agents are working fine.
      • +
    +
    4. +
  4. (Optionally) You can now upgrade your agents to GoCD 24.1.0 whenever you choose. +
      +
    • Technically GoCD agent installs are only a "bootstrapper" which downloads the matching agent code from the server for +each release. It is wise to avoid too much discrepancy in versions to make upgrades (like this one!) easier, but it is +not critical.
      • +
    +
    5. +
+ +

If you have issues, downgrades back to 22.1.0+ should be fine - there have been no breaking database or configuration +changes within these versions. If you have any further queries/issues, please ask on GitHub Discussions or the Google Group.

+ +

Server container image is now based on Wolfi OS

+ +

The GoCD server container has always been based on a minimal Linux distribution, previously Alpine Linux, +but from 24.1.0 has been switched to Wolfi OS. Wolfi OS is a similarly minimal, +security-oriented (un)distro from the folks at Chainguard which is +optimized for supply-chain security - +and unlike the musl-based Alpine uses glibc, similar to most other distributions.

+ +

Unfortunately, the use of Alpine has always posed difficulties due to its musl libc base. Most of the time this is an +irrelevant detail to users, however it has posed issues for GoCD packaging of Java runtime environments & providing aarch64 +availability for a variety of reasons stemming from GoCD's dependencies. While GoCD has applied relatively stable +workarounds to support Alpine, these are not recommended and have prevented providing a default GoCD server container +image for aarch64/arm64 architectures off-the-shelf.

+ +

Wolfi uses the same apk package manager as Alpine, with conventional package names, and although packages cannot be +used across the two OSes, the transition should be easy for most folks. The image is now multi-architecture (amd64/x64 and aarch64/arm64) +making it usable out-of-the-box within arm64 cloud instances and Apple Silicon Macs.

+ +

If you build a child container from the gocd-server container, from 24.1.0 +you will need to review your Dockerfile to check that:

+ +
    +
  • any additional packages you need to install are available for Wolfi.
    • +
  • any pre-compiled binaries specifically compiled for musl should be switched to glibc variants
    • +
+ +

There has previously been a non-officially documented multi-arch server image based on CentOS Stream, +which was the only option on aarch64. This will be removed, as it is unnecessary now we have a glibc-based image. +If you were using this, please switch back to gocd/gocd-server rather than gocd/gocd-server-centos-*.

+ +

Agent container image changes

+ +
    +
  1. A Wolfi-based agent image is now available, matching the +server image. This will become the default recommended agent image for container-based elastic agents.
    2. +
  2. The Alpine agent images will now become a rolling distribution within the gocd-agent-alpine +repository. This means that the repository will not change for each Alpine release (3.18, 3.19 etc) any longer. Alpine releases new +versions each 6 months while maintaining very good compatibility, and maintaining different repositories added unnecessary +maintenance overhead. Each GoCD release will be based on the latest compatible Alpine release, mirroring how gocd-agent-docker-dind +has always been released. GoCD 23.5.0 will be the last version released under version specific repos (3.16, 3.17, 3.18, 3.19).
    3. +
  3. CentOS Stream 8 and 9 +based container images will be discontinued after 24.1.0. While these images are stable and well-maintained, they are +not as widely used other images, and as a distribution upstream of RHEL, Rocky, Alma etc, CentOS Stream has not +proved to get an appropriate level of security/maintenance patches for dependencies, nor the official security +bulletins needed for containers tools to accurate scan the images. If you are using these images, and would prefer a +Red Hat/RHEL-like image, please open an issue!. We are open to bring back an +Alma or Rocky-based image to meet the needs of those who want to keep their agent containers within the RHEL ecosystem.
    4. +
+ +

Windows installers no longer signed after 24.1.0

+ +

Windows installers were previously code-signed with a "proper" Thoughtworks-issued OV code-signing certificate from +DigiCert that avoided Windows SmartScreen prompts. Due to both certificate cost and changes in requirements for OV +code-signing certificates (to have hardware-managed keys), in the short term this is no longer sustainable for GoCD. +Therefore installers will likely not be signed from 24.2.0 onwards when the existing certificate expires.

+ +

GoCD can still be installed on Windows subsequent to this change, however users will need to review and accept +warnings from Windows during installation. Note that runtime binaries are still signed as before, such as the Java +runtime and service wrapper binaries; so this change only affects installation - not runtime.

+ +

If you have a suggestion of approach to reinstate Windows code signing for a open-source project with limited funding, +or know other projects which have done so, please reach out!

+ +

Enhancements

+ +
    +
  • #10520 - Change GoCD to no longer force links to open in new windows/tabs.
    • +
  • #12415 - Change baseline to require Java 17 minimum.
    • +
  • #12500 - Replace Alpine with Wolfi as primary server container image, consolidating Alpine agent images.
    • +
  • #12710 - Bundle latest Java 17.0.11 release with non-Linux installers & containers
    • +
  • #12712 - Add deb/rpm aarch64 support by replacing bundled x64 JRE with arch-independent package deps
    • +
  • Starting this release, Wolfi based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 24.04 (Noble Numbat) based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #4011 - RPM packages do not install on RHEL unless SELinux is disabled
    • +
  • #12440 - Installing Chromium on Alpine 3.18 gocd docker agent causes agent crash loop
    • +
  • #12535 - Improve performance of agents API responses and dashboard stage modal
    • +
  • #12616 - Improve performance when working with large numbers of server health warnings/errors
    • +
+ +

Security fixes

+ +

This release fixes CVE-2024-28866, a theoretical +vulnerability which has not shown to be practically exploitable. Thank you to Aviv Keller (RedYetiDev) for +discovering and responsibly disclosing this issue.

+ +

We regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 24.1.0 and + Plugin API changelog for 24.1.0.

+ +

Contributors

+ +

Aravind SV, Aviv Keller / RedYetiDev, Chad Wilson, Matthias Kraaz, Tim Borrowdale, brewpark

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.5.0

+
+
+

This release is a maintenance and bug-fix release.

+ +

Enhancements

+ +
    +
  • #12353 - Starting this release, Alpine 3.19 based container images for GoCD Agent are available.
    • +
  • #12353 - Build the default GoCD Server image on Alpine 3.19
    • +
  • #12212 - Make template selector dropdowns alphabetically sorted
    • +
+ +

Bug fixes

+ +
    +
  • #12220 - Console view toolbar not shown after scrolling on v23.4.0
    • +
  • #12305 - Unable to pick stage from Add Material menu in Chrome on MacOS Sonoma
    • +
  • #12389 - Fix disappearing second+ stages on VSM view after clicking a stage
    • +
  • #12392 - Correct display of "cancelled by" for stage runs other than that being viewed
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.5.0 and + Plugin API changelog for 23.5.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Chris Gillatt, Lewis Jales-Huggins

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.4.0

+
+
+

This release is mainly a maintenance and bug-fix release.

+ +

Jetty web server upgrade

+ +

GoCD relies internally upon the Eclipse Jetty web server, which was +upgraded from v9 to v10 in this release.

+ +

If you customise the configuration of the web server via config/jetty.xml or by overriding the Java system property +jetty.xml.file.name, note that any custom configuration will be overridden to ensure compatibility with the new version. +After upgrading, shut down your GoCD server and merge back your custom changes from a backup of your config directory +/ Jetty configuration. You can review the changes to jetty.xml here.

+ +

Enhancements

+ +
    +
  • #12120 - Bundle latest Java 17.0.9 release with non-Linux installers & containers
    • +
  • #12147 - Speed agent bootstrapping by reducing agent dependencies
    • +
  • #12051 - Remove subversion & mercurial from default container images
    • +
+ +

Bug fixes

+ +
    +
  • #11868, #11893 - Server config can have boolean attributes unintentionally toggled by server at GoCD startup
    • +
  • #11819 - Agent links from stage details jobs tab no longer work since 23.2.0
    • +
  • #11866 - GoCD 23.2/23.3 breaks agent mTLS connectivity when private key is encrypted/passphrase protected
    • +
  • #11969 - GoCD Agent on Java 20+ cant talk to server on Java 17
    • +
  • #12107 - Improve error logging during agent token acquisition failures
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

If you use GoCD container images, note that this release rebuilds GoCD images to include +fixes to curl CVE-2023-38545 across all supported platforms.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.4.0 and + Plugin API changelog for 23.4.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Mai-Khattab, Victor Sollerhed, jprogin, k-c-p

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.3.0

+
+
+

This release is a maintenance release to address a couple of unintended regressions in the 23.2.0 release.

+ +

Bug fixes

+ +
    +
  • #11790 - Stage History pagination links are broken on 23.2.0
    • +
  • #11783 - Build detail timestamp icon is missing on 23.2.0
    • +
  • #11797 - Some plugin config/report views have missing icons on 23.2.0
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.3.0 and + Plugin API changelog for 23.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.2.0

+
+
+
+ NOTE: An issue was discovered with 23.2.0 which prevents UI navigation via Stage History to older stage runs in + the history when you're already viewing the detail of an individual stage (Stage Details view). + + Please upgrade to 23.3.0 instead, which resolves this issue. +
+
+

This release is mainly a maintenance and bug-fix release.

+ +

Minor changes that may affect plugins

+ +

There have been some changes made to GoCD's UI dependencies to improve loading times which may unintentionally affect +certain plugins' views. If you notice a visual problem with a plugin view after +updating to 23.2.0, please update to the latest released version of the plugin, and if the issue persists please open an +issue on the plugin's GitHub repository.

+ +

A small number of third-party community-authored authorization plugins may no longer be compatible if they have not +been updated to declare compatibility with the 2.0 extension API +and still use the outdated extension version 1.0 deprecated in 2019. +All known popular plugins maintained by the community have been updated, so please update your plugins and open an issue +with the plugin author if you notice a plugin version compatibility error preventing the plugin from loading.

+ +

GoCD Agent DIND container image start-up is now more conservative

+ +

The GoCD agent "docker-in-docker" image +semantics were changed to ensure that the Docker daemon has started correctly before starting the +GoCD agent.

+ +

This aligns behavior with the upstream official docker:dind image +and resolves a race condition in #11378 that can cause docker-related tasks on GoCD agents to fail +due to improvements in GoCD agent work pick-up speed in recent releases.

+ +

Prior to GoCD 23.2.0, if the daemon failed to start the agent would continue to work without it. Docker commands within +tasks would fail, however the agent would continue. If you were accidentally relying on this behaviour (e.g due to running +the agent without the privileged flag, without the appropriate Kubernetes securityContext, or without +mounting the host's docker.sock into the container correctly), you will need to update your agent start +scripts or elastic agent profile to ensure the daemon has the correct container privileges, OR switch to a non-DIND +agent image such as a plain Alpine image.

+ +

Keep in mind that you only need to use a DIND agent image if you are relying on docker-in-docker or docker-out-of-docker +approaches to build or run nested or sibling containers within your agent host. If you want a drop-in replacement, we +recommend that you use an off-the-shelf GoCD Agent Alpine image, or if you need the Docker CLI (without daemon) +build your own custom child image, augmenting with apk add docker-cli or similar tooling.

+ +

Enhancements

+ +
    +
  • #11629, #11633 - Ability to store/retrieve session state within GoCD plugins to facilitate increased security OAuth2/OIDC
    • +
  • #11693 - Starting this release, Debian 12 / Bookworm based container images for GoCD Agent are available.
    • +
  • #11578 - Starting this release, Alpine 3.18 based container images for GoCD Agent are available.
    • +
  • #11578 - Build the default GoCD Server image on Alpine 3.18
    • +
  • #11405 - Reduce size/security attack surface of CentOS Stream 9 based container images (requires use of microdnf instead of dnf)
    • +
  • #11472, #11449, #11473, #11626, #11627, #11625 - Increase UI loading speed by reducing bundle size
    • +
  • #11535 - Improve pipeline config tab switch confirmation dialog message
    • +
  • #11663 - Improve user experience when managing Pluggable SCMs with Auto Update
    • +
  • #11664 - Improve error messages during config repo material validation
    • +
  • #11634 - Allow server wrapper-properties customisation within server container images
    • +
+ +

Bug fixes

+ +
    +
  • #11378, #11406 - gocd-agent-docker-dind:v23.1.0 image can sometimes fail docker tasks run after agent start
    • +
  • #11548 - go-agent 23.1.0 does not start when system tmp dir has a noexec mount
    • +
  • #11376 - Remove unnecessary bloat within CentOS 7 arm64 agent container image
    • +
  • #11544 - Pipeline config deep links from Pluggable SCMs and Elastic Agents don't work as expected
    • +
  • #11399 - GoCD Artifacts tab doesn't show artifacts whose name starts with a dot
    • +
  • #11773 - Fix import of nant_path from nant config repo tasks
    • +
  • #11772 - Fix export to config repo of fetch artifact tasks without pipeline name set
    • +
  • #11652 - Fix font display consistency across views
    • +
  • #2822 - Fix logging ERROR noise from url rewriting logic
    • +
  • #11513 - Remove misleading reporting of agent "creating properties" in console logs
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

However, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.2.0 and + Plugin API changelog for 23.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, FeltIP, James McNee, Jeroen Oortwijn, Ketan Padegaonkar, Marc Ende

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

23.1.0

+
+
+

Dashboard personalization enhancements

+ +

Personalized views allowing filters for failed or building stages now also allow inclusion of Cancelled or Paused pipelines.

+ +

Personalize Dashboard to show only cancelled or paused pipelines

+ +

Yum Repo Poller Plugin no longer bundled by default

+ +

Due to both its uncommon use and improvement of agent bootstrap speeds the Yum/RPM/DNF Repository Poller Plugin +is no longer bundled with GoCD from 23.1.0 onwards.

+ +

All plugins impose a marginal startup cost for the server and certain plugins also +to all agents. Since it is also currently difficult to override bundled plugins in some GoCD setups, the team have +decided to stop bundling this particular plugin.

+ +

If you rely upon this plugin, follow these upgrade steps:

+ +
    +
  1. download the latest version of the plugin from GitHub
    2. +
  2. install the plugin as an external plugin (see plugin user guide)
    3. +
  3. upgrade your server to 23.1.0
    4. +
+ +

You needn't worry about:

+ +
    +
  • Starting your old server version with the external plugin added. GoCD will ignore it, and prefer the bundled plugin until you upgrade.
    • +
  • Loss of configuration while starting your server on 23.1.0 before adding the plugin back. Your config will be retained, + however your server will not function correctly, and certain pipelines will not be editable until you restore the plugin + and restart your server, which you should do as soon as possible.
    • +
+ +

As always, we recommend that you take a backup before upgrading.

+ +

Other Enhancements

+ +
    +
  • #11341 - Starting this release, Ubuntu, Debian and CentOS based container images are built multi-platform for both amd64 and arm64/aarch64 (example)
    • +
  • #11053 - Starting this release, Alpine 3.17 based container images for GoCD Agent are available.
    • +
  • #11053 - Build the default GoCD Server image on Alpine 3.17
    • +
  • #8544 - Validate and enable GoCD server/agent install on Linux ARM / aarch64 system architecture
    • +
  • #11286 - Improve agent work pickup speed with an exponential rather than fixed 10s backoff
    • +
  • #11100 - Guard against out-of-memory errors when handling extremely long log lines from build task output
    • +
  • #11275, #11285 - Improve artifact upload speed with buffer tweaks
    • +
  • #11205 - Simplify & improve agent operating system complete name determination
    • +
  • #11295 - Improve agent logging to avoid confusing double-timestamps
    • +
  • #11048 - Improve logging of server output to assist with backup debugging
    • +
  • #11296 - Improve container logging to avoid cut-off lines due to log buffering
    • +
+ +

Bug fixes

+ +
    +
  • #266, #11159 - GoCD doesnt correctly parse minified JUnit XML produced by pytest
    • +
  • #4469, #11317 - Agent Error occurred during loop NullPointerException: Cannot invoke "org.apache.http.Header.getValue()" because "md5Header" is null
    • +
  • #11222 - Fix occasional issues with container start stalling or crashing due to process wrapper issues
    • +
  • #10669 - Dragging outside of the pipeline config web config dialogs can close the dialog without saving
    • +
  • #11004 - Dead docs link on dashboard personalization page
    • +
  • #11047 - Fix error messages on failure to launch DB backup process
    • +
  • #11070 - Fix build label handling on VSM and job detail pages
    • +
  • #11141 - Check server identity by default when talking SMTP over TLS
    • +
  • #11134 - Stage History API fails with DB error on MySQL 8
    • +
  • #11260 - Loading materials admin page creates syntax error on MySQL 8
    • +
+ +

Security fixes

+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by infoatb and CC Bomber, Kitri BoB (tunaf). +Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Additionally, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 23.1.0 and + Plugin API changelog for 23.1.0.

+ +

Contributors

+ +

Aravind SV, CC Bomber Kitri BoB (tunaf), Chad Wilson, Christian Butcher, Ketan Padegaonkar, Kim Sullivan, Sandro Heinzelmann, iantra, infoatb

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.3.0

+
+
+

Changes

+ +
    +
  • #10759 - Improve agent start-up time during agent-to-server version synchronization
    • +
  • #10924 - Bundle latest Java 17.0.5 patch release with non-Linux installers & containers
    • +
  • Starting this release, MacOS Apple Silicon (arm64/aarch64) installers and +test-drive experience are available.
    • +
  • Starting this release, CentOS Stream 9 based docker images for GoCD Server are available.
    • +
+ +

Bug fixes

+ +
    +
  • #8999 - Agents page layout has overlapping backgrounds on Chromium-based browsers
    • +
  • #10736 - GoCD 22.2.0 broke display of timestamps in plugin Elastic Agent Status Reports
    • +
  • #10837 - Job History sidebar dropdown does not display timestamps for previous job runs
    • +
  • #10891 - Build labels are truncated in pipeline activity page
    • +
  • #10937 - Support API logs a lot of noisy errors on Java 16+
    • +
  • #10943 - Fetch Artifact task doesn't provide correct suggestions when switching stages on pipeline config
    • +
  • #10982 - Fix Postgres backups via pg_dump on Windows
    • +
+ +

Security fixes

+ +

There are no security fixes included in this release (for issues known to affect GoCD).

+ +

This release does upgrade a number of important internal components, some of which were EOL. We do not have evidence that +the previously vulnerable dependencies pose any specific risk in GoCD's usage, however we endeavour to minimise +dependency drift.

+ +

Since we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs +- API changelog for 22.3.0 and + Plugin API changelog for 22.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Chantry C, Jeroen Oortwijn, Ketan Padegaonkar, Lewis Jales-Huggins, pan Jacek

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.2.0

+
+
+

Changes

+ +
    +
  • #10613 - Bundle latest Java 17
    • +
  • #10518 - Build the default GoCD Server image on Alpine 3.16
    • +
  • Starting this release, Alpine 3.16 based docker images for GoCD Agent are available.
    • +
  • Starting this release, CentOS Stream 9 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 22.04 (Jammy Jellyfish) based docker images for GoCD Agent are available.
    • +
+ +

Security fixes

+ +

In this release, permissions were restricted further on Windows installer GoCD server & agent folders. Thank you to +s7331 for responsibly disclosing this issue.

+ +

Additionally, we regularly upgrade dependencies to mitigate known vulnerabilities from third party software (regardless of +whether they are known to affect GoCD), so upgrading to the latest release is always recommended from a security perspective.

+ +

Bug fixes

+ +
    +
  • #4173 - On Windows, custom commands with spaces in path fail
    • +
  • #8986 - Git Material authentication fails for second user on the same repository
    • +
  • #9153 - Git Material credentials cannot be changed
    • +
  • #9509 - Unable to render VSM page when dependent pipelines are deleted or renamed
    • +
  • #9964 - Can't add user into a role (and other admin functions) behind CloudFlare minification proxy
    • +
  • #10036 - HTTP 500 when using external authorization plugins and GoCD site urls are blank
    • +
  • #10440 - Windows installer does not exit as intended on downgrade attempts
    • +
  • #10441 - Fix compatibility with JDK 11.0.15+ and 17.0.3+ during server configuration upgrades
    • +
  • #10555 - Misleading error message logged when agents have connectivity issues with GoCD Server
    • +
  • #10566 - Job Instance API does not return job state transitions as documented
    • +
  • #10610 - Custom tabs do not resize correctly to use window height as intended
    • +
  • #10648 - Plugin Admin page can display stale information after plugins are upgraded
    • +
  • #10668 - Fetch External (plugin) Artifact task gives generic Unprocessable Entity error for failing plugin validations
    • +
  • #10675 - Stage Details statistics graph page navigation broken on Chrome/Chromium
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 22.2.0 and Plugin API changelog for 22.2.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Christian Butcher, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Shakir Shakiel, s7331

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

22.1.0

+
+
+

Security fixes

+ +

This release has important security fixes and upgrades to a number of internal components.

+ +

This is an especially important upgrade due to two remote code execution vulnerabilities that could allow existing authenticated +users with malicious intent to trigger remote code execution on the GoCD Server, within

+ + + +

If you are unable to upgrade immediately, you can mitigate the high severity issues by

+ +
    +
  1. removing any authorization configurations for the bundled LDAP Authentication plugin +
      +
    • if LDAP login is required, consider migrating your configuration to a patched (v4.2.0-73+) version of the LDAP Authorization Plugin, which supports both authentication and (optional) authorization
      • +
    +
    2. +
  2. uninstalling the hg/Mercurial binary from the underlying GoCD Server operating system or Docker image
    3. +
+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by Alessio Della Libera (of the Snyk Security Team), +Alexey Solovyev (solev9ev) and SuperXX (Xiao Xiong). Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Java 17 support

+ +

This release includes compatibility changes within the GoCD Server to support Java 17.

+ +

Java 16+ includes a number of restrictions on access to Java Runtime internals that required either GoCD changes or +specific "opt-outs" to be included in GoCD server's start-up arguments. Currently, there are no opt-outs known +to be required on GoCD agents.

+ +

If you use the regular GoCD start-up scripts, and/or the packaged Java Runtime Environments with our installers and/or +Docker images, there is nothing extra you should need to do to run with Java 16+. +
+

+ +
Plugin compatibility with Java 17
+

GoCD has many plugins and while we have sanity checked many, it is not practical for us to test every plugin. +Plugins are also constrained by these Java Runtime restrictions, and if they either rely on access to Java Runtime +internals or use libraries that do so, they may experience issues.

+ +

If you experience issues with a plugin, or GoCD Server or a GoCD Agent

+ +
    +
  • try working around the issue by following this guide
    • +
  • please report the issue, including a full stack trace from the logs +
      +
    • for plugin issues, on the relevant plugin's GitHub repository (these are linked from the Author of each plugin in Admin -> Plugins)
      • +
    • for GoCD Server/Agent issues, on our GitHub issues
      • +
    +
    • +
  • if you are not sure if a plugin or GoCD is at fault, feel free to start a discussion in our GitHub discussions +or via the GoCD Google Group
    • +
+ +

Changes

+ +
    +
  • #9818 - Upgrade GoCD to run and build with Java 17
    • +
  • #10025 - Build the default GoCD Server image on Alpine 3.15
    • +
  • #10153 - Drop source/target compatibility back to Java 11 LTS
    • +
  • #10071 - Support Bitbucket push webhooks that contain multiple changes
    • +
+ +

Bug fixes

+ +
    +
  • #9002 - Cannot input multiple lines for Perforce material view
    • +
  • #9927 - Clean working directory sometimes fails on POSIX file systems with GoCD 21.3
    • +
  • #10086 - GoCD Server fails to start when commit GPG signing is enabled at system/user level
    • +
  • #10169 - Correct message displayed when agents are stuck cancelling jobs
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 22.1.0 and Plugin API changelog for 22.1.0.

+ +

Contributors

+ +

Alessio Della Libera (of the Snyk Security Team), Alexey Solovyev (solev9ev), Aravind SV, Chad Wilson, Ganesh S Patil, Jeroen Oortwijn, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Sandro Heinzelmann, SuperXX (Xiao Xiong)

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.4.0

+
+
+

Preparation for Java 17

+ +

This release focuses on internal changes, dependency upgrades and build/test automation changes required for GoCD to support Java 17. Since Java 17 is a long-term-support (LTS) release and Java 16 is now end-of-life, we intend to skip specific validation against Java 16.

+ +

While we are not quite ready, most required changes are part of the 21.4.0 release, so we expect experimental builds to be made available soon in preparation for a subsequent release.

+ +

Security Fixes

+ +

This release improves GoCD's security posture further by

+ +
    +
  • correcting a reflected XSS issue on API error responses. Thank you to dmxjon (aka DiMaX) for responsibly disclosing this issue.
    • +
  • upgrading a number of internal components, some of which have known vulnerabilities.
    • +
+ +

We do not have evidence that the upgraded dependencies pose any specific risk in GoCD's usage, however we endeavour to minimise dependency drift.

+ +

Changes

+ +
    +
  • #9828 - Build the default GoCD Server image on Alpine 3.14
    • +
  • #9966 - Migrate CentOS 8 Agent and Server images to CentOS Stream
    • +
  • #9922 - Base Debian agent images on "slim" variants
    • +
  • Starting this release, Alpine 3.15 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Debian 11 based docker images for GoCD Agent are available.
    • +
+ +

Bug Fixes

+ +
    +
  • #9914 - GoCD Server on MacOS not running with packaged JRE by default
    • +
  • #9992 - Remove broken "more…" link from Job Detail pages
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.4.0 and Plugin API changelog for 21.4.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, dmxjon (aka DiMaX)

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.3.0

+
+
+

Security Fixes

+ +

This release has important security fixes and upgrades to lots of internal components. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

The Business Continuity feature has been disabled as a part of these changes. If you are not able to upgrade immediately, please make sure to disable the route /add-on/business-continuity/* while you make plans to upgrade.

+ +

Security fixes in this release were due to vulnerabilities responsibly disclosed by Simon Scannell, Thomas Chauchefoin, and Paul Gerste of SonarSource. Many thanks to them for the disclosures, discussions and ideas around mitigation.

+ +

Changes

+ +
    +
  • All materials URLs for Git, Mercurial, Subversion and TFS materials will now need to start with an alphanumeric character or a /. Please open a GitHub issue if this is a problem for you. There is a temporary flag available for this change.
    • +
  • #9662 - Remove "Failures" tab in Job Details page.
    • +
  • #9797 - Build the default GoCD Server image on Alpine 3.13.
    • +
  • Starting this release, Alpine 3.14 based docker images for GoCD Agent are available.
    • +
  • Starting this release, Ubuntu 20.04 based docker images for GoCD Agent are available.
    • +
+ +

Upcoming changes

+ +

GoCD doesn't yet work with Java 16+. The upgrade to Java 16 requires quite a few changes, which will be attempted in the near future. Given changes in the Java ecosystem (such as Adoptium not providing a JRE any more), we might need to re-think sticking with the latest JVM and maybe consider LTS releases.

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.3.0 and Plugin API changelog for 21.3.0.

+ +

Contributors

+ +

Aravind SV, Chad Wilson, Hussein Kadiri, Mahesh Panchaksharaiah, Marques Lee, Paul Gerste, Simon Scannell, Thomas Chauchefoin

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.2.0

+
+
+

Security Fixes

+ +

This release has important security fixes. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

Changes

+ +
    +
  • #9086 - Bundle latest Java 15
    • +
  • Starting this release, Alpine 3.13 based docker images for GoCD Agent are available.
    • +
+ +

Bug fixes

+ +
    +
  • #8899 - "Config Changed" diff marks lines containing dash (-) as removed
    • +
  • #9073 - Add missing Content-Type check
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.2.0 and Plugin API changelog for 21.2.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

21.1.0

+
+
+

Security Fixes

+ +

This release has important security fixes pertaining to Agent-Server communication. We recommend all users to upgrade to this version to safeguard your GoCD server.

+ +

These security vulnerabilities were responsibly disclosed by Denis Andzakovic. We want to give users some time to upgrade, before providing more details about the vulnerabilities.

+ +

Webhook support for Config Repositories

+ +

Starting GoCD 21.1.0, the config repositories can be refreshed or updated via a webhook trigger. The config repositories page will now showcase the URL required to configure the same (if auto update has been turned off).

+ +
+ Config Repositories with webhook +
+ +

Improvements

+ +
    +
  • #8900 - Improve UX - add search functionality on page
    • +
+ +

Bug fixes

+ +
    +
  • #8915 - Repeated logging: Could not find file config/cipher and config/go.feature.toggles
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 21.1.0 and Plugin API changelog for 21.1.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.10.0

+
+
+

Improvements

+ +
    +
  • 85a721b - Improve UI performance by increasing the polling interval if the window is in background.
    • +
  • #8729 - Modal UX improvements: for validation failures, errors indicated next to the save button
    • +
+ +

Bug fixes

+ +
    +
  • #8730 - Unexplained performance degradation/lock-ups after 20.5.0 to 20.8.0 upgrade
    • +
  • #8741 - Pipeline Activity column headings not aligned with progress blobs
    • +
  • #8767 - Agents API is slow when there are too many secure variables in GoCD environment
    • +
  • #8774 - Agent resource tags are case-sensitive when referenced from a job
    • +
  • #8775 - Make ignore_for_scheduling field read-only on pipeline config edit SPA, for configs from Config Repo
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.10.0 and Plugin API changelog for 20.10.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Shakir Shakiel, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.9.0

+
+
+

Preference Page

+

As part of the ongoing UI/UX refresh for improving the user experience, the Prefernce page has been rewritten to keep it in sync with other pages, while retaining existing functionality. Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ Preference page +
+ +

Stage Overview on VSM Page

+ +

Staring this release, the users can view the stage overview on VSM page. Earlier, it was available on the Dashboard and Pipeline Activity Page.

+ +
+ Stage overview on VSM page +
+ +

In case of stage re-runs, the stage overview now provides an option to view previous stage runs.

+ +
+ Stage instances on stage overview +
+ +

Other Improvements

+ +
    +
  • #1926 - Job Timeout should apply even when the job could not be assigned to an agent
    • +
  • #5787 - Ability to start server in maintenance mode
    • +
  • #8170 - Support for webhook integration with Pluggable SCM materials
    • +
  • #8592 - Add secrets support in elastic agent configurations
    • +
  • #8599 - Load GoCD configurations from config repositories on GoCD startup
    • +
  • #8667 - Auto Update of Config Repo materials can be turned off now
    • +
+ +

Bug fixes

+ +
    +
  • #8542 - Changes to global Plugin Material Config and Package Config does not reflect on pipeline materials
    • +
  • #8594 - Feeds API for scheduled jobs will return jobs only for pipeline which can be viewed by the user
    • +
  • #8601 - Solve issue around missing SCMs coming from config repo
    • +
  • #8623 - Fix the check connection button text on pluggable scm modal
    • +
  • #8628 - Do not run database migration for server in standby
    • +
  • #8643 - Elastic Agent Plugin always migrates the old plugin settings
    • +
  • #8650 - Fixed the git version mismatch between error message and actual check
    • +
  • #8653 - Fixed the issue of Duplicate SCM on config repo parsing
    • +
  • #8655 - Do not purge the config repo defined structures cache on polled fetch on Config Repo Page
    • +
  • #8685 - Minor Pipeline Comparison UI regressions introduced in 20.3.0
    • +
  • #8624 - Fix - Postgres with SSL throws "PSQLException: SSL error: null"
    • +
+ +

Removal

+ +
    +
  • The CentOS 6 based docker image for GoCD Agent has been removed. CentOS 6 has reached end-of-life in Nov 2020. Please use an image based on a newer version of the CentOS.
    • +
  • The Alpine 3.9 based docker image for GoCD Agent has been removed. Alpine 3.9 has reached end-of-life in Nov 2020. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.9.0 and Plugin API changelog for 20.9.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.8.0

+
+
+

Materials Page

+ +

We have introduced a new Materials Page which lists all the configured materials. The page provides an ability to trigger a material update. For each material you can view the modifications with a corresponding link to VSM.

+ +
+ Materials SPA +
+ +

Support for Branch and Pull Requests

+ +

The GoCD Groovy DSL Configuration Plugin adds support for PR and branches in the latest version of the plugin. The plugin provides an ability to templatize a pipeline or an entire workflow to run your builds against each branch and PR. Once a template is defined, the plugin scans the configured repository at a regular interval and for each available branch/PR it builds the corresponding pipelines.

+ +

Refer to the plugin documentation for comprehensive examples to use this feature.

+ +

Stage Overview on Pipeline Activity Page

+ +

Staring this release, the users can utilize the stage overview on Pipeline Activity page. Earlier, it was only available on the Dashboard.

+ +
+ Stage overview on pipeline activity +
+ +

Other Improvements

+ +
    +
  • #3962 - Support allowlist for pluggable SCM materials
    • +
  • #8234 - Support for secrets management interpolation on Pluggable SCM materials
    • +
  • #8367 - Add support for denylist for plugin materials on the edit material popup
    • +
  • #8522 - Exponential backoff material update in case of failures
    • +
  • #8558 - Add support for secrets in Package configurations
    • +
+ +

Bug fixes

+ +
    +
  • #8490 - Invalid stage settings link on stage overview when a pipeline is defined from a template
    • +
  • #8492 - ConfigRepoPlugin should decrypt all of the configuration properties when including them in the request.
    • +
  • #8502 - Dashboard UI issue: Repeated trigger buttons
    • +
  • #8511 - Allow group admin users to check connection for Pluggable SCM config
    • +
  • #8524 - Test Connection with ## in Repository URL doesn't work in Pipeline Wizard
    • +
  • #8525 - Backup breaks when WRAPPER_CONF_DIR is not set
    • +
  • #8540 - Fix job rerun icon positioning on stage overview
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.8.0 and Plugin API changelog for 20.8.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.7.0

+
+
+

Dashboard Improvements

+ +

In this release, there have been significant improvements to the GoCD dashboard UX:

+ +
    +
  • We have introduced a new stage overview which provides users with quick access to stage details on the dashboard. The stage overview provides information about all the jobs in a stage, gives an option to re-run jobs and to quickly access the job console from the dashboard.
    • +
  • The GoCD dashboard now provides an ability to trigger manual stages.
    • +
+ +
+ Quick stage overview on dashboard +
+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.12 based docker images for GoCD Agent are available.
    • +
  • The bundled yum package material plugin has been updated to work on RHEL 8
    • +
  • #8411 - Allow only admins and pipeline group admins to perform check connection on pipeline materials.
    • +
+ +

Bug fixes

+ +
    +
  • #8416 - Agent SSL Verification with reverse proxy fails
    • +
  • #8427 - Agents going Lost Contact after a while and warnings in the server about remoteBuildRepository
    • +
  • #8460 - Mask authentication credentials in urls on materials tab on pipeline config edit page
    • +
  • #8463 - Fail to perform any GoCD updates due to invalid config repository configuration
    • +
  • #8464 - Added validation for null arguments for exec command
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.7.0 and Plugin API changelog for 20.7.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.6.0

+
+
+

New Pipeline as code wizard

+ +

The Pipeline as code wizard makes it easier for users to define and generate pipeline definitions using the config repo plugin of their choice.

+ +
+ Pipeline as code wizard +
+ +

SSL support - Breaking Changes

+ +

In GoCD 20.2.0 we had announced the removal of support for TLS on port 8154 using a self-signed certificate. To minimize disruptions, GoCD temporarily provided an option to enable the TLS port.

+ +

With this release, GOCD no longer supports configuring TLS within GoCD and will stop bringing up TLS on port 8154. If you have temporarily enabled TLS, and if the agents are configured to use the TLS port 8154 they will have to reconfigured to use port 8153, else the agent will stop connecting to the server.

+ +

Business Continuity

+ +

GoCD had a failover mechanism to decrease the impact of server failure. This feature was available as part of the paid offering through the Business Continuity Addon. +As part of open sourcing all the commercial components, the Business continuity feature has been incorporated into GoCD core. Please refer to the documentation to know more about the Business Continuity feature.

+ +

Data Sharing

+ +

The Data Sharing feature has been removed from GoCD.

+ +

Other Improvements

+ +
    +
  • #8210 - Allow git material to honor a refSpec as the branch name
    • +
  • #8263 - Better naming for whitelist/blacklist options
    • +
  • #6722 - Showcase a help component for concepts on all SPAs
    • +
  • #8315 - Show help text when plugin role selector is disabled on Roles SPA
    • +
  • #8327 - Show branch name on materials table
    • +
+ +

Bug fixes

+ +
    +
  • #8231 - Fix rule circumvention issue that allows partials from config-repository to be merged even if rules are violated
    • +
  • #8314 - Fix Users update API to return appropriate status code on update user failure
    • +
  • #8298 - Fix duplicate error message from the Stage Trigger API
    • +
  • #8335 - Fix NPE issue while using access token which has reference to invalid authorization configuration
    • +
  • #8345 - Stale response while using Stage History API
    • +
  • #8350 - Resolve secret params during check connection
    • +
  • #8308 - Validate empty tasks in a job
    • +
  • #8261 - Added toggle icon to view the text while editing for secure environment variables
    • +
  • #8141 - Improvements and Bug Fixes on Pipeline Config SPA
    • +
  • #8361 - Add client side validations for environment variables on Pipeline Config SPA
    • +
+ +

Removal

+ +
    +
  • The Debian 8 (jessie) based docker image for GoCD Agent has been removed. Debian 8 (jessie) has reached end-of-life in June 2020. Please use an image based on a newer version of the Debian.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.6.0 and Plugin API changelog for 20.6.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.5.0

+
+
+

Support for multiple databases

+ +

GoCD 20.5.0, while continuing to use H2 as the default database, introduces support for PostgreSQL without a need for the (previously used) commercial addon. As part of these changes GoCD moved away from using the unmaintained dbdeploy to liquibase for automated database migrations. These changes require a one-time manual migration of the GoCD database running on versions <= 20.4.0 to one compliant with GoCD 20.5.0 and beyond, even if you decide not to migrate to PostgreSQL.

+ +

Please refer to the GoCD Database migration document for steps to migrate your database.

+ +

UI/UX refresh

+ +

As part of the ongoing UI/UX refresh for improving the user experience, the Templates Authorization page has been rewritten to keep it in sync with other pages, while retaining existing functionality.

+ +
+ Template Authorization +
+ +

Other Improvements

+ +
    +
  • #150 - Agents API (on GoCD server side) provides information about Agent and Agent Bootstrapper versions.
    • +
  • #8127 - Improved performance of pipeline edit on Environments page
    • +
  • #8114 - Agents API to force kill tasks on an agent stuck in Building(Cancelled) state.
    • +
  • #8223 - Improved help text in UI for artifact cleanup options.
    • +
+ +

Bug fixes

+ +
    +
  • #8220 - Fixed bug when adding notifications using the Notification Filters API.
    • +
+ +

Deprecations

+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.5.0 and Plugin API changelog for 20.5.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.4.0

+
+
+

Default permissions on new pipeline groups

+ +

Starting from 20.4.0, all pipeline groups with no explicit permissions setup can only be viewed and operated by GoCD system administrators. Earlier, such pipeline groups could be viewed and operated by every valid user. This changes it to be secure by default.

+ +

UI/UX refresh

+ +

As part of the ongoing UI/UX refresh for improving the user experience, the Pipeline Config edit page has been rewritten to keep it in sync with other pages, while retaining existing functionality. Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ Pipeline Config Edit +
+ +

Other Improvements

+ +
    +
  • #8118 - Update Package and Pluggable SCM page to support auto_update
    • +
  • #8140 - Improving config repository error message while parsing related to rules
    • +
+ +

Bug fixes

+ +
    +
  • #8119 - Adding a package material via Package page causes the pipeline to fail
    • +
  • #8132 - Fixed Template API update failure when parameter resolution has errors
    • +
+ +

Deprecations

+ +
    +
  • The Alpine 3.8 based docker image for GoCD Agent has been removed. Alpine 3.8 has reached end-of-life in May 2020. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.4.0 and Plugin API changelog for 20.4.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.3.0

+
+
+

New Pluggable SCMs Page

+ +

We have introduced a new Pluggable SCMs page to create and manage Plugin Materials.

+ +
+ Pluggable SCMs page +
+ +

UI/UX refresh

+ +

As part of our ongoing UI/UX refresh for improving the user experience, we have rewritten the Packages and Comparisons page to keep it in sync with other pages and retaining the existing functionality.

+ +

Packages Page

+ +
+ Package Repository page +
+ +

Comparison Page

+ +
+ Comparison page +
+ +

Other Improvements

+ +
    +
  • #2947 - Custom SCM material plugins do not show up in the list of materials when creating a new pipeline
    • +
  • #7022 - Pipeline creation wizard missing package material type
    • +
  • #7860 - Pipelines page: disable delete for pipelines with dependent pipelines
    • +
  • #7889 - [Performace Improvement] Remove unnecessary group by cause while loading dashboard pipeline
    • +
+ +

Bug fixes

+ +
    +
  • #2197 - Incorrect error message for invalid template name
    • +
  • #7865 - PipelineConfig Create API: ensures pipeline group name check is case-insensitive
    • +
  • #7903 - Maintenance mode message not showed in some pages
    • +
  • #7982 - Fix fingerprint generation for Plugin and Package materials
    • +
  • #8012 - PipelineConfig API: incorrect error mapping for stage authorization errors
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.3.0 and Plugin API changelog for 20.3.0.

+ +

Contributors

+ +

Aravind SV, Ganesh S Patil, Ketan Padegaonkar, Kritika Singh, Mahesh Panchaksharaiah, Marques Lee, Steven Streisguth, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.2.0

+
+
+

Support for Rules on Config Repositories (Pipeline as Code)

+ +

In order to provide fine-grained access control over the entities that are created by a config repository, GoCD adds support for defining rules on config repositories that specifies which environments, pipeline groups, pipelines the repository can refer to. +Please refer to the Specifying rules on Config Repository for more information.

+ +

Changes to SSL Support

+

There are important changes to how GoCD handles SSL support. If you are upgrading to GoCD 20.2.0, agents will have to be reconfigured to connect to the server. Please read the GoCD SSL Changes for more information.

+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.11 and CentOS 8 based docker images for GoCD Server are available.
    • +
  • #6031 - Improve Pipeline Material auto update mismatch error
    • +
  • #7736 - Improvements to wrapper properties examples
    • +
  • #7748 - Improve Logging - Add plugin load/update/remove logs
    • +
  • #7713 - Provide additional information about GoCD deprecated APIs
    • +
  • #3194 - Add the possibility to retrieve template parameters through the template API
    • +
+ +

Bug fixes

+ +
    +
  • #7737 - Fixed issue with moving pipeline between groups
    • +
  • #7676 - Fixed invalid run_instance_count during pipeline export
    • +
  • #7822 - Missing response body error when submitted Pipeline JSON has duplicate job name error
    • +
  • #7824 - Pipeline Config API does not return any error message for invalid job resources
    • +
  • #7830 - Don't showcase pending agents in edit agents modal
    • +
  • #7853 - Improve search on Config Repository SPA
    • +
  • #7709 - Leading space in commit message breaks material modification check
    • +
  • #7752 - Modification check failed for material: special characters are not allowed
    • +
  • #3103 - Missing parameter in dependent pipeline leads to unknown error in template configuration
    • +
  • #7747 - Operate permission cannot View pipeline group
    • +
+ +

Breaking Changes

+ + + +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.2.0 and Plugin API changelog for 20.2.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

20.1.0

+
+
+

Improvements to Role Based Access Control

+ +

As part of GoCD release v19.11.0, GoCD roles were enhanced to support granular authorization.

+ +

This release adds support to configure access permissions for cluster profiles and elastic agent profiles. Support for other GoCD entities will be added in subsequent releases.

+ +

Please refer to the Policy Documentation for Elastic Agent Configurations for more information.

+ +

UI/UX refresh

+ +

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages:

+ +

Pipeline Group Authorization Edit Page

+ +
+ Pipeline Group Authorization Edit Page +
+ +

Support for Postgres 10 and above

+ +

From this release the commercial GoCD PostgreSQL Addon will support Postgres version 10, 11 and 12.

+ +

Note: As per earlier announcement this Addon is expected to be open sourced in Q2 of 2020.

+ +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.11 based docker images for GoCD Agent are available.
    • +
  • #1364 - Introduce Get Job Instance API
    • +
  • #2990 - Make 'material name' accessible through Pipeline instance API
    • +
  • #3326 - History APIs for pipeline/stage/job instances should allow defining page size
    • +
  • #5717 - Showcase config repository validation errors on separate line
    • +
  • #7560 - Enable job settings link in elastic agent profile usages modal for pipelines coming from config-repos
    • +
  • #7575 - Expose current agent resources as GO_AGENT_RESOURCES environment variable
    • +
+ +

Bug fixes

+ +
    +
  • #7498 - Handle failing stage status animation
    • +
  • #7472 - Cancelled icon is not rendered for cancelled jobs on stage details page
    • +
  • #7509 - Config Repositories does not refresh when an elastic profile is added
    • +
  • #7534 - Pipeline Group API update gives 200 even when a non-existent role is passed
    • +
  • #7557 - Unable to run commands with multi-line arguments configured via UI
    • +
  • #7572 - Dashboard UI not updating on pipeline group authorization updates
    • +
  • #7603 - CPU Spike while visiting Elastic Agents Configuration page
    • +
  • #7654 - Fix for 19.12.0 upgrade failures if pipeline label contains package material name.
    • +
  • #7656 - Pipeline Group Admin should receive a 403 on create pipeline if the group specified does not exist
    • +
+ +

Deprecations

+ +
    +
  • The Alpine 3.7 based docker image for GoCD Agent has been removed. Alpine 3.7 has reached end-of-life in Nov 2019. Please use an image based on a newer version of the Alpine.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 20.1.0 and Plugin API changelog for 20.1.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole, Zamfir Catalin Alexandru

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.12.0

+
+
+

Read Only View for Config Repository Pipelines

+ +

Earlier users had to visit the source control repository to know the pipeline settings of the pipelines defined on config repository. Now, Users will now be able to view configurations of pipelines defined via config repositories in read-only mode within the GoCD application.

+ +
+ Read Only View for Config Repository Pipeline +
+ +

Improvements to Role Based Access Control

+ +

As part of GoCD release v19.11.0, GoCD added support to configure access permissions to environments using policies at a granular level. +This release adds support to configure access permissions for config repositories. Support for other GoCD entities will be added in subsequent releases.

+ +

UI/UX refresh

+ +

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages:

+ +

Elastic Agent Configuration Page

+ +
+ Elastic Agent Configuration Landing Page +
+ +
+ Elastic Agent Configuration Cluster Profile Page +
+ +
+ Elastic Agent Configuration Elastic Profile Page +
+ +

Pipeline Activity Page

+ +
+ Pipeline Activity Page +
+ +
+ Pipeline Activity Comment Page +
+ +

Agent Job Run History Page

+ +
+ Agent Job Run History Page +
+ +
+ Agent Job State Transition Page +
+ +

Other Improvements

+
    +
  • #7321 - Introduce Pipeline Comment feature to allow users commenting on a pipeline instance. Please refer to the documentation to know more about pipeline comment feature.
    • +
  • #7229 - Performance improvements to Pipeline Config updates through UI.
    • +
  • #3370 - Add pipeline group name to environment variable context during build assignment.
    • +
  • #7402 - Allow users to rename pipeline group via API.
    • +
  • #7370 - Environment SPA Improvements.
    • +
  • #7372 - Add Confirmation modal on server config SPA while switching tabs.
    • +
  • #7375 - Open new read only templates page upon clicking view templates from pipeline configurations page.
    • +
  • #7374 - Improve agent's API error message.
    • +
  • #6897 - Guess webhook repo url for ssh urls.
    • +
+ +

Bug fixes

+ +
    +
  • #7481 - Fix persistence issue with secure environment variables of an environment.
    • +
  • #7432 - Show error message when entity does not exist on SPAs.
    • +
  • #7356 - Show appropriate error message for disabled pipeline edit icon on templates SPA.
    • +
  • #7357 - Fix read only templates view jump issue.
    • +
  • #7359 - Disable deleting environments defined in config repository through API.
    • +
  • #7345 - Fix export pipeline to generate valid configuration for pipelines consisting of package repository materials.
    • +
  • #7373 - Fix project management configuration persistence issue.
    • +
  • #7415 - Allow users to cancel stage on maintainance mode page.
    • +
  • #7423 - Show validation error message for on cancel task.
    • +
  • #7456 - Fix loading issues with config repository SPA.
    • +
  • #7468 - Show appropriate error message when user does not have permissions to edit pipeline configurations.
    • +
  • #6363 - Show appropriate error message when pipeline does not exists on edit pipeline configurations page.
    • +
  • #7442 - Fix issue with positioning of tool tip in users management page.
    • +
  • #7336 - Add missing Send Test Email option on Email Configuration SPA.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.12.0 and Plugin API changelog for 19.12.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Andrew Bentley, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.11.0

+
+
+
+ Issue with Environment Variables of Environment: There is a known issue with GoCD release v19.11.0: Github issue #7481 causing the secure environment variables defined in an environment not to be persisted on the server. There is a GoCD release v19.12.0, which fixes this issue. It is recommended to use 19.12.0 (or above) installers. + +
+
+ + Users on GoCD release v19.11.0 are recommended to use the alternatives mentioned as part of the Github Comment to avoid this issue. + +
+
+ + Updated: Monday 23 DEC at 11:00:00 UTC 2019 +
+ +

Role Based Access Control

+ +

Traditionally, a Role in GoCD is a group of users. With this release, we are enhancing the purpose of Roles. Roles can now be used to control the access of different entities in GoCD, which earlier were accessible only by System Administrators.

+ +

System Adminstrators can configure permissions for a given role using policies at a granular level. This release adds support to configure access to environments, support for more entities will be added in subsequent releases.

+ +

Read the GoCD Policy documentation for more details.

+ +

UI/UX refresh

+

As part of our ongoing effort towards making the UI/UX consistent across all pages of GoCD, in this release we have rebuilt the following pages,

+ +

Server Configuration Page

+
+ New Server Configuration Page +
+ +

Environments Page

+
+ New Environments Page +
+ +

Templates Page

+
+ New Templates Page +
+ +

Pipelines Page

+
+ New Pipelines Page +
+ +

Other Improvments

+ +
    +
  • #7229 - Performance improvements to Pipeline Config updates through UI.
    • +
  • #6956 - Added support to load multiple plugins as a bundle.
    • +
+ +

Bug fixes

+ +
    +
  • #7296 - Fix issue with mounting directories as docker volume, if directories already exist
    • +
  • #7281 - Fix for Agents page constant shuffle.
    • +
  • #7285 - Fixed issue with weird lines showing up on agents table
    • +
  • #7138 - Fix for Agent Job History order inconsistency
    • +
  • #7212 - Error messages on agents SPA not getting displayed.
    • +
  • #2048 - Fixed issue with incorrect job cancel, in case of canceling run on all agent job
    • +
  • #7172 - Set JVM Properties in docker-gocd-agent-ubuntu
    • +
  • #7177 - Show appropriate error when user does not have permissions to operate on a pipeline or pipeline group.
    • +
  • #6754 - Fix for systemd not detected on Amazon Linux 2
    • +
  • #7301 - Include wrapper-config files to the GoCD backup process
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.11.0 and Plugin API changelog for 19.11.0.

+ +

Security

+ +

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. +In this release, a security issue responsibly disclosed by Wasin Sae-ngow was fixed.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Antonio Masucci, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Riko Stave, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.10.0

+
+
+

Database cleanup

+ +
+ Please make sure that a GoCD server backup is taken before upgrading to 19.10.0. +
+ +


+ +

There are some unnecessary data in the GoCD database which will be removed upon the first server start after upgrading to 19.10.0. +This cleanup will be done only for completed jobs and will remove historical data related to environment variables, artifact plans, resources and job-related metadata. +This will not affect any information in GoCD's configuration file.

+ +

Depending on the size of your database, you may experience some delay during startup while the data is being removed from the database. Please do not kill the GoCD server until the database upgrade completes. +If you do end up killing it, you might need to restore the database from the backup taken before this upgrade.

+ +
    +
  • 7d5d01f - Delete cruft from the DB for jobs that are completed.
    • +
+ +

Improved Agents page

+ +

Agents page has been improved in this release. Now it will have 2 tabs - Static and Elastic - for easy viewing and searching of static and elastic agents.

+ +
+ New Agents page - Static agents +
+ +
+ New Agents page - Elastic agents +
+ +

Optional upstream dependencies

+ +

Introduced ignore_for_scheduling flag at the pipeline dependency level to improve GoCD's ability to model pipelines, as described in this issue. +This flag allows run of an upstream pipeline to be ignored by the downstream pipeline. +This is useful in cases where a downstream pipeline has multiple materials and wants to have fine-grained control over which materials cause it to run. Previously, this was available only for SCM materials (like git, mercurial, etc). This flag is available on the material edit page, Pipeline Config API and the bundled JSON/YAML config repo plugins.

+ +

Other Improvements

+ +
    +
  • Starting this release, CentOS 8 based images for GoCD Agent are available
    • +
  • 2c93195 - Bundle Java 13 for all installers.
    • +
  • #4756 - Provide an option to sort by duration on the job run history page
    • +
  • #6289 - Expose scm material url and branch as environment variables to tasks
    • +
  • #6602 - Dashboard will show an info icon instead of settings icon for pipeline-as-code pipelines
    • +
  • #7113 - Added 'group' property to Get Pipeline Config API
    • +
  • #7155 - Added support for 'group' attribute in Update Pipeline Config API
    • +
+ +

Bug fixes

+ +
    +
  • #7002 - Honour hostname in agent autoregister properties
    • +
  • #7037 - Bring back UUID support in SVN post commit hook API
    • +
  • #7064 - Authorization config update API should not need id value
    • +
  • #7067 - Fix for Notification preferences not persisted
    • +
  • #7068 - Enable email support link is pointing to wrong link under preferences tab
    • +
  • #7107 - Fix for job details page error if agent is not yet assigned
    • +
  • #7126 - Fixed no response on deleting an auth config
    • +
+ +

Deprecations

+ +
    +
  • Starting this release, Fedora based docker image for GoCD Agent will not be published. Users can continue to use the older images and the agent will get auto-upgraded.
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.10.0 and Plugin API changelog for 19.10.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Rodny, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.9.0

+
+
+

Support for Java 8 and 10 removed

+ +

Support for Java 8 and 10 has been dropped from this release. This is in line with our official stance on Java we announced earlier this year post the Java Licensing Changes.

+ +

Starting 19.9.0, GoCD Server and Agent would only support Java 11 or 12. Support for Java 13 will be introduced soon. GoCD installers from 19.6.0 come with Java Runtime pre-bundled, so users no longer need to install it separately.

+ +

Users might need to upgrade the GoCD Agent Bootstrapper. More information can be found here

+ +

Other Improvements

+ +
    +
  • #911 - Moved agent configuration out of the main xml configuration.
    • +
  • #6919 - Improve performance of artifact download and digesting.
    • +
+ +

Bug fixes

+ +
    +
  • 4c54c9b - Fix git failure on CentOS 7 based GoCD agent docker images.
    • +
  • #6918 - Error on opening on job details in the absence of cluster profile
    • +
  • #6942 - Rules reordering not working on edit of secret config
    • +
  • #6952 - GoCD page suddenly asking for client certificate
    • +
  • #6968 - Materials API return 404 for existing materials and modifications in 19.8.0
    • +
  • #6973 - Ignore unknown properties while upgrading plugin profile configuration
    • +
  • #6979 - Add missing working directory replacement during agent duplication
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.9.0 and Plugin API changelog for 19.9.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Rajiesh N, Saurabh Mistry, Sebastian Goral, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.8.0

+
+
+

New Pipeline Creation Wizard

+ +

We have introduced a new simplified pipeline creation wizard as part of our ongoing UI/UX refresh for improving the user experience.

+ +

Feedback/ideas are welcome, please open an issue here to add your comments.

+ +
+ New Pipeline Creation Wizard +
+ +

Introduce support for latest API version

+ +

GoCD’s APIs are versioned. Accessing an API endpoint requires providing a version number as part of the Accept header. GoCD now allows accessing the latest version of an API by omitting the version number in the header. For instance, you can use Accept: application/vnd.go.cd+json instead of Accept: application/vnd.go.cd.v3+json. More information can be found on GitHub issue #6620.

+ +

Ability to trigger a stage only if the previous stage has succeeded

+ +

Introduced the attribute allowOnlyOnSuccess for approval at stage level. If the attribute is set to true, the stage can be manually triggered only if the previous stage (if there is one) has resulted in success. More information can be found on GitHub issue #6294.

+ +

Java 8 and 10 deprecation

+ +

Support for Java 8 and 10 will be removed in the next release of GoCD. GoCD installers come with Java Runtime pre-bundled, so users no longer need to install it separately. +The removal of Java versions is in line with the Java Licensing Changes we had announced earlier this year in this blog post.

+ +

Other Improvements

+ +
    +
  • Starting this release, Debian Buster (10) based images for GoCD Agent are available.
    • +
  • 08f7b6e - Slim down the windows installer sizes.
    • +
  • #6688 - Allow plugins to execute javascript as part of angular plugin view
    • +
  • #6802 - Add git, hg, svn, p4 version info to support output
    • +
  • #6826 - Optimized GoCD server and agent docker image size
    • +
  • #6832 - Synchronize user info with external sources
    • +
+ +

Bug fixes

+ +
    +
  • 6731045 - Fixed issue with analytics not loading up if AdBlock is enabled. A new version of analytics plugin has been released. Users will have to update to the same.
    • +
  • 35021fb - Fix jetty warning on agent connection.
    • +
  • fc61beb - Fix the DIND image. Now the docker service is started using root user.
    • +
  • f10025b - On uninstall, cleanup temp dirs that are left behind by server process.
    • +
  • #5587 - Re-running failed jobs leaves a warning with null exception in the logs
    • +
  • #6376 - Rerun old stage failing without providing console output
    • +
  • #6409 - No indication of failure when subsequent stages are run after material config is changed post first stage run
    • +
  • #6640 - Pipeline pause message is not shown completely on dashboard
    • +
  • #6682 - Environments Get API does not honor If-None-Match header
    • +
  • #6727 - Template Authorization API returns 404
    • +
  • #6815 - Fix for world-writable files in go-agent and go-server packages.
    • +
  • #6827 - Upgrading GoCD linux packages from 19.7.0 to 19.8.0 overwrites wrapper-properties.conf file
    • +
  • #6855 - GoCD server emits "Weak cipher suite" warnings on startup
    • +
  • #6879 - Sync environments when a config repo is deleted
    • +
  • #6892 - Fixed issue with GoCD installation on Windows
    • +
+ +

APIs

+ +

Improvements, deprecations and breaking changes in the API and plugin API have been moved to their respective changelogs - API changelog for 19.8.0 and Plugin API changelog for 19.8.0.

+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Sneha Patil, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Veerababu Kona, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.7.0

+
+
+
+ Windows Installer Issue: There is a known issue with the fresh install of 19.7.0 windows installers: GitHub issue #6892. There is a 19.8.0 release, which fixes this issue. It is recommended to use 19.8.0 windows installers. + +
+
+ + Updated: Friday 06 SEP at 07:25:00 UTC 2019 +
+ +

Bug Fixes

+ +
    +
  • #6666 - Fixes issue with GoCD server/agent not automatically starting on a server restart.
    • +
  • #6674 - Fixes issues with migrating user defined Environment Variables on upgrade to 19.6.0
    • +
  • #6677 - Disable directory listing for assets directory.
    • +
  • #6684 - Bring back GO_ENVIRONMENT_NAME environment variable as part of Job Console.
    • +
  • #6690 - Fixes issue with dependency on sysvinit-tools for RPM distros.
    • +
  • #6699 - Allow exiting running GoCD docker containers by sending SIGINT ctrl-c signal.
    • +
+ +

Versions of Java this release of GoCD works with

+
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 has been deprecated. The support for the same will be removed in a release scheduled for November 2019.
    • +
  • The Plugin Info API version 5 has been deprecated. This version will be removed in a release scheduled for Sept 2019. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline config API version 7 has been deprecated. This version will be removed in a release scheduled for Oct 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned get all materials API has been deprecated in favor of get all materials API v1. This version will be removed in a release scheduled for Oct 2019.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.6.0

+
+
+
+ Known issues: There are two known issues with the 19.6.0 installers: GitHub issue #6666 and GitHub issue #6674 with workarounds mentioned in the issues. There is is a 19.7.0 release, which fixes these issues. It is recommended to upgrade directly to 19.7.0. + +
+
+ Windows Installer Issue: There is a known issue with the fresh install of 19.6.0 windows installers: GitHub issue #6892. There is a 19.8.0 release, which fixes this issue. It is recommended to use 19.8.0 windows installers. +
+
+ + Updated: Friday 06 SEP at 07:25:00 UTC 2019 +
+ +

Secrets Management

+ +

We have enhanced support for managing secrets in GoCD. GoCD now provides an ability to refer to secrets defined in an external Secret Manager. With this, apart from referring to secrets, users can manage permissions for these secrets and rotate them without any changes to GoCD configuration.

+ +

Support for Secrets Management is provided using plugins. We have introduced a new secrets extension using which plugin authors can write a plugin to support a Secret Manager of their choice. We have built a File based Secret Management plugin which is bundled along with GoCD.

+ +

Please refer to the Secret Management Documentation for more information.

+ +
+ Secret Management SPA +
+ +

GoCD Installer Changes

+ +

There is some variation in how GoCD server and agents across multiple different operating systems and installer types need to be managed by system admins. To reduce the maintenance overhead and cognitive load, all the installers have undergone varying degrees of changes.

+ +
+ If you are an existing GoCD user upgrading from an older version of GoCD, please read about the changes before performing an upgrade. Users installing GoCD for the first time should not be affected. +
+ +

Running Dockerized GoCD Containers as Non Root

+ +

Starting from this release, GoCD containers run as non-root user, by default. The Dockerized GoCD application will run as go:root (uid:1000, gid:0) user instead of running as root:root (uid:0, gid:0). For more information, checkout Running Dockerized GoCD Containers as Non Root blog post.

+ +

Simpler HTTP authentication for agent-server communication

+ +

Historically, GoCD agent server communication required SSL/TLS mutual authentication using X509 certificates. GoCD version 19.6 disables mutual TLS by default. This will allow GoCD administrators to terminate agent-server communication at load balancers or reverse proxies.

+ +

To turn on the old behavior and enable mutual TLS, set the environment variable GO_USE_TOKEN_AUTH to false.

+ +

Versions of Java this release of GoCD works with

+
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • Starting this release, Alpine 3.10 based docker images for GoCD Agent are available.
    • +
  • #6567 - Order pipeline group names in alphabetical order when cloning a pipeline.
    • +
  • #6225 - Introduce stage building animation on dashboard.
    • +
  • #6471 - Display pipelines and environments defined by config repository.
    • +
  • #6423 - Collect Metrics for Trial XP in GoCD as part of GoCD data sharing.
    • +
+ +

Security

+ +

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. +In this release, a security issue responsibly disclosed by Heinrich was fixed.

+ +

Bug fixes

+ +
    +
  • #6628 - Fix internal server error on consuming Packages Index API.
    • +
  • #6630 - Fix internal server error on consuming Package Repositories Index API.
    • +
  • #6615 - Fix Job requiring elastic agent starves forever in case of multiple reschedule.
    • +
  • #6468 - Shouldn't allow to save pipeline config with empty template.
    • +
  • #6328 - Cancel the scheduled elastic agent jobs on GoCD upgrade from version prior to 19.3.0.
    • +
  • #6565 - Show spinner in modal when performing save/update.
    • +
  • #6547 - Update footer banner message when server is in maintenance mode.
    • +
  • #6017 - Improved error messages in APIs consuming environment variables.
    • +
  • #6350 - Show Raw console logs of a building job.
    • +
  • 2ad7510 - fixed subversion SASL auth error when subversion material use the svn protocol.
    • +
+ +

New Deprecations

+ +
    +
  • The Plugin Info API version 5 has been deprecated. This version will be removed in a release scheduled for Sept 2019. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline config API version 7 has been deprecated. This version will be removed in a release scheduled for Oct 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned get all materials API has been deprecated in favor of get all materials API v1. This version will be removed in a release scheduled for Oct 2019.
    • +
+ +

Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 8 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 has been deprecated. The support for the same will be removed in a release scheduled for November 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • The Fedora 28 based docker image for GoCD Agent has been removed. Fedora 28 has reached end-of-life in June 2019. Please use an image based on a newer version of the Fedora.
    • +
  • The Stage History unversioned API has been removed. Version 1 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been removed. Version 6 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.5.0

+
+
+

Replacing X.509 with simpler HTTPs token-based authentication for Agent-Server Communication - Beta feature

+ +

This is a beta feature: agent-server commnication can be toggled to use token-based authentication instead of self-signed X.509 certificates from the GoCD server. +To enable token-based auth, set the environment variable GO_USE_TOKEN_AUTH on the GoCD agent to true.

+ +

With token-based authentication enabled, agents can use load balancers or reverse proxy DNS names and not GoCD server DNS/IP. It is also not required to expose port 8154 on the GoCD server. TLS termination can happen at the reverse proxy instead.

+ +

Other Improvements

+ + + +

Bug fixes

+ +
    +
  • #6295 - Improved errors UI in Config Repo.
    • +
  • #5667 - Do not validate plugin properties while deleting a plugin profile entity.
    • +
  • #6278 - All rails APIs return strong Etag.
    • +
  • #6337 - Start Docker deamon process for dind image.
    • +
  • #6325 - Supress warnings thrown in server logs when a user visits job console of jobs either not assigned or not started writing to console.
    • +
+ +

Versions of Java this release of GoCD works with

+ +
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

Please refer to this blog post for GoCD official stance on supported Java versions.

+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking Changes

+ +
    +
  • The Dashboard API version 2 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been removed. Fedora 28 has reached end-of-life in June 2019. Please use an image based on a newer version of the Fedora.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Rajiesh N, Saurabh Mistry, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.4.0

+
+
+

Improved Git and Mercurial material configurations

+ +

Introduced username and password (or encryptedPassword) attributes on Git and Mercurial materials. Users can now use these fields to setup credentials in a secure manner, instead of putting credentials in the URL. The YAML, JSON and Groovy config repo plugins have been updated to allow these additional fields on material definitions.

+ +

Users can also utilize the newly introduced branch attribute on Mercurial materials to specify the branch instead of specifying in the URL.

+ +
+ Users are advised to move their credentials from the URLs into these attributes. This allows passwords to be encrypted and stored in the configuration. +
+


+
+ Changing the material configuration will be treated as a new material for the corresponding pipeline, which in turn will trigger the pipeline. +
+ +

Introduced support for Java 12

+ +

Starting this release, GoCD has now added support for Java 12. All the docker images and installers for Windows and OSX are bundled with a supported version of Java (not necessarily 12).

+ +

Please refer to this blog post for our official stance on supported Java versions going forward.

+ +

Versions of Java this release of GoCD works with

+ +
    +
  • Java 8 (Deprecated)
    • +
  • Java 10 (Deprecated)
    • +
  • Java 11
    • +
  • Java 12
    • +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • Starting this release, Fedora 30 based docker images for GoCD Agent are available.
    • +
  • #6131 - Show the affected pipelines in Server Health Messages when material update fails.
    • +
  • #6245 - Remove redundant pluginId attribute from agentProfile tag.
    • +
  • #5923 - Improve logging for Access Token API requests.
    • +
+ +

Bug fixes

+ +
    +
  • #6216 - Fix encryption API to honour "go.encryption.api.max.requests" system property.
    • +
  • #6030 - Modification check failed for material for pipelines that polling is disabled and or are paused.
    • +
  • #6143 - Config Save successfully completes without updating the changes.
    • +
  • #6304 - Allow editing pipelines, agents and env vars for environment with special characters in name.
    • +
  • #6228 - Personal access tokens taking too long to generate.
    • +
  • #6030 - Server health message noise for disabled or paused pipelines with failed modification checks
    • +
  • A security fix regarding GoCD cruise-config.xml save has been identified and fixed in the current release. Users are advised to update their GoCD servers to the latest version.
    • +
+ +

New Deprecations

+ +
    +
  • The Pipeline config API version 6 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 7 of the API is available, and users are encouraged to use it.
    • +
  • The Config repo API version 1 has been deprecated. This version will be removed in a release scheduled for Aug 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Support for Java 8 and Java 10 has been deprecated. The support for the same will be removed in a release scheduled for September 2019.
    • +
+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Dashboard API version 2 has been deprecated. This version will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • TFS workspace location on GoCD agents has been changed to be a server workspace, rather than a local workspace. See: #5427 - for more information. This can affect users who use TFS materials.
    • +
  • The Alpine 3.6 based docker image for GoCD Agent has been removed. Alpine 3.6 has reached end-of-life in May 2019. Please use an image based on a newer version of the Alpine.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.3.0

+
+
+

Multi-cluster support for Elastic Agent

+ +

Now elastic agent can be created in different cluster based on the cluster profile. Elastic Profiles SPA is updated to reflect cluster profiles and elastic agent profiles.

+ +
+ Cluster Support +
+ +

To know more about about Cluster Profiles click here.

+ +

Introduced elastic agent extension v5 to support cluster profiles. For more info refer Elastic Agent Plugin Endpoint documentation.

+ +
+ Upgrade instructions: In order to perform a graceful upgrade, it's advised to use the maintenance mode to make sure that all running elastic agent jobs have finished, before upgrading to 19.3.0 or a later release of GoCD. If not, you might need to cancel any previously started elastic agent jobs after the upgrade. +
+ +

Improved Backup SPA

+ +

SPA is updated to show real-time progress of your GoCD server backup.

+
+ Backup SPA +
+ +

API Improvements

+ + + +

Other Improvements

+ +
    +
  • #6036 - Improvements to the user management page.
    • +
  • #2123 - Git shallow clone will also apply to submodules.
    • +
  • #6190 - Improved login page design and added a logout page.
    • +
  • #5885 - Provided an option to create pipeline within a group from dashboard.
    • +
  • #5978 - Added webhook endpoint for hosted bitbucket servers.
    • +
  • #6043 - Allow reordering of pipelines from config repositories. This adds an optional display_order property for pipelines defined in config repositories, which allow you to order pipelines.
    • +
  • Improve consistency of some error messages generated by GoCD server.
    • +
  • macOS installers will no longer ship as osx .app files. The installers now ship as a zip file, with a shell script. We believe this provides much better flexibility and allows users to run the GoCD agent and server in a location of their choice.
    • +
+ +

Bug fixes

+ +
    +
  • #5956 - Fixed issue with environments API incorrectly rendering encrypted variables as ****** instead of the correct encrypted value.
    • +
  • #5886 - Do not allow assigning an agent to an environment defined in config repository environment.
    • +
  • #5968 - Fix spurious e.map is not a function javascript error for notifications.
    • +
  • #5974 - Unable to expand/collapse environments with name containing special characters.
    • +
  • #5962 - GoCD shows HTTP Basic Auth dialog when after user is logged out.
    • +
  • #6011 - Fix errors with parsing git log when coloring is turned on using .gitconfig.
    • +
  • #5967 - Environments api will accept either encrypted_value or value.
    • +
  • #3635 - GoCD can update git submodules if a custom name is provided for one.
    • +
  • #5973 - Fixed issue with expanding environment panel with name containing special characters
    • +
+ +

New Deprecations

+ +
    +
  • The Elastic Agents plugin extension v4 has been deprecated. This version will be removed in a release scheduled for August 2019. Plugin developers should use version 5 of the plugin API.
    • +
+ +

Deprecations

+ +
    +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in an upcoming release. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • Unversioned get stage history API has been deprecated in favor of get stage history API v1. This version will be removed in a release scheduled for July 2019.
    • +
  • The Dashboard API version 2 has been deprecated. This version will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The Plugin Info API version 4 has been deprecated. This version will be removed in a release scheduled for July 2019. Version 5 of the API is available, and users are encouraged to use it.
    • +
  • The Alpine 3.6 based docker image for GoCD Agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
  • The Fedora 28 based docker image for GoCD Agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • The Elastic Agent Profiles API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it. With the introduction of support for clusters all Elastic Agent Profiles need to be associated with a cluster. Since version 1 of the API does not support clusters, as an exception this API had to be removed without deprecation.
    • +
  • The Dashboard API version 1 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API version 1 has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Users API version 2 has been removed. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been removed in favor of Get Stage Instance API v1.
    • +
  • The Ubuntu 14.04 based docker image for GoCD Agent has been removed. Ubuntu 14.04 has reached end-of-life in April 2019. Please use an image based on a newer version of the Ubuntu.
    • +
  • The elastic agent plugin extension version 3 has been removed. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. Users should upgrade their plugins to the latest version to see these new features.
    • +
  • GoCD will now require minimum git version 1.9. This has been done to improve support for cloning git submodules.
    • +
  • For Pipelines using git materials, ignored files will also be cleaned from the working directory. The command has been changed to git clean -dffx instead of git clean -dff.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dhanashri Pagar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Ketan Sangle, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sandro Heinzelmann, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Viraj Patil, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.2.0

+
+
+

Access Tokens

+ +

We have introduced support for personal access tokens. GoCD users can now generate tokens through the application or the Access Token API and use them to access the GoCD APIs rather than passing their username & password. The tokens inherit the privileges of the user who created them.

+ +

Personal Access Token:

+
+ Personal Access Token +
+


+ +

Access Token Management

+
+ Admin Access Token +
+


+ +

To know more about about Access Tokens click here.

+ +

Github Oauth, GitLab Oauth and LDAP authorization plugins are migrated to authorization extension v2 to support access token based authentication for APIs. Please provide feedback/ideas by opening a GitHub issue on respective repository.

+ +

Google Oauth plugin is upgraded to use authorization extension v2 however it does not have support for access token based API authentication.

+ +

Improved pipeline pause information

+

Paused pipelines now show the time at which they were paused, along with the reason for pausing.

+ +
+ Pipeline Info when Paused +
+


+ +

New User Management Page

+

We have rewritten the User summary page, now known as User Management, to improve the user experience. Please provide feedback / ideas by opening a GitHub issue

+ +
+ User Management SPA +
+


+ +

Config Repo Improvements

+ +
    +
  • b2c6384 - Reparse and merge ConfigRepos on any change in Config Repo configuration. (#5792)
    • +
  • ed02069 - Allow users to configure empty secure environment variables.
    • +
  • 738f763 - Better error messages on Config Repo SPA in case of invalid ID.
    • +
  • d9d3c0a - Expand the Config Repo panels that are in an error state. (#5650)
    • +
  • #5756 - Added support to add global SCMs through config repo.
    • +
  • #5579 - Introduced Config Repo preflight API v1 endpoint.
    • +
+ +
+ Config repo improvements +
+ +

API Improvements

+ + + +

Authorization extension version 2

+ +
    +
  • 32cfcc5 - Introduced Authorization Extension version 2.
    • +
+ +

Other Improvements

+ +
    +
  • 3317123 - Show maintenance mode updated by timestamp along with date. (#5786)
    • +
  • 2b64f3f - Better error messages on plugins page when an installed plugin is incompatible with the GoCD server. (#5614)
    • +
  • 6a560ee - Display pause timestamp on the dashboard when a pipeline is paused. (#5719)
    • +
  • 2665b54 - Show agents assigned to environments via config repository. (#5761)
    • +
  • 3317123 - Added time stamp for the last triggered maintenance mode. (#5786)
    • +
+ +

Bug fixes

+ +
    +
  • 9a1eaf3 - Do not remove MaterialHealthStateScope for Config Repo materials. (#5651)
    • +
  • ba49547 - Disable job settings link for pipelines defined in Config Repo on elastic profiles page. (#5604)
    • +
  • 3f2fc49 - Made status report button state on elastic profiles page consistent with the status report button on plugins page. (#5776)
    • +
  • 6c4da91 - Fixed environments api version 2 etag generation issue. (#5807)
    • +
  • 38e68d0 - Render console log containing new line character ("\n"). (#5037)
    • +
  • #5705 - Fix for high CPU usage on console logs/tests page.
    • +
  • #5897 - Killing agent via stop command honors the process ID.
    • +
  • #5788 - Fixed back button navigation on dashboard.
    • +
+ +

New Deprecations

+
    +
  • The Fedora 28 based docker image for gocd agent has been deprecated and will not be built after June 2019 release of GoCD. This will be done as Fedora 28 will reach end-of-life in June 2019.
    • +
  • The Dashboard API v2 has been deprecated. This version of the API will be removed in a release scheduled for June 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Deprecations

+
    +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in a release scheduled for April 2019. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Dashboard API v1 has been deprecated. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been deprecated in favor of Get Stage Instance API v1. This version will be removed in a release scheduled for April 2019.
    • +
  • The Users API v2 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Ubuntu 14.04 based docker image for gocd agent has been deprecated and will not be built after April 2019 release of GoCD. This will be done as Ubuntu 14.04 will reach end-of-life in April 2019.
    • +
  • The Alpine 3.6 based docker image for gocd agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • f12cbf3 - Remove the pipeline quick edit SPA.
    • +
  • 74e4e3c - Support for DES was deprecated as part of 18.7.0 release in favor of AES. The support for DES is removed as part of this release. Users who have defined encrypted values in their configuration repositories should update them to use AES encryption. (#5646)
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sanjana Bayya, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

19.1.0

+
+
+

GoCD Maintenance mode

+ +

GoCD maintenance mode can be utilized by the GoCD system administrator to safely restart or upgrade the GoCD server without having any running jobs reschedule when the server is back up. Initiating maintenance mode will cause various sub-systems of GoCD to stop working making sure server is not performing any operation.

+ +
+ Maintenance Mode Feature +
+


+ +

To know more about about GoCD Maintenance Mode click here.

+ +

Improved Pipeline as Code experience.

+ +

Continuing on the road towards improving GoCD's pipelines as code / config repositories experience, this release introduces the ability to export a GoCD pipeline to a format which can be used by the config repository plugins (for instance, YAML or JSON plugins). You can then check in these pipeline definitions to a repository and remove them from GoCD's config.

+ +
+ Pipeline Export Feature +
+


+ +

More improvements to this feature are in pipeline. Add your feedback or suggestions here

+ +
    +
  • 45aab5e - Show validation errors on config repo SPA. (#5711)
    • +
+ +
+ Config SPA Error +
+


+ +
    +
  • 6c88929 - Performance improvement to loading multiple Config Repos on server restart. (#5663)
    • +
+ +

API Improvements

+ + + +

Plugin API improvements

+ +
    +
  • b851373 - Adding Server version information in v2 ServerInfoProcessor. (#5686)
    • +
+ +

Other Improvements

+ +
    +
  • d6f7b49 - Allow user to override server keystore password using system environment. (#5592)
    • +
  • 51919ab - Set extra properties for the agent, from server. (#5666)
    • +
  • 143054f - Plugin Info request processor versioning. (#5654)
    • +
  • 792ae61 - Show cancelled by on the dashboard on hovering over a stage. (#5683)
    • +
  • a06b497 - Improved performance of Envrionments API. (#5698)
    • +
+ +

Bug fixes

+ +
    +
  • 9a1eaf3 - Do not remove MaterialHealthStateScope for config repo materials. (#5651)
    • +
  • 773b68d - Fix for header issue on edit pipeline. (#5596)
    • +
  • e6fd8f7 - Show error on delete when artifact store is referred in pipelines. (#5634)
    • +
  • 90e2523 - Plugin settings modal show save failure error. (#5645)
    • +
  • ee08190 - Decrease z-index to make admin menu render on top of console controls. (#5659)
    • +
  • a9812de - Toggle TFS workspace location on agent. (#5427)
    • +
  • c647a96 - Artifact store delete message was not visible on error.
    • +
  • 70f9448 - Updated clone auth config message to use newly created auth config id.
    • +
+ +

Deprecations

+ +
    +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Get Server Info processor version 1 has been deprecated. This version will be removed in a release scheduled for April 2019. Plugin developers should use version 2 of the Get Server Info processor.
    • +
  • The Dashboard API v1 has been deprecated. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Unversioned Get Stage Instance API has been deprecated in favor of Get Stage Instance API v1. This version will be removed in a release scheduled for April 2019.
    • +
  • The Users API v2 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 3 of the API is available, and users are encouraged to use it.
    • +
  • The System Admins API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Roles API v1 has been deprecated. This version of the API will be removed in a release scheduled for April 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
  • The Ubuntu 14.04 based docker image for gocd agent has been deprecated and will not be built after April 2019 release of GoCD. This will be done as Ubuntu 14.04 will reach end-of-life in April 2019.
    • +
  • The Alpine 3.6 based docker image for gocd agent has been deprecated and will not be built after May 2019 release of GoCD. This will be done as Alpine 3.6 will reach end-of-life in May 2019.
    • +
+ +

Breaking Changes

+ +
    +
  • f12cbf3 - Remove the pipeline quick edit spa.
    • +
  • 74e4e3c - Support for DES was deprecated as part of 18.7.0 release in favor of AES.The support for DES is removed as part of this release. Users who have defined encrypted values in their configuration repositories should update them to use AES encryption. (#5646)
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Eric Cheung, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mansi Shah, Marques Lee, Naveen Bhaskar, Prateek Baheti, Rahul Pargaonkar, Rajiesh N, Sanjana Bayya, Sheroy Marker, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.12.0

+
+
+

Manage Config Repositories through UI

+ +

We have added a new Config Repositories page. This page lists existing config repos and allows CRUD (Create-Read-Update-Delete) operations for a config repo. This page has the ability to show errors and allows users to force a check of the repository.

+ +
+ Config Repositories Page +
+


+ +

UI/UX Improvements

+ +

The Elastic agent profiles page now provides the ability to view jobs configured for an elastic profile.

+ +
+ Elastic Profile List Jobs +
+


+ +

Admin Menu has been improved for better accessibility.

+ +
+ Admin Menu +
+ +

Other Improvements

+
    +
  • 0a15ede - Performance improvement to loading multiple Config Repos on server restart. (#5010)
    • +
  • df76be9 - GoCD Admins can now configure the server to set HSTS header as part of HTTPs response. (#5557) Refer docs for configuring the header.
    • +
+ +

API Improvements

+ + + +

Security

+

We regularly fix security issues reported by security researchers. Upgrading to the latest release is always recommended. In this release, a security issue responsibly disclosed by Jake +and Imran Siddiqui was fixed.

+ +

Bug fixes

+ +
    +
  • cb9ab57 - Fixed an issue where the first personalization tab showed all pipelines on page load. (#5512)
    • +
  • bbeebad - Fix for email notification not sent on job cancellation due to timeout. (#5370)
    • +
  • 0efb7d0 - Allow javascript to be executed in the plugin settings modal. (#4797)
    • +
  • b00b026 - Fixed links pointing to pipeline dependency graph. (#5535)
    • +
+ +

Installer Changes

+ +
    +
  • +

    OSX installers are now bundled with adoptopenjdk JRE 8, commit 6814d48 - fixes an issue with Server and Agent not working on JRE >=9. (#3934)

    +
    • +
  • +

    Support for Java 11 was introduced in 18.10.0. Windows installers have been changed to bundle with OpenJDK 11.

    +
    • +
+ +

Deprecations

+ +
    +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
  • The Dashboard API v1 has been deprecated in this release. This version of the API will be removed in a release scheduled for March 2019. Version 2 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking Changes

+ +
    +
  • Windows installers are now bundled with OpenJDK 11. In absence of 32 bit JDK distributions from OpenJDK we have stopped providing 32 bit windows installers from this release.
    • +
  • With this release there will be limited support for IE11. Visual bugs can be expected on this browser.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Armin G Jazi, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kritika Singh, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Sana Jahan, Steven Streisguth, Tomasz Setkowski, Varsha Varadarajan, Vishal Devgire, Vrushali Waykole

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.11.0

+
+
+

Improvements

+ +
    +
  • 7203cb3 - Allow artifact plugins to introduce new environment variables to be used by subsequent tasks. (#5188)
    • +
+ +

Performance Improvements

+ +
    +
  • In this release, users with ~100 or above agents will see a significant performance improvement on the agents page and when invoking the agents API. In 18.10, due to upgrading some libraries to support Java 9 (and beyond) there were some performance regressions with the agents page (and the agents API).
    • +
  • 451cef0 - Improve performance of some pipeline lookups in the database by removing a cast operation.
    • +
  • dcf69b0 - Do not lookup pipelines by both label and counter, prefer a counter. (#5256)
    • +
  • f0d1a6e - Use byte arrays (instead of strings) to represent the config XML. This improves performance of some of the admin pages and also quickly renders large configuration XML.
    • +
+ +

New APIs

+ +

Introduced APIs to

+ + + +

Bug fixes

+ +
    +
  • ad87a7c - Ensure that the GoCD server health check API returns an HTTP 200 OK status code when backup is in progress. (#5416)
    • +
  • 69e4b39 - Render the dashboard again after backup is completed. (#5391)
    • +
  • 98853a2 - Fix a NullPointerException in the logs when a pipeline that is building is removed from the config file.
    • +
  • aabbf06 - Fix 500 server error when calling pipeline config API by ensuring that the default artifact directory is not null. (#5342)
    • +
  • 6fddce6 - Prevent console logs of cancelled jobs running on elastic agents from being lost. (#5325)
    • +
  • e95e88b - Agent will ensure that plugins are loaded before performing any jobs. (#5169)
    • +
  • 49d7413 - Do not send email notification if user account is disabled. (#5277)
    • +
  • 13be966 - Re-enable pipeline operation buttons on dashboard if pipeline trigger fails. (#5153)
    • +
+ +

Docker Images

+ +

We have added support for the GoCD agents for Fedora-28 and Fedora-29.

+ +

Deprecations

+ +
    +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return an AES cipher-text and users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This version will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
+ +

Breaking Changes

+ +
    +
  • The alpine 3.5 based docker image for GoCD agent has been removed since alpine 3.5 has reached end of life.
    • +
  • The Template Config API v3 has been removed. Version 4 of the API is available, and users are encouraged to use it.
    • +
  • The Pipeline Config API v5 has been removed. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Feeds API for getting a Stage no longer supports the pipeline_label URL parameter. Users should use the pipeline_counter parameter instead.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Sana Jahan, Steven Streisguth, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.10.0

+
+
+

Support for Java 10 and 11

+ +

While we continue to support Java 8, GoCD has now added support for Java 10 and 11. With Oracle moving towards a 6 month cadence for newer releases we are evaluating the process to keep in sync with the new cadence. Watch this space for more information in the coming releases.

+ +

Environments Page

+ +

Originally the Environments page grouped the pipelines by environment with an option for admins to edit the environment. With the introduction of the new pipeline dashboard users have an option to group the pipelines by Pipeline Group or Environment.

+ +

With this release we have moved the environments page under the Admin tab. This page lists all the configured environments with an option to edit them.

+ +
+ Environments page moved under Admin tab +
+ +

Elastic Agent Extension V4

+ +

Upgraded the Elastic Agent Extension to Version 4. With this version GoCD notifies the plugin on completion of Job +run by an elastic agent.

+ +

New APIs

+ + + +

Improvements

+ +
    +
  • 69559f9 - Added support for referencing Environment Variable in Pipeline Label. (#5180)
    • +
  • 1ed99a0 - Allow non-admins to view all analytics other than dashboard analytics. (#5237)
    • +
+ +

Bug fixes

+ +
    +
  • 7b83e68 - Validate fetch artifact config before save. (#5202)
    • +
  • 9f17781 - Set status 503 when backup is in progress. (#5222)
    • +
  • fa31d58 - Fix for email notification filter not acknowledging 'Only if it contains my check-ins'. (#5238)
    • +
  • 1cce495 - Fix ETag computation for DataSharing Settings API. (#5184)
    • +
  • 0349a02 - Timer triggered pipelines are not scheduled on a standby server. (#5234)
    • +
+ +

Deprecations

+ +
    +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for November 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for November 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
  • The elastic agent plugin extension version 3 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the elastic agent plugin api to allow adding support for job completion request. The docker, docker swarm, kubernetes and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.
    • +
  • The notification plugin extension version 3 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 4 of the notification plugin api.
    • +
  • The analytics plugin extension version 1 has been deprecated. This versions will be removed in a release scheduled for Mar 2019. Plugin developers should use version 2 of the analytics plugin api.
    • +
+ +

Breaking Changes

+ +
    +
  • We have stopped building ubuntu 12.04 based docker image for gocd agent as ubuntu 12.04 is now end-of-life.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Danilo Sato, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kosta Welke, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Ravi Ranjan, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.9.0

+
+
+

Backups on a schedule

+ +

This release allows performing a backup on schedule. GoCD now allows executing a script once the backup completes. This feature removes the need for GoCD administrators to execute and monitor custom "cron-like" jobs to ensure that backups are completed.

+ +

For example: Users can now add the following snippet to the config XML to perform a backup once a night at 10pm on weekdays and call the /usr/local/bin/upload-to-s3 script after the backup is done:

+ +
<server>
+  ...
+  <backup schedule="0 0 22 ? * MON-FRI" 
+          postBackupScript="/usr/local/bin/upload-to-s3"
+          emailOnSuccess="false"
+          emailOnFailure="true"/>
+</server>
+
+ +

Analytics Extension V2

+ +

Upgraded the Analytics Extension to Version 2. This version adds support for showing analytics on the Agents and Value Stream Map(VSM) page.

+ +

Notification Extension V4

+ +

Version 4 of the Notification Extension enchances the existing Stage Status notification message to include the material fingerprint. It also provides details of previous stage(if any) responsible for triggering the current stage.

+ +

Bug fixes

+ +
    +
  • 8e0966d - Fixed scroll behaviour of filter tabs on the dashboard when navigating using the tabs dropdown. (#5097)
    • +
  • 0fdfe21 - Fix the search box width on the add/edit views modal on the dashboard.
    • +
+ +

Deprecations

+ +
    +
  • The ubuntu 12.04 based docker image for gocd agent has been deprecated and will not be built in the upcoming releases of GoCD. This is done because ubuntu 12.04 is now end-of-life.
    • +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.8.0

+
+
+

Flexible & Personalized Dashboard

+ +

We have made several improvements to the pipeline view on the new dashboard to make it more personal and relevant to our users.

+ +

Group pipelines either by pipeline groups or environments

+ +
+ grouping by environment or pipeline group name +
+


+ Create personalizations based on your preference

+ +
+ create new personalization view +
+


+ +

Make views more relevant by showing only those pipelines that are building or failed

+ +
+ show only building and failed pipelines +
+


+ +

Re-order views to your liking

+ +
+ reorder views +
+


+ +

Accessibility Improvements

+ +

We have made some accessibility improvements which makes it easier for people +using screenreaders to use the new dashboard.

+ +

Data Sharing Update

+ +

As of this release (18.8), GoCD collects information regarding jobs run by elastic agents and pipelines added through config repo. These metrics help us gauge the effectiveness of the pipeline as code feature and elastic agent plugins.

+ +
+ Data Sharing +
+


+ +

New APIs

+ + + +

Improvements

+ +
    +
  • 1ca78a3 - Improve log messages at server startup when plugins are not configured.
    • +
  • #5041 - Pipelines created via the PipelineConfig API are not paused by default now
    • +
  • GoCD server image is now updated to alpine 3.8.
    • +
  • Published 2 new GoCD agent images for docker based on alpine 3.8 and ubuntu 18.04.
    • +
+ +

Performance Improvements

+ +
    +
  • #4965 - Improve performance of config saves when config repositories are configured.
    • +
+ +

Breaking changes

+ +
    +
  • GoCD is no longer an OAuth provider. This integration was primarily used for integration with Mingle and the commercial business-continuity addon. Users who have been using GoCD's OAuth provider for the commercial business-continuity addon should read the business-continuity release notes before upgrading their GoCD servers.
    • +
+ +

Bug fixes

+ +
    +
  • d5fd967 - Fetch artifact task should support ./ as source directory for backward compatability. (#4810)
    • +
  • #4971 - Do not expose gocd server class-loader to a plugin.
    • +
  • #5020 - Request logging broken after loading indicator was introduced in version 18.7.0.
    • +
  • #3390 - Deleting pipeline config via API don't notify scheduleService to cancel job
    • +
  • dfa0d22 - Fixed config repo cloning using API. (#5013)
    • +
+ +

Deprecations

+ +
    +
  • The ubuntu 12.04 based docker image for gocd agent has been deprecated and will not be built in the upcoming releases of GoCD. This is done because ubuntu 12.04 is now end-of-life.
    • +
  • The alpine 3.5 based docker image for gocd agent has been deprecated and will not be built after November 2018 release of GoCD. This will be done as alpine 3.5 will reach end-of-life in November 2018.
    • +
  • With the introduction of AES for encryption/decryption in release 18.7.0, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated in release 18.7.0. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Anisha Roofi, Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Chandrakanth Nagaraj, Dilip Nandakumar, Ganesh S Patil, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Noah Huppert, Pranav Bansod, Rahul Pargaonkar, Rajiesh N, Reuben James, Senthil R, Steven Streisguth, Tina Vinod, Varsha Varadarajan, Victor Sollerhed, Vishal Devgire

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.7.0

+
+
+

External Artifacts

+ +

Introduced support for publishing and fetching artifacts from an external artifacts store.

+ +
    +
  • We have introduced a new Artifacts Plugin Extension for plugin authors to write plugins which support artifact stores of their choice.
    • +
  • Introduced Artifact Plugin for Docker Registry to store and fetch docker images from the docker registry.
    • +
+ +

Better encryption

+

We have moved towards using AES for encryption/decryption over DES. All DES cipher-text in cruise-config.xml will be migrated to AES cipher-text. Support for DES is retained to handle DES cipher-texts configured in config-repos. DES encryption is deprecated, check the deprecation notes for more details.

+ +

Data Sharing

+

GoCD now shares some (non-personally identifiable) information about the instance, to help improve the experience and performance. All GoCD system administrators will see a notification message about it and will have a chance to review the information sent and make a decision about it.

+ +
+ GoCD Data Sharing +
+ +

New Loading... screen

+

The GoCD server now starts up into a "Loading …" screen early on in the process. So, if you have scripts waiting on the port to be open, instead use the server health API, which will succeed with an HTTP status of 200 once the server is up. Till then, it'll fail with an HTTP status of 503.

+ +
+ Loading Screen +
+ +

API Improvements

+ + + +

Bug fixes

+ +
    +
  • 9edcd29 - Fixed issue with webhook authentication. (#4945)
    • +
  • db8652b - This fixes issue with analytics not showing up on GoCD instance running on Windows. (#4923)
    • +
  • 941d93f - Fixed an issue with Jobs being hung when agent goes to missing state. (#4823)
    • +
  • 3a1933d - Fixed infinite redirect issue for password and web based plugin. (#4853)
    • +
  • eb7c461 - Fix for Agent not honoring GO_AGENT_LOG_DIR directive in service_mode. (#4718)
    • +
  • 44264c3 - Fixed an issue with VSM pin showing incorrectly. (#3775)
    • +
  • 0d18844 - Fixed missing Stage detail page link for a failing Stage. (#4909)
    • +
+ +

Breaking changes

+
    +
  • As of release 18.2.0 the following (unversioned) APIs had been deprecated and have been removed in 18.7.0. + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • The Plugin Info API v3 deprecated in 18.3.0 has been removed in 18.7.0. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Deprecations

+
    +
  • With the introduction of AES for encryption/decryption in this release, we are deprecating support for DES. Support for DES is retained to support DES cipher-texts configured in config-repos and will be available till the last release of GoCD for the year 2018. The Encryption API is updated to return a AES cipher-text, users are encouraged to update their DES cipher-texts in config-repos using this API.
    • +
  • The Pipeline Config API v5 has been deprecated as of this release. This version of the API will be removed in a release scheduled for October 2018. Version 6 of the API is available, and users are encouraged to use it.
    • +
  • The Template Config API v3 has been deprecated as of this release. This version of the API will be removed in a release scheduled for October 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Pranav Bansod, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan, ralcini

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.6.0

+
+
+

Improvements

+ +
    +
  • 3541529 - Upgrade to TFS SDK version 14.118.0.
    • +
  • ebdfb7d - Do not log server info at shutdown.
    • +
+ +

Library upgrades

+ +

In order to move towards supporting JRE version 9 and upwards, this release upgrades several libraries used by GoCD, including spring, hibernate, mybatis. See #4785, #4749 and #4768.

+ +

Breaking changes

+ +
    +
  • APIs now respond with an HTTP status code 403(Forbidden) instead of the 401(Unauthorized) when authenticated users are not authorized to view or perform operations on a resource.
    • +
  • URLs containing any un-normalized paths (/../, ./ and /.), semicolon (; and %3B), encoded forward-slash (%2F), backslash (\, %5C), encoded percent (%25) will be rejected.
    • +
  • The pipeline config API version 3 and version 4 have been removed. Please use version 5 of the pipeline config API.
    • +
  • The elastic agent plugin extension version 1 and (a development version 2) has been removed. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features. Users using ECS plugin >= 4.0.0, docker swarm plugin >= 3.0.0, docker plugin >= 0.9.0 and kubernetes elastic agent >= 1.0.0 need not upgrade.
    • +
+ +

Bug fixes

+ +
    +
  • #4737 - Secure variables that were not masked in task plugins are now masked properly.
    • +
  • #4805 - Pipeline history page pagination was broken.
    • +
  • #4757 - Fix Mac installer to use Java 1.8 only.
    • +
  • #4751 - Fix incorrect cache key generation.
    • +
  • #4746 - Fix issue with user preferences page on Microsoft Edge browser.
    • +
  • #4338 - QuickEdit does not allow delete of only stage in pipeline.
    • +
  • #4775 - Dashboard UI rendering duplicate pipeline information.
    • +
  • 5eb1121 - Fix the roles configuration link in the admin dropdown menu.
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for July 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.5.0

+
+
+

Bug fixes

+ +
    +
  • #4724 - Fixed issue with duplicate pipeline instances showing on dashboard due to config-save operations via different methods.
    • +
  • #4727 - Fix spaces in template message in quick edit view.
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.4.0

+
+
+

+ Previously, there was a warning about not upgrading to 18.4. In 18.5, an issue around pipelines created using the pipeline config API showing twice on the dashboard was fixed. We haven't been able to replicate issue #4723 around pipelines created using JSON and YAML plugins, we suspect it might be an issue with the individual's setup. [Updated: 2018 May 11, 11:45 UTC] +

+ +

Performance fix

+ +

This release primarily addresses performance issue caused by a config save, which slows down several requests because of a long-running database query executed in order to update the dashboard.

+ +

We have performed some optimizations in order to significantly reduce the number of SQL calls executed. Read more about it at #4706 and #4705.

+ +

Improvements

+ +
    +
  • #4664 - Improved logging on GoCD server when agent registration fails.
    • +
  • #4610 - Add an origin attribute on fetch task. The origin attribute indicates where to fetch the artifact from. For all artifacts fetched from the gocd server, the value is 'gocd'
    • +
  • #4630 - Upgrade jetty to version 9.4.9.
    • +
+ +

Bug fixes

+ +
    +
  • #4675 - Server side timestamps are rendered properly when daylight saving is in effect.
    • +
  • #4691 - Allow logged in users to access PluginInfos API.
    • +
  • #4673 - Allow null environment variable value in config repo plugins.
    • +
  • #3908 - Allow admin to change selected user in the User summary page.
    • +
  • #4690 - Fixed some issues with case-insensitive renames of pipeline names.
    • +
  • #4698 - Do not truncate long pipeline name.
    • +
  • #4682 - Do not send a HTTP basic authentication challenge for API requests sent by the browser over AJAX.
    • +
+ +

Bundled plugins

+ +
    +
  • Upgraded the bundled LDAP authentication plugin to version 1.0.2. See the plugin CHANGELOG for more details.
    • +
  • Upgraded the bundled file based authentication plugin to version 1.0.2. See the plugin CHANGELOG for more details.
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for June 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated as part of 18.2.0 and will be removed in a release scheduled for June 2018. Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent plugin extension version 1 and (a development verion 2) has been deprecated. These versions will be removed in a release scheduled for June 2018. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.
    • +
+ +

Breaking changes

+ + + +

Known Issues

+ +
    +
  • There are a few known minor issues when triggering pipelines on the new dashboard: +
      +
    • #4647 - Trigger buttons do not get disabled if the pipeline was force triggered and material update is in progress
      • +
    • #4452 - Horizontal scroll appears in Trigger With Options Materials popup
      • +
    • #4481 - CCTray corner cases: NullPointerException because of a pipeline not being in the config when the dashboard looks to update itself.
      • +
    +
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.3.0

+
+
+

New Dashboard Page out of Beta

+

After we released the improved GoCD Dashboard (beta) in 18.2.0, we made several bug fixes and performance improvements based on feedback from our users. The GoCD dashboard improves performance for large GoCD instances with thousands of pipelines. In 18.3.0, we have replaced the older version of the dashboard with this improved dashboard which will be available as the default option to all GoCD users.

+ +
+ new dashboard page +
+ +

Enhancements to GoCD's Plugin Architecture

+

We have been working on a few improvements to our plugin architecture.

+ +

Support for adding plugin alerts to GoCD's Errors and Warnings section: +GoCD provides an ability for plugins to add Error and Warning messages. These messages will show up along with the GoCD's own Errors and Warnings. Plugins now have an ability to notify users with any plugin error or warning messages which shows up in GoCD.

+ +
+ Errors and Warnings from Plugins +
+ +

Multiple Extension Support for Plugins: +Plugins can now implement multiple extensions. This will allow plugin developers to create a single plugin to support multiple extensions which complement each other. E.g This would allow one to write a new GitHub PR workflow plugin with both SCM and Notification extensions.

+ +

The plugin info API v4 has been introduced to represent plugins which implement multiple extensions. The two changes are:

+ +
    +
  • "type" is no longer at plugin level. It's at an extension level.
    • +
  • "extension_info" was an attribute. It's now a list called "extensions".
    • +
+ +

Notification Extension V3: +Introduced Version 3 of Notification Extension. This version adds a new message to notify agent state changes.

+ +

Analytics Extension Point: +There is a new analytics extension point which allows analytics to be embedded into GoCD. We are continuing to work on it and you'll hear more about it soon.

+ +

Docker Images

+

A new Docker image GoCD Agent is available for Debian 9.

+ +

Improvements

+
    +
  • #4644 - Environments page no longer lists the pipeline instances, this page is only for listing the available environments and editing them.
    • +
  • #4617 - Ability to turn-off logging of JVM-args and Environment variables to STDERR on GoCD Agent and Server startup.
    • +
  • #4607 - Remove flash filter from agent remoting endpoint
    • +
  • #4278 - Change in Build and Test Artifact XML representation
    • +
  • #4559 - Upgraded Objenesis library to fix performance issues around object cloning.
    • +
  • #4557 - Plugin settings api improvements
    • +
  • #4435 - Add the blacklist textarea to other scm materials in the pipeline creation wizard
    • +
  • #4432 - Setting up one listener per notification plugin to avoid one plugin interfering with others
    • +
  • #4521 - Update config-repo yaml plugin to 0.6.2
    • +
+ +

Bug fixes

+
    +
  • #4656 - Serialise lastBuildTime for CCTray in UTC with timezone
    • +
  • #4466 - Make JSON output invalid on error
    • +
  • #4569 - Update mail sender with mailhost config every time while performing backup.
    • +
  • #4474 - Fixed issue with SPAs popping up a login dialog after session timeout
    • +
  • #4542 - Fix plugin logging concurrency issue
    • +
  • #4496 - Show only pipelines that the user has admin permissions to extract a template.
    • +
  • #4501 - Ensure cancelled stage has lastTransitionedTime.
    • +
+ +

Deprecations

+
    +
  • As of release 18.2.0 the following (unversioned) APIs have been deprecated and will be removed in a release scheduled for June 2018: + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated as part of 18.2.0 and will be removed in a release scheduled for June 2018. Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent plugin extension version 1 and (a development verion 2) has been deprecated. These versions will be removed in a release scheduled for June 2018. Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • +

    The Plugin Info API v3 has been deprecated as part of 18.3.0. This version of the API will be removed in a release scheduled for July 2018. Version 4 of the API is available, and users are encouraged to use it.

    +
    • +
  • The Agent Docker Image for Debian 7 is deprecated as part of 18.3.0 and will be removed in a release scheduled for May 2018. Users should upgrade to a newer version of the Debian image.
    • +
+ +

Breaking changes

+ + +

Known Issues

+
    +
  • There are a few known minor issues when triggering pipelines on the new dashboard: +
      +
    • #4647 - Trigger buttons do not get disabled if the pipeline was force triggered and material update is in progress
      • +
    • #4452 - Horizontal scroll appears in Trigger With Options Materials popup
      • +
    • #4481 - CCTray corner cases: NullPointerException because of a pipeline not being in the config when the dashboard looks to update itself.
      • +
    +
    • +
  • +

    There is a known issue with API authentication:

    + +

    API requests that wait for a authentication challenge before sending the credentials in the Authorization header fail with 401. +This is due to a bug introduced in the pull request #4585 - 'SPAs - redirect to login page if unauthorized'. +The bug essentially responded with a 401 http response before the WWW-Authenticate header could be added. More details can be found in the github issue #4682.

    +
    • +
+ +

Contributors

+

Aditya Sood, Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Christoph Burgmer, Ganesh S Patil, Isabelle Carter, John Eismeier, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rafael Nunes, Rajiesh N, Senthil R, Steven Streisguth, Ted Timmons, Tomasz Sętkowski, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +

Please report any issues that you observe on GitHub issues.

+ +
+
+

18.2.0

+
+
+

New Dashboard Page (Beta)

+ +
+ new dashboard page + New Dashboard Page +
+ +

This release of GoCD ships with a 'preview' version of the new dashboard page (can be accessed using '/go/dashboard'). This improves performance for large GoCD instances with thousands of pipelines. It does so by:

+ +
    +
  • keeping track of the state of the dashboard in memory (instead of being pulled from the DB).
    • +
  • rendering the response as a JSON (instead of HTML). This improves the rendering time by several hundred times on the server.
    • +
  • a javascript based frontend that is several thousand times faster on large instances, reducing the CPU usage of your browser. Your laptop battery will thank you. :)
    • +
  • reduces the polling rate when the dashboard is shown in a browser tab that is hidden.
    • +
+ +
+

Please report any issues that you observe on GitHub issues. This new dashboard will replace the existing dashboard in one of the upcoming releases of GoCD.

+
+ +

This feature can be turned off by executing:

+ +
curl https://your-go-server/go/api/admin/feature_toggles/quicker_dashboard_key \
+  -d toggle_value=off \
+  -H 'Confirm:true' \
+  -u username:password
+
+ +

Elastic Agent Status Report

+ +
+ elastic agent status report + Elastic Agent Status Report +
+ +

To make it easier to see information about your elastic agent and check logs in case of issues, elastic agent plugins can now provide an elastic agent status report. This report is available from the agents page, and from the job detail page. Docker, Docker Swarm, and Amazon ECS plugins implement this status report feature.

+ +

Elastic Agent Plugin Status Report

+ +
+ elastic agent plugin status report + Elastic Agent Plugin Status Report +
+ +

To make it easier to see information about elastic agent cluster, elastic agent plugins can provide a report about all running agents and the state of the cluster. This report is available from the plugins page. Docker, Docker Swarm, and Amazon ECS plugins implement this status report feature.

+ +

API Improvements

+ +
    +
  • +

    612c66a - Introduction of pipeline pause api and unpause api. (#4076).

    + +

    The old pause/unpause APIs have been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    b52aff7 - Introduction of pipeline unlock API. (#4237).

    + +

    The old pipeline unlock API has been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    666b206 - Introduction of pipeline schedule API. (#4319).

    + +

    The old pipeline schedule API has been deprecated and users should upgrade to the new API.

    +
    • +
  • +

    6dfa18f - Introduction of server health messages API. (#4256).

    + +

    This endpoint will render the warnings and errors that were earlier visible only when clicking on the "errors and warnings" modal on the GoCD server

    +
    • +
  • +

    0353bb6 - Introduction of Template Authorization API. (#3081).

    +
    • +
  • +

    9c4829e - Support gitlab@ urls for gitlab webhooks. (#4211)

    + +

    Many GitLab installations use gitlab@ as a git user. This was once a default user for GitLab installs. Due to this the urls for ssh connections from gitlab can include this user.

    +
    • +
+ +

Improvements

+ +
    +
  • Introduce environment variables GO_MATERIAL_HAS_CHANGED and GO_MATERIAL_${material name or dest}_HAS_CHANGED to indicate if materials have changed from the previous pipeline run, and if materials have changed, which materials have changed. Read more about these variables in the help documentation.
    • +
+ +

Docker images

+ +

We have introduced the GoCD Agent Docker in Docker image. This can be used to run the docker related tasks such as building a docker image, pushing to a registry etc. Advanced use-cases include containerizing the application and running tests using DInD.

+ +

Read more about changes with docker images for the server docker image and agent docker image.

+ +

Bug fixes

+ +
    +
  • +

    With the introduction of the server health messages API, we can now show server health messages on some of the pages introduced in the last several releases, viz. roles, authorization configuration, agents, elastic profiles, plugin settings.

    +
    • +
  • +

    #3899 - Fixed an infinite redirect issue when logging in using web based authentication plugins

    +
    • +
  • +

    #3926 - Handle console logs better with utf-8 encoding

    +
    • +
  • +

    157f12d - Enforce http(s) URL scheme for tracking tools. (#4356)

    + +

    This will add an http:// prefix to tracking tool links that do not start with http:// or https://.

    +
    • +
  • +

    The plugin settings request is supported for the SCM and Package repository extensions on the plugins SPA. The plugin settings that can be configured for scm and package repo plugins are made use of only on the server side.

    +
    • +
+ +

Deprecations

+ +
    +
  • As of release 18.2 the following (unversioned) APIs have been deprecated and will be removed in 18.5 (scheduled to be released in May 2018): + + +

    These APIs have been replaced with a versioned API and users are encouraged to use these instead.

    +
    • +
  • +

    The pipeline config API version 3 and version 4 have been deprecated and will be removed in 18.5 (scheduled to be released in May 2018). Version 5 of the pipeline config API has been introduced to add the new pipeline unlock behavior attribute (#3943).

    +
    • +
  • +

    The elastic agent api version 1 and (a development verion 2) has been deprecated. These versions will be removed in 18.5 (scheduled to be released in May 2018). Plugin developers should use version 3 of the elastic agent plugin api to allow adding support for agent status report and plugin status report. The docker, docker swarm, and ecs plugins have been migrated to the new versions, and users should upgrade their plugins to the latest version to see these new features.

    +
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.3.0 (scheduled to be released in March 2018).
    • +
+ +

Breaking changes

+ +
    +
  • Version 1 of the users api has been removed. Version 2 of the API is available, and users are encouraged to use it.
    • +
+ +

Known issues

+ +
    +
  • There are a few known issues when triggering pipelines using the trigger with options feature on the new dashboard: +
      +
    • #4488 - If for a material no revision selected on trigger with options, schedules with latest revision
      • +
    • #4489 - If invalid revision specified do not trigger pipeline
      • +
    • #4448 - Pipeline with lock behavior specified continues to be locked after run completion under certain conditions
      • +
    +
    • +
+ +

Contributors

+ +

Akshay Dewan, Akshay Mayekar, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Charles Bryant, Christian Lövsund, Don Stewart, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Paul Thomas, Rajiesh N, Senthil R, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

18.1.0

+
+
+

Bug Fixes

+
    +
  • f9ad399 - Validate roles assigned to stage authorization on template update through API. (#4185) #4176
    • +
  • 63d7d0f - Test artifacts configured using config-repo is uploaded to GoCD server's build artifacts' default location. (#4083) #4071
    • +
  • 1442a09 - Get Pipeline Config API failed to find pipeline for remote configured pipelines. (#4010) #4008
    • +
  • addf343 - Fix path of logback-include.xml. (#4145)
    • +
  • d409d23 - Fix whitelist in configrepo hg material. (#4191)
    • +
  • 8971a71 - Do not allow agent to register with duplicate elastic agent id. (#4133)
    • +
+ +

Docker Images

+
    +
  • Published an updated GoCD Server and Agent docker image for the latest version of Alpine (3.7)
    • +
+ +

Breaking Changes

+ + +

Deprecations

+
    +
  • As of release 17.11, version 1 of the users API is deprecated. This version of the API will be removed in 18.2.0 release (scheduled to be released in February 2018). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.2 (scheduled to be released in February 2018).
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.12.0

+
+
+

UX Changes

+
    +
  • +

    0e92610 - Newer plugins page. (#4030).

    + +

    As a part of an ongoing UI/UX refresh, we have introduced the new plugins page:

    +
    • +
+ +
+ Plugins SPA +
+ +

Other Improvements

+
    +
  • +

    0ee52b3 - Disallow an authenticated user from re-authentication. (#3940)

    + +

    With this change, an authenticated user is re-directed to home page on trying to access the login page.

    +
    • +
  • +

    6fda2f5 - Add new unlock behavior. (#3943) #106

    + +

    As a part of this change, two types of locking behavior are introduced:

    + +
      +
    • +

      Run single instance of pipeline at a time ("Lock behavior: Unlock when finished")

      +
      • +
    • +

      Run single instance of pipeline and lock on failure ("Lock behavior: Lock on failure")

      +
      • +
    + +

    More information can be found in the docs.

    +
    • +
  • +

    979fa50 - Addition of pipeline count information to about page. (#3960)

    +
    • +
+ +

Bug Fixes

+
    +
  • ab1ccf8 - Fix config file validation to not use file system to validate paths. This caused issues in certain cases where the server working directories were using symlinks. (#4026) #3984
    • +
  • 6660a1b - Show 'console log not available' error in build details page's console tab when console.log file is not available. (#3998) #3773 #3650
    • +
  • e48d958 - Fixes console.log file not being available at server if websocket connection is closed while waiting for logs. (#3999) #3986
    • +
  • ee992e6 - Fixes issue in agent zip installers in which agents fail to register if their log directories' path have spaces in them. (#3976) #3966
    • +
  • e6c9b3a - Fixes issue with stale cache being used in CCtray which caused users associated with plugin-roles to not see pipelines which they were authorized to see otherwise. (#3955) #3954
    • +
  • 449cbc3 - Allows overriding default Go server ports when using windows service. (#4038) #3982
    • +
+ +

Security Fixes

+
    +
  • +

    488712d - Token based approach for agent registration. (#4014)

    + +
      +
    • Adds a new endpoint to get token from server in exchange of agent uuid. The token for a given agent is issued for unknown agents only - already registered or pending agents cannot request for a token.
      • +
    • Agent requests for a token before registration if required. This token is stored on agent's disk and reused for registration calls.
      • +
    + +

    Note: As a result of this fix, Go-lang agents need to be updated to work with GoCD server versions 17.12 or higher, else the agent's registration would fail. +Golang agent users can follow up with the author on this issue.

    +
    • +
+ +

API Changes

+ + +

Docker Images

+
    +
  • Addition of ability to run custom scripts while starting up the gocd-server or gocd-agent using the official GoCD docker images. #46
    • +
+ +

Breaking Changes

+
    +
  • +

    cdf6722 - Remove code related to starting vncserver. (#4028) #4005

    + +

    Alternatives to using the VNC flag are mentioned in this comment.

    +
    • +
+ +

Deprecations

+
    +
  • As of release 17.11, version 1 of the users API is deprecated. This version of the API will be removed in 18.1.0 release (scheduled to be released in January 2018). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.5, authentication plugin endpoints have been deprecated. Support for these plugins will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. The following plugins are affected by this deprecation: + +
    • +
  • Plugins upload form has been removed from the new plugins page. It is still available in the old plugins page, which will be removed in release 18.2 (scheduled to be released in February 2018).
    • +
  • As of release 17.9, version 2 of the plugin info API is deprecated. This version of the API will be removed in 18.1.0 release (scheduled to be released in January 2018). Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aditya Sood, Akshay Dewan, Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, EugenMayer, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Senthil R, Szymon Chojnacki, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.11.0

+
+
+

UX Changes

+
    +
  • +

    67f1605 - Find Value Stream Map (VSM) more easily and show pipeline run duration in VSM. (#3705) (#3858)

    + +

    Pipeline instances have an explicit link to VSM across the application for better discoverability.

    + +
    + Explicit vsm link in dashboard +
    + +

    Pipeline run duration shown in VSM:

    +
    + Pipeline run duration in VSM +
    +
    • +
+

Improvements

+ +
    +
  • a8d09f3 - Added support for parameters and template references in config repo pipelines. (#3851) (#3849)
    • +
  • 36b675e - Added support for bitbucket webhook. (#3862)
    • +
  • 6320d55 - Added support for gitlab webhook. (#3862)
    • +
  • 2cb4c00 - GoCD Server session timeout has been made configurable. (#3856) (docs)
    • +
  • e51f3b6 - GoCD Agent supports configuring proxies. (#995)
    • +
+ +

Breaking Changes

+
    +
  • +

    f501efc - Move over to logback from log4j for logging. (#3831)

    + +
      +
    • Switching to logback solves a number of logging related issues such as #3588, #3557 and #3403
      • +
    • The users should now configure logging using corresponding logback.xml instead of log4j.properties for both server and agents (docs).
      • +
    • This has been marked as a breaking change since GoCD would no longer honour log4j.properties file. Users managing log4j.properties file externally would have to update their scripts to use the logback.xml instead.
      • +
    +
    • +
  • +

    Support for phusion based docker server and agent images have been removed this release. We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04

    +
    • +
+ +

Performance Fixes

+
    +
  • eb7305e - Fixes memory leak issue in agent-bootstrapper/launcher caused by server upgrades. (#3792)
    • +
+ +

Bug Fixes

+
    +
  • cef6649 - Fixes a race condition during Job reschedule. (#3891)
    • +
  • a1f9945 - Improves checksums for agent jar(s) download. (#3884)
    • +
  • 4db7e52 - Does not show the settings icon for config repo pipelines on VSM. (#3892) (#3881)
    • +
  • 686c76d - Fixes issue with users authenticated using WebBasedAuthentication not assigned the right permissions. (#3878)
    • +
+ +

API Changes

+ + +

Docker Images

+
    +
  • We have made a few changes to the GoCD Server (Changelog) and the GoCD Agent (Changelog) Docker images.
    • +
+ +

Deprecations

+ + +

Note

+
    +
  • With release 17.5.0 support for in-built password file and LDAP/AD authentication had been deprecated. In this release support for this has been removed in favour of the bundled LDAP and Password File plugins respectively.
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Drew J. Sonne, Emily Luke, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Mikhail Advani, Naveen Bhaskar, Rajiesh N, Senthil R, stayclassychicago, Suzie Prince, Tomasz Setkowski, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.10.0

+
+
+

Important: After the 17.9 release, we made an announcement asking users to hold off upgrading their GoCD instance. We found an issue (#3834) affecting a small set of users. This release provides a fix for the same.

+ +

Critical Bug Fixes

+
    +
  • 05598d8 - Unable to start the server after 17.9.0 upgrade. (#3834)
    • +
+ +

Other Changes

+
    +
  • 176ebc2 - Fix for no plugins visible after 17.9.0 upgrade. (#3829)
    • +
+ +

Docker Images

+ + +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Roman Gorodeckij, Senthil R, Suzie Prince, Varsha Varadarajan

+ +

Note

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ + +
+
+

17.9.0

+
+
+
Sep 11 13:00 UTC 2017: We are investigating an issue (#3834) with upgrades affecting a small number of users. Please hold off on upgrading to 17.9.0 until further notice.
+ +

Improvements

+
    +
  • +

    928c585 - Grouping elastic profile by plugin ID. (#3772)

    + +

    We have created an organized view of the elastic agent profiles. Now, you can view them by the type of elastic agent plugin (Docker Swarm, OpenStack, ECS etc.), making it easier to find a particular profile.

    + +
    + Group elastic profile by plugin id +
    +
    • +
  • +

    1c1f2fe - Administrators can choose to edit a Pipeline with one-click from the Value Stream Map.

    + +
    + Edit pipeline from VSM +
    +
    • +
  • +

    ca7c3fa - Addition of a request processor to allow plugin authors to query information from the GoCD server. (#3401)

    +
    • +
+ +

API Changes

+ + +

Bug Fixes

+ +
    +
  • +

    4c9e3c9 - Removed memory leaks from agent bootstrapper.

    + +

    GoCD agents are designed to automatically upgrade themselves when the GoCD server is upgraded. This requires the currently running agent to release all resources before exiting and handing over control to a newer version of the agent process. There were some file system resource and memory leaks that have been identified which affect versions of go-agent bootstrapper between 17.4 and 17.8. We recommend that users either upgrade their gocd server and agent versions to the latest version, or restart the agent process to release any memory and filesystem resources that may be locked by the agent process.

    +
    • +
  • e538ba0 - Check if agent is disabled before job assignment.
    • +
  • d47180f - Addition of a few more fields to materials form which is used in creation of pipelines.
    • +
  • 8f6cc6c - Send request headers from server to plugins.
    • +
  • 0eab696 - Stage and job related warnings should not be logged for a rerun stage/job. (#3753)
    • +
  • 8f66499 - Fixes select all bug on admin edit in environment page. (#3737)
    • +
  • 793d198 - Redirect authenticated user to home page on re-authentication.
    • +
+ +

Docker Images

+
    +
  • GoCD images make logs available to docker by writing them to STDOUT. Users can access the logs anytime by executing   docker logs   in both server and agent containers.
    • +
  • We've launched an updated GoCD Agent docker image for the latest version of Alpine (3.6)
    • +
+ +

Breaking Changes

+

If you are using the commercial Amazon ECS Elastic Agent Plugin, upgrading to GoCD 17.9.0 would require a plugin upgrade to V2.0.0.

+ +

Deprecations

+
    +
  • As of release 17.9, version 2 of the plugin info API is deprecated. This version of the API will be removed in 17.12.0 release (scheduled to be released in December 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.5, authentication plugin endpoints have been deprecated. Support for this plugin will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. +
    Authentication plugins
    + +
    • +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.10 release (scheduled to be released in October 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other actions necessary.

    +
    • +
  • As of 17.8, the phusion based docker server and agent images are deprecated in favour of the new docker server and agent images. Support for the phusion images will be removed in 17.11.0 (scheduled to be released in November 2017). We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Other Changes

+
    +
  • dc39953 - Config repo change attribute "plugin" to "pluginId". (#3672)
    • +
  • 3c9a8f1 - Addition of a toggle to make pipeline quick edit page as a default page. (#3722)
    • +
  • 19210e4 - Always open console tab when job name is clicked. (#3742)
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Pedro Carriço, Rajiesh N, Senthil R, Stephen Murby, Suzie Prince, Tim Brown, Varsha Varadarajan

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.8.0

+
+
+

Pipeline as Code

+ +

With this release, GoCD supports Pipeline as code, out of the box. We've bundled the JSON config repo plugin and the YAML config repo plugin with the GoCD server. +A shout out to our core contributor Tomasz Sętkowski for maintaining these plugins.

+ +

Amazon ECS Elastic Agent Plugin

+ +

Thoughtworks now offers a new commercial plugin which allows you to run elastic agents on Amazon ECS. The plugin takes care of spinning up and shutting down EC2 instances based on the need of your deployment pipeline. For more information about this, click here.

+ +

Improvements

+ +
    +
  • 1ccb029 - Ensure order of auth_config is used to authenticate users. (#3608)
    • +
  • 36d546e - Removed support for Team Foundation Server 2010. Users can continue to use GoCD with TFS 2012, 2013, 2015 and Visual Studio Team Services.
    • +
  • d7c4d16 - Display pause text in pipeline history. (#2784)
    • +
  • 52ac924 - Save agent hostname and ip address as part of build history. This information will be displayed on the job details page for all kinds of agents. (#3368)
    • +
+ +

Docker Images

+ +
    +
  • Some improvements have been made to reduce the size of the docker GoCD server image. Please check the changelog here.
    • +
  • Some improvements have been made to create slimmer docker GoCD agent images. Please check the changelog here. +We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other action necessary.

    +
    • +
  • As of 17.5, authentication plugin endpoints have been deprecated. Support for this plugin will be removed in 18.1 (scheduled to be released in January 2018). Plugin developers are encouraged to migrate their plugins to use the Authorization Plugins that were introduced. +
    Authentication plugins
    + +
    • +
  • As of 17.8, the phusion based docker server and agent images are deprecated in favour of the new docker server and agent images. Support for the phusion images will be removed in 17.11.0. + We provide support for the docker images for GoCD agents across the following operating systems - Alpine 3.5, CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
+ +

Contributors

+ +

Ankit Srivastava, Ankur K, Aravind SV, Bhupendrakumar Piprava, Emily Luke, Huimin Li, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kyle Olivo, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh N, Senthil R, Suzie Prince, Tomasz Sętkowski, Varsha Varadarajan, Victor Nascimento

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.7.0

+
+
+

Security Fixes

+ +

Important: This release comes on the back of 17.6.0 as we have identified a critical security vulnerability with 17.5.0 and 17.6.0. If you are on 17.5.0 or 17.6.0, please upgrade immediately to this version to keep your GoCD server secure. We want to give sometime for users to upgrade before disclosing the details of the vulnerability.

+ + +
+
+

17.6.0

+
+
+

Important

+ +

There has been a critical security vulnerability identified with this release, fixes for the same have been provided in 17.7.0. If you are on 17.6.0, please upgrade immediately to 17.7.0 to keep your GoCD sever and agent secure.

+ +

Security Fixes

+ +

This release has critical security fixes to prevent CSRF, XSS and Session hijacking exploits. We highly recommend users to upgrade to keep your GoCD server and agent secure. +Thanks 4cad for reporting these issues.

+ +

Improvements

+ +
    +
  • +

    42c681d - Added option to skip agent startup on windows. (#3577)

    + +

    This adds a /START_AGENT=NO to prevent the agent service from starting up when performing a headless installation on windows. See the documentation for more details.

    +
    • +
  • +

    2c95a10 - Improve timestamp rendering on some pages. (#3574)

    + +

    This improves the timestamp rendering on the job details, stage details and pipeline compare pages. You will now see timestamps in your local timezone.

    + +
    + Improve timestamp rendering +
    + +
    + Improve timestamp rendering +
    +
    • +
  • +

    9450dba - Add a "Rerun Failed" button to rerun failed jobs. (#3570)

    + +
    + Rerun failed jobs +
    +
    • +
  • +

    The in-built password file authentication plugin now supports bcrypt, which is a stronger password hashing function. GoCD server administrators should migrate SHA1 passwords to use bcrypt instead.

    +
    • +
+ +

API Enhancements

+ +
    +
  • Introduced a GitHub webhook API to accept push events on a GitHub repository or repositories in a GitHub organization.
    • +
+ +

Bug Fixes

+ +
    +
  • +

    88f1678 - Disable trigger with options button for view user in the environments page. (#3602)

    +
    • +
  • +

    dba8212 - Javascript error when saving user preferences. (#3576)

    +
    • +
  • +

    30615dc - Reduce the amount of plugins that an agent downloads and initializes. (#3584)

    + +

    This should reduce the amount of data an agent downloads when a plugin is installed, or the server is upgraded. This will also help reduce the amount of memory used by the GoCD agent process.

    +
    • +
+ +

Breaking Changes

+ +
    +
  • +

    8dfb1a9 - Removed Environments Config API v1. (#3606)

    + +

    Version 1 of the Environment Config API was deprecated in 17.3. Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    As of 17.5, support for in-built password file and LDAP/AD authentication have been deprecated. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017). Existing configuration will be automatically migrated to use the new in-built password file and LDAP/AD authentication plugins. No other action necessary.

    +
    • +
  • +

    The Authorization Plugin endpoints were introduced as an extension to the existing Authentication Plugin endpoints, with this Authentication Plugin endpoint were deprecated as of 17.5.0. Support for this plugin would be removed in 18.1 (scheduled to be release in January 2018). Plugin developers are encouraged to migrate their plugins to use the new Authorization Plugins.

    +
    Authentication plugins
    + +
    • +
+ +

Contributors

+ +

Ankit Srivastava, Aravind SV, Bhupendrakumar Piprava, Drew Sonne, Jyoti Singh, Kerry Wilson, Ketan Padegaonkar, Lubaina R, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh N, Sean Escriva, Stephen Murby, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.5.0

+
+
+

Important

+ +

There has been a critical security vulnerability identified with this release, fixes for the same have been provided in 17.7.0. If you are on 17.5.0, please upgrade immediately to 17.7.0 to keep your GoCD sever and agent secure.

+ +

Authorization Plugin

+ +

Authorization Plugin extension was released as beta in GoCD 17.2.0, over the last couple of releases there has been more work done around fine tuning the endpoint. With this release we are taking the Authorization Plugin endpoint out of beta.

+ +

Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading GoCD. Refer to the Authorization Plugin Endpoint documentation for the latest changes.

+ +

The built-in LDAP and password file based authentication mechanisms have been deprecated and disabled in favor of separate plugins which implement the new Authorization Plugin extensions. The new plugins provide more functionality, with the benefit of allowing users to customize the behavior of these plugins. These plugins are bundled with the GoCD server, so no action will be required from users. Existing passwordFile and ldap configuration would be migrated to make use of these plugins.

+ +
    +
  • +

    LDAP/AD authentication plugin

    + +

    The bundled LDAP/AD authentication plugin will now allow users to connect to and authenticate with multiple LDAP/AD servers in their organizations. Early adopters of this plugin using the experimental build will have to make changes to their config. Refer to the plugin changelog to see the changes between experimental release to latest stable release.

    +
    • +
  • +

    Password File Authentication Plugin

    + +

    The bundled Password File Authentication Plugin currently supports only SHA1 hashed passwords, but support for other hashing functions is on its way.

    +
    • +
+ +

There are 2 new sets of pages that allows configuring the authorization plugins and mapping of GoCD roles to users.

+ +
+ GoCD Security Menu +
+ +
+ Example LDAP server configuration +
Example LDAP connection configuration
+
+ +
+ Example GoCD role to LDAP group mapping +
Example GoCD role to LDAP group mapping
+
+ +

API Enhancements

+ + + +

Bug Fixes

+ +
    +
  • +

    9cec83f - Stop very large file systems (EFS) from being identified as having no space. (#3426)

    + +

    Large filesystems like EFS, have an amount of storage that exceeds what can be addressed with a java long type (263-1). Any storage space greater than 263-1, will be shown to be 263-1.

    +
    • +
  • +

    2b06534 - Pipeline not getting unlocked upon a successful run. (#3497)

    + +

    Fixed a issue of pipelines not getting unlocked even upon a successful run of the last stage during a race condition.

    +
    • +
  • +

    26bfeab - Avoid catastrophic regex backtracking during config save. (#3551)

    + +

    Fixed an issue to avoid catastrophic regex backtracking during xsd validation of custom task command.

    +
    • +
  • +

    2a21e7c - Using UTF-8 to read console to fix encoding issue. (#3486)

    +
    • +
  • +

    e89fdb6 - CCTray permission bug fix. (#3516)

    + +

    Allow users to see all pipelines in CCTray when no global superadmins are setup to make the behavior consistent with dashboard.

    +
    • +
+ +

Breaking Changes

+ +
    +
  • +

    bd64d11 - Removed Templates API v2. (#3441)

    + +

    Version 2 of the Templates API was deprecated in 17.1. Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated. Please note the timeframe of when they will be removed.

+ +
    +
  • +

    Support for in-built password file and LDAP/AD authentication have been deprecated as of this release. Support for these authentication mechanisms would be removed in 17.9 release (scheduled to be released in September 2017).

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API was deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    The Authorization Plugin endpoints were introduced as an extension to the existing Authentication Plugin endpoints, with this we are deprecating the Authentication Plugin endpoint. Support for this plugin would be removed in 18.1 (scheduled to be release in January 2018). Plugin developers are encouraged to migrate their plugins to use the new Authorization Plugins.

    +
    Authentication plugins
    + +
    • +
+ +

Contributors

+ +

Ankit Srivastava, Aravind SV, Badri J, Bhupendrakumar Piprava, Chris Northwood, David Rice, Emily Luke, Huimin Li, Isabelle Carter, Jen Marley, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Kyle Olivo, Louda Peña, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Rajiesh N, Suzie Prince, Varsha Varadarajan

+ + + +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.4.0

+
+
+

UI Enhancements

+ +
    +
  • d6d59fb - Enhanced console log view with an option to expand/collapse outputs of comamnds. (#3199) +
    + Foldable Console Logs +
    +
    • +
  • +

    a4d669c - Full screen mode for console logs. (#3293)

    + +
    + Full screen mode +
    +
    • +
  • +

    8bcc3c7 - Add toggles to timestamps. (#3199)

    + +
    + Timestamp toggle +
    +
    • +
  • +

    f4a3b07 - Job run history dropdown. (#3299)

    + +
    + Job Run History dropdown +
    +
    • +
  • +

    87b223c - Errors/warnings box in the header. (#3378)

    + +
    + Errors/warnings box +
    +
    • +
  • +

    b9e1c20 - Colored border to bottom of job details header. (#3408)

    + +
    + Job Deail header border +
    +
    • +
+ +

Authorization Plugin (Beta)

+ +

There has been more work done around fine tuning the Authorization Plugin endpoints, as part of this some of the plugin API calls have changed. Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading Go. Refer Authorization Plugin Endpoint documentation for the latest changes.

+ +
    +
  • eddecb7 - Verify Connection API response has status, message and errors. (#3395)
    • +
+ +

Performance Improvements

+ +
    +
  • 11f19db - Moving pipeline state to a separate table which for now contains locked information about the pipeline. Read locks is held only if we are loading the state from db. (#3204)
    • +
+ +

Other Improvements

+ +
    +
  • 0ac7678 - Displaying pipeline schedule time as localtime on dashboard, environments page and pipeline-history page. Users can hover over it to see timezone information. (#3417)
    • +
  • d13f81a - Switch agent-bootstrapper to use the new logging mechanism. The bootstrapper now has its own agent-bootstrapper-log4j.properties file under the config directory. (#3267)
    • +
  • 567820c - Switch agent-launcher to use the new logging mechanism. The launcher now has its own agent-launcher-log4j.properties file under the config directory.
    • +
  • b1af25f - Display plugin name instead of plugin id in the dropdown in the elastic agent profiles page. (#3324)
    • +
+ +

Bug Fixes

+ +
    +
  • ba510ad - Server now checks if the elastic agent is brought up by the same plugin as was expected by the scheduled elastic job during assignment. (#3418)
    • +
  • b0f4359 - Handle pluggable task view when task plugin is missing. (#3320)
    • +
  • 404002e - Render the elastic agent icon only if the plugin info exists for the elastic agent. (#3314)
    • +
+ +

Security Fixes

+ +
    +
  • 51de8bc - Encrypting secure variables for Elastic Agent plugin settings. (#3356)
    • +
+ +

Breaking Changes

+ +
    +
  • #3267 - On GoCD agents installed on windows or if using the zip installers, logs will now be written to logs directory instead of the working directory. This would be a breaking change only if there are custom scripts relying on the logs location.
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • +

    As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.5 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API was deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Docker Images and AMIs

+ +
    +
  • The GoCD server docker image is now alpine based with support for volume mounts. +
      +
    • To find out what changed in the docker server image, please refer to the changelog.
      • +
    +
    • +
  • You can download the docker images for GoCD agents across the following operating systems - CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04 +
      +
    • To find out what changed in the docker agent images, please refer to the changelog.
      • +
    +
    • +
  • We have an Amazon Linux based AMI for the GoCD Server making it very simple to launch GoCD server on your AWS EC2 instance.
    • +
  • We have an Amazon Linux based AMI for a demo GoCD Server and Agent making it very simple to get started with GoCD on your AWS EC2 instance.
    • +
+ +

Feedback is appreciated. Please log your feedback or issues on github for the following -

+ + + +

Contributors

+ +

Ankit Srivastava, Aravind SV, Badri Janakiraman, Bhupendrakumar Piprava, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kiera Radman, Lubaina R, Mahesh Panchaksharaiah, Markandan R, Marques Lee, Rajiesh N, Suzie Prince, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.3.0

+
+
+

UI Enhancements

+ +
    +
  • 320f223 - Enhanched job/stage status accessibility with addition of symbols to signify stage and job statuses. (#3233) +
    + Stage and Task Symbols +
    +
    • +
  • cfc778e - Build status indicator moved from build summary to breadcrumb toolbar. (#3270) +
    + Build Status +
    +
    • +
  • 5478a54 - Agents page improvement for better identification of elastic agents by addition of icon related to the type of agent in use. (#3276) +
    + Elastic Agent Icon +
    +
    • +
+ +

API Enhancements

+ +

6986dcc - Added v2 of Environment Config API with support to PATCH environment-variables. (#3080)

+ +

Authorization Plugin (Beta)

+ +

There has been more work done around fine tuning the Authorization Plugin endpoints, as part of this some of the plugin API calls have changed. Action required: Early adopters of this extension will have to update their plugins to handle the updated API calls before upgrading Go. Refer Authorization Plugin Endpoint documentation for the latest changes.

+ +

Other Improvements

+ +
    +
  • 262c107 - Pipeline Quick Edit, disable edit until save completes. (#3266)
    • +
+ +

Bug Fixes

+ +
    +
  • 8224568 - This fixes 17.2.0 upgrade failures in cases where cruise_config xml had encrypted values with spaces. (#3244)
    • +
  • 4db0550 - Agents page retain sort order across page refresh. (#3226)
    • +
  • 73e0292 - Elastic Agents, fixed reduntant agent creation calls to the plugin. (#3193)
    • +
  • 5d75f45 - Agents page memory leak fix. (#3217)
    • +
+ +

Breaking Changes

+ +
    +
  • On GoCD servers installed on windows or if using the zip installers, logs will now be written to logs directory instead of the working directory. This would be a breaking change only if there are custom scripts relying on the logs location.
    • +
  • The gocd/gocd-server docker image now uses alpine as the base image.
    • +
  • The gocd/gocd-server docker image no longer recognizes the latest tag. Please use docker pull gocd/gocd-server:v17.3.0 instead.
    • +
  • The gocd/gocd-agent docker image no longer exists. We have a variety of agent images for different distributions.
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • +

    As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    As of release 17.3, version 1 of the Environment Config API is deprecated. This version of the API will be removed in 17.6 release (scheduled to be released in June 2017). Version 2 of the API is available, and users are encouraged to use it.

    +
    • +
+ +

Docker Images and AMIs

+ +
    +
  • The GoCD server docker image is now alpine based with support for volume mounts, with this going forward there will be no more support for phusion based images.
    • +
  • You can download the docker images for GoCD agents across the following operating systems - CentOS 6 & 7 , Debian 7 & 8, Ubuntu 12.04, 14.04 & 16.04
    • +
  • We have also introduced an Amazon Linux based AMI for the GoCD Server making it very simple to launch GoCD server on your AWS EC2 instance.
    • +
+ +

Feedback is appreciated. Please log your feedback or issues on github for the following -

+ + + +

Contributors

+ +

Ankit Srivastava, Aravind SV, Barrow KwanBhupendrakumar Piprava, Etienne Dysli Metref, Ganesh S Patil, Isabelle Carter, Junaid Shah, Jyoti Singh, Karel Bemelmans, Ketan Padegaonkar, Kiera Radman, Kyle Olivo, Lubaina R, Mahesh Panchaksharaiah, Marques Lee, Naveen Bhaskar, Rajiesh Narayanan, Varsha Varadarajan

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.2.0

+
+
+

Authorization Plugin Endpoint (beta)

+ +

GoCD currently supports password-file, LDAP and plugin based authentication.

+ +

In addition to authentication, GoCD offers authorization by restricting certain operations to specific users and groups of users ("roles").

+ +

Without the use of authorization plugins, roles can only be managed through GoCD and it does not provide an ability to use roles defined in systems used for authentication (for example in LDAP groups). With this limitation, administrators need to configure roles in multiples places.

+ +

The introduction of the authorization plugin endpoint (Beta) allows GoCD to delegate both authentication and authorization of users to plugins. The plugins will have the flexibility to use any identity service providers like LDAP, Google, GitHub etc.

+ +

Authorization Plugin Endpoint (beta) documentation is available. We have built LDAP Authentication plugin using the Authorization Plugin Endpoint, this plugin supports only authentication. We would recommend developers to write plugins which support both authentication and authorization and provide us feedback to enhance this endpoint.

+ +

Feature Enhancements

+ +
    +
  • +

    c088435 - Template Authorization UI and API enhancements.

    + +
      +
    • All pipeline group admins by default provided view permission to templates. Super admin can restrict this access.
      • +
    • Super admin can provide template view access to users/roles.
      • +
    • Allow template admins to delete templates via UI and API
      • +
    + +
    + Template Permissions +
    +
    • +
+ +

Other Improvements

+ +
    +
  • 3b9f54b - Go server/agent services do not get started on a new installation for debian and rpm based installations in order to allow users to make configuration changes before starting them up. (#3119)
    • +
+ +

Bug Fixes

+ +
    +
  • 7ddf84e - User search functionality - Search through plugins implementing AuthenticationExtension. (#3107)
    • +
  • ad1a118 - Sort resources and environments alphabetically on agents page selector dropdown. (#3134)
    • +
  • Multiple UI fixes on the old and new themes.
    • +
+ +

Security Fixes

+ +
    +
  • a837fc0 - Ensures passwords in git or hg material url's is masked before logging or using in server health message. (#3171)
    • +
+ +

Breaking changes

+ + + +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • As of release 17.1, version 2 of the Templates API was deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
+ +

Contributors

+ +

Aravind SV, Bhupendrakumar Piprava, Dmitry Ledentsov, Ganesh S Patil, Isabelle Carter, Jyoti Singh, Ketan Padegaonkar, Kyle Olivo, Lubaina R, Mahesh Panchaksharaiah, Markandan R, NaveenBhaskar, Rajiesh Narayanan, Stephen Gran, Sumanth Kumar Mora, Varsha Varadarajan, cnenning

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

17.1.0

+
+
+

Performance Improvement

+ +
    +
  • +

    2ae7fdb - Full config save optimization. (#2912)

    + +

    Optimization to full config save through UI and API to give significant improvements in the config save time. Our performance runs show full config save times reduced by half.

    +
    • +
+ +

API Enhancements

+ + + +

Plugin enhancements

+ + +

Other Improvements

+ +
    +
  • c094e90 - Added environment variables to the server api page. (#3073)
    • +
  • 0802c7e - Added CPU time in api/support for the threads. (#3006)
    • +
  • c749c47 - Added a link to pipeline settings in the pipeline history page. (#2939)
    • +
+ +

Bug Fixes

+ +
    +
  • Multiple UI fixes and tweaks on the new theme that was introduced in 16.12.
    • +
  • e9611f8 - Refresh ElasticAgent-OperatingSystem and ElasticAgent-UsableSpace while initializing the runtimeInfo. (#3078)
    • +
  • b66bddc - Refactor agent controller to switch between http and websockets. (#2864)
    • +
  • c26f118 - Mask password entered for materials of type svn, tfs, perforce. (#2937)
    • +
  • 4b684ee - Provide template admin authorization to users within a role. (#2989)
    • +
  • df85694 - Additional validations for templates API. (#3035)
    • +
+ +

Breaking changes

+ +
    +
  • +

    920b7ee - Removed support for Java 7.

    + +

    Starting with the 17.1 release of GoCD, Server and Agents will only run with Java 8. Users are encouraged to upgrade to the latest release of GoCD with Java 8.

    + +

    Windows installations of GoCD need not install Java 8 separately since the Windows installer comes bundled with a JRE. However this may require users to upgrade the agent installer on Windows.

    + +

    If you have trouble while upgrading to Go version 17.1, please take a look at the + troubleshooting page in the + documentation.

    +
    • +
  • +

    7a48c1a - Removed GoCD OpenSocial Gadget (Card activity tab) and Pipeline Dashboard Widget in Mingle. (#1908)

    + +

    As of release 16.12, the OpenSocial gadgets was deprecated. This feature is now removed because of a couple of reasons — + (a) there's not enough evidence of many users using this feature in a way that'll impact their usage of GoCD + (b) the underlying implementation framework (Apache Shindig) hasn't been maintained for quite some time and contained several security vulnerabilities.

    +
    • +
  • +

    7274d23 - Removed Version 2 and 3 of the Agents API. (#2984)

    + +

    As of release 16.12, version 2 and version 3 of the Agents API was deprecated. Version 2 of Agents API was introduced in 15.3.0 and version 3 of the API was introduced in 16.8. These versions of the API have been removed in favor of version 4 of this API. This API is backward compatible, and users are encouraged to use it.

    +
    • +
  • +

    1e48c42 - Removed Templates API Version 1.

    + +

    As of release 16.11, version 1 of the Templates API was deprecated. Users are encouraged to use Version 3 of the API which is backward compatible with Version 1.

    +
    • +
  • +

    f2ac6b1 - Removed support for text based API support log. (#2975)

    +
    • +
  • +

    da61c2b - Removed old Agents page. (#3015)

    +
    • +
+ +

Deprecations

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • As of release 16.12, git versions older than 1.9 are deprecated. Support for git versions older than 1.9 will be stopped in 17.2 (scheduled to be released in February 2017). Users are recommended to upgrade git on the GoCD server and agents (if git is used as a material). We are aware that the linux distributions have an older version of git installed by default. Please refer to this to upgrade git.
    • +
  • As of release 16.12, version 1 of the Plugin Info API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 17.1, version 2 of the Templates API is deprecated. This version of the API will be removed in 17.4 release (scheduled to be released in April 2017). Version 3 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 of the Pipeline Config API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 3 of this API is backward compatible, and users are encouraged to use it.
    • +
  • +

    As of release 16.7, Java API based Go Plugins have been deprecated. Support for running these plugins will be removed in 17.2 (scheduled to be released in February 2017). Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins.

    + +

    Below is the list of plugins that will stop working in 17.2.

    + +

    Note: The GoCD team has built a shim that allows migration of all plugins with minimal change. We are actively working with plugin authors to ensure that these plugins are migrated over in time for 17.2.

    + +

    Package plugins

    + + + +

    Task plugins

    + + +
    • +
+ +

Contributors

+ +

Alison Polton-Simon, Aravind SV, Bhupendrakumar Piprava, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, Markandan R, Naveen Bhaskar, Padma Mullagiri, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Setkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? We're here to help. Reach out to us.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.12.0

+
+
+

UI Refresh

+ +

The entire application has been refreshed to sport a flat look.

+ +

If you have feedback or issues with the new look please log them at GitHub.

+ +
+ New Theme +
+ +

Agents Page

+ +

A brand new snappy and light-weight replacement for viewing and managing agents!

+ +

The old page is still available as a toggle. +If you have feedback or issues with the new agents page please log them at GitHub.

+ +
+ Agents Page +
+ +

Elastic Agents

+ +

Elastic agents is now a fully supported feature in GoCD.

+ +

To be able to use elastic agents, you should install an existing elastic-agent plugin, or write your own. Once the plugin is installed you must configure an "elastic agent profile" that you can associate with the jobs that require elastic agents.

+ +
+ Create Elastic Profile +
+ +

TFS Upgrade

+ +

We have upgraded to TEE SDK 14.0.3. Users will now be able to use GoCD with TFS 2012, 2013, 2015 and Visual Studio Team Services. Please file an issue if you're having issues connecting to TFS repositories. Earlier versions of TFS are no longer supported and may not work.

+ +

Pipeline Edit Link

+ +

Users can now directly navigate to the pipeline settings page from the stage and job detail page.

+ +

API Enhancements

+ +
    +
  • 8952af2 - API to manage packages.
    • +
  • e599a23 - API to manage package repositories.
    • +
  • 9aabf48 - Introduced version 2 of Plugin Info API to provide complete metadata for plugin type package-repository and icons for plugins that provide it.
    • +
+ +

Other Improvements

+ +
    +
  • fddc9fe - Improve performance of downloading of agent jars on a server upgrade. (#2813)
    • +
  • 5387e21 - Handling cleanup of agent and launcher jars from previous version of agent during an upgrade. (#2789)
    • +
  • +

    b97b635 - Generate additional windows installers to be able to package 32 bit and 64 bit JRE.

    + +

    There are two flavors of Server and Agent installers for Windows, one packaged with 64 bit JRE and the other with 32 bit JRE. 32-bit JREs only allow up-to 2GB of memory. Because large GoCD servers usually need more than 2GB of heap size, we recommend using a Server with 64 bit JRE. Agents should continue to use 32 bit JRE unless required.

    +
    • +
  • +

    b763d31 - Generate SHA-256 webserver certs instead of SHA-1. (#2842)

    + +

    The self-signed web-server certificate that GoCD generates is now a SHA-256 certificate instead of a SHA-1 certificate. SHA1 certificates have been deprecated by most browser vendors and users will start to see a warning in their browsers.

    + +

    Any new installations of GoCD will generate a SHA-256 certificate. For existing installations, users should remove the file config/keystore to allow GoCD to regenerate a new server certificate. Depending on your end-to-end transport security settings you may need to configure the -rootCertFile argument to the GoCD agent.

    +
    • +
+ +

Bug Fixes

+ +
    +
  • b34da2d - Bug fixes to ensure that git gc on the config repository works as expected.
    • +
  • a34c6dc - Allow dots in the repository and package id. (#2844)
    • +
  • Miscellaneous fixes to the new quick edit and agents pages.
    • +
+ +

Library upgrades

+ +
    +
  • 4aa1c56 - Bump JRuby to 1.7.26 from 1.7.11.
    • +
  • f4bce94 - Upgrading JGit to 4.5.0.201609210915-r.
    • +
+ +

Breaking changes

+ +
    +
  • +

    5052154 - Removed Pipeline Config API V1. This API was deprecated since 16.7 and has been replaced with version 3. Version 3 of the API is available, and users are encouraged to use it.

    +
    • +
  • +

    Microsoft Internet Explorer versions older than 11 are no longer supported. Please use IE 11 or higher. Microsoft Edge is recommended.

    +
    • +
+ +

Deprecations

+ +

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+ +

The following features have been deprecated, along with the timeframe when they will be removed.

+ +
    +
  • We shall be stopping support for git versions older than 1.9 in three months time (Feb 2017). Users are recommended to upgrade git on the GoCD server and agents (if git is used as a material). We are aware that the linux distributions have an older version of git installed by default. Please refer to this to upgrade git.
    • +
  • The GoCD api support page http://your-server:8153/go/api/support supports JSON and plain-text outputs. JSON has been the default since release 16.6. We will be removing the plain-text output in release 17.1 (scheduled to be released in Jan 2017). It is much simpler to consume the JSON output than the plain-text output.
    • +
  • As of release 16.12, the OpenSocial gadgets have been deprecated. This feature will be removed in 17.1 (scheduled to be released in Jan 2017). This has been done for a few of reasons — +(a) there's not enough evidence of many users using this feature in a way that'll impact their usage of GoCD +(b) the underlying implementation framework (Apache Shindig) hasn't been maintained for quite some time and contain several security vulnerabilities.
    • +
  • As of release 16.12, version 1 of the Plugin Info API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.11, version 1 of the Templates API is deprecated. This version of the API will be removed in 17.1 release (scheduled to be released in Jan 2017). Version 2 of the API is available, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 and version 3 of the Agents API is deprecated. Version 2 of Agents API was introduced in 15.3.0 and version 3 of the API was introduced in 16.8. These versions of the API will be removed in 17.1 release (scheduled to be released in Jan 2017). Version 4 of this API is backward compatible, and users are encouraged to use it.
    • +
  • As of release 16.5, Java 7 support was deprecated. Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). GoCD works great with Java 8, and users are encouraged to use it.
    • +
  • As of release 16.12, version 2 of the Pipeline Config API is deprecated. This version of the API will be removed in 17.2 release (scheduled to be released in Feb 2017). Version 3 of this API is backward compatible, and users are encouraged to use it.
    • +
  • +

    As of release 16.7, Java API based Go Plugins have been deprecated. Support for running these plugins will be removed in 17.1 (scheduled to be released in January 2017). Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins.

    + +

    Below is the list of plugins that will stop working in 17.1.

    + +

    Note: The GoCD team has built a shim that allows migration of all plugins with minimal change. We are actively working with plugin authors to ensure that these plugins are migrated over in time for 17.1.

    + +

    Package plugins

    + + + +

    Task plugins

    + + +
    • +
+ +

Contributors

+ +

Alison Polton-Simon, Aravind SV, Bhupendrakumar Piprava, ByteFlinger, Ganesh S Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, Markandan R, Naveen Bhaskar, Padma Mullagiri, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Setkowski, Varsha Varadarajan, Walmyr (wlsf82 on GitHub), Zabil Cheriya Maliackal

+ +

Security researchers

+ +

https://hackerone.com/gocd/thanks

+ +

Note

+ +

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+ +

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.11.0

+
+
+

API enhancements

+ +

fb24522 - Added new API to manage elastic agent profiles.

+ +

Quick Edit (Beta) Changes/Fixes

+ +

1a345c0 - Working directory validation on the new pipeline config page.

+

e116274 - Added tooltip for material filter input.

+

761b411 - Show server side timer validation on new pipeline config page.

+ +

Bug fixes

+ +

ec51570 - Do not raise an exception when duplicate modifications are seen in the database.

+

40999af - Improve handling of weak etags with deflate.

+

c69c1c4 - Having fixed-delay does not honour the git gc cron.

+

4509fe7 - Fixing VSM show more link.

+

e3d3360 - Allow pipeline group admins to create or update SCMs.

+

d646cfc - Added a blank check for build tasks' attributes.

+

5a54b2b - Change current directory of agent's batch file in windows 8.

+

008f4f4 - Fix the checkbox to allow known users to login in server configuration page.

+

e49cac1 - Handling empty responses from package material plugins.

+ +

Breaking changes

+ +

No breaking changes in this release.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Alison Polton-Simon, Aravind SV, ByteFlinger, Ganesh S Patil, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh Narayanan, Sallie Walecka, Sumanth Kumar Mora, Tomasz Sętkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.10.0

+
+
+

Agents page (Beta)

+ +

This is a new page for managing agents, which should feel a lot more light weight and snappier than the existing agents page.

+ +

We would really appreciate your feedback to make this page better. If you notice any issues or bugs with this page, please submit a bug report on GitHub

+ +
+ Beta Agents Page +
+ +

How do I use this?

+ +

Click on the "Check out the new agents page" on the agents page that you're familiar with.

+ +
+ Old Agents Page +
+
+

Known issues

+

#2735 - Agents Bulk update API: Enabling a pending agent returns 400 bad request

+ +

Improvements

+ +

53d0d42 - Show details about linux distribution flavors and versions. (#2608)

+

cc69476 - Filter for pipeline history view. (#2391)

+ +

API enhancements

+ +

687d454 - Added new API to manage pipeline templates. (#2233)

+

f8ab50a - Added PATCH support for environments update API, this will allow you to specify pipelines and agents that should be added and/or removed in a single API call.

+

09c864e - Added Agents API V4. This adds a 'build_details' property with relevant links to the job that is currently building on the agent.

+ +

Bug fixes

+ +

2d8ec07 - Spaces are not trimmed from environment variables. (#1411)

+

845ee9b - Tweak the agent registration protocol a bit. (#2558)

+

ee9cdae - Escape the jar URL to allow symbols such as # (needed when running GoCD on Mesos).

+ +

Security fixes

+ +

1f2a189 - Do not display the value of secure environment variable in templates view. (#2652)

+ +

Performance improvements

+ +

53ab276 - Removed an extra post merge validation. (#2594)

+ +

Breaking changes

+ +

No breaking changes in this release

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Aravind SV, Ganesh S Patil, Juhi Jariwala, Ketan Padegaonkar, Mahesh Panchaksharaiah, Matt Devlin (Mdevlin4 on GitHub), Sumanth Kumar Mora, Naveen Bhaskar, Rajiesh Narayanan, Tim Anderegg, Tomasz Sętkowski, Varsha Varadarajan, Venkata Jaswanth, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.9.0

+
+
+

Quick Edit (Beta)

+ +

Currently, editing a pipeline means navigating through multiple pages (and page refreshes), for modifying stages, jobs with tabs for options and environment variables, etc. Quick edit to make it smoother.

+ +

With this feature, you can change a pipeline's materials/stages/jobs/tasks simultaneously and update it as single operation. This feature also uses the new pipeline config API to make your configuration changes quicker.

+ +How do I use this? + +

Click on "Quick Edit" button on the pipeline edit page.

+ +
+ Quick edit +
+ +

Click on "Normal Edit" button to get back to old edit page.

+
+ Quick edit +
+ +Why is this beta? + +

We are working on adding few missing features like:

+ +
    +

  • Package materials (like yum, maven, artifactory plugins)

    • +

  • Pipeline template editing, pipelines that use templates can only update Pipeline Settings +and Materials

    • +
+ +Known issues? + +

Missing API validation for a few attributes, they are tracked below:

+ +
    +

  • Pipeline Config API: Stage operate permission user not validated (#2629)

    • +

  • Pipeline Config API: Validation missing for parameter name used in the custom task argument (#2628)

    • +

  • Missing validation errors on pipeline_config API (#2553)

    • +
+ +What's next? + +

We really appreciate your feedback to make this page better.

+ +

Going forward, once all the features are in, we plan to use this page as the default view for modifying configuration.

+ +

Submit your feedback by creating github issue at https://github.com/gocd/gocd/issues

+ +

API Enhancements

+

d662685 - Provided Git and git-gc stats in the support api. (#2578)

+ +

Library upgrades

+

973cbf2 - Upgraded jetty minor version to 9.2.18.v20160721.

+

74b8b47 - Upgraded logging jars.

+ +

Bug fixes

+

dc78601 - Added validation of the encryptedPassword attribute of password aware materials - SVN, P4, TFS.

+ +

Security Fixes

+

faa6a2a - Removed displaying url's from the not found page. (#2584)

+

ca7ff9c - Changed the package material check-connection request from GET to POST. (#2550)

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

Contributors

+ +

Ganesh S Patil, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, Rajiesh Narayanan, Sumanth Kumar Mora, Tomasz Sętkowski, Varsha Varadarajan, Zabil Cheriya Maliackal

+ +

Security researchers

+ +https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.8.0

+
+
+

Beta Feature - Elastic agents

+ +

+The new extension point allows the gocd server (with the help of plugins) to spin up and shut down agents on demand. +This extension point allows plugin developers to write plugins that allow GoCD to hook into and leverage various technologies +like Docker, AWS, +GCE, Kubernetes. +

+ +

+Developers can start building their own elastic agent plugins by forking the +skeleton plugin +and looking at a sample docker plugin +as an example reference implementation. The plugin API documentation can be found here. +

+ +

API Enhancements

+

ee281ec - Added v3 of agents API to render (read-only) elastic agent attributes.

+ +

Security Fixes

+

d8cd812 - Disallowed directory listing of certain folders on the GoCD server.

+

d05746b - Added a friendlier error message on failing to send test email.

+

fb32102 - Disallowed Plugin Interact endpoint for non Authentication Plugins.

+

4d871a6 - Add cache control and pragma header to login page.

+ +

Breaking Changes

+

e7bb87b - Added a custom header to the Create Backup API.

+

914974d - Added a custom header for the Create Artifact API.

+ +

Performance fixes

+

670df79 - Re-use SSL connections by specifying a user principal as part of all remoting connections.

+

4c472e1 - Used fixed delay instead rate execution of agent ping thread.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support was deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
  • + As of release 16.7, version 1 of the Pipeline Config API was deprecated. + This version of the API will be removed in 16.10 release (scheduled to be released in Oct 2016). + Version 2 of this API is backward compatible, and users are encouraged to use it. +
    • +
  • + As of release 16.7, Java API based Go Plugins have been deprecated. + Support for running these plugins will be removed in 17.1 (scheduled to be released in January 2017). + Plugin developers are encouraged to upgrade their plugins to use JSON message based plugin API. to build plugins. +
    • +
+ +

For GoCD developers

+

8806f6b - Added a vagrant file to allow local development and testing of GoCD.

+ +

Contributors

+

+Aravind SV, Ganesh Patil, Jyoti Singh, Ken Mugrage, Ketan Padegaonkar, Mahesh Panchaksharaiah, Naveen Bhaskar, norcnorc, Rajiesh Narayanan, Sumanth M, Tomasz Setkowski, Varsha Varadarajan, Zabil Cheriya Maliackal +

+

Security researchers

+

https://hackerone.com/gocd/thanks

+

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.7.0

+
+
+

GoCD configuration under SCM (a.k.a Config repositories)

+ +

+ Manage pipeline configurations from one or more source-control repositories (think "git repository") and modify them externally. + You can find more details about it here, + and watch a quick demo of this feature here. +

+ +

Known issues

+

Upgrading the agent to 16.7.0 before upgrading the server is known to cause issues. Users are advised to first upgrade the server to 16.7.0 before they upgrade the agent.

+

In case you are seeing issues with the agent not starting up after the upgrade, please see this comment.

+ +

Important bug fixes

+

3e88caf - Windows Installer fixes.

+ +

Improvements

+

b283b42 - Display the correct ip-address of agents running on virtualized instances or containers. (#1657)

+ +

API enhancements

+

34e05b6 - New API for viewing, creating and editing Pluggable SCMs. (#1508)

+

642d7f4 - New API for creating and editing environments. (#966)

+

79c7168 - New API for bulk updating agents. (#2340)

+

99e2707 - New API for viewing Plugin Information. (#1873)

+

d4a7639 - Support for updating whitelists using pipeline configuration API.

+ +

Security fixes

+

103340c - Upgraded all agent-server communication to use HTTPS by default. Read more about how to improve security of your GoCD setup.

+

3d2afad - Pluggable tasks secure configurations are encrypted before saving to xml configuration. (#903)

+

657feb3 - Added missing security headers on a few pages to activate web browser protection.

+

6909484 - Escaped the error message in the repositories page. (XSS).

+ +

Breaking changes

+

f58e900 - Removed Agents API v1, users should use version 2 of the. Agents API

+

5602048 - Removed old backup API, users should user version 1 of the. Backup API

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ + + +

For GoCD developers

+

d395806 - Migrated build scripts to Gradle.

+ +

Contributors

+

Aravind SV, adeshmukh-sf, Dominic Tootell, Ganesh Patil, Jyoti Singh, Ketan Padegaonkar, Mahesh Panchaksharaiah, norcnorc, Rajiesh Narayanan, Sumanth M, + Ted Sheibar, Tomasz Sętkowski, Varsha Varadarajan, Venkata Jaswanth, Viktor Sadovnikov, Zabil Cheriya Maliackal

+ +

Security researchers

+https://hackerone.com/gocd/thanks + +

Note

+

A more comprehensive list of changes for this release can be found here.

+ +

Have ideas and want to contribute? Need some help getting started? Search the archives in the GoCD mailing list.

+

Found a security issue that needs fixing? Please report it to https://hackerone.com/gocd

+ +
+
+

16.6.0

+
+
+

Whitelist support for SCM materials

+ +

#2314 - Handling the triggering of a pipeline for monolithic repositories using a whitelist.

+

For example, in a repository 'baz' with folders/projects 'foo/bar' and 'foo/qux' one +can trigger the pipeline only on changes to 'foo/bar' by configuring it as a whitelisted folder.

+ +

API Enhancements

+ +

#2240 - Added a URL endpoint to grab a snapshot of the GoCD config git repository. +For example, backup the config repo 'config-repository' using:

+ +
git clone https://ci.example.com/go/api/config-repository.git
+ +

#2283 - Changed the existing API /api/support to return information in JSON format for easier parsing. +This end point also returns more information to identify performance bottlenecks.

+ +

#2239 - Added a version API to get the version of Go server.

+ +

Performance Improvements

+ +

#2248 - Improved page load performance across the board.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support was deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
+ +

Upcoming Feature - Config in a repository

+

+This release also adds foundation for reading pipeline configuration from the material's repository. +This feature is still in development and more details can be found +here. +

+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Thanks to + Aravind SV, + Carlos Villela, + Ganesh S Patil, + Joakim Lahtinen, + Jyoti Singh, + Ketan Padegaonkar, + Lubaina Rangwala, + Mahesh Panchaksharaiah, + Marina, + Naveen Bhaskar, + Paul Nilsson, + Rajiesh Narayanan, + Ted Sheibar, + Tomasz Sętkowski, + Varsha V, + Xiao Li, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.5.0

+
+
+

Support for Java 8

+ +

+We've graduated from being Java 8 compatible to officially supporting it! +You can see our journey to this milestone +here. +

+ +

+GoCD will continue to support Java 7 till release 17.1 scheduled for January 2017. Post that, we will exclusively support Java 8. We recommend that you plan for and upgrade to Java 8 (for both GoCD server and agents) before the 17.1 release. +

+ +

Performance

+ +

#2145 - Handle large modifications made to SCM materials without memory issues on the agent.

+ +

Materials

+

Fixes around handling git rebase

+ +

#2110 - Fix automatic build loop after a git rebase.

+

#985 - Fix git history rewrite causing errors.

+ +

User interface

+ +

#2136 - Warnings on VSM if pipeline is built with incompatible revisions.

+ +

Deprecations

+

Features that become superseded or irrelevant become deprecated, and are scheduled to be removed in some timeframe.

+

The following features have been deprecated, along with the timeframe when they will be removed

+ +
    +
  • + As of release 16.5, Java 7 support is deprecated. + Java 7 support will be removed in 17.1 release (scheduled to be released in January 2017). + GoCD works great with Java 8, and users are encouraged to use it. +
    • +
+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Thanks to + Aravind SV, + Brett Cave, + Ganesh S Patil, + Jen Marley, + Jyoti Singh, + Ketan Padegaonkar, + Moritz Lenz, + Mahesh Panchaksharaiah, + Naveen Bhaskar, + Rajiesh Narayanan, + Tomasz Sętkowski, + Varsha V, + vmignot, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.4.0

+
+
+

Security

+ +

+ Important: There are several security fixes to prevent XSS, CSRF and remote execution exploits. We highly recommend this upgrade to keep your GoCD server and agent secure. +

+ +

Performance

+ +

#2106 - Handle eviction/expiry of composite-keys from GoCache.

+ +

Note

+ +

+ A more comprehensive list of changes for this release can be found here. +

+ +

Contributors

+ +

+ Special thanks again to drrb for reporting and verifying all of the security vulnerabilities in this release. +

+ +

+ Thanks to + Aravind SV, + Austin Guest, + David Rice, + Ganesh S Patil, + Jen Marley, + Jyoti Singh, + Juhi Jariwala, + Ketan Padegaonkar, + Mahesh Panchaksharaiah, + Naveen Bhaskar, + Rajiesh Narayanan, + Rami, + Varsha V, + WPC, + Xiao Li, + Zabil C.M + for making GoCD better! +

+ +
+
+

16.3.0

+
+
+

Security

+

Important: This release fixes several XSS and CSRF vulnerabilities which can be exploited in earlier versions. As the changes are extensive, patches for older releases will not be provided. We recommend all users to upgrade to this version to safeguard your GoCD server.

+

These security vulnerabilities were responsibly disclosed by drrb. We want to give users some time to upgrade, before providing more details about the vulnerabilities. We will work with drrb on the specifics of providing these details, soon.

+

Notable features

+
Materials
+ +
+ GoCD shallow clone for git +
+
Configuration
+ +
Installers
+ +

API changes

+

The following APIs now require an extra request header Confirm: true (due to security-related changes):

+ +

Deprecations

+
    +
  • +

    The old java API-based plugin extensions for tasks and package repositories has been deprecated. Developers are encouraged to use the new JSON message-based APIs to author plugins.

    +

    These APIs will be removed in the September release of GoCD.

    +
    • +
  • +

    In light of downward trend in Solaris installers, we are now considering a timeline to stop providing Solaris installers for GoCD. Users can continue to use the generic zip files to run GoCD on Solaris. However the support for Solaris will be on a best-effort basis.

    +

    We will stop providing Solaris installers from the July release of GoCD.

    +
    • +
+

Note

+

A more comprehensive list of changes for this release can be found here.

+

Contributors

+

Special thanks to drrb for reporting and verifying all of the security vulnerabilities in this release.

+

Thanks to Andre Moeller, Aravind SV, bradeac, Chris Northwood, Daniel Somerfield, David Rice, Dmitry Ledentsov, Fredrik Wendt, Glenn Lewis, Jan Fabry, Jovan Alleyne, Jyoti Singh, Juhi Jariwala, Juha Siponen, Ketan Padegaonkar, Mahesh Panchaksharaiah, Rajiesh Narayanan, Tomasz Sętkowski, Varsha V, WPC, Xiao Li, Zabil C.M for making GoCD better!

+ +
+
+

16.2.1

+
+
+

+ Important: 16.2 has been removed from the downloads page because it had an issue which caused problems while installing windows agents. +

+
Fixes
+ + +
+
+

16.2.0

+
+
+

What's new in GoCD 16.2

+
Features and bug fixes
+ +

Note

+

+ A more comprehensive list of changes for this release can be found here. +

+

Contributors

+

+ Aravind SV, + Graham Christensen, + Jyoti Singh, + Juhi Jariwala, + Ketan Padegaonkar, + Mahesh Panchaksharaiah, + Mark Crossfield, + Rajiesh Narayanan, + Tomasz Sętkowski, + Varsha V, + WPC, + Xiao Li, + Zabil C.M +

+ +
+
+

16.1.0

+
+
+

What's new in GoCD 16.1

+

+ We are moving to a more regular release schedule, and so you might see releases with mostly issues fixed, while bigger level features are in progress across releases. +

+
Important features and bug fixes in this release -
+ +

Note

+

+ The comprehensive list of changes for this release can be found here. +

+

Thanks!

+

Tomasz Setkowski, Sean Escriva for making this release of GoCD better!

+ +
+
+

15.3.1

+
+
+

What's new in GoCD 15.3.1

+

Important: 15.3.1 has been removed from the downloads page because it had an issue which could have caused problems during configuration save. The issue + mentioned is fixed in 16.1.0. The rest of the issues mentioned below are a part of 16.1.0 as well. We highly recommend upgrading to 16.1.0.

+
Important bug fixes in this release -
+ +

Note

+

+ The comprehensive list of changes for this release can be found here. +

+ +
+
+

15.3.0

+
+
+

New API for editing pipelines

+

+ A convenience JSON HAL compliant API for modifying pipelines. Check + api.gocd.org for usage details. +

+

Get informed about updates

+

+ A new version of Go CD is released every few months, with this feature you'll now be notified about the latest supported release (if you are running an older version). +

+

+ Bell icon on the top nav bar +

+

+ Release notification appears on hovering over the bell icon +

+

Other notable features

+ +

Important bug fixes

+ +

Note

+

+ The comprehensive list of changes for this release can be found + here. +

+

Thanks!

+

Tomasz Setkowski, Steve Hill, Alex Schwartz, Pooja R, Srinivas Upadhya, Xiao Li, Sandy Gordon, Arun Kumar, Björn Andersson, Federica Luraschi, Graham Christensen, Parker Shelton, Justin, Max Griffiths, Ashok Gowtham M, Massood, Ben Overmyer,James M. Greene, Ashwanth Kumar, Jakub Narloch, Alex Voitau, Joakim Wånggren, Paul Clarkin, X O and markuswehrle for making Go better. +

+ +
+
+

15.2.0

+
+
+

Improvements to the console log

+

+ GoCD now supports rendering of ANSI color codes to show you much more beautiful console logs. Additionally, Go will automatically follow the logs as your build produces it, very much like your favorite terminal program. +

+
+ Console log coloring +
+
Authentication end-point
+

+ With the newly exposed authentication end-point, Go users can now add custom authentication schemes through plugins. Read the blog + post for details. +

+
+ GoCD Login Page with Git Hub icon +
+
Setup hostname when auto-registering agents
+

+ You can now specify a property agent.auto.register.hostname to setup the hostname when + auto-registering an agent. +

+

API Improvements

+

+ Go's APIs are fairly old, have inconsistent and unpredictable content types (csv, xml, json, plain text). +

+

+ We have now migrated the + Agents API, + Users API, + Backups API to use JSON hypermedia API (using JSON+HAL). +

+

Going forward, we would like to announce an ongoing effort to improve and migrate existing APIs to use something that is more modern, easy to discover, learn and build API clients for.

+

Learn more about the new API on our new api documentation site.

+

Other notable features

+
    +
  • #194 - Allow secure variables (environment) on environments, stages and jobs.
    • +
  • #1121 - Ability for plugins to CRUD global configuration.
    • +
  • #958 - API method for renaming agent.
    • +
  • #264 - Agent API to assign resource.
    • +
  • #1261 - Port over Users API.
    • +
  • #1292 - Port over Backup API.
    • +
  • #1087 - Switching to Jetty 9 by default
    • +
  • #1210 - SSL connection errors/warnings with modern browsers
    • +
  • #1306 - Upgrade jre packaged with windows installers to java 7u79
    • +
+

Bug fixes

+
    +
  • #68 - Re-scheduled pipeline does not show the updated Agent IP details on the Job details page
    • +
  • #1089 - Re-scheduled Jobs not being marked as completed on completion
    • +
  • #1060 - Assets (and content) could be served as gzip
    • +
  • #1061 - UTF-8 characters not getting displayed correctly when the job is running or when it is rescheduled
    • +
  • #1291 and #1249 - Fan-in performance improvements.
    • +
  • #1039 - Fix for relative root paths in SVN 1.5+ externals.
    • +
  • #1109 - XSS vulnerability on user settings page.
    • +
  • #1219 - XSS vulnerability via SCM commit messages.
    • +
  • #649 - Destination folder inside flyweight gets deleted in case a material is specified twice in the config (with and without destination).
    • +
  • #1297 - UI fix to display file in artifact tab if it contains only blank spaces as file name.
    • +
  • #1199 - Could not fetch artifact with '+' symbol in filename
    • +
  • #1012 - Unable to change configuration after making one of the pipelines use a template
    • +
  • #1201 - Session tracking mode changed to be cookie only
    • +
+

Note

+

The comprehensive list of changes for this release can be found here.

+

Thanks!

+

+ @ctorpe, @thenathanjones, + @nfisher, @paulclarkin, @skarlso for making Go better. +

+ +
+
+

15.1.0

+
+
+

New plugin endpoint for "Materials"

+

This new plugin endpoint introduced in 15.1 allows Go's already long list of source code materials to be extended without making changes to the core!

+

Support for this endpoint brought along support for GitHub pull requests, contributed by an external contributor @ashwanthkumar (so exciting!), with support from a Go core contributor, @srinivasupadhya. + You'll never need to wish that Go supported your favorite kind of material repository, you can implement support for it yourself! +

+

+ You can see all the SCM material plugins on the Go Community plugins. See how to write one, here. +

+

+ Here's how the GitHub pull requests plugin looks in action (below). Read more about it in this blog post. Watch out for more improvements in the UI around this area. +

+
+ GitHub Pull Request with GitHub poller and notification plugins +
+

New plugin endpoint for "Notifications"

+

Continuing on the path of opening up different parts of Go for extension, Go 15.1 introduces a new plugin endpoint for notifications. At this point, Go notifies the plugin of changes in the status of every stage, as it happens! This allows + for quite a lot of use cases, and we are excited to see plugins written against this endpoint even before release (yay, open source!).

+

@matt-richardson has written a really nice generic notification plugin, which sends build notifications to any websocket listener! @ashwanthkumar has written a great plugin to notify Slack about build status changes. @srinivasupadhya has written a couple of nice notification plugins to update pull request statuses in GitHub and Atlassian + Stash.

+

You can see all of those plugins on the Go Community plugins page/plugins/index.html. See how to write one yourself, here.

+

Pipeline label shortening

+

This contribution by @alexschwartz helps declutter the Go Dashboard, by allowing the pipeline label to be trimmed, per material. This feature is really useful when dealing with unwieldy 40 character + SHAs in pipelines with git/mercurial materials in them. This feature allows this:

+
+ Old long pipeline labels +
+

to be changed into this:

+
+ New short pipeline labels +
+

Read more about this feature in the documentation.

+

Timestamps in console logs

+

Starting from Go 15.1, Go's console logs will have timestamps for every line. This is very useful for finding out long-running parts of tasks. Here's how it looks:

+
+ Console log timestamps +
+
More ...
+

This release is filled with many other notable features, changes and fixes, such as:

+
    +
  • #848 - Support for Mercurial versions 2.0 and greater.
    • +
  • #781 - Post-commit hook for Mercurial (contribution by Go team alumnus, @sachinsudheendra).
    • +
  • #768 - A beta feature to upload plugins directly from within the Go plugins tab (contribution by @pwen and @pamo).
    • +
  • #700 - Run multiple agents as services - for Linux (contribution by @bernardn).
    • +
  • #400 - Large part of a long-pending upgrade from Jetty 6 to Jetty 9 (turned off, by default in 15.1 - Waiting for some performance fixes on Jetty's side).
    • +
  • #104 - Agents do not restart because of a server restart, any more (plugin sync issue fixed).
    • +
  • #725 - Pipeline instance information through APIs.
    • +
  • #941 - Small improvement around config save -Look for a lot more around this area soon!
    • +
  • #877 - Performance improvements around CCTray and APIs.
    • +
+ +
+
+

14.4.0

+
+
+

New Features

+
    +
  • 719 - JSON message based Plugin APIs (docs - package, + task) +
    • +
  • 44 - Revise how new pipelines appear under 'Personalize'. Thanks @mmb for the contribution. (docs) +
    • +
  • 699 - Users can comment on pipeline run history. (docs)
    Note: This feature needs some improvements + listed here. Therefore the feature is turned 'off' for this release. To turn 'on' the feature, see details. + Thanks @mmb, @gajwani,@fkotsian & @bsnchancontribution. +
    • +
+

Bug Fixes

+
    +
  • 716 - Multiline commit comments don't trigger notifications. Thanks @mythgarr for the contribution.
    • +
  • 360 - Unable to 'clean working directory' when recursive symlinks are present. Also, improved logging for error scenario. Thanks @mmb & @gajwani for the contribution.
    • +
  • 770 - 'Check connection' for package materials fails in 'new pipeline creation' wizard when there are many other task plugins registered.
    • +
+

Others

+
    +
  • 688 - Change command error stream prefix to STDERR. Thanks @mmb for the contribution.
    • +
  • 769 - Remove unnecessary logging from test environment. Thanks @hammerdr for the contribution.
    • +
+ +
+
+

14.3.0

+
+
+

New Features

+ +

Enhancements

+
    +
  • 435 - Value Stream Map for a commit. (docs) +
    • +
  • 466 - Setting up e-mail notifications is now easier with 'any pipeline' and 'any stage' options. Thanks @lcs777 for the contribution. (docs) +
    • +
  • 460 - Enhanced search which hide pipelines. Thanks @ciotlosm for the contribution.
    • +
  • 310 - Plugin logger now allows logging exceptions. Thanks @tusharm for the contribution. +
    • +
+

Tech Debt

+
    +
  • + 130 - Upgrade Rails 2.3.14 to 4.0.4. Thanks @juniorz for your ideas and contributions during the early days of migration. +
    • +
  • 401 - Moved four database tables to Hibernate from iBatis. Not something we expected to get a PR for, kudos to @RikTyer for this one. +
    • +
+

Bug Fixes

+
    +
  • 315 - Pipeline label was not getting resolved in case of auto trigger.
    • +
  • 403 - If Go server has firewall restrictions on outgoing connections, Xml test artifacts with dtd specified used to cause problems while uploading.
    • +
  • 469 - Fixed logged in session timeout. Thanks @greenmoss for reporting the issue.
    • +
  • 297 - Resource and personalise drop-downs were not showing up properly on some versions of chrome.
    • +
  • 482 - In Value Stream Map, material circle was not being rendered properly. Thanks @dvarchev for investigating and sending a patch.
    • +
  • 548 - Polling and builds used to fail when a git submodule URL changed. Thanks @mmb for the contribution.
    • +
  • 314 - Don't allow leading/trailing spaces in commands. Thanks @sahilm for the patch. +
    • +
  • 525 - Output working directory in console output and when polling fails. Thanks @mmb for the patch. +
    • +
+
Other
+ + +
+
+

14.2.0

+
+
+

Enhancements

+
    +
  • 190 - Git post commit hook to trigger Go pipeline. +
    • +
  • 271 - Make card activity gadget work with mingle saas instance. +
    • +
  • 185 - Adding a layer of database connection configurations. +
    • +
  • 203 - Adding verbosity to exception message while loading DatabaseProvider. +
    • +
  • 114 - Move OSX packaging from ant to buildr. +
    • +
+

Bug Fixes

+
    +
  • 286 - Go server logs for mac installers are not coming up. +
    • +
  • 196 - Cannot save a job which has colon (:) in its Nant Path. +
    • +
  • 223 - Large artifact fail to upload.
    • +
  • 246 - Pipeline history view flashes for long pipelines. +
    • +
  • 91 - The pipeline activity page does not show the revision completely even on hovering on it. +
    • +
+

Others

+
    +
  • 213 - Removing unused filter code.
    • +
+ +
+
+

14.1.0

+
+
+

Enhancements

+
    +
  • Added capability to create a Task plugin.
    • +
+

Bug Fixes

+
    +
  • Fixed a corner case issue around job reschedule.
    • +
  • Fixed issue where SVN post-commit hook was not passing along credentials.
    • +
  • Fixed issue with adding users via UI with a . (dot) in the username.
    • +
  • Go Agent handles UnknownHostException by substituting host name with a generated name.
    • +
  • Task running executables in the working directory should now be prefixed with ./.
    • +
+ +
+
+
+
+ +
+
+ + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/resources.html b/pr-1714/resources.html new file mode 100644 index 000000000..d31c0146c --- /dev/null +++ b/pr-1714/resources.html @@ -0,0 +1,220 @@ + + + + + + + + + + + + + + + + Resources, Documentation and Support | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+
+
+
+
+
+ GoCD user documentation +
+
+
+

Documentation

+ +
+
+
+
+
+ GoCD mailing list +
+
+
+

Mailing Lists

+
    +
  • + GoCD Users Google Group +

    This mailing list is a place for users of GoCD to discuss and help each other. Developers may participate in the list from time to time, but the primary interactions are between users.

    +
    • +
  • + GoCD Developers Google Group +

    This mailing list is used for discussions about the development of GoCD. This list is only for discussion of changes to the source code and related issues. Configuration and support questions should be addressed to the user group.

    +
    • +
+
+
+
+
+
+
+
+ GoCD developer documentation +
+
+
+

Developer Documentation

+
    +
  • + GoCD APIs +

    Documentation on using the RESTful GoCD APIs

    +
    • +
  • + GoCD Developer Documentation +

    Documentation describing the development environment, technology stack and architecture of GoCD.

    • +
  • + Contributor License Agreement +

    If you would like to contribute back to GoCD you'll need to electronically sign this agreement

    +
    • +
+
+
+
+
+
+ Other GoCD resources +
+
+
+

Other Resources

+ +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/resources/index.html b/pr-1714/resources/index.html new file mode 100644 index 000000000..e7a8caa10 --- /dev/null +++ b/pr-1714/resources/index.html @@ -0,0 +1,220 @@ + + + + + + + + + + + + + + + + Resources, Documentation and Support | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+ +
+
+
+
+
+
+
+
+ GoCD user documentation +
+
+
+

Documentation

+ +
+
+
+
+
+ GoCD mailing list +
+
+
+

Mailing Lists

+
    +
  • + GoCD Users Google Group +

    This mailing list is a place for users of GoCD to discuss and help each other. Developers may participate in the list from time to time, but the primary interactions are between users.

    +
    • +
  • + GoCD Developers Google Group +

    This mailing list is used for discussions about the development of GoCD. This list is only for discussion of changes to the source code and related issues. Configuration and support questions should be addressed to the user group.

    +
    • +
+
+
+
+
+
+
+
+ GoCD developer documentation +
+
+
+

Developer Documentation

+
    +
  • + GoCD APIs +

    Documentation on using the RESTful GoCD APIs

    +
    • +
  • + GoCD Developer Documentation +

    Documentation describing the development environment, technology stack and architecture of GoCD.

    • +
  • + Contributor License Agreement +

    If you would like to contribute back to GoCD you'll need to electronically sign this agreement

    +
    • +
+
+
+
+
+
+ Other GoCD resources +
+
+
+

Other Resources

+ +
+
+
+
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/roadmap.html b/pr-1714/roadmap.html new file mode 100644 index 000000000..6da29a26d --- /dev/null +++ b/pr-1714/roadmap.html @@ -0,0 +1,235 @@ + + + + + + + + + + + + + + + + Roadmap - GoCD Product Vision | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Roadmap

+ GoCD's current roadmap and the work being done towards it +
+
+
+
+ +

+ +

High level principles on which GoCD's roadmap is based

+
    +
  • Be universal and be extensible.
    • + +
  • Improve support for APIs and configuration as code.
    • + +
  • Improve user experience based on research into how GoCD is used.
    • + +
  • Produce more supporting content for improving the way people do CD.
    • +
+ +

Recent work

+
    +
  • + Making GoCD more cloud native: +
      +
    • Easier installation experience on Kubernetes, using helm charts.
      • +
    • Automatically configuring GoCD elastic agents to make agent provisioning flexible and on-demand.
      • +
    +
    • + +
  • Improving GoCD's trial experience by providing easier ways of trying it (for instance: docker-compose).
    • + +
  • Commercial plugin for analytics.
    • +
+ +

Overall direction:

+ +
    +
  1. +

    Make GoCD fit more natively with cloud providers and container schedulers:

    + + Container scheduling systems such as Kubernetes are all the rage and we think they’re great for Continuous Delivery. They provide great support for infrastructure as code and to run services and applications. CD, as a concept, is necessary in this world as well. We propose to enhance GoCD’s support for these systems by: + +

    + +
      +
    • Enabling multi-cluster support for GoCD’s Kubernetes elastic agents and Amazon ECS elastic agents.
      • +
    • Implementation-specific support for Kubernetes node management for Amazon EKS and Google GKE.
      • +
    • Reducing the barriers to using elastic agents by bundling them with GoCD and defaulting to Docker container based elastic agents.
      • +
    • Closer integration with Kubernetes for deployment of applications.
      • +
    +
    2. + +
  2. +

    Help teams optimize their end-to-end delivery workflow:

    + + This will be supported by: + +

    + +
      +
    • Enhancing GoCD analytics plugin to move from pull-based reporting to push-based insights on possible improvements to users’ defined end-to-end workflows.
      • +
    • More content and evangelism around the importance of metrics to Continuous Delivery.
      • +
    +
    3. + +
  3. +

    Make it easier for organizations to allow teams to self-provision their CD infrastructure:

    + + Organizations want teams to be in control of their part of the CD infrastructure, while expecting CD tools to provide the ability for different teams to be separated. They also expect the ability to have an overall view of workflows across the organization. GoCD already provides the ability to have separation at the level of pipeline groups. We propose to enhance these capabilities by: + +

    + +
      +
    • Introducing personal access tokens for APIs.
      • +
    • Secrets management support, with integration with Hashicorp Vault.
      • +
    • More granular permissions such as: +
        +
      • Ability to restrict what API tokens can do.
        • +
      • Ability for super-admins to delegate control to non-admin users.
        • +
      • Ability to control what configuration as code repositories are allowed to do.
        • +
      +
      • +
    • Allow configuration as code repositories to control more entities than pipelines and related entities.
      • +
    • Allow defining which entities configuration as code repositories can affect (to be able to provide separate repositories to teams).
      • +
    +
    4. + +
  4. +

    Improve the user experience of teams using GoCD:

    + + We've leaned on user interviews and research to understand how people use GoCD and how teams practice Continuous Delivery. Based on insights from these conversations and research, we continuously improve the user experience of GoCD. Upcoming work in this area includes: + +

    + +
      +
    • Improved configuration as code experience: Reducing the feedback loop between making changes to the code and seeing your changes in GoCD.
      • +
    • Improved experience of navigation from GoCD's dashboard to the logs of failing jobs.
      • +
    +
    5. +
+ +

+ +Last updated: Apr 12, 2019 + +

+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/roadmap/index.html b/pr-1714/roadmap/index.html new file mode 100644 index 000000000..e9bfa021a --- /dev/null +++ b/pr-1714/roadmap/index.html @@ -0,0 +1,235 @@ + + + + + + + + + + + + + + + + Roadmap - GoCD Product Vision | GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+
+

Roadmap

+ GoCD's current roadmap and the work being done towards it +
+
+
+
+ +

+ +

High level principles on which GoCD's roadmap is based

+
    +
  • Be universal and be extensible.
    • + +
  • Improve support for APIs and configuration as code.
    • + +
  • Improve user experience based on research into how GoCD is used.
    • + +
  • Produce more supporting content for improving the way people do CD.
    • +
+ +

Recent work

+
    +
  • + Making GoCD more cloud native: +
      +
    • Easier installation experience on Kubernetes, using helm charts.
      • +
    • Automatically configuring GoCD elastic agents to make agent provisioning flexible and on-demand.
      • +
    +
    • + +
  • Improving GoCD's trial experience by providing easier ways of trying it (for instance: docker-compose).
    • + +
  • Commercial plugin for analytics.
    • +
+ +

Overall direction:

+ +
    +
  1. +

    Make GoCD fit more natively with cloud providers and container schedulers:

    + + Container scheduling systems such as Kubernetes are all the rage and we think they’re great for Continuous Delivery. They provide great support for infrastructure as code and to run services and applications. CD, as a concept, is necessary in this world as well. We propose to enhance GoCD’s support for these systems by: + +

    + +
      +
    • Enabling multi-cluster support for GoCD’s Kubernetes elastic agents and Amazon ECS elastic agents.
      • +
    • Implementation-specific support for Kubernetes node management for Amazon EKS and Google GKE.
      • +
    • Reducing the barriers to using elastic agents by bundling them with GoCD and defaulting to Docker container based elastic agents.
      • +
    • Closer integration with Kubernetes for deployment of applications.
      • +
    +
    2. + +
  2. +

    Help teams optimize their end-to-end delivery workflow:

    + + This will be supported by: + +

    + +
      +
    • Enhancing GoCD analytics plugin to move from pull-based reporting to push-based insights on possible improvements to users’ defined end-to-end workflows.
      • +
    • More content and evangelism around the importance of metrics to Continuous Delivery.
      • +
    +
    3. + +
  3. +

    Make it easier for organizations to allow teams to self-provision their CD infrastructure:

    + + Organizations want teams to be in control of their part of the CD infrastructure, while expecting CD tools to provide the ability for different teams to be separated. They also expect the ability to have an overall view of workflows across the organization. GoCD already provides the ability to have separation at the level of pipeline groups. We propose to enhance these capabilities by: + +

    + +
      +
    • Introducing personal access tokens for APIs.
      • +
    • Secrets management support, with integration with Hashicorp Vault.
      • +
    • More granular permissions such as: +
        +
      • Ability to restrict what API tokens can do.
        • +
      • Ability for super-admins to delegate control to non-admin users.
        • +
      • Ability to control what configuration as code repositories are allowed to do.
        • +
      +
      • +
    • Allow configuration as code repositories to control more entities than pipelines and related entities.
      • +
    • Allow defining which entities configuration as code repositories can affect (to be able to provide separate repositories to teams).
      • +
    +
    4. + +
  4. +

    Improve the user experience of teams using GoCD:

    + + We've leaned on user interviews and research to understand how people use GoCD and how teams practice Continuous Delivery. Based on insights from these conversations and research, we continuously improve the user experience of GoCD. Upcoming work in this area includes: + +

    + +
      +
    • Improved configuration as code experience: Reducing the feedback loop between making changes to the code and seeing your changes in GoCD.
      • +
    • Improved experience of navigation from GoCD's dashboard to the logs of failing jobs.
      • +
    +
    5. +
+ +

+ +Last updated: Apr 12, 2019 + +

+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/robots.txt b/pr-1714/robots.txt new file mode 100644 index 000000000..1f53798bb --- /dev/null +++ b/pr-1714/robots.txt @@ -0,0 +1,2 @@ +User-agent: * +Disallow: / diff --git a/pr-1714/sedaily.html b/pr-1714/sedaily.html new file mode 100644 index 000000000..0bfdedea2 --- /dev/null +++ b/pr-1714/sedaily.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ./?utm_campaign=sedaily_2017_podcast&utm_medium=sedaily_podcast&utm_source=sedaily_podcast&utm_content=sed_podcast&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/sedaily/index.html b/pr-1714/sedaily/index.html new file mode 100644 index 000000000..19e7ea981 --- /dev/null +++ b/pr-1714/sedaily/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../?utm_campaign=sedaily_2017_podcast&utm_medium=sedaily_podcast&utm_source=sedaily_podcast&utm_content=sed_podcast&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/sitemap.xml b/pr-1714/sitemap.xml new file mode 100644 index 000000000..a2c33ec1a --- /dev/null +++ b/pr-1714/sitemap.xml @@ -0,0 +1,1161 @@ + + + + http://localhost:4567/2016/01/17/not-done-unless-its-done/ + + + http://localhost:4567/2015/06/13/using-windows-powershell-tasks/ + + + http://localhost:4567/2015/09/01/visibility-is-opportunity/ + + + http://localhost:4567/2017/10/03/introduction-continuous-delivery-deployment-tools/ + + + http://localhost:4567/2014/06/05/using-go-cd-with-custom-certificates/ + + + http://localhost:4567/2016/03/24/how-to-avoid-brittle-code/ + + + http://localhost:4567/glossary/ + + + http://localhost:4567/resources/ + + + http://localhost:4567/contributor-license-agreement/ + + + http://localhost:4567/misc/generate-patched-jar-for-deserialization-vulnerability/ + + + http://localhost:4567/videos/go-value-stream-map/ + + + http://localhost:4567/videos/go-pipeline-visibility/ + + + http://localhost:4567/videos/go-failed-smoke-test/ + + + http://localhost:4567/videos/go-command-repo/ + + + http://localhost:4567/2015/04/27/Feature-Branch-Support/ + + + http://localhost:4567/2018/10/30/measure-continuous-delivery-process/ + + + http://localhost:4567/2018/07/31/cd-microservices-configuration-strategy/ + + + http://localhost:4567/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/ + + + http://localhost:4567/2015/11/09/deserialization-vulnerability-commons-collections/ + + + http://localhost:4567/2017/06/22/deployment-pipeline-patterns-infographic/ + + + http://localhost:4567/2017/04/17/build-propagation-using-fan-in-fan-out/ + + + http://localhost:4567/2023/02/13/gocd-project-status/ + + + http://localhost:4567/2016/02/08/not-done-unless-its-done-security/ + + + http://localhost:4567/2018/07/17/gocd-materials-blacklisting-whitelisting/ + + + http://localhost:4567/2017/10/31/mobile-app-continuous-delivery-gocd/ + + + http://localhost:4567/2017/05/16/its-not-CI-its-CI-theatre/ + + + http://localhost:4567/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/ + + + http://localhost:4567/2015/10/29/go-webinar-recording/ + + + http://localhost:4567/2015/10/19/gocd-snap-at-devops-enterprise-summit/ + + + http://localhost:4567/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/ + + + http://localhost:4567/2017/08/15/canary-releases/ + + + http://localhost:4567/ebook-cd-analytics/ + + + http://localhost:4567/getting-started/part-1/ + + + http://localhost:4567/getting-started/part-2/ + + + http://localhost:4567/getting-started/part-3/ + + + http://localhost:4567/googlebac7590bd2b477d8/ + + + http://localhost:4567/contribute/ + + + http://localhost:4567/help/ + + + http://localhost:4567/roadmap/ + + + http://localhost:4567/videos/go-fan-out-fan/ + + + http://localhost:4567/videos/go-linking-dependencies/ + + + http://localhost:4567/videos/go-fundamental-concepts/ + + + http://localhost:4567/pipelines-as-code/ + + + http://localhost:4567/why-gocd/ + + + http://localhost:4567/analytics/ + + + http://localhost:4567/enterprise/thoughtworks-support-services-general-terms/ + + + http://localhost:4567/enterprise/thoughtworks-go-extensions-eula/ + + + http://localhost:4567/analytics-feedback/ + + + http://localhost:4567/elastic-agents/ + + + http://localhost:4567/kubernetes/ + + + http://localhost:4567/cd101/ + + + http://localhost:4567/jenkins/ + + + http://localhost:4567/2017/05/09/continuous-integration-devops-research/ + + + http://localhost:4567/2016/06/21/dont-let-sunk-costs-sink-your-project/ + + + http://localhost:4567/2015/07/14/Go_15_2_announced/ + + + http://localhost:4567/2018/03/21/continuous-delivery-gocd-kubernetes/ + + + http://localhost:4567/2014/03/06/hello-world-with-go/ + + + http://localhost:4567/2017/07/10/gocd-vs-spinnaker/ + + + http://localhost:4567/2014/02/25/why-we-need-to-practice-cd/ + + + http://localhost:4567/2017/06/13/modeling-deployment-pipelines-agents-environments/ + + + http://localhost:4567/2020/10/11/restore-backup-for-gocd-on-kubernetes/ + + + http://localhost:4567/2017/05/02/what-does-pipelines-as-code-really-mean/ + + + http://localhost:4567/2014/11/11/Go_14_3_announced/ + + + http://localhost:4567/2015/12/22/gocd-in-2016/ + + + http://localhost:4567/2015/06/23/hardly-anyone-knows-cd/ + + + http://localhost:4567/2015/08/28/pipeline-patterns/ + + + http://localhost:4567/2017/09/19/actions-spread-devops-adoption/ + + + http://localhost:4567/2015/05/06/Getting-Started-Resources/ + + + http://localhost:4567/2017/04/06/reusing-pipelines/ + + + http://localhost:4567/2017/03/ + + + http://localhost:4567/2017/06/01/forever-home/ + + + http://localhost:4567/2020/04/14/gocd-on-kubernetes-using-terraform/ + + + http://localhost:4567/2017/02/16/migrating-snapci-to-gocd/ + + + http://localhost:4567/2014/08/07/go-webinar-recording/ + + + http://localhost:4567/2018/10/16/new-gocd-features/ + + + http://localhost:4567/2019/05/21/official-stance-on-java/ + + + http://localhost:4567/2018/11/30/deployment-frequency/ + + + http://localhost:4567/2021/12/14/log4j-vulnerability/ + + + http://localhost:4567/2018/05/08/continuous-delivery-microservices-test-strategy/ + + + http://localhost:4567/2017/07/25/blue-green-deployments/ + + + http://localhost:4567/2014/07/01/What-would-help-you/ + + + http://localhost:4567/2018/09/11/cd-microservices-remediation-strategy/ + + + http://localhost:4567/2017/05/23/control-deployments-manual-approvals/ + + + http://localhost:4567/2017/04/25/gocd-over-jenkins/ + + + http://localhost:4567/2017/09/05/misconceptions-patterns-devops-adoption/ + + + http://localhost:4567/2019/06/25/GoCD-non-root-containers/ + + + http://localhost:4567/2015/05/07/go-webinar-recording/ + + + http://localhost:4567/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/ + + + http://localhost:4567/2020/10/11/perform-backup-for-gocd-on-kubernetes/ + + + http://localhost:4567/2015/06/18/authentication-end-point/ + + + http://localhost:4567/2014/02/25/go-moving-to-open-source/ + + + http://localhost:4567/2017/07/20/deployment-pipeline-automated-testing/ + + + http://localhost:4567/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/ + + + http://localhost:4567/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/ + + + http://localhost:4567/2014/02/24/model-everything-fail-fast/ + + + http://localhost:4567/2018/02/13/managing-build-versions-pipeline/ + + + http://localhost:4567/2015/08/05/Go-Sample-Virtualbox/ + + + http://localhost:4567/2014/04/24/source-code-for-go-now-available/ + + + http://localhost:4567/2014/02/24/build-promotion-go/ + + + http://localhost:4567/2014/03/10/go-webinar-recording/ + + + http://localhost:4567/2014/05/18/manage-agents-with-docker/ + + + http://localhost:4567/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/ + + + http://localhost:4567/2017/08/22/principles-practices-continuous-delivery/ + + + http://localhost:4567/2015/06/17/Upcoming-API-Changes/ + + + http://localhost:4567/2018/07/24/gocd-usage-analytics/ + + + http://localhost:4567/2019/05/14/installing-configuring-gocd-gke-using-helm/ + + + http://localhost:4567/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/ + + + http://localhost:4567/2017/09/12/value-stream-mapping/ + + + http://localhost:4567/2018/01/17/continuous-delivery-beginners-guide/ + + + http://localhost:4567/2014/11/21/go-webinar-recording/ + + + http://localhost:4567/2014/08/19/cloning-templates/ + + + http://localhost:4567/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/ + + + http://localhost:4567/2015/04/23/Go_15_1_jdk7_announcement/ + + + http://localhost:4567/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/ + + + http://localhost:4567/2017/03/01/importance-and-principles-of-cd-pipelines/ + + + http://localhost:4567/2014/04/24/agent-bootstrapper-upgrade-for-plugins/ + + + http://localhost:4567/2014/02/24/go-template-permissions/ + + + http://localhost:4567/2018/01/31/continuous-delivery-metrics/ + + + http://localhost:4567/2014/02/24/deploy-package-not-just-tag-branch-or-binary/ + + + http://localhost:4567/2017/04/06/ + + + http://localhost:4567/2017/04/17/ + + + http://localhost:4567/2017/04/25/ + + + http://localhost:4567/2017/04/ + + + http://localhost:4567/2017/05/02/ + + + http://localhost:4567/2017/05/09/ + + + http://localhost:4567/2017/05/16/ + + + http://localhost:4567/2017/05/23/ + + + http://localhost:4567/2017/05/ + + + http://localhost:4567/2017/06/01/ + + + http://localhost:4567/2017/06/13/ + + + http://localhost:4567/2017/06/20/ + + + http://localhost:4567/2017/06/22/ + + + http://localhost:4567/2017/06/26/ + + + http://localhost:4567/2017/06/ + + + http://localhost:4567/2017/07/05/ + + + http://localhost:4567/2016/02/08/ + + + http://localhost:4567/2016/02/ + + + http://localhost:4567/2016/03/15/ + + + http://localhost:4567/2016/03/24/ + + + http://localhost:4567/2016/03/ + + + http://localhost:4567/2016/06/08/ + + + http://localhost:4567/2016/06/21/ + + + http://localhost:4567/2016/06/ + + + http://localhost:4567/2016/07/13/ + + + http://localhost:4567/2016/07/ + + + http://localhost:4567/2016/ + + + http://localhost:4567/2017/01/05/ + + + http://localhost:4567/2017/01/ + + + http://localhost:4567/2017/02/16/ + + + http://localhost:4567/2017/02/ + + + http://localhost:4567/2017/03/01/ + + + http://localhost:4567/2017/03/29/ + + + http://localhost:4567/2017/10/03/ + + + http://localhost:4567/2017/10/10/ + + + http://localhost:4567/2017/10/17/ + + + http://localhost:4567/2017/10/31/ + + + http://localhost:4567/2017/10/ + + + http://localhost:4567/2017/11/07/ + + + http://localhost:4567/2017/11/14/ + + + http://localhost:4567/2017/11/28/ + + + http://localhost:4567/2017/11/ + + + http://localhost:4567/2017/12/06/ + + + http://localhost:4567/2017/12/ + + + http://localhost:4567/2017/ + + + http://localhost:4567/2018/01/17/ + + + http://localhost:4567/2018/01/31/ + + + http://localhost:4567/2018/01/ + + + http://localhost:4567/2018/02/13/ + + + http://localhost:4567/changelog/ + + + http://localhost:4567/2017/07/10/ + + + http://localhost:4567/2017/07/13/ + + + http://localhost:4567/2017/07/18/ + + + http://localhost:4567/2017/07/20/ + + + http://localhost:4567/2017/07/25/ + + + http://localhost:4567/2017/07/ + + + http://localhost:4567/2017/08/08/ + + + http://localhost:4567/2017/08/15/ + + + http://localhost:4567/2017/08/22/ + + + http://localhost:4567/2017/08/29/ + + + http://localhost:4567/2017/08/31/ + + + http://localhost:4567/2017/08/ + + + http://localhost:4567/2017/09/05/ + + + http://localhost:4567/2017/09/12/ + + + http://localhost:4567/2017/09/19/ + + + http://localhost:4567/2017/09/26/ + + + http://localhost:4567/2017/09/ + + + http://localhost:4567/2014/05/ + + + http://localhost:4567/2014/06/05/ + + + http://localhost:4567/2014/06/ + + + http://localhost:4567/2014/07/01/ + + + http://localhost:4567/2014/07/09/ + + + http://localhost:4567/2014/07/ + + + http://localhost:4567/2014/08/07/ + + + http://localhost:4567/2014/08/19/ + + + http://localhost:4567/2014/08/ + + + http://localhost:4567/2014/10/09/ + + + http://localhost:4567/2014/10/ + + + http://localhost:4567/2014/11/11/ + + + http://localhost:4567/2014/11/14/ + + + http://localhost:4567/2014/11/21/ + + + http://localhost:4567/2014/11/ + + + http://localhost:4567/2014/12/17/ + + + http://localhost:4567/2014/12/ + + + http://localhost:4567/2014/page/3/ + + + http://localhost:4567/2014/page/2/ + + + http://localhost:4567/2015/page/3/ + + + http://localhost:4567/2015/page/2/ + + + http://localhost:4567/2017/page/4/ + + + http://localhost:4567/2017/page/3/ + + + http://localhost:4567/2017/page/2/ + + + http://localhost:4567/2018/page/2/ + + + http://localhost:4567/2014/02/24/ + + + http://localhost:4567/2014/02/25/ + + + http://localhost:4567/2014/02/ + + + http://localhost:4567/2014/03/06/ + + + http://localhost:4567/2014/03/10/ + + + http://localhost:4567/2014/03/ + + + http://localhost:4567/2014/04/24/ + + + http://localhost:4567/2014/04/ + + + http://localhost:4567/2014/05/18/ + + + http://localhost:4567/2015/08/28/ + + + http://localhost:4567/2015/08/ + + + http://localhost:4567/2015/09/01/ + + + http://localhost:4567/2015/09/ + + + http://localhost:4567/2015/10/19/ + + + http://localhost:4567/2015/10/29/ + + + http://localhost:4567/2015/10/ + + + http://localhost:4567/2015/11/09/ + + + http://localhost:4567/2015/11/18/ + + + http://localhost:4567/2015/11/ + + + http://localhost:4567/2015/12/22/ + + + http://localhost:4567/2015/12/28/ + + + http://localhost:4567/2015/12/ + + + http://localhost:4567/2015/ + + + http://localhost:4567/2016/01/17/ + + + http://localhost:4567/2016/01/25/ + + + http://localhost:4567/2016/01/ + + + http://localhost:4567/2014/ + + + http://localhost:4567/2015/04/23/ + + + http://localhost:4567/2015/04/27/ + + + http://localhost:4567/2015/04/29/ + + + http://localhost:4567/2015/04/ + + + http://localhost:4567/2015/05/06/ + + + http://localhost:4567/2015/05/07/ + + + http://localhost:4567/2015/05/ + + + http://localhost:4567/2015/06/13/ + + + http://localhost:4567/2015/06/17/ + + + http://localhost:4567/2015/06/18/ + + + http://localhost:4567/2015/06/23/ + + + http://localhost:4567/2015/06/ + + + http://localhost:4567/2015/07/07/ + + + http://localhost:4567/2015/07/14/ + + + http://localhost:4567/2015/07/ + + + http://localhost:4567/2015/08/05/ + + + http://localhost:4567/infoq/ + + + http://localhost:4567/support/ + + + http://localhost:4567/documentation/ + + + http://localhost:4567/cla/ + + + http://localhost:4567/learn-more/why-go/ + + + http://localhost:4567/contribute/contribution-guide/ + + + http://localhost:4567/getting-started/ + + + http://localhost:4567/contribute/roadmap/ + + + http://localhost:4567/contribute/cla/ + + + http://localhost:4567/community/plugins/ + + + http://localhost:4567/community/resources/ + + + http://localhost:4567/2017/04/11/gocd-over-jenkins/ + + + http://localhost:4567/2014/10/09/Distrubuted-Test-Execution/ + + + http://localhost:4567/2014/02/25/go-is-now-open-source/ + + + http://localhost:4567/partners/ + + + http://localhost:4567/events/ + + + http://localhost:4567/community/partners/ + + + http://localhost:4567/community/events/ + + + http://localhost:4567/chef/ + + + http://localhost:4567/community/ + + + http://localhost:4567/101/ + + + http://localhost:4567/podcastinit/ + + + http://localhost:4567/spinnaker/ + + + http://localhost:4567/arrested/ + + + http://localhost:4567/gocdvsjenkins/ + + + http://localhost:4567/govsjenkins/ + + + http://localhost:4567/SEdaily/ + + + http://localhost:4567/sedaily/ + + + http://localhost:4567/twit/ + + + http://localhost:4567/recode/ + + + http://localhost:4567/talkpython/ + + + http://localhost:4567/2017/11/14/minimizing-risk-improving-security-devops/ + + + http://localhost:4567/2016/07/13/DotNet-Core-and-GoCD/ + + + http://localhost:4567/2015/07/07/GitHub-Integration/ + + + http://localhost:4567/2017/09/26/are-you-ready-for-continuous-delivery-infographic/ + + + http://localhost:4567/2017/07/05/product-manager-guide-continuous-delivery/ + + + http://localhost:4567/2017/10/10/architecting-continuous-delivery/ + + + http://localhost:4567/2015/06/18/plugin-settings/ + + + http://localhost:4567/2016/01/25/are-you-ready-for-continuous-delivery/ + + + http://localhost:4567/2017/06/26/serverless-architecture-continuous-delivery/ + + + http://localhost:4567/2014/04/24/Go_14_1_announced/ + + + http://localhost:4567/2017/07/13/introduction-continuous-delivery-101/ + + + http://localhost:4567/2015/04/29/Go_15_1_announced/ + + + http://localhost:4567/2017/08/08/gocd-elastic-agents-benefits/ + + + http://localhost:4567/2019/01/14/cd-metrics-deployment-lead-time/ + + + http://localhost:4567/2018/08/21/replacing-gocd-with-gocd/ + + + http://localhost:4567/2017/08/29/driving-change-devops-adoption/ + + + http://localhost:4567/test-drive-gocd/ + + + http://localhost:4567/2014/12/17/Go_14_4_announced/ + + + http://localhost:4567/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/ + + + http://localhost:4567/2014/10/09/Distributed-Test-Execution/ + + + http://localhost:4567/2017/06/20/hotfixes-rollback-rollforward/ + + + http://localhost:4567/2014/02/24/tracing-our-path-production/ + + + http://localhost:4567/2014/07/09/stopping-support-for-java-jdk-6/ + + + http://localhost:4567/2018/06/12/cd-microservices-environment-strategy/ + + + http://localhost:4567/2017/03/29/beginnings-of-a-real-pipeline/ + + + http://localhost:4567/2019/03/19/user-authorization-ldap/ + + + http://localhost:4567/2017/08/31/apax-acquires-thoughtworks/ + + + http://localhost:4567/2015/12/28/gocd-continuous-delivery-through-pipelines/ + + + http://localhost:4567/2015/11/18/Open-Source-Tests/ + + + http://localhost:4567/2017/07/18/continuous-deployment-strategies/ + + + http://localhost:4567/2018/04/25/five-considerations-continuous-delivery-microservices/ + + + http://localhost:4567/2014/02/24/how-peg-your-pipeline-dependency-version/ + + + http://localhost:4567/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/ + + + http://localhost:4567/2018/09/ + + + http://localhost:4567/2018/10/16/ + + + http://localhost:4567/2018/10/30/ + + + http://localhost:4567/2018/10/ + + + http://localhost:4567/2018/11/30/ + + + http://localhost:4567/2018/11/ + + + http://localhost:4567/2018/ + + + http://localhost:4567/2019/01/14/ + + + http://localhost:4567/2019/01/ + + + http://localhost:4567/2019/03/19/ + + + http://localhost:4567/2019/03/ + + + http://localhost:4567/2019/05/14/ + + + http://localhost:4567/2019/05/21/ + + + http://localhost:4567/2019/05/ + + + http://localhost:4567/2019/06/25/ + + + http://localhost:4567/2019/06/ + + + http://localhost:4567/2019/08/05/ + + + http://localhost:4567/2018/02/ + + + http://localhost:4567/2018/03/21/ + + + http://localhost:4567/2018/03/ + + + http://localhost:4567/2018/04/25/ + + + http://localhost:4567/2018/04/ + + + http://localhost:4567/2018/05/08/ + + + http://localhost:4567/2018/05/30/ + + + http://localhost:4567/2018/05/ + + + http://localhost:4567/2018/06/12/ + + + http://localhost:4567/2018/06/ + + + http://localhost:4567/2018/07/17/ + + + http://localhost:4567/2018/07/24/ + + + http://localhost:4567/2018/07/31/ + + + http://localhost:4567/2018/07/ + + + http://localhost:4567/2018/08/21/ + + + http://localhost:4567/2018/08/ + + + http://localhost:4567/2018/09/11/ + + + http://localhost:4567/tags/cd-analytics/ + + + http://localhost:4567/tags/cd-for-microservices/ + + + http://localhost:4567/tags/cd-confessions/ + + + http://localhost:4567/tags/infographic/ + + + http://localhost:4567/tags/modeling-deployment-pipelines/ + + + http://localhost:4567/tags/cd-hacks/ + + + http://localhost:4567/tags/announcements/ + + + http://localhost:4567/tags/continuous-deployment-strategies/ + + + http://localhost:4567/tags/it-s-not-cd-if-you-can-t-deploy-right-now/ + + + http://localhost:4567/tags/cd-101/ + + + http://localhost:4567/enterprise-campaign/ + + + http://localhost:4567/enterprise/ + + + http://localhost:4567/2019/08/ + + + http://localhost:4567/2019/09/17/ + + + http://localhost:4567/2019/09/ + + + http://localhost:4567/2019/ + + + http://localhost:4567/2020/04/14/ + + + http://localhost:4567/2020/04/ + + + http://localhost:4567/2020/10/11/ + + + http://localhost:4567/2020/10/ + + + http://localhost:4567/2020/ + + + http://localhost:4567/2021/12/14/ + + + http://localhost:4567/2021/12/ + + + http://localhost:4567/2021/ + + + http://localhost:4567/2023/02/13/ + + + http://localhost:4567/2023/02/ + + + http://localhost:4567/2023/ + + + http://localhost:4567/tags/are-you-ready-for-continuous-delivery/ + + + http://localhost:4567/tags/selling-devops/ + + + http://localhost:4567/releases/ + + + http://localhost:4567/videos/ + + + http://localhost:4567/plugins/ + + + http://localhost:4567/blog/ + + + http://localhost:4567/download/ + + diff --git a/pr-1714/spinnaker.html b/pr-1714/spinnaker.html new file mode 100644 index 000000000..22e9aebd5 --- /dev/null +++ b/pr-1714/spinnaker.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the 2017/07/10/gocd-vs-spinnaker/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/spinnaker/index.html b/pr-1714/spinnaker/index.html new file mode 100644 index 000000000..f76876ffd --- /dev/null +++ b/pr-1714/spinnaker/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../2017/07/10/gocd-vs-spinnaker/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/support.html b/pr-1714/support.html new file mode 100644 index 000000000..c33f7f1a7 --- /dev/null +++ b/pr-1714/support.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the https://www.thoughtworks.com/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/support/index.html b/pr-1714/support/index.html new file mode 100644 index 000000000..c33f7f1a7 --- /dev/null +++ b/pr-1714/support/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the https://www.thoughtworks.com/ page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/tags/announcements.html b/pr-1714/tags/announcements.html new file mode 100644 index 000000000..1ba66beea --- /dev/null +++ b/pr-1714/tags/announcements.html @@ -0,0 +1,206 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/announcements/index.html b/pr-1714/tags/announcements/index.html new file mode 100644 index 000000000..e25337a2a --- /dev/null +++ b/pr-1714/tags/announcements/index.html @@ -0,0 +1,206 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/are-you-ready-for-continuous-delivery.html b/pr-1714/tags/are-you-ready-for-continuous-delivery.html new file mode 100644 index 000000000..c7b548da5 --- /dev/null +++ b/pr-1714/tags/are-you-ready-for-continuous-delivery.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery? + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/are-you-ready-for-continuous-delivery/index.html b/pr-1714/tags/are-you-ready-for-continuous-delivery/index.html new file mode 100644 index 000000000..5d376f502 --- /dev/null +++ b/pr-1714/tags/are-you-ready-for-continuous-delivery/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Are you ready for Continuous Delivery? + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-101.html b/pr-1714/tags/cd-101.html new file mode 100644 index 000000000..75e935d3c --- /dev/null +++ b/pr-1714/tags/cd-101.html @@ -0,0 +1,223 @@ + + + + + + + + + + + + + + + + CD 101 - Introduction to Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-101/index.html b/pr-1714/tags/cd-101/index.html new file mode 100644 index 000000000..0f5a420ef --- /dev/null +++ b/pr-1714/tags/cd-101/index.html @@ -0,0 +1,223 @@ + + + + + + + + + + + + + + + + CD 101 - Introduction to Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-analytics.html b/pr-1714/tags/cd-analytics.html new file mode 100644 index 000000000..3d3dc26e1 --- /dev/null +++ b/pr-1714/tags/cd-analytics.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-analytics/index.html b/pr-1714/tags/cd-analytics/index.html new file mode 100644 index 000000000..0fb182451 --- /dev/null +++ b/pr-1714/tags/cd-analytics/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-confessions.html b/pr-1714/tags/cd-confessions.html new file mode 100644 index 000000000..20a92e5ef --- /dev/null +++ b/pr-1714/tags/cd-confessions.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-confessions/index.html b/pr-1714/tags/cd-confessions/index.html new file mode 100644 index 000000000..590ff7e7a --- /dev/null +++ b/pr-1714/tags/cd-confessions/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-for-microservices.html b/pr-1714/tags/cd-for-microservices.html new file mode 100644 index 000000000..49e6db664 --- /dev/null +++ b/pr-1714/tags/cd-for-microservices.html @@ -0,0 +1,240 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-for-microservices/index.html b/pr-1714/tags/cd-for-microservices/index.html new file mode 100644 index 000000000..7a2c9d245 --- /dev/null +++ b/pr-1714/tags/cd-for-microservices/index.html @@ -0,0 +1,240 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-hacks.html b/pr-1714/tags/cd-hacks.html new file mode 100644 index 000000000..f25afb38c --- /dev/null +++ b/pr-1714/tags/cd-hacks.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/cd-hacks/index.html b/pr-1714/tags/cd-hacks/index.html new file mode 100644 index 000000000..4ee5f5edd --- /dev/null +++ b/pr-1714/tags/cd-hacks/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/continuous-deployment-strategies.html b/pr-1714/tags/continuous-deployment-strategies.html new file mode 100644 index 000000000..9c07cb2ef --- /dev/null +++ b/pr-1714/tags/continuous-deployment-strategies.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + Continuous Deployment Strategies + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/continuous-deployment-strategies/index.html b/pr-1714/tags/continuous-deployment-strategies/index.html new file mode 100644 index 000000000..a8a3eea2b --- /dev/null +++ b/pr-1714/tags/continuous-deployment-strategies/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + Continuous Deployment Strategies + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/infographic.html b/pr-1714/tags/infographic.html new file mode 100644 index 000000000..b21a746bb --- /dev/null +++ b/pr-1714/tags/infographic.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Continuous Delivery Infographics + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/infographic/index.html b/pr-1714/tags/infographic/index.html new file mode 100644 index 000000000..4986fb918 --- /dev/null +++ b/pr-1714/tags/infographic/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + + + + + + + Continuous Delivery Infographics + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now.html b/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now.html new file mode 100644 index 000000000..46b03b5cc --- /dev/null +++ b/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + It's Not CD if You Can't Deploy Right Now + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now/index.html b/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now/index.html new file mode 100644 index 000000000..3fbf838ab --- /dev/null +++ b/pr-1714/tags/it-s-not-cd-if-you-can-t-deploy-right-now/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + It's Not CD if You Can't Deploy Right Now + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/modeling-deployment-pipelines.html b/pr-1714/tags/modeling-deployment-pipelines.html new file mode 100644 index 000000000..fca61904f --- /dev/null +++ b/pr-1714/tags/modeling-deployment-pipelines.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Modeling Deployment Pipelines + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/modeling-deployment-pipelines/index.html b/pr-1714/tags/modeling-deployment-pipelines/index.html new file mode 100644 index 000000000..a81a00670 --- /dev/null +++ b/pr-1714/tags/modeling-deployment-pipelines/index.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + + + + + Modeling Deployment Pipelines + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/selling-devops.html b/pr-1714/tags/selling-devops.html new file mode 100644 index 000000000..7fcc3b1bc --- /dev/null +++ b/pr-1714/tags/selling-devops.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + You Can't Buy DevOps, but You May Need to Sell It + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/tags/selling-devops/index.html b/pr-1714/tags/selling-devops/index.html new file mode 100644 index 000000000..76b4ebf14 --- /dev/null +++ b/pr-1714/tags/selling-devops/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + + + + + + + You Can't Buy DevOps, but You May Need to Sell It + + + + + + + + + +
+
+ + + +
+ +
+ + + +
+
+ +
+
+
+
+
+ +
+
+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1714/talkpython.html b/pr-1714/talkpython.html new file mode 100644 index 000000000..06d34b64d --- /dev/null +++ b/pr-1714/talkpython.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the download/?utm_campaign=tptm_2016&utm_medium=podcast_banner&utm_source=podcast_Banner_tptm&utm_content=manage_complexity_ease&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/talkpython/index.html b/pr-1714/talkpython/index.html new file mode 100644 index 000000000..ff8409be9 --- /dev/null +++ b/pr-1714/talkpython/index.html @@ -0,0 +1,15 @@ + + + + + + + + You will be redirected to the ../download/?utm_campaign=tptm_2016&utm_medium=podcast_banner&utm_source=podcast_Banner_tptm&utm_content=manage_complexity_ease&utm_term= page of the go.cd website. + If you are not redirected in a couple of seconds please click here + + + + diff --git a/pr-1714/test-drive-gocd.html b/pr-1714/test-drive-gocd.html new file mode 100644 index 000000000..f91b09dcc --- /dev/null +++ b/pr-1714/test-drive-gocd.html @@ -0,0 +1,197 @@ + + + + + + + + + + + + + + + + Test Drive GoCD + + + + + + + + + +
+
+ + + +
+ +
+ + +
+ +
+ +
+ +
+

Test Drive GoCD

+
+

Looking for a quick way to evaluate GoCD?
Try out our test drive below.

+

This is for evaluation purposes only, and not intended for production use. We’ve created a streamlined experience to help you quickly understand GoCD.

+
+ +
+
    +
  • +
    +

    + Step 1: Download and run it. +

    +
    +
    +
    +
    + + Loading… +
    +
    + +
    +
    +

    Bash

    + 
    
+                
+              
    
+
+
+              
    
+                
    PowerShell
    
+                
    
+                
+              
    
+            
    
+
+            
    
+          
    
+        
    • 
+
+        
  • 
+          
    
+            
    
+              Step 2: Try it out.
+            
    
+          
    
+          
    
+            
    Click the "New Pipeline" button in the upper-right corner of the screen to create and run your first pipeline in GoCD.
    
+            add pipeline screenshot
+          
    
+        
    • 
+
+        
  • 
+          
    
+            
    
+              Step 3: Move it to Production.
+            
    
+          
    
+          
    
+            
    Once you've finished exploring our test drive, we recommend downloading and installing GoCD following our introduction to setting up your own GoCD server.
    
+          
    
+        
    • 
+      

+    

+  

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/test-drive-gocd/index.html b/pr-1714/test-drive-gocd/index.html
new file mode 100644
index 000000000..627b0b3e1
--- /dev/null
+++ b/pr-1714/test-drive-gocd/index.html
@@ -0,0 +1,197 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Test Drive GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+
+

+
+

+
+  

+    
Test Drive GoCD

+    

+      
Looking for a quick way to evaluate GoCD? 
 Try out our test drive below.

+      
This is for evaluation purposes only, and not intended for production use. We’ve created a streamlined experience to help you quickly understand GoCD.

+    

+
+    

+      
    
+        
  • 
+          
    
+            
    
+              Step 1: Download and run it.
+            
    
+          
    
+          
    
+            
    
+              
    
+                
+                Loading…
+              
    
+            
    
+
+            
    
+              
    
+                
    Bash
    
+                
    
+                
+              
    
+
+
+              
    
+                
    PowerShell
    
+                
    
+                
+              
    
+            
    
+
+            
    
+          
    
+        
    • 
+
+        
  • 
+          
    
+            
    
+              Step 2: Try it out.
+            
    
+          
    
+          
    
+            
    Click the "New Pipeline" button in the upper-right corner of the screen to create and run your first pipeline in GoCD.
    
+            add pipeline screenshot
+          
    
+        
    • 
+
+        
  • 
+          
    
+            
    
+              Step 3: Move it to Production.
+            
    
+          
    
+          
    
+            
    Once you've finished exploring our test drive, we recommend downloading and installing GoCD following our introduction to setting up your own GoCD server.
    
+          
    
+        
    • 
+      

+    

+  

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/test-drive-gocd/try.ps1 b/pr-1714/test-drive-gocd/try.ps1
new file mode 100644
index 000000000..860812fbe
--- /dev/null
+++ b/pr-1714/test-drive-gocd/try.ps1
@@ -0,0 +1,148 @@
+param($url)
+
+try {
+  [System.Reflection.Assembly]::LoadWithPartialName("System.Net.Cache")
+} catch {
+}
+
+function Main {
+  param($url)
+
+  $filename = [io.path]::GetFileName($url)
+  $install_dir = $("$filename" -replace '-([^-]+)\.zip$')
+
+  Emph 'Welcome to the GoCD Test Drive'
+  ''
+
+  $filehash=$(try { WebGetString "$url" } catch { Die "Could not retrieve checksum at: ${url}.sha256" })
+
+  If ([string]::IsNullOrEmpty("$filehash")) {
+    Die "Could not retrieve checksum at: ${url}.sha256"
+  }
+
+  Emph "Checking dependencies..."
+  ''
+
+  if ((Test-Path "$filename" -PathType Leaf) -and (Verify "$filename" "$filehash")) {
+    "Cached ${filename} matches checksum; no need to freshen the download"
+  } else {
+    if (Test-Path "$filename" -PathType Container) {
+      Die "You have a directory named ${filename}; please remove this before running the GoCD Test Drive"
+    }
+
+    'Fetching GoCD...'
+    try { (WebGet "$url" "$filename") } catch { Die "Failed to download $url" }
+
+    if (-not (Verify "$filename" "$filehash")) {
+      Die "Downloaded file ""${filename}"" does not match checksum ${filehash}!"
+    }
+  }
+
+  Emph "Unpacking archive ${filename}"
+
+  try {
+    # Expand-Archive is not available in Server 2012 and Windows 8.1 be default
+    [System.Reflection.Assembly]::LoadWithPartialName("System.IO.Compression.FileSystem") | Out-Null
+    [System.IO.Compression.ZipFile]::ExtractToDirectory($(Join-Path -Path $(Get-Location) -ChildPath $filename), $(Get-Location))
+  } catch {
+    "Failed to unpack archive ${filename}"
+  }
+
+  if (-not (Test-Path "$install_dir" -PathType Container)) {
+    Die "Did not unpack to the expected folder: ${install_dir}"
+  }
+
+  Emph "Entering directory ${install_dir}"
+  Push-Location -Path "$install_dir"
+
+  try {
+    if (Test-Path "run-gocd" -PathType Leaf) {
+      Emph "Executing run-gocd"
+
+      # We're on Unix
+      if (Get-Command chmod) {
+        chmod a+rx "./run-gocd"
+        if (Test-Path "./packages/jre/bin" -PathType Container) {
+          chmod -R a+rx "./packages/jre/bin"
+        }
+      }
+
+      ./run-gocd
+    } elseif (Test-Path "run-gocd.exe" -PathType Leaf) {
+      Emph "Executing run-gocd.exe"
+      ./run-gocd.exe
+    } else {
+      Die "Unpacked archive does not contain run-gocd executable!"
+    }
+  } finally {
+    Pop-Location
+  }
+}
+
+function WebGet {
+  param($url, $file)
+
+  "Fetching $url"
+
+  $uri = New-Object "System.Uri" "$url"
+  $req = [System.Net.HttpWebRequest]::Create($uri)
+  $req.set_Timeout(15000)
+  $res = $req.GetResponse()
+
+  # get the file length
+  $total = [System.Math]::Floor($res.get_ContentLength()/1024)
+
+  $rstr = $res.GetResponseStream()
+
+  # open the destination file stream
+  $dst = New-Object -TypeName System.IO.FileStream -ArgumentList $file, Create; $buf = New-Object byte[] 10KB
+  $len = $rstr.Read($buf, 0, $buf.length)
+  $soFar = $len
+
+  while ($len -gt 0) {
+    $dst.Write($buf, 0, $len)
+    $len = $rstr.Read($buf, 0, $buf.length)
+    $soFar = $soFar + $len
+
+    [System.Console]::CursorLeft = 0
+    [System.Console]::Write("Downloaded {0}K of {1}K", [System.Math]::Floor($soFar/1024), $total)
+  }
+
+  "`nDownload complete: $file"
+  $dst.Flush()
+  $dst.Close()
+  $dst.Dispose()
+  $rstr.Dispose()
+}
+
+function WebGetString {
+  param($url)
+
+  $client=New-Object System.Net.WebClient
+  $client.CachePolicy = New-Object System.Net.Cache.RequestCachePolicy(6)
+
+  $($client.DownloadString("${url}.sha256") | ForEach-Object { $_.split(" ")[0] })
+}
+
+function Die {
+  Write-Error "$args"
+  break
+}
+
+function Emph {
+  Write-Host "$args" -fore green
+}
+
+function Verify {
+  param($file, $hash)
+
+  $calculated = $(Get-FileHash -Path "$file" -Algorithm SHA256 | Select -ExpandProperty Hash)
+
+  return "$hash" -eq "$calculated"
+}
+
+If ($PSBoundParameters.Count -eq 0) {
+  Die 'You must provide a URL'
+}
+
+Main $url
diff --git a/pr-1714/test-drive-gocd/try.sh b/pr-1714/test-drive-gocd/try.sh
new file mode 100644
index 000000000..7e83a2e85
--- /dev/null
+++ b/pr-1714/test-drive-gocd/try.sh
@@ -0,0 +1,130 @@
+#!/bin/bash
+
+set -e
+
+use_colors=$(type tput &> /dev/null && test "$(tput -T "$TERM" colors)" -ge 8 && echo "yes" || echo "no")
+
+function main() {
+  if [ $# -ne 1 ]; then
+    die "This script requires a URL"
+  fi
+
+  prerequisites unzip curl basename cut sed
+
+  local url="$1"
+  local filename=$(basename "$url")
+  local fileparts=(${filename//-/ })
+  local install_dir=$(IFS=- ; echo "${fileparts[*]:0:4}")
+
+  local filehash=$(read_url "${url}.sha256" | cut -f 1 -d " ")
+
+  emph "Welcome to the GoCD Test Drive"
+  echo ""
+
+  if [ -z "$filehash" ]; then
+    die "Could not retrieve checksum at: ${url}.sha256"
+  fi
+
+  emph "Checking dependencies..."
+  echo ""
+
+  if test -f "$filename" && verify "$filename" "$filehash"; then
+    echo "Cached ${filename} matches checksum; no need to freshen the download"
+  else
+    if [ -d "$filename" ]; then
+      die "You have a directory named ${filename}; please remove this before running the GoCD Test Drive"
+    fi
+
+    echo "Fetching GoCD..."
+
+    download "$url" "$filename" || die "Failed to download $url"
+    verify "$filename" "$filehash" || die "Downloaded file \"${filename}\" does not match checksum ${filehash}!"
+  fi
+
+  emph "Unpacking archive ${filename}"
+  unzip -q -o "$filename" || die "Failed to unpack archive ${filename}"
+
+  test -d "$install_dir" || die "Did not unpack to the expected folder: ${install_dir}"
+
+  emph "Entering directory ${install_dir}"
+  cd "$install_dir"
+
+  if [ -f run-gocd ]; then
+    emph "Executing run-gocd"
+    chmod a+rx run-gocd && ./run-gocd
+  elif [ -f run-gocd.exe ]; then
+    # running bash in Windows?
+    emph "Executing run-gocd.exe"
+    chmod a+rx run-gocd.exe && ./run-gocd.exe
+  else
+    die "Unpacked archive does not contain run-gocd executable!"
+  fi
+}
+
+function prerequisites() {
+  for cmd in $@; do
+    if ! type "$cmd" &> /dev/null; then
+      die "This script requires ${cmd}"
+    fi
+  done
+}
+
+function read_url() {
+  local url="$1"
+  curl -fsSL "$url"
+}
+
+function download() {
+  local url="$1"
+  local file="$2"
+
+  curl -fSL "$url" -o "$file"
+}
+
+function verify() {
+  local file="$1"
+  local hash="$2"
+
+  if type shasum &> /dev/null; then
+    [ "$hash" = $(shasum -a 256 "$file" | cut -d " " -f 1) ] || return 1
+  elif type sha &> /dev/null; then
+    [ "$hash" = $(sha -a 256 "$file" | cut -d " " -f 1) ] || return 1
+  elif type sha256sum &> /dev/null; then
+    [ "$hash" = $(sha256sum "$file" | cut -d " " -f 1) ] || return 1
+  elif type openssl &> /dev/null; then
+    [ "$hash" = $(openssl dgst -sha256 "$file" | cut -d " " -f 2) ] || return 1
+  else
+    warn "[WARNING] Unable to verify SHA-256 because you don't have \`shasum\`, \`sha256sum\`, \`sha\`, or \`openssl\` installed."
+  fi
+}
+
+function emph() {
+  if [ "yes" = "$use_colors" ]; then
+    echo -e "\033[1;32m$*\033[0m"
+  else
+    echo "$*"
+  fi
+}
+
+function warn() {
+  if [ "yes" = "$use_colors" ]; then
+    echo -e "\033[1;33m$*\033[0m" >&2
+  else
+    echo "$*" >&2
+  fi
+}
+
+function yell() {
+  if [ "yes" = "$use_colors" ]; then
+    echo -e "\033[37;41m$*\033[0m" >&2
+  else
+    echo "$*" >&2
+  fi
+}
+
+function die() {
+  yell $@
+  exit 1
+}
+
+main $@
diff --git a/pr-1714/thoughtworks-support-services-general-terms b/pr-1714/thoughtworks-support-services-general-terms
new file mode 100644
index 000000000..9e08f808c
--- /dev/null
+++ b/pr-1714/thoughtworks-support-services-general-terms
@@ -0,0 +1,15 @@
+
+
+  
+    
+    
+  
+  
+    You will be redirected to the enterprise/thoughtworks-support-services-general-terms.html page of the go.cd website.
+    If you are not redirected in a couple of seconds please click here
+    
+  
+
+
diff --git a/pr-1714/twit.html b/pr-1714/twit.html
new file mode 100644
index 000000000..7c3f921b2
--- /dev/null
+++ b/pr-1714/twit.html
@@ -0,0 +1,15 @@
+
+
+  
+    
+    
+  
+  
+    You will be redirected to the ./?utm_campaign=twit_podcast_q1_2017&utm_medium=podcast_twit&utm_source=podcast_twit&utm_content=go_cd&utm_term= page of the go.cd website.
+    If you are not redirected in a couple of seconds please click here
+    
+  
+
+
diff --git a/pr-1714/twit/index.html b/pr-1714/twit/index.html
new file mode 100644
index 000000000..de498ea89
--- /dev/null
+++ b/pr-1714/twit/index.html
@@ -0,0 +1,15 @@
+
+
+  
+    
+    
+  
+  
+    You will be redirected to the ../?utm_campaign=twit_podcast_q1_2017&utm_medium=podcast_twit&utm_source=podcast_twit&utm_content=go_cd&utm_term= page of the go.cd website.
+    If you are not redirected in a couple of seconds please click here
+    
+  
+
+
diff --git a/pr-1714/version.txt b/pr-1714/version.txt
new file mode 100644
index 000000000..86af41c44
--- /dev/null
+++ b/pr-1714/version.txt
@@ -0,0 +1,9 @@
+Last updated: 2024-08-09 12:56:41 +0000
+
+Latest commit:
+    commit 4aab051fbac2e20da8a0fae5e67228a7c075ddcf
+    Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
+    Date:   Fri Aug 9 12:55:26 2024 +0000
+    
+        Merge de138c7ad3de8d9b46c9569df13c7329447d1c81 into dcca4504c962435cd1e02b6e19adfbe6d977fc32
+    
diff --git a/pr-1714/videos.html b/pr-1714/videos.html
new file mode 100644
index 000000000..b7d2eafcb
--- /dev/null
+++ b/pr-1714/videos.html
@@ -0,0 +1,193 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Introduction to GoCD | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+    
+  

+

+

+

+  

+    

+      

+        

+          Fan Out &amp; Fan In
+          
Fan Out & Fan In

+        

+      

+    

+    

+      

+        

+          Failed Smoke Test
+          
Failed Smoke Test

+        

+      

+    

+    

+      

+        

+          Command Repo
+          
Command Repo

+        

+      

+    

+    

+      

+        

+          The Value Stream Map
+          
The Value Stream Map

+        

+      

+    

+    

+      

+        

+          Pipeline Visibility
+          
Pipeline Visibility

+        

+      

+    

+    

+      

+        

+          Fundamental Concepts
+          
Fundamental Concepts

+        

+      

+    

+    

+      

+        
+        

+          Linking To Dependencies
+          
Linking To Dependencies

+        

+      

+    

+  

+

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-command-repo.html b/pr-1714/videos/go-command-repo.html
new file mode 100644
index 000000000..23359b990
--- /dev/null
+++ b/pr-1714/videos/go-command-repo.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Command Repo | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Command Repo

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-command-repo/index.html b/pr-1714/videos/go-command-repo/index.html
new file mode 100644
index 000000000..07aeb7eb8
--- /dev/null
+++ b/pr-1714/videos/go-command-repo/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Command Repo | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Command Repo

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-failed-smoke-test.html b/pr-1714/videos/go-failed-smoke-test.html
new file mode 100644
index 000000000..bca1073ce
--- /dev/null
+++ b/pr-1714/videos/go-failed-smoke-test.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Failed Smoke Test | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Failed Smoke Test

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-failed-smoke-test/index.html b/pr-1714/videos/go-failed-smoke-test/index.html
new file mode 100644
index 000000000..fd2cd9749
--- /dev/null
+++ b/pr-1714/videos/go-failed-smoke-test/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Failed Smoke Test | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Failed Smoke Test

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-fan-out-fan.html b/pr-1714/videos/go-fan-out-fan.html
new file mode 100644
index 000000000..1c8d671f6
--- /dev/null
+++ b/pr-1714/videos/go-fan-out-fan.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Fan-out and Fan-in | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Fan-out & Fan-in

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-fan-out-fan/index.html b/pr-1714/videos/go-fan-out-fan/index.html
new file mode 100644
index 000000000..9b5a53652
--- /dev/null
+++ b/pr-1714/videos/go-fan-out-fan/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Fan-out and Fan-in | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Fan-out & Fan-in

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-fundamental-concepts.html b/pr-1714/videos/go-fundamental-concepts.html
new file mode 100644
index 000000000..56ddd6e54
--- /dev/null
+++ b/pr-1714/videos/go-fundamental-concepts.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Fundamental Concepts | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Fundamental Concepts

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-fundamental-concepts/index.html b/pr-1714/videos/go-fundamental-concepts/index.html
new file mode 100644
index 000000000..04494273c
--- /dev/null
+++ b/pr-1714/videos/go-fundamental-concepts/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Videos - Fundamental Concepts | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Fundamental Concepts

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-linking-dependencies.html b/pr-1714/videos/go-linking-dependencies.html
new file mode 100644
index 000000000..1024fc52c
--- /dev/null
+++ b/pr-1714/videos/go-linking-dependencies.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Dependency Management, Deployment Pipeline Linking and Value Stream Map | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Linking to Dependencies

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-linking-dependencies/index.html b/pr-1714/videos/go-linking-dependencies/index.html
new file mode 100644
index 000000000..62f07a0a6
--- /dev/null
+++ b/pr-1714/videos/go-linking-dependencies/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Dependency Management, Deployment Pipeline Linking and Value Stream Map | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Linking to Dependencies

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-pipeline-visibility.html b/pr-1714/videos/go-pipeline-visibility.html
new file mode 100644
index 000000000..316ce6179
--- /dev/null
+++ b/pr-1714/videos/go-pipeline-visibility.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Pipeline Visibility | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Pipeline Visibility

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-pipeline-visibility/index.html b/pr-1714/videos/go-pipeline-visibility/index.html
new file mode 100644
index 000000000..c21b86524
--- /dev/null
+++ b/pr-1714/videos/go-pipeline-visibility/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Pipeline Visibility | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Pipeline Visibility

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-value-stream-map.html b/pr-1714/videos/go-value-stream-map.html
new file mode 100644
index 000000000..bbfb18cb3
--- /dev/null
+++ b/pr-1714/videos/go-value-stream-map.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Value Stream Map | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Value Stream Map

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/go-value-stream-map/index.html b/pr-1714/videos/go-value-stream-map/index.html
new file mode 100644
index 000000000..ede3d5fa4
--- /dev/null
+++ b/pr-1714/videos/go-value-stream-map/index.html
@@ -0,0 +1,139 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Value Stream Map | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+  

+    
Value Stream Map

+    
+  

+

+

+

+  ← Back to Videos
+  
+
+

+

+
+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/videos/index.html b/pr-1714/videos/index.html
new file mode 100644
index 000000000..af065ebf4
--- /dev/null
+++ b/pr-1714/videos/index.html
@@ -0,0 +1,193 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Introduction to GoCD | GoCD Videos
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+    
+  

+

+

+

+  

+    

+      

+        

+          Fan Out &amp; Fan In
+          
Fan Out & Fan In

+        

+      

+    

+    

+      

+        

+          Failed Smoke Test
+          
Failed Smoke Test

+        

+      

+    

+    

+      

+        

+          Command Repo
+          
Command Repo

+        

+      

+    

+    

+      

+        

+          The Value Stream Map
+          
The Value Stream Map

+        

+      

+    

+    

+      

+        

+          Pipeline Visibility
+          
Pipeline Visibility

+        

+      

+    

+    

+      

+        

+          Fundamental Concepts
+          
Fundamental Concepts

+        

+      

+    

+    

+      

+        
+        

+          Linking To Dependencies
+          
Linking To Dependencies

+        

+      

+    

+  

+

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/why-gocd.html b/pr-1714/why-gocd.html
new file mode 100644
index 000000000..4adf47257
--- /dev/null
+++ b/pr-1714/why-gocd.html
@@ -0,0 +1,340 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Features and Benefits | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+    
+  

+

+

+  

+    

+      

+        

+          

+            Model complex workflows and deployment pipelines
+          

+        

+        

+          
 Model complex workflows

+          

+            With its parallel and sequential execution, GoCD can easily configure dependencies for fast feedback and
+            on-demand deployment. Its fan-in/fan-out dependency management always does the "right thing," avoiding
+            spurious builds.
+          

+        

+        

+      

+      

+        

+          

+            Promote trusted artifacts
+          

+        

+        

+          
Promote trusted artifacts

+          

+            Every pipeline instance is anchored to a particular changeset. GoCD makes it easy to pass once-built
+            binaries between stages so you know exactly what's being deployed and that the binary has been tested.
+          

+        

+        

+      

+      

+        

+          

+            Visualize your workflow
+          

+        

+        

+          
See how your workflow really works 

+          

+            GoCD's real power is in the visibility it provides over your end-to-end workflow. GoCD's Value Stream Map
+            lets you track a change from commit to deploy at a glance. And when things go wrong, it's easy to see both
+            the upstream cause and the downstream effects.
+          

+        

+        

+      

+      

+        

+          

+            Deploy any version at any time
+          

+        

+        

+          
Deploy any version, any time

+          

+            GoCD's manual triggers allow you to deploy any known good version of your application to wherever you
+            like. This increases reliability of pushing to production, and empowers QA teams with self-service
+            environments. And, if necessary, it's securable and auditable.
+          

+        

+        

+      

+      

+        

+          

+            Run and grok your tests
+          

+        

+        

+          
Run and grok your tests

+          

+            Verification is a key piece of any deployment pipeline. GoCD will execute tests written in most languages or
+            frameworks. GoCD's agent grid provides parallel and cross-platform execution. GoCD's test reporting will tell
+            you in exactly which changeset and on which platform a test started breaking, which comes in extremely handy
+            when fixing a complex broken build.
+          

+        

+        

+      

+      

+        

+  

+    Try GoCD today with our new Test Drive experience
+  

+  START NOW
+

+
+      

+      

+        

+          

+            Compare builds
+          

+        

+        

+          
Compare builds

+          

+            GoCD's compare builds feature can provide a simple bill of materials for any deployment. Perhaps more
+            powerful is its ability to compare the content - both files and commit messages - across any two arbitrary
+            builds. This is invaluable when troubleshooting a broken pipeline.
+          

+        

+        

+      

+      

+        

+          

+            Eliminate bottlenecks
+          

+        

+        

+          
Eliminate bottlenecks

+          

+            GoCD's agent grid eliminates bottlenecks, providing trivial parallel execution across pipelines, platforms,
+            versions, branches, etc.
+          

+        

+        

+      

+      

+        

+          

+            Keep pipeline configuration tidy
+          

+        

+        

+          
Keep configuration tidy

+          

+            Easily reuse pipeline configurations via GoCD's template system. This makes managing pipelines for versions
+            and branches easy as pie.
+          

+        

+        

+      

+      

+        

+          

+            Trust your team
+          

+        

+        

+          
Trust your team; be responsible

+          

+            While most enterprise applications go overboard with their permission model, GoCD seeks to provide just
+            enough. In particular, GoCD supports auditable deployment and can delegate the configuration of pipelines to
+            users without full-blown admin privileges.
+          

+        

+        

+      

+      

+        

+          

+            GoCD open source plugins
+          

+        

+        

+          
Plugins

+          

+            GoCD has extension points for which plugins can be created. There are numerous plugins already available, or if you don't see what you need, you can write your own.
+          

+        

+        

+      

+    

+  

+    
Screenshots

+    

+      

+        

+          
+            Dashboard
+          
+          
Dashboard

+        

+      

+      

+        

+          
+            Console with timestamp
+          
+          
Console with timestamp

+        

+      

+    

+    

+      

+        

+          
+            Agents
+          
+          
Agents

+        

+      

+      

+        

+          
+            Value stream map
+          
+          
Value stream map

+        

+      

+    

+  

+

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+
diff --git a/pr-1714/why-gocd/index.html b/pr-1714/why-gocd/index.html
new file mode 100644
index 000000000..f75f1d6c6
--- /dev/null
+++ b/pr-1714/why-gocd/index.html
@@ -0,0 +1,340 @@
+
+
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+    Features and Benefits | GoCD
+    
+    
+    
+    
+    
+    
+  
+
+  
+    

+  

+    
+    
+    
+  

+
+

+
+
+    

+  

+    
+  

+

+

+  

+    

+      

+        

+          

+            Model complex workflows and deployment pipelines
+          

+        

+        

+          
 Model complex workflows

+          

+            With its parallel and sequential execution, GoCD can easily configure dependencies for fast feedback and
+            on-demand deployment. Its fan-in/fan-out dependency management always does the "right thing," avoiding
+            spurious builds.
+          

+        

+        

+      

+      

+        

+          

+            Promote trusted artifacts
+          

+        

+        

+          
Promote trusted artifacts

+          

+            Every pipeline instance is anchored to a particular changeset. GoCD makes it easy to pass once-built
+            binaries between stages so you know exactly what's being deployed and that the binary has been tested.
+          

+        

+        

+      

+      

+        

+          

+            Visualize your workflow
+          

+        

+        

+          
See how your workflow really works 

+          

+            GoCD's real power is in the visibility it provides over your end-to-end workflow. GoCD's Value Stream Map
+            lets you track a change from commit to deploy at a glance. And when things go wrong, it's easy to see both
+            the upstream cause and the downstream effects.
+          

+        

+        

+      

+      

+        

+          

+            Deploy any version at any time
+          

+        

+        

+          
Deploy any version, any time

+          

+            GoCD's manual triggers allow you to deploy any known good version of your application to wherever you
+            like. This increases reliability of pushing to production, and empowers QA teams with self-service
+            environments. And, if necessary, it's securable and auditable.
+          

+        

+        

+      

+      

+        

+          

+            Run and grok your tests
+          

+        

+        

+          
Run and grok your tests

+          

+            Verification is a key piece of any deployment pipeline. GoCD will execute tests written in most languages or
+            frameworks. GoCD's agent grid provides parallel and cross-platform execution. GoCD's test reporting will tell
+            you in exactly which changeset and on which platform a test started breaking, which comes in extremely handy
+            when fixing a complex broken build.
+          

+        

+        

+      

+      

+        

+  

+    Try GoCD today with our new Test Drive experience
+  

+  START NOW
+

+
+      

+      

+        

+          

+            Compare builds
+          

+        

+        

+          
Compare builds

+          

+            GoCD's compare builds feature can provide a simple bill of materials for any deployment. Perhaps more
+            powerful is its ability to compare the content - both files and commit messages - across any two arbitrary
+            builds. This is invaluable when troubleshooting a broken pipeline.
+          

+        

+        

+      

+      

+        

+          

+            Eliminate bottlenecks
+          

+        

+        

+          
Eliminate bottlenecks

+          

+            GoCD's agent grid eliminates bottlenecks, providing trivial parallel execution across pipelines, platforms,
+            versions, branches, etc.
+          

+        

+        

+      

+      

+        

+          

+            Keep pipeline configuration tidy
+          

+        

+        

+          
Keep configuration tidy

+          

+            Easily reuse pipeline configurations via GoCD's template system. This makes managing pipelines for versions
+            and branches easy as pie.
+          

+        

+        

+      

+      

+        

+          

+            Trust your team
+          

+        

+        

+          
Trust your team; be responsible

+          

+            While most enterprise applications go overboard with their permission model, GoCD seeks to provide just
+            enough. In particular, GoCD supports auditable deployment and can delegate the configuration of pipelines to
+            users without full-blown admin privileges.
+          

+        

+        

+      

+      

+        

+          

+            GoCD open source plugins
+          

+        

+        

+          
Plugins

+          

+            GoCD has extension points for which plugins can be created. There are numerous plugins already available, or if you don't see what you need, you can write your own.
+          

+        

+        

+      

+    

+  

+    
Screenshots

+    

+      

+        

+          
+            Dashboard
+          
+          
Dashboard

+        

+      

+      

+        

+          
+            Console with timestamp
+          
+          
Console with timestamp

+        

+      

+    

+    

+      

+        

+          
+            Agents
+          
+          
Agents

+        

+      

+      

+        

+          
+            Value stream map
+          
+          
Value stream map

+        

+      

+    

+  

+

+

+
+    
+
+    

+      

+      

+      
✖
+      

+    

+
+  
+