diff --git a/pr-1683/.nojekyll b/pr-1683/.nojekyll new file mode 100644 index 000000000..e69de29bb diff --git a/pr-1683/101.html b/pr-1683/101.html new file mode 100644 index 000000000..314b7e9f0 --- /dev/null +++ b/pr-1683/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-1683/101/index.html b/pr-1683/101/index.html new file mode 100644 index 000000000..7baca7c37 --- /dev/null +++ b/pr-1683/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-1683/2014.html b/pr-1683/2014.html new file mode 100644 index 000000000..9ce1d01fc --- /dev/null +++ b/pr-1683/2014.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 1 of 3

+ + + + +

Next page

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

Archive for + Feb 2014 +

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

Archive for + Feb 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/02/24/build-promotion-go.html b/pr-1683/2014/02/24/build-promotion-go.html new file mode 100644 index 000000000..ee794b55e --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/build-promotion-go/index.html b/pr-1683/2014/02/24/build-promotion-go/index.html new file mode 100644 index 000000000..590c59ec8 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/deploy-package-not-just-tag-branch-or-binary.html b/pr-1683/2014/02/24/deploy-package-not-just-tag-branch-or-binary.html new file mode 100644 index 000000000..43d4e0208 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/deploy-package-not-just-tag-branch-or-binary/index.html b/pr-1683/2014/02/24/deploy-package-not-just-tag-branch-or-binary/index.html new file mode 100644 index 000000000..ab5cec11f --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/go-template-permissions.html b/pr-1683/2014/02/24/go-template-permissions.html new file mode 100644 index 000000000..115464ee3 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/go-template-permissions/index.html b/pr-1683/2014/02/24/go-template-permissions/index.html new file mode 100644 index 000000000..6fad546ee --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware.html b/pr-1683/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware.html new file mode 100644 index 000000000..ff187c13b --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/index.html b/pr-1683/2014/02/24/how-implement-continuous-delivery-enterprise-java-middleware/index.html new file mode 100644 index 000000000..8b0ad18ee --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/how-peg-your-pipeline-dependency-version.html b/pr-1683/2014/02/24/how-peg-your-pipeline-dependency-version.html new file mode 100644 index 000000000..0e6d6388e --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/how-peg-your-pipeline-dependency-version/index.html b/pr-1683/2014/02/24/how-peg-your-pipeline-dependency-version/index.html new file mode 100644 index 000000000..387c1c423 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/index.html b/pr-1683/2014/02/24/index.html new file mode 100644 index 000000000..db75d9261 --- /dev/null +++ b/pr-1683/2014/02/24/index.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/02/24/model-everything-fail-fast.html b/pr-1683/2014/02/24/model-everything-fail-fast.html new file mode 100644 index 000000000..43b4becf3 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/model-everything-fail-fast/index.html b/pr-1683/2014/02/24/model-everything-fail-fast/index.html new file mode 100644 index 000000000..72d2c0d33 --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/tracing-our-path-production.html b/pr-1683/2014/02/24/tracing-our-path-production.html new file mode 100644 index 000000000..3cb2699ad --- /dev/null +++ b/pr-1683/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-1683/2014/02/24/tracing-our-path-production/index.html b/pr-1683/2014/02/24/tracing-our-path-production/index.html new file mode 100644 index 000000000..c477ed3bf --- /dev/null +++ b/pr-1683/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-1683/2014/02/25.html b/pr-1683/2014/02/25.html new file mode 100644 index 000000000..a606b4595 --- /dev/null +++ b/pr-1683/2014/02/25.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 25 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/02/25/go-is-now-open-source.html b/pr-1683/2014/02/25/go-is-now-open-source.html new file mode 100644 index 000000000..16ddeb2e6 --- /dev/null +++ b/pr-1683/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-1683/2014/02/25/go-is-now-open-source/index.html b/pr-1683/2014/02/25/go-is-now-open-source/index.html new file mode 100644 index 000000000..6fbd6f714 --- /dev/null +++ b/pr-1683/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-1683/2014/02/25/go-moving-to-open-source.html b/pr-1683/2014/02/25/go-moving-to-open-source.html new file mode 100644 index 000000000..9711e97f0 --- /dev/null +++ b/pr-1683/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-1683/2014/02/25/go-moving-to-open-source/index.html b/pr-1683/2014/02/25/go-moving-to-open-source/index.html new file mode 100644 index 000000000..30e7d145d --- /dev/null +++ b/pr-1683/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-1683/2014/02/25/index.html b/pr-1683/2014/02/25/index.html new file mode 100644 index 000000000..42a2dd988 --- /dev/null +++ b/pr-1683/2014/02/25/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 25 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/02/25/why-we-need-to-practice-cd.html b/pr-1683/2014/02/25/why-we-need-to-practice-cd.html new file mode 100644 index 000000000..fb8f78358 --- /dev/null +++ b/pr-1683/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-1683/2014/02/25/why-we-need-to-practice-cd/index.html b/pr-1683/2014/02/25/why-we-need-to-practice-cd/index.html new file mode 100644 index 000000000..5400dccd1 --- /dev/null +++ b/pr-1683/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-1683/2014/02/index.html b/pr-1683/2014/02/index.html new file mode 100644 index 000000000..ef5e43c1f --- /dev/null +++ b/pr-1683/2014/02/index.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2014 +

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

Archive for + Mar 2014 +

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

Archive for + Mar 6 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/03/06/hello-world-with-go.html b/pr-1683/2014/03/06/hello-world-with-go.html new file mode 100644 index 000000000..359a07ff5 --- /dev/null +++ b/pr-1683/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-1683/2014/03/06/hello-world-with-go/index.html b/pr-1683/2014/03/06/hello-world-with-go/index.html new file mode 100644 index 000000000..6026681d3 --- /dev/null +++ b/pr-1683/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-1683/2014/03/06/index.html b/pr-1683/2014/03/06/index.html new file mode 100644 index 000000000..22a282887 --- /dev/null +++ b/pr-1683/2014/03/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 6 2014 +

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

Archive for + Mar 10 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/03/10/go-webinar-recording.html b/pr-1683/2014/03/10/go-webinar-recording.html new file mode 100644 index 000000000..835856e05 --- /dev/null +++ b/pr-1683/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-1683/2014/03/10/go-webinar-recording/index.html b/pr-1683/2014/03/10/go-webinar-recording/index.html new file mode 100644 index 000000000..7d0bcac12 --- /dev/null +++ b/pr-1683/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-1683/2014/03/10/index.html b/pr-1683/2014/03/10/index.html new file mode 100644 index 000000000..2ce171a6b --- /dev/null +++ b/pr-1683/2014/03/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 10 2014 +

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

Archive for + Mar 2014 +

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

Archive for + Apr 2014 +

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

Archive for + Apr 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/04/24/Go_14_1_announced.html b/pr-1683/2014/04/24/Go_14_1_announced.html new file mode 100644 index 000000000..22cdfb01d --- /dev/null +++ b/pr-1683/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-1683/2014/04/24/Go_14_1_announced/index.html b/pr-1683/2014/04/24/Go_14_1_announced/index.html new file mode 100644 index 000000000..236451ae8 --- /dev/null +++ b/pr-1683/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-1683/2014/04/24/agent-bootstrapper-upgrade-for-plugins.html b/pr-1683/2014/04/24/agent-bootstrapper-upgrade-for-plugins.html new file mode 100644 index 000000000..6681c984f --- /dev/null +++ b/pr-1683/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-1683/2014/04/24/agent-bootstrapper-upgrade-for-plugins/index.html b/pr-1683/2014/04/24/agent-bootstrapper-upgrade-for-plugins/index.html new file mode 100644 index 000000000..d8fcc4a53 --- /dev/null +++ b/pr-1683/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-1683/2014/04/24/index.html b/pr-1683/2014/04/24/index.html new file mode 100644 index 000000000..587a30907 --- /dev/null +++ b/pr-1683/2014/04/24/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 24 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/04/24/source-code-for-go-now-available.html b/pr-1683/2014/04/24/source-code-for-go-now-available.html new file mode 100644 index 000000000..092bce979 --- /dev/null +++ b/pr-1683/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-1683/2014/04/24/source-code-for-go-now-available/index.html b/pr-1683/2014/04/24/source-code-for-go-now-available/index.html new file mode 100644 index 000000000..f927dc160 --- /dev/null +++ b/pr-1683/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-1683/2014/04/index.html b/pr-1683/2014/04/index.html new file mode 100644 index 000000000..6fb2e4ef0 --- /dev/null +++ b/pr-1683/2014/04/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 2014 +

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

Archive for + May 2014 +

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

Archive for + May 18 2014 +

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

Archive for + May 18 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/05/18/manage-agents-with-docker.html b/pr-1683/2014/05/18/manage-agents-with-docker.html new file mode 100644 index 000000000..a8dfe8186 --- /dev/null +++ b/pr-1683/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-1683/2014/05/18/manage-agents-with-docker/index.html b/pr-1683/2014/05/18/manage-agents-with-docker/index.html new file mode 100644 index 000000000..341461765 --- /dev/null +++ b/pr-1683/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-1683/2014/05/index.html b/pr-1683/2014/05/index.html new file mode 100644 index 000000000..ffa257d3c --- /dev/null +++ b/pr-1683/2014/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2014 +

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

Archive for + Jun 2014 +

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

Archive for + Jun 5 2014 +

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

Archive for + Jun 5 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/06/05/using-go-cd-with-custom-certificates.html b/pr-1683/2014/06/05/using-go-cd-with-custom-certificates.html new file mode 100644 index 000000000..58239710c --- /dev/null +++ b/pr-1683/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-1683/2014/06/05/using-go-cd-with-custom-certificates/index.html b/pr-1683/2014/06/05/using-go-cd-with-custom-certificates/index.html new file mode 100644 index 000000000..bd0bd34f7 --- /dev/null +++ b/pr-1683/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-1683/2014/06/index.html b/pr-1683/2014/06/index.html new file mode 100644 index 000000000..a8208531d --- /dev/null +++ b/pr-1683/2014/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2014 +

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

Archive for + Jul 2014 +

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

Archive for + Jul 1 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/07/01/What-would-help-you.html b/pr-1683/2014/07/01/What-would-help-you.html new file mode 100644 index 000000000..48172a0e5 --- /dev/null +++ b/pr-1683/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-1683/2014/07/01/What-would-help-you/index.html b/pr-1683/2014/07/01/What-would-help-you/index.html new file mode 100644 index 000000000..9c0507f66 --- /dev/null +++ b/pr-1683/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-1683/2014/07/01/index.html b/pr-1683/2014/07/01/index.html new file mode 100644 index 000000000..4f5b2a634 --- /dev/null +++ b/pr-1683/2014/07/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 1 2014 +

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

Archive for + Jul 9 2014 +

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

Archive for + Jul 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/07/09/stopping-support-for-java-jdk-6.html b/pr-1683/2014/07/09/stopping-support-for-java-jdk-6.html new file mode 100644 index 000000000..49b4f434a --- /dev/null +++ b/pr-1683/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-1683/2014/07/09/stopping-support-for-java-jdk-6/index.html b/pr-1683/2014/07/09/stopping-support-for-java-jdk-6/index.html new file mode 100644 index 000000000..fbd4991f6 --- /dev/null +++ b/pr-1683/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-1683/2014/07/index.html b/pr-1683/2014/07/index.html new file mode 100644 index 000000000..620a34b5d --- /dev/null +++ b/pr-1683/2014/07/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2014 +

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

Archive for + Aug 2014 +

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

Archive for + Aug 7 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/08/07/go-webinar-recording.html b/pr-1683/2014/08/07/go-webinar-recording.html new file mode 100644 index 000000000..0dcea7d45 --- /dev/null +++ b/pr-1683/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-1683/2014/08/07/go-webinar-recording/index.html b/pr-1683/2014/08/07/go-webinar-recording/index.html new file mode 100644 index 000000000..27e4840b0 --- /dev/null +++ b/pr-1683/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-1683/2014/08/07/index.html b/pr-1683/2014/08/07/index.html new file mode 100644 index 000000000..1e1b7b979 --- /dev/null +++ b/pr-1683/2014/08/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 7 2014 +

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

Archive for + Aug 19 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/08/19/cloning-templates.html b/pr-1683/2014/08/19/cloning-templates.html new file mode 100644 index 000000000..a8bcdbe17 --- /dev/null +++ b/pr-1683/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-1683/2014/08/19/cloning-templates/index.html b/pr-1683/2014/08/19/cloning-templates/index.html new file mode 100644 index 000000000..21237f3c8 --- /dev/null +++ b/pr-1683/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-1683/2014/08/19/index.html b/pr-1683/2014/08/19/index.html new file mode 100644 index 000000000..f442468da --- /dev/null +++ b/pr-1683/2014/08/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 19 2014 +

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

Archive for + Aug 2014 +

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

Archive for + Oct 2014 +

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

Archive for + Oct 9 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/10/09/Distributed-Test-Execution.html b/pr-1683/2014/10/09/Distributed-Test-Execution.html new file mode 100644 index 000000000..b213cfedc --- /dev/null +++ b/pr-1683/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-1683/2014/10/09/Distributed-Test-Execution/index.html b/pr-1683/2014/10/09/Distributed-Test-Execution/index.html new file mode 100644 index 000000000..153cf6c4f --- /dev/null +++ b/pr-1683/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-1683/2014/10/09/Distrubuted-Test-Execution.html b/pr-1683/2014/10/09/Distrubuted-Test-Execution.html new file mode 100644 index 000000000..d062e8e61 --- /dev/null +++ b/pr-1683/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-1683/2014/10/09/Distrubuted-Test-Execution/index.html b/pr-1683/2014/10/09/Distrubuted-Test-Execution/index.html new file mode 100644 index 000000000..f58180b65 --- /dev/null +++ b/pr-1683/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-1683/2014/10/09/index.html b/pr-1683/2014/10/09/index.html new file mode 100644 index 000000000..cadfc452a --- /dev/null +++ b/pr-1683/2014/10/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 9 2014 +

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

Archive for + Oct 2014 +

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

Archive for + Nov 2014 +

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

Archive for + Nov 11 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/11/11/Go_14_3_announced.html b/pr-1683/2014/11/11/Go_14_3_announced.html new file mode 100644 index 000000000..3a0c117c8 --- /dev/null +++ b/pr-1683/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-1683/2014/11/11/Go_14_3_announced/index.html b/pr-1683/2014/11/11/Go_14_3_announced/index.html new file mode 100644 index 000000000..2637d4bef --- /dev/null +++ b/pr-1683/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-1683/2014/11/11/index.html b/pr-1683/2014/11/11/index.html new file mode 100644 index 000000000..1f0aff541 --- /dev/null +++ b/pr-1683/2014/11/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 11 2014 +

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

Archive for + Nov 14 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts.html b/pr-1683/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts.html new file mode 100644 index 000000000..188e99b34 --- /dev/null +++ b/pr-1683/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-1683/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/index.html b/pr-1683/2014/11/14/Go_14_3_issue_with_uploading_compressed_artifacts/index.html new file mode 100644 index 000000000..6518e31ad --- /dev/null +++ b/pr-1683/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-1683/2014/11/14/index.html b/pr-1683/2014/11/14/index.html new file mode 100644 index 000000000..a957e257c --- /dev/null +++ b/pr-1683/2014/11/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 14 2014 +

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

Archive for + Nov 21 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/11/21/go-webinar-recording.html b/pr-1683/2014/11/21/go-webinar-recording.html new file mode 100644 index 000000000..a9a04fbfb --- /dev/null +++ b/pr-1683/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-1683/2014/11/21/go-webinar-recording/index.html b/pr-1683/2014/11/21/go-webinar-recording/index.html new file mode 100644 index 000000000..01a285815 --- /dev/null +++ b/pr-1683/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-1683/2014/11/21/index.html b/pr-1683/2014/11/21/index.html new file mode 100644 index 000000000..cbbea6f4e --- /dev/null +++ b/pr-1683/2014/11/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 21 2014 +

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

Archive for + Nov 2014 +

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

Archive for + Dec 2014 +

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

Archive for + Dec 17 2014 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/12/17/Go_14_4_announced.html b/pr-1683/2014/12/17/Go_14_4_announced.html new file mode 100644 index 000000000..08d4040ea --- /dev/null +++ b/pr-1683/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-1683/2014/12/17/Go_14_4_announced/index.html b/pr-1683/2014/12/17/Go_14_4_announced/index.html new file mode 100644 index 000000000..fe5e7ae1f --- /dev/null +++ b/pr-1683/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-1683/2014/12/17/index.html b/pr-1683/2014/12/17/index.html new file mode 100644 index 000000000..a8002fed4 --- /dev/null +++ b/pr-1683/2014/12/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 17 2014 +

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

Archive for + Dec 2014 +

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

Archive for + 2014 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/page/2.html b/pr-1683/2014/page/2.html new file mode 100644 index 000000000..0c33795b4 --- /dev/null +++ b/pr-1683/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-1683/2014/page/2/index.html b/pr-1683/2014/page/2/index.html new file mode 100644 index 000000000..ae62d37ee --- /dev/null +++ b/pr-1683/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-1683/2014/page/3.html b/pr-1683/2014/page/3.html new file mode 100644 index 000000000..b55126750 --- /dev/null +++ b/pr-1683/2014/page/3.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2014 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2014/page/3/index.html b/pr-1683/2014/page/3/index.html new file mode 100644 index 000000000..5f0416279 --- /dev/null +++ b/pr-1683/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-1683/2015.html b/pr-1683/2015.html new file mode 100644 index 000000000..7f80d441c --- /dev/null +++ b/pr-1683/2015.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 1 of 3

+ + + + +

Next page

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

Archive for + Apr 2015 +

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

Archive for + Apr 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/04/23/Go_15_1_jdk7_announcement.html b/pr-1683/2015/04/23/Go_15_1_jdk7_announcement.html new file mode 100644 index 000000000..fe97a0d53 --- /dev/null +++ b/pr-1683/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-1683/2015/04/23/Go_15_1_jdk7_announcement/index.html b/pr-1683/2015/04/23/Go_15_1_jdk7_announcement/index.html new file mode 100644 index 000000000..383fe552b --- /dev/null +++ b/pr-1683/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-1683/2015/04/23/index.html b/pr-1683/2015/04/23/index.html new file mode 100644 index 000000000..f1a776128 --- /dev/null +++ b/pr-1683/2015/04/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 23 2015 +

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

Archive for + Apr 27 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/04/27/Feature-Branch-Support.html b/pr-1683/2015/04/27/Feature-Branch-Support.html new file mode 100644 index 000000000..cd35c5ac8 --- /dev/null +++ b/pr-1683/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-1683/2015/04/27/Feature-Branch-Support/index.html b/pr-1683/2015/04/27/Feature-Branch-Support/index.html new file mode 100644 index 000000000..a4c7010fb --- /dev/null +++ b/pr-1683/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-1683/2015/04/27/index.html b/pr-1683/2015/04/27/index.html new file mode 100644 index 000000000..601de0351 --- /dev/null +++ b/pr-1683/2015/04/27/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 27 2015 +

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

Archive for + Apr 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/04/29/Go_15_1_announced.html b/pr-1683/2015/04/29/Go_15_1_announced.html new file mode 100644 index 000000000..9ce083c3a --- /dev/null +++ b/pr-1683/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-1683/2015/04/29/Go_15_1_announced/index.html b/pr-1683/2015/04/29/Go_15_1_announced/index.html new file mode 100644 index 000000000..2cfe79f33 --- /dev/null +++ b/pr-1683/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-1683/2015/04/29/index.html b/pr-1683/2015/04/29/index.html new file mode 100644 index 000000000..6ad8dab1e --- /dev/null +++ b/pr-1683/2015/04/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 29 2015 +

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

Archive for + Apr 2015 +

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

Archive for + May 2015 +

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

Archive for + May 6 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/05/06/Getting-Started-Resources.html b/pr-1683/2015/05/06/Getting-Started-Resources.html new file mode 100644 index 000000000..8538edbe1 --- /dev/null +++ b/pr-1683/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-1683/2015/05/06/Getting-Started-Resources/index.html b/pr-1683/2015/05/06/Getting-Started-Resources/index.html new file mode 100644 index 000000000..7883b6955 --- /dev/null +++ b/pr-1683/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-1683/2015/05/06/index.html b/pr-1683/2015/05/06/index.html new file mode 100644 index 000000000..86440d495 --- /dev/null +++ b/pr-1683/2015/05/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 6 2015 +

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

Archive for + May 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/05/07/go-webinar-recording.html b/pr-1683/2015/05/07/go-webinar-recording.html new file mode 100644 index 000000000..0285ed21a --- /dev/null +++ b/pr-1683/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-1683/2015/05/07/go-webinar-recording/index.html b/pr-1683/2015/05/07/go-webinar-recording/index.html new file mode 100644 index 000000000..086b11975 --- /dev/null +++ b/pr-1683/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-1683/2015/05/07/index.html b/pr-1683/2015/05/07/index.html new file mode 100644 index 000000000..4e8af5641 --- /dev/null +++ b/pr-1683/2015/05/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 7 2015 +

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

Archive for + May 2015 +

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

Archive for + Jun 2015 +

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

Archive for + Jun 13 2015 +

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

Archive for + Jun 13 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/06/13/using-windows-powershell-tasks.html b/pr-1683/2015/06/13/using-windows-powershell-tasks.html new file mode 100644 index 000000000..8d5662bf1 --- /dev/null +++ b/pr-1683/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-1683/2015/06/13/using-windows-powershell-tasks/index.html b/pr-1683/2015/06/13/using-windows-powershell-tasks/index.html new file mode 100644 index 000000000..f67f08342 --- /dev/null +++ b/pr-1683/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-1683/2015/06/17.html b/pr-1683/2015/06/17.html new file mode 100644 index 000000000..db79f085f --- /dev/null +++ b/pr-1683/2015/06/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 17 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/06/17/Upcoming-API-Changes.html b/pr-1683/2015/06/17/Upcoming-API-Changes.html new file mode 100644 index 000000000..319c56dcd --- /dev/null +++ b/pr-1683/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-1683/2015/06/17/Upcoming-API-Changes/index.html b/pr-1683/2015/06/17/Upcoming-API-Changes/index.html new file mode 100644 index 000000000..e0c71b0d9 --- /dev/null +++ b/pr-1683/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-1683/2015/06/17/index.html b/pr-1683/2015/06/17/index.html new file mode 100644 index 000000000..b03b7ebef --- /dev/null +++ b/pr-1683/2015/06/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 17 2015 +

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

Archive for + Jun 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/06/18/authentication-end-point.html b/pr-1683/2015/06/18/authentication-end-point.html new file mode 100644 index 000000000..abfc4aa81 --- /dev/null +++ b/pr-1683/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-1683/2015/06/18/authentication-end-point/index.html b/pr-1683/2015/06/18/authentication-end-point/index.html new file mode 100644 index 000000000..1b830dbd7 --- /dev/null +++ b/pr-1683/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-1683/2015/06/18/index.html b/pr-1683/2015/06/18/index.html new file mode 100644 index 000000000..ed87b3971 --- /dev/null +++ b/pr-1683/2015/06/18/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/06/18/plugin-settings.html b/pr-1683/2015/06/18/plugin-settings.html new file mode 100644 index 000000000..708120124 --- /dev/null +++ b/pr-1683/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-1683/2015/06/18/plugin-settings/index.html b/pr-1683/2015/06/18/plugin-settings/index.html new file mode 100644 index 000000000..3e9f8e1ef --- /dev/null +++ b/pr-1683/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-1683/2015/06/23.html b/pr-1683/2015/06/23.html new file mode 100644 index 000000000..6663a17e8 --- /dev/null +++ b/pr-1683/2015/06/23.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 23 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/06/23/hardly-anyone-knows-cd.html b/pr-1683/2015/06/23/hardly-anyone-knows-cd.html new file mode 100644 index 000000000..d8ce15a1c --- /dev/null +++ b/pr-1683/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-1683/2015/06/23/hardly-anyone-knows-cd/index.html b/pr-1683/2015/06/23/hardly-anyone-knows-cd/index.html new file mode 100644 index 000000000..e1e30de71 --- /dev/null +++ b/pr-1683/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-1683/2015/06/23/index.html b/pr-1683/2015/06/23/index.html new file mode 100644 index 000000000..3db5a154b --- /dev/null +++ b/pr-1683/2015/06/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 23 2015 +

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

Archive for + Jun 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/07.html b/pr-1683/2015/07.html new file mode 100644 index 000000000..5af0ec4f0 --- /dev/null +++ b/pr-1683/2015/07.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2015 +

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

Archive for + Jul 7 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/07/07/GitHub-Integration.html b/pr-1683/2015/07/07/GitHub-Integration.html new file mode 100644 index 000000000..2c8321bde --- /dev/null +++ b/pr-1683/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-1683/2015/07/07/GitHub-Integration/index.html b/pr-1683/2015/07/07/GitHub-Integration/index.html new file mode 100644 index 000000000..f114ca73f --- /dev/null +++ b/pr-1683/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-1683/2015/07/07/index.html b/pr-1683/2015/07/07/index.html new file mode 100644 index 000000000..1dd8e8bf5 --- /dev/null +++ b/pr-1683/2015/07/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 7 2015 +

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

Archive for + Jul 14 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/07/14/Go_15_2_announced.html b/pr-1683/2015/07/14/Go_15_2_announced.html new file mode 100644 index 000000000..403a7c22e --- /dev/null +++ b/pr-1683/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-1683/2015/07/14/Go_15_2_announced/index.html b/pr-1683/2015/07/14/Go_15_2_announced/index.html new file mode 100644 index 000000000..4045b1785 --- /dev/null +++ b/pr-1683/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-1683/2015/07/14/index.html b/pr-1683/2015/07/14/index.html new file mode 100644 index 000000000..6f694bdae --- /dev/null +++ b/pr-1683/2015/07/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 14 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/07/index.html b/pr-1683/2015/07/index.html new file mode 100644 index 000000000..4fc08add8 --- /dev/null +++ b/pr-1683/2015/07/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2015 +

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

Archive for + Aug 2015 +

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

Archive for + Aug 5 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/08/05/Go-Sample-Virtualbox.html b/pr-1683/2015/08/05/Go-Sample-Virtualbox.html new file mode 100644 index 000000000..c31ec7b48 --- /dev/null +++ b/pr-1683/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-1683/2015/08/05/Go-Sample-Virtualbox/index.html b/pr-1683/2015/08/05/Go-Sample-Virtualbox/index.html new file mode 100644 index 000000000..742331013 --- /dev/null +++ b/pr-1683/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-1683/2015/08/05/index.html b/pr-1683/2015/08/05/index.html new file mode 100644 index 000000000..5c7d211d6 --- /dev/null +++ b/pr-1683/2015/08/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/08/28.html b/pr-1683/2015/08/28.html new file mode 100644 index 000000000..28204794b --- /dev/null +++ b/pr-1683/2015/08/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/08/28/index.html b/pr-1683/2015/08/28/index.html new file mode 100644 index 000000000..894fe4211 --- /dev/null +++ b/pr-1683/2015/08/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/08/28/pipeline-patterns.html b/pr-1683/2015/08/28/pipeline-patterns.html new file mode 100644 index 000000000..03d2ef976 --- /dev/null +++ b/pr-1683/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-1683/2015/08/28/pipeline-patterns/index.html b/pr-1683/2015/08/28/pipeline-patterns/index.html new file mode 100644 index 000000000..9b5e972cd --- /dev/null +++ b/pr-1683/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-1683/2015/08/index.html b/pr-1683/2015/08/index.html new file mode 100644 index 000000000..2910c4f34 --- /dev/null +++ b/pr-1683/2015/08/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2015 +

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

Archive for + Sep 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/09/01.html b/pr-1683/2015/09/01.html new file mode 100644 index 000000000..aa37ccbdb --- /dev/null +++ b/pr-1683/2015/09/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 1 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/09/01/index.html b/pr-1683/2015/09/01/index.html new file mode 100644 index 000000000..387269cb5 --- /dev/null +++ b/pr-1683/2015/09/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 1 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/09/01/visibility-is-opportunity.html b/pr-1683/2015/09/01/visibility-is-opportunity.html new file mode 100644 index 000000000..5d85900e0 --- /dev/null +++ b/pr-1683/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-1683/2015/09/01/visibility-is-opportunity/index.html b/pr-1683/2015/09/01/visibility-is-opportunity/index.html new file mode 100644 index 000000000..31fce8453 --- /dev/null +++ b/pr-1683/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-1683/2015/09/index.html b/pr-1683/2015/09/index.html new file mode 100644 index 000000000..d9e10f586 --- /dev/null +++ b/pr-1683/2015/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/10.html b/pr-1683/2015/10.html new file mode 100644 index 000000000..9c4ac05f8 --- /dev/null +++ b/pr-1683/2015/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/10/19.html b/pr-1683/2015/10/19.html new file mode 100644 index 000000000..736ece1ec --- /dev/null +++ b/pr-1683/2015/10/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 19 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/10/19/gocd-snap-at-devops-enterprise-summit.html b/pr-1683/2015/10/19/gocd-snap-at-devops-enterprise-summit.html new file mode 100644 index 000000000..694fbb367 --- /dev/null +++ b/pr-1683/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-1683/2015/10/19/gocd-snap-at-devops-enterprise-summit/index.html b/pr-1683/2015/10/19/gocd-snap-at-devops-enterprise-summit/index.html new file mode 100644 index 000000000..21ad6aaef --- /dev/null +++ b/pr-1683/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-1683/2015/10/19/index.html b/pr-1683/2015/10/19/index.html new file mode 100644 index 000000000..b3f69e709 --- /dev/null +++ b/pr-1683/2015/10/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 19 2015 +

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

Archive for + Oct 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/10/29/go-webinar-recording.html b/pr-1683/2015/10/29/go-webinar-recording.html new file mode 100644 index 000000000..e62e34525 --- /dev/null +++ b/pr-1683/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-1683/2015/10/29/go-webinar-recording/index.html b/pr-1683/2015/10/29/go-webinar-recording/index.html new file mode 100644 index 000000000..57c2638b8 --- /dev/null +++ b/pr-1683/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-1683/2015/10/29/index.html b/pr-1683/2015/10/29/index.html new file mode 100644 index 000000000..5371daaf9 --- /dev/null +++ b/pr-1683/2015/10/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 29 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/10/index.html b/pr-1683/2015/10/index.html new file mode 100644 index 000000000..793e248f4 --- /dev/null +++ b/pr-1683/2015/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11.html b/pr-1683/2015/11.html new file mode 100644 index 000000000..1994b0b53 --- /dev/null +++ b/pr-1683/2015/11.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11/09.html b/pr-1683/2015/11/09.html new file mode 100644 index 000000000..ca303ee64 --- /dev/null +++ b/pr-1683/2015/11/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 9 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11/09/deserialization-vulnerability-commons-collections.html b/pr-1683/2015/11/09/deserialization-vulnerability-commons-collections.html new file mode 100644 index 000000000..cece65eff --- /dev/null +++ b/pr-1683/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-1683/2015/11/09/deserialization-vulnerability-commons-collections/index.html b/pr-1683/2015/11/09/deserialization-vulnerability-commons-collections/index.html new file mode 100644 index 000000000..c5d394c9f --- /dev/null +++ b/pr-1683/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-1683/2015/11/09/index.html b/pr-1683/2015/11/09/index.html new file mode 100644 index 000000000..95eb750fb --- /dev/null +++ b/pr-1683/2015/11/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 9 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11/18.html b/pr-1683/2015/11/18.html new file mode 100644 index 000000000..3f42b0b2a --- /dev/null +++ b/pr-1683/2015/11/18.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11/18/Open-Source-Tests.html b/pr-1683/2015/11/18/Open-Source-Tests.html new file mode 100644 index 000000000..530b5e01c --- /dev/null +++ b/pr-1683/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-1683/2015/11/18/Open-Source-Tests/index.html b/pr-1683/2015/11/18/Open-Source-Tests/index.html new file mode 100644 index 000000000..b6c366f36 --- /dev/null +++ b/pr-1683/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-1683/2015/11/18/index.html b/pr-1683/2015/11/18/index.html new file mode 100644 index 000000000..54faedb3f --- /dev/null +++ b/pr-1683/2015/11/18/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 18 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/11/index.html b/pr-1683/2015/11/index.html new file mode 100644 index 000000000..02d5cc4fe --- /dev/null +++ b/pr-1683/2015/11/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2015 +

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

Archive for + Dec 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/12/22.html b/pr-1683/2015/12/22.html new file mode 100644 index 000000000..890a821f7 --- /dev/null +++ b/pr-1683/2015/12/22.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 22 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/12/22/gocd-in-2016.html b/pr-1683/2015/12/22/gocd-in-2016.html new file mode 100644 index 000000000..1a2a78aa4 --- /dev/null +++ b/pr-1683/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-1683/2015/12/22/gocd-in-2016/index.html b/pr-1683/2015/12/22/gocd-in-2016/index.html new file mode 100644 index 000000000..a17623557 --- /dev/null +++ b/pr-1683/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-1683/2015/12/22/index.html b/pr-1683/2015/12/22/index.html new file mode 100644 index 000000000..4da29cc96 --- /dev/null +++ b/pr-1683/2015/12/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 22 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/12/28.html b/pr-1683/2015/12/28.html new file mode 100644 index 000000000..6f9e032f2 --- /dev/null +++ b/pr-1683/2015/12/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/12/28/gocd-continuous-delivery-through-pipelines.html b/pr-1683/2015/12/28/gocd-continuous-delivery-through-pipelines.html new file mode 100644 index 000000000..77329464e --- /dev/null +++ b/pr-1683/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-1683/2015/12/28/gocd-continuous-delivery-through-pipelines/index.html b/pr-1683/2015/12/28/gocd-continuous-delivery-through-pipelines/index.html new file mode 100644 index 000000000..f929210d1 --- /dev/null +++ b/pr-1683/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-1683/2015/12/28/index.html b/pr-1683/2015/12/28/index.html new file mode 100644 index 000000000..5105e9083 --- /dev/null +++ b/pr-1683/2015/12/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 28 2015 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/12/index.html b/pr-1683/2015/12/index.html new file mode 100644 index 000000000..27ea60e79 --- /dev/null +++ b/pr-1683/2015/12/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2015 +

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

Archive for + 2015 +

+ +

Page 1 of 3

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/page/2.html b/pr-1683/2015/page/2.html new file mode 100644 index 000000000..2d015e8eb --- /dev/null +++ b/pr-1683/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-1683/2015/page/2/index.html b/pr-1683/2015/page/2/index.html new file mode 100644 index 000000000..722d216dd --- /dev/null +++ b/pr-1683/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-1683/2015/page/3.html b/pr-1683/2015/page/3.html new file mode 100644 index 000000000..a47173c55 --- /dev/null +++ b/pr-1683/2015/page/3.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2015 +

+ +

Page 3 of 3

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2015/page/3/index.html b/pr-1683/2015/page/3/index.html new file mode 100644 index 000000000..8a6f474fc --- /dev/null +++ b/pr-1683/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-1683/2016.html b/pr-1683/2016.html new file mode 100644 index 000000000..21b13b087 --- /dev/null +++ b/pr-1683/2016.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01.html b/pr-1683/2016/01.html new file mode 100644 index 000000000..206590cdb --- /dev/null +++ b/pr-1683/2016/01.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01/17.html b/pr-1683/2016/01/17.html new file mode 100644 index 000000000..3cc558ccd --- /dev/null +++ b/pr-1683/2016/01/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01/17/index.html b/pr-1683/2016/01/17/index.html new file mode 100644 index 000000000..6e086f073 --- /dev/null +++ b/pr-1683/2016/01/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01/17/not-done-unless-its-done.html b/pr-1683/2016/01/17/not-done-unless-its-done.html new file mode 100644 index 000000000..a3af13cfd --- /dev/null +++ b/pr-1683/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-1683/2016/01/17/not-done-unless-its-done/index.html b/pr-1683/2016/01/17/not-done-unless-its-done/index.html new file mode 100644 index 000000000..17e56728e --- /dev/null +++ b/pr-1683/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-1683/2016/01/25.html b/pr-1683/2016/01/25.html new file mode 100644 index 000000000..5fa3ba754 --- /dev/null +++ b/pr-1683/2016/01/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 25 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01/25/are-you-ready-for-continuous-delivery.html b/pr-1683/2016/01/25/are-you-ready-for-continuous-delivery.html new file mode 100644 index 000000000..e7b94545c --- /dev/null +++ b/pr-1683/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-1683/2016/01/25/are-you-ready-for-continuous-delivery/index.html b/pr-1683/2016/01/25/are-you-ready-for-continuous-delivery/index.html new file mode 100644 index 000000000..ea983af03 --- /dev/null +++ b/pr-1683/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-1683/2016/01/25/index.html b/pr-1683/2016/01/25/index.html new file mode 100644 index 000000000..3e3fbd9c3 --- /dev/null +++ b/pr-1683/2016/01/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 25 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/01/index.html b/pr-1683/2016/01/index.html new file mode 100644 index 000000000..e85153b82 --- /dev/null +++ b/pr-1683/2016/01/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/02.html b/pr-1683/2016/02.html new file mode 100644 index 000000000..cbde1d7cd --- /dev/null +++ b/pr-1683/2016/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/02/08.html b/pr-1683/2016/02/08.html new file mode 100644 index 000000000..1e50ec847 --- /dev/null +++ b/pr-1683/2016/02/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/02/08/index.html b/pr-1683/2016/02/08/index.html new file mode 100644 index 000000000..41ef76ad6 --- /dev/null +++ b/pr-1683/2016/02/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/02/08/not-done-unless-its-done-security.html b/pr-1683/2016/02/08/not-done-unless-its-done-security.html new file mode 100644 index 000000000..15d3321c4 --- /dev/null +++ b/pr-1683/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-1683/2016/02/08/not-done-unless-its-done-security/index.html b/pr-1683/2016/02/08/not-done-unless-its-done-security/index.html new file mode 100644 index 000000000..e48299d93 --- /dev/null +++ b/pr-1683/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-1683/2016/02/index.html b/pr-1683/2016/02/index.html new file mode 100644 index 000000000..53ab42abe --- /dev/null +++ b/pr-1683/2016/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2016 +

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

Archive for + Mar 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/03/15.html b/pr-1683/2016/03/15.html new file mode 100644 index 000000000..a0cd14655 --- /dev/null +++ b/pr-1683/2016/03/15.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 15 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops.html b/pr-1683/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops.html new file mode 100644 index 000000000..abb4578c4 --- /dev/null +++ b/pr-1683/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-1683/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/index.html b/pr-1683/2016/03/15/are-you-ready-for-continuous-delivery-part-2-feedback-loops/index.html new file mode 100644 index 000000000..aa2ac22fc --- /dev/null +++ b/pr-1683/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-1683/2016/03/15/index.html b/pr-1683/2016/03/15/index.html new file mode 100644 index 000000000..21a125b15 --- /dev/null +++ b/pr-1683/2016/03/15/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 15 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/03/24.html b/pr-1683/2016/03/24.html new file mode 100644 index 000000000..90373c355 --- /dev/null +++ b/pr-1683/2016/03/24.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 24 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/03/24/how-to-avoid-brittle-code.html b/pr-1683/2016/03/24/how-to-avoid-brittle-code.html new file mode 100644 index 000000000..997aebbf7 --- /dev/null +++ b/pr-1683/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-1683/2016/03/24/how-to-avoid-brittle-code/index.html b/pr-1683/2016/03/24/how-to-avoid-brittle-code/index.html new file mode 100644 index 000000000..5829cf435 --- /dev/null +++ b/pr-1683/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-1683/2016/03/24/index.html b/pr-1683/2016/03/24/index.html new file mode 100644 index 000000000..3c81bee8f --- /dev/null +++ b/pr-1683/2016/03/24/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 24 2016 +

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

Archive for + Mar 2016 +

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

Archive for + Jun 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/06/08.html b/pr-1683/2016/06/08.html new file mode 100644 index 000000000..925c27eda --- /dev/null +++ b/pr-1683/2016/06/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 8 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline.html b/pr-1683/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline.html new file mode 100644 index 000000000..3bf4fbee5 --- /dev/null +++ b/pr-1683/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-1683/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/index.html b/pr-1683/2016/06/08/Add-performance-testing-to-your-Continuous-Delivery-pipeline/index.html new file mode 100644 index 000000000..a83bbc1f6 --- /dev/null +++ b/pr-1683/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-1683/2016/06/08/index.html b/pr-1683/2016/06/08/index.html new file mode 100644 index 000000000..9c077506d --- /dev/null +++ b/pr-1683/2016/06/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 8 2016 +

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

Archive for + Jun 21 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/06/21/dont-let-sunk-costs-sink-your-project.html b/pr-1683/2016/06/21/dont-let-sunk-costs-sink-your-project.html new file mode 100644 index 000000000..b448c5eee --- /dev/null +++ b/pr-1683/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-1683/2016/06/21/dont-let-sunk-costs-sink-your-project/index.html b/pr-1683/2016/06/21/dont-let-sunk-costs-sink-your-project/index.html new file mode 100644 index 000000000..cc6068ecd --- /dev/null +++ b/pr-1683/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-1683/2016/06/21/index.html b/pr-1683/2016/06/21/index.html new file mode 100644 index 000000000..50521a577 --- /dev/null +++ b/pr-1683/2016/06/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 21 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/06/index.html b/pr-1683/2016/06/index.html new file mode 100644 index 000000000..3d262ae42 --- /dev/null +++ b/pr-1683/2016/06/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2016 +

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

Archive for + Jul 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/07/13.html b/pr-1683/2016/07/13.html new file mode 100644 index 000000000..27fc91cc1 --- /dev/null +++ b/pr-1683/2016/07/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/07/13/DotNet-Core-and-GoCD.html b/pr-1683/2016/07/13/DotNet-Core-and-GoCD.html new file mode 100644 index 000000000..a7d7b9003 --- /dev/null +++ b/pr-1683/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-1683/2016/07/13/DotNet-Core-and-GoCD/index.html b/pr-1683/2016/07/13/DotNet-Core-and-GoCD/index.html new file mode 100644 index 000000000..b87833816 --- /dev/null +++ b/pr-1683/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-1683/2016/07/13/index.html b/pr-1683/2016/07/13/index.html new file mode 100644 index 000000000..112f6db5b --- /dev/null +++ b/pr-1683/2016/07/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2016 +

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

Archive for + Jul 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2016/index.html b/pr-1683/2016/index.html new file mode 100644 index 000000000..5fe369b38 --- /dev/null +++ b/pr-1683/2016/index.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2016 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017.html b/pr-1683/2017.html new file mode 100644 index 000000000..40fa8cc77 --- /dev/null +++ b/pr-1683/2017.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 1 of 4

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/01.html b/pr-1683/2017/01.html new file mode 100644 index 000000000..e1004e2ee --- /dev/null +++ b/pr-1683/2017/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/01/05.html b/pr-1683/2017/01/05.html new file mode 100644 index 000000000..99bdd7a16 --- /dev/null +++ b/pr-1683/2017/01/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 5 2017 +

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

Archive for + Jan 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/01/05/why-we-moved-from-go-cd-to-gocd-io.html b/pr-1683/2017/01/05/why-we-moved-from-go-cd-to-gocd-io.html new file mode 100644 index 000000000..09fca3259 --- /dev/null +++ b/pr-1683/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-1683/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/index.html b/pr-1683/2017/01/05/why-we-moved-from-go-cd-to-gocd-io/index.html new file mode 100644 index 000000000..d5e78deb7 --- /dev/null +++ b/pr-1683/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-1683/2017/01/index.html b/pr-1683/2017/01/index.html new file mode 100644 index 000000000..880bf2294 --- /dev/null +++ b/pr-1683/2017/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/02.html b/pr-1683/2017/02.html new file mode 100644 index 000000000..92bcb2c4d --- /dev/null +++ b/pr-1683/2017/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/02/16.html b/pr-1683/2017/02/16.html new file mode 100644 index 000000000..455d5eb2a --- /dev/null +++ b/pr-1683/2017/02/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/02/16/index.html b/pr-1683/2017/02/16/index.html new file mode 100644 index 000000000..c8023b7c6 --- /dev/null +++ b/pr-1683/2017/02/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/02/16/migrating-snapci-to-gocd.html b/pr-1683/2017/02/16/migrating-snapci-to-gocd.html new file mode 100644 index 000000000..589e06ce6 --- /dev/null +++ b/pr-1683/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-1683/2017/02/16/migrating-snapci-to-gocd/index.html b/pr-1683/2017/02/16/migrating-snapci-to-gocd/index.html new file mode 100644 index 000000000..3c378a06f --- /dev/null +++ b/pr-1683/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-1683/2017/02/index.html b/pr-1683/2017/02/index.html new file mode 100644 index 000000000..2ad5b2361 --- /dev/null +++ b/pr-1683/2017/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2017 +

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

Archive for + Mar 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/03/01.html b/pr-1683/2017/03/01.html new file mode 100644 index 000000000..7ab868296 --- /dev/null +++ b/pr-1683/2017/03/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/03/01/importance-and-principles-of-cd-pipelines.html b/pr-1683/2017/03/01/importance-and-principles-of-cd-pipelines.html new file mode 100644 index 000000000..5f8ac7b11 --- /dev/null +++ b/pr-1683/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-1683/2017/03/01/importance-and-principles-of-cd-pipelines/index.html b/pr-1683/2017/03/01/importance-and-principles-of-cd-pipelines/index.html new file mode 100644 index 000000000..9c4b6bdd5 --- /dev/null +++ b/pr-1683/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-1683/2017/03/01/index.html b/pr-1683/2017/03/01/index.html new file mode 100644 index 000000000..1f744ec05 --- /dev/null +++ b/pr-1683/2017/03/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/03/29.html b/pr-1683/2017/03/29.html new file mode 100644 index 000000000..8b5e73132 --- /dev/null +++ b/pr-1683/2017/03/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/03/29/beginnings-of-a-real-pipeline.html b/pr-1683/2017/03/29/beginnings-of-a-real-pipeline.html new file mode 100644 index 000000000..7ecd56cc0 --- /dev/null +++ b/pr-1683/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-1683/2017/03/29/beginnings-of-a-real-pipeline/index.html b/pr-1683/2017/03/29/beginnings-of-a-real-pipeline/index.html new file mode 100644 index 000000000..fe8a55f45 --- /dev/null +++ b/pr-1683/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-1683/2017/03/29/index.html b/pr-1683/2017/03/29/index.html new file mode 100644 index 000000000..3bba41f5e --- /dev/null +++ b/pr-1683/2017/03/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 29 2017 +

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

Archive for + Mar 2017 +

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

Archive for + Apr 2017 +

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

Archive for + Apr 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/04/06/index.html b/pr-1683/2017/04/06/index.html new file mode 100644 index 000000000..81cb7798b --- /dev/null +++ b/pr-1683/2017/04/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/04/06/reusing-pipelines.html b/pr-1683/2017/04/06/reusing-pipelines.html new file mode 100644 index 000000000..9eb680088 --- /dev/null +++ b/pr-1683/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-1683/2017/04/06/reusing-pipelines/index.html b/pr-1683/2017/04/06/reusing-pipelines/index.html new file mode 100644 index 000000000..2f44b4b2e --- /dev/null +++ b/pr-1683/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-1683/2017/04/11/gocd-over-jenkins.html b/pr-1683/2017/04/11/gocd-over-jenkins.html new file mode 100644 index 000000000..b835f4b81 --- /dev/null +++ b/pr-1683/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-1683/2017/04/11/gocd-over-jenkins/index.html b/pr-1683/2017/04/11/gocd-over-jenkins/index.html new file mode 100644 index 000000000..594b26f7c --- /dev/null +++ b/pr-1683/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-1683/2017/04/17.html b/pr-1683/2017/04/17.html new file mode 100644 index 000000000..d73058800 --- /dev/null +++ b/pr-1683/2017/04/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/04/17/build-propagation-using-fan-in-fan-out.html b/pr-1683/2017/04/17/build-propagation-using-fan-in-fan-out.html new file mode 100644 index 000000000..920ccf317 --- /dev/null +++ b/pr-1683/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-1683/2017/04/17/build-propagation-using-fan-in-fan-out/index.html b/pr-1683/2017/04/17/build-propagation-using-fan-in-fan-out/index.html new file mode 100644 index 000000000..37f057f2b --- /dev/null +++ b/pr-1683/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-1683/2017/04/17/index.html b/pr-1683/2017/04/17/index.html new file mode 100644 index 000000000..6edb29b7d --- /dev/null +++ b/pr-1683/2017/04/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/04/25.html b/pr-1683/2017/04/25.html new file mode 100644 index 000000000..b49576193 --- /dev/null +++ b/pr-1683/2017/04/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/04/25/gocd-over-jenkins.html b/pr-1683/2017/04/25/gocd-over-jenkins.html new file mode 100644 index 000000000..9229facdc --- /dev/null +++ b/pr-1683/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-1683/2017/04/25/gocd-over-jenkins/index.html b/pr-1683/2017/04/25/gocd-over-jenkins/index.html new file mode 100644 index 000000000..c3dc0cfe9 --- /dev/null +++ b/pr-1683/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-1683/2017/04/25/index.html b/pr-1683/2017/04/25/index.html new file mode 100644 index 000000000..0668838c7 --- /dev/null +++ b/pr-1683/2017/04/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2017 +

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

Archive for + Apr 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05.html b/pr-1683/2017/05.html new file mode 100644 index 000000000..f9b59873a --- /dev/null +++ b/pr-1683/2017/05.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2017 +

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

Archive for + May 2 2017 +

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

Archive for + May 2 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/02/what-does-pipelines-as-code-really-mean.html b/pr-1683/2017/05/02/what-does-pipelines-as-code-really-mean.html new file mode 100644 index 000000000..f159ccf26 --- /dev/null +++ b/pr-1683/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-1683/2017/05/02/what-does-pipelines-as-code-really-mean/index.html b/pr-1683/2017/05/02/what-does-pipelines-as-code-really-mean/index.html new file mode 100644 index 000000000..9aa093b83 --- /dev/null +++ b/pr-1683/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-1683/2017/05/09.html b/pr-1683/2017/05/09.html new file mode 100644 index 000000000..5be76d6ae --- /dev/null +++ b/pr-1683/2017/05/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 9 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/09/continuous-integration-devops-research.html b/pr-1683/2017/05/09/continuous-integration-devops-research.html new file mode 100644 index 000000000..cf1636e07 --- /dev/null +++ b/pr-1683/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-1683/2017/05/09/continuous-integration-devops-research/index.html b/pr-1683/2017/05/09/continuous-integration-devops-research/index.html new file mode 100644 index 000000000..9a13d2e9d --- /dev/null +++ b/pr-1683/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-1683/2017/05/09/index.html b/pr-1683/2017/05/09/index.html new file mode 100644 index 000000000..6ad0b3116 --- /dev/null +++ b/pr-1683/2017/05/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 9 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/16.html b/pr-1683/2017/05/16.html new file mode 100644 index 000000000..3c6c89960 --- /dev/null +++ b/pr-1683/2017/05/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/16/index.html b/pr-1683/2017/05/16/index.html new file mode 100644 index 000000000..05127a85a --- /dev/null +++ b/pr-1683/2017/05/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 16 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/16/its-not-CI-its-CI-theatre.html b/pr-1683/2017/05/16/its-not-CI-its-CI-theatre.html new file mode 100644 index 000000000..d972a907b --- /dev/null +++ b/pr-1683/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-1683/2017/05/16/its-not-CI-its-CI-theatre/index.html b/pr-1683/2017/05/16/its-not-CI-its-CI-theatre/index.html new file mode 100644 index 000000000..3f568ce5c --- /dev/null +++ b/pr-1683/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-1683/2017/05/23.html b/pr-1683/2017/05/23.html new file mode 100644 index 000000000..aee769389 --- /dev/null +++ b/pr-1683/2017/05/23.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 23 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/23/control-deployments-manual-approvals.html b/pr-1683/2017/05/23/control-deployments-manual-approvals.html new file mode 100644 index 000000000..5b46dc362 --- /dev/null +++ b/pr-1683/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-1683/2017/05/23/control-deployments-manual-approvals/index.html b/pr-1683/2017/05/23/control-deployments-manual-approvals/index.html new file mode 100644 index 000000000..f9293cd46 --- /dev/null +++ b/pr-1683/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-1683/2017/05/23/index.html b/pr-1683/2017/05/23/index.html new file mode 100644 index 000000000..6aee5207e --- /dev/null +++ b/pr-1683/2017/05/23/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 23 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/05/index.html b/pr-1683/2017/05/index.html new file mode 100644 index 000000000..713a92887 --- /dev/null +++ b/pr-1683/2017/05/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2017 +

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

Archive for + Jun 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/01.html b/pr-1683/2017/06/01.html new file mode 100644 index 000000000..573937c54 --- /dev/null +++ b/pr-1683/2017/06/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 1 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/01/forever-home.html b/pr-1683/2017/06/01/forever-home.html new file mode 100644 index 000000000..10c732b92 --- /dev/null +++ b/pr-1683/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-1683/2017/06/01/forever-home/index.html b/pr-1683/2017/06/01/forever-home/index.html new file mode 100644 index 000000000..679cb5f2c --- /dev/null +++ b/pr-1683/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-1683/2017/06/01/index.html b/pr-1683/2017/06/01/index.html new file mode 100644 index 000000000..fefd9195f --- /dev/null +++ b/pr-1683/2017/06/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 1 2017 +

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

Archive for + Jun 13 2017 +

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

Archive for + Jun 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/13/modeling-deployment-pipelines-agents-environments.html b/pr-1683/2017/06/13/modeling-deployment-pipelines-agents-environments.html new file mode 100644 index 000000000..e68ee436d --- /dev/null +++ b/pr-1683/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-1683/2017/06/13/modeling-deployment-pipelines-agents-environments/index.html b/pr-1683/2017/06/13/modeling-deployment-pipelines-agents-environments/index.html new file mode 100644 index 000000000..ab7477d4b --- /dev/null +++ b/pr-1683/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-1683/2017/06/20.html b/pr-1683/2017/06/20.html new file mode 100644 index 000000000..6bc0398ba --- /dev/null +++ b/pr-1683/2017/06/20.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/20/hotfixes-rollback-rollforward.html b/pr-1683/2017/06/20/hotfixes-rollback-rollforward.html new file mode 100644 index 000000000..d73a2fb7c --- /dev/null +++ b/pr-1683/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-1683/2017/06/20/hotfixes-rollback-rollforward/index.html b/pr-1683/2017/06/20/hotfixes-rollback-rollforward/index.html new file mode 100644 index 000000000..990c196d5 --- /dev/null +++ b/pr-1683/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-1683/2017/06/20/index.html b/pr-1683/2017/06/20/index.html new file mode 100644 index 000000000..c6128ed95 --- /dev/null +++ b/pr-1683/2017/06/20/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 20 2017 +

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

Archive for + Jun 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/22/deployment-pipeline-patterns-infographic.html b/pr-1683/2017/06/22/deployment-pipeline-patterns-infographic.html new file mode 100644 index 000000000..5d3c2045c --- /dev/null +++ b/pr-1683/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-1683/2017/06/22/deployment-pipeline-patterns-infographic/index.html b/pr-1683/2017/06/22/deployment-pipeline-patterns-infographic/index.html new file mode 100644 index 000000000..df9def3fe --- /dev/null +++ b/pr-1683/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-1683/2017/06/22/index.html b/pr-1683/2017/06/22/index.html new file mode 100644 index 000000000..4dc34b968 --- /dev/null +++ b/pr-1683/2017/06/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/26.html b/pr-1683/2017/06/26.html new file mode 100644 index 000000000..61388154c --- /dev/null +++ b/pr-1683/2017/06/26.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/26/index.html b/pr-1683/2017/06/26/index.html new file mode 100644 index 000000000..545f0dda0 --- /dev/null +++ b/pr-1683/2017/06/26/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/06/26/serverless-architecture-continuous-delivery.html b/pr-1683/2017/06/26/serverless-architecture-continuous-delivery.html new file mode 100644 index 000000000..532c29932 --- /dev/null +++ b/pr-1683/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-1683/2017/06/26/serverless-architecture-continuous-delivery/index.html b/pr-1683/2017/06/26/serverless-architecture-continuous-delivery/index.html new file mode 100644 index 000000000..c265b9e04 --- /dev/null +++ b/pr-1683/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-1683/2017/06/index.html b/pr-1683/2017/06/index.html new file mode 100644 index 000000000..e11e78e29 --- /dev/null +++ b/pr-1683/2017/06/index.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07.html b/pr-1683/2017/07.html new file mode 100644 index 000000000..e9a26800c --- /dev/null +++ b/pr-1683/2017/07.html @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2017 +

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

Archive for + Jul 5 2017 +

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

Archive for + Jul 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/05/product-manager-guide-continuous-delivery.html b/pr-1683/2017/07/05/product-manager-guide-continuous-delivery.html new file mode 100644 index 000000000..141f8121b --- /dev/null +++ b/pr-1683/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-1683/2017/07/05/product-manager-guide-continuous-delivery/index.html b/pr-1683/2017/07/05/product-manager-guide-continuous-delivery/index.html new file mode 100644 index 000000000..115165da4 --- /dev/null +++ b/pr-1683/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-1683/2017/07/10.html b/pr-1683/2017/07/10.html new file mode 100644 index 000000000..40c02625e --- /dev/null +++ b/pr-1683/2017/07/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/10/gocd-vs-spinnaker.html b/pr-1683/2017/07/10/gocd-vs-spinnaker.html new file mode 100644 index 000000000..8a8e90784 --- /dev/null +++ b/pr-1683/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-1683/2017/07/10/gocd-vs-spinnaker/index.html b/pr-1683/2017/07/10/gocd-vs-spinnaker/index.html new file mode 100644 index 000000000..732f168f2 --- /dev/null +++ b/pr-1683/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-1683/2017/07/10/index.html b/pr-1683/2017/07/10/index.html new file mode 100644 index 000000000..2a4524f5b --- /dev/null +++ b/pr-1683/2017/07/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/13.html b/pr-1683/2017/07/13.html new file mode 100644 index 000000000..230fc6a2a --- /dev/null +++ b/pr-1683/2017/07/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/13/index.html b/pr-1683/2017/07/13/index.html new file mode 100644 index 000000000..d7f3e6e5a --- /dev/null +++ b/pr-1683/2017/07/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 13 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/13/introduction-continuous-delivery-101.html b/pr-1683/2017/07/13/introduction-continuous-delivery-101.html new file mode 100644 index 000000000..ec3dab2e9 --- /dev/null +++ b/pr-1683/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-1683/2017/07/13/introduction-continuous-delivery-101/index.html b/pr-1683/2017/07/13/introduction-continuous-delivery-101/index.html new file mode 100644 index 000000000..febe01dde --- /dev/null +++ b/pr-1683/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-1683/2017/07/18.html b/pr-1683/2017/07/18.html new file mode 100644 index 000000000..49a833fea --- /dev/null +++ b/pr-1683/2017/07/18.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 18 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/18/continuous-deployment-strategies.html b/pr-1683/2017/07/18/continuous-deployment-strategies.html new file mode 100644 index 000000000..1d653cca7 --- /dev/null +++ b/pr-1683/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-1683/2017/07/18/continuous-deployment-strategies/index.html b/pr-1683/2017/07/18/continuous-deployment-strategies/index.html new file mode 100644 index 000000000..750bf68ed --- /dev/null +++ b/pr-1683/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-1683/2017/07/18/index.html b/pr-1683/2017/07/18/index.html new file mode 100644 index 000000000..8060040e4 --- /dev/null +++ b/pr-1683/2017/07/18/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 18 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/20.html b/pr-1683/2017/07/20.html new file mode 100644 index 000000000..62c0ec082 --- /dev/null +++ b/pr-1683/2017/07/20.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/20/deployment-pipeline-automated-testing.html b/pr-1683/2017/07/20/deployment-pipeline-automated-testing.html new file mode 100644 index 000000000..650208aa5 --- /dev/null +++ b/pr-1683/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-1683/2017/07/20/deployment-pipeline-automated-testing/index.html b/pr-1683/2017/07/20/deployment-pipeline-automated-testing/index.html new file mode 100644 index 000000000..470940e02 --- /dev/null +++ b/pr-1683/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-1683/2017/07/20/index.html b/pr-1683/2017/07/20/index.html new file mode 100644 index 000000000..a6bc7da01 --- /dev/null +++ b/pr-1683/2017/07/20/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 20 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/25.html b/pr-1683/2017/07/25.html new file mode 100644 index 000000000..6a02b8f96 --- /dev/null +++ b/pr-1683/2017/07/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/25/blue-green-deployments.html b/pr-1683/2017/07/25/blue-green-deployments.html new file mode 100644 index 000000000..3bb9cdac0 --- /dev/null +++ b/pr-1683/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-1683/2017/07/25/blue-green-deployments/index.html b/pr-1683/2017/07/25/blue-green-deployments/index.html new file mode 100644 index 000000000..d5227a6c3 --- /dev/null +++ b/pr-1683/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-1683/2017/07/25/index.html b/pr-1683/2017/07/25/index.html new file mode 100644 index 000000000..476f2b572 --- /dev/null +++ b/pr-1683/2017/07/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 25 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/07/index.html b/pr-1683/2017/07/index.html new file mode 100644 index 000000000..3eff271e4 --- /dev/null +++ b/pr-1683/2017/07/index.html @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08.html b/pr-1683/2017/08.html new file mode 100644 index 000000000..7937db5bb --- /dev/null +++ b/pr-1683/2017/08.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/08.html b/pr-1683/2017/08/08.html new file mode 100644 index 000000000..363159c22 --- /dev/null +++ b/pr-1683/2017/08/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 8 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/08/gocd-elastic-agents-benefits.html b/pr-1683/2017/08/08/gocd-elastic-agents-benefits.html new file mode 100644 index 000000000..bcc20048c --- /dev/null +++ b/pr-1683/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-1683/2017/08/08/gocd-elastic-agents-benefits/index.html b/pr-1683/2017/08/08/gocd-elastic-agents-benefits/index.html new file mode 100644 index 000000000..f0ecd79df --- /dev/null +++ b/pr-1683/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-1683/2017/08/08/index.html b/pr-1683/2017/08/08/index.html new file mode 100644 index 000000000..3a8e32690 --- /dev/null +++ b/pr-1683/2017/08/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 8 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/15.html b/pr-1683/2017/08/15.html new file mode 100644 index 000000000..116253b59 --- /dev/null +++ b/pr-1683/2017/08/15.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 15 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/15/canary-releases.html b/pr-1683/2017/08/15/canary-releases.html new file mode 100644 index 000000000..7ae9cd5ae --- /dev/null +++ b/pr-1683/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-1683/2017/08/15/canary-releases/index.html b/pr-1683/2017/08/15/canary-releases/index.html new file mode 100644 index 000000000..a8ed10331 --- /dev/null +++ b/pr-1683/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-1683/2017/08/15/index.html b/pr-1683/2017/08/15/index.html new file mode 100644 index 000000000..fbe1df397 --- /dev/null +++ b/pr-1683/2017/08/15/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 15 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/22.html b/pr-1683/2017/08/22.html new file mode 100644 index 000000000..a18f2f0a9 --- /dev/null +++ b/pr-1683/2017/08/22.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/22/index.html b/pr-1683/2017/08/22/index.html new file mode 100644 index 000000000..bd1c9837a --- /dev/null +++ b/pr-1683/2017/08/22/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 22 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/22/principles-practices-continuous-delivery.html b/pr-1683/2017/08/22/principles-practices-continuous-delivery.html new file mode 100644 index 000000000..2a199255b --- /dev/null +++ b/pr-1683/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-1683/2017/08/22/principles-practices-continuous-delivery/index.html b/pr-1683/2017/08/22/principles-practices-continuous-delivery/index.html new file mode 100644 index 000000000..8cd13af44 --- /dev/null +++ b/pr-1683/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-1683/2017/08/29.html b/pr-1683/2017/08/29.html new file mode 100644 index 000000000..02a7d21ac --- /dev/null +++ b/pr-1683/2017/08/29.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/29/driving-change-devops-adoption.html b/pr-1683/2017/08/29/driving-change-devops-adoption.html new file mode 100644 index 000000000..5f3ad54bd --- /dev/null +++ b/pr-1683/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-1683/2017/08/29/driving-change-devops-adoption/index.html b/pr-1683/2017/08/29/driving-change-devops-adoption/index.html new file mode 100644 index 000000000..db8d3ffed --- /dev/null +++ b/pr-1683/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-1683/2017/08/29/index.html b/pr-1683/2017/08/29/index.html new file mode 100644 index 000000000..81b46b34f --- /dev/null +++ b/pr-1683/2017/08/29/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 29 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/31.html b/pr-1683/2017/08/31.html new file mode 100644 index 000000000..a3c58300e --- /dev/null +++ b/pr-1683/2017/08/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/31/apax-acquires-thoughtworks.html b/pr-1683/2017/08/31/apax-acquires-thoughtworks.html new file mode 100644 index 000000000..975fbd95f --- /dev/null +++ b/pr-1683/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-1683/2017/08/31/apax-acquires-thoughtworks/index.html b/pr-1683/2017/08/31/apax-acquires-thoughtworks/index.html new file mode 100644 index 000000000..8a2b550ab --- /dev/null +++ b/pr-1683/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-1683/2017/08/31/index.html b/pr-1683/2017/08/31/index.html new file mode 100644 index 000000000..c2ae8162b --- /dev/null +++ b/pr-1683/2017/08/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/08/index.html b/pr-1683/2017/08/index.html new file mode 100644 index 000000000..2fc68dd8c --- /dev/null +++ b/pr-1683/2017/08/index.html @@ -0,0 +1,136 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09.html b/pr-1683/2017/09.html new file mode 100644 index 000000000..0f4cf7850 --- /dev/null +++ b/pr-1683/2017/09.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/05.html b/pr-1683/2017/09/05.html new file mode 100644 index 000000000..75b8d1d03 --- /dev/null +++ b/pr-1683/2017/09/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/05/index.html b/pr-1683/2017/09/05/index.html new file mode 100644 index 000000000..539b4b8e6 --- /dev/null +++ b/pr-1683/2017/09/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 5 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/05/misconceptions-patterns-devops-adoption.html b/pr-1683/2017/09/05/misconceptions-patterns-devops-adoption.html new file mode 100644 index 000000000..f4d3aeeb9 --- /dev/null +++ b/pr-1683/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-1683/2017/09/05/misconceptions-patterns-devops-adoption/index.html b/pr-1683/2017/09/05/misconceptions-patterns-devops-adoption/index.html new file mode 100644 index 000000000..d47dc565f --- /dev/null +++ b/pr-1683/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-1683/2017/09/12.html b/pr-1683/2017/09/12.html new file mode 100644 index 000000000..34402812f --- /dev/null +++ b/pr-1683/2017/09/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 12 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/12/index.html b/pr-1683/2017/09/12/index.html new file mode 100644 index 000000000..3cbc28b36 --- /dev/null +++ b/pr-1683/2017/09/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 12 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/12/value-stream-mapping.html b/pr-1683/2017/09/12/value-stream-mapping.html new file mode 100644 index 000000000..18f77e5d6 --- /dev/null +++ b/pr-1683/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-1683/2017/09/12/value-stream-mapping/index.html b/pr-1683/2017/09/12/value-stream-mapping/index.html new file mode 100644 index 000000000..d40bcf10c --- /dev/null +++ b/pr-1683/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-1683/2017/09/19.html b/pr-1683/2017/09/19.html new file mode 100644 index 000000000..fc4d58ced --- /dev/null +++ b/pr-1683/2017/09/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 19 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/19/actions-spread-devops-adoption.html b/pr-1683/2017/09/19/actions-spread-devops-adoption.html new file mode 100644 index 000000000..e26d7052a --- /dev/null +++ b/pr-1683/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-1683/2017/09/19/actions-spread-devops-adoption/index.html b/pr-1683/2017/09/19/actions-spread-devops-adoption/index.html new file mode 100644 index 000000000..b43528039 --- /dev/null +++ b/pr-1683/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-1683/2017/09/19/index.html b/pr-1683/2017/09/19/index.html new file mode 100644 index 000000000..f1fe60261 --- /dev/null +++ b/pr-1683/2017/09/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 19 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/26.html b/pr-1683/2017/09/26.html new file mode 100644 index 000000000..c2df136a1 --- /dev/null +++ b/pr-1683/2017/09/26.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/26/are-you-ready-for-continuous-delivery-infographic.html b/pr-1683/2017/09/26/are-you-ready-for-continuous-delivery-infographic.html new file mode 100644 index 000000000..3fc791d74 --- /dev/null +++ b/pr-1683/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-1683/2017/09/26/are-you-ready-for-continuous-delivery-infographic/index.html b/pr-1683/2017/09/26/are-you-ready-for-continuous-delivery-infographic/index.html new file mode 100644 index 000000000..6020ce12c --- /dev/null +++ b/pr-1683/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-1683/2017/09/26/index.html b/pr-1683/2017/09/26/index.html new file mode 100644 index 000000000..1aa6acdf7 --- /dev/null +++ b/pr-1683/2017/09/26/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 26 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/09/index.html b/pr-1683/2017/09/index.html new file mode 100644 index 000000000..76ba65f2f --- /dev/null +++ b/pr-1683/2017/09/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10.html b/pr-1683/2017/10.html new file mode 100644 index 000000000..0aa4b7865 --- /dev/null +++ b/pr-1683/2017/10.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/03.html b/pr-1683/2017/10/03.html new file mode 100644 index 000000000..11157cdb8 --- /dev/null +++ b/pr-1683/2017/10/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 3 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/03/index.html b/pr-1683/2017/10/03/index.html new file mode 100644 index 000000000..174c4546b --- /dev/null +++ b/pr-1683/2017/10/03/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 3 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/03/introduction-continuous-delivery-deployment-tools.html b/pr-1683/2017/10/03/introduction-continuous-delivery-deployment-tools.html new file mode 100644 index 000000000..e9d707328 --- /dev/null +++ b/pr-1683/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-1683/2017/10/03/introduction-continuous-delivery-deployment-tools/index.html b/pr-1683/2017/10/03/introduction-continuous-delivery-deployment-tools/index.html new file mode 100644 index 000000000..59e8e481e --- /dev/null +++ b/pr-1683/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-1683/2017/10/10.html b/pr-1683/2017/10/10.html new file mode 100644 index 000000000..ac8ca1bab --- /dev/null +++ b/pr-1683/2017/10/10.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/10/architecting-continuous-delivery.html b/pr-1683/2017/10/10/architecting-continuous-delivery.html new file mode 100644 index 000000000..8632ee49a --- /dev/null +++ b/pr-1683/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-1683/2017/10/10/architecting-continuous-delivery/index.html b/pr-1683/2017/10/10/architecting-continuous-delivery/index.html new file mode 100644 index 000000000..dee8cd366 --- /dev/null +++ b/pr-1683/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-1683/2017/10/10/index.html b/pr-1683/2017/10/10/index.html new file mode 100644 index 000000000..0e8a51edd --- /dev/null +++ b/pr-1683/2017/10/10/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 10 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/17.html b/pr-1683/2017/10/17.html new file mode 100644 index 000000000..cefc8222c --- /dev/null +++ b/pr-1683/2017/10/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic.html b/pr-1683/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic.html new file mode 100644 index 000000000..04b09ab66 --- /dev/null +++ b/pr-1683/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-1683/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/index.html b/pr-1683/2017/10/17/difference-between-continuous-delivery-continuous-deployment-infographic/index.html new file mode 100644 index 000000000..604b3d942 --- /dev/null +++ b/pr-1683/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-1683/2017/10/17/index.html b/pr-1683/2017/10/17/index.html new file mode 100644 index 000000000..3c227bb8b --- /dev/null +++ b/pr-1683/2017/10/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 17 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/31.html b/pr-1683/2017/10/31.html new file mode 100644 index 000000000..696a16524 --- /dev/null +++ b/pr-1683/2017/10/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/31/index.html b/pr-1683/2017/10/31/index.html new file mode 100644 index 000000000..cca65e639 --- /dev/null +++ b/pr-1683/2017/10/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 31 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/10/31/mobile-app-continuous-delivery-gocd.html b/pr-1683/2017/10/31/mobile-app-continuous-delivery-gocd.html new file mode 100644 index 000000000..e82bf0e7e --- /dev/null +++ b/pr-1683/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-1683/2017/10/31/mobile-app-continuous-delivery-gocd/index.html b/pr-1683/2017/10/31/mobile-app-continuous-delivery-gocd/index.html new file mode 100644 index 000000000..fc9974510 --- /dev/null +++ b/pr-1683/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-1683/2017/10/index.html b/pr-1683/2017/10/index.html new file mode 100644 index 000000000..1a4fe3ea0 --- /dev/null +++ b/pr-1683/2017/10/index.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2017 +

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

Archive for + Nov 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/11/07.html b/pr-1683/2017/11/07.html new file mode 100644 index 000000000..5ec8e715b --- /dev/null +++ b/pr-1683/2017/11/07.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 7 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool.html b/pr-1683/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool.html new file mode 100644 index 000000000..d9b1c5d30 --- /dev/null +++ b/pr-1683/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-1683/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/index.html b/pr-1683/2017/11/07/confessions-stories-continuous-delivery-mingle-project-management-tool/index.html new file mode 100644 index 000000000..13b1c012a --- /dev/null +++ b/pr-1683/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-1683/2017/11/07/index.html b/pr-1683/2017/11/07/index.html new file mode 100644 index 000000000..47c3f73d6 --- /dev/null +++ b/pr-1683/2017/11/07/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 7 2017 +

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

Archive for + Nov 14 2017 +

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

Archive for + Nov 14 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/11/14/minimizing-risk-improving-security-devops.html b/pr-1683/2017/11/14/minimizing-risk-improving-security-devops.html new file mode 100644 index 000000000..801cec6c6 --- /dev/null +++ b/pr-1683/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-1683/2017/11/14/minimizing-risk-improving-security-devops/index.html b/pr-1683/2017/11/14/minimizing-risk-improving-security-devops/index.html new file mode 100644 index 000000000..1ea23e608 --- /dev/null +++ b/pr-1683/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-1683/2017/11/28.html b/pr-1683/2017/11/28.html new file mode 100644 index 000000000..af38cb40f --- /dev/null +++ b/pr-1683/2017/11/28.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 28 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source.html b/pr-1683/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source.html new file mode 100644 index 000000000..02bea357b --- /dev/null +++ b/pr-1683/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-1683/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/index.html b/pr-1683/2017/11/28/confessions-continuous-delivery-experts-gocd-open-source/index.html new file mode 100644 index 000000000..247ef964c --- /dev/null +++ b/pr-1683/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-1683/2017/11/28/index.html b/pr-1683/2017/11/28/index.html new file mode 100644 index 000000000..0bc44b4f1 --- /dev/null +++ b/pr-1683/2017/11/28/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 28 2017 +

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

Archive for + Nov 2017 +

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

Archive for + Dec 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/12/06.html b/pr-1683/2017/12/06.html new file mode 100644 index 000000000..28f616cc6 --- /dev/null +++ b/pr-1683/2017/12/06.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 6 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith.html b/pr-1683/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith.html new file mode 100644 index 000000000..65f6f0ab1 --- /dev/null +++ b/pr-1683/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-1683/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/index.html b/pr-1683/2017/12/06/confessions-continuous-delivery-experts-snapci-microservices-monolith/index.html new file mode 100644 index 000000000..889e37bc0 --- /dev/null +++ b/pr-1683/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-1683/2017/12/06/index.html b/pr-1683/2017/12/06/index.html new file mode 100644 index 000000000..1dd7ee047 --- /dev/null +++ b/pr-1683/2017/12/06/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 6 2017 +

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

Archive for + Dec 2017 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/index.html b/pr-1683/2017/index.html new file mode 100644 index 000000000..07f39feba --- /dev/null +++ b/pr-1683/2017/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 1 of 4

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/page/2.html b/pr-1683/2017/page/2.html new file mode 100644 index 000000000..629fffbd8 --- /dev/null +++ b/pr-1683/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-1683/2017/page/2/index.html b/pr-1683/2017/page/2/index.html new file mode 100644 index 000000000..68ac29981 --- /dev/null +++ b/pr-1683/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-1683/2017/page/3.html b/pr-1683/2017/page/3.html new file mode 100644 index 000000000..180cea1b8 --- /dev/null +++ b/pr-1683/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-1683/2017/page/3/index.html b/pr-1683/2017/page/3/index.html new file mode 100644 index 000000000..e04f3e22b --- /dev/null +++ b/pr-1683/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-1683/2017/page/4.html b/pr-1683/2017/page/4.html new file mode 100644 index 000000000..9e22f67e5 --- /dev/null +++ b/pr-1683/2017/page/4.html @@ -0,0 +1,143 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2017 +

+ +

Page 4 of 4

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2017/page/4/index.html b/pr-1683/2017/page/4/index.html new file mode 100644 index 000000000..789d22310 --- /dev/null +++ b/pr-1683/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-1683/2018.html b/pr-1683/2018.html new file mode 100644 index 000000000..b8ad576e1 --- /dev/null +++ b/pr-1683/2018.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 1 of 2

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01.html b/pr-1683/2018/01.html new file mode 100644 index 000000000..9df175736 --- /dev/null +++ b/pr-1683/2018/01.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01/17.html b/pr-1683/2018/01/17.html new file mode 100644 index 000000000..268c0a937 --- /dev/null +++ b/pr-1683/2018/01/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01/17/continuous-delivery-beginners-guide.html b/pr-1683/2018/01/17/continuous-delivery-beginners-guide.html new file mode 100644 index 000000000..d565dd30e --- /dev/null +++ b/pr-1683/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-1683/2018/01/17/continuous-delivery-beginners-guide/index.html b/pr-1683/2018/01/17/continuous-delivery-beginners-guide/index.html new file mode 100644 index 000000000..9cb2de540 --- /dev/null +++ b/pr-1683/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-1683/2018/01/17/index.html b/pr-1683/2018/01/17/index.html new file mode 100644 index 000000000..bac94cd88 --- /dev/null +++ b/pr-1683/2018/01/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01/31.html b/pr-1683/2018/01/31.html new file mode 100644 index 000000000..d83e0efa4 --- /dev/null +++ b/pr-1683/2018/01/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01/31/continuous-delivery-metrics.html b/pr-1683/2018/01/31/continuous-delivery-metrics.html new file mode 100644 index 000000000..696a5b6b3 --- /dev/null +++ b/pr-1683/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-1683/2018/01/31/continuous-delivery-metrics/index.html b/pr-1683/2018/01/31/continuous-delivery-metrics/index.html new file mode 100644 index 000000000..464ea32a9 --- /dev/null +++ b/pr-1683/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-1683/2018/01/31/index.html b/pr-1683/2018/01/31/index.html new file mode 100644 index 000000000..41c98567c --- /dev/null +++ b/pr-1683/2018/01/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/01/index.html b/pr-1683/2018/01/index.html new file mode 100644 index 000000000..ec2339497 --- /dev/null +++ b/pr-1683/2018/01/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/02.html b/pr-1683/2018/02.html new file mode 100644 index 000000000..170d758ed --- /dev/null +++ b/pr-1683/2018/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/02/13.html b/pr-1683/2018/02/13.html new file mode 100644 index 000000000..42528f6d6 --- /dev/null +++ b/pr-1683/2018/02/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/02/13/index.html b/pr-1683/2018/02/13/index.html new file mode 100644 index 000000000..e5bd7da30 --- /dev/null +++ b/pr-1683/2018/02/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/02/13/managing-build-versions-pipeline.html b/pr-1683/2018/02/13/managing-build-versions-pipeline.html new file mode 100644 index 000000000..72b8832ef --- /dev/null +++ b/pr-1683/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-1683/2018/02/13/managing-build-versions-pipeline/index.html b/pr-1683/2018/02/13/managing-build-versions-pipeline/index.html new file mode 100644 index 000000000..c5a6af07f --- /dev/null +++ b/pr-1683/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-1683/2018/02/index.html b/pr-1683/2018/02/index.html new file mode 100644 index 000000000..6def83afd --- /dev/null +++ b/pr-1683/2018/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/03.html b/pr-1683/2018/03.html new file mode 100644 index 000000000..2da5e6afd --- /dev/null +++ b/pr-1683/2018/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/03/21.html b/pr-1683/2018/03/21.html new file mode 100644 index 000000000..ea49c1d40 --- /dev/null +++ b/pr-1683/2018/03/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/03/21/continuous-delivery-gocd-kubernetes.html b/pr-1683/2018/03/21/continuous-delivery-gocd-kubernetes.html new file mode 100644 index 000000000..8643e23d2 --- /dev/null +++ b/pr-1683/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-1683/2018/03/21/continuous-delivery-gocd-kubernetes/index.html b/pr-1683/2018/03/21/continuous-delivery-gocd-kubernetes/index.html new file mode 100644 index 000000000..76b8ae233 --- /dev/null +++ b/pr-1683/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-1683/2018/03/21/index.html b/pr-1683/2018/03/21/index.html new file mode 100644 index 000000000..54b72458c --- /dev/null +++ b/pr-1683/2018/03/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 21 2018 +

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

Archive for + Mar 2018 +

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

Archive for + Apr 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/04/25.html b/pr-1683/2018/04/25.html new file mode 100644 index 000000000..0e37c999f --- /dev/null +++ b/pr-1683/2018/04/25.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/04/25/five-considerations-continuous-delivery-microservices.html b/pr-1683/2018/04/25/five-considerations-continuous-delivery-microservices.html new file mode 100644 index 000000000..f9c28072d --- /dev/null +++ b/pr-1683/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-1683/2018/04/25/five-considerations-continuous-delivery-microservices/index.html b/pr-1683/2018/04/25/five-considerations-continuous-delivery-microservices/index.html new file mode 100644 index 000000000..74f59a228 --- /dev/null +++ b/pr-1683/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-1683/2018/04/25/index.html b/pr-1683/2018/04/25/index.html new file mode 100644 index 000000000..479ffcbc2 --- /dev/null +++ b/pr-1683/2018/04/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 25 2018 +

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

Archive for + Apr 2018 +

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

Archive for + May 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/05/08.html b/pr-1683/2018/05/08.html new file mode 100644 index 000000000..391b6830a --- /dev/null +++ b/pr-1683/2018/05/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 8 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/05/08/continuous-delivery-microservices-test-strategy.html b/pr-1683/2018/05/08/continuous-delivery-microservices-test-strategy.html new file mode 100644 index 000000000..25fe95e2b --- /dev/null +++ b/pr-1683/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-1683/2018/05/08/continuous-delivery-microservices-test-strategy/index.html b/pr-1683/2018/05/08/continuous-delivery-microservices-test-strategy/index.html new file mode 100644 index 000000000..13d72b865 --- /dev/null +++ b/pr-1683/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-1683/2018/05/08/index.html b/pr-1683/2018/05/08/index.html new file mode 100644 index 000000000..a90570075 --- /dev/null +++ b/pr-1683/2018/05/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 8 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/05/30.html b/pr-1683/2018/05/30.html new file mode 100644 index 000000000..163b1f958 --- /dev/null +++ b/pr-1683/2018/05/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/05/30/ci-microservices-feature-toggles-trunk-based-development.html b/pr-1683/2018/05/30/ci-microservices-feature-toggles-trunk-based-development.html new file mode 100644 index 000000000..48b34f439 --- /dev/null +++ b/pr-1683/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-1683/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/index.html b/pr-1683/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/index.html new file mode 100644 index 000000000..872cc35ed --- /dev/null +++ b/pr-1683/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-1683/2018/05/30/index.html b/pr-1683/2018/05/30/index.html new file mode 100644 index 000000000..21bc2b611 --- /dev/null +++ b/pr-1683/2018/05/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 30 2018 +

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

Archive for + May 2018 +

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

Archive for + Jun 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/06/12.html b/pr-1683/2018/06/12.html new file mode 100644 index 000000000..572bf2b4e --- /dev/null +++ b/pr-1683/2018/06/12.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 12 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/06/12/cd-microservices-environment-strategy.html b/pr-1683/2018/06/12/cd-microservices-environment-strategy.html new file mode 100644 index 000000000..662acbc88 --- /dev/null +++ b/pr-1683/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-1683/2018/06/12/cd-microservices-environment-strategy/index.html b/pr-1683/2018/06/12/cd-microservices-environment-strategy/index.html new file mode 100644 index 000000000..348aeaddb --- /dev/null +++ b/pr-1683/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-1683/2018/06/12/index.html b/pr-1683/2018/06/12/index.html new file mode 100644 index 000000000..6f147b263 --- /dev/null +++ b/pr-1683/2018/06/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 12 2018 +

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

Archive for + Jun 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07.html b/pr-1683/2018/07.html new file mode 100644 index 000000000..07b7e37f4 --- /dev/null +++ b/pr-1683/2018/07.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/17.html b/pr-1683/2018/07/17.html new file mode 100644 index 000000000..50072fc55 --- /dev/null +++ b/pr-1683/2018/07/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/17/gocd-materials-blacklisting-whitelisting.html b/pr-1683/2018/07/17/gocd-materials-blacklisting-whitelisting.html new file mode 100644 index 000000000..59b71a7bd --- /dev/null +++ b/pr-1683/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-1683/2018/07/17/gocd-materials-blacklisting-whitelisting/index.html b/pr-1683/2018/07/17/gocd-materials-blacklisting-whitelisting/index.html new file mode 100644 index 000000000..2ef7b6f9e --- /dev/null +++ b/pr-1683/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-1683/2018/07/17/index.html b/pr-1683/2018/07/17/index.html new file mode 100644 index 000000000..b10d6e2dc --- /dev/null +++ b/pr-1683/2018/07/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 17 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/24.html b/pr-1683/2018/07/24.html new file mode 100644 index 000000000..c593c48c2 --- /dev/null +++ b/pr-1683/2018/07/24.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 24 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/24/gocd-usage-analytics.html b/pr-1683/2018/07/24/gocd-usage-analytics.html new file mode 100644 index 000000000..703007407 --- /dev/null +++ b/pr-1683/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-1683/2018/07/24/gocd-usage-analytics/index.html b/pr-1683/2018/07/24/gocd-usage-analytics/index.html new file mode 100644 index 000000000..9908c16e3 --- /dev/null +++ b/pr-1683/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-1683/2018/07/24/index.html b/pr-1683/2018/07/24/index.html new file mode 100644 index 000000000..0f0affca2 --- /dev/null +++ b/pr-1683/2018/07/24/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 24 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/31.html b/pr-1683/2018/07/31.html new file mode 100644 index 000000000..d30ce023c --- /dev/null +++ b/pr-1683/2018/07/31.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/31/cd-microservices-configuration-strategy.html b/pr-1683/2018/07/31/cd-microservices-configuration-strategy.html new file mode 100644 index 000000000..ab0331198 --- /dev/null +++ b/pr-1683/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-1683/2018/07/31/cd-microservices-configuration-strategy/index.html b/pr-1683/2018/07/31/cd-microservices-configuration-strategy/index.html new file mode 100644 index 000000000..565d6acee --- /dev/null +++ b/pr-1683/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-1683/2018/07/31/index.html b/pr-1683/2018/07/31/index.html new file mode 100644 index 000000000..d97857c1c --- /dev/null +++ b/pr-1683/2018/07/31/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 31 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/07/index.html b/pr-1683/2018/07/index.html new file mode 100644 index 000000000..eb53175f0 --- /dev/null +++ b/pr-1683/2018/07/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jul 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/08.html b/pr-1683/2018/08.html new file mode 100644 index 000000000..64dc9e3b0 --- /dev/null +++ b/pr-1683/2018/08.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/08/21.html b/pr-1683/2018/08/21.html new file mode 100644 index 000000000..ae1330850 --- /dev/null +++ b/pr-1683/2018/08/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/08/21/index.html b/pr-1683/2018/08/21/index.html new file mode 100644 index 000000000..adffb2f3e --- /dev/null +++ b/pr-1683/2018/08/21/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 21 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/08/21/replacing-gocd-with-gocd.html b/pr-1683/2018/08/21/replacing-gocd-with-gocd.html new file mode 100644 index 000000000..726f05a3a --- /dev/null +++ b/pr-1683/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-1683/2018/08/21/replacing-gocd-with-gocd/index.html b/pr-1683/2018/08/21/replacing-gocd-with-gocd/index.html new file mode 100644 index 000000000..2330fdaf2 --- /dev/null +++ b/pr-1683/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-1683/2018/08/index.html b/pr-1683/2018/08/index.html new file mode 100644 index 000000000..28795e418 --- /dev/null +++ b/pr-1683/2018/08/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/09.html b/pr-1683/2018/09.html new file mode 100644 index 000000000..416d68257 --- /dev/null +++ b/pr-1683/2018/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/09/11.html b/pr-1683/2018/09/11.html new file mode 100644 index 000000000..44431bb48 --- /dev/null +++ b/pr-1683/2018/09/11.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 11 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/09/11/cd-microservices-remediation-strategy.html b/pr-1683/2018/09/11/cd-microservices-remediation-strategy.html new file mode 100644 index 000000000..0fb80a8e2 --- /dev/null +++ b/pr-1683/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-1683/2018/09/11/cd-microservices-remediation-strategy/index.html b/pr-1683/2018/09/11/cd-microservices-remediation-strategy/index.html new file mode 100644 index 000000000..ea58d2df4 --- /dev/null +++ b/pr-1683/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-1683/2018/09/11/index.html b/pr-1683/2018/09/11/index.html new file mode 100644 index 000000000..ad94c3919 --- /dev/null +++ b/pr-1683/2018/09/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 11 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/09/index.html b/pr-1683/2018/09/index.html new file mode 100644 index 000000000..91eca7ec9 --- /dev/null +++ b/pr-1683/2018/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10.html b/pr-1683/2018/10.html new file mode 100644 index 000000000..8be0b78a9 --- /dev/null +++ b/pr-1683/2018/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10/16.html b/pr-1683/2018/10/16.html new file mode 100644 index 000000000..02df7efd2 --- /dev/null +++ b/pr-1683/2018/10/16.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 16 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10/16/index.html b/pr-1683/2018/10/16/index.html new file mode 100644 index 000000000..d389929c4 --- /dev/null +++ b/pr-1683/2018/10/16/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 16 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10/16/new-gocd-features.html b/pr-1683/2018/10/16/new-gocd-features.html new file mode 100644 index 000000000..b6b55b92d --- /dev/null +++ b/pr-1683/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-1683/2018/10/16/new-gocd-features/index.html b/pr-1683/2018/10/16/new-gocd-features/index.html new file mode 100644 index 000000000..d19ebffe6 --- /dev/null +++ b/pr-1683/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-1683/2018/10/30.html b/pr-1683/2018/10/30.html new file mode 100644 index 000000000..e93b74b41 --- /dev/null +++ b/pr-1683/2018/10/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10/30/index.html b/pr-1683/2018/10/30/index.html new file mode 100644 index 000000000..4d17de3e5 --- /dev/null +++ b/pr-1683/2018/10/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/10/30/measure-continuous-delivery-process.html b/pr-1683/2018/10/30/measure-continuous-delivery-process.html new file mode 100644 index 000000000..ab6ddb295 --- /dev/null +++ b/pr-1683/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-1683/2018/10/30/measure-continuous-delivery-process/index.html b/pr-1683/2018/10/30/measure-continuous-delivery-process/index.html new file mode 100644 index 000000000..b9ae14cec --- /dev/null +++ b/pr-1683/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-1683/2018/10/index.html b/pr-1683/2018/10/index.html new file mode 100644 index 000000000..2b1c2ce5c --- /dev/null +++ b/pr-1683/2018/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/11.html b/pr-1683/2018/11.html new file mode 100644 index 000000000..60d8ab20f --- /dev/null +++ b/pr-1683/2018/11.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/11/30.html b/pr-1683/2018/11/30.html new file mode 100644 index 000000000..c5a471ff6 --- /dev/null +++ b/pr-1683/2018/11/30.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/11/30/deployment-frequency.html b/pr-1683/2018/11/30/deployment-frequency.html new file mode 100644 index 000000000..3806b94d6 --- /dev/null +++ b/pr-1683/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-1683/2018/11/30/deployment-frequency/index.html b/pr-1683/2018/11/30/deployment-frequency/index.html new file mode 100644 index 000000000..4f87a51fb --- /dev/null +++ b/pr-1683/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-1683/2018/11/30/index.html b/pr-1683/2018/11/30/index.html new file mode 100644 index 000000000..1d67091c3 --- /dev/null +++ b/pr-1683/2018/11/30/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 30 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/11/index.html b/pr-1683/2018/11/index.html new file mode 100644 index 000000000..1496f65d5 --- /dev/null +++ b/pr-1683/2018/11/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Nov 2018 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/index.html b/pr-1683/2018/index.html new file mode 100644 index 000000000..47c9da9fa --- /dev/null +++ b/pr-1683/2018/index.html @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 1 of 2

+ + + + +

Next page

+ + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/page/2.html b/pr-1683/2018/page/2.html new file mode 100644 index 000000000..03e665685 --- /dev/null +++ b/pr-1683/2018/page/2.html @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2018 +

+ +

Page 2 of 2

+ +

Previous page

+ + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2018/page/2/index.html b/pr-1683/2018/page/2/index.html new file mode 100644 index 000000000..ce5919367 --- /dev/null +++ b/pr-1683/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-1683/2019.html b/pr-1683/2019.html new file mode 100644 index 000000000..1bc4d754c --- /dev/null +++ b/pr-1683/2019.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/01.html b/pr-1683/2019/01.html new file mode 100644 index 000000000..af6e69dee --- /dev/null +++ b/pr-1683/2019/01.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/01/14.html b/pr-1683/2019/01/14.html new file mode 100644 index 000000000..e7fbfa9db --- /dev/null +++ b/pr-1683/2019/01/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/01/14/cd-metrics-deployment-lead-time.html b/pr-1683/2019/01/14/cd-metrics-deployment-lead-time.html new file mode 100644 index 000000000..994d2a918 --- /dev/null +++ b/pr-1683/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-1683/2019/01/14/cd-metrics-deployment-lead-time/index.html b/pr-1683/2019/01/14/cd-metrics-deployment-lead-time/index.html new file mode 100644 index 000000000..e0a7e4ef8 --- /dev/null +++ b/pr-1683/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-1683/2019/01/14/index.html b/pr-1683/2019/01/14/index.html new file mode 100644 index 000000000..9988826b7 --- /dev/null +++ b/pr-1683/2019/01/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/01/index.html b/pr-1683/2019/01/index.html new file mode 100644 index 000000000..5f8dea174 --- /dev/null +++ b/pr-1683/2019/01/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jan 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/03.html b/pr-1683/2019/03.html new file mode 100644 index 000000000..94a8258b9 --- /dev/null +++ b/pr-1683/2019/03.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/03/19.html b/pr-1683/2019/03/19.html new file mode 100644 index 000000000..f05efc399 --- /dev/null +++ b/pr-1683/2019/03/19.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 19 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/03/19/index.html b/pr-1683/2019/03/19/index.html new file mode 100644 index 000000000..84669a44c --- /dev/null +++ b/pr-1683/2019/03/19/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 19 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/03/19/user-authorization-ldap.html b/pr-1683/2019/03/19/user-authorization-ldap.html new file mode 100644 index 000000000..f324b4e8d --- /dev/null +++ b/pr-1683/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-1683/2019/03/19/user-authorization-ldap/index.html b/pr-1683/2019/03/19/user-authorization-ldap/index.html new file mode 100644 index 000000000..7c8ada2e7 --- /dev/null +++ b/pr-1683/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-1683/2019/03/index.html b/pr-1683/2019/03/index.html new file mode 100644 index 000000000..dd20315e1 --- /dev/null +++ b/pr-1683/2019/03/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Mar 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/05.html b/pr-1683/2019/05.html new file mode 100644 index 000000000..128230c2d --- /dev/null +++ b/pr-1683/2019/05.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2019 +

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

Archive for + May 14 2019 +

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

Archive for + May 14 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/05/14/installing-configuring-gocd-gke-using-helm.html b/pr-1683/2019/05/14/installing-configuring-gocd-gke-using-helm.html new file mode 100644 index 000000000..ba7f2455c --- /dev/null +++ b/pr-1683/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-1683/2019/05/14/installing-configuring-gocd-gke-using-helm/index.html b/pr-1683/2019/05/14/installing-configuring-gocd-gke-using-helm/index.html new file mode 100644 index 000000000..972fd1531 --- /dev/null +++ b/pr-1683/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-1683/2019/05/21.html b/pr-1683/2019/05/21.html new file mode 100644 index 000000000..d76f3e099 --- /dev/null +++ b/pr-1683/2019/05/21.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 21 2019 +

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

Archive for + May 21 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/05/21/official-stance-on-java.html b/pr-1683/2019/05/21/official-stance-on-java.html new file mode 100644 index 000000000..ddfb59c43 --- /dev/null +++ b/pr-1683/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-1683/2019/05/21/official-stance-on-java/index.html b/pr-1683/2019/05/21/official-stance-on-java/index.html new file mode 100644 index 000000000..4352abb0e --- /dev/null +++ b/pr-1683/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-1683/2019/05/index.html b/pr-1683/2019/05/index.html new file mode 100644 index 000000000..6444a1efe --- /dev/null +++ b/pr-1683/2019/05/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + May 2019 +

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

Archive for + Jun 2019 +

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

Archive for + Jun 25 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/06/25/GoCD-non-root-containers.html b/pr-1683/2019/06/25/GoCD-non-root-containers.html new file mode 100644 index 000000000..f0a0ad017 --- /dev/null +++ b/pr-1683/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-1683/2019/06/25/GoCD-non-root-containers/index.html b/pr-1683/2019/06/25/GoCD-non-root-containers/index.html new file mode 100644 index 000000000..1943762d4 --- /dev/null +++ b/pr-1683/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-1683/2019/06/25/index.html b/pr-1683/2019/06/25/index.html new file mode 100644 index 000000000..1ca861b41 --- /dev/null +++ b/pr-1683/2019/06/25/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Jun 25 2019 +

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

Archive for + Jun 2019 +

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

Archive for + Aug 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/08/05.html b/pr-1683/2019/08/05.html new file mode 100644 index 000000000..6d7ad0d94 --- /dev/null +++ b/pr-1683/2019/08/05.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html b/pr-1683/2019/08/05/configure-container-registry-gcr-artifact-store-gocd.html new file mode 100644 index 000000000..454f6c352 --- /dev/null +++ b/pr-1683/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-1683/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/index.html b/pr-1683/2019/08/05/configure-container-registry-gcr-artifact-store-gocd/index.html new file mode 100644 index 000000000..1627d0fdc --- /dev/null +++ b/pr-1683/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-1683/2019/08/05/index.html b/pr-1683/2019/08/05/index.html new file mode 100644 index 000000000..05cd6f32a --- /dev/null +++ b/pr-1683/2019/08/05/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Aug 5 2019 +

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

Archive for + Aug 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/09.html b/pr-1683/2019/09.html new file mode 100644 index 000000000..27fe0a8de --- /dev/null +++ b/pr-1683/2019/09.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/09/17.html b/pr-1683/2019/09/17.html new file mode 100644 index 000000000..7520538ed --- /dev/null +++ b/pr-1683/2019/09/17.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 17 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html b/pr-1683/2019/09/17/configure-gocd-agents-kubernetes-static-elastic.html new file mode 100644 index 000000000..9c3ddad53 --- /dev/null +++ b/pr-1683/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-1683/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/index.html b/pr-1683/2019/09/17/configure-gocd-agents-kubernetes-static-elastic/index.html new file mode 100644 index 000000000..9f86e9761 --- /dev/null +++ b/pr-1683/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-1683/2019/09/17/index.html b/pr-1683/2019/09/17/index.html new file mode 100644 index 000000000..89df07a5d --- /dev/null +++ b/pr-1683/2019/09/17/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 17 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/09/index.html b/pr-1683/2019/09/index.html new file mode 100644 index 000000000..02d991631 --- /dev/null +++ b/pr-1683/2019/09/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Sep 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2019/index.html b/pr-1683/2019/index.html new file mode 100644 index 000000000..83240998b --- /dev/null +++ b/pr-1683/2019/index.html @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2019 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020.html b/pr-1683/2020.html new file mode 100644 index 000000000..77f9e8cf1 --- /dev/null +++ b/pr-1683/2020.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2020 +

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

Archive for + Apr 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/04/14.html b/pr-1683/2020/04/14.html new file mode 100644 index 000000000..e0645fce7 --- /dev/null +++ b/pr-1683/2020/04/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 14 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/04/14/gocd-on-kubernetes-using-terraform.html b/pr-1683/2020/04/14/gocd-on-kubernetes-using-terraform.html new file mode 100644 index 000000000..9e19b23f8 --- /dev/null +++ b/pr-1683/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-1683/2020/04/14/gocd-on-kubernetes-using-terraform/index.html b/pr-1683/2020/04/14/gocd-on-kubernetes-using-terraform/index.html new file mode 100644 index 000000000..6a813ff6f --- /dev/null +++ b/pr-1683/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-1683/2020/04/14/index.html b/pr-1683/2020/04/14/index.html new file mode 100644 index 000000000..ef6935e82 --- /dev/null +++ b/pr-1683/2020/04/14/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Apr 14 2020 +

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

Archive for + Apr 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/10.html b/pr-1683/2020/10.html new file mode 100644 index 000000000..e51bca41b --- /dev/null +++ b/pr-1683/2020/10.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/10/11.html b/pr-1683/2020/10/11.html new file mode 100644 index 000000000..f9ec4b5e8 --- /dev/null +++ b/pr-1683/2020/10/11.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 11 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/10/11/index.html b/pr-1683/2020/10/11/index.html new file mode 100644 index 000000000..d7623f523 --- /dev/null +++ b/pr-1683/2020/10/11/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 11 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/10/11/perform-backup-for-gocd-on-kubernetes.html b/pr-1683/2020/10/11/perform-backup-for-gocd-on-kubernetes.html new file mode 100644 index 000000000..c86d4a0b4 --- /dev/null +++ b/pr-1683/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-1683/2020/10/11/perform-backup-for-gocd-on-kubernetes/index.html b/pr-1683/2020/10/11/perform-backup-for-gocd-on-kubernetes/index.html new file mode 100644 index 000000000..9cdab5e56 --- /dev/null +++ b/pr-1683/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-1683/2020/10/11/restore-backup-for-gocd-on-kubernetes.html b/pr-1683/2020/10/11/restore-backup-for-gocd-on-kubernetes.html new file mode 100644 index 000000000..790e32104 --- /dev/null +++ b/pr-1683/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-1683/2020/10/11/restore-backup-for-gocd-on-kubernetes/index.html b/pr-1683/2020/10/11/restore-backup-for-gocd-on-kubernetes/index.html new file mode 100644 index 000000000..c046d2b9c --- /dev/null +++ b/pr-1683/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-1683/2020/10/index.html b/pr-1683/2020/10/index.html new file mode 100644 index 000000000..6d6a2178f --- /dev/null +++ b/pr-1683/2020/10/index.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Oct 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2020/index.html b/pr-1683/2020/index.html new file mode 100644 index 000000000..e337584a3 --- /dev/null +++ b/pr-1683/2020/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2020 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2021.html b/pr-1683/2021.html new file mode 100644 index 000000000..6bc25e4f6 --- /dev/null +++ b/pr-1683/2021.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2021 +

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

Archive for + Dec 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2021/12/14.html b/pr-1683/2021/12/14.html new file mode 100644 index 000000000..85692f7db --- /dev/null +++ b/pr-1683/2021/12/14.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 14 2021 +

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

Archive for + Dec 14 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2021/12/14/log4j-vulnerability.html b/pr-1683/2021/12/14/log4j-vulnerability.html new file mode 100644 index 000000000..4af4a267f --- /dev/null +++ b/pr-1683/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-1683/2021/12/14/log4j-vulnerability/index.html b/pr-1683/2021/12/14/log4j-vulnerability/index.html new file mode 100644 index 000000000..2a5238496 --- /dev/null +++ b/pr-1683/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-1683/2021/12/index.html b/pr-1683/2021/12/index.html new file mode 100644 index 000000000..e1cab8fd0 --- /dev/null +++ b/pr-1683/2021/12/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Dec 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2021/index.html b/pr-1683/2021/index.html new file mode 100644 index 000000000..1b86f1880 --- /dev/null +++ b/pr-1683/2021/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2021 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023.html b/pr-1683/2023.html new file mode 100644 index 000000000..eb0692f66 --- /dev/null +++ b/pr-1683/2023.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023/02.html b/pr-1683/2023/02.html new file mode 100644 index 000000000..fce9d20d8 --- /dev/null +++ b/pr-1683/2023/02.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023/02/13.html b/pr-1683/2023/02/13.html new file mode 100644 index 000000000..615d86083 --- /dev/null +++ b/pr-1683/2023/02/13.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023/02/13/gocd-project-status.html b/pr-1683/2023/02/13/gocd-project-status.html new file mode 100644 index 000000000..c38216418 --- /dev/null +++ b/pr-1683/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-1683/2023/02/13/gocd-project-status/index.html b/pr-1683/2023/02/13/gocd-project-status/index.html new file mode 100644 index 000000000..1ee1c83ae --- /dev/null +++ b/pr-1683/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-1683/2023/02/13/index.html b/pr-1683/2023/02/13/index.html new file mode 100644 index 000000000..8114ea20e --- /dev/null +++ b/pr-1683/2023/02/13/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 13 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023/02/index.html b/pr-1683/2023/02/index.html new file mode 100644 index 000000000..2c64dd7cf --- /dev/null +++ b/pr-1683/2023/02/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + Feb 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/2023/index.html b/pr-1683/2023/index.html new file mode 100644 index 000000000..b04a307dd --- /dev/null +++ b/pr-1683/2023/index.html @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + GoCD - Continuous Delivery + + + + + + + + + +
+
+ + + +
+ +
+ + +

Archive for + 2023 +

+ + + + + + + +
+
+
+
✖ +
+
+ + + diff --git a/pr-1683/SEdaily.html b/pr-1683/SEdaily.html new file mode 100644 index 000000000..0bfdedea2 --- /dev/null +++ b/pr-1683/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-1683/SEdaily/index.html b/pr-1683/SEdaily/index.html new file mode 100644 index 000000000..19e7ea981 --- /dev/null +++ b/pr-1683/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-1683/adwords.txt b/pr-1683/adwords.txt new file mode 100644 index 000000000..500ade381 --- /dev/null +++ b/pr-1683/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-1683/analytics-feedback.html b/pr-1683/analytics-feedback.html new file mode 100644 index 000000000..5714f3133 --- /dev/null +++ b/pr-1683/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-1683/analytics-feedback/index.html b/pr-1683/analytics-feedback/index.html new file mode 100644 index 000000000..ff611bf11 --- /dev/null +++ b/pr-1683/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-1683/analytics.html b/pr-1683/analytics.html new file mode 100644 index 000000000..6f745de06 --- /dev/null +++ b/pr-1683/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-1683/analytics/index.html b/pr-1683/analytics/index.html new file mode 100644 index 000000000..d0ce8b881 --- /dev/null +++ b/pr-1683/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-1683/arrested.html b/pr-1683/arrested.html new file mode 100644 index 000000000..f8149077f --- /dev/null +++ b/pr-1683/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-1683/arrested/index.html b/pr-1683/arrested/index.html new file mode 100644 index 000000000..c04f6df85 --- /dev/null +++ b/pr-1683/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-1683/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf b/pr-1683/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf new file mode 100644 index 000000000..35acda2fa Binary files /dev/null and b/pr-1683/assets/font-awesome/fontawesome-webfont-13b1eab6.ttf differ diff --git a/pr-1683/assets/font-awesome/fontawesome-webfont-28b78224.woff b/pr-1683/assets/font-awesome/fontawesome-webfont-28b78224.woff new file mode 100644 index 000000000..400014a4b Binary files /dev/null and b/pr-1683/assets/font-awesome/fontawesome-webfont-28b78224.woff differ diff --git a/pr-1683/assets/font-awesome/fontawesome-webfont-98a8aa5c.svg b/pr-1683/assets/font-awesome/fontawesome-webfont-98a8aa5c.svg new file mode 100644 index 000000000..855c845e5 --- /dev/null +++ b/pr-1683/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-1683/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 b/pr-1683/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 new file mode 100644 index 000000000..4d13fc604 Binary files /dev/null and b/pr-1683/assets/font-awesome/fontawesome-webfont-d6f48cba.woff2 differ diff --git a/pr-1683/assets/font-awesome/fontawesome-webfont-d980c2ce.eot b/pr-1683/assets/font-awesome/fontawesome-webfont-d980c2ce.eot new file mode 100644 index 000000000..e9f60ca95 Binary files /dev/null and b/pr-1683/assets/font-awesome/fontawesome-webfont-d980c2ce.eot differ diff --git a/pr-1683/assets/gocd-brand-styleguide.zip b/pr-1683/assets/gocd-brand-styleguide.zip new file mode 100644 index 000000000..7a8a3c068 Binary files /dev/null and b/pr-1683/assets/gocd-brand-styleguide.zip differ diff --git a/pr-1683/assets/images/Go_logo-063a2295.png b/pr-1683/assets/images/Go_logo-063a2295.png new file mode 100644 index 000000000..e1c080737 Binary files /dev/null and b/pr-1683/assets/images/Go_logo-063a2295.png differ diff --git a/pr-1683/assets/images/Go_watermark_logo-c6c0c15b.svg b/pr-1683/assets/images/Go_watermark_logo-c6c0c15b.svg new file mode 100644 index 000000000..003cd94ee --- /dev/null +++ b/pr-1683/assets/images/Go_watermark_logo-c6c0c15b.svg @@ -0,0 +1,14 @@ + + + + + + + + diff --git a/pr-1683/assets/images/acceptnace-test-build-time-6e0b8af7.png b/pr-1683/assets/images/acceptnace-test-build-time-6e0b8af7.png new file mode 100644 index 000000000..763a9b8fa Binary files /dev/null and b/pr-1683/assets/images/acceptnace-test-build-time-6e0b8af7.png differ diff --git a/pr-1683/assets/images/add_pipeline-65d0b8ef.gif b/pr-1683/assets/images/add_pipeline-65d0b8ef.gif new file mode 100644 index 000000000..caefa119f Binary files /dev/null and b/pr-1683/assets/images/add_pipeline-65d0b8ef.gif differ diff --git a/pr-1683/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg b/pr-1683/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg new file mode 100644 index 000000000..b66162241 Binary files /dev/null and b/pr-1683/assets/images/analytics-feedback/1053-accelerate-5cedeb47.jpg differ diff --git a/pr-1683/assets/images/analytics-feedback/1053-devops-9230560f.jpg b/pr-1683/assets/images/analytics-feedback/1053-devops-9230560f.jpg new file mode 100644 index 000000000..444ec9431 Binary files /dev/null and b/pr-1683/assets/images/analytics-feedback/1053-devops-9230560f.jpg differ diff --git a/pr-1683/assets/images/analytics-feedback/1053-future-81b38bba.jpg b/pr-1683/assets/images/analytics-feedback/1053-future-81b38bba.jpg new file mode 100644 index 000000000..ad1742786 Binary files /dev/null and b/pr-1683/assets/images/analytics-feedback/1053-future-81b38bba.jpg differ diff --git a/pr-1683/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg b/pr-1683/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg new file mode 100644 index 000000000..5d56581f9 Binary files /dev/null and b/pr-1683/assets/images/analytics-feedback/1053-prizes-bedc6f56.jpg differ diff --git a/pr-1683/assets/images/author-mohan-2781e880.png b/pr-1683/assets/images/author-mohan-2781e880.png new file mode 100644 index 000000000..e4b847682 Binary files /dev/null and b/pr-1683/assets/images/author-mohan-2781e880.png differ diff --git a/pr-1683/assets/images/author-placeholder-b138532c.png b/pr-1683/assets/images/author-placeholder-b138532c.png new file mode 100644 index 000000000..2a26d30d1 Binary files /dev/null and b/pr-1683/assets/images/author-placeholder-b138532c.png differ diff --git a/pr-1683/assets/images/author-wei-f31c41e4.jpg b/pr-1683/assets/images/author-wei-f31c41e4.jpg new file mode 100644 index 000000000..57c55dc42 Binary files /dev/null and b/pr-1683/assets/images/author-wei-f31c41e4.jpg differ diff --git a/pr-1683/assets/images/bg-pattern-470c69ee.png b/pr-1683/assets/images/bg-pattern-470c69ee.png new file mode 100644 index 000000000..9afda79fe Binary files /dev/null and b/pr-1683/assets/images/bg-pattern-470c69ee.png differ diff --git a/pr-1683/assets/images/blog/Permissions1-0658062a.png b/pr-1683/assets/images/blog/Permissions1-0658062a.png new file mode 100644 index 000000000..cf0f9d2e0 Binary files /dev/null and b/pr-1683/assets/images/blog/Permissions1-0658062a.png differ diff --git a/pr-1683/assets/images/blog/Pipeline1-c8a7b4f0.png b/pr-1683/assets/images/blog/Pipeline1-c8a7b4f0.png new file mode 100644 index 000000000..7d2b910bd Binary files /dev/null and b/pr-1683/assets/images/blog/Pipeline1-c8a7b4f0.png differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg b/pr-1683/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg new file mode 100644 index 000000000..f52798385 Binary files /dev/null and b/pr-1683/assets/images/blog/add-performance-testing/add-performance-2b3ca1b1.jpg differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/add-performance-testing-to-your-continuous-delivery-pipeline-f09d6a66.jpg b/pr-1683/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-1683/assets/images/blog/add-performance-testing/add-performance-testing-to-your-continuous-delivery-pipeline-f09d6a66.jpg differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg b/pr-1683/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg new file mode 100644 index 000000000..406c3e691 Binary files /dev/null and b/pr-1683/assets/images/blog/add-performance-testing/load-test-4a8d0de7.jpg differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg b/pr-1683/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg new file mode 100644 index 000000000..60133157e Binary files /dev/null and b/pr-1683/assets/images/blog/add-performance-testing/soak-test-4502bd56.jpg differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg b/pr-1683/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg new file mode 100644 index 000000000..3ad1d962a Binary files /dev/null and b/pr-1683/assets/images/blog/add-performance-testing/spike-test-4b37b4b6.jpg differ diff --git a/pr-1683/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg b/pr-1683/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg new file mode 100644 index 000000000..21ec29795 Binary files /dev/null and b/pr-1683/assets/images/blog/add-performance-testing/stress-test-3a7430f8.jpg differ diff --git a/pr-1683/assets/images/blog/agent-bootstrapper-upgrade-for-plugins/summary_image-925c9056.png b/pr-1683/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-1683/assets/images/blog/agent-bootstrapper-upgrade-for-plugins/summary_image-925c9056.png differ diff --git a/pr-1683/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png b/pr-1683/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png new file mode 100644 index 000000000..bae8672e2 Binary files /dev/null and b/pr-1683/assets/images/blog/agents-environments/agents-environments-hero-1ab3d2e8.png differ diff --git a/pr-1683/assets/images/blog/agents-environments/pipeline-with-environment-agents-4cefb1b7.jpeg b/pr-1683/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-1683/assets/images/blog/agents-environments/pipeline-with-environment-agents-4cefb1b7.jpeg differ diff --git a/pr-1683/assets/images/blog/architecting-continuous-delivery/architecting-continuous-delivery-hero-25ac88c4.jpg b/pr-1683/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-1683/assets/images/blog/architecting-continuous-delivery/architecting-continuous-delivery-hero-25ac88c4.jpg differ diff --git a/pr-1683/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png b/pr-1683/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png new file mode 100644 index 000000000..2b2ef8496 Binary files /dev/null and b/pr-1683/assets/images/blog/architecting-continuous-delivery/gocd-pipeline-3d4714d3.png differ diff --git a/pr-1683/assets/images/blog/architecting-continuous-delivery/ice-cream-test-anti-pattern-32612565.png b/pr-1683/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-1683/assets/images/blog/architecting-continuous-delivery/ice-cream-test-anti-pattern-32612565.png differ diff --git a/pr-1683/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png b/pr-1683/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png new file mode 100644 index 000000000..77a756089 Binary files /dev/null and b/pr-1683/assets/images/blog/architecting-continuous-delivery/rollback-deployment-a69c8139.png differ diff --git a/pr-1683/assets/images/blog/architecting-continuous-delivery/the-deployment-pipeline-6ed8f669.png b/pr-1683/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-1683/assets/images/blog/architecting-continuous-delivery/the-deployment-pipeline-6ed8f669.png differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continous-delivery-infographic/are-you-ready-for-CD-info-hero-ab1ff875.png b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continous-delivery-infographic/are-you-ready-for-CD-info-hero-ab1ff875.png differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continous-delivery-infographic/ready-for-continous-delivery-infographic-5f550770.png b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continous-delivery-infographic/ready-for-continous-delivery-infographic-5f550770.png differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continuous-delivery/feedback_loops-93f9a552.jpg b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continuous-delivery/feedback_loops-93f9a552.jpg differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_delivery_feedback_loops-cb9bdbe3.png b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_delivery_feedback_loops-cb9bdbe3.png differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_integration_feedback_loops-8325bf92.png b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continuous-delivery/gocd_thoughtworks_continuous_integration_feedback_loops-8325bf92.png differ diff --git a/pr-1683/assets/images/blog/are-you-ready-for-continuous-delivery/woodline-02b5f243.jpeg b/pr-1683/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-1683/assets/images/blog/are-you-ready-for-continuous-delivery/woodline-02b5f243.jpeg differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png b/pr-1683/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png new file mode 100644 index 000000000..5e6d898f4 Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/configure-plugin-5a5b3512.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png b/pr-1683/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png new file mode 100644 index 000000000..e565397de Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/generate-oauth-token-3fb15337.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/github-login-18b74573.png b/pr-1683/assets/images/blog/authentication-plugins/github-login-18b74573.png new file mode 100644 index 000000000..73d5f55a5 Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/github-login-18b74573.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png b/pr-1683/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png new file mode 100644 index 000000000..95270e628 Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/list-plugin-56a2f413.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/login-page-b00e9881.png b/pr-1683/assets/images/blog/authentication-plugins/login-page-b00e9881.png new file mode 100644 index 000000000..dc8c1f769 Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/login-page-b00e9881.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png b/pr-1683/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png new file mode 100644 index 000000000..68ad058cc Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/search-user-6d06f1b6.png differ diff --git a/pr-1683/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png b/pr-1683/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png new file mode 100644 index 000000000..323969ab7 Binary files /dev/null and b/pr-1683/assets/images/blog/authentication-plugins/successful-login-a699ce6f.png differ diff --git a/pr-1683/assets/images/blog/beginners-guide-cd/beginners-guide-cd-header-d0a7319f.jpg b/pr-1683/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-1683/assets/images/blog/beginners-guide-cd/beginners-guide-cd-header-d0a7319f.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/beginnings_pipelines_hero-ebbdcaab.jpg b/pr-1683/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-1683/assets/images/blog/beginnings-real-pipeline/beginnings_pipelines_hero-ebbdcaab.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg new file mode 100644 index 000000000..fea7f0a62 Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-01-7fb30a06.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg new file mode 100644 index 000000000..bcf493bb2 Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-02-2e6553b3.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg new file mode 100644 index 000000000..3a5917211 Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-03-7fbc9b91.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg new file mode 100644 index 000000000..10e76b59b Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-04-60925b1e.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg new file mode 100644 index 000000000..d23bdac6f Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-05-c73cf40f.jpg differ diff --git a/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg new file mode 100644 index 000000000..dd9c8068e Binary files /dev/null and b/pr-1683/assets/images/blog/beginnings-real-pipeline/pipeline-06-1243d084.jpg differ diff --git a/pr-1683/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg b/pr-1683/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg new file mode 100644 index 000000000..bab3b4ac2 Binary files /dev/null and b/pr-1683/assets/images/blog/blue-green/blue-green-hero-3f180508.jpg differ diff --git a/pr-1683/assets/images/blog/blue-green/dns-9ac8588f.jpeg b/pr-1683/assets/images/blog/blue-green/dns-9ac8588f.jpeg new file mode 100644 index 000000000..50d4255eb Binary files /dev/null and b/pr-1683/assets/images/blog/blue-green/dns-9ac8588f.jpeg differ diff --git a/pr-1683/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg b/pr-1683/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg new file mode 100644 index 000000000..725d99c96 Binary files /dev/null and b/pr-1683/assets/images/blog/blue-green/load-balancer-1a3e2b12.jpeg differ diff --git a/pr-1683/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg b/pr-1683/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg new file mode 100644 index 000000000..2b5ee272d Binary files /dev/null and b/pr-1683/assets/images/blog/build-propagation/build-propagation-hero-c6cae895.jpg differ diff --git a/pr-1683/assets/images/blog/build-propagation/fan-in-fan-out-774eac6e.jpeg b/pr-1683/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-1683/assets/images/blog/build-propagation/fan-in-fan-out-774eac6e.jpeg differ diff --git a/pr-1683/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg b/pr-1683/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg new file mode 100644 index 000000000..1e806dec4 Binary files /dev/null and b/pr-1683/assets/images/blog/build-propagation/pipeline-dependencies-64bb4fc3.jpeg differ diff --git a/pr-1683/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg b/pr-1683/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg new file mode 100644 index 000000000..4a70b8eea Binary files /dev/null and b/pr-1683/assets/images/blog/build-propagation/pipeline-repos-5e961b5b.jpeg differ diff --git a/pr-1683/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg b/pr-1683/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg new file mode 100644 index 000000000..5201cb8eb Binary files /dev/null and b/pr-1683/assets/images/blog/canary-releases/canary-releases-hero-6370dec9.jpg differ diff --git a/pr-1683/assets/images/blog/cd-confession-gocd/automate-everything-gocd-e047261e.jpeg b/pr-1683/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-1683/assets/images/blog/cd-confession-gocd/automate-everything-gocd-e047261e.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-confession-gocd/continuous-delivery-confessions-gocd-5d3dbaab.png b/pr-1683/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-1683/assets/images/blog/cd-confession-gocd/continuous-delivery-confessions-gocd-5d3dbaab.png differ diff --git a/pr-1683/assets/images/blog/cd-confession-snapci/continuous-delivery-confessions-snapci-de12716b.png b/pr-1683/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-1683/assets/images/blog/cd-confession-snapci/continuous-delivery-confessions-snapci-de12716b.png differ diff --git a/pr-1683/assets/images/blog/cd-confessions-mingle/cd-confessions-mingle-hero-2b7da0fe.jpg b/pr-1683/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-1683/assets/images/blog/cd-confessions-mingle/cd-confessions-mingle-hero-2b7da0fe.jpg differ diff --git a/pr-1683/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png b/pr-1683/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png new file mode 100644 index 000000000..77a756089 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-confessions-mingle/feedback-loops-a69c8139.png differ diff --git a/pr-1683/assets/images/blog/cd-considerations/5-consideration-microservices-gocd-12ad175f.jpg b/pr-1683/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-1683/assets/images/blog/cd-considerations/5-consideration-microservices-gocd-12ad175f.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-considerations/environments-plan-e0ff13b0.jpeg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-considerations/environments-plan-e0ff13b0.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-considerations/hotfix-process-fef37152.jpeg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-considerations/hotfix-process-fef37152.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-considerations/test-strategy-0cde2295.jpeg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-considerations/test-strategy-0cde2295.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-microservices-configuration-strategy-95389633.jpg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-microservices-configuration-strategy-95389633.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-microservices-environment-strategy-0cce5b32.jpg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-microservices-environment-strategy-0cce5b32.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/cd-microservices-remediation-strategy-b0bee309.jpg b/pr-1683/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-1683/assets/images/blog/cd-considerations/cd-microservices-remediation-strategy-b0bee309.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg b/pr-1683/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg new file mode 100644 index 000000000..69aa85d82 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/configuration-strategy-95389633.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/continuous-delivery-remediation-strategy-d02def00.jpeg b/pr-1683/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-1683/assets/images/blog/cd-considerations/continuous-delivery-remediation-strategy-d02def00.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png b/pr-1683/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png new file mode 100644 index 000000000..7a949f975 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/environments-dynamic-provisioning-b19e72d6.png differ diff --git a/pr-1683/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg b/pr-1683/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg new file mode 100644 index 000000000..22d440449 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/environments-plan-e0ff13b0.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png b/pr-1683/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png new file mode 100644 index 000000000..3902603d1 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/feature-toggles-bf40d521.png differ diff --git a/pr-1683/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png b/pr-1683/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png new file mode 100644 index 000000000..0ace00361 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/feature-toggles-diagram-4a61a06d.png differ diff --git a/pr-1683/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg b/pr-1683/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg new file mode 100644 index 000000000..8cec03232 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/hotfix-process-fef37152.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg b/pr-1683/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg new file mode 100644 index 000000000..20f19fffa Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/managing-configuration-6efe2f64.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg b/pr-1683/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg new file mode 100644 index 000000000..b7674b3ee Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/tbd-feature-toggles-bcdf66d0.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg b/pr-1683/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg new file mode 100644 index 000000000..201d07e94 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/test-strategy-0cde2295.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg b/pr-1683/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg new file mode 100644 index 000000000..0a983e70a Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/test-strategy-microservices-a668284d.jpg differ diff --git a/pr-1683/assets/images/blog/cd-considerations/toss.txt b/pr-1683/assets/images/blog/cd-considerations/toss.txt new file mode 100644 index 000000000..79a8839f4 --- /dev/null +++ b/pr-1683/assets/images/blog/cd-considerations/toss.txt @@ -0,0 +1 @@ +throw this away diff --git a/pr-1683/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png b/pr-1683/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png new file mode 100644 index 000000000..2a7e5c50c Binary files /dev/null and b/pr-1683/assets/images/blog/cd-considerations/trunk-based-development-6995662e.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/cd-hacks-gocd-materials-a91363d7.jpg b/pr-1683/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-1683/assets/images/blog/cd-hacks/cd-hacks-gocd-materials-a91363d7.jpg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg b/pr-1683/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg new file mode 100644 index 000000000..4c2b35ec7 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/configure-gocd-kubernetes-54b43f25.jpg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png b/pr-1683/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png new file mode 100644 index 000000000..f688d1b3c Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/edit_material_whitelist-1592dc8d.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png b/pr-1683/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png new file mode 100644 index 000000000..a73391abc Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/fetch_materials-07a717f9.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-add-auth-ldap-397c6a4c.png b/pr-1683/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-1683/assets/images/blog/cd-hacks/gocd-add-auth-ldap-397c6a4c.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-authorize-config-ldap-2440fa39.gif b/pr-1683/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-1683/assets/images/blog/cd-hacks/gocd-authorize-config-ldap-2440fa39.gif differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-create-artifact-store-2-089da79f.png b/pr-1683/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-1683/assets/images/blog/cd-hacks/gocd-create-artifact-store-2-089da79f.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-create-artifact-store-f8aef3b8.png b/pr-1683/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-1683/assets/images/blog/cd-hacks/gocd-create-artifact-store-f8aef3b8.png differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg b/pr-1683/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg new file mode 100644 index 000000000..814bea317 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/gocd-gke-helm-1bd3db0e.jpg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif b/pr-1683/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif new file mode 100644 index 000000000..ac65a72fb Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/gocd-install-ldap-603cddda.gif differ diff --git a/pr-1683/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg b/pr-1683/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg new file mode 100644 index 000000000..80082c1d5 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/gocd-k8s-terraform-ba99de44.jpg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/google-container-registry-artifact-store-034f7207.jpg b/pr-1683/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-1683/assets/images/blog/cd-hacks/google-container-registry-artifact-store-034f7207.jpg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg b/pr-1683/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg new file mode 100644 index 000000000..c27125dab Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/material-blacklisting-5d8fd8c0.jpeg differ diff --git a/pr-1683/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg b/pr-1683/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg new file mode 100644 index 000000000..cc7b837df Binary files /dev/null and b/pr-1683/assets/images/blog/cd-hacks/open-ldap-gocd-04a9f314.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg b/pr-1683/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg new file mode 100644 index 000000000..ac6c7af4f Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/CD-metrics-part2-08356f5b.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png b/pr-1683/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png new file mode 100644 index 000000000..dfc2dd9ca Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/average-cycle-time-7d08aaa7.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg b/pr-1683/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg new file mode 100644 index 000000000..d005fb8f3 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/build-learn-measure-649caa06.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/cd-metrics-example-pipelines-11f24e33.png b/pr-1683/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-1683/assets/images/blog/cd-metrics/cd-metrics-example-pipelines-11f24e33.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/cd-metrics-lead-time-1e8d759a.jpg b/pr-1683/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-1683/assets/images/blog/cd-metrics/cd-metrics-lead-time-1e8d759a.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png b/pr-1683/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png new file mode 100644 index 000000000..a38e20256 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/continuous-delivery-benchmarking-329817c5.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg b/pr-1683/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg new file mode 100644 index 000000000..803b0e5fd Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/deployment-frequency-concept-f47c6623.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png b/pr-1683/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png new file mode 100644 index 000000000..917a5ae8a Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/gocd-pipelines-6356c22e.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg b/pr-1683/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg new file mode 100644 index 000000000..eb4fdec56 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/lead-time-diagram-a4a572a6.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/lead-time-workflow-analytics-91e6cc27.png b/pr-1683/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-1683/assets/images/blog/cd-metrics/lead-time-workflow-analytics-91e6cc27.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png b/pr-1683/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png new file mode 100644 index 000000000..61e375dcd Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/manual-lead-time-30c8d15c.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg b/pr-1683/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg new file mode 100644 index 000000000..f35171f02 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/measure-cd-process-0855a3b2.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/metrics-continuous-delivery-header-85a81e8b.jpg b/pr-1683/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-1683/assets/images/blog/cd-metrics/metrics-continuous-delivery-header-85a81e8b.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/throughput-f47c6623.jpg b/pr-1683/assets/images/blog/cd-metrics/throughput-f47c6623.jpg new file mode 100644 index 000000000..803b0e5fd Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/throughput-f47c6623.jpg differ diff --git a/pr-1683/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png b/pr-1683/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png new file mode 100644 index 000000000..f4cf72175 Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/throughput-gocd-3b8ad603.png differ diff --git a/pr-1683/assets/images/blog/cd-metrics/throughput-manual-feaec385.png b/pr-1683/assets/images/blog/cd-metrics/throughput-manual-feaec385.png new file mode 100644 index 000000000..997dd4e0f Binary files /dev/null and b/pr-1683/assets/images/blog/cd-metrics/throughput-manual-feaec385.png differ diff --git a/pr-1683/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg b/pr-1683/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg new file mode 100644 index 000000000..695dbfe2d Binary files /dev/null and b/pr-1683/assets/images/blog/ci-theatre/ci-theatre-hero-ee863baa.jpg differ diff --git a/pr-1683/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png b/pr-1683/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png new file mode 100644 index 000000000..b835f124b Binary files /dev/null and b/pr-1683/assets/images/blog/cloning-templates/environment-variable-view-33c004e5.png differ diff --git a/pr-1683/assets/images/blog/cloning-templates/trigger-with-options-1-e172b0b5.png b/pr-1683/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-1683/assets/images/blog/cloning-templates/trigger-with-options-1-e172b0b5.png differ diff --git a/pr-1683/assets/images/blog/cloning-templates/trigger-with-options-2-77162996.png b/pr-1683/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-1683/assets/images/blog/cloning-templates/trigger-with-options-2-77162996.png differ diff --git a/pr-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-5f550770.png b/pr-1683/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-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-5f550770.png differ diff --git a/pr-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-hero-ab1ff875.png b/pr-1683/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-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continous-delivery-vs-deployment-infographic-hero-ab1ff875.png differ diff --git a/pr-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continuous-delivery-vs-continuous-deployment-infographic-305dd620.png b/pr-1683/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-1683/assets/images/blog/continous-delivery-vs-deployment-infographic/continuous-delivery-vs-continuous-deployment-infographic-305dd620.png differ diff --git a/pr-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part1-hero-16be1e69.jpg b/pr-1683/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-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part1-hero-16be1e69.jpg differ diff --git a/pr-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part2-hero-c606477c.jpg b/pr-1683/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-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part2-hero-c606477c.jpg differ diff --git a/pr-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part3-hero-a7e89092.jpg b/pr-1683/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-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part3-hero-a7e89092.jpg differ diff --git a/pr-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part4-hero-d6b73c08.jpg b/pr-1683/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-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part4-hero-d6b73c08.jpg differ diff --git a/pr-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part5-hero-3db5a75f.jpg b/pr-1683/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-1683/assets/images/blog/continuous-delivery-101/continuous-delivery-101-part5-hero-3db5a75f.jpg differ diff --git a/pr-1683/assets/images/blog/continuous-deployment-strategies/blue-green-deployments-d73adc69.jpeg b/pr-1683/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-1683/assets/images/blog/continuous-deployment-strategies/blue-green-deployments-d73adc69.jpeg differ diff --git a/pr-1683/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg b/pr-1683/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg new file mode 100644 index 000000000..18e0069bd Binary files /dev/null and b/pr-1683/assets/images/blog/continuous-deployment-strategies/canary-release-5c74ac79.jpeg differ diff --git a/pr-1683/assets/images/blog/continuous-deployment-strategies/continuous-deployment-hero-9ab88d57.jpg b/pr-1683/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-1683/assets/images/blog/continuous-deployment-strategies/continuous-deployment-hero-9ab88d57.jpg differ diff --git a/pr-1683/assets/images/blog/deploy-now/but_it_just_needs_oven-6a40663e.png b/pr-1683/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-1683/assets/images/blog/deploy-now/but_it_just_needs_oven-6a40663e.png differ diff --git a/pr-1683/assets/images/blog/deploy-now/but_it_just_needs_paint-11210336.png b/pr-1683/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-1683/assets/images/blog/deploy-now/but_it_just_needs_paint-11210336.png differ diff --git a/pr-1683/assets/images/blog/deploy-now/but_it_just_needs_recorded-8850667e.png b/pr-1683/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-1683/assets/images/blog/deploy-now/but_it_just_needs_recorded-8850667e.png differ diff --git a/pr-1683/assets/images/blog/deploy-now/continuous_delivery_security_testing_pipeline-af8f0e84.png b/pr-1683/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-1683/assets/images/blog/deploy-now/continuous_delivery_security_testing_pipeline-af8f0e84.png differ diff --git a/pr-1683/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png b/pr-1683/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png new file mode 100644 index 000000000..1616e240c Binary files /dev/null and b/pr-1683/assets/images/blog/deploy-now/security-badge-ac4cc5f1.png differ diff --git a/pr-1683/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png b/pr-1683/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png new file mode 100644 index 000000000..c9cd82cae Binary files /dev/null and b/pr-1683/assets/images/blog/distrubuted-test-execution/summary_image-8bed632c.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png b/pr-1683/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png new file mode 100644 index 000000000..af5411932 Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/agent-pkg-51ae766c.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead-1bb6cb32.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead-1bb6cb32.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png b/pr-1683/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png new file mode 100644 index 000000000..5c62f059f Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/fetch_artifacts-15559133.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png b/pr-1683/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png new file mode 100644 index 000000000..120ca5c26 Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/gocd_artifacts-ce31bb61.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png b/pr-1683/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png new file mode 100644 index 000000000..fc0369e96 Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample-92375ac6.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/package_cmd_label-2f8c10da.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/package_cmd_label-2f8c10da.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png b/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png new file mode 100644 index 000000000..690dc668d Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-6fc7697d.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-as-material-d5920f88.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/pipeline-as-material-d5920f88.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png b/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png new file mode 100644 index 000000000..3ab36e5a4 Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-material-61624efe.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-passed-build-35fe20dd.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/pipeline-passed-build-35fe20dd.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/pipeline-stage-job-acb12e4f.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/pipeline-stage-job-acb12e4f.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png b/pr-1683/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png new file mode 100644 index 000000000..35664d105 Binary files /dev/null and b/pr-1683/assets/images/blog/dotnet-core-gocd/tasks-3c016ad4.png differ diff --git a/pr-1683/assets/images/blog/dotnet-core-gocd/value-stream-map-73b88bd3.png b/pr-1683/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-1683/assets/images/blog/dotnet-core-gocd/value-stream-map-73b88bd3.png differ diff --git a/pr-1683/assets/images/blog/driving-change-devops/cannot-buy-devops-you-can-sell-devops-28115ba7.jpg b/pr-1683/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-1683/assets/images/blog/driving-change-devops/cannot-buy-devops-you-can-sell-devops-28115ba7.jpg differ diff --git a/pr-1683/assets/images/blog/driving-change-devops/driving-change-devops-hero-a5d5b1d4.jpg b/pr-1683/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-1683/assets/images/blog/driving-change-devops/driving-change-devops-hero-a5d5b1d4.jpg differ diff --git a/pr-1683/assets/images/blog/driving-change-devops/part-2-cant-buy-devops-48f30921.jpg b/pr-1683/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-1683/assets/images/blog/driving-change-devops/part-2-cant-buy-devops-48f30921.jpg differ diff --git a/pr-1683/assets/images/blog/driving-change-devops/spreading-devops-adoption-4387ffdb.jpg b/pr-1683/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-1683/assets/images/blog/driving-change-devops/spreading-devops-adoption-4387ffdb.jpg differ diff --git a/pr-1683/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg b/pr-1683/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg new file mode 100644 index 000000000..4853d7d53 Binary files /dev/null and b/pr-1683/assets/images/blog/elastic-agents/elastic-agent-hero-995aca63.jpg differ diff --git a/pr-1683/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg b/pr-1683/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg new file mode 100644 index 000000000..280eb42a3 Binary files /dev/null and b/pr-1683/assets/images/blog/elastic-agents/parallelize-9e407871.jpeg differ diff --git a/pr-1683/assets/images/blog/end-to-end-kubernetes/end-to-end-kubernetes-hero-a52d8df4.jpg b/pr-1683/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-1683/assets/images/blog/end-to-end-kubernetes/end-to-end-kubernetes-hero-a52d8df4.jpg differ diff --git a/pr-1683/assets/images/blog/feature-branch/extract-template-cfd29320.png b/pr-1683/assets/images/blog/feature-branch/extract-template-cfd29320.png new file mode 100644 index 000000000..060638b43 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/extract-template-cfd29320.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/failed-build-bb7a251d.png b/pr-1683/assets/images/blog/feature-branch/failed-build-bb7a251d.png new file mode 100644 index 000000000..4631cfd7d Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/failed-build-bb7a251d.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/mature-ci-cd-setup-f94937bf.png b/pr-1683/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-1683/assets/images/blog/feature-branch/mature-ci-cd-setup-f94937bf.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/plugins-loaded-9903d601.png b/pr-1683/assets/images/blog/feature-branch/plugins-loaded-9903d601.png new file mode 100644 index 000000000..086fa98f0 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/plugins-loaded-9903d601.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png b/pr-1683/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png new file mode 100644 index 000000000..039fe9697 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/replace-material-1-0c4f6bbf.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/replace-material-2-afc048ab.png b/pr-1683/assets/images/blog/feature-branch/replace-material-2-afc048ab.png new file mode 100644 index 000000000..a241af8c6 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/replace-material-2-afc048ab.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/setup-90ad35f1.png b/pr-1683/assets/images/blog/feature-branch/setup-90ad35f1.png new file mode 100644 index 000000000..9ac661fd2 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/setup-90ad35f1.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/trigger-build-aa3c586e.png b/pr-1683/assets/images/blog/feature-branch/trigger-build-aa3c586e.png new file mode 100644 index 000000000..4bfb4dc84 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/trigger-build-aa3c586e.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png b/pr-1683/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png new file mode 100644 index 000000000..24ee0a702 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/update-status-1-b1d0e5b3.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/update-status-2-f94045e6.png b/pr-1683/assets/images/blog/feature-branch/update-status-2-f94045e6.png new file mode 100644 index 000000000..0949b5694 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/update-status-2-f94045e6.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/vsm-59138517.png b/pr-1683/assets/images/blog/feature-branch/vsm-59138517.png new file mode 100644 index 000000000..6b98fae32 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/vsm-59138517.png differ diff --git a/pr-1683/assets/images/blog/feature-branch/with_prs-6626da92.png b/pr-1683/assets/images/blog/feature-branch/with_prs-6626da92.png new file mode 100644 index 000000000..d6829d535 Binary files /dev/null and b/pr-1683/assets/images/blog/feature-branch/with_prs-6626da92.png differ diff --git a/pr-1683/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg b/pr-1683/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg new file mode 100644 index 000000000..f5c19a3e4 Binary files /dev/null and b/pr-1683/assets/images/blog/forever-home/forever-home-hero-640e2d7a.jpg differ diff --git a/pr-1683/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png b/pr-1683/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png new file mode 100644 index 000000000..b7217b373 Binary files /dev/null and b/pr-1683/assets/images/blog/forever-home/gocd-io-domain-c4a15911.png differ diff --git a/pr-1683/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png b/pr-1683/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png new file mode 100644 index 000000000..531d4b59d Binary files /dev/null and b/pr-1683/assets/images/blog/getting-started-resources/summary_image-8d195d0a.png differ diff --git a/pr-1683/assets/images/blog/github-integration/github-issue-link-in-build-cause-e5aa4891.png b/pr-1683/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-1683/assets/images/blog/github-integration/github-issue-link-in-build-cause-e5aa4891.png differ diff --git a/pr-1683/assets/images/blog/github-integration/github-issue-link-in-compare-pipeline-2f73a0c6.png b/pr-1683/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-1683/assets/images/blog/github-integration/github-issue-link-in-compare-pipeline-2f73a0c6.png differ diff --git a/pr-1683/assets/images/blog/github-integration/github-issues-integration-639bff5d.png b/pr-1683/assets/images/blog/github-integration/github-issues-integration-639bff5d.png new file mode 100644 index 000000000..63f6d68c5 Binary files /dev/null and b/pr-1683/assets/images/blog/github-integration/github-issues-integration-639bff5d.png differ diff --git a/pr-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/dieamond-problem-6c3b1401.png b/pr-1683/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-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/dieamond-problem-6c3b1401.png differ diff --git a/pr-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-architecture-f39bda5b.png b/pr-1683/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-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-architecture-f39bda5b.png differ diff --git a/pr-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-fanIn-4f7b1e3b.png b/pr-1683/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-1683/assets/images/blog/go-cd-continuous-delivery-through-pipelines/goCD-fanIn-4f7b1e3b.png differ diff --git a/pr-1683/assets/images/blog/go-moving-to-open-source/gocd-website-as-of-feb-2014-from-archive.org-214753b0.png b/pr-1683/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-1683/assets/images/blog/go-moving-to-open-source/gocd-website-as-of-feb-2014-from-archive.org-214753b0.png differ diff --git a/pr-1683/assets/images/blog/go_14_1_announcement/1_Without_Curl-f0795e21.png b/pr-1683/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-1683/assets/images/blog/go_14_1_announcement/1_Without_Curl-f0795e21.png differ diff --git a/pr-1683/assets/images/blog/go_14_1_announcement/2_With_Curl-ccd04a54.png b/pr-1683/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-1683/assets/images/blog/go_14_1_announcement/2_With_Curl-ccd04a54.png differ diff --git a/pr-1683/assets/images/blog/gocd-and-java-licenses/gocd-java-licenses-header-og-30168501.jpg b/pr-1683/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-1683/assets/images/blog/gocd-and-java-licenses/gocd-java-licenses-header-og-30168501.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-in-2016/9777304813_645817bfdf_h_small_cropped-f28ca58c.jpg b/pr-1683/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-1683/assets/images/blog/gocd-in-2016/9777304813_645817bfdf_h_small_cropped-f28ca58c.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg b/pr-1683/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg new file mode 100644 index 000000000..340dbd010 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-in-2016/summary_image-f28ca58c.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-jenkins/gocd-over-jenkins-hero-e727f77f.jpg b/pr-1683/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-1683/assets/images/blog/gocd-jenkins/gocd-over-jenkins-hero-e727f77f.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-kubernetes-helm-chart/GoCD-deploying-kubernetes-0635fbee.svg b/pr-1683/assets/images/blog/gocd-kubernetes-helm-chart/GoCD-deploying-kubernetes-0635fbee.svg new file mode 100644 index 000000000..1948b2f53 --- /dev/null +++ b/pr-1683/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-1683/assets/images/blog/gocd-kubernetes-helm-chart/gocd-kubernetes-helm-chart-hero-71d9973f.jpg b/pr-1683/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-1683/assets/images/blog/gocd-kubernetes-helm-chart/gocd-kubernetes-helm-chart-hero-71d9973f.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-1b4c4e55.png b/pr-1683/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-1683/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-1b4c4e55.png differ diff --git a/pr-1683/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-c15ee8f8.svg b/pr-1683/assets/images/blog/gocd-kubernetes-helm-chart/kubernetes-cluster-agents-c15ee8f8.svg new file mode 100644 index 000000000..e8d1b07ac --- /dev/null +++ b/pr-1683/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-1683/assets/images/blog/gocd-snap-at-devops-enterprise-summit/summary_image-32888e61.png b/pr-1683/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-1683/assets/images/blog/gocd-snap-at-devops-enterprise-summit/summary_image-32888e61.png differ diff --git a/pr-1683/assets/images/blog/gocd-usage-analytics/gocd-settings-2-c7d8ebf4.png b/pr-1683/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-1683/assets/images/blog/gocd-usage-analytics/gocd-settings-2-c7d8ebf4.png differ diff --git a/pr-1683/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png b/pr-1683/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png new file mode 100644 index 000000000..2911477bd Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-usage-analytics/gocd-settings-3b53fce9.png differ diff --git a/pr-1683/assets/images/blog/gocd-usage-analytics/notification-773fb524.png b/pr-1683/assets/images/blog/gocd-usage-analytics/notification-773fb524.png new file mode 100644 index 000000000..f0627ecaa Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-usage-analytics/notification-773fb524.png differ diff --git a/pr-1683/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg b/pr-1683/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg new file mode 100644 index 000000000..465baf4ac Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-usage-analytics/usage-analytics-cb4affcc.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png b/pr-1683/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png new file mode 100644 index 000000000..ce3ad3087 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-versions/gocd_14_1-c5732d40.png differ diff --git a/pr-1683/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png b/pr-1683/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png new file mode 100644 index 000000000..d8bf1427d Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-versions/gocd_14_3-a3f5bfc9.png differ diff --git a/pr-1683/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png b/pr-1683/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png new file mode 100644 index 000000000..c6a1b7845 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-versions/gocd_14_4-bf679473.png differ diff --git a/pr-1683/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png b/pr-1683/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png new file mode 100644 index 000000000..8cc64bb62 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-versions/gocd_15_1-3e0a1787.png differ diff --git a/pr-1683/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png b/pr-1683/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png new file mode 100644 index 000000000..82f0c1f67 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-versions/gocd_15_2-d6c97247.png differ diff --git a/pr-1683/assets/images/blog/gocd-vs-spinnaker/concerns-CD-workflow-b113290e.jpeg b/pr-1683/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-1683/assets/images/blog/gocd-vs-spinnaker/concerns-CD-workflow-b113290e.jpeg differ diff --git a/pr-1683/assets/images/blog/gocd-vs-spinnaker/gocd-vs-spinnaker-hero-66a667cb.jpg b/pr-1683/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-1683/assets/images/blog/gocd-vs-spinnaker/gocd-vs-spinnaker-hero-66a667cb.jpg differ diff --git a/pr-1683/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png b/pr-1683/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png new file mode 100644 index 000000000..9b8f5f5f1 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-vs-spinnaker/gocd-vsm-e76668b8.png differ diff --git a/pr-1683/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png b/pr-1683/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png new file mode 100644 index 000000000..ec6cea962 Binary files /dev/null and b/pr-1683/assets/images/blog/gocd-vs-spinnaker/spinnaker-pipeline-bee01f81.png differ diff --git a/pr-1683/assets/images/blog/hardly-anyone-knows-cd/01_CD_the_idea_low-res-aa3d8a60.jpg b/pr-1683/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-1683/assets/images/blog/hardly-anyone-knows-cd/01_CD_the_idea_low-res-aa3d8a60.jpg differ diff --git a/pr-1683/assets/images/blog/hello-world-with-go/media_1394063203663-defb74a5.png b/pr-1683/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-1683/assets/images/blog/hello-world-with-go/media_1394063203663-defb74a5.png differ diff --git a/pr-1683/assets/images/blog/hello-world-with-go/media_1394063238598-cc4cd6e6.png b/pr-1683/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-1683/assets/images/blog/hello-world-with-go/media_1394063238598-cc4cd6e6.png differ diff --git a/pr-1683/assets/images/blog/hello-world-with-go/media_1394063327989-43ac29c7.png b/pr-1683/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-1683/assets/images/blog/hello-world-with-go/media_1394063327989-43ac29c7.png differ diff --git a/pr-1683/assets/images/blog/hello-world-with-go/media_1394063391538-70cbaf26.png b/pr-1683/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-1683/assets/images/blog/hello-world-with-go/media_1394063391538-70cbaf26.png differ diff --git a/pr-1683/assets/images/blog/hello-world-with-go/media_1394063534943-251780ef.png b/pr-1683/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-1683/assets/images/blog/hello-world-with-go/media_1394063534943-251780ef.png differ diff --git a/pr-1683/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg b/pr-1683/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg new file mode 100644 index 000000000..856e470d4 Binary files /dev/null and b/pr-1683/assets/images/blog/high-centered-team/sunkcosts_masthead-c1ddda92.jpg differ diff --git a/pr-1683/assets/images/blog/high-centered-team/truck-149df877.jpg b/pr-1683/assets/images/blog/high-centered-team/truck-149df877.jpg new file mode 100644 index 000000000..03c2b684a Binary files /dev/null and b/pr-1683/assets/images/blog/high-centered-team/truck-149df877.jpg differ diff --git a/pr-1683/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg b/pr-1683/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg new file mode 100644 index 000000000..99b3e535a Binary files /dev/null and b/pr-1683/assets/images/blog/hotfix-rollback/deployment-pipeline-hotfix-3d31bdb3.jpeg differ diff --git a/pr-1683/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg b/pr-1683/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg new file mode 100644 index 000000000..5d2f7b48d Binary files /dev/null and b/pr-1683/assets/images/blog/hotfix-rollback/hotfix-rollback-hero-ecabe937.jpg differ diff --git a/pr-1683/assets/images/blog/hotfix-rollback/prod-pipeline-hotfix-stage-5455face.jpeg b/pr-1683/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-1683/assets/images/blog/hotfix-rollback/prod-pipeline-hotfix-stage-5455face.jpeg differ diff --git a/pr-1683/assets/images/blog/how-implement-continuous-delivery-enterprise-java-middleware/summary_image-9864dd87.png b/pr-1683/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-1683/assets/images/blog/how-implement-continuous-delivery-enterprise-java-middleware/summary_image-9864dd87.png differ diff --git a/pr-1683/assets/images/blog/how-to-avoid-brittle-code/how-to-avoid-brittle-code-083942f0.jpg b/pr-1683/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-1683/assets/images/blog/how-to-avoid-brittle-code/how-to-avoid-brittle-code-083942f0.jpg differ diff --git a/pr-1683/assets/images/blog/importance-cd-pipelines/Fast-Feedback-First-3e39eb55.png b/pr-1683/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-1683/assets/images/blog/importance-cd-pipelines/Fast-Feedback-First-3e39eb55.png differ diff --git a/pr-1683/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg b/pr-1683/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg new file mode 100644 index 000000000..30b0d5f3f Binary files /dev/null and b/pr-1683/assets/images/blog/importance-cd-pipelines/build-reuse-83ab8b4a.jpeg differ diff --git a/pr-1683/assets/images/blog/importance-cd-pipelines/importance_pipelines_hero-58d38841.jpg b/pr-1683/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-1683/assets/images/blog/importance-cd-pipelines/importance_pipelines_hero-58d38841.jpg differ diff --git a/pr-1683/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg b/pr-1683/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg new file mode 100644 index 000000000..4f7e6ac82 Binary files /dev/null and b/pr-1683/assets/images/blog/importance-cd-pipelines/magic-364edd88.jpeg differ diff --git a/pr-1683/assets/images/blog/issues/Circle-icons-caution-c3010dc6.svg b/pr-1683/assets/images/blog/issues/Circle-icons-caution-c3010dc6.svg new file mode 100644 index 000000000..12fee87da --- /dev/null +++ b/pr-1683/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-1683/assets/images/blog/issues/issue-0621ef4e.png b/pr-1683/assets/images/blog/issues/issue-0621ef4e.png new file mode 100644 index 000000000..298897581 Binary files /dev/null and b/pr-1683/assets/images/blog/issues/issue-0621ef4e.png differ diff --git a/pr-1683/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png b/pr-1683/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png new file mode 100644 index 000000000..04e259034 Binary files /dev/null and b/pr-1683/assets/images/blog/java-announcements/Duke_Wave-e8fff48c.png differ diff --git a/pr-1683/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png b/pr-1683/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png new file mode 100644 index 000000000..486861333 Binary files /dev/null and b/pr-1683/assets/images/blog/java-announcements/Duke_Wave_Wide-867d8ffb.png differ diff --git a/pr-1683/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg b/pr-1683/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg new file mode 100644 index 000000000..a35061517 --- /dev/null +++ b/pr-1683/assets/images/blog/java-announcements/OpenJDK_logo-9596ed5b.svg @@ -0,0 +1,105 @@ + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/blog/manage-agents-with-docker/small_h-7876947e.png b/pr-1683/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-1683/assets/images/blog/manage-agents-with-docker/small_h-7876947e.png differ diff --git a/pr-1683/assets/images/blog/manage-build-versions/manage-build-versions-hero-c20cdce6.jpg b/pr-1683/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-1683/assets/images/blog/manage-build-versions/manage-build-versions-hero-c20cdce6.jpg differ diff --git a/pr-1683/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg b/pr-1683/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg new file mode 100644 index 000000000..600cb2023 Binary files /dev/null and b/pr-1683/assets/images/blog/manual-gates/dummy-stage-8006248e.jpeg differ diff --git a/pr-1683/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg b/pr-1683/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg new file mode 100644 index 000000000..1e3990b91 Binary files /dev/null and b/pr-1683/assets/images/blog/manual-gates/manual-approval-hero-4d6c9eec.jpg differ diff --git a/pr-1683/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg b/pr-1683/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg new file mode 100644 index 000000000..3c863a9ed Binary files /dev/null and b/pr-1683/assets/images/blog/manual-gates/pipeline-environments-53b88a03.jpeg differ diff --git a/pr-1683/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png b/pr-1683/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png new file mode 100644 index 000000000..1c7db2667 Binary files /dev/null and b/pr-1683/assets/images/blog/manual-gates/pipeline-history-cdb6d8df.png differ diff --git a/pr-1683/assets/images/blog/mark-failfast1-076157dd.png b/pr-1683/assets/images/blog/mark-failfast1-076157dd.png new file mode 100644 index 000000000..d851e5dd5 Binary files /dev/null and b/pr-1683/assets/images/blog/mark-failfast1-076157dd.png differ diff --git a/pr-1683/assets/images/blog/mark-failfast2-39e40b5e.png b/pr-1683/assets/images/blog/mark-failfast2-39e40b5e.png new file mode 100644 index 000000000..078a0f7c9 Binary files /dev/null and b/pr-1683/assets/images/blog/mark-failfast2-39e40b5e.png differ diff --git a/pr-1683/assets/images/blog/mark-failfast3-3b0c6e47.png b/pr-1683/assets/images/blog/mark-failfast3-3b0c6e47.png new file mode 100644 index 000000000..726713e76 Binary files /dev/null and b/pr-1683/assets/images/blog/mark-failfast3-3b0c6e47.png differ diff --git a/pr-1683/assets/images/blog/mark-failfast4-af0026ee.png b/pr-1683/assets/images/blog/mark-failfast4-af0026ee.png new file mode 100644 index 000000000..ce1355e10 Binary files /dev/null and b/pr-1683/assets/images/blog/mark-failfast4-af0026ee.png differ diff --git a/pr-1683/assets/images/blog/mark-failfast5-d9d38b33.png b/pr-1683/assets/images/blog/mark-failfast5-d9d38b33.png new file mode 100644 index 000000000..0db8f585a Binary files /dev/null and b/pr-1683/assets/images/blog/mark-failfast5-d9d38b33.png differ diff --git a/pr-1683/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd-d04ddb52.jpg b/pr-1683/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-1683/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd-d04ddb52.jpg differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/CD-pipeline-f6e59dd8.png b/pr-1683/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-1683/assets/images/blog/mobile-app-cd-gocd/CD-pipeline-f6e59dd8.png differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png b/pr-1683/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png new file mode 100644 index 000000000..afa608757 Binary files /dev/null and b/pr-1683/assets/images/blog/mobile-app-cd-gocd/analytics-dd27692c.png differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/breaking-down-monolith-tests-c699a617.png b/pr-1683/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-1683/assets/images/blog/mobile-app-cd-gocd/breaking-down-monolith-tests-c699a617.png differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/gocd-labels-601cf430.png b/pr-1683/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-1683/assets/images/blog/mobile-app-cd-gocd/gocd-labels-601cf430.png differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/mobile-gocd-hero-7e8b965c.jpg b/pr-1683/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-1683/assets/images/blog/mobile-app-cd-gocd/mobile-gocd-hero-7e8b965c.jpg differ diff --git a/pr-1683/assets/images/blog/mobile-app-cd-gocd/sonarqube-quality-96da80f3.png b/pr-1683/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-1683/assets/images/blog/mobile-app-cd-gocd/sonarqube-quality-96da80f3.png differ diff --git a/pr-1683/assets/images/blog/no-one-agrees-define-ci-cd/affinitywall-3a2cf6af.jpg b/pr-1683/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-1683/assets/images/blog/no-one-agrees-define-ci-cd/affinitywall-3a2cf6af.jpg differ diff --git a/pr-1683/assets/images/blog/no-one-agrees-define-ci-cd/delivery-wordcloud-6fd91655.jpg b/pr-1683/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-1683/assets/images/blog/no-one-agrees-define-ci-cd/delivery-wordcloud-6fd91655.jpg differ diff --git a/pr-1683/assets/images/blog/no-one-agrees-define-ci-cd/deployment-wordcloud-5df3e112.jpg b/pr-1683/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-1683/assets/images/blog/no-one-agrees-define-ci-cd/deployment-wordcloud-5df3e112.jpg differ diff --git a/pr-1683/assets/images/blog/no-one-agrees-define-ci-cd/no-one-can-agree-ci-cd-hero-693779a7.jpg b/pr-1683/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-1683/assets/images/blog/no-one-agrees-define-ci-cd/no-one-can-agree-ci-cd-hero-693779a7.jpg differ diff --git a/pr-1683/assets/images/blog/no-one-agrees-define-ci-cd/tools-5f584a98.jpg b/pr-1683/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-1683/assets/images/blog/no-one-agrees-define-ci-cd/tools-5f584a98.jpg differ diff --git a/pr-1683/assets/images/blog/pipeline-pattern-info/deployment-pipeline-pattern-infographic-3156c1d7.png b/pr-1683/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-1683/assets/images/blog/pipeline-pattern-info/deployment-pipeline-pattern-infographic-3156c1d7.png differ diff --git a/pr-1683/assets/images/blog/pipeline-pattern-info/pipeline-pattern-info-hero-ab1ff875.png b/pr-1683/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-1683/assets/images/blog/pipeline-pattern-info/pipeline-pattern-info-hero-ab1ff875.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png b/pr-1683/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png new file mode 100644 index 000000000..b642855eb Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/fetch-artifact-a8a9593d.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png b/pr-1683/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png new file mode 100644 index 000000000..948d21373 Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/infrastructure-as-code-f02b950c.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png b/pr-1683/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png new file mode 100644 index 000000000..acd664400 Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/parallel-pipelines-c881369f.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png b/pr-1683/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png new file mode 100644 index 000000000..dd50167b0 Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/testing-failures-f00335a2.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png b/pr-1683/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png new file mode 100644 index 000000000..5b65446b7 Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/testing-jobs-e35ab17e.png differ diff --git a/pr-1683/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png b/pr-1683/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png new file mode 100644 index 000000000..a9db07269 Binary files /dev/null and b/pr-1683/assets/images/blog/pipeline-patterns/upload-artifact-9e796eb7.png differ diff --git a/pr-1683/assets/images/blog/pipelines-as-code/pipelines-as-code-hero-a3209f2b.jpg b/pr-1683/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-1683/assets/images/blog/pipelines-as-code/pipelines-as-code-hero-a3209f2b.jpg differ diff --git a/pr-1683/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png b/pr-1683/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png new file mode 100644 index 000000000..1ad5413e0 Binary files /dev/null and b/pr-1683/assets/images/blog/plugin-settings/configure-plugin-8e65ded3.png differ diff --git a/pr-1683/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png b/pr-1683/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png new file mode 100644 index 000000000..64241d1c6 Binary files /dev/null and b/pr-1683/assets/images/blog/plugin-settings/configure-plugin-errors-3678f632.png differ diff --git a/pr-1683/assets/images/blog/plugin-settings/list-plugin-37a71798.png b/pr-1683/assets/images/blog/plugin-settings/list-plugin-37a71798.png new file mode 100644 index 000000000..dffb7fa84 Binary files /dev/null and b/pr-1683/assets/images/blog/plugin-settings/list-plugin-37a71798.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/go-cd-after-devops-a582c350.png b/pr-1683/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-1683/assets/images/blog/product-manager-guide/go-cd-after-devops-a582c350.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/go-cd-before-devops-e2b4d0e9.png b/pr-1683/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-1683/assets/images/blog/product-manager-guide/go-cd-before-devops-e2b4d0e9.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/go-cd-continuous-delivery-6041ff84.png b/pr-1683/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-1683/assets/images/blog/product-manager-guide/go-cd-continuous-delivery-6041ff84.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/go-cd-continuous-deployment-4d9c957d.png b/pr-1683/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-1683/assets/images/blog/product-manager-guide/go-cd-continuous-deployment-4d9c957d.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/go-cd-continuous-integration-0f4a50c1.png b/pr-1683/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-1683/assets/images/blog/product-manager-guide/go-cd-continuous-integration-0f4a50c1.png differ diff --git a/pr-1683/assets/images/blog/product-manager-guide/product-manager-guide-hero-f291ec0f.jpg b/pr-1683/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-1683/assets/images/blog/product-manager-guide/product-manager-guide-hero-f291ec0f.jpg differ diff --git a/pr-1683/assets/images/blog/replacing-gocd/replacing-gocd-with-gocd-c2db4202.jpg b/pr-1683/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-1683/assets/images/blog/replacing-gocd/replacing-gocd-with-gocd-c2db4202.jpg differ diff --git a/pr-1683/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg b/pr-1683/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg new file mode 100644 index 000000000..360f3ef88 Binary files /dev/null and b/pr-1683/assets/images/blog/reusing-pipelines/introducing-template-2a3da5c1.jpeg differ diff --git a/pr-1683/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg b/pr-1683/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg new file mode 100644 index 000000000..6841c7245 Binary files /dev/null and b/pr-1683/assets/images/blog/reusing-pipelines/reusing-pipelines-hero-6de82f68.jpg differ diff --git a/pr-1683/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg b/pr-1683/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg new file mode 100644 index 000000000..200e35ef2 Binary files /dev/null and b/pr-1683/assets/images/blog/reusing-pipelines/simplified-version-62879135.jpeg differ diff --git a/pr-1683/assets/images/blog/run-x-instance/1-021212d2.png b/pr-1683/assets/images/blog/run-x-instance/1-021212d2.png new file mode 100644 index 000000000..2d4653c14 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/1-021212d2.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/10-fe33e252.png b/pr-1683/assets/images/blog/run-x-instance/10-fe33e252.png new file mode 100644 index 000000000..f7551e901 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/10-fe33e252.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/11-1-b8855dee.png b/pr-1683/assets/images/blog/run-x-instance/11-1-b8855dee.png new file mode 100644 index 000000000..090b05452 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/11-1-b8855dee.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/11-2-19aa7f49.png b/pr-1683/assets/images/blog/run-x-instance/11-2-19aa7f49.png new file mode 100644 index 000000000..b258deec5 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/11-2-19aa7f49.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/2-9cb7bf31.png b/pr-1683/assets/images/blog/run-x-instance/2-9cb7bf31.png new file mode 100644 index 000000000..a9b9c73a0 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/2-9cb7bf31.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/3-41b700d0.png b/pr-1683/assets/images/blog/run-x-instance/3-41b700d0.png new file mode 100644 index 000000000..a13fb5584 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/3-41b700d0.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/4-2-53ddc6c0.png b/pr-1683/assets/images/blog/run-x-instance/4-2-53ddc6c0.png new file mode 100644 index 000000000..d0063fc36 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/4-2-53ddc6c0.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/4-9650ff39.png b/pr-1683/assets/images/blog/run-x-instance/4-9650ff39.png new file mode 100644 index 000000000..c0290f046 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/4-9650ff39.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/5-6da0dd74.png b/pr-1683/assets/images/blog/run-x-instance/5-6da0dd74.png new file mode 100644 index 000000000..724f1c4a8 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/5-6da0dd74.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/6-40adc5ae.png b/pr-1683/assets/images/blog/run-x-instance/6-40adc5ae.png new file mode 100644 index 000000000..52f19638f Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/6-40adc5ae.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/7-016f6a36.png b/pr-1683/assets/images/blog/run-x-instance/7-016f6a36.png new file mode 100644 index 000000000..b4250130e Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/7-016f6a36.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/8-b478f0af.png b/pr-1683/assets/images/blog/run-x-instance/8-b478f0af.png new file mode 100644 index 000000000..2e2cc3e5b Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/8-b478f0af.png differ diff --git a/pr-1683/assets/images/blog/run-x-instance/9-9d8fd047.png b/pr-1683/assets/images/blog/run-x-instance/9-9d8fd047.png new file mode 100644 index 000000000..1cca36754 Binary files /dev/null and b/pr-1683/assets/images/blog/run-x-instance/9-9d8fd047.png differ diff --git a/pr-1683/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png b/pr-1683/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png new file mode 100644 index 000000000..4ca6957ef Binary files /dev/null and b/pr-1683/assets/images/blog/sample-virtualbox/Virtualbox_logo-705f7f16.png differ diff --git a/pr-1683/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png b/pr-1683/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png new file mode 100644 index 000000000..4e6465ba5 Binary files /dev/null and b/pr-1683/assets/images/blog/sample-virtualbox/pipelines-af0e50ad.png differ diff --git a/pr-1683/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png b/pr-1683/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png new file mode 100644 index 000000000..8ee61cbf8 Binary files /dev/null and b/pr-1683/assets/images/blog/sample-virtualbox/pipelines-v2-3c5b12e7.png differ diff --git a/pr-1683/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png b/pr-1683/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png new file mode 100644 index 000000000..861ca8e5b Binary files /dev/null and b/pr-1683/assets/images/blog/sample-virtualbox/vsm-8192b7e0.png differ diff --git a/pr-1683/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png b/pr-1683/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png new file mode 100644 index 000000000..1dd7fcf06 Binary files /dev/null and b/pr-1683/assets/images/blog/sample-virtualbox/vsm-v2-96349260.png differ diff --git a/pr-1683/assets/images/blog/security-devops-minimizing-risk/security-devops-hero-3e9a0f07.jpg b/pr-1683/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-1683/assets/images/blog/security-devops-minimizing-risk/security-devops-hero-3e9a0f07.jpg differ diff --git a/pr-1683/assets/images/blog/serverless-continuous-delivery/serverless-continuous-delivery-hero-4a1b2ac1.jpg b/pr-1683/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-1683/assets/images/blog/serverless-continuous-delivery/serverless-continuous-delivery-hero-4a1b2ac1.jpg differ diff --git a/pr-1683/assets/images/blog/serverless-continuous-delivery/traditional-vs-serverless-ee2afc44.jpeg b/pr-1683/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-1683/assets/images/blog/serverless-continuous-delivery/traditional-vs-serverless-ee2afc44.jpeg differ diff --git a/pr-1683/assets/images/blog/set-up-a-go-dev-environment/summary_image-33c07d56.png b/pr-1683/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-1683/assets/images/blog/set-up-a-go-dev-environment/summary_image-33c07d56.png differ diff --git a/pr-1683/assets/images/blog/source-code-for-go-now-available/summary_image-05a17ee5.png b/pr-1683/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-1683/assets/images/blog/source-code-for-go-now-available/summary_image-05a17ee5.png differ diff --git a/pr-1683/assets/images/blog/sriram-buildpromo1-1cbd5825.png b/pr-1683/assets/images/blog/sriram-buildpromo1-1cbd5825.png new file mode 100644 index 000000000..47f168c3a Binary files /dev/null and b/pr-1683/assets/images/blog/sriram-buildpromo1-1cbd5825.png differ diff --git a/pr-1683/assets/images/blog/sriram-package1-8fa6fb41.png b/pr-1683/assets/images/blog/sriram-package1-8fa6fb41.png new file mode 100644 index 000000000..98fa5f33b Binary files /dev/null and b/pr-1683/assets/images/blog/sriram-package1-8fa6fb41.png differ diff --git a/pr-1683/assets/images/blog/sriram-peg1_0-6dafffb1.png b/pr-1683/assets/images/blog/sriram-peg1_0-6dafffb1.png new file mode 100644 index 000000000..45cd67f1b Binary files /dev/null and b/pr-1683/assets/images/blog/sriram-peg1_0-6dafffb1.png differ diff --git a/pr-1683/assets/images/blog/sriram-peg2-9f490080.png b/pr-1683/assets/images/blog/sriram-peg2-9f490080.png new file mode 100644 index 000000000..c80661ab4 Binary files /dev/null and b/pr-1683/assets/images/blog/sriram-peg2-9f490080.png differ diff --git a/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg b/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg new file mode 100644 index 000000000..2f8aad74d Binary files /dev/null and b/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax-hero-a5d5b1d4.jpg differ diff --git a/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg b/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg new file mode 100644 index 000000000..8eb9f38eb Binary files /dev/null and b/pr-1683/assets/images/blog/thoughtworks-apax/thoughtworks-apax_announcement-78953733.jpg differ diff --git a/pr-1683/assets/images/blog/tracingprod1-1c3ed7f0.png b/pr-1683/assets/images/blog/tracingprod1-1c3ed7f0.png new file mode 100644 index 000000000..69da4fa38 Binary files /dev/null and b/pr-1683/assets/images/blog/tracingprod1-1c3ed7f0.png differ diff --git a/pr-1683/assets/images/blog/upcoming-API-changes/summary_image-40154615.png b/pr-1683/assets/images/blog/upcoming-API-changes/summary_image-40154615.png new file mode 100644 index 000000000..107f702df Binary files /dev/null and b/pr-1683/assets/images/blog/upcoming-API-changes/summary_image-40154615.png differ diff --git a/pr-1683/assets/images/blog/using-go-cd-with-custom-certificates/summary_image-55b6cd48.png b/pr-1683/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-1683/assets/images/blog/using-go-cd-with-custom-certificates/summary_image-55b6cd48.png differ diff --git a/pr-1683/assets/images/blog/using-windows-powershell-tasks/PowerShell_5.0_icon-af7bd014.png b/pr-1683/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-1683/assets/images/blog/using-windows-powershell-tasks/PowerShell_5.0_icon-af7bd014.png differ diff --git a/pr-1683/assets/images/blog/using-windows-powershell-tasks/SOURCE_LOCATION.txt b/pr-1683/assets/images/blog/using-windows-powershell-tasks/SOURCE_LOCATION.txt new file mode 100644 index 000000000..434cb1aeb --- /dev/null +++ b/pr-1683/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-1683/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png new file mode 100644 index 000000000..b8f399ae6 Binary files /dev/null and b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-1-b761531e.png differ diff --git a/pr-1683/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png new file mode 100644 index 000000000..300674f5d Binary files /dev/null and b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-2-c64ada41.png differ diff --git a/pr-1683/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png new file mode 100644 index 000000000..21b3f0278 Binary files /dev/null and b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-3-b790e151.png differ diff --git a/pr-1683/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png new file mode 100644 index 000000000..e8d67a7bf Binary files /dev/null and b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-4-f20aa3b0.png differ diff --git a/pr-1683/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png new file mode 100644 index 000000000..17f7f1987 Binary files /dev/null and b/pr-1683/assets/images/blog/webinar-recording/webinar-recording-5-fc90b5f8.png differ diff --git a/pr-1683/assets/images/blog/whats-new-gocd/gocd-analytics-vsm-a734be3e.png b/pr-1683/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-1683/assets/images/blog/whats-new-gocd/gocd-analytics-vsm-a734be3e.png differ diff --git a/pr-1683/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif b/pr-1683/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif new file mode 100644 index 000000000..675e5db8a Binary files /dev/null and b/pr-1683/assets/images/blog/whats-new-gocd/gocd-dashboard-f14ab52a.gif differ diff --git a/pr-1683/assets/images/blog/whats-new-gocd/gocd-java-licensing-30168501.jpg b/pr-1683/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-1683/assets/images/blog/whats-new-gocd/gocd-java-licensing-30168501.jpg differ diff --git a/pr-1683/assets/images/blog/whats-new-gocd/gocd-new-features-99a2019c.jpg b/pr-1683/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-1683/assets/images/blog/whats-new-gocd/gocd-new-features-99a2019c.jpg differ diff --git a/pr-1683/assets/images/blog/why-we-moved-from-go-cd-to-gocd-io/please-standy-by-8a8b64b2.jpg b/pr-1683/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-1683/assets/images/blog/why-we-moved-from-go-cd-to-gocd-io/please-standy-by-8a8b64b2.jpg differ diff --git a/pr-1683/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg b/pr-1683/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg new file mode 100644 index 000000000..0e635e7ad Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/analytics-bkgd-d5ff6a49.jpg differ diff --git a/pr-1683/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg b/pr-1683/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg new file mode 100644 index 000000000..0573132eb Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/matt_photo_testimonial_web-05a481f4.jpg differ diff --git a/pr-1683/assets/images/campaign/analytics/pipeline1-8ac70cb4.png b/pr-1683/assets/images/campaign/analytics/pipeline1-8ac70cb4.png new file mode 100644 index 000000000..33860d10a Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/pipeline1-8ac70cb4.png differ diff --git a/pr-1683/assets/images/campaign/analytics/util1-fb757c80.png b/pr-1683/assets/images/campaign/analytics/util1-fb757c80.png new file mode 100644 index 000000000..9e9c376ac Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/util1-fb757c80.png differ diff --git a/pr-1683/assets/images/campaign/analytics/vsm1-13668439.jpg b/pr-1683/assets/images/campaign/analytics/vsm1-13668439.jpg new file mode 100644 index 000000000..e65056dad Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/vsm1-13668439.jpg differ diff --git a/pr-1683/assets/images/campaign/analytics/waittime1-7b27dbc4.png b/pr-1683/assets/images/campaign/analytics/waittime1-7b27dbc4.png new file mode 100644 index 000000000..ce301d788 Binary files /dev/null and b/pr-1683/assets/images/campaign/analytics/waittime1-7b27dbc4.png differ diff --git a/pr-1683/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg b/pr-1683/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg new file mode 100644 index 000000000..e175a6db4 Binary files /dev/null and b/pr-1683/assets/images/campaign/cd101/815-booklet-mockup-40c8ffce.jpg differ diff --git a/pr-1683/assets/images/campaign/cd101/cd101-banner-4869e4af.png b/pr-1683/assets/images/campaign/cd101/cd101-banner-4869e4af.png new file mode 100644 index 000000000..a84c05f15 Binary files /dev/null and b/pr-1683/assets/images/campaign/cd101/cd101-banner-4869e4af.png differ diff --git a/pr-1683/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png b/pr-1683/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png new file mode 100644 index 000000000..a0a4dc9ad Binary files /dev/null and b/pr-1683/assets/images/campaign/cd101/cd101-banner-blank-4ef9359a.png differ diff --git a/pr-1683/assets/images/campaign/cd101/cd101-banner2-fed55b97.png b/pr-1683/assets/images/campaign/cd101/cd101-banner2-fed55b97.png new file mode 100644 index 000000000..9fb71b42f Binary files /dev/null and b/pr-1683/assets/images/campaign/cd101/cd101-banner2-fed55b97.png differ diff --git a/pr-1683/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf b/pr-1683/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf new file mode 100644 index 000000000..252878b03 Binary files /dev/null and b/pr-1683/assets/images/campaign/cd101/ebook-continuous-delivery-101.pdf differ diff --git a/pr-1683/assets/images/campaign/ebook-cd-analytics/ebook-analytics-banner-6764ab2f.jpg b/pr-1683/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-1683/assets/images/campaign/ebook-cd-analytics/ebook-analytics-banner-6764ab2f.jpg differ diff --git a/pr-1683/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf b/pr-1683/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf new file mode 100644 index 000000000..be7f0ea77 Binary files /dev/null and b/pr-1683/assets/images/campaign/ebook-cd-analytics/ebook-cd-analytics.pdf differ diff --git a/pr-1683/assets/images/campaign/ebook-cd-analytics/w-analytics-mockup-c8c186cc.png b/pr-1683/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-1683/assets/images/campaign/ebook-cd-analytics/w-analytics-mockup-c8c186cc.png differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg b/pr-1683/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg new file mode 100644 index 000000000..e6f10cbea Binary files /dev/null and b/pr-1683/assets/images/campaign/elastic-agents/771--hero-0ca41611.jpg differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/771-spot_illo_1-be2fe817.png b/pr-1683/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-1683/assets/images/campaign/elastic-agents/771-spot_illo_1-be2fe817.png differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/771-spot_illo_2-95655f15.png b/pr-1683/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-1683/assets/images/campaign/elastic-agents/771-spot_illo_2-95655f15.png differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/771-spot_illo_3-59bccaf1.png b/pr-1683/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-1683/assets/images/campaign/elastic-agents/771-spot_illo_3-59bccaf1.png differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg b/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg new file mode 100644 index 000000000..9c70b4ff2 Binary files /dev/null and b/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner-d74e12d9.jpg differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg b/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg new file mode 100644 index 000000000..9ba6512fe Binary files /dev/null and b/pr-1683/assets/images/campaign/elastic-agents/elastic-agents-banner1-f33fbef8.jpg differ diff --git a/pr-1683/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg b/pr-1683/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg new file mode 100644 index 000000000..c0fd3633d --- /dev/null +++ b/pr-1683/assets/images/campaign/elastic-agents/icons_plug-15f84b59.svg @@ -0,0 +1,37 @@ + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg b/pr-1683/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg new file mode 100644 index 000000000..4630ea996 --- /dev/null +++ b/pr-1683/assets/images/campaign/elastic-agents/icons_plug-point-c55b9041.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg b/pr-1683/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg new file mode 100644 index 000000000..f0237be30 --- /dev/null +++ b/pr-1683/assets/images/campaign/elastic-agents/icons_tick-28de127f.svg @@ -0,0 +1,13 @@ + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/adblock-6fed935d.svg b/pr-1683/assets/images/campaign/enterprise/adblock-6fed935d.svg new file mode 100644 index 000000000..dc4932082 --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/adblock-6fed935d.svg @@ -0,0 +1,32 @@ + + Asset 1 + + + + + + + + + + + + + + + + + + + + + + + + Please turn offadblockersto see oursignup form. + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/business-611be55b.svg b/pr-1683/assets/images/campaign/enterprise/business-611be55b.svg new file mode 100644 index 000000000..ed3cea77b --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/business-611be55b.svg @@ -0,0 +1,29 @@ + + + + + + + + + + + + + + + 870-business copy 3 + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg b/pr-1683/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg new file mode 100644 index 000000000..6c8eed045 Binary files /dev/null and b/pr-1683/assets/images/campaign/enterprise/ccoal_bkgd-91448e8b.jpg differ diff --git a/pr-1683/assets/images/campaign/enterprise/ec2-b607824f.svg b/pr-1683/assets/images/campaign/enterprise/ec2-b607824f.svg new file mode 100644 index 000000000..3fc4c9c90 --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/ec2-b607824f.svg @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + + + + + ec2 + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg new file mode 100644 index 000000000..0462ff0a6 Binary files /dev/null and b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test1-d837841d.jpg differ diff --git a/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg new file mode 100644 index 000000000..dc21be161 Binary files /dev/null and b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test2-31802b54.jpg differ diff --git a/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg new file mode 100644 index 000000000..4e13cc62b Binary files /dev/null and b/pr-1683/assets/images/campaign/enterprise/ent-bkgd-test3-5a086c8c.jpg differ diff --git a/pr-1683/assets/images/campaign/enterprise/postgres-82a803cd.svg b/pr-1683/assets/images/campaign/enterprise/postgres-82a803cd.svg new file mode 100644 index 000000000..33109b15a --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/postgres-82a803cd.svg @@ -0,0 +1,21 @@ + + + + + + + + + + 870-postgres copy 2 + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/security-2897cd2a.svg b/pr-1683/assets/images/campaign/enterprise/security-2897cd2a.svg new file mode 100644 index 000000000..f7da9ee26 --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/security-2897cd2a.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + security + + + diff --git a/pr-1683/assets/images/campaign/enterprise/support-8ca9a904.svg b/pr-1683/assets/images/campaign/enterprise/support-8ca9a904.svg new file mode 100644 index 000000000..dcbc61f57 --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/support-8ca9a904.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + + + + 870-support copy + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg b/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg new file mode 100644 index 000000000..1260c24ba --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial-01-b56ec8fd.svg @@ -0,0 +1,665 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg b/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg new file mode 100644 index 000000000..c80bb4208 --- /dev/null +++ b/pr-1683/assets/images/campaign/enterprise/ui_illo_commercial_2-1db00c77.svg @@ -0,0 +1,507 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg b/pr-1683/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg new file mode 100644 index 000000000..53974d766 Binary files /dev/null and b/pr-1683/assets/images/campaign/jenkins/jenkins-hero-3-04215858.jpg differ diff --git a/pr-1683/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg b/pr-1683/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg new file mode 100644 index 000000000..8070fb74b Binary files /dev/null and b/pr-1683/assets/images/campaign/jenkins/jenkins-hero-ca8f8af3.jpg differ diff --git a/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg b/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg new file mode 100644 index 000000000..3d7db9347 Binary files /dev/null and b/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-a3f53758.jpg differ diff --git a/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg b/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg new file mode 100644 index 000000000..76c3c22e1 Binary files /dev/null and b/pr-1683/assets/images/campaign/kubernetes/k8s-bkgd-blk-58c33514.jpg differ diff --git a/pr-1683/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg b/pr-1683/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg new file mode 100644 index 000000000..e8d1b07ac --- /dev/null +++ b/pr-1683/assets/images/campaign/kubernetes/k8s-diagram-c15ee8f8.svg @@ -0,0 +1,248 @@ + + + + + + + + + + + + + + + + + + + 890-K8_ILLO_outline_revision + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg b/pr-1683/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg new file mode 100644 index 000000000..457c59e02 --- /dev/null +++ b/pr-1683/assets/images/campaign/kubernetes/ui_illo_commercial_2-8ea6f1e8.svg @@ -0,0 +1,508 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg b/pr-1683/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg new file mode 100644 index 000000000..fb4b754b5 Binary files /dev/null and b/pr-1683/assets/images/campaign/test-drive/halftone_bkgd_03-b22151f1.jpg differ diff --git a/pr-1683/assets/images/contact-section-background-a4da15b4.jpg b/pr-1683/assets/images/contact-section-background-a4da15b4.jpg new file mode 100644 index 000000000..3f4be8af0 Binary files /dev/null and b/pr-1683/assets/images/contact-section-background-a4da15b4.jpg differ diff --git a/pr-1683/assets/images/customer-logos/ancestry-fa92ee57.jpg b/pr-1683/assets/images/customer-logos/ancestry-fa92ee57.jpg new file mode 100644 index 000000000..ff80d0089 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/ancestry-fa92ee57.jpg differ diff --git a/pr-1683/assets/images/customer-logos/autotrader-4dec0c58.jpg b/pr-1683/assets/images/customer-logos/autotrader-4dec0c58.jpg new file mode 100644 index 000000000..c64c1f7b2 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/autotrader-4dec0c58.jpg differ diff --git a/pr-1683/assets/images/customer-logos/barclaycard-86f6dd22.jpg b/pr-1683/assets/images/customer-logos/barclaycard-86f6dd22.jpg new file mode 100644 index 000000000..cf62a4422 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/barclaycard-86f6dd22.jpg differ diff --git a/pr-1683/assets/images/customer-logos/bt-fe7c6f66.jpg b/pr-1683/assets/images/customer-logos/bt-fe7c6f66.jpg new file mode 100644 index 000000000..997027771 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/bt-fe7c6f66.jpg differ diff --git a/pr-1683/assets/images/customer-logos/haufe-e5b70aab.jpg b/pr-1683/assets/images/customer-logos/haufe-e5b70aab.jpg new file mode 100644 index 000000000..e947993e8 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/haufe-e5b70aab.jpg differ diff --git a/pr-1683/assets/images/customer-logos/hoovers-80eda3f2.jpg b/pr-1683/assets/images/customer-logos/hoovers-80eda3f2.jpg new file mode 100644 index 000000000..ea8bcd575 Binary files /dev/null and b/pr-1683/assets/images/customer-logos/hoovers-80eda3f2.jpg differ diff --git a/pr-1683/assets/images/customer-logos/medidata-b4b4285b.jpg b/pr-1683/assets/images/customer-logos/medidata-b4b4285b.jpg new file mode 100644 index 000000000..0a004e91c Binary files /dev/null and b/pr-1683/assets/images/customer-logos/medidata-b4b4285b.jpg differ diff --git a/pr-1683/assets/images/customer-logos/nike-8f9e91cd.jpg b/pr-1683/assets/images/customer-logos/nike-8f9e91cd.jpg new file mode 100644 index 000000000..9e70f7acb Binary files /dev/null and b/pr-1683/assets/images/customer-logos/nike-8f9e91cd.jpg differ diff --git a/pr-1683/assets/images/deploy-any-version-d66b0f45.png b/pr-1683/assets/images/deploy-any-version-d66b0f45.png new file mode 100644 index 000000000..9df3e1cfe Binary files /dev/null and b/pr-1683/assets/images/deploy-any-version-d66b0f45.png differ diff --git a/pr-1683/assets/images/dld-deb-c037d30e.svg b/pr-1683/assets/images/dld-deb-c037d30e.svg new file mode 100644 index 000000000..554542829 --- /dev/null +++ b/pr-1683/assets/images/dld-deb-c037d30e.svg @@ -0,0 +1 @@ +Asset 7 \ No newline at end of file diff --git a/pr-1683/assets/images/dld-docker-54779d1e.svg b/pr-1683/assets/images/dld-docker-54779d1e.svg new file mode 100644 index 000000000..fc54ed5ca --- /dev/null +++ b/pr-1683/assets/images/dld-docker-54779d1e.svg @@ -0,0 +1,13 @@ + + + + + + + + + + + + + \ No newline at end of file diff --git a/pr-1683/assets/images/dld-k8s-df3afe16.svg b/pr-1683/assets/images/dld-k8s-df3afe16.svg new file mode 100644 index 000000000..bedd3b88e --- /dev/null +++ b/pr-1683/assets/images/dld-k8s-df3afe16.svg @@ -0,0 +1,84 @@ + + + + + + + + + + image/svg+xml + + + + + + + + + + + + diff --git a/pr-1683/assets/images/dld-osx-cd5f0631.svg b/pr-1683/assets/images/dld-osx-cd5f0631.svg new file mode 100644 index 000000000..97ed91186 --- /dev/null +++ b/pr-1683/assets/images/dld-osx-cd5f0631.svg @@ -0,0 +1,4 @@ + + + + \ No newline at end of file diff --git a/pr-1683/assets/images/dld-rpm-2d7d4dd6.svg b/pr-1683/assets/images/dld-rpm-2d7d4dd6.svg new file mode 100644 index 000000000..9afbec3bf --- /dev/null +++ b/pr-1683/assets/images/dld-rpm-2d7d4dd6.svg @@ -0,0 +1,9 @@ + + + + + + + \ No newline at end of file diff --git a/pr-1683/assets/images/dld-win-fa0f769a.svg b/pr-1683/assets/images/dld-win-fa0f769a.svg new file mode 100644 index 000000000..cbb5e3e1f --- /dev/null +++ b/pr-1683/assets/images/dld-win-fa0f769a.svg @@ -0,0 +1 @@ +Asset 3 \ No newline at end of file diff --git a/pr-1683/assets/images/dld-zip-073204d1.svg b/pr-1683/assets/images/dld-zip-073204d1.svg new file mode 100644 index 000000000..1648bcfdd --- /dev/null +++ b/pr-1683/assets/images/dld-zip-073204d1.svg @@ -0,0 +1 @@ +Asset 6 \ No newline at end of file diff --git a/pr-1683/assets/images/elastic-agents-bg-d6debd33.jpg b/pr-1683/assets/images/elastic-agents-bg-d6debd33.jpg new file mode 100644 index 000000000..0d0b0480c Binary files /dev/null and b/pr-1683/assets/images/elastic-agents-bg-d6debd33.jpg differ diff --git a/pr-1683/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png b/pr-1683/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png new file mode 100644 index 000000000..d6eeb1f6d Binary files /dev/null and b/pr-1683/assets/images/enterprise-Analytics-forAddons-8fabc3e1.png differ diff --git a/pr-1683/assets/images/enterprise-sales-al-aef0859e.jpg b/pr-1683/assets/images/enterprise-sales-al-aef0859e.jpg new file mode 100644 index 000000000..c2ad4200c Binary files /dev/null and b/pr-1683/assets/images/enterprise-sales-al-aef0859e.jpg differ diff --git a/pr-1683/assets/images/enterprise-sales-craig-535f8939.jpg b/pr-1683/assets/images/enterprise-sales-craig-535f8939.jpg new file mode 100644 index 000000000..63bf92ae4 Binary files /dev/null and b/pr-1683/assets/images/enterprise-sales-craig-535f8939.jpg differ diff --git a/pr-1683/assets/images/enterprise-sales-rupesh-67d31c82.jpg b/pr-1683/assets/images/enterprise-sales-rupesh-67d31c82.jpg new file mode 100644 index 000000000..098300c9d Binary files /dev/null and b/pr-1683/assets/images/enterprise-sales-rupesh-67d31c82.jpg differ diff --git a/pr-1683/assets/images/external-link-728fc441.svg b/pr-1683/assets/images/external-link-728fc441.svg new file mode 100644 index 000000000..b18f652ed --- /dev/null +++ b/pr-1683/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-1683/assets/images/favicon.ico b/pr-1683/assets/images/favicon.ico new file mode 100644 index 000000000..fab7ad966 Binary files /dev/null and b/pr-1683/assets/images/favicon.ico differ diff --git a/pr-1683/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png b/pr-1683/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png new file mode 100644 index 000000000..e924c0808 Binary files /dev/null and b/pr-1683/assets/images/getting-started/Pipeline-Configuration-page-3be2877e.png differ diff --git a/pr-1683/assets/images/getting-started/a-custom-tab-in-action-6bd08a14.png b/pr-1683/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-1683/assets/images/getting-started/a-custom-tab-in-action-6bd08a14.png differ diff --git a/pr-1683/assets/images/getting-started/adding-a-fetch-artifact-task-143fc605.png b/pr-1683/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-1683/assets/images/getting-started/adding-a-fetch-artifact-task-143fc605.png differ diff --git a/pr-1683/assets/images/getting-started/adding-an-artifact-533dbc7e.png b/pr-1683/assets/images/getting-started/adding-an-artifact-533dbc7e.png new file mode 100644 index 000000000..7fd8b1617 Binary files /dev/null and b/pr-1683/assets/images/getting-started/adding-an-artifact-533dbc7e.png differ diff --git a/pr-1683/assets/images/getting-started/agents-5dab5e8b.png b/pr-1683/assets/images/getting-started/agents-5dab5e8b.png new file mode 100644 index 000000000..271e27e92 Binary files /dev/null and b/pr-1683/assets/images/getting-started/agents-5dab5e8b.png differ diff --git a/pr-1683/assets/images/getting-started/autocompletion-of-the-pipeline-dependency-material-351e8d25.png b/pr-1683/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-1683/assets/images/getting-started/autocompletion-of-the-pipeline-dependency-material-351e8d25.png differ diff --git a/pr-1683/assets/images/getting-started/build-pipeline-ae429bf1.png b/pr-1683/assets/images/getting-started/build-pipeline-ae429bf1.png new file mode 100644 index 000000000..af31e2715 Binary files /dev/null and b/pr-1683/assets/images/getting-started/build-pipeline-ae429bf1.png differ diff --git a/pr-1683/assets/images/getting-started/check-that-the-material-exists-dcaf841d.png b/pr-1683/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-1683/assets/images/getting-started/check-that-the-material-exists-dcaf841d.png differ diff --git a/pr-1683/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png b/pr-1683/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png new file mode 100644 index 000000000..deb79408f Binary files /dev/null and b/pr-1683/assets/images/getting-started/configuring-a-custom-tab-894db0c5.png differ diff --git a/pr-1683/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png b/pr-1683/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png new file mode 100644 index 000000000..fe375090d Binary files /dev/null and b/pr-1683/assets/images/getting-started/create-the-downstream-pipeline-c13b4e17.png differ diff --git a/pr-1683/assets/images/getting-started/custom-command-ea9f5535.png b/pr-1683/assets/images/getting-started/custom-command-ea9f5535.png new file mode 100644 index 000000000..9dae4b5e4 Binary files /dev/null and b/pr-1683/assets/images/getting-started/custom-command-ea9f5535.png differ diff --git a/pr-1683/assets/images/getting-started/dependent-pipelines-in-a-valuestream-map-06de9ca9.png b/pr-1683/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-1683/assets/images/getting-started/dependent-pipelines-in-a-valuestream-map-06de9ca9.png differ diff --git a/pr-1683/assets/images/getting-started/dependent-pipelines-on-the-dashboard-4695ac92.png b/pr-1683/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-1683/assets/images/getting-started/dependent-pipelines-on-the-dashboard-4695ac92.png differ diff --git a/pr-1683/assets/images/getting-started/display-the-contents-of-the-fetched-artifact-6c894245.png b/pr-1683/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-1683/assets/images/getting-started/display-the-contents-of-the-fetched-artifact-6c894245.png differ diff --git a/pr-1683/assets/images/getting-started/env-variables-322e76d2.png b/pr-1683/assets/images/getting-started/env-variables-322e76d2.png new file mode 100644 index 000000000..03fe66649 Binary files /dev/null and b/pr-1683/assets/images/getting-started/env-variables-322e76d2.png differ diff --git a/pr-1683/assets/images/getting-started/fetching-artifacts-from-ancestor-pipelines-c5ce9341.png b/pr-1683/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-1683/assets/images/getting-started/fetching-artifacts-from-ancestor-pipelines-c5ce9341.png differ diff --git a/pr-1683/assets/images/getting-started/first-pipeline-paused-99e91c88.png b/pr-1683/assets/images/getting-started/first-pipeline-paused-99e91c88.png new file mode 100644 index 000000000..3c5bf0848 Binary files /dev/null and b/pr-1683/assets/images/getting-started/first-pipeline-paused-99e91c88.png differ diff --git a/pr-1683/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png b/pr-1683/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png new file mode 100644 index 000000000..b762a4158 Binary files /dev/null and b/pr-1683/assets/images/getting-started/gateways-to-VSM-e9ae0c02.png differ diff --git a/pr-1683/assets/images/getting-started/image17-dc293a0b.png b/pr-1683/assets/images/getting-started/image17-dc293a0b.png new file mode 100644 index 000000000..e6059bf24 Binary files /dev/null and b/pr-1683/assets/images/getting-started/image17-dc293a0b.png differ diff --git a/pr-1683/assets/images/getting-started/initial-job-and-task-ad6e3eca.png b/pr-1683/assets/images/getting-started/initial-job-and-task-ad6e3eca.png new file mode 100644 index 000000000..67761fd33 Binary files /dev/null and b/pr-1683/assets/images/getting-started/initial-job-and-task-ad6e3eca.png differ diff --git a/pr-1683/assets/images/getting-started/job-output-394d7a4a.png b/pr-1683/assets/images/getting-started/job-output-394d7a4a.png new file mode 100644 index 000000000..664d86299 Binary files /dev/null and b/pr-1683/assets/images/getting-started/job-output-394d7a4a.png differ diff --git a/pr-1683/assets/images/getting-started/job-run-details-b5eacb09.png b/pr-1683/assets/images/getting-started/job-run-details-b5eacb09.png new file mode 100644 index 000000000..ae2d0e19d Binary files /dev/null and b/pr-1683/assets/images/getting-started/job-run-details-b5eacb09.png differ diff --git a/pr-1683/assets/images/getting-started/materials-2a974162.png b/pr-1683/assets/images/getting-started/materials-2a974162.png new file mode 100644 index 000000000..024e22e7b Binary files /dev/null and b/pr-1683/assets/images/getting-started/materials-2a974162.png differ diff --git a/pr-1683/assets/images/getting-started/move-the-fetch-artifact-task-to-the-top-68961f7f.png b/pr-1683/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-1683/assets/images/getting-started/move-the-fetch-artifact-task-to-the-top-68961f7f.png differ diff --git a/pr-1683/assets/images/getting-started/name-your-pipeline-cbbe9c97.png b/pr-1683/assets/images/getting-started/name-your-pipeline-cbbe9c97.png new file mode 100644 index 000000000..195fac0c9 Binary files /dev/null and b/pr-1683/assets/images/getting-started/name-your-pipeline-cbbe9c97.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/10a-pipeline-building-dashboard-c22c699b.png b/pr-1683/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-1683/assets/images/getting-started/part-1/10a-pipeline-building-dashboard-c22c699b.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/11a-pipeline-finished-new-dashboard-91e8dfbe.png b/pr-1683/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-1683/assets/images/getting-started/part-1/11a-pipeline-finished-new-dashboard-91e8dfbe.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/12-information-about-the-stage-21da9f48.png b/pr-1683/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-1683/assets/images/getting-started/part-1/12-information-about-the-stage-21da9f48.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/13-output-of-job-4fce197c.png b/pr-1683/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-1683/assets/images/getting-started/part-1/13-output-of-job-4fce197c.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/14-environment-variables-34b793b1.png b/pr-1683/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-1683/assets/images/getting-started/part-1/14-environment-variables-34b793b1.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/15-job-run-details-e55dd48f.png b/pr-1683/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-1683/assets/images/getting-started/part-1/15-job-run-details-e55dd48f.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/1gocd-new-pipeline-page-e94f7b2c.png b/pr-1683/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-1683/assets/images/getting-started/part-1/1gocd-new-pipeline-page-e94f7b2c.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/2-agents-page-ee212887.png b/pr-1683/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-1683/assets/images/getting-started/part-1/2-agents-page-ee212887.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/3-step-1-a772fe86.png b/pr-1683/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-1683/assets/images/getting-started/part-1/3-step-1-a772fe86.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/4-step-2a-9f39d601.png b/pr-1683/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-1683/assets/images/getting-started/part-1/4-step-2a-9f39d601.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/5-step-2b-a50afb00.png b/pr-1683/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-1683/assets/images/getting-started/part-1/5-step-2b-a50afb00.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/6-step-3a-7189499d.png b/pr-1683/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-1683/assets/images/getting-started/part-1/6-step-3a-7189499d.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/7-step-3b-9bcde35c.png b/pr-1683/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-1683/assets/images/getting-started/part-1/7-step-3b-9bcde35c.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/8-step-3c-1bfdef0f.png b/pr-1683/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-1683/assets/images/getting-started/part-1/8-step-3c-1bfdef0f.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/9-pipeline-paused-0facb989.png b/pr-1683/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-1683/assets/images/getting-started/part-1/9-pipeline-paused-0facb989.png differ diff --git a/pr-1683/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg b/pr-1683/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg new file mode 100644 index 000000000..3c0517eb6 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-1/gocd-pipelines-materials-2018-3a418409.svg @@ -0,0 +1,1755 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg b/pr-1683/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg new file mode 100644 index 000000000..ffab0cb77 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-1/gocd-server-and-agents-2018-169513a1.svg @@ -0,0 +1,127 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg b/pr-1683/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg new file mode 100644 index 000000000..c1d4766b3 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-1/gocd-stage-jobs-tasks-2018-5399c80d.svg @@ -0,0 +1,1230 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-2/1-pipeline-configuration-page-08907387.png b/pr-1683/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-1683/assets/images/getting-started/part-2/1-pipeline-configuration-page-08907387.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/10-adding-fetch-artifact-cd85c5b4.png b/pr-1683/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-1683/assets/images/getting-started/part-2/10-adding-fetch-artifact-cd85c5b4.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/11-details-can-be-autocompleted-3378453b.png b/pr-1683/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-1683/assets/images/getting-started/part-2/11-details-can-be-autocompleted-3378453b.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/12-move-the-fetch-artifact-to-top-18eeeed5.png b/pr-1683/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-1683/assets/images/getting-started/part-2/12-move-the-fetch-artifact-to-top-18eeeed5.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/13-contents-of-fetch-artifact-d389e3d3.png b/pr-1683/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-1683/assets/images/getting-started/part-2/13-contents-of-fetch-artifact-d389e3d3.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/14-tasks-should-look-like-this-b45c1798.png b/pr-1683/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-1683/assets/images/getting-started/part-2/14-tasks-should-look-like-this-b45c1798.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/15-output-of-fetched-artifact-974958e8.png b/pr-1683/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-1683/assets/images/getting-started/part-2/15-output-of-fetched-artifact-974958e8.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/16-ancestor-artifacts-vsm-142de56a.png b/pr-1683/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-1683/assets/images/getting-started/part-2/16-ancestor-artifacts-vsm-142de56a.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/17-fetch-from-ancestor-pipeline-074da703.png b/pr-1683/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-1683/assets/images/getting-started/part-2/17-fetch-from-ancestor-pipeline-074da703.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/18-custom-tab-configure-e1e878c6.png b/pr-1683/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-1683/assets/images/getting-started/part-2/18-custom-tab-configure-e1e878c6.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/19-custom-tab-in-action-a2c1dcac.png b/pr-1683/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-1683/assets/images/getting-started/part-2/19-custom-tab-in-action-a2c1dcac.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/2-pipeline-dependency-material-73c42e70.png b/pr-1683/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-1683/assets/images/getting-started/part-2/2-pipeline-dependency-material-73c42e70.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/3-autocompletion-pipeline-material-1737f4e3.png b/pr-1683/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-1683/assets/images/getting-started/part-2/3-autocompletion-pipeline-material-1737f4e3.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/4-create-downstream-pipeline-ae7713c5.png b/pr-1683/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-1683/assets/images/getting-started/part-2/4-create-downstream-pipeline-ae7713c5.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/5-dependent-pipeline-dashboard-19905315.png b/pr-1683/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-1683/assets/images/getting-started/part-2/5-dependent-pipeline-dashboard-19905315.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/6-value-stream-map-8a14c25b.png b/pr-1683/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-1683/assets/images/getting-started/part-2/6-value-stream-map-8a14c25b.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/7-adding-artifact-977cd8a3.png b/pr-1683/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-1683/assets/images/getting-started/part-2/7-adding-artifact-977cd8a3.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/8-artifacts-tab-2a423239.png b/pr-1683/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-1683/assets/images/getting-started/part-2/8-artifacts-tab-2a423239.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/9-contents-of-artifact-52748cf0.png b/pr-1683/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-1683/assets/images/getting-started/part-2/9-contents-of-artifact-52748cf0.png differ diff --git a/pr-1683/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg b/pr-1683/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg new file mode 100644 index 000000000..bed1e9da2 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-2/gocd-pipeline-dependency-material-bd64c6f3.svg @@ -0,0 +1,181 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-3/1-gateways-to-vsm-0e9d70b0.png b/pr-1683/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-1683/assets/images/getting-started/part-3/1-gateways-to-vsm-0e9d70b0.png differ diff --git a/pr-1683/assets/images/getting-started/part-3/2-vsm-of-production-pipeline-80c78046.png b/pr-1683/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-1683/assets/images/getting-started/part-3/2-vsm-of-production-pipeline-80c78046.png differ diff --git a/pr-1683/assets/images/getting-started/part-3/3-vsm-of-build-pipeline-8b12b538.png b/pr-1683/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-1683/assets/images/getting-started/part-3/3-vsm-of-build-pipeline-8b12b538.png differ diff --git a/pr-1683/assets/images/getting-started/part-3/4-pinned-vsm-with-links-8f4c5d92.png b/pr-1683/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-1683/assets/images/getting-started/part-3/4-pinned-vsm-with-links-8f4c5d92.png differ diff --git a/pr-1683/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg b/pr-1683/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg new file mode 100644 index 000000000..e822ce4c9 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-3/deployment-pipeline1-19e8c39a.svg @@ -0,0 +1,500 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg b/pr-1683/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg new file mode 100644 index 000000000..577859572 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-3/deployment-pipeline2-0a138975.svg @@ -0,0 +1,1276 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-3/fan-out-b5681eff.svg b/pr-1683/assets/images/getting-started/part-3/fan-out-b5681eff.svg new file mode 100644 index 000000000..5a0c58be7 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-3/fan-out-b5681eff.svg @@ -0,0 +1,186 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg b/pr-1683/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg new file mode 100644 index 000000000..69163d5e5 --- /dev/null +++ b/pr-1683/assets/images/getting-started/part-3/valuestreammap-in-gocd-fb09ba15.svg @@ -0,0 +1,279 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/getting-started/pipeline-3968f530.png b/pr-1683/assets/images/getting-started/pipeline-3968f530.png new file mode 100644 index 000000000..12f2187d3 Binary files /dev/null and b/pr-1683/assets/images/getting-started/pipeline-3968f530.png differ diff --git a/pr-1683/assets/images/getting-started/pipeline-building-17e80a92.png b/pr-1683/assets/images/getting-started/pipeline-building-17e80a92.png new file mode 100644 index 000000000..b0851002f Binary files /dev/null and b/pr-1683/assets/images/getting-started/pipeline-building-17e80a92.png differ diff --git a/pr-1683/assets/images/getting-started/pipeline-finished-6ab859f9.png b/pr-1683/assets/images/getting-started/pipeline-finished-6ab859f9.png new file mode 100644 index 000000000..fd4a8d57d Binary files /dev/null and b/pr-1683/assets/images/getting-started/pipeline-finished-6ab859f9.png differ diff --git a/pr-1683/assets/images/getting-started/production-pipeline-5136d4e0.png b/pr-1683/assets/images/getting-started/production-pipeline-5136d4e0.png new file mode 100644 index 000000000..2674010ab Binary files /dev/null and b/pr-1683/assets/images/getting-started/production-pipeline-5136d4e0.png differ diff --git a/pr-1683/assets/images/getting-started/stage-information-0040c9a6.png b/pr-1683/assets/images/getting-started/stage-information-0040c9a6.png new file mode 100644 index 000000000..ce336a79b Binary files /dev/null and b/pr-1683/assets/images/getting-started/stage-information-0040c9a6.png differ diff --git a/pr-1683/assets/images/getting-started/start-adding-a-pipeline-dependency-material-bb980ccf.png b/pr-1683/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-1683/assets/images/getting-started/start-adding-a-pipeline-dependency-material-bb980ccf.png differ diff --git a/pr-1683/assets/images/getting-started/the-artifacts-tab-every-job-will-have-one-44b45466.png b/pr-1683/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-1683/assets/images/getting-started/the-artifacts-tab-every-job-will-have-one-44b45466.png differ diff --git a/pr-1683/assets/images/getting-started/the-contents-of-the-artifact-d796debe.png b/pr-1683/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-1683/assets/images/getting-started/the-contents-of-the-artifact-d796debe.png differ diff --git a/pr-1683/assets/images/getting-started/the-details-can-be-autocompleted-20f3be0c.png b/pr-1683/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-1683/assets/images/getting-started/the-details-can-be-autocompleted-20f3be0c.png differ diff --git a/pr-1683/assets/images/getting-started/the-output-the-artifact-is-fetched-and-displayed-9191ccc5.png b/pr-1683/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-1683/assets/images/getting-started/the-output-the-artifact-is-fetched-and-displayed-9191ccc5.png differ diff --git a/pr-1683/assets/images/getting-started/this-is-how-the-tasks-should-look-like-01685645.png b/pr-1683/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-1683/assets/images/getting-started/this-is-how-the-tasks-should-look-like-01685645.png differ diff --git a/pr-1683/assets/images/getting-started/this-is-pipeline-06738393.png b/pr-1683/assets/images/getting-started/this-is-pipeline-06738393.png new file mode 100644 index 000000000..1f9230fe9 Binary files /dev/null and b/pr-1683/assets/images/getting-started/this-is-pipeline-06738393.png differ diff --git a/pr-1683/assets/images/getting-started/use-the-predefined-stage-job-62a795ea.png b/pr-1683/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-1683/assets/images/getting-started/use-the-predefined-stage-job-62a795ea.png differ diff --git a/pr-1683/assets/images/go-banner-1-904dd546.jpg b/pr-1683/assets/images/go-banner-1-904dd546.jpg new file mode 100644 index 000000000..e1d291f22 Binary files /dev/null and b/pr-1683/assets/images/go-banner-1-904dd546.jpg differ diff --git a/pr-1683/assets/images/go-banner-3de3d3a0.jpg b/pr-1683/assets/images/go-banner-3de3d3a0.jpg new file mode 100644 index 000000000..dab3e010a Binary files /dev/null and b/pr-1683/assets/images/go-banner-3de3d3a0.jpg differ diff --git a/pr-1683/assets/images/go-banner-desktop-aac7fdc4.jpg b/pr-1683/assets/images/go-banner-desktop-aac7fdc4.jpg new file mode 100644 index 000000000..d0d73a258 Binary files /dev/null and b/pr-1683/assets/images/go-banner-desktop-aac7fdc4.jpg differ diff --git a/pr-1683/assets/images/go-banner-phone-30701141.jpg b/pr-1683/assets/images/go-banner-phone-30701141.jpg new file mode 100644 index 000000000..9787df1d9 Binary files /dev/null and b/pr-1683/assets/images/go-banner-phone-30701141.jpg differ diff --git a/pr-1683/assets/images/go-banner-phone.jpg-4b6f8001.png b/pr-1683/assets/images/go-banner-phone.jpg-4b6f8001.png new file mode 100644 index 000000000..ebf18cfdd Binary files /dev/null and b/pr-1683/assets/images/go-banner-phone.jpg-4b6f8001.png differ diff --git a/pr-1683/assets/images/go-banner-tablet-b5881e67.jpg b/pr-1683/assets/images/go-banner-tablet-b5881e67.jpg new file mode 100644 index 000000000..82d853faa Binary files /dev/null and b/pr-1683/assets/images/go-banner-tablet-b5881e67.jpg differ diff --git a/pr-1683/assets/images/go-cd-QA-pipeline-64230cf5.png b/pr-1683/assets/images/go-cd-QA-pipeline-64230cf5.png new file mode 100644 index 000000000..1ef90e235 Binary files /dev/null and b/pr-1683/assets/images/go-cd-QA-pipeline-64230cf5.png differ diff --git a/pr-1683/assets/images/go-gauge-report-54cc286b.png b/pr-1683/assets/images/go-gauge-report-54cc286b.png new file mode 100644 index 000000000..b04a29ea9 Binary files /dev/null and b/pr-1683/assets/images/go-gauge-report-54cc286b.png differ diff --git a/pr-1683/assets/images/go-gauge-specs-3d290b06.png b/pr-1683/assets/images/go-gauge-specs-3d290b06.png new file mode 100644 index 000000000..5c0842b9a Binary files /dev/null and b/pr-1683/assets/images/go-gauge-specs-3d290b06.png differ diff --git a/pr-1683/assets/images/go-logo-small-0cc554b3.png b/pr-1683/assets/images/go-logo-small-0cc554b3.png new file mode 100644 index 000000000..ddb7733ae Binary files /dev/null and b/pr-1683/assets/images/go-logo-small-0cc554b3.png differ diff --git a/pr-1683/assets/images/go.cd_Compare-Builds-33d3164a.svg b/pr-1683/assets/images/go.cd_Compare-Builds-33d3164a.svg new file mode 100644 index 000000000..25085082a --- /dev/null +++ b/pr-1683/assets/images/go.cd_Compare-Builds-33d3164a.svg @@ -0,0 +1,157 @@ + + + + + + + + + + + + + + + + + + + P1.31 + P1.32 + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_Deploy-any-version-anytime-d2db9a66.svg b/pr-1683/assets/images/go.cd_Deploy-any-version-anytime-d2db9a66.svg new file mode 100644 index 000000000..c5d32f9e9 --- /dev/null +++ b/pr-1683/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-1683/assets/images/go.cd_Model-complex-workflows-0eb00251.svg b/pr-1683/assets/images/go.cd_Model-complex-workflows-0eb00251.svg new file mode 100644 index 000000000..425721ddc --- /dev/null +++ b/pr-1683/assets/images/go.cd_Model-complex-workflows-0eb00251.svg @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg b/pr-1683/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg new file mode 100644 index 000000000..466f56e10 --- /dev/null +++ b/pr-1683/assets/images/go.cd_See-how-things-really-work-0430fdc2.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_agent-e1db9f64.png b/pr-1683/assets/images/go.cd_agent-e1db9f64.png new file mode 100644 index 000000000..aaeaad965 Binary files /dev/null and b/pr-1683/assets/images/go.cd_agent-e1db9f64.png differ diff --git a/pr-1683/assets/images/go.cd_blog-about-gocd-cbc119dd.svg b/pr-1683/assets/images/go.cd_blog-about-gocd-cbc119dd.svg new file mode 100644 index 000000000..cc3c2a162 --- /dev/null +++ b/pr-1683/assets/images/go.cd_blog-about-gocd-cbc119dd.svg @@ -0,0 +1,148 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_changes-a75c578f.svg b/pr-1683/assets/images/go.cd_changes-a75c578f.svg new file mode 100644 index 000000000..596838e7d --- /dev/null +++ b/pr-1683/assets/images/go.cd_changes-a75c578f.svg @@ -0,0 +1,138 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_code-5d7d3f74.svg b/pr-1683/assets/images/go.cd_code-5d7d3f74.svg new file mode 100644 index 000000000..7d328e269 --- /dev/null +++ b/pr-1683/assets/images/go.cd_code-5d7d3f74.svg @@ -0,0 +1,138 @@ + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_community-a7895dc9.svg b/pr-1683/assets/images/go.cd_community-a7895dc9.svg new file mode 100644 index 000000000..be3cd24d7 --- /dev/null +++ b/pr-1683/assets/images/go.cd_community-a7895dc9.svg @@ -0,0 +1,176 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_decide-66f54e71.svg b/pr-1683/assets/images/go.cd_decide-66f54e71.svg new file mode 100644 index 000000000..06f19952f --- /dev/null +++ b/pr-1683/assets/images/go.cd_decide-66f54e71.svg @@ -0,0 +1,138 @@ + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_dev-documentation-2f137096.svg b/pr-1683/assets/images/go.cd_dev-documentation-2f137096.svg new file mode 100644 index 000000000..75205b163 --- /dev/null +++ b/pr-1683/assets/images/go.cd_dev-documentation-2f137096.svg @@ -0,0 +1,162 @@ + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg b/pr-1683/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg new file mode 100644 index 000000000..a49b90a66 --- /dev/null +++ b/pr-1683/assets/images/go.cd_elliminates-bottlenecks-2d9caee6.svg @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_fork-e81f9737.svg b/pr-1683/assets/images/go.cd_fork-e81f9737.svg new file mode 100644 index 000000000..641679d70 --- /dev/null +++ b/pr-1683/assets/images/go.cd_fork-e81f9737.svg @@ -0,0 +1,143 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_form-cb660f66.svg b/pr-1683/assets/images/go.cd_form-cb660f66.svg new file mode 100644 index 000000000..166493787 --- /dev/null +++ b/pr-1683/assets/images/go.cd_form-cb660f66.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_gitter-8f5a1c91.svg b/pr-1683/assets/images/go.cd_gitter-8f5a1c91.svg new file mode 100644 index 000000000..44dd479bd --- /dev/null +++ b/pr-1683/assets/images/go.cd_gitter-8f5a1c91.svg @@ -0,0 +1,129 @@ + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_gocd-on-github-1b93b87e.svg b/pr-1683/assets/images/go.cd_gocd-on-github-1b93b87e.svg new file mode 100644 index 000000000..72c8d39d4 --- /dev/null +++ b/pr-1683/assets/images/go.cd_gocd-on-github-1b93b87e.svg @@ -0,0 +1,322 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_installation-bcefac0e.svg b/pr-1683/assets/images/go.cd_installation-bcefac0e.svg new file mode 100644 index 000000000..432cafeff --- /dev/null +++ b/pr-1683/assets/images/go.cd_installation-bcefac0e.svg @@ -0,0 +1,169 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_join-community-939c83d9.svg b/pr-1683/assets/images/go.cd_join-community-939c83d9.svg new file mode 100644 index 000000000..b47e77d8e --- /dev/null +++ b/pr-1683/assets/images/go.cd_join-community-939c83d9.svg @@ -0,0 +1,150 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg b/pr-1683/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg new file mode 100644 index 000000000..31dda06e3 --- /dev/null +++ b/pr-1683/assets/images/go.cd_keep-configuration-tidy-c6a43973.svg @@ -0,0 +1,177 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_mailing-list-5daf2f9a.svg b/pr-1683/assets/images/go.cd_mailing-list-5daf2f9a.svg new file mode 100644 index 000000000..cd48984eb --- /dev/null +++ b/pr-1683/assets/images/go.cd_mailing-list-5daf2f9a.svg @@ -0,0 +1,165 @@ + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_merge-eabd7739.svg b/pr-1683/assets/images/go.cd_merge-eabd7739.svg new file mode 100644 index 000000000..e6f54ac36 --- /dev/null +++ b/pr-1683/assets/images/go.cd_merge-eabd7739.svg @@ -0,0 +1,137 @@ + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_other-resources-50299cf1.svg b/pr-1683/assets/images/go.cd_other-resources-50299cf1.svg new file mode 100644 index 000000000..cfa4954f9 --- /dev/null +++ b/pr-1683/assets/images/go.cd_other-resources-50299cf1.svg @@ -0,0 +1,143 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png b/pr-1683/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png new file mode 100644 index 000000000..cbf60f0c7 Binary files /dev/null and b/pr-1683/assets/images/go.cd_pipeline-dependency-material-0eeb8252.png differ diff --git a/pr-1683/assets/images/go.cd_pipelines-materials-e64b8575.svg b/pr-1683/assets/images/go.cd_pipelines-materials-e64b8575.svg new file mode 100644 index 000000000..022e8adf6 --- /dev/null +++ b/pr-1683/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-1683/assets/images/go.cd_plugins-a7a0b91f.svg b/pr-1683/assets/images/go.cd_plugins-a7a0b91f.svg new file mode 100644 index 000000000..6422c87b0 --- /dev/null +++ b/pr-1683/assets/images/go.cd_plugins-a7a0b91f.svg @@ -0,0 +1,145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg b/pr-1683/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg new file mode 100644 index 000000000..74c6ecb15 --- /dev/null +++ b/pr-1683/assets/images/go.cd_promoted-trusted-artifacts-211c04a4.svg @@ -0,0 +1,172 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_pull-request-b418521e.svg b/pr-1683/assets/images/go.cd_pull-request-b418521e.svg new file mode 100644 index 000000000..c667997e8 --- /dev/null +++ b/pr-1683/assets/images/go.cd_pull-request-b418521e.svg @@ -0,0 +1,141 @@ + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_roadmap-a4ec26c2.svg b/pr-1683/assets/images/go.cd_roadmap-a4ec26c2.svg new file mode 100644 index 000000000..8c49282f5 --- /dev/null +++ b/pr-1683/assets/images/go.cd_roadmap-a4ec26c2.svg @@ -0,0 +1,149 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg b/pr-1683/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg new file mode 100644 index 000000000..9d14025cb --- /dev/null +++ b/pr-1683/assets/images/go.cd_run-and-grok-your-tests-a04b0bac.svg @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_server-aff636b1.png b/pr-1683/assets/images/go.cd_server-aff636b1.png new file mode 100644 index 000000000..00a67ce0f Binary files /dev/null and b/pr-1683/assets/images/go.cd_server-aff636b1.png differ diff --git a/pr-1683/assets/images/go.cd_server-and-agents-8a7f4cd3.svg b/pr-1683/assets/images/go.cd_server-and-agents-8a7f4cd3.svg new file mode 100644 index 000000000..2cad7bd1f --- /dev/null +++ b/pr-1683/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-1683/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg b/pr-1683/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg new file mode 100644 index 000000000..2387cc422 --- /dev/null +++ b/pr-1683/assets/images/go.cd_setup-your-first-pipeline-6ece3a98.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_stage-jobs-tasks-a58d5b3b.svg b/pr-1683/assets/images/go.cd_stage-jobs-tasks-a58d5b3b.svg new file mode 100644 index 000000000..f58545157 --- /dev/null +++ b/pr-1683/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-1683/assets/images/go.cd_test-gocd-d32d8061.svg b/pr-1683/assets/images/go.cd_test-gocd-d32d8061.svg new file mode 100644 index 000000000..4fdb4fbfb --- /dev/null +++ b/pr-1683/assets/images/go.cd_test-gocd-d32d8061.svg @@ -0,0 +1,156 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_trust-your-team-ae0d921b.svg b/pr-1683/assets/images/go.cd_trust-your-team-ae0d921b.svg new file mode 100644 index 000000000..5423f7e44 --- /dev/null +++ b/pr-1683/assets/images/go.cd_trust-your-team-ae0d921b.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_user-documentation-36dc7dba.svg b/pr-1683/assets/images/go.cd_user-documentation-36dc7dba.svg new file mode 100644 index 000000000..174a38a73 --- /dev/null +++ b/pr-1683/assets/images/go.cd_user-documentation-36dc7dba.svg @@ -0,0 +1,172 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_user-group-a35f5dac.svg b/pr-1683/assets/images/go.cd_user-group-a35f5dac.svg new file mode 100644 index 000000000..8bc4d7b85 --- /dev/null +++ b/pr-1683/assets/images/go.cd_user-group-a35f5dac.svg @@ -0,0 +1,150 @@ + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_want-to-do-4b72b9b7.svg b/pr-1683/assets/images/go.cd_want-to-do-4b72b9b7.svg new file mode 100644 index 000000000..06dfc65c2 --- /dev/null +++ b/pr-1683/assets/images/go.cd_want-to-do-4b72b9b7.svg @@ -0,0 +1,152 @@ + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go.cd_why-go-plugins-f59a63a3.svg b/pr-1683/assets/images/go.cd_why-go-plugins-f59a63a3.svg new file mode 100644 index 000000000..7526531d6 --- /dev/null +++ b/pr-1683/assets/images/go.cd_why-go-plugins-f59a63a3.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/go_logo-5b5ca9e1.svg b/pr-1683/assets/images/go_logo-5b5ca9e1.svg new file mode 100644 index 000000000..50d5ede16 --- /dev/null +++ b/pr-1683/assets/images/go_logo-5b5ca9e1.svg @@ -0,0 +1,42 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/gocd-watermark-b94da563.svg b/pr-1683/assets/images/gocd-watermark-b94da563.svg new file mode 100644 index 000000000..094af8850 --- /dev/null +++ b/pr-1683/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-1683/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg b/pr-1683/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg new file mode 100644 index 000000000..b1caee527 Binary files /dev/null and b/pr-1683/assets/images/gocd_continuous_delivery_thoughtworks_twitter-9cfe1828.jpg differ diff --git a/pr-1683/assets/images/halftone_gradient_background-9042b7fc.jpg b/pr-1683/assets/images/halftone_gradient_background-9042b7fc.jpg new file mode 100644 index 000000000..5b0c4fc71 Binary files /dev/null and b/pr-1683/assets/images/halftone_gradient_background-9042b7fc.jpg differ diff --git a/pr-1683/assets/images/help/community-301af89c.svg b/pr-1683/assets/images/help/community-301af89c.svg new file mode 100644 index 000000000..56daada99 --- /dev/null +++ b/pr-1683/assets/images/help/community-301af89c.svg @@ -0,0 +1,142 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/help/docs-4b296108.svg b/pr-1683/assets/images/help/docs-4b296108.svg new file mode 100644 index 000000000..5572c2e92 --- /dev/null +++ b/pr-1683/assets/images/help/docs-4b296108.svg @@ -0,0 +1,159 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/help/intro-5ae8c318.svg b/pr-1683/assets/images/help/intro-5ae8c318.svg new file mode 100644 index 000000000..6f4aa95cd --- /dev/null +++ b/pr-1683/assets/images/help/intro-5ae8c318.svg @@ -0,0 +1,107 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/home/cloud-native-de09706b.svg b/pr-1683/assets/images/home/cloud-native-de09706b.svg new file mode 100644 index 000000000..57320d8f1 --- /dev/null +++ b/pr-1683/assets/images/home/cloud-native-de09706b.svg @@ -0,0 +1,226 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/home/complex-workflow-66e3fca0.svg b/pr-1683/assets/images/home/complex-workflow-66e3fca0.svg new file mode 100644 index 000000000..10f3735c0 --- /dev/null +++ b/pr-1683/assets/images/home/complex-workflow-66e3fca0.svg @@ -0,0 +1,217 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/home/end-to-end-e50a03a0.svg b/pr-1683/assets/images/home/end-to-end-e50a03a0.svg new file mode 100644 index 000000000..c33dda488 --- /dev/null +++ b/pr-1683/assets/images/home/end-to-end-e50a03a0.svg @@ -0,0 +1,187 @@ + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/home/pipe_bkgd-564e4ebb.jpg b/pr-1683/assets/images/home/pipe_bkgd-564e4ebb.jpg new file mode 100644 index 000000000..b9a021e2a Binary files /dev/null and b/pr-1683/assets/images/home/pipe_bkgd-564e4ebb.jpg differ diff --git a/pr-1683/assets/images/home/traceability-1b39450a.svg b/pr-1683/assets/images/home/traceability-1b39450a.svg new file mode 100644 index 000000000..e94d32645 --- /dev/null +++ b/pr-1683/assets/images/home/traceability-1b39450a.svg @@ -0,0 +1,205 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/home/ui_illo-647c5fa8.svg b/pr-1683/assets/images/home/ui_illo-647c5fa8.svg new file mode 100644 index 000000000..9ef74bfad --- /dev/null +++ b/pr-1683/assets/images/home/ui_illo-647c5fa8.svg @@ -0,0 +1 @@ +Asset 2 \ No newline at end of file diff --git a/pr-1683/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg b/pr-1683/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg new file mode 100644 index 000000000..03435e892 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_blog-about-gocd-fb55d4a8.svg @@ -0,0 +1,91 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg b/pr-1683/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg new file mode 100644 index 000000000..c14a3d495 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_code-for-gocd-61ebd40f.svg @@ -0,0 +1,90 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_community-0ebe9afa.svg b/pr-1683/assets/images/icons/go.cd_community-0ebe9afa.svg new file mode 100644 index 000000000..4b8babfdf --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_community-0ebe9afa.svg @@ -0,0 +1,124 @@ + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_compare-builds-a87196c2.svg b/pr-1683/assets/images/icons/go.cd_compare-builds-a87196c2.svg new file mode 100644 index 000000000..3dbef2f10 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_compare-builds-a87196c2.svg @@ -0,0 +1,123 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg b/pr-1683/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg new file mode 100644 index 000000000..13033fa43 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_deploy-any-version-anytime-b7041220.svg @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg b/pr-1683/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg new file mode 100644 index 000000000..426a83b4b --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_eliminate-bottlenecks-c1266c2a.svg @@ -0,0 +1,174 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_join-community-61198ca4.svg b/pr-1683/assets/images/icons/go.cd_join-community-61198ca4.svg new file mode 100644 index 000000000..02897541a --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_join-community-61198ca4.svg @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg b/pr-1683/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg new file mode 100644 index 000000000..dc664cf77 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_keep-configuration-tidy-2129d3db.svg @@ -0,0 +1,125 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg b/pr-1683/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg new file mode 100644 index 000000000..e7176dd55 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_model-complex-workflows-9b181d3c.svg @@ -0,0 +1,96 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_plugins-d2b1494a.svg b/pr-1683/assets/images/icons/go.cd_plugins-d2b1494a.svg new file mode 100644 index 000000000..c03c403a3 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_plugins-d2b1494a.svg @@ -0,0 +1,88 @@ + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg b/pr-1683/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg new file mode 100644 index 000000000..dcc9a7687 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_promote-trusted-artifacts-5d5fc8ae.svg @@ -0,0 +1,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg b/pr-1683/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg new file mode 100644 index 000000000..504e7c0eb --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_run-and-grok-your-tests-f25e60ad.svg @@ -0,0 +1,205 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_security-d3942ad4.svg b/pr-1683/assets/images/icons/go.cd_security-d3942ad4.svg new file mode 100644 index 000000000..2361e0786 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_security-d3942ad4.svg @@ -0,0 +1,96 @@ + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg b/pr-1683/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg new file mode 100644 index 000000000..dfe756765 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_see-how-things-really-work-d44e8c48.svg @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg b/pr-1683/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg new file mode 100644 index 000000000..7c58e7225 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_test-gocd-a7b99d2f.svg @@ -0,0 +1,127 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg b/pr-1683/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg new file mode 100644 index 000000000..5299731d3 --- /dev/null +++ b/pr-1683/assets/images/icons/go.cd_trust-your-team-f21f86c3.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/image01-453d1ed1.png b/pr-1683/assets/images/image01-453d1ed1.png new file mode 100644 index 000000000..eb639e65a Binary files /dev/null and b/pr-1683/assets/images/image01-453d1ed1.png differ diff --git a/pr-1683/assets/images/image02-7cb7c1f3.png b/pr-1683/assets/images/image02-7cb7c1f3.png new file mode 100644 index 000000000..e5ac7600b Binary files /dev/null and b/pr-1683/assets/images/image02-7cb7c1f3.png differ diff --git a/pr-1683/assets/images/image03-da3d56f1.png b/pr-1683/assets/images/image03-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1683/assets/images/image03-da3d56f1.png differ diff --git a/pr-1683/assets/images/image07-77a88407.png b/pr-1683/assets/images/image07-77a88407.png new file mode 100644 index 000000000..7486f2520 Binary files /dev/null and b/pr-1683/assets/images/image07-77a88407.png differ diff --git a/pr-1683/assets/images/image08-da3d56f1.png b/pr-1683/assets/images/image08-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1683/assets/images/image08-da3d56f1.png differ diff --git a/pr-1683/assets/images/image09-da3d56f1.png b/pr-1683/assets/images/image09-da3d56f1.png new file mode 100644 index 000000000..77f8e872c Binary files /dev/null and b/pr-1683/assets/images/image09-da3d56f1.png differ diff --git a/pr-1683/assets/images/image10-554cdcff.png b/pr-1683/assets/images/image10-554cdcff.png new file mode 100644 index 000000000..b08715e33 Binary files /dev/null and b/pr-1683/assets/images/image10-554cdcff.png differ diff --git a/pr-1683/assets/images/inner-banner-bg-5a21fadc.jpg b/pr-1683/assets/images/inner-banner-bg-5a21fadc.jpg new file mode 100644 index 000000000..1944de848 Binary files /dev/null and b/pr-1683/assets/images/inner-banner-bg-5a21fadc.jpg differ diff --git a/pr-1683/assets/images/lightbox-arrow-e5c1fbd9.svg b/pr-1683/assets/images/lightbox-arrow-e5c1fbd9.svg new file mode 100644 index 000000000..a69f8e2c6 --- /dev/null +++ b/pr-1683/assets/images/lightbox-arrow-e5c1fbd9.svg @@ -0,0 +1,11 @@ + + + + + + + + diff --git a/pr-1683/assets/images/lightbox-close-3acf70e4.svg b/pr-1683/assets/images/lightbox-close-3acf70e4.svg new file mode 100644 index 000000000..779a3c73d --- /dev/null +++ b/pr-1683/assets/images/lightbox-close-3acf70e4.svg @@ -0,0 +1,12 @@ + + + + + + + + + diff --git a/pr-1683/assets/images/middleman-logo-257e02f7.svg b/pr-1683/assets/images/middleman-logo-257e02f7.svg new file mode 100644 index 000000000..98ef9fc3a --- /dev/null +++ b/pr-1683/assets/images/middleman-logo-257e02f7.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/pr-1683/assets/images/model-complex-worklflows-8b2fd43e.jpg b/pr-1683/assets/images/model-complex-worklflows-8b2fd43e.jpg new file mode 100644 index 000000000..991090b61 Binary files /dev/null and b/pr-1683/assets/images/model-complex-worklflows-8b2fd43e.jpg differ diff --git a/pr-1683/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png b/pr-1683/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png new file mode 100644 index 000000000..091c89743 Binary files /dev/null and b/pr-1683/assets/images/no-timestamps-in-console-logs-example-a63eaf2d.png differ diff --git a/pr-1683/assets/images/pipeline_subscribe-028c93fa.jpg b/pr-1683/assets/images/pipeline_subscribe-028c93fa.jpg new file mode 100644 index 000000000..2d8d0d1c5 Binary files /dev/null and b/pr-1683/assets/images/pipeline_subscribe-028c93fa.jpg differ diff --git a/pr-1683/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg b/pr-1683/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg new file mode 100644 index 000000000..ec37b677a Binary files /dev/null and b/pr-1683/assets/images/pipelines-as-code/banner_background_drk-cd76b5ae.jpg differ diff --git a/pr-1683/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg b/pr-1683/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg new file mode 100644 index 000000000..e901d35b9 --- /dev/null +++ b/pr-1683/assets/images/pipelines-as-code/cloud_deploy-c140fc1d.svg @@ -0,0 +1,92 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg b/pr-1683/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg new file mode 100644 index 000000000..36baee4f8 --- /dev/null +++ b/pr-1683/assets/images/pipelines-as-code/elastic_agents-bbc8417c.svg @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/pipelines-as-code/k8s-acf3f006.svg b/pr-1683/assets/images/pipelines-as-code/k8s-acf3f006.svg new file mode 100644 index 000000000..fad07ac62 --- /dev/null +++ b/pr-1683/assets/images/pipelines-as-code/k8s-acf3f006.svg @@ -0,0 +1,97 @@ + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg b/pr-1683/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg new file mode 100644 index 000000000..980efdecf --- /dev/null +++ b/pr-1683/assets/images/pipelines-as-code/modern_interface-fd96e1c5.svg @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pr-1683/assets/images/pipelines-as-code/pipelines-as-code-banner-2d9a5b61.jpg b/pr-1683/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-1683/assets/images/pipelines-as-code/pipelines-as-code-banner-2d9a5b61.jpg differ diff --git a/pr-1683/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif b/pr-1683/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif new file mode 100644 index 000000000..381e57aca Binary files /dev/null and b/pr-1683/assets/images/pipelines-as-code/terminal_dark-5dab632e.gif differ diff --git a/pr-1683/assets/images/placeholder-3f95a996.jpg b/pr-1683/assets/images/placeholder-3f95a996.jpg new file mode 100644 index 000000000..45f37b9d1 Binary files /dev/null and b/pr-1683/assets/images/placeholder-3f95a996.jpg differ diff --git a/pr-1683/assets/images/plugins-4ae2cffd.png b/pr-1683/assets/images/plugins-4ae2cffd.png new file mode 100644 index 000000000..c7d20a63c Binary files /dev/null and b/pr-1683/assets/images/plugins-4ae2cffd.png differ diff --git a/pr-1683/assets/images/promote-trusted-artifacts-bb483c0c.png b/pr-1683/assets/images/promote-trusted-artifacts-bb483c0c.png new file mode 100644 index 000000000..4d80d1484 Binary files /dev/null and b/pr-1683/assets/images/promote-trusted-artifacts-bb483c0c.png differ diff --git a/pr-1683/assets/images/releases/15.1/15_1_console_log_timestamp-d475e063.png b/pr-1683/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-1683/assets/images/releases/15.1/15_1_console_log_timestamp-d475e063.png differ diff --git a/pr-1683/assets/images/releases/15.1/15_1_github_pr-4d2a6ba4.png b/pr-1683/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-1683/assets/images/releases/15.1/15_1_github_pr-4d2a6ba4.png differ diff --git a/pr-1683/assets/images/releases/15.1/15_1_new_pipeline_label-e4efa9b7.png b/pr-1683/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-1683/assets/images/releases/15.1/15_1_new_pipeline_label-e4efa9b7.png differ diff --git a/pr-1683/assets/images/releases/15.1/15_1_old_pipeline_label-9b431eaf.png b/pr-1683/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-1683/assets/images/releases/15.1/15_1_old_pipeline_label-9b431eaf.png differ diff --git a/pr-1683/assets/images/releases/15.2/console-log-color-9cb3f569.png b/pr-1683/assets/images/releases/15.2/console-log-color-9cb3f569.png new file mode 100644 index 000000000..3047bbff5 Binary files /dev/null and b/pr-1683/assets/images/releases/15.2/console-log-color-9cb3f569.png differ diff --git a/pr-1683/assets/images/releases/15.3/update-check-bell-224e93de.png b/pr-1683/assets/images/releases/15.3/update-check-bell-224e93de.png new file mode 100644 index 000000000..20515ab66 Binary files /dev/null and b/pr-1683/assets/images/releases/15.3/update-check-bell-224e93de.png differ diff --git a/pr-1683/assets/images/releases/15.3/update-check-info-e75610b1.png b/pr-1683/assets/images/releases/15.3/update-check-info-e75610b1.png new file mode 100644 index 000000000..c696bce10 Binary files /dev/null and b/pr-1683/assets/images/releases/15.3/update-check-info-e75610b1.png differ diff --git a/pr-1683/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png b/pr-1683/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png new file mode 100644 index 000000000..cf3f03227 Binary files /dev/null and b/pr-1683/assets/images/releases/16.10/agents-page-beta-29cf3ee0.png differ diff --git a/pr-1683/assets/images/releases/16.10/agents-page-old-9d4fe063.png b/pr-1683/assets/images/releases/16.10/agents-page-old-9d4fe063.png new file mode 100644 index 000000000..31a8c0c6d Binary files /dev/null and b/pr-1683/assets/images/releases/16.10/agents-page-old-9d4fe063.png differ diff --git a/pr-1683/assets/images/releases/16.12/agents-page-b520368d.png b/pr-1683/assets/images/releases/16.12/agents-page-b520368d.png new file mode 100644 index 000000000..8abb6ef58 Binary files /dev/null and b/pr-1683/assets/images/releases/16.12/agents-page-b520368d.png differ diff --git a/pr-1683/assets/images/releases/16.12/elastic-profiles-add-new-eb4f88a3.png b/pr-1683/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-1683/assets/images/releases/16.12/elastic-profiles-add-new-eb4f88a3.png differ diff --git a/pr-1683/assets/images/releases/16.12/new-theme-912e9418.png b/pr-1683/assets/images/releases/16.12/new-theme-912e9418.png new file mode 100644 index 000000000..1b8ca1d9d Binary files /dev/null and b/pr-1683/assets/images/releases/16.12/new-theme-912e9418.png differ diff --git a/pr-1683/assets/images/releases/16.3/git-shallow-clone-e82e142c.png b/pr-1683/assets/images/releases/16.3/git-shallow-clone-e82e142c.png new file mode 100644 index 000000000..d7e094e24 Binary files /dev/null and b/pr-1683/assets/images/releases/16.3/git-shallow-clone-e82e142c.png differ diff --git a/pr-1683/assets/images/releases/16.9/quickeditbutton-78e54c92.png b/pr-1683/assets/images/releases/16.9/quickeditbutton-78e54c92.png new file mode 100644 index 000000000..84366bfb0 Binary files /dev/null and b/pr-1683/assets/images/releases/16.9/quickeditbutton-78e54c92.png differ diff --git a/pr-1683/assets/images/releases/16.9/quickeditpage-126e6d7a.png b/pr-1683/assets/images/releases/16.9/quickeditpage-126e6d7a.png new file mode 100644 index 000000000..2cc08d64d Binary files /dev/null and b/pr-1683/assets/images/releases/16.9/quickeditpage-126e6d7a.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/pipeline-run-duration-in-vsm-4d3bffed.png b/pr-1683/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-1683/assets/images/releases/17.11.0/pipeline-run-duration-in-vsm-4d3bffed.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/vsm-explicit-link-dashboard-ca369c86.png b/pr-1683/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-1683/assets/images/releases/17.11.0/vsm-explicit-link-dashboard-ca369c86.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/vsm-explicit-link-job-details-header-41ce0456.png b/pr-1683/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-1683/assets/images/releases/17.11.0/vsm-explicit-link-job-details-header-41ce0456.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/vsm-explicit-link-stage-details-1590a797.png b/pr-1683/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-1683/assets/images/releases/17.11.0/vsm-explicit-link-stage-details-1590a797.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/vsm-explicit-link-vsm-4d3bffed.png b/pr-1683/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-1683/assets/images/releases/17.11.0/vsm-explicit-link-vsm-4d3bffed.png differ diff --git a/pr-1683/assets/images/releases/17.11.0/vsm-explicit-link-vsm-header-95afe224.png b/pr-1683/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-1683/assets/images/releases/17.11.0/vsm-explicit-link-vsm-header-95afe224.png differ diff --git a/pr-1683/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png b/pr-1683/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png new file mode 100644 index 000000000..610690ffd Binary files /dev/null and b/pr-1683/assets/images/releases/17.12.0/Plugins-SPA-73593efd.png differ diff --git a/pr-1683/assets/images/releases/17.2.0/template-permissions-73dc5171.png b/pr-1683/assets/images/releases/17.2.0/template-permissions-73dc5171.png new file mode 100644 index 000000000..aa96f6f88 Binary files /dev/null and b/pr-1683/assets/images/releases/17.2.0/template-permissions-73dc5171.png differ diff --git a/pr-1683/assets/images/releases/17.3.0/build_status-96febef4.png b/pr-1683/assets/images/releases/17.3.0/build_status-96febef4.png new file mode 100644 index 000000000..e8076ba41 Binary files /dev/null and b/pr-1683/assets/images/releases/17.3.0/build_status-96febef4.png differ diff --git a/pr-1683/assets/images/releases/17.3.0/elastic_agent_icon-1e562032.png b/pr-1683/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-1683/assets/images/releases/17.3.0/elastic_agent_icon-1e562032.png differ diff --git a/pr-1683/assets/images/releases/17.3.0/stage_with_symbols-4c8d52df.png b/pr-1683/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-1683/assets/images/releases/17.3.0/stage_with_symbols-4c8d52df.png differ diff --git a/pr-1683/assets/images/releases/17.4.0/border-31151e37.png b/pr-1683/assets/images/releases/17.4.0/border-31151e37.png new file mode 100644 index 000000000..053c1a716 Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/border-31151e37.png differ diff --git a/pr-1683/assets/images/releases/17.4.0/errors-a3128474.png b/pr-1683/assets/images/releases/17.4.0/errors-a3128474.png new file mode 100644 index 000000000..d76f715da Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/errors-a3128474.png differ diff --git a/pr-1683/assets/images/releases/17.4.0/expand_logs-49fa414c.gif b/pr-1683/assets/images/releases/17.4.0/expand_logs-49fa414c.gif new file mode 100644 index 000000000..a0fbf2c41 Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/expand_logs-49fa414c.gif differ diff --git a/pr-1683/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png b/pr-1683/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png new file mode 100644 index 000000000..f5f3070d0 Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/fullscreen-9ad2d6eb.png differ diff --git a/pr-1683/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif b/pr-1683/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif new file mode 100644 index 000000000..809b75653 Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/job_history-cb7e5a4e.gif differ diff --git a/pr-1683/assets/images/releases/17.4.0/timestamp-99c7c6d3.png b/pr-1683/assets/images/releases/17.4.0/timestamp-99c7c6d3.png new file mode 100644 index 000000000..db7037d54 Binary files /dev/null and b/pr-1683/assets/images/releases/17.4.0/timestamp-99c7c6d3.png differ diff --git a/pr-1683/assets/images/releases/17.5.0/auth-config-e288de5a.png b/pr-1683/assets/images/releases/17.5.0/auth-config-e288de5a.png new file mode 100644 index 000000000..9e2779378 Binary files /dev/null and b/pr-1683/assets/images/releases/17.5.0/auth-config-e288de5a.png differ diff --git a/pr-1683/assets/images/releases/17.5.0/role-config-4127629c.png b/pr-1683/assets/images/releases/17.5.0/role-config-4127629c.png new file mode 100644 index 000000000..828b4ce12 Binary files /dev/null and b/pr-1683/assets/images/releases/17.5.0/role-config-4127629c.png differ diff --git a/pr-1683/assets/images/releases/17.5.0/security-menu-d1aed431.png b/pr-1683/assets/images/releases/17.5.0/security-menu-d1aed431.png new file mode 100644 index 000000000..fd7a6d1d2 Binary files /dev/null and b/pr-1683/assets/images/releases/17.5.0/security-menu-d1aed431.png differ diff --git a/pr-1683/assets/images/releases/17.6.0/improve-timestamp-rendering-1-5a8314bf.png b/pr-1683/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-1683/assets/images/releases/17.6.0/improve-timestamp-rendering-1-5a8314bf.png differ diff --git a/pr-1683/assets/images/releases/17.6.0/improve-timestamp-rendering-2-41be5dda.png b/pr-1683/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-1683/assets/images/releases/17.6.0/improve-timestamp-rendering-2-41be5dda.png differ diff --git a/pr-1683/assets/images/releases/17.6.0/rerun-failed-jobs-182f21d2.png b/pr-1683/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-1683/assets/images/releases/17.6.0/rerun-failed-jobs-182f21d2.png differ diff --git a/pr-1683/assets/images/releases/17.9.0/edit-pipeline-from-vsm-008fac52.png b/pr-1683/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-1683/assets/images/releases/17.9.0/edit-pipeline-from-vsm-008fac52.png differ diff --git a/pr-1683/assets/images/releases/17.9.0/elastic-agent-grouping-by-plugin-id-3f70396b.png b/pr-1683/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-1683/assets/images/releases/17.9.0/elastic-agent-grouping-by-plugin-id-3f70396b.png differ diff --git a/pr-1683/assets/images/releases/18.10.0/environments-under-admin-e89c15f6.gif b/pr-1683/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-1683/assets/images/releases/18.10.0/environments-under-admin-e89c15f6.gif differ diff --git a/pr-1683/assets/images/releases/18.12.0/admin_menu-6be5be5a.png b/pr-1683/assets/images/releases/18.12.0/admin_menu-6be5be5a.png new file mode 100644 index 000000000..c8ae092a0 Binary files /dev/null and b/pr-1683/assets/images/releases/18.12.0/admin_menu-6be5be5a.png differ diff --git a/pr-1683/assets/images/releases/18.12.0/config_repo-8810e00d.png b/pr-1683/assets/images/releases/18.12.0/config_repo-8810e00d.png new file mode 100644 index 000000000..fd2c4ca0c Binary files /dev/null and b/pr-1683/assets/images/releases/18.12.0/config_repo-8810e00d.png differ diff --git a/pr-1683/assets/images/releases/18.12.0/elastic_profile_jobs-d50b21a6.png b/pr-1683/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-1683/assets/images/releases/18.12.0/elastic_profile_jobs-d50b21a6.png differ diff --git a/pr-1683/assets/images/releases/18.2.0/elastic-agent-plugin-status-report-1ad2f3fc.png b/pr-1683/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-1683/assets/images/releases/18.2.0/elastic-agent-plugin-status-report-1ad2f3fc.png differ diff --git a/pr-1683/assets/images/releases/18.2.0/elastic-agent-status-report-66a6779c.png b/pr-1683/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-1683/assets/images/releases/18.2.0/elastic-agent-status-report-66a6779c.png differ diff --git a/pr-1683/assets/images/releases/18.2.0/new-dashboard-4720d938.png b/pr-1683/assets/images/releases/18.2.0/new-dashboard-4720d938.png new file mode 100644 index 000000000..fb8c911f2 Binary files /dev/null and b/pr-1683/assets/images/releases/18.2.0/new-dashboard-4720d938.png differ diff --git a/pr-1683/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png b/pr-1683/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png new file mode 100644 index 000000000..7c06af9e6 Binary files /dev/null and b/pr-1683/assets/images/releases/18.3.0/new-dashboard-dd0bd431.png differ diff --git a/pr-1683/assets/images/releases/18.3.0/plugin-error-warning-messages-0bbd0095.png b/pr-1683/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-1683/assets/images/releases/18.3.0/plugin-error-warning-messages-0bbd0095.png differ diff --git a/pr-1683/assets/images/releases/18.7.0/data-sharing-ae8581cb.png b/pr-1683/assets/images/releases/18.7.0/data-sharing-ae8581cb.png new file mode 100644 index 000000000..65f91edfc Binary files /dev/null and b/pr-1683/assets/images/releases/18.7.0/data-sharing-ae8581cb.png differ diff --git a/pr-1683/assets/images/releases/18.7.0/loading-screen-d4d02113.png b/pr-1683/assets/images/releases/18.7.0/loading-screen-d4d02113.png new file mode 100644 index 000000000..4296932ed Binary files /dev/null and b/pr-1683/assets/images/releases/18.7.0/loading-screen-d4d02113.png differ diff --git a/pr-1683/assets/images/releases/18.8.0/by-pipeline-status-898e5dee.gif b/pr-1683/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-1683/assets/images/releases/18.8.0/by-pipeline-status-898e5dee.gif differ diff --git a/pr-1683/assets/images/releases/18.8.0/create-new-view-cf4e737f.gif b/pr-1683/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-1683/assets/images/releases/18.8.0/create-new-view-cf4e737f.gif differ diff --git a/pr-1683/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif b/pr-1683/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif new file mode 100644 index 000000000..c2f4a4983 Binary files /dev/null and b/pr-1683/assets/images/releases/18.8.0/dashboard-grouping-18748d18.gif differ diff --git a/pr-1683/assets/images/releases/18.8.0/data-sharing-721f77da.png b/pr-1683/assets/images/releases/18.8.0/data-sharing-721f77da.png new file mode 100644 index 000000000..9e04764e4 Binary files /dev/null and b/pr-1683/assets/images/releases/18.8.0/data-sharing-721f77da.png differ diff --git a/pr-1683/assets/images/releases/18.8.0/only-building-and-failed-pipelines-b8590063.gif b/pr-1683/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-1683/assets/images/releases/18.8.0/only-building-and-failed-pipelines-b8590063.gif differ diff --git a/pr-1683/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif b/pr-1683/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif new file mode 100644 index 000000000..42d7a170f Binary files /dev/null and b/pr-1683/assets/images/releases/18.8.0/reorder-views-c7beeb90.gif differ diff --git a/pr-1683/assets/images/releases/19.1.0/config-spa-error-3c12e3b4.png b/pr-1683/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-1683/assets/images/releases/19.1.0/config-spa-error-3c12e3b4.png differ diff --git a/pr-1683/assets/images/releases/19.1.0/pipeline-export-111479b7.gif b/pr-1683/assets/images/releases/19.1.0/pipeline-export-111479b7.gif new file mode 100644 index 000000000..f33445adb Binary files /dev/null and b/pr-1683/assets/images/releases/19.1.0/pipeline-export-111479b7.gif differ diff --git a/pr-1683/assets/images/releases/19.1.0/server-maintenance-mode-9b7eb7ce.gif b/pr-1683/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-1683/assets/images/releases/19.1.0/server-maintenance-mode-9b7eb7ce.gif differ diff --git a/pr-1683/assets/images/releases/19.1.0/users_management-6344f05c.png b/pr-1683/assets/images/releases/19.1.0/users_management-6344f05c.png new file mode 100644 index 000000000..258f74b21 Binary files /dev/null and b/pr-1683/assets/images/releases/19.1.0/users_management-6344f05c.png differ diff --git a/pr-1683/assets/images/releases/19.10.0/new-agents-page-elastic-agents-4ff88a93.png b/pr-1683/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-1683/assets/images/releases/19.10.0/new-agents-page-elastic-agents-4ff88a93.png differ diff --git a/pr-1683/assets/images/releases/19.10.0/new-agents-page-static-agents-36c50ab2.png b/pr-1683/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-1683/assets/images/releases/19.10.0/new-agents-page-static-agents-36c50ab2.png differ diff --git a/pr-1683/assets/images/releases/19.11.0/environments-page-8e483812.png b/pr-1683/assets/images/releases/19.11.0/environments-page-8e483812.png new file mode 100644 index 000000000..31f15714c Binary files /dev/null and b/pr-1683/assets/images/releases/19.11.0/environments-page-8e483812.png differ diff --git a/pr-1683/assets/images/releases/19.11.0/pipelines-page-312b6290.png b/pr-1683/assets/images/releases/19.11.0/pipelines-page-312b6290.png new file mode 100644 index 000000000..074377860 Binary files /dev/null and b/pr-1683/assets/images/releases/19.11.0/pipelines-page-312b6290.png differ diff --git a/pr-1683/assets/images/releases/19.11.0/server-config-page-cf024239.png b/pr-1683/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-1683/assets/images/releases/19.11.0/server-config-page-cf024239.png differ diff --git a/pr-1683/assets/images/releases/19.11.0/templates-page-cdfccb06.png b/pr-1683/assets/images/releases/19.11.0/templates-page-cdfccb06.png new file mode 100644 index 000000000..2e8a25864 Binary files /dev/null and b/pr-1683/assets/images/releases/19.11.0/templates-page-cdfccb06.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/agent-job-run-history-a5954e57.png b/pr-1683/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-1683/assets/images/releases/19.12.0/agent-job-run-history-a5954e57.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/agent-job-state-transition-993dae0a.png b/pr-1683/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-1683/assets/images/releases/19.12.0/agent-job-state-transition-993dae0a.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png b/pr-1683/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png new file mode 100644 index 000000000..7824b1c39 Binary files /dev/null and b/pr-1683/assets/images/releases/19.12.0/cluster-profile-d2db2a55.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/elastic-profile-0d215002.png b/pr-1683/assets/images/releases/19.12.0/elastic-profile-0d215002.png new file mode 100644 index 000000000..1d70aa14e Binary files /dev/null and b/pr-1683/assets/images/releases/19.12.0/elastic-profile-0d215002.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/landing-page-77146027.png b/pr-1683/assets/images/releases/19.12.0/landing-page-77146027.png new file mode 100644 index 000000000..e8cac420a Binary files /dev/null and b/pr-1683/assets/images/releases/19.12.0/landing-page-77146027.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/pipeline-activity-23b57419.png b/pr-1683/assets/images/releases/19.12.0/pipeline-activity-23b57419.png new file mode 100644 index 000000000..4be15a7a4 Binary files /dev/null and b/pr-1683/assets/images/releases/19.12.0/pipeline-activity-23b57419.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/pipeline-activity-comment-d715f3e2.png b/pr-1683/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-1683/assets/images/releases/19.12.0/pipeline-activity-comment-d715f3e2.png differ diff --git a/pr-1683/assets/images/releases/19.12.0/read-only-pipeline-859d7dec.png b/pr-1683/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-1683/assets/images/releases/19.12.0/read-only-pipeline-859d7dec.png differ diff --git a/pr-1683/assets/images/releases/19.2.0/admin-access-token-70620ea3.gif b/pr-1683/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-1683/assets/images/releases/19.2.0/admin-access-token-70620ea3.gif differ diff --git a/pr-1683/assets/images/releases/19.2.0/config_repo_improvements-af73b808.png b/pr-1683/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-1683/assets/images/releases/19.2.0/config_repo_improvements-af73b808.png differ diff --git a/pr-1683/assets/images/releases/19.2.0/personal-access-token-4768f301.gif b/pr-1683/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-1683/assets/images/releases/19.2.0/personal-access-token-4768f301.gif differ diff --git a/pr-1683/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png b/pr-1683/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png new file mode 100644 index 000000000..395a57d75 Binary files /dev/null and b/pr-1683/assets/images/releases/19.2.0/pipeline-pause-f955aa17.png differ diff --git a/pr-1683/assets/images/releases/19.2.0/user-management-spa-7977dd9a.gif b/pr-1683/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-1683/assets/images/releases/19.2.0/user-management-spa-7977dd9a.gif differ diff --git a/pr-1683/assets/images/releases/19.3.0/backup-2504b1e5.png b/pr-1683/assets/images/releases/19.3.0/backup-2504b1e5.png new file mode 100644 index 000000000..a14277e0b Binary files /dev/null and b/pr-1683/assets/images/releases/19.3.0/backup-2504b1e5.png differ diff --git a/pr-1683/assets/images/releases/19.3.0/elastic_profile-51501be1.png b/pr-1683/assets/images/releases/19.3.0/elastic_profile-51501be1.png new file mode 100644 index 000000000..f9dc83bc6 Binary files /dev/null and b/pr-1683/assets/images/releases/19.3.0/elastic_profile-51501be1.png differ diff --git a/pr-1683/assets/images/releases/19.6.0/secret-config-spa-cda210eb.gif b/pr-1683/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-1683/assets/images/releases/19.6.0/secret-config-spa-cda210eb.gif differ diff --git a/pr-1683/assets/images/releases/19.8.0/new-pipeline-wizard-b98bde85.gif b/pr-1683/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-1683/assets/images/releases/19.8.0/new-pipeline-wizard-b98bde85.gif differ diff --git a/pr-1683/assets/images/releases/20.1.0/pipeline_grp_edit-ac8877a7.png b/pr-1683/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-1683/assets/images/releases/20.1.0/pipeline_grp_edit-ac8877a7.png differ diff --git a/pr-1683/assets/images/releases/20.3.0/comparison_spa-085ed386.png b/pr-1683/assets/images/releases/20.3.0/comparison_spa-085ed386.png new file mode 100644 index 000000000..eefef324c Binary files /dev/null and b/pr-1683/assets/images/releases/20.3.0/comparison_spa-085ed386.png differ diff --git a/pr-1683/assets/images/releases/20.3.0/package_repository_spa-9ac4e2cd.png b/pr-1683/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-1683/assets/images/releases/20.3.0/package_repository_spa-9ac4e2cd.png differ diff --git a/pr-1683/assets/images/releases/20.3.0/pluggable_scm_spa-32d3f3ac.png b/pr-1683/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-1683/assets/images/releases/20.3.0/pluggable_scm_spa-32d3f3ac.png differ diff --git a/pr-1683/assets/images/releases/20.4.0/pipeline-config-spa-68c3e3f8.gif b/pr-1683/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-1683/assets/images/releases/20.4.0/pipeline-config-spa-68c3e3f8.gif differ diff --git a/pr-1683/assets/images/releases/20.5.0/template_authorization_spa-e6c515e8.png b/pr-1683/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-1683/assets/images/releases/20.5.0/template_authorization_spa-e6c515e8.png differ diff --git a/pr-1683/assets/images/releases/20.6.0/pipeline_as_code_wizard-f66fe5df.png b/pr-1683/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-1683/assets/images/releases/20.6.0/pipeline_as_code_wizard-f66fe5df.png differ diff --git a/pr-1683/assets/images/releases/20.7.0/stage_overview-0e769ece.gif b/pr-1683/assets/images/releases/20.7.0/stage_overview-0e769ece.gif new file mode 100644 index 000000000..09f3d2b09 Binary files /dev/null and b/pr-1683/assets/images/releases/20.7.0/stage_overview-0e769ece.gif differ diff --git a/pr-1683/assets/images/releases/20.8.0/materials_spa-3c79018e.gif b/pr-1683/assets/images/releases/20.8.0/materials_spa-3c79018e.gif new file mode 100644 index 000000000..0db362bb2 Binary files /dev/null and b/pr-1683/assets/images/releases/20.8.0/materials_spa-3c79018e.gif differ diff --git a/pr-1683/assets/images/releases/20.8.0/stage_overview-5293c27c.png b/pr-1683/assets/images/releases/20.8.0/stage_overview-5293c27c.png new file mode 100644 index 000000000..12301b4a1 Binary files /dev/null and b/pr-1683/assets/images/releases/20.8.0/stage_overview-5293c27c.png differ diff --git a/pr-1683/assets/images/releases/20.9.0/preference_page-31d0b157.png b/pr-1683/assets/images/releases/20.9.0/preference_page-31d0b157.png new file mode 100644 index 000000000..2838cf5bb Binary files /dev/null and b/pr-1683/assets/images/releases/20.9.0/preference_page-31d0b157.png differ diff --git a/pr-1683/assets/images/releases/20.9.0/stage_instances-62e0f62d.png b/pr-1683/assets/images/releases/20.9.0/stage_instances-62e0f62d.png new file mode 100644 index 000000000..9ed4b29b4 Binary files /dev/null and b/pr-1683/assets/images/releases/20.9.0/stage_instances-62e0f62d.png differ diff --git a/pr-1683/assets/images/releases/20.9.0/stage_overview-347bb105.png b/pr-1683/assets/images/releases/20.9.0/stage_overview-347bb105.png new file mode 100644 index 000000000..fd5720ff2 Binary files /dev/null and b/pr-1683/assets/images/releases/20.9.0/stage_overview-347bb105.png differ diff --git a/pr-1683/assets/images/releases/21.1.0/config_repo_webhook-a1e13cb6.png b/pr-1683/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-1683/assets/images/releases/21.1.0/config_repo_webhook-a1e13cb6.png differ diff --git a/pr-1683/assets/images/releases/23.1.0/personalization_config-5bb66d39.png b/pr-1683/assets/images/releases/23.1.0/personalization_config-5bb66d39.png new file mode 100644 index 000000000..c9d4a1322 Binary files /dev/null and b/pr-1683/assets/images/releases/23.1.0/personalization_config-5bb66d39.png differ diff --git a/pr-1683/assets/images/rss-icon-d175b643.png b/pr-1683/assets/images/rss-icon-d175b643.png new file mode 100644 index 000000000..29fc01483 Binary files /dev/null and b/pr-1683/assets/images/rss-icon-d175b643.png differ diff --git a/pr-1683/assets/images/screenshots/agents-a2ea5e8d.png b/pr-1683/assets/images/screenshots/agents-a2ea5e8d.png new file mode 100644 index 000000000..ede6adbd2 Binary files /dev/null and b/pr-1683/assets/images/screenshots/agents-a2ea5e8d.png differ diff --git a/pr-1683/assets/images/screenshots/console-timestamp-5541d6ce.png b/pr-1683/assets/images/screenshots/console-timestamp-5541d6ce.png new file mode 100644 index 000000000..10afd1248 Binary files /dev/null and b/pr-1683/assets/images/screenshots/console-timestamp-5541d6ce.png differ diff --git a/pr-1683/assets/images/screenshots/dashboard-fa9a3fa2.png b/pr-1683/assets/images/screenshots/dashboard-fa9a3fa2.png new file mode 100644 index 000000000..0e9d9d262 Binary files /dev/null and b/pr-1683/assets/images/screenshots/dashboard-fa9a3fa2.png differ diff --git a/pr-1683/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg b/pr-1683/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg new file mode 100644 index 000000000..512807c82 Binary files /dev/null and b/pr-1683/assets/images/screenshots/thumb/agent-dpr-2-a093bdc6.jpg differ diff --git a/pr-1683/assets/images/screenshots/thumb/console-with-timestamps-dpr-2-c597ddc1.jpg b/pr-1683/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-1683/assets/images/screenshots/thumb/console-with-timestamps-dpr-2-c597ddc1.jpg differ diff --git a/pr-1683/assets/images/screenshots/thumb/dashboard-one-red-dpr-2-16cd5841.jpg b/pr-1683/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-1683/assets/images/screenshots/thumb/dashboard-one-red-dpr-2-16cd5841.jpg differ diff --git a/pr-1683/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg b/pr-1683/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg new file mode 100644 index 000000000..3187de483 Binary files /dev/null and b/pr-1683/assets/images/screenshots/thumb/value-stream-map-thumb-42a9868b.jpg differ diff --git a/pr-1683/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg b/pr-1683/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg new file mode 100644 index 000000000..f317464cb Binary files /dev/null and b/pr-1683/assets/images/screenshots/thumb/vsm-dpr-2-1cc74b7f.jpg differ diff --git a/pr-1683/assets/images/screenshots/vsm-795421ee.png b/pr-1683/assets/images/screenshots/vsm-795421ee.png new file mode 100644 index 000000000..3f00516bd Binary files /dev/null and b/pr-1683/assets/images/screenshots/vsm-795421ee.png differ diff --git a/pr-1683/assets/images/see-how-things-really-work-39fbef93.png b/pr-1683/assets/images/see-how-things-really-work-39fbef93.png new file mode 100644 index 000000000..abd234cea Binary files /dev/null and b/pr-1683/assets/images/see-how-things-really-work-39fbef93.png differ diff --git a/pr-1683/assets/images/see-how-things-work-ff28c0ec.png b/pr-1683/assets/images/see-how-things-work-ff28c0ec.png new file mode 100644 index 000000000..b3ac82315 Binary files /dev/null and b/pr-1683/assets/images/see-how-things-work-ff28c0ec.png differ diff --git a/pr-1683/assets/images/texture-bg-2-9c21c423.jpg b/pr-1683/assets/images/texture-bg-2-9c21c423.jpg new file mode 100644 index 000000000..5e5d57662 Binary files /dev/null and b/pr-1683/assets/images/texture-bg-2-9c21c423.jpg differ diff --git a/pr-1683/assets/images/texture-bg-35f0b9ad.jpg b/pr-1683/assets/images/texture-bg-35f0b9ad.jpg new file mode 100644 index 000000000..b90aa9ae6 Binary files /dev/null and b/pr-1683/assets/images/texture-bg-35f0b9ad.jpg differ diff --git a/pr-1683/assets/images/texture-bg-grey-8c7af6fc.jpg b/pr-1683/assets/images/texture-bg-grey-8c7af6fc.jpg new file mode 100644 index 000000000..7ba93c876 Binary files /dev/null and b/pr-1683/assets/images/texture-bg-grey-8c7af6fc.jpg differ diff --git a/pr-1683/assets/images/timestamps-in-console-logs-example-eb317f14.png b/pr-1683/assets/images/timestamps-in-console-logs-example-eb317f14.png new file mode 100644 index 000000000..b484fcb21 Binary files /dev/null and b/pr-1683/assets/images/timestamps-in-console-logs-example-eb317f14.png differ diff --git a/pr-1683/assets/images/version-bg-ad19c611.png b/pr-1683/assets/images/version-bg-ad19c611.png new file mode 100644 index 000000000..e2c8c469b Binary files /dev/null and b/pr-1683/assets/images/version-bg-ad19c611.png differ diff --git a/pr-1683/assets/images/video.mov b/pr-1683/assets/images/video.mov new file mode 100644 index 000000000..02b91ddba Binary files /dev/null and b/pr-1683/assets/images/video.mov differ diff --git a/pr-1683/assets/images/videos/go-command-repo-4cd595b8.jpg b/pr-1683/assets/images/videos/go-command-repo-4cd595b8.jpg new file mode 100644 index 000000000..f45960875 Binary files /dev/null and b/pr-1683/assets/images/videos/go-command-repo-4cd595b8.jpg differ diff --git a/pr-1683/assets/images/videos/go-failed-smoke-test-82510d2b.jpg b/pr-1683/assets/images/videos/go-failed-smoke-test-82510d2b.jpg new file mode 100644 index 000000000..fea0d5141 Binary files /dev/null and b/pr-1683/assets/images/videos/go-failed-smoke-test-82510d2b.jpg differ diff --git a/pr-1683/assets/images/videos/go-fan-out-fan-dda14cdd.jpg b/pr-1683/assets/images/videos/go-fan-out-fan-dda14cdd.jpg new file mode 100644 index 000000000..aed4e6ddd Binary files /dev/null and b/pr-1683/assets/images/videos/go-fan-out-fan-dda14cdd.jpg differ diff --git a/pr-1683/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg b/pr-1683/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg new file mode 100644 index 000000000..a6e2d14e0 Binary files /dev/null and b/pr-1683/assets/images/videos/go-fundamental-concepts-3643ce4a.jpg differ diff --git a/pr-1683/assets/images/videos/go-linking-dependencies-f51246fd.jpg b/pr-1683/assets/images/videos/go-linking-dependencies-f51246fd.jpg new file mode 100644 index 000000000..9841122f5 Binary files /dev/null and b/pr-1683/assets/images/videos/go-linking-dependencies-f51246fd.jpg differ diff --git a/pr-1683/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg b/pr-1683/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg new file mode 100644 index 000000000..32c62d3c8 Binary files /dev/null and b/pr-1683/assets/images/videos/go-pipeline-visibility-9e2c5d77.jpg differ diff --git a/pr-1683/assets/images/videos/go-value-stream-map-d215777c.jpg b/pr-1683/assets/images/videos/go-value-stream-map-d215777c.jpg new file mode 100644 index 000000000..d1d146e1d Binary files /dev/null and b/pr-1683/assets/images/videos/go-value-stream-map-d215777c.jpg differ diff --git a/pr-1683/assets/images/vms-build-time-7ae5af26.jpg b/pr-1683/assets/images/vms-build-time-7ae5af26.jpg new file mode 100644 index 000000000..f1150508e Binary files /dev/null and b/pr-1683/assets/images/vms-build-time-7ae5af26.jpg differ diff --git a/pr-1683/assets/javascripts/all-74d6f297.js b/pr-1683/assets/javascripts/all-74d6f297.js new file mode 100644 index 000000000..9305c22f7 --- /dev/null +++ b/pr-1683/assets/javascripts/all-74d6f297.js @@ -0,0 +1,81 @@ +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 l=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){l(t,0)},i._unhandledRejectionFn=function(t){void 0!==console&&console&&console.warn("Possible Unhandled Promise Rejection:",t)};var c=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 c?c.Promise.prototype["finally"]||(c.Promise.prototype["finally"]=t):c.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,!(_=p.exec(t)))break;for(var S=_.index+(d?_[1].length:0),k=_.index+_[0].length,C=b,E=w,T=n.length;C"+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}(),/*! + * jQuery JavaScript Library v1.12.3 + * http://jquery.com/ + * + * Includes Sizzle.js + * http://sizzlejs.com/ + * + * Copyright jQuery Foundation and other contributors + * Released under the MIT license + * http://jquery.org/license + * + * Date: 2016-04-05T19:16Z + */ +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(n===undefined&&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=undefined}return n}function l(t){var e;for(e in t)if(("data"!==e||!ft.isEmptyObject(t[e]))&&"toJSON"!==e)return!1;return!0}function c(t,e,n,i){if(Ot(t)){var r,o,s=ft.expando,a=t.nodeType,u=a?ft.cache:t,l=a?t[s]:t[s]&&s;if(l&&u[l]&&(i||u[l].data)||n!==undefined||"string"!=typeof e)return l||(l=a?t[s]=nt.pop()||ft.guid++:s),u[l]||(u[l]=a?{}:{toJSON:ft.noop}),"object"!=typeof e&&"function"!=typeof e||(i?u[l]=ft.extend(u[l],e):u[l].data=ft.extend(u[l].data,e)),o=u[l],i||(o.data||(o.data={}),o=o.data),n!==undefined&&(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(Ot(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?!l(i):!ft.isEmptyObject(i))return}(n||(delete s[a].data,l(s[a])))&&(o?ft.cleanData([t],!0):ht.deleteExpando||s!=s.window?delete s[a]:s[a]=undefined)}}}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(),l=n&&n[3]||(ft.cssNumber[e]?"":"px"),c=(ft.cssNumber[e]||"px"!==l&&+u)&&$t.exec(ft.css(t,e));if(c&&c[3]!==l){l=l||c[3],n=n||[],c=+u||1;do{o=o||".5",c/=o,ft.style(t,e,c+l)}while(o!==(o=a()/u)&&1!==o&&--s)}return n&&(c=+c||+u||0,r=n[1]?c+(n[1]+1)*n[2]:+n[2],i&&(i.unit=l,i.start=c,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||"*"):undefined;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 e===undefined||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){Mt.test(t.type)&&(t.defaultChecked=t.checked)}function v(t,e,n,i,r){for(var o,s,a,u,l,c,h,p=t.length,v=f(e),y=[],b=0;b"!==h[1]||Vt.test(s)?0:u:u.firstChild,o=s&&s.childNodes.length;o--;)ft.nodeName(c=s.childNodes[o],"tbody")&&!c.childNodes.length&&s.removeChild(c);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=undefined);for(a in e)x(t,a,n,i,e[a],o);return t}if(null==i&&null==r?(r=n,i=n=undefined):null==r&&("string"==typeof n?(r=i,i=undefined):(r=i,i=n,n=undefined)),!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;i1&&"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())),_(o,e,n,i)});if(h&&(l=v(e,t[0].ownerDocument,!1,t,i),r=l.firstChild,1===l.childNodes.length&&(l=r),r||i)){for(a=ft.map(d(l,"script"),k),s=a.length;c")).appendTo(e.documentElement),e=(ae[0].contentWindow||ae[0].contentDocument).document,e.write(),e.close(),n=N(t,e),ae.detach()),ue[t]=n),n}function O(t,e){return{get:function(){return t()?void delete this.get:(this.get=e).apply(this,arguments)}}}function I(t){if(t in ke)return t;for(var e=t.charAt(0).toUpperCase()+t.slice(1),n=Se.length;n--;)if((t=Se[n]+e)in ke)return t}function L(t,e){for(var n,i,r,o=[],s=0,a=t.length;s=0&&n=0},isEmptyObject:function(t){var e;for(e in t)return!1;return!0},isPlainObject:function(t){var e;if(!t||"object"!==ft.type(t)||t.nodeType||ft.isWindow(t))return!1;try{if(t.constructor&&!ct.call(t,"constructor")&&!ct.call(t.constructor.prototype,"isPrototypeOf"))return!1}catch(t){return!1}if(!ht.ownFirst)for(e in t)return ct.call(t,e);for(e in t);return e===undefined||ct.call(t,e)},type:function(t){return null==t?t+"":"object"==typeof t||"function"==typeof t?ut[lt.call(t)]||"object":typeof t},globalEval:function(e){e&&ft.trim(e)&&(t.execScript||function(e){t.eval.call(t,e)})(e)},camelCase:function(t){return t.replace(mt,"ms-").replace(gt,vt)},nodeName:function(t,e){return t.nodeName&&t.nodeName.toLowerCase()===e.toLowerCase()},each:function(t,e){var i,r=0;if(n(t))for(i=t.length;rS.cacheLength&&delete t[e.shift()],t[n+" "]=i}var e=[];return t}function i(t){return t[M]=!0,t}function r(t){var e=I.createElement("div");try{return!!t(e)}catch(t){return!1}finally{e.parentNode&&e.parentNode.removeChild(e),e=null}}function o(t,e){for(var n=t.split("|"),i=n.length;i--;)S.attrHandle[n[i]]=e}function s(t,e){var n=e&&t,i=n&&1===t.nodeType&&1===e.nodeType&&(~e.sourceIndex||G)-(~t.sourceIndex||G);if(i)return i;if(n)for(;n=n.nextSibling;)if(n===e)return-1;return t?1:-1}function a(t){return function(e){return"input"===e.nodeName.toLowerCase()&&e.type===t}}function u(t){return function(e){var n=e.nodeName.toLowerCase();return("input"===n||"button"===n)&&e.type===t}}function l(t){return i(function(e){return e=+e,i(function(n,i){for(var r,o=t([],n.length,e),s=o.length;s--;)n[r=o[s]]&&(n[r]=!(i[r]=n[r]))})})}function c(t){return t&&"undefined"!=typeof t.getElementsByTagName&&t}function h(){}function p(t){for(var e=0,n=t.length,i="";e1?function(e,n,i){for(var r=t.length;r--;)if(!t[r](e,n,i))return!1;return!0}:t[0]}function m(t,n,i){for(var r=0,o=n.length;r-1&&(i[l]=!(s[l]=h))}}else b=g(b===s?b.splice(d,b.length):b),o?o(null,s,b,u):Q.apply(s,b)})}function y(t){for(var e,n,i,r=t.length,o=S.relative[t[0].type],s=o||S.relative[" "],a=o?1:0,u=f(function(t){return t===e},s,!0),l=f(function(t){return tt(e,t)>-1},s,!0),c=[function(t,n,i){var r=!o&&(i||n!==P)||((e=n).nodeType?u(t,n,i):l(t,n,i));return e=null,r}];a1&&d(c),a>1&&p(t.slice(0,a-1).concat({value:" "===t[a-2].type?"*":""})).replace(at,"$1"),n,a0,o=t.length>0,s=function(i,s,a,u,l){var c,h,p,f=0,d="0",m=i&&[],v=[],y=P,b=i||o&&S.find.TAG("*",l),w=B+=null==y?1:Math.random()||.1,x=b.length;for(l&&(P=s===I||s||l);d!==x&&null!=(c=b[d]);d++){if(o&&c){for(h=0,s||c.ownerDocument===I||(O(c),a=!D);p=t[h++];)if(p(c,s||I,a)){u.push(c);break}l&&(B=w)}r&&((c=!p&&c)&&f--,i&&m.push(c))}if(f+=d,r&&d!==f){for(h=0;p=n[h++];)p(m,v,s,a);if(i){if(f>0)for(;d--;)m[d]||v[d]||(v[d]=K.call(u));v=g(v)}Q.apply(u,v),l&&!i&&v.length>0&&f+n.length>1&&e.uniqueSort(u)}return l&&(B=w,P=y),m};return r?i(s):s}var w,x,S,k,C,E,T,_,P,N,A,O,I,L,D,$,j,R,H,M="sizzle"+1*new Date,z=t.document,B=0,F=0,q=n(),W=n(),U=n(),V=function(t,e){return t===e&&(A=!0),0},G=1<<31,X={}.hasOwnProperty,Y=[],K=Y.pop,J=Y.push,Q=Y.push,Z=Y.slice,tt=function(t,e){for(var n=0,i=t.length;n+~]|"+nt+")"+nt+"*"),ct=new RegExp("="+nt+"*([^\\]'\"]*?)"+nt+"*\\]","g"),ht=new RegExp(ot),pt=new RegExp("^"+it+"$"),ft={ID:new RegExp("^#("+it+")"),CLASS:new RegExp("^\\.("+it+")"),TAG:new RegExp("^("+it+"|[*])"),ATTR:new RegExp("^"+rt),PSEUDO:new RegExp("^"+ot),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+nt+"*(even|odd|(([+-]|)(\\d*)n|)"+nt+"*(?:([+-]|)"+nt+"*(\\d+)|))"+nt+"*\\)|)","i"),bool:new RegExp("^(?:"+et+")$","i"),needsContext:new RegExp("^"+nt+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+nt+"*((?:-\\d)?\\d*)"+nt+"*\\)|)(?=[^-]|$)","i")},dt=/^(?:input|select|textarea|button)$/i,mt=/^h\d$/i,gt=/^[^{]+\{\s*\[native \w/,vt=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,yt=/[+~]/,bt=/'|\\/g,wt=new RegExp("\\\\([\\da-f]{1,6}"+nt+"?|("+nt+")|.)","ig"),xt=function(t,e,n){var i="0x"+e-65536;return i!==i||n?e:i<0?String.fromCharCode(i+65536):String.fromCharCode(i>>10|55296,1023&i|56320)},St=function(){O()};try{Q.apply(Y=Z.call(z.childNodes),z.childNodes),Y[z.childNodes.length].nodeType}catch(t){Q={apply:Y.length?function(t,e){J.apply(t,Z.call(e))}:function(t,e){for(var n=t.length,i=0;t[n++]=e[i++];);t.length=n-1}}}x=e.support={},C=e.isXML=function(t){var e=t&&(t.ownerDocument||t).documentElement;return!!e&&"HTML"!==e.nodeName},O=e.setDocument=function(t){var e,n,i=t?t.ownerDocument||t:z;return i!==I&&9===i.nodeType&&i.documentElement?(I=i,L=I.documentElement,D=!C(I),(n=I.defaultView)&&n.top!==n&&(n.addEventListener?n.addEventListener("unload",St,!1):n.attachEvent&&n.attachEvent("onunload",St)),x.attributes=r(function(t){return t.className="i",!t.getAttribute("className")}),x.getElementsByTagName=r(function(t){return t.appendChild(I.createComment("")),!t.getElementsByTagName("*").length}),x.getElementsByClassName=gt.test(I.getElementsByClassName),x.getById=r(function(t){return L.appendChild(t).id=M,!I.getElementsByName||!I.getElementsByName(M).length}),x.getById?(S.find.ID=function(t,e){if("undefined"!=typeof e.getElementById&&D){var n=e.getElementById(t);return n?[n]:[]}},S.filter.ID=function(t){var e=t.replace(wt,xt);return function(t){return t.getAttribute("id")===e}}):(delete S.find.ID,S.filter.ID=function(t){var e=t.replace(wt,xt);return function(t){var n="undefined"!=typeof t.getAttributeNode&&t.getAttributeNode("id");return n&&n.value===e}}),S.find.TAG=x.getElementsByTagName?function(t,e){return"undefined"!=typeof e.getElementsByTagName?e.getElementsByTagName(t):x.qsa?e.querySelectorAll(t):void 0}:function(t,e){var n,i=[],r=0,o=e.getElementsByTagName(t);if("*"===t){for(;n=o[r++];)1===n.nodeType&&i.push(n);return i}return o},S.find.CLASS=x.getElementsByClassName&&function(t,e){if("undefined"!=typeof e.getElementsByClassName&&D)return e.getElementsByClassName(t)},j=[],$=[],(x.qsa=gt.test(I.querySelectorAll))&&(r(function(t){L.appendChild(t).innerHTML="",t.querySelectorAll("[msallowcapture^='']").length&&$.push("[*^$]="+nt+"*(?:''|\"\")"),t.querySelectorAll("[selected]").length||$.push("\\["+nt+"*(?:value|"+et+")"),t.querySelectorAll("[id~="+M+"-]").length||$.push("~="),t.querySelectorAll(":checked").length||$.push(":checked"),t.querySelectorAll("a#"+M+"+*").length||$.push(".#.+[+~]")}),r(function(t){var e=I.createElement("input");e.setAttribute("type","hidden"),t.appendChild(e).setAttribute("name","D"),t.querySelectorAll("[name=d]").length&&$.push("name"+nt+"*[*^$|!~]?="),t.querySelectorAll(":enabled").length||$.push(":enabled",":disabled"),t.querySelectorAll("*,:x"),$.push(",.*:")})),(x.matchesSelector=gt.test(R=L.matches||L.webkitMatchesSelector||L.mozMatchesSelector||L.oMatchesSelector||L.msMatchesSelector))&&r(function(t){x.disconnectedMatch=R.call(t,"div"),R.call(t,"[s!='']:x"),j.push("!=",ot)}),$=$.length&&new RegExp($.join("|")),j=j.length&&new RegExp(j.join("|")),e=gt.test(L.compareDocumentPosition),H=e||gt.test(L.contains)?function(t,e){var n=9===t.nodeType?t.documentElement:t,i=e&&e.parentNode;return t===i||!(!i||1!==i.nodeType||!(n.contains?n.contains(i):t.compareDocumentPosition&&16&t.compareDocumentPosition(i)))}:function(t,e){if(e)for(;e=e.parentNode;)if(e===t)return!0;return!1},V=e?function(t,e){if(t===e)return A=!0,0;var n=!t.compareDocumentPosition-!e.compareDocumentPosition;return n||(n=(t.ownerDocument||t)===(e.ownerDocument||e)?t.compareDocumentPosition(e):1,1&n||!x.sortDetached&&e.compareDocumentPosition(t)===n?t===I||t.ownerDocument===z&&H(z,t)?-1:e===I||e.ownerDocument===z&&H(z,e)?1:N?tt(N,t)-tt(N,e):0:4&n?-1:1)}:function(t,e){if(t===e)return A=!0,0;var n,i=0,r=t.parentNode,o=e.parentNode,a=[t],u=[e];if(!r||!o)return t===I?-1:e===I?1:r?-1:o?1:N?tt(N,t)-tt(N,e):0;if(r===o)return s(t,e);for(n=t;n=n.parentNode;)a.unshift(n);for(n=e;n=n.parentNode;)u.unshift(n);for(;a[i]===u[i];)i++;return i?s(a[i],u[i]):a[i]===z?-1:u[i]===z?1:0},I):I},e.matches=function(t,n){return e(t,null,null,n)},e.matchesSelector=function(t,n){if((t.ownerDocument||t)!==I&&O(t),n=n.replace(ct,"='$1']"),x.matchesSelector&&D&&!U[n+" "]&&(!j||!j.test(n))&&(!$||!$.test(n)))try{var i=R.call(t,n);if(i||x.disconnectedMatch||t.document&&11!==t.document.nodeType)return i}catch(t){}return e(n,I,null,[t]).length>0},e.contains=function(t,e){return(t.ownerDocument||t)!==I&&O(t),H(t,e)},e.attr=function(t,e){(t.ownerDocument||t)!==I&&O(t);var n=S.attrHandle[e.toLowerCase()],i=n&&X.call(S.attrHandle,e.toLowerCase())?n(t,e,!D):undefined;return i!==undefined?i:x.attributes||!D?t.getAttribute(e):(i=t.getAttributeNode(e))&&i.specified?i.value:null},e.error=function(t){throw new Error("Syntax error, unrecognized expression: "+t)},e.uniqueSort=function(t){var e,n=[],i=0,r=0;if(A=!x.detectDuplicates,N=!x.sortStable&&t.slice(0),t.sort(V),A){for(;e=t[r++];)e===t[r]&&(i=n.push(r));for(;i--;)t.splice(n[i],1)}return N=null,t},k=e.getText=function(t){var e,n="",i=0,r=t.nodeType;if(r){if(1===r||9===r||11===r){if("string"==typeof t.textContent)return t.textContent;for(t=t.firstChild;t;t=t.nextSibling)n+=k(t)}else if(3===r||4===r)return t.nodeValue}else for(;e=t[i++];)n+=k(e);return n},S=e.selectors={cacheLength:50,createPseudo:i,match:ft,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(t){return t[1]=t[1].replace(wt,xt),t[3]=(t[3]||t[4]||t[5]||"").replace(wt,xt),"~="===t[2]&&(t[3]=" "+t[3]+" "),t.slice(0,4)},CHILD:function(t){return t[1]=t[1].toLowerCase(),"nth"===t[1].slice(0,3)?(t[3]||e.error(t[0]),t[4]=+(t[4]?t[5]+(t[6]||1):2*("even"===t[3]||"odd"===t[3])),t[5]=+(t[7]+t[8]||"odd"===t[3])):t[3]&&e.error(t[0]),t},PSEUDO:function(t){var e,n=!t[6]&&t[2];return ft.CHILD.test(t[0])?null:(t[3]?t[2]=t[4]||t[5]||"":n&&ht.test(n)&&(e=E(n,!0))&&(e=n.indexOf(")",n.length-e)-n.length)&&(t[0]=t[0].slice(0,e),t[2]=n.slice(0,e)),t.slice(0,3))}},filter:{TAG:function(t){var e=t.replace(wt,xt).toLowerCase();return"*"===t?function(){return!0}:function(t){return t.nodeName&&t.nodeName.toLowerCase()===e}},CLASS:function(t){var e=q[t+" "];return e||(e=new RegExp("(^|"+nt+")"+t+"("+nt+"|$)"))&&q(t,function(t){return e.test("string"==typeof t.className&&t.className||"undefined"!=typeof t.getAttribute&&t.getAttribute("class")||"")})},ATTR:function(t,n,i){return function(r){var o=e.attr(r,t);return null==o?"!="===n:!n||(o+="","="===n?o===i:"!="===n?o!==i:"^="===n?i&&0===o.indexOf(i):"*="===n?i&&o.indexOf(i)>-1:"$="===n?i&&o.slice(-i.length)===i:"~="===n?(" "+o.replace(st," ")+" ").indexOf(i)>-1:"|="===n&&(o===i||o.slice(0,i.length+1)===i+"-"))}},CHILD:function(t,e,n,i,r){var o="nth"!==t.slice(0,3),s="last"!==t.slice(-4),a="of-type"===e;return 1===i&&0===r?function(t){return!!t.parentNode}:function(e,n,u){var l,c,h,p,f,d,m=o!==s?"nextSibling":"previousSibling",g=e.parentNode,v=a&&e.nodeName.toLowerCase(),y=!u&&!a,b=!1;if(g){if(o){for(;m;){for(p=e;p=p[m];)if(a?p.nodeName.toLowerCase()===v:1===p.nodeType)return!1;d=m="only"===t&&!d&&"nextSibling"}return!0}if(d=[s?g.firstChild:g.lastChild],s&&y){for(p=g,h=p[M]||(p[M]={}),c=h[p.uniqueID]||(h[p.uniqueID]={}),l=c[t]||[],f=l[0]===B&&l[1],b=f&&l[2],p=f&&g.childNodes[f];p=++f&&p&&p[m]||(b=f=0)||d.pop();)if(1===p.nodeType&&++b&&p===e){c[t]=[B,f,b];break}}else if(y&&(p=e,h=p[M]||(p[M]={}),c=h[p.uniqueID]||(h[p.uniqueID]={}),l=c[t]||[],f=l[0]===B&&l[1],b=f),!1===b)for(;(p=++f&&p&&p[m]||(b=f=0)||d.pop())&&((a?p.nodeName.toLowerCase()!==v:1!==p.nodeType)||!++b||(y&&(h=p[M]||(p[M]={}),c=h[p.uniqueID]||(h[p.uniqueID]={}),c[t]=[B,b]),p!==e)););return(b-=r)===i||b%i==0&&b/i>=0}}},PSEUDO:function(t,n){var r,o=S.pseudos[t]||S.setFilters[t.toLowerCase()]||e.error("unsupported pseudo: "+t);return o[M]?o(n):o.length>1?(r=[t,t,"",n],S.setFilters.hasOwnProperty(t.toLowerCase())?i(function(t,e){for(var i,r=o(t,n),s=r.length;s--;)i=tt(t,r[s]),t[i]=!(e[i]=r[s])}):function(t){return o(t,0,r)}):o}},pseudos:{not:i(function(t){var e=[],n=[],r=T(t.replace(at,"$1"));return r[M]?i(function(t,e,n,i){for(var o,s=r(t,null,i,[]),a=t.length;a--;)(o=s[a])&&(t[a]=!(e[a]=o))}):function(t,i,o){return e[0]=t,r(e,null,o,n),e[0]=null,!n.pop()}}),has:i(function(t){return function(n){return e(t,n).length>0}}),contains:i(function(t){return t=t.replace(wt,xt),function(e){return(e.textContent||e.innerText||k(e)).indexOf(t)>-1}}),lang:i(function(t){return pt.test(t||"")||e.error("unsupported lang: "+t),t=t.replace(wt,xt).toLowerCase(),function(e){var n;do{if(n=D?e.lang:e.getAttribute("xml:lang")||e.getAttribute("lang"))return(n=n.toLowerCase())===t||0===n.indexOf(t+"-")}while((e=e.parentNode)&&1===e.nodeType);return!1}}),target:function(e){var n=t.location&&t.location.hash;return n&&n.slice(1)===e.id},root:function(t){return t===L},focus:function(t){return t===I.activeElement&&(!I.hasFocus||I.hasFocus())&&!!(t.type||t.href||~t.tabIndex)},enabled:function(t){return!1===t.disabled},disabled:function(t){return!0===t.disabled},checked:function(t){var e=t.nodeName.toLowerCase();return"input"===e&&!!t.checked||"option"===e&&!!t.selected},selected:function(t){return t.parentNode&&t.parentNode.selectedIndex,!0===t.selected},empty:function(t){for(t=t.firstChild;t;t=t.nextSibling)if(t.nodeType<6)return!1;return!0},parent:function(t){return!S.pseudos.empty(t)},header:function(t){return mt.test(t.nodeName)},input:function(t){return dt.test(t.nodeName)},button:function(t){var e=t.nodeName.toLowerCase();return"input"===e&&"button"===t.type||"button"===e},text:function(t){var e;return"input"===t.nodeName.toLowerCase()&&"text"===t.type&&(null==(e=t.getAttribute("type"))||"text"===e.toLowerCase())},first:l(function(){return[0]}),last:l(function(t,e){return[e-1]}),eq:l(function(t,e,n){return[n<0?n+e:n]}),even:l(function(t,e){for(var n=0;n=0;)t.push(i);return t}),gt:l(function(t,e,n){for(var i=n<0?n+e:n;++i2&&"ID"===(s=o[0]).type&&x.getById&&9===e.nodeType&&D&&S.relative[o[1].type]){if(!(e=(S.find.ID(s.matches[0].replace(wt,xt),e)||[])[0]))return n;l&&(e=e.parentNode),t=t.slice(o.shift().value.length)}for(r=ft.needsContext.test(t)?0:o.length;r--&&(s=o[r],!S.relative[a=s.type]);)if((u=S.find[a])&&(i=u(s.matches[0].replace(wt,xt),yt.test(o[0].type)&&c(e.parentNode)||e))){if(o.splice(r,1),!(t=i.length&&p(o)))return Q.apply(n,i),n;break}}return(l||T(t,h))(i,e,!D,n,!e||yt.test(t)&&c(e.parentNode)||e),n},x.sortStable=M.split("").sort(V).join("")===M,x.detectDuplicates=!!A,O(),x.sortDetached=r(function(t){return 1&t.compareDocumentPosition(I.createElement("div"))}),r(function(t){return t.innerHTML="","#"===t.firstChild.getAttribute("href")})||o("type|href|height|width",function(t,e,n){if(!n)return t.getAttribute(e,"type"===e.toLowerCase()?1:2)}),x.attributes&&r(function(t){return t.innerHTML="",t.firstChild.setAttribute("value",""),""===t.firstChild.getAttribute("value")})||o("value",function(t,e,n){if(!n&&"input"===t.nodeName.toLowerCase())return t.defaultValue}),r(function(t){return null==t.getAttribute("disabled")})||o(et,function(t,e,n){var i;if(!n)return!0===t[e]?e.toLowerCase():(i=t.getAttributeNode(e))&&i.specified?i.value:null}),e}(t);ft.find=yt,ft.expr=yt.selectors,ft.expr[":"]=ft.expr.pseudos,ft.uniqueSort=ft.unique=yt.uniqueSort,ft.text=yt.getText,ft.isXMLDoc=yt.isXML,ft.contains=yt.contains;var bt=function(t,e,n){for(var i=[],r=n!==undefined;(t=t[e])&&9!==t.nodeType;)if(1===t.nodeType){if(r&&ft(t).is(n))break;i.push(t)}return i},wt=function(t,e){for(var n=[];t;t=t.nextSibling)1===t.nodeType&&t!==e&&n.push(t);return n},xt=ft.expr.match.needsContext,St=/^<([\w-]+)\s*\/?>(?:<\/\1>|)$/,kt=/^.[^:#\[\.,]*$/;ft.filter=function(t,e,n){var i=e[0];return n&&(t=":not("+t+")"),1===e.length&&1===i.nodeType?ft.find.matchesSelector(i,t)?[i]:[]:ft.find.matches(t,ft.grep(e,function(t){return 1===t.nodeType}))},ft.fn.extend({find:function(t){var e,n=[],i=this,r=i.length;if("string"!=typeof t)return this.pushStack(ft(t).filter(function(){for(e=0;e1?ft.unique(n):n),n.selector=this.selector?this.selector+" "+t:t,n},filter:function(t){return this.pushStack(i(this,t||[],!1))},not:function(t){return this.pushStack(i(this,t||[],!0))},is:function(t){return!!i(this,"string"==typeof t&&xt.test(t)?ft(t):t||[],!1).length}});var Ct,Et=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/;(ft.fn.init=function(t,e,n){var i,r;if(!t)return this;if(n=n||Ct,"string"==typeof t){if(!(i="<"===t.charAt(0)&&">"===t.charAt(t.length-1)&&t.length>=3?[null,t,null]:Et.exec(t))||!i[1]&&e)return!e||e.jquery?(e||n).find(t):this.constructor(e).find(t);if(i[1]){if(e=e instanceof ft?e[0]:e,ft.merge(this,ft.parseHTML(i[1],e&&e.nodeType?e.ownerDocument||e:it,!0)),St.test(i[1])&&ft.isPlainObject(e))for(i in e)ft.isFunction(this[i])?this[i](e[i]):this.attr(i,e[i]);return this}if((r=it.getElementById(i[2]))&&r.parentNode){if(r.id!==i[2])return Ct.find(t);this.length=1,this[0]=r}return this.context=it,this.selector=t,this}return t.nodeType?(this.context=this[0]=t,this.length=1,this):ft.isFunction(t)?"undefined"!=typeof n.ready?n.ready(t):t(ft):(t.selector!==undefined&&(this.selector=t.selector,this.context=t.context),ft.makeArray(t,this))}).prototype=ft.fn,Ct=ft(it);var Tt=/^(?:parents|prev(?:Until|All))/,_t={children:!0,contents:!0,next:!0,prev:!0};ft.fn.extend({has:function(t){var e,n=ft(t,this),i=n.length;return this.filter(function(){for(e=0;e-1:1===n.nodeType&&ft.find.matchesSelector(n,t))){o.push(n);break}return this.pushStack(o.length>1?ft.uniqueSort(o):o)},index:function(t){return t?"string"==typeof t?ft.inArray(this[0],ft(t)):ft.inArray(t.jquery?t[0]:t,this):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(t,e){return this.pushStack(ft.uniqueSort(ft.merge(this.get(),ft(t,e))))},addBack:function(t){return this.add(null==t?this.prevObject:this.prevObject.filter(t))}}),ft.each({parent:function(t){var e=t.parentNode;return e&&11!==e.nodeType?e:null},parents:function(t){return bt(t,"parentNode")},parentsUntil:function(t,e,n){return bt(t,"parentNode",n)},next:function(t){return r(t,"nextSibling")},prev:function(t){return r(t,"previousSibling")},nextAll:function(t){return bt(t,"nextSibling")},prevAll:function(t){return bt(t,"previousSibling")},nextUntil:function(t,e,n){return bt(t,"nextSibling",n)},prevUntil:function(t,e,n){return bt(t,"previousSibling",n)},siblings:function(t){return wt((t.parentNode||{}).firstChild,t)},children:function(t){return wt(t.firstChild)},contents:function(t){return ft.nodeName(t,"iframe")?t.contentDocument||t.contentWindow.document:ft.merge([],t.childNodes)}},function(t,e){ft.fn[t]=function(n,i){var r=ft.map(this,e,n);return"Until"!==t.slice(-5)&&(i=n),i&&"string"==typeof i&&(r=ft.filter(i,r)),this.length>1&&(_t[t]||(r=ft.uniqueSort(r)),Tt.test(t)&&(r=r.reverse())),this.pushStack(r)}});var Pt=/\S+/g;ft.Callbacks=function(t){t="string"==typeof t?o(t):ft.extend({},t);var e,n,i,r,s=[],a=[],u=-1,l=function(){for(r=t.once,i=e=!0;a.length;u=-1)for(n=a.shift();++u-1;)s.splice(n,1),n<=u&&u--}),this},has:function(t){return t?ft.inArray(t,s)>-1:s.length>0},empty:function(){return s&&(s=[]),this},disable:function(){return r=a=[],s=n="",this},disabled:function(){return!s},lock:function(){return r=!0,n||c.disable(),this},locked:function(){return!!r},fireWith:function(t,n){return r||(n=n||[],n=[t,n.slice?n.slice():n],a.push(n),e||l()),this},fire:function(){return c.fireWith(this,arguments),this},fired:function(){return!!i}};return c},ft.extend({Deferred:function(t){var e=[["resolve","done",ft.Callbacks("once memory"),"resolved"],["reject","fail",ft.Callbacks("once memory"),"rejected"],["notify","progress",ft.Callbacks("memory")]],n="pending",i={state:function(){return n},always:function(){return r.done(arguments).fail(arguments),this},then:function(){var t=arguments;return ft.Deferred(function(n){ft.each(e,function(e,o){var s=ft.isFunction(t[e])&&t[e];r[o[1]](function(){var t=s&&s.apply(this,arguments);t&&ft.isFunction(t.promise)?t.promise().progress(n.notify).done(n.resolve).fail(n.reject):n[o[0]+"With"](this===i?n.promise():this,s?[t]:arguments)})}),t=null}).promise()},promise:function(t){return null!=t?ft.extend(t,i):i}},r={};return i.pipe=i.then,ft.each(e,function(t,o){var s=o[2],a=o[3];i[o[1]]=s.add,a&&s.add(function(){n=a},e[1^t][2].disable,e[2][2].lock),r[o[0]]=function(){return r[o[0]+"With"](this===r?i:this,arguments),this},r[o[0]+"With"]=s.fireWith}),i.promise(r),t&&t.call(r,r),r},when:function(t){var e,n,i,r=0,o=rt.call(arguments),s=o.length,a=1!==s||t&&ft.isFunction(t.promise)?s:0,u=1===a?t:ft.Deferred(),l=function(t,n,i){return function(r){n[t]=this,i[t]=arguments.length>1?rt.call(arguments):r,i===e?u.notifyWith(n,i):--a||u.resolveWith(n,i)}};if(s>1)for(e=new Array(s),n=new Array(s),i=new Array(s);r0||(Nt.resolveWith(it,[ft]),ft.fn.triggerHandler&&(ft(it).triggerHandler("ready"),ft(it).off("ready"))))}}),ft.ready.promise=function(e){if(!Nt)if(Nt=ft.Deferred(),"complete"===it.readyState||"loading"!==it.readyState&&!it.documentElement.doScroll)t.setTimeout(ft.ready);else if(it.addEventListener)it.addEventListener("DOMContentLoaded",a),t.addEventListener("load",a);else{it.attachEvent("onreadystatechange",a),t.attachEvent("onload",a);var n=!1;try{n=null==t.frameElement&&it.documentElement}catch(t){}n&&n.doScroll&&function e(){if(!ft.isReady){try{n.doScroll("left")}catch(n){return t.setTimeout(e,50)}s(),ft.ready()}}()}return Nt.promise(e)},ft.ready.promise();var At;for(At in ft(ht))break;ht.ownFirst="0"===At,ht.inlineBlockNeedsLayout=!1,ft(function(){var t,e,n,i;(n=it.getElementsByTagName("body")[0])&&n.style&&(e=it.createElement("div"),i=it.createElement("div"),i.style.cssText="position:absolute;border:0;width:0;height:0;top:0;left:-9999px",n.appendChild(i).appendChild(e),"undefined"!=typeof e.style.zoom&&(e.style.cssText="display:inline;margin:0;border:0;padding:1px;width:1px;zoom:1",ht.inlineBlockNeedsLayout=t=3===e.offsetWidth,t&&(n.style.zoom=1)),n.removeChild(i))}),function(){var t=it.createElement("div");ht.deleteExpando=!0;try{delete t.test}catch(t){ht.deleteExpando=!1}t=null}();var Ot=function(t){var e=ft.noData[(t.nodeName+" ").toLowerCase()],n=+t.nodeType||1;return(1===n||9===n)&&(!e||!0!==e&&t.getAttribute("classid")===e)},It=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,Lt=/([A-Z])/g;ft.extend({cache:{},noData:{"applet ":!0,"embed ":!0,"object ":"clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"},hasData:function(t){return!!(t=t.nodeType?ft.cache[t[ft.expando]]:t[ft.expando])&&!l(t)},data:function(t,e,n){return c(t,e,n)},removeData:function(t,e){return h(t,e)},_data:function(t,e,n){return c(t,e,n,!0)},_removeData:function(t,e){return h(t,e,!0)}}),ft.fn.extend({data:function(t,e){var n,i,r,o=this[0],s=o&&o.attributes;if(t===undefined){if(this.length&&(r=ft.data(o),1===o.nodeType&&!ft._data(o,"parsedAttrs"))){for(n=s.length;n--;)s[n]&&(i=s[n].name,0===i.indexOf("data-")&&(i=ft.camelCase(i.slice(5)),u(o,i,r[i])));ft._data(o,"parsedAttrs",!0)}return r}return"object"==typeof t?this.each(function(){ft.data(this,t)}):arguments.length>1?this.each(function(){ft.data(this,t,e)}):o?u(o,t,ft.data(o,t)):undefined},removeData:function(t){return this.each(function(){ft.removeData(this,t)})}}),ft.extend({queue:function(t,e,n){var i;if(t)return e=(e||"fx")+"queue",i=ft._data(t,e),n&&(!i||ft.isArray(n)?i=ft._data(t,e,ft.makeArray(n)):i.push(n)),i||[]},dequeue:function(t,e){e=e||"fx";var n=ft.queue(t,e),i=n.length,r=n.shift(),o=ft._queueHooks(t,e),s=function(){ft.dequeue(t,e)};"inprogress"===r&&(r=n.shift(),i--),r&&("fx"===e&&n.unshift("inprogress"),delete o.stop,r.call(t,s,o)),!i&&o&&o.empty.fire()},_queueHooks:function(t,e){var n=e+"queueHooks";return ft._data(t,n)||ft._data(t,n,{empty:ft.Callbacks("once memory").add(function(){ft._removeData(t,e+"queue"),ft._removeData(t,n)})})}}),ft.fn.extend({queue:function(t,e){var n=2;return"string"!=typeof t&&(e=t,t="fx",n--),arguments.length
a",ht.leadingWhitespace=3===t.firstChild.nodeType,ht.tbody=!t.getElementsByTagName("tbody").length,ht.htmlSerialize=!!t.getElementsByTagName("link").length,ht.html5Clone="<:nav>"!==it.createElement("nav").cloneNode(!0).outerHTML,n.type="checkbox",n.checked=!0,e.appendChild(n),ht.appendChecked=n.checked,t.innerHTML="",ht.noCloneChecked=!!t.cloneNode(!0).lastChild.defaultValue,e.appendChild(t),n=it.createElement("input"),n.setAttribute("type","radio"),n.setAttribute("checked","checked"),n.setAttribute("name","t"),t.appendChild(n),ht.checkClone=t.cloneNode(!0).cloneNode(!0).lastChild.checked,ht.noCloneEvent=!!t.addEventListener,t[ft.expando]=1,ht.attributes=!t.getAttribute(ft.expando)}();var Wt={option:[1,""],legend:[1,"
","
"],area:[1,"",""],param:[1,"",""],thead:[1,"","
"],tr:[2,"","
"],col:[2,"","
"],td:[3,"","
"],_default:ht.htmlSerialize?[0,"",""]:[1,"X
","
"]};Wt.optgroup=Wt.option,Wt.tbody=Wt.tfoot=Wt.colgroup=Wt.caption=Wt.thead,Wt.th=Wt.td;var Ut=/<|&#?\w+;/,Vt=/-1&&(d=f.split("."),f=d.shift(),d.sort()),s=f.indexOf(":")<0&&"on"+f,e=e[ft.expando]?e:new ft.Event(f,"object"==typeof e&&e),e.isTrigger=r?2:3,e.namespace=d.join("."),e.rnamespace=e.namespace?new RegExp("(^|\\.)"+d.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,e.result=undefined,e.target||(e.target=i),n=null==n?[e]:ft.makeArray(n,[e]),l=ft.event.special[f]||{},r||!l.trigger||!1!==l.trigger.apply(i,n))){if(!r&&!l.noBubble&&!ft.isWindow(i)){for(u=l.delegateType||f,Kt.test(u+f)||(a=a.parentNode);a;a=a.parentNode)p.push(a),c=a;c===(i.ownerDocument||it)&&p.push(c.defaultView||c.parentWindow||t)}for(h=0;(a=p[h++])&&!e.isPropagationStopped();)e.type=h>1?u:l.bindType||f,o=(ft._data(a,"events")||{})[e.type]&&ft._data(a,"handle"),o&&o.apply(a,n),(o=s&&a[s])&&o.apply&&Ot(a)&&(e.result=o.apply(a,n),!1===e.result&&e.preventDefault());if(e.type=f,!r&&!e.isDefaultPrevented()&&(!l._default||!1===l._default.apply(p.pop(),n))&&Ot(i)&&s&&i[f]&&!ft.isWindow(i)){c=i[s],c&&(i[s]=null),ft.event.triggered=f;try{i[f]()}catch(t){}ft.event.triggered=undefined,c&&(i[s]=c)}return e.result}},dispatch:function(t){t=ft.event.fix(t);var e,n,i,r,o,s=[],a=rt.call(arguments),u=(ft._data(this,"events")||{})[t.type]||[],l=ft.event.special[t.type]||{};if(a[0]=t,t.delegateTarget=this,!l.preDispatch||!1!==l.preDispatch.call(this,t)){for(s=ft.event.handlers.call(this,t,u),e=0;(r=s[e++])&&!t.isPropagationStopped();)for(t.currentTarget=r.elem,n=0;(o=r.handlers[n++])&&!t.isImmediatePropagationStopped();)t.rnamespace&&!t.rnamespace.test(o.namespace)||(t.handleObj=o,t.data=o.data,(i=((ft.event.special[o.origType]||{}).handle||o.handler).apply(r.elem,a))!==undefined&&!1===(t.result=i)&&(t.preventDefault(),t.stopPropagation()));return l.postDispatch&&l.postDispatch.call(this,t),t.result}},handlers:function(t,e){var n,i,r,o,s=[],a=e.delegateCount,u=t.target;if(a&&u.nodeType&&("click"!==t.type||isNaN(t.button)||t.button<1))for(;u!=this;u=u.parentNode||this)if(1===u.nodeType&&(!0!==u.disabled||"click"!==t.type)){for(i=[],n=0;n-1:ft.find(r,this,null,[u]).length),i[r]&&i.push(o);i.length&&s.push({elem:u,handlers:i})}return a]","i"),te=/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([\w:-]+)[^>]*)\/>/gi,ee=/\s*$/g,oe=f(it),se=oe.appendChild(it.createElement("div"));ft.extend({htmlPrefilter:function(t){return t.replace(te,"<$1>")},clone:function(t,e,n){var i,r,o,s,a,u=ft.contains(t.ownerDocument,t);if(ht.html5Clone||ft.isXMLDoc(t)||!Zt.test("<"+t.nodeName+">")?o=t.cloneNode(!0):(se.innerHTML=t.outerHTML,se.removeChild(o=se.firstChild)),!(ht.noCloneEvent&&ht.noCloneChecked||1!==t.nodeType&&11!==t.nodeType||ft.isXMLDoc(t)))for(i=d(o),a=d(t),s=0;null!=(r=a[s]);++s)i[s]&&T(r,i[s]);if(e)if(n)for(a=a||d(t),i=i||d(o),s=0;null!=(r=a[s]);s++)E(r,i[s]);else E(t,o);return i=d(o,"script"),i.length>0&&m(i,!u&&d(t,"script")),i=a=r=null,o},cleanData:function(t,e){for(var n,i,r,o,s=0,a=ft.expando,u=ft.cache,l=ht.attributes,c=ft.event.special;null!=(n=t[s]);s++)if((e||Ot(n))&&(r=n[a],o=r&&u[r])){if(o.events)for(i in o.events)c[i]?ft.event.remove(n,i):ft.removeEvent(n,i,o.handle);u[r]&&(delete u[r],l||"undefined"==typeof n.removeAttribute?n[a]=undefined:n.removeAttribute(a),nt.push(r))}}}),ft.fn.extend({domManip:_,detach:function(t){return P(this,t,!0)},remove:function(t){return P(this,t)},text:function(t){return Ht(this,function(t){return t===undefined?ft.text(this):this.empty().append((this[0]&&this[0].ownerDocument||it).createTextNode(t))},null,t,arguments.length)},append:function(){return _(this,arguments,function(t){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){S(this,t).appendChild(t)}})},prepend:function(){return _(this,arguments,function(t){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var e=S(this,t);e.insertBefore(t,e.firstChild)}})},before:function(){return _(this,arguments,function(t){this.parentNode&&this.parentNode.insertBefore(t,this)})},after:function(){return _(this,arguments,function(t){this.parentNode&&this.parentNode.insertBefore(t,this.nextSibling)})},empty:function(){for(var t,e=0;null!=(t=this[e]);e++){for(1===t.nodeType&&ft.cleanData(d(t,!1));t.firstChild;)t.removeChild(t.firstChild);t.options&&ft.nodeName(t,"select")&&(t.options.length=0)}return this},clone:function(t,e){return t=null!=t&&t,e=null==e?t:e,this.map(function(){return ft.clone(this,t,e)})},html:function(t){return Ht(this,function(t){var e=this[0]||{},n=0,i=this.length;if(t===undefined)return 1===e.nodeType?e.innerHTML.replace(Qt,""):undefined;if("string"==typeof t&&!ee.test(t)&&(ht.htmlSerialize||!Zt.test(t))&&(ht.leadingWhitespace||!Ft.test(t))&&!Wt[(zt.exec(t)||["",""])[1].toLowerCase()]){t=ft.htmlPrefilter(t);try{for(;nt",e=l.getElementsByTagName("td"),e[0].style.cssText="margin:0;border:0;padding:0;display:none",(o=0===e[0].offsetHeight)&&(e[0].style.display="",e[1].style.display="none",o=0===e[0].offsetHeight)),h.removeChild(u)}var n,i,r,o,s,a,u=it.createElement("div"),l=it.createElement("div");l.style&&(l.style.cssText="float:left;opacity:.5",ht.opacity="0.5"===l.style.opacity,ht.cssFloat=!!l.style.cssFloat,l.style.backgroundClip="content-box",l.cloneNode(!0).style.backgroundClip="",ht.clearCloneStyle="content-box"===l.style.backgroundClip,u=it.createElement("div"),u.style.cssText="border:0;width:8px;height:0;top:0;left:-9999px;padding:0;margin-top:1px;position:absolute",l.innerHTML="",u.appendChild(l),ht.boxSizing=""===l.style.boxSizing||""===l.style.MozBoxSizing||""===l.style.WebkitBoxSizing,ft.extend(ht,{reliableHiddenOffsets:function(){return null==n&&e(),o},boxSizingReliable:function(){return null==n&&e(),r},pixelMarginRight:function(){return null==n&&e(),i},pixelPosition:function(){return null==n&&e(),n},reliableMarginRight:function(){return null==n&&e(),s},reliableMarginLeft:function(){return null==n&&e(),a}}))}();var fe,de,me=/^(top|right|bottom|left)$/;t.getComputedStyle?(fe=function(e){var n=e.ownerDocument.defaultView;return n&&n.opener||(n=t),n.getComputedStyle(e)},de=function(t,e,n){var i,r,o,s,a=t.style;return n=n||fe(t),s=n?n.getPropertyValue(e)||n[e]:undefined,""!==s&&s!==undefined||ft.contains(t.ownerDocument,t)||(s=ft.style(t,e)),n&&!ht.pixelMarginRight()&&ce.test(s)&&le.test(e)&&(i=a.width,r=a.minWidth,o=a.maxWidth,a.minWidth=a.maxWidth=a.width=s,s=n.width,a.width=i,a.minWidth=r,a.maxWidth=o),s===undefined?s:s+""}):pe.currentStyle&&(fe=function(t){return t.currentStyle},de=function(t,e,n){var i,r,o,s,a=t.style;return n=n||fe(t),s=n?n[e]:undefined,null==s&&a&&a[e]&&(s=a[e]),ce.test(s)&&!me.test(e)&&(i=a.left,r=t.runtimeStyle,o=r&&r.left,o&&(r.left=t.currentStyle.left),a.left="fontSize"===e?"1em":s,s=a.pixelLeft+"px",a.left=i,o&&(r.left=o)),s===undefined?s:s+""||"auto"});var ge=/alpha\([^)]*\)/i,ve=/opacity\s*=\s*([^)]*)/i,ye=/^(none|table(?!-c[ea]).+)/,be=new RegExp("^("+Dt+")(.*)$","i"),we={position:"absolute",visibility:"hidden",display:"block"},xe={letterSpacing:"0",fontWeight:"400"},Se=["Webkit","O","Moz","ms"],ke=it.createElement("div").style;ft.extend({cssHooks:{opacity:{get:function(t,e){if(e){var n=de(t,"opacity");return""===n?"1":n}}}},cssNumber:{animationIterationCount:!0,columnCount:!0,fillOpacity:!0,flexGrow:!0,flexShrink:!0,fontWeight:!0,lineHeight:!0,opacity:!0,order:!0,orphans:!0,widows:!0,zIndex:!0,zoom:!0},cssProps:{"float":ht.cssFloat?"cssFloat":"styleFloat"},style:function(t,e,n,i){if(t&&3!==t.nodeType&&8!==t.nodeType&&t.style){var r,o,s,a=ft.camelCase(e),u=t.style;if(e=ft.cssProps[a]||(ft.cssProps[a]=I(a)||a),s=ft.cssHooks[e]||ft.cssHooks[a],n===undefined)return s&&"get"in s&&(r=s.get(t,!1,i))!==undefined?r:u[e];if(o=typeof n,"string"===o&&(r=$t.exec(n))&&r[1]&&(n=p(t,e,r),o="number"),null!=n&&n===n&&("number"===o&&(n+=r&&r[3]||(ft.cssNumber[a]?"":"px")),ht.clearCloneStyle||""!==n||0!==e.indexOf("background")||(u[e]="inherit"),!(s&&"set"in s&&(n=s.set(t,n,i))===undefined)))try{u[e]=n}catch(t){}}},css:function(t,e,n,i){var r,o,s,a=ft.camelCase(e);return e=ft.cssProps[a]||(ft.cssProps[a]=I(a)||a),s=ft.cssHooks[e]||ft.cssHooks[a],s&&"get"in s&&(o=s.get(t,!0,n)),o===undefined&&(o=de(t,e,i)),"normal"===o&&e in xe&&(o=xe[e]),""===n||n?(r=parseFloat(o),!0===n||isFinite(r)?r||0:o):o}}),ft.each(["height","width"],function(t,e){ft.cssHooks[e]={get:function(t,n,i){if(n)return ye.test(ft.css(t,"display"))&&0===t.offsetWidth?he(t,we,function(){return j(t,e,i)}):j(t,e,i)},set:function(t,n,i){var r=i&&fe(t);return D(t,n,i?$(t,e,i,ht.boxSizing&&"border-box"===ft.css(t,"boxSizing",!1,r),r):0)}}}),ht.opacity||(ft.cssHooks.opacity={get:function(t,e){return ve.test((e&&t.currentStyle?t.currentStyle.filter:t.style.filter)||"")?.01*parseFloat(RegExp.$1)+"":e?"1":""},set:function(t,e){var n=t.style,i=t.currentStyle,r=ft.isNumeric(e)?"alpha(opacity="+100*e+")":"",o=i&&i.filter||n.filter||"";n.zoom=1,(e>=1||""===e)&&""===ft.trim(o.replace(ge,""))&&n.removeAttribute&&(n.removeAttribute("filter"),""===e||i&&!i.filter)||(n.filter=ge.test(o)?o.replace(ge,r):o+" "+r)}}),ft.cssHooks.marginRight=O(ht.reliableMarginRight,function(t,e){if(e)return he(t,{display:"inline-block"},de,[t,"marginRight"])}),ft.cssHooks.marginLeft=O(ht.reliableMarginLeft,function(t,e){if(e)return(parseFloat(de(t,"marginLeft"))||(ft.contains(t.ownerDocument,t)?t.getBoundingClientRect().left-he(t,{marginLeft:0},function(){return t.getBoundingClientRect().left}):0))+"px"}),ft.each({margin:"",padding:"",border:"Width"},function(t,e){ft.cssHooks[t+e]={expand:function(n){for(var i=0,r={},o="string"==typeof n?n.split(" "):[n];i<4;i++)r[t+jt[i]+e]=o[i]||o[i-2]||o[0];return r}},le.test(t)||(ft.cssHooks[t+e].set=D)}),ft.fn.extend({css:function(t,e){return Ht(this,function(t,e,n){var i,r,o={},s=0;if(ft.isArray(e)){for(i=fe(t),r=e.length;s1)},show:function(){return L(this,!0)},hide:function(){return L(this)},toggle:function(t){return"boolean"==typeof t?t?this.show():this.hide():this.each(function(){Rt(this)?ft(this).show():ft(this).hide()})}}),ft.Tween=R,R.prototype={constructor:R,init:function(t,e,n,i,r,o){this.elem=t,this.prop=n,this.easing=r||ft.easing._default,this.options=e,this.start=this.now=this.cur(),this.end=i,this.unit=o||(ft.cssNumber[n]?"":"px")},cur:function(){var t=R.propHooks[this.prop];return t&&t.get?t.get(this):R.propHooks._default.get(this)},run:function(t){var e,n=R.propHooks[this.prop];return this.options.duration?this.pos=e=ft.easing[this.easing](t,this.options.duration*t,0,1,this.options.duration):this.pos=e=t,this.now=(this.end-this.start)*e+this.start,this.options.step&&this.options.step.call(this.elem,this.now,this),n&&n.set?n.set(this):R.propHooks._default.set(this),this}},R.prototype.init.prototype=R.prototype,R.propHooks={_default:{get:function(t){var e;return 1!==t.elem.nodeType||null!=t.elem[t.prop]&&null==t.elem.style[t.prop]?t.elem[t.prop]:(e=ft.css(t.elem,t.prop,""),e&&"auto"!==e?e:0)},set:function(t){ft.fx.step[t.prop]?ft.fx.step[t.prop](t):1!==t.elem.nodeType||null==t.elem.style[ft.cssProps[t.prop]]&&!ft.cssHooks[t.prop]?t.elem[t.prop]=t.now:ft.style(t.elem,t.prop,t.now+t.unit)}}},R.propHooks.scrollTop=R.propHooks.scrollLeft={set:function(t){t.elem.nodeType&&t.elem.parentNode&&(t.elem[t.prop]=t.now)}},ft.easing={linear:function(t){return t},swing:function(t){return.5-Math.cos(t*Math.PI)/2},_default:"swing"},ft.fx=R.prototype.init,ft.fx.step={};var Ce,Ee,Te=/^(?:toggle|show|hide)$/,_e=/queueHooks$/;ft.Animation=ft.extend(q,{tweeners:{"*":[function(t,e){var n=this.createTween(t,e);return p(n.elem,t,$t.exec(e),n),n}]},tweener:function(t,e){ft.isFunction(t)?(e=t,t=["*"]):t=t.match(Pt);for(var n,i=0,r=t.length;i
a",t=n.getElementsByTagName("a")[0],e.setAttribute("type","checkbox"),n.appendChild(e),t=n.getElementsByTagName("a")[0],t.style.cssText="top:1px",ht.getSetAttribute="t"!==n.className,ht.style=/top/.test(t.getAttribute("style")),ht.hrefNormalized="/a"===t.getAttribute("href"),ht.checkOn=!!e.value,ht.optSelected=r.selected,ht.enctype=!!it.createElement("form").enctype,i.disabled=!0,ht.optDisabled=!r.disabled,e=it.createElement("input"),e.setAttribute("value",""),ht.input=""===e.getAttribute("value"),e.value="t",e.setAttribute("type","radio"),ht.radioValue="t"===e.value}();var Pe=/\r/g,Ne=/[\x20\t\r\n\f]+/g;ft.fn.extend({val:function(t){var e,n,i,r=this[0];{if(arguments.length)return i=ft.isFunction(t),this.each(function(n){var r;1===this.nodeType&&(r=i?t.call(this,n,ft(this).val()):t,null==r?r="":"number"==typeof r?r+="":ft.isArray(r)&&(r=ft.map(r,function(t){return null==t?"":t+""})),(e=ft.valHooks[this.type]||ft.valHooks[this.nodeName.toLowerCase()])&&"set"in e&&e.set(this,r,"value")!==undefined||(this.value=r))});if(r)return(e=ft.valHooks[r.type]||ft.valHooks[r.nodeName.toLowerCase()])&&"get"in e&&(n=e.get(r,"value"))!==undefined?n:(n=r.value,"string"==typeof n?n.replace(Pe,""):null==n?"":n)}}}),ft.extend({valHooks:{option:{get:function(t){var e=ft.find.attr(t,"value");return null!=e?e:ft.trim(ft.text(t)).replace(Ne," ")}},select:{get:function(t){for(var e,n,i=t.options,r=t.selectedIndex,o="select-one"===t.type||r<0,s=o?null:[],a=o?r+1:i.length,u=r<0?a:o?r:0;u-1)try{i.selected=n=!0}catch(t){i.scrollHeight}else i.selected=!1;return n||(t.selectedIndex=-1),r}}}}),ft.each(["radio","checkbox"],function(){ft.valHooks[this]={set:function(t,e){if(ft.isArray(e))return t.checked=ft.inArray(ft(t).val(),e)>-1}},ht.checkOn||(ft.valHooks[this].get=function(t){return null===t.getAttribute("value")?"on":t.value})});var Ae,Oe,Ie=ft.expr.attrHandle,Le=/^(?:checked|selected)$/i,De=ht.getSetAttribute,$e=ht.input;ft.fn.extend({attr:function(t,e){return Ht(this,ft.attr,t,e,arguments.length>1)},removeAttr:function(t){return this.each(function(){ft.removeAttr(this,t)})}}),ft.extend({attr:function(t,e,n){var i,r,o=t.nodeType;if(3!==o&&8!==o&&2!==o)return"undefined"==typeof t.getAttribute?ft.prop(t,e,n):(1===o&&ft.isXMLDoc(t)||(e=e.toLowerCase(),r=ft.attrHooks[e]||(ft.expr.match.bool.test(e)?Oe:Ae)),n!==undefined?null===n?void ft.removeAttr(t,e):r&&"set"in r&&(i=r.set(t,n,e))!==undefined?i:(t.setAttribute(e,n+""),n):r&&"get"in r&&null!==(i=r.get(t,e))?i:(i=ft.find.attr(t,e),null==i?undefined:i))},attrHooks:{type:{set:function(t,e){if(!ht.radioValue&&"radio"===e&&ft.nodeName(t,"input")){var n=t.value;return t.setAttribute("type",e),n&&(t.value=n),e}}}},removeAttr:function(t,e){var n,i,r=0,o=e&&e.match(Pt);if(o&&1===t.nodeType)for(;n=o[r++];)i=ft.propFix[n]||n,ft.expr.match.bool.test(n)?$e&&De||!Le.test(n)?t[i]=!1:t[ft.camelCase("default-"+n)]=t[i]=!1:ft.attr(t,n,""),t.removeAttribute(De?n:i)}}),Oe={set:function(t,e,n){return!1===e?ft.removeAttr(t,n):$e&&De||!Le.test(n)?t.setAttribute(!De&&ft.propFix[n]||n,n):t[ft.camelCase("default-"+n)]=t[n]=!0,n}},ft.each(ft.expr.match.bool.source.match(/\w+/g),function(t,e){var n=Ie[e]||ft.find.attr;$e&&De||!Le.test(e)?Ie[e]=function(t,e,i){var r,o;return i||(o=Ie[e],Ie[e]=r,r=null!=n(t,e,i)?e.toLowerCase():null,Ie[e]=o),r}:Ie[e]=function(t,e,n){if(!n)return t[ft.camelCase("default-"+e)]?e.toLowerCase():null}}),$e&&De||(ft.attrHooks.value={set:function(t,e,n){if(!ft.nodeName(t,"input"))return Ae&&Ae.set(t,e,n);t.defaultValue=e}}),De||(Ae={set:function(t,e,n){var i=t.getAttributeNode(n);if(i||t.setAttributeNode(i=t.ownerDocument.createAttribute(n)),i.value=e+="","value"===n||e===t.getAttribute(n))return e}},Ie.id=Ie.name=Ie.coords=function(t,e,n){var i;if(!n)return(i=t.getAttributeNode(e))&&""!==i.value?i.value:null},ft.valHooks.button={get:function(t,e){var n=t.getAttributeNode(e);if(n&&n.specified)return n.value},set:Ae.set},ft.attrHooks.contenteditable={set:function(t,e,n){Ae.set(t,""!==e&&e,n)}},ft.each(["width","height"],function(t,e){ft.attrHooks[e]={set:function(t,n){if(""===n)return t.setAttribute(e,"auto"),n}}})),ht.style||(ft.attrHooks.style={get:function(t){return t.style.cssText||undefined},set:function(t,e){return t.style.cssText=e+""}});var je=/^(?:input|select|textarea|button|object)$/i,Re=/^(?:a|area)$/i;ft.fn.extend({prop:function(t,e){return Ht(this,ft.prop,t,e,arguments.length>1)},removeProp:function(t){return t=ft.propFix[t]||t,this.each(function(){try{this[t]=undefined,delete this[t]}catch(t){}})}}),ft.extend({prop:function(t,e,n){var i,r,o=t.nodeType;if(3!==o&&8!==o&&2!==o)return 1===o&&ft.isXMLDoc(t)||(e=ft.propFix[e]||e,r=ft.propHooks[e]),n!==undefined?r&&"set"in r&&(i=r.set(t,n,e))!==undefined?i:t[e]=n:r&&"get"in r&&null!==(i=r.get(t,e))?i:t[e]},propHooks:{tabIndex:{get:function(t){var e=ft.find.attr(t,"tabindex");return e?parseInt(e,10):je.test(t.nodeName)||Re.test(t.nodeName)&&t.href?0:-1}}},propFix:{"for":"htmlFor","class":"className"}}),ht.hrefNormalized||ft.each(["href","src"],function(t,e){ft.propHooks[e]={get:function(t){return t.getAttribute(e,4)}}}),ht.optSelected||(ft.propHooks.selected={get:function(t){var e=t.parentNode;return e&&(e.selectedIndex,e.parentNode&&e.parentNode.selectedIndex),null},set:function(t){var e=t.parentNode;e&&(e.selectedIndex,e.parentNode&&e.parentNode.selectedIndex)}}),ft.each(["tabIndex","readOnly","maxLength","cellSpacing","cellPadding","rowSpan","colSpan","useMap","frameBorder","contentEditable"],function(){ft.propFix[this.toLowerCase()]=this}),ht.enctype||(ft.propFix.enctype="encoding");var He=/[\t\r\n\f]/g;ft.fn.extend({addClass:function(t){var e,n,i,r,o,s,a,u=0;if(ft.isFunction(t))return this.each(function(e){ft(this).addClass(t.call(this,e,W(this)))});if("string"==typeof t&&t)for(e=t.match(Pt)||[];n=this[u++];)if(r=W(n),i=1===n.nodeType&&(" "+r+" ").replace(He," ")){for(s=0;o=e[s++];)i.indexOf(" "+o+" ")<0&&(i+=o+" ");a=ft.trim(i),r!==a&&ft.attr(n,"class",a)}return this},removeClass:function(t){var e,n,i,r,o,s,a,u=0;if(ft.isFunction(t))return this.each(function(e){ft(this).removeClass(t.call(this,e,W(this)))});if(!arguments.length)return this.attr("class","");if("string"==typeof t&&t)for(e=t.match(Pt)||[];n=this[u++];)if(r=W(n),i=1===n.nodeType&&(" "+r+" ").replace(He," ")){for(s=0;o=e[s++];)for(;i.indexOf(" "+o+" ")>-1;)i=i.replace(" "+o+" "," ");a=ft.trim(i),r!==a&&ft.attr(n,"class",a)}return this},toggleClass:function(t,e){var n=typeof t;return"boolean"==typeof e&&"string"===n?e?this.addClass(t):this.removeClass(t):ft.isFunction(t)?this.each(function(n){ft(this).toggleClass(t.call(this,n,W(this),e),e)}):this.each(function(){var e,i,r,o;if("string"===n)for(i=0,r=ft(this),o=t.match(Pt)||[];e=o[i++];)r.hasClass(e)?r.removeClass(e):r.addClass(e);else t!==undefined&&"boolean"!==n||(e=W(this),e&&ft._data(this,"__className__",e),ft.attr(this,"class",e||!1===t?"":ft._data(this,"__className__")||""))})},hasClass:function(t){var e,n,i=0;for(e=" "+t+" ";n=this[i++];)if(1===n.nodeType&&(" "+W(n)+" ").replace(He," ").indexOf(e)>-1)return!0;return!1}}),ft.each("blur focus focusin focusout load resize scroll unload click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup error contextmenu".split(" "),function(t,e){ft.fn[e]=function(t,n){return arguments.length>0?this.on(e,null,t,n):this.trigger(e)}}),ft.fn.extend({hover:function(t,e){return this.mouseenter(t).mouseleave(e||t)}});var Me=t.location,ze=ft.now(),Be=/\?/,Fe=/(,)|(\[|{)|(}|])|"(?:[^"\\\r\n]|\\["\\\/bfnrt]|\\u[\da-fA-F]{4})*"\s*:?|true|false|null|-?(?!0\d)\d+(?:\.\d+|)(?:[eE][+-]?\d+|)/g;ft.parseJSON=function(e){if(t.JSON&&t.JSON.parse)return t.JSON.parse(e+"");var n,i=null,r=ft.trim(e+"");return r&&!ft.trim(r.replace(Fe,function(t,e,r,o){return n&&e&&(i=0),0===i?t:(n=r||e,i+=!o-!r,"")}))?Function("return "+r)():ft.error("Invalid JSON: "+e)},ft.parseXML=function(e){var n,i;if(!e||"string"!=typeof e)return null;try{t.DOMParser?(i=new t.DOMParser,n=i.parseFromString(e,"text/xml")):(n=new t.ActiveXObject("Microsoft.XMLDOM"),n.async="false",n.loadXML(e))}catch(t){n=undefined} +return n&&n.documentElement&&!n.getElementsByTagName("parsererror").length||ft.error("Invalid XML: "+e),n};var qe=/#.*$/,We=/([?&])_=[^&]*/,Ue=/^(.*?):[ \t]*([^\r\n]*)\r?$/gm,Ve=/^(?:about|app|app-storage|.+-extension|file|res|widget):$/,Ge=/^(?:GET|HEAD)$/,Xe=/^\/\//,Ye=/^([\w.+-]+:)(?:\/\/(?:[^\/?#]*@|)([^\/?#:]*)(?::(\d+)|)|)/,Ke={},Je={},Qe="*/".concat("*"),Ze=Me.href,tn=Ye.exec(Ze.toLowerCase())||[];ft.extend({active:0,lastModified:{},etag:{},ajaxSettings:{url:Ze,type:"GET",isLocal:Ve.test(tn[1]),global:!0,processData:!0,async:!0,contentType:"application/x-www-form-urlencoded; charset=UTF-8",accepts:{"*":Qe,text:"text/plain",html:"text/html",xml:"application/xml, text/xml",json:"application/json, text/javascript"},contents:{xml:/\bxml\b/,html:/\bhtml/,json:/\bjson\b/},responseFields:{xml:"responseXML",text:"responseText",json:"responseJSON"},converters:{"* text":String,"text html":!0,"text json":ft.parseJSON,"text xml":ft.parseXML},flatOptions:{url:!0,context:!0}},ajaxSetup:function(t,e){return e?G(G(t,ft.ajaxSettings),e):G(ft.ajaxSettings,t)},ajaxPrefilter:U(Ke),ajaxTransport:U(Je),ajax:function(e,n){function i(e,n,i,r){var o,h,y,b,x,k=n;2!==w&&(w=2,u&&t.clearTimeout(u),c=undefined,a=r||"",S.readyState=e>0?4:0,o=e>=200&&e<300||304===e,i&&(b=X(p,S,i)),b=Y(p,b,S,o),o?(p.ifModified&&(x=S.getResponseHeader("Last-Modified"),x&&(ft.lastModified[s]=x),(x=S.getResponseHeader("etag"))&&(ft.etag[s]=x)),204===e||"HEAD"===p.type?k="nocontent":304===e?k="notmodified":(k=b.state,h=b.data,y=b.error,o=!y)):(y=k,!e&&k||(k="error",e<0&&(e=0))),S.status=e,S.statusText=(n||k)+"",o?m.resolveWith(f,[h,k,S]):m.rejectWith(f,[S,k,y]),S.statusCode(v),v=undefined,l&&d.trigger(o?"ajaxSuccess":"ajaxError",[S,p,o?h:y]),g.fireWith(f,[S,k]),l&&(d.trigger("ajaxComplete",[S,p]),--ft.active||ft.event.trigger("ajaxStop")))}"object"==typeof e&&(n=e,e=undefined),n=n||{};var r,o,s,a,u,l,c,h,p=ft.ajaxSetup({},n),f=p.context||p,d=p.context&&(f.nodeType||f.jquery)?ft(f):ft.event,m=ft.Deferred(),g=ft.Callbacks("once memory"),v=p.statusCode||{},y={},b={},w=0,x="canceled",S={readyState:0,getResponseHeader:function(t){var e;if(2===w){if(!h)for(h={};e=Ue.exec(a);)h[e[1].toLowerCase()]=e[2];e=h[t.toLowerCase()]}return null==e?null:e},getAllResponseHeaders:function(){return 2===w?a:null},setRequestHeader:function(t,e){var n=t.toLowerCase();return w||(t=b[n]=b[n]||t,y[t]=e),this},overrideMimeType:function(t){return w||(p.mimeType=t),this},statusCode:function(t){var e;if(t)if(w<2)for(e in t)v[e]=[v[e],t[e]];else S.always(t[S.status]);return this},abort:function(t){var e=t||x;return c&&c.abort(e),i(0,e),this}};if(m.promise(S).complete=g.add,S.success=S.done,S.error=S.fail,p.url=((e||p.url||Ze)+"").replace(qe,"").replace(Xe,tn[1]+"//"),p.type=n.method||n.type||p.method||p.type,p.dataTypes=ft.trim(p.dataType||"*").toLowerCase().match(Pt)||[""],null==p.crossDomain&&(r=Ye.exec(p.url.toLowerCase()),p.crossDomain=!(!r||r[1]===tn[1]&&r[2]===tn[2]&&(r[3]||("http:"===r[1]?"80":"443"))===(tn[3]||("http:"===tn[1]?"80":"443")))),p.data&&p.processData&&"string"!=typeof p.data&&(p.data=ft.param(p.data,p.traditional)),V(Ke,p,n,S),2===w)return S;l=ft.event&&p.global,l&&0==ft.active++&&ft.event.trigger("ajaxStart"),p.type=p.type.toUpperCase(),p.hasContent=!Ge.test(p.type),s=p.url,p.hasContent||(p.data&&(s=p.url+=(Be.test(s)?"&":"?")+p.data,delete p.data),!1===p.cache&&(p.url=We.test(s)?s.replace(We,"$1_="+ze++):s+(Be.test(s)?"&":"?")+"_="+ze++)),p.ifModified&&(ft.lastModified[s]&&S.setRequestHeader("If-Modified-Since",ft.lastModified[s]),ft.etag[s]&&S.setRequestHeader("If-None-Match",ft.etag[s])),(p.data&&p.hasContent&&!1!==p.contentType||n.contentType)&&S.setRequestHeader("Content-Type",p.contentType),S.setRequestHeader("Accept",p.dataTypes[0]&&p.accepts[p.dataTypes[0]]?p.accepts[p.dataTypes[0]]+("*"!==p.dataTypes[0]?", "+Qe+"; q=0.01":""):p.accepts["*"]);for(o in p.headers)S.setRequestHeader(o,p.headers[o]);if(p.beforeSend&&(!1===p.beforeSend.call(f,S,p)||2===w))return S.abort();x="abort";for(o in{success:1,error:1,complete:1})S[o](p[o]);if(c=V(Je,p,n,S)){if(S.readyState=1,l&&d.trigger("ajaxSend",[S,p]),2===w)return S;p.async&&p.timeout>0&&(u=t.setTimeout(function(){S.abort("timeout")},p.timeout));try{w=1,c.send(y,i)}catch(t){if(!(w<2))throw t;i(-1,t)}}else i(-1,"No Transport");return S},getJSON:function(t,e,n){return ft.get(t,e,n,"json")},getScript:function(t,e){return ft.get(t,undefined,e,"script")}}),ft.each(["get","post"],function(t,e){ft[e]=function(t,n,i,r){return ft.isFunction(n)&&(r=r||i,i=n,n=undefined),ft.ajax(ft.extend({url:t,type:e,dataType:r,data:n,success:i},ft.isPlainObject(t)&&t))}}),ft._evalUrl=function(t){return ft.ajax({url:t,type:"GET",dataType:"script",cache:!0,async:!1,global:!1,"throws":!0})},ft.fn.extend({wrapAll:function(t){if(ft.isFunction(t))return this.each(function(e){ft(this).wrapAll(t.call(this,e))});if(this[0]){var e=ft(t,this[0].ownerDocument).eq(0).clone(!0);this[0].parentNode&&e.insertBefore(this[0]),e.map(function(){for(var t=this;t.firstChild&&1===t.firstChild.nodeType;)t=t.firstChild;return t}).append(this)}return this},wrapInner:function(t){return ft.isFunction(t)?this.each(function(e){ft(this).wrapInner(t.call(this,e))}):this.each(function(){var e=ft(this),n=e.contents();n.length?n.wrapAll(t):e.append(t)})},wrap:function(t){var e=ft.isFunction(t);return this.each(function(n){ft(this).wrapAll(e?t.call(this,n):t)})},unwrap:function(){return this.parent().each(function(){ft.nodeName(this,"body")||ft(this).replaceWith(this.childNodes)}).end()}}),ft.expr.filters.hidden=function(t){return ht.reliableHiddenOffsets()?t.offsetWidth<=0&&t.offsetHeight<=0&&!t.getClientRects().length:J(t)},ft.expr.filters.visible=function(t){return!ft.expr.filters.hidden(t)};var en=/%20/g,nn=/\[\]$/,rn=/\r?\n/g,on=/^(?:submit|button|image|reset|file)$/i,sn=/^(?:input|select|textarea|keygen)/i;ft.param=function(t,e){var n,i=[],r=function(t,e){e=ft.isFunction(e)?e():null==e?"":e,i[i.length]=encodeURIComponent(t)+"="+encodeURIComponent(e)};if(e===undefined&&(e=ft.ajaxSettings&&ft.ajaxSettings.traditional),ft.isArray(t)||t.jquery&&!ft.isPlainObject(t))ft.each(t,function(){r(this.name,this.value)});else for(n in t)Q(n,t[n],e,r);return i.join("&").replace(en,"+")},ft.fn.extend({serialize:function(){return ft.param(this.serializeArray())},serializeArray:function(){return this.map(function(){var t=ft.prop(this,"elements");return t?ft.makeArray(t):this}).filter(function(){var t=this.type;return this.name&&!ft(this).is(":disabled")&&sn.test(this.nodeName)&&!on.test(t)&&(this.checked||!Mt.test(t))}).map(function(t,e){var n=ft(this).val();return null==n?null:ft.isArray(n)?ft.map(n,function(t){return{name:e.name,value:t.replace(rn,"\r\n")}}):{name:e.name,value:n.replace(rn,"\r\n")}}).get()}}),ft.ajaxSettings.xhr=t.ActiveXObject!==undefined?function(){return this.isLocal?tt():it.documentMode>8?Z():/^(get|post|head|put|delete|options)$/i.test(this.type)&&Z()||tt()}:Z;var an=0,un={},ln=ft.ajaxSettings.xhr();t.attachEvent&&t.attachEvent("onunload",function(){for(var t in un)un[t](undefined,!0)}),ht.cors=!!ln&&"withCredentials"in ln,ln=ht.ajax=!!ln,ln&&ft.ajaxTransport(function(e){if(!e.crossDomain||ht.cors){var n;return{send:function(i,r){var o,s=e.xhr(),a=++an;if(s.open(e.type,e.url,e.async,e.username,e.password),e.xhrFields)for(o in e.xhrFields)s[o]=e.xhrFields[o];e.mimeType&&s.overrideMimeType&&s.overrideMimeType(e.mimeType),e.crossDomain||i["X-Requested-With"]||(i["X-Requested-With"]="XMLHttpRequest");for(o in i)i[o]!==undefined&&s.setRequestHeader(o,i[o]+"");s.send(e.hasContent&&e.data||null),n=function(t,i){var o,u,l;if(n&&(i||4===s.readyState))if(delete un[a],n=undefined,s.onreadystatechange=ft.noop,i)4!==s.readyState&&s.abort();else{l={},o=s.status,"string"==typeof s.responseText&&(l.text=s.responseText);try{u=s.statusText}catch(t){u=""}o||!e.isLocal||e.crossDomain?1223===o&&(o=204):o=l.text?200:404}l&&r(o,u,l,s.getAllResponseHeaders())},e.async?4===s.readyState?t.setTimeout(n):s.onreadystatechange=un[a]=n:n()},abort:function(){n&&n(undefined,!0)}}}}),ft.ajaxSetup({accepts:{script:"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"},contents:{script:/\b(?:java|ecma)script\b/},converters:{"text script":function(t){return ft.globalEval(t),t}}}),ft.ajaxPrefilter("script",function(t){t.cache===undefined&&(t.cache=!1),t.crossDomain&&(t.type="GET",t.global=!1)}),ft.ajaxTransport("script",function(t){if(t.crossDomain){var e,n=it.head||ft("head")[0]||it.documentElement;return{send:function(i,r){e=it.createElement("script"),e.async=!0,t.scriptCharset&&(e.charset=t.scriptCharset),e.src=t.url,e.onload=e.onreadystatechange=function(t,n){(n||!e.readyState||/loaded|complete/.test(e.readyState))&&(e.onload=e.onreadystatechange=null,e.parentNode&&e.parentNode.removeChild(e),e=null,n||r(200,"success"))},n.insertBefore(e,n.firstChild)},abort:function(){e&&e.onload(undefined,!0)}}}});var cn=[],hn=/(=)\?(?=&|$)|\?\?/;ft.ajaxSetup({jsonp:"callback",jsonpCallback:function(){var t=cn.pop()||ft.expando+"_"+ze++;return this[t]=!0,t}}),ft.ajaxPrefilter("json jsonp",function(e,n,i){var r,o,s,a=!1!==e.jsonp&&(hn.test(e.url)?"url":"string"==typeof e.data&&0===(e.contentType||"").indexOf("application/x-www-form-urlencoded")&&hn.test(e.data)&&"data");if(a||"jsonp"===e.dataTypes[0])return r=e.jsonpCallback=ft.isFunction(e.jsonpCallback)?e.jsonpCallback():e.jsonpCallback,a?e[a]=e[a].replace(hn,"$1"+r):!1!==e.jsonp&&(e.url+=(Be.test(e.url)?"&":"?")+e.jsonp+"="+r),e.converters["script json"]=function(){return s||ft.error(r+" was not called"),s[0]},e.dataTypes[0]="json",o=t[r],t[r]=function(){s=arguments},i.always(function(){o===undefined?ft(t).removeProp(r):t[r]=o,e[r]&&(e.jsonpCallback=n.jsonpCallback,cn.push(r)),s&&ft.isFunction(o)&&o(s[0]),s=o=undefined}),"script"}),ft.parseHTML=function(t,e,n){if(!t||"string"!=typeof t)return null;"boolean"==typeof e&&(n=e,e=!1),e=e||it;var i=St.exec(t),r=!n&&[];return i?[e.createElement(i[1])]:(i=v([t],e,r),r&&r.length&&ft(r).remove(),ft.merge([],i.childNodes))};var pn=ft.fn.load;ft.fn.load=function(t,e,n){if("string"!=typeof t&&pn)return pn.apply(this,arguments);var i,r,o,s=this,a=t.indexOf(" ");return a>-1&&(i=ft.trim(t.slice(a,t.length)),t=t.slice(0,a)),ft.isFunction(e)?(n=e,e=undefined):e&&"object"==typeof e&&(r="POST"),s.length>0&&ft.ajax({url:t,type:r||"GET",dataType:"html",data:e}).done(function(t){o=arguments,s.html(i?ft("
").append(ft.parseHTML(t)).find(i):t)}).always(n&&function(t,e){s.each(function(){n.apply(this,o||[t.responseText,e,t])})}),this},ft.each(["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"],function(t,e){ft.fn[e]=function(t){return this.on(e,t)}}),ft.expr.filters.animated=function(t){return ft.grep(ft.timers,function(e){return t===e.elem}).length},ft.offset={setOffset:function(t,e,n){var i,r,o,s,a,u,l,c=ft.css(t,"position"),h=ft(t),p={};"static"===c&&(t.style.position="relative"),a=h.offset(),o=ft.css(t,"top"),u=ft.css(t,"left"),l=("absolute"===c||"fixed"===c)&&ft.inArray("auto",[o,u])>-1,l?(i=h.position(),s=i.top,r=i.left):(s=parseFloat(o)||0,r=parseFloat(u)||0),ft.isFunction(e)&&(e=e.call(t,n,ft.extend({},a))),null!=e.top&&(p.top=e.top-a.top+s),null!=e.left&&(p.left=e.left-a.left+r),"using"in e?e.using.call(t,p):h.css(p)}},ft.fn.extend({offset:function(t){if(arguments.length)return t===undefined?this:this.each(function(e){ft.offset.setOffset(this,t,e)});var e,n,i={top:0,left:0},r=this[0],o=r&&r.ownerDocument;if(o)return e=o.documentElement,ft.contains(e,r)?("undefined"!=typeof r.getBoundingClientRect&&(i=r.getBoundingClientRect()),n=et(o),{top:i.top+(n.pageYOffset||e.scrollTop)-(e.clientTop||0),left:i.left+(n.pageXOffset||e.scrollLeft)-(e.clientLeft||0)}):i},position:function(){if(this[0]){var t,e,n={top:0,left:0},i=this[0];return"fixed"===ft.css(i,"position")?e=i.getBoundingClientRect():(t=this.offsetParent(),e=this.offset(),ft.nodeName(t[0],"html")||(n=t.offset()),n.top+=ft.css(t[0],"borderTopWidth",!0),n.left+=ft.css(t[0],"borderLeftWidth",!0)),{top:e.top-n.top-ft.css(i,"marginTop",!0),left:e.left-n.left-ft.css(i,"marginLeft",!0)}}},offsetParent:function(){return this.map(function(){for(var t=this.offsetParent;t&&!ft.nodeName(t,"html")&&"static"===ft.css(t,"position");)t=t.offsetParent;return t||pe})}}),ft.each({scrollLeft:"pageXOffset",scrollTop:"pageYOffset"},function(t,e){var n=/Y/.test(e);ft.fn[t]=function(i){return Ht(this,function(t,i,r){var o=et(t);if(r===undefined)return o?e in o?o[e]:o.document.documentElement[i]:t[i];o?o.scrollTo(n?ft(o).scrollLeft():r,n?r:ft(o).scrollTop()):t[i]=r},t,i,arguments.length,null)}}),ft.each(["top","left"],function(t,e){ft.cssHooks[e]=O(ht.pixelPosition,function(t,n){if(n)return n=de(t,e),ce.test(n)?ft(t).position()[e]+"px":n})}),ft.each({Height:"height",Width:"width"},function(t,e){ft.each({padding:"inner"+t,content:e,"":"outer"+t},function(n,i){ft.fn[i]=function(i,r){var o=arguments.length&&(n||"boolean"!=typeof i),s=n||(!0===i||!0===r?"margin":"border");return Ht(this,function(e,n,i){var r;return ft.isWindow(e)?e.document.documentElement["client"+t]:9===e.nodeType?(r=e.documentElement,Math.max(e.body["scroll"+t],r["scroll"+t],e.body["offset"+t],r["offset"+t],r["client"+t])):i===undefined?ft.css(e,n,s):ft.style(e,n,i,s)},e,o?i:undefined,o,null)}})}),ft.fn.extend({bind:function(t,e,n){return this.on(t,null,e,n)},unbind:function(t,e){return this.off(t,null,e)},delegate:function(t,e,n,i){return this.on(e,t,n,i)},undelegate:function(t,e,n){return 1===arguments.length?this.off(t,"**"):this.off(e,t||"**",n)}}),ft.fn.size=function(){return this.length},ft.fn.andSelf=ft.fn.addBack,"function"==typeof define&&define.amd&&define("jquery",[],function(){return ft});var fn=t.jQuery,dn=t.$;return ft.noConflict=function(e){return t.$===ft&&(t.$=dn),e&&t.jQuery===ft&&(t.jQuery=fn),ft},e||(t.jQuery=t.$=ft),ft}),function(t,e,n){var i=window.matchMedia;"undefined"!=typeof module&&module.exports?module.exports=n(i):"function"==typeof define&&define.amd?define(function(){return e[t]=n(i)}):e[t]=n(i)}("enquire",this,function(t){"use strict";function e(t,e){var n=0,i=t.length;for(n;n