CitconWiki - User contributions [en]

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T18:08:05Z

Paul.duvall: /* Motivations (Similar to Non-Cloud CD) */

''' ''Effectively'' using the cloud for Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the whole software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes. The [http://martinfowler.com/bliki/BlueGreenDeployment.html Blue/Green Deployment] pattern is a way to keep environments always up and running while embracing the Ephemeral Environment pattern.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T16:54:50Z

Paul.duvall: /* Patterns */

''' ''Effectively'' using the cloud for Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes. The [http://martinfowler.com/bliki/BlueGreenDeployment.html Blue/Green Deployment] pattern is a way to keep environments always up and running while embracing the Ephemeral Environment pattern.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T16:51:47Z

Paul.duvall: /* Patterns */

''' ''Effectively'' using the cloud for Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes. [http://martinfowler.com/bliki/BlueGreenDeployment.html Blue/Green Deployment] pattern is a way to keep environments always up and running while embracing ephemeral environment pattern.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T00:30:32Z

Paul.duvall:

''' ''Effectively'' using the cloud for Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T00:14:25Z

Paul.duvall: /* Motivations (Similar to Non-Cloud CD) */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes
* Reduce Infrastructure Costs

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-26T00:13:44Z

Paul.duvall: /* Principles */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth

== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T23:54:26Z

Paul.duvall: /* Patterns */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments (for example, Dev->QA->Staging->Production with fixed IP Addresses, endpoints, etc.) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T23:52:17Z

Paul.duvall: /* Antipatterns */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and are often only modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. This is an antipattern because environments are often in an unknown state and it presents bottlenecks for change. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else (see the pattern above).

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T23:45:20Z

Paul.duvall: /* Patterns */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) exist for the duration of a source code revision; then they get terminated and a new environment is added based on recent code changes.
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:29:44Z

Paul.duvall: /* Motivations (Similar to Non-Cloud CD) */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Always be working off/in a known state - version-control should always represent the canonical source of the while software system
* Get features to users quicker
* Reduce repetitive error-prone manual processes

== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:25:28Z

Paul.duvall: /* Patterns */

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* '''Dynamic Configuration''': Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:24:04Z

Paul.duvall:

''' ''Effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset - one that embraces ''abundance'' over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:22:04Z

Paul.duvall: /* Patterns */

'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* '''Short-Lived Dev/Test Environments''' Responsible team members only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:20:51Z

Paul.duvall: /* Antipatterns */

'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* Responsible team members will only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve" time. repetition, "cost"
* '''Stale Environments''' Similar to Fixed Environments, but when developers and other team members keep their environments around for more than a few days.
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:18:36Z

Paul.duvall: /* Antipatterns */

'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* Responsible team members will only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way to "conserve time. repetition, "cost"
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:17:19Z

Paul.duvall: /* Patterns */

'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance->Production) may exist but only per source code revision
* '''Software Systems as Code''': All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* Responsible team members will only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage

== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

CITCONNA2013Sessions

2013-08-25T19:16:08Z

Paul.duvall: /* Table View */

CITCON NA 2013 Boston Sessions

Back to the [[Main Page]]

== 10:00 Topics ==

# [[Reproducible CI]]
# [[From 0 percent to greater than 0 percent Test Coverage]]
# [[To Branch or Not to Branch?]]
# [[Property Based Developer Testing]]
# [[Test Expressivity]]

== 11:15 Topics ==

# [[End to end Continuous Delivery tools]]
# [[Test Triage and Intermittent Test techniques]]
# ---
# ---
# [[Managing Test Data All The Way To Production]]

== Lunch Topics ==

# ---

== 2:00 Topics ==

# [[CI Feedback & Metrics]]
# ---
# [[Feature Toggling Strategies]]
# [[CI Challenges With Multiple Branches]]
# ---

== 3:15 Topics ==

# [[NextGen CI Toolkit Wishlist]]
# [[Dead Sea Effect]]
# ---
# ---
# [[Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity]]

== 4:30 Topics ==

# [[Performance testing, automating]]
# [[Continuous Full System Deployment]]
# ---
# ---
# ---

==Final session==
[[CNA2013: Ah-ha moments]]

== Table View ==

{| class="wikitable"
|-
! Room name
! 10:00
! 11:15
! 2:00
! 3:15
! 4:30
|-
| Horace Mann
| ---
| [[End to end Continuous Delivery tools]]
| ---
| ---
| ---
|-
| Deborah Sampson
| ---
| [[Test Triage and Intermittent Test techniques]]
| ---
| ---
| ---
|-
| Thomas Paul
| [[From 0 percent to greater than 0 percent Test Coverage]]
| ---
| [[CI Challenges With Multiple Branches]]
| ---
| ---
|-
| Abigail Adams
| [[Property Based Developer Testing]]
| ---
| ---
| ---
| ---
|-
| Crispus Attucks
| [[Test Expressivity]]
| [[Managing Test Data All The Way To Production]]
| ---
| [[Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity]]
| ---
|}

CITCONNA2013Sessions

2013-08-25T19:15:04Z

Paul.duvall: /* 3:15 Topics */

CITCON NA 2013 Boston Sessions

Back to the [[Main Page]]

== 10:00 Topics ==

# [[Reproducible CI]]
# [[From 0 percent to greater than 0 percent Test Coverage]]
# [[To Branch or Not to Branch?]]
# [[Property Based Developer Testing]]
# [[Test Expressivity]]

== 11:15 Topics ==

# [[End to end Continuous Delivery tools]]
# [[Test Triage and Intermittent Test techniques]]
# ---
# ---
# [[Managing Test Data All The Way To Production]]

== Lunch Topics ==

# ---

== 2:00 Topics ==

# [[CI Feedback & Metrics]]
# ---
# [[Feature Toggling Strategies]]
# [[CI Challenges With Multiple Branches]]
# ---

== 3:15 Topics ==

# [[NextGen CI Toolkit Wishlist]]
# [[Dead Sea Effect]]
# ---
# ---
# [[Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity]]

== 4:30 Topics ==

# [[Performance testing, automating]]
# [[Continuous Full System Deployment]]
# ---
# ---
# ---

==Final session==
[[CNA2013: Ah-ha moments]]

== Table View ==

{| class="wikitable"
|-
! Room name
! 10:00
! 11:15
! 2:00
! 3:15
! 4:30
|-
| Horace Mann
| ---
| [[End to end Continuous Delivery tools]]
| ---
| ---
| ---
|-
| Deborah Sampson
| ---
| [[Test Triage and Intermittent Test techniques]]
| ---
| ---
| ---
|-
| Thomas Paul
| [[From 0 percent to greater than 0 percent Test Coverage]]
| ---
| [[CI Challenges With Multiple Branches]]
| ---
| ---
|-
| Abigail Adams
| [[Property Based Developer Testing]]
| ---
| ---
| ---
| ---
|-
| Crispus Attucks
| [[Test Expressivity]]
| [[Managing Test Data All The Way To Production]]
| ---
| [[Applying_Cloud_Mindset_to_Continuous_Delivery:_Abundance_over_Scarcity]]
| ---
|}

CITCONNA2013Sessions

2013-08-25T19:13:54Z

Paul.duvall: /* Table View */

CITCON NA 2013 Boston Sessions

Back to the [[Main Page]]

== 10:00 Topics ==

# [[Reproducible CI]]
# [[From 0 percent to greater than 0 percent Test Coverage]]
# [[To Branch or Not to Branch?]]
# [[Property Based Developer Testing]]
# [[Test Expressivity]]

== 11:15 Topics ==

# [[End to end Continuous Delivery tools]]
# [[Test Triage and Intermittent Test techniques]]
# ---
# ---
# [[Managing Test Data All The Way To Production]]

== Lunch Topics ==

# ---

== 2:00 Topics ==

# [[CI Feedback & Metrics]]
# ---
# [[Feature Toggling Strategies]]
# [[CI Challenges With Multiple Branches]]
# ---

== 3:15 Topics ==

# [[NextGen CI Toolkit Wishlist]]
# [[Dead Sea Effect]]
# [[Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity]]
# ---
# ---

== 4:30 Topics ==

# [[Performance testing, automating]]
# [[Continuous Full System Deployment]]
# ---
# ---
# ---

==Final session==
[[CNA2013: Ah-ha moments]]

== Table View ==

{| class="wikitable"
|-
! Room name
! 10:00
! 11:15
! 2:00
! 3:15
! 4:30
|-
| Horace Mann
| ---
| [[End to end Continuous Delivery tools]]
| ---
| ---
| ---
|-
| Deborah Sampson
| ---
| [[Test Triage and Intermittent Test techniques]]
| ---
| ---
| ---
|-
| Thomas Paul
| [[From 0 percent to greater than 0 percent Test Coverage]]
| ---
| [[CI Challenges With Multiple Branches]]
| ---
| ---
|-
| Abigail Adams
| [[Property Based Developer Testing]]
| ---
| ---
| ---
| ---
|-
| Crispus Attucks
| [[Test Expressivity]]
| [[Managing Test Data All The Way To Production]]
| ---
| [[Applying_Cloud_Mindset_to_Continuous_Delivery:_Abundance_over_Scarcity]]
| ---
|}

Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity

2013-08-25T19:09:03Z

Paul.duvall: Created page with "'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abun..."

'''In ''effectively'' using the cloud for all Continuous Delivery (CD) requires a new mindset. One that embraces abundance over scarcity. With the freedom that comes with abundance requires responsibility'''

== Motivations (Similar to Non-Cloud CD) ==
* Reduce Cycle Time and Accelerate Feedback
* Fix problems faster; Troubleshoot more quickly
* Get features to users quicker
* Reduce repetitive error-prone manual processes
== Principles ==
* Abundance over Scarcity
* Reduce and Eliminate Assumptions
* Continually Validate the Source of Truth
* Reduce Infrastructure Costs
== High-Level Practices ==
* Dispose Early and Often
* Recreate from Source
* Use Binaries to Speed Environment and Deployment Creation
== Patterns ==
* '''Ephemeral Environments''': Environments (instance ids, endpoints, etc.) exist per version-control revision in deployment pipeline. The concept of fixed environments with fixed environments (e.g. Dev->QA->Staging->Production) go away. The logical environments in a deployment pipeline (Commit->Acceptance->UAT->Load&Performance, Production) may exist but only per source code revision
* '''Software Systems as Code''':All software systems assets (ACID: Application Code, Configuration, Infrastructure, Data) are described in code, get committed to a version-control repository and move down the pipeline to be built, tested, and deployed
** Infrastructure gets "built" just like the application code
* '''Self-Service Deployments''': Any authorized team member can perform a Self-Service Deployments (w/ Environments) from any stage in the pipeline - from binary artifacts - without contacting a human
* Many attributes contained in configuration files/databases in non-cloud environments can be dynamically obtained through tools like CloudFormation, Puppet, Chef, etc. so that they don't need to be hard-coded in config files for each environment type
* '''Disposable Environments''': Non-Production Environments are automatically terminated based on team policies. Open-source tools like [https://github.com/stelligent/cloudpatrol CloudPatrol] and [https://github.com/Netflix/SimianArmy/wiki/Janitor-Home Janitor Monkey] can assist with this.
* Responsible team members will only use an environment for the duration of their test and then terminate it so that the team is no longer charged by the cloud provide for usage
== Antipatterns ==
* '''Fixed Environments''' (Keeping around environments with the same instance ids, endpoints) for multiple revisions, multiple days, etc. as a way
* '''Fragmented Automation''' - Various automation scripts and components used in creating/modifying environments or deployments at different times. Some might be automated, while others might be automated. The opposite of a Single Path to Production as part of a deployment pipeline.
* '''Partial Deployments''' - Making deployment changes to existing environments as a way to reduce the time of deployment. The adverse effect is that the envrionment/system is in an unknown state making it difficult to troubleshoot problems.
* '''Shared Environments''' - Multiple team members (Dev, QA, Ops, etc.) have access to a non-production environment as a way to manage resource usage.
* '''Locking down Environments''' - As a way to control change to environments that are "works of art" - have been created through manual and/or automated means over a period of days, weeks or months. These environments are considered "scarce" and should only be modified by a few select people as a way to deal with change management and to reduce the risk that a change could detrimentally impact the system. Locking down environments can be an effective when there's a team policy in which environments are only created through automated scripts and nothing else.

CITCONNA2013Sessions

2013-08-25T18:32:23Z

Paul.duvall: /* 3:15 Topics */

CITCON NA 2013 Boston Sessions

Back to the [[Main Page]]

== 10:00 Topics ==

# [[Reproducible CI]]
# [[From 0 percent to greater than 0 percent Test Coverage]]
# [[To Branch or Not to Branch?]]
# [[Property Based Developer Testing]]
# [[Test Expressivity]]

== 11:15 Topics ==

# [[End to end Continuous Delivery tools]]
# [[Test Triage and Intermittent Test techniques]]
# ---
# ---
# [[Managing Test Data All The Way To Production]]

== Lunch Topics ==

# ---

== 2:00 Topics ==

# [[CI Feedback & Metrics]]
# ---
# [[Feature Toggling Strategies]]
# [[CI Challenges With Multiple Branches]]
# ---

== 3:15 Topics ==

# [[NextGen CI Toolkit Wishlist]]
# [[Dead Sea Effect]]
# [[Applying Cloud Mindset to Continuous Delivery: Abundance over Scarcity]]
# ---
# ---

== 4:30 Topics ==

# [[Performance testing, automating]]
# [[Continuous Full System Deployment]]
# ---
# ---
# ---

==Final session==
[[CNA2013: Ah-ha moments]]

== Table View ==

{| class="wikitable"
|-
! Room name
! 10:00
! 11:15
! 2:00
! 3:15
! 4:30
|-
| Horace Mann
| ---
| [[End to end Continuous Delivery tools]]
| ---
| ---
| ---
|-
| Deborah Sampson
| ---
| [[Test Triage and Intermittent Test techniques]]
| ---
| ---
| ---
|-
| Thomas Paul
| [[From 0 percent to greater than 0 percent Test Coverage]]
| ---
| [[CI Challenges With Multiple Branches]]
| ---
| ---
|-
| Abigail Adams
| [[Property Based Developer Testing]]
| ---
| ---
| ---
| ---
|-
| Crispus Attucks
| [[Test Expressivity]]
| [[Managing Test Data All The Way To Production]]
| ---
| ---
| ---
|}

Paul Duvall

2013-08-25T18:30:37Z

Paul.duvall: /* About */

===About===
* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website]
* My company: [http://www.stelligent.com/ Stelligent]
* Stelligent's blog: [http://www.stelligent.com/blog Stelligent Blog]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/solutions/elastic-operations/ Elastic Operations]

===Video Series===
* [http://www.informit.com/store/devops-in-the-cloud-livelessons-video-training-create-9780321793263 DevOps in the Cloud LiveLessons (Video Training): Create a Continuous Delivery Platform Using Amazon Web Services (AWS) and Jenkins]

===Articles===
* [http://www.ibm.com/developerworks/java/library/a-devops1/ Agile DevOps: The flattening of the software release process]
* [http://www.ibm.com/developerworks/java/library/a-devops2/ Agile DevOps: Infrastructure automation]
* [http://www.ibm.com/developerworks/java/library/a-devops3/ Agile DevOps: Transient environments]
* [http://www.ibm.com/developerworks/java/library/a-devops4/ Agile DevOps: Unleash the Chaos Monkey]
* [http://www.ibm.com/developerworks/java/library/a-devops5/ Agile DevOps: Test-driven infrastructure]
* [http://www.ibm.com/developerworks/java/library/a-devops6/ Agile DevOps: Version everything]
* [http://www.ibm.com/developerworks/java/library/a-devops7/ Agile DevOps: Agile DevOps: Dynamic configuration]
* [http://www.ibm.com/developerworks/java/library/a-devops8/ Agile DevOps: Agile DevOps: Continuous software delivery in the cloud]
* [http://www.ibm.com/developerworks/java/library/a-devops9/ Agile DevOps: Breaking down silos]
* [http://www.ibm.com/developerworks/java/library/a-devops10/ Agile DevOps: Build a DevOps dashboard]
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]

Paul Duvall

2013-08-25T18:28:13Z

Paul.duvall: /* Articles */

===About===
* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website]
* My company: [http://www.stelligent.com/ Stelligent]
* My blog: [http://www.stelligent.com/blog Stelligent Blog]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/solutions/elastic-operations/ Elastic Operations]

===Video Series===
* [http://www.informit.com/store/devops-in-the-cloud-livelessons-video-training-create-9780321793263 DevOps in the Cloud LiveLessons (Video Training): Create a Continuous Delivery Platform Using Amazon Web Services (AWS) and Jenkins]

===Articles===
* [http://www.ibm.com/developerworks/java/library/a-devops1/ Agile DevOps: The flattening of the software release process]
* [http://www.ibm.com/developerworks/java/library/a-devops2/ Agile DevOps: Infrastructure automation]
* [http://www.ibm.com/developerworks/java/library/a-devops3/ Agile DevOps: Transient environments]
* [http://www.ibm.com/developerworks/java/library/a-devops4/ Agile DevOps: Unleash the Chaos Monkey]
* [http://www.ibm.com/developerworks/java/library/a-devops5/ Agile DevOps: Test-driven infrastructure]
* [http://www.ibm.com/developerworks/java/library/a-devops6/ Agile DevOps: Version everything]
* [http://www.ibm.com/developerworks/java/library/a-devops7/ Agile DevOps: Agile DevOps: Dynamic configuration]
* [http://www.ibm.com/developerworks/java/library/a-devops8/ Agile DevOps: Agile DevOps: Continuous software delivery in the cloud]
* [http://www.ibm.com/developerworks/java/library/a-devops9/ Agile DevOps: Breaking down silos]
* [http://www.ibm.com/developerworks/java/library/a-devops10/ Agile DevOps: Build a DevOps dashboard]
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]

Paul Duvall

2013-08-25T18:27:37Z

Paul.duvall:

===About===
* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website]
* My company: [http://www.stelligent.com/ Stelligent]
* My blog: [http://www.stelligent.com/blog Stelligent Blog]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/solutions/elastic-operations/ Elastic Operations]

===Video Series===
* [http://www.informit.com/store/devops-in-the-cloud-livelessons-video-training-create-9780321793263 DevOps in the Cloud LiveLessons (Video Training): Create a Continuous Delivery Platform Using Amazon Web Services (AWS) and Jenkins]

===Articles===
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]
* [http://www.ibm.com/developerworks/java/library/a-devops1/ Agile DevOps: The flattening of the software release process]
* [http://www.ibm.com/developerworks/java/library/a-devops2/ Agile DevOps: Infrastructure automation]
* [http://www.ibm.com/developerworks/java/library/a-devops3/ Agile DevOps: Transient environments]
* [http://www.ibm.com/developerworks/java/library/a-devops4/ Agile DevOps: Unleash the Chaos Monkey]
* [http://www.ibm.com/developerworks/java/library/a-devops5/ Agile DevOps: Test-driven infrastructure]
* [http://www.ibm.com/developerworks/java/library/a-devops6/ Agile DevOps: Version everything]
* [http://www.ibm.com/developerworks/java/library/a-devops7/ Agile DevOps: Agile DevOps: Dynamic configuration]
* [http://www.ibm.com/developerworks/java/library/a-devops8/ Agile DevOps: Agile DevOps: Continuous software delivery in the cloud]
* [http://www.ibm.com/developerworks/java/library/a-devops9/ Agile DevOps: Breaking down silos]
* [http://www.ibm.com/developerworks/java/library/a-devops10/ Agile DevOps: Build a DevOps dashboard]

Paul Duvall

2013-08-25T18:26:47Z

Paul.duvall: /* Articles */

* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website]
* My company: [http://www.stelligent.com/ Stelligent]
* My blog: [http://www.stelligent.com/blog Stelligent Blog]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/solutions/elastic-operations/ Elastic Operations]

===Video Series===
* [http://www.informit.com/store/devops-in-the-cloud-livelessons-video-training-create-9780321793263 DevOps in the Cloud LiveLessons (Video Training): Create a Continuous Delivery Platform Using Amazon Web Services (AWS) and Jenkins]

===Articles===
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]
* [http://www.ibm.com/developerworks/java/library/a-devops1/ Agile DevOps: The flattening of the software release process]
* [http://www.ibm.com/developerworks/java/library/a-devops2/ Agile DevOps: Infrastructure automation]
* [http://www.ibm.com/developerworks/java/library/a-devops3/ Agile DevOps: Transient environments]
* [http://www.ibm.com/developerworks/java/library/a-devops4/ Agile DevOps: Unleash the Chaos Monkey]
* [http://www.ibm.com/developerworks/java/library/a-devops5/ Agile DevOps: Test-driven infrastructure]
* [http://www.ibm.com/developerworks/java/library/a-devops6/ Agile DevOps: Version everything]
* [http://www.ibm.com/developerworks/java/library/a-devops7/ Agile DevOps: Agile DevOps: Dynamic configuration]
* [http://www.ibm.com/developerworks/java/library/a-devops8/ Agile DevOps: Agile DevOps: Continuous software delivery in the cloud]
* [http://www.ibm.com/developerworks/java/library/a-devops9/ Agile DevOps: Breaking down silos]
* [http://www.ibm.com/developerworks/java/library/a-devops10/ Agile DevOps: Build a DevOps dashboard]

Paul Duvall

2013-08-25T18:26:09Z

Paul.duvall:

* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website]
* My company: [http://www.stelligent.com/ Stelligent]
* My blog: [http://www.stelligent.com/blog Stelligent Blog]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/solutions/elastic-operations/ Elastic Operations]

===Articles===
* [http://www.informit.com/store/devops-in-the-cloud-livelessons-video-training-create-9780321793263 DevOps in the Cloud LiveLessons (Video Training): Create a Continuous Delivery Platform Using Amazon Web Services (AWS) and Jenkins]

===Articles===
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]
* [http://www.ibm.com/developerworks/java/library/a-devops1/ Agile DevOps: The flattening of the software release process]
* [http://www.ibm.com/developerworks/java/library/a-devops2/ Agile DevOps: Infrastructure automation]
* [http://www.ibm.com/developerworks/java/library/a-devops3/ Agile DevOps: Transient environments]
* [http://www.ibm.com/developerworks/java/library/a-devops4/ Agile DevOps: Unleash the Chaos Monkey]
* [http://www.ibm.com/developerworks/java/library/a-devops5/ Agile DevOps: Test-driven infrastructure]
* [http://www.ibm.com/developerworks/java/library/a-devops6/ Agile DevOps: Version everything]
* [http://www.ibm.com/developerworks/java/library/a-devops7/ Agile DevOps: Agile DevOps: Dynamic configuration]
* [http://www.ibm.com/developerworks/java/library/a-devops8/ Agile DevOps: Agile DevOps: Continuous software delivery in the cloud]
* [http://www.ibm.com/developerworks/java/library/a-devops9/ Agile DevOps: Breaking down silos]
* [http://www.ibm.com/developerworks/java/library/a-devops10/ Agile DevOps: Build a DevOps dashboard]

Provisioning in the Cloud

2010-04-17T21:42:06Z

Paul.duvall:

* Can provision target environments using [http://en.wikipedia.org/wiki/Cloud_computing cloud computing]
* Creating on-demand virtual hardware instances through an API
* Non-production environments are most appropriate for cloud computing
* Spinning up test instances is good use case for cloud computing
* Amazon Web Services Management Console [http://aws.amazon.com/console/]
* CI as a Service [http://www.stelligent.com/products/provisioner.php]
** Accepting beta users at ciasaservice@stelligent.com

Paul Duvall

2010-04-17T21:28:43Z

Paul.duvall:

* My book: [http://www.amazon.com/gp/product/0321336380/ Continuous Integration: ''Improving Software Quality and Reducing Risk'']
** [http://www.integratebutton.com/ Book's website] and [http://www.integratebutton.com/blog blog]
* My company: [http://www.stelligent.com/ Stelligent],
* My blog: [http://integratebutton.typepad.com/ Integrate Button]
* paul.duvall -at- stelligent.com
* My [http://www.linkedin.com/in/paulduvall LinkedIn] page
* [http://www.stelligent.com/products/provisioner.php CI as a Service]

===Articles===
* [http://www-128.ibm.com/developerworks/java/library/j-ap09056/index.html Automation for the people: Choosing a Continuous Integration Server]
* [http://www-128.ibm.com/developerworks/java/library/j-ap10106/index.html Automation for the people: Removing the smell from your build scripts]
* [http://www-128.ibm.com/developerworks/java/library/j-ap08016/index.html Automation for the people: Continuous Inspection]
* [http://www-128.ibm.com/developerworks/java/library/j-ap03137/index.html Automation for the people: Continuous Testing]
* [http://www.ibm.com/developerworks/java/library/j-ap01139/ Automation for the people: Deployment Automation Patterns, Part 1]
* [http://www.ibm.com/developerworks/java/library/j-ap02109/index.html Automation for the people: Deployment Automation Patterns, Part 2]

Provisioning in the Cloud

2010-04-17T21:27:28Z

Paul.duvall:

* Can provision target environments using [http://en.wikipedia.org/wiki/Cloud_computing cloud computing]
* Non-production environments are most appropriate for cloud computing
* Spinning up test instances is good use case for cloud computing
* Amazon Web Services Management Console [http://aws.amazon.com/console/]
* CI as a Service [http://www.stelligent.com/products/provisioner.php]
** Accepting beta users at ciasaservice@stelligent.com

Provisioning in the Cloud

2010-04-17T21:23:13Z

Paul.duvall:

* Amazon Web Services Management Console [http://aws.amazon.com/console/]
* CI as a Service [http://www.stelligent.com/products/provisioner.php]
** Accepting beta users at ciasaservice@stelligent.com

Provisioning in the Cloud

2010-04-17T21:21:56Z

Paul.duvall:

* Amazon Web Services Management Console [http://aws.amazon.com/console/]
* CI as a Service [http://www.stelligent.com/products/provisioner.php]

Provisioning in the Cloud

2010-04-17T21:20:05Z

Paul.duvall: New page: * [Amazon Web Services Management Console|http://aws.amazon.com/console/]

* [Amazon Web Services Management Console|http://aws.amazon.com/console/]

CITCONUS2010Sessions

2010-04-17T21:18:49Z

Paul.duvall:

The notes from sessions go here. Please create one page per session.<br>

[[Value of Automated Acceptance testing]]

[[Is Scrum Evil]]

[[Continuous Deployment]]

[[Backyard Beekeeping]]

[[Fear and Rage in CI and TDD]]

[[Automated Workspace Setup]]

[[Metrics on and generated by CI]]

[[Provisioning in the Cloud]]

[[How to do without a CI Server]]

[[Lean Software Development]]

[[Intersection of CI and Release Management]]

Lean Software Development

2010-04-17T21:16:29Z

Paul.duvall:

* Reengineering the Corporation - [http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]
* About Systems Thinking - How the whole thing works together, not isolated - http://en.wikipedia.org/wiki/Systems_thinking
* Build Quality In, rather than by inspection
* The Toyota Way [http://www.amazon.com/Toyota-Way-Jeffrey-Liker/dp/0071392319]
* http://en.wikipedia.org/wiki/W._Edwards_Deming
* http://www.poppendieck.com/
** Lean Software Development: An Agile Toolkit - [http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/]
** Leading Lean Software Development: Results Are not the Point - [http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704/]
** Implementing Lean Software Development: From Concept to Cash [http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/]
* 7 principles
** Eliminate Waste
** Create Knowledge
** Build Quality In
** Defer Commitment
** Deliver Fast
** Respect People
** Improve the System
* Value Stream Mapping - [http://en.wikipedia.org/wiki/Value_stream_mapping] (lean manufacturing technique used to analyze the flow of materials and information currently required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as "material and information flow mapping)
* The 5th Discipline - [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization/dp/0385260954]
* "Because we have the demand, now we put in the effort to implement it", Kanban
* Specified->Coded->Tested->Deployed->Customer
* Toyota Production System - [http://en.wikipedia.org/wiki/Toyota_Production_System]
* Lean can focus on the System-level, CIO level rather than just the PMs, or Engineers, etc.
* The Goal [http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271781/]
* This American Life: NUMMI Plant [http://www.thisamericanlife.org/radio-archives/episode/403/nummi]

Lean Software Development

2010-04-17T21:10:26Z

Paul.duvall:

Lean Software Development

2010-04-17T21:09:17Z

Paul.duvall:

Lean Software Development

2010-04-17T21:01:10Z

Paul.duvall:

* Reengineering the Corporation - [http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]
* About Systems Thinking - How the whole thing works together, not isolated - http://en.wikipedia.org/wiki/Systems_thinking
* Build Quality In, rather than by inspection
* The Toyota Way [http://www.amazon.com/Toyota-Way-Jeffrey-Liker/dp/0071392319]
* http://en.wikipedia.org/wiki/W._Edwards_Deming
* http://www.poppendieck.com/
** Lean Software Development: An Agile Toolkit - [http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/]
** Leading Lean Software Development: Results Are not the Point - [http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704/]
** Implementing Lean Software Development: From Concept to Cash [http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/]
* 7 principles
** Eliminate Waste
** Create Knowledge
** Build Quality In
** Defer Commitment
** Deliver Fast
** Respect People
** Improve the System
* Value Stream Mapping - [http://en.wikipedia.org/wiki/Value_stream_mapping] (lean manufacturing technique used to analyze the flow of materials and information currently required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as "material and information flow mapping)
* The 5th Discipline - [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization/dp/0385260954]
* "Because we have the demand, now we put in the effort to implement it", Kanban
* Specified->Coded->Tested->Deployed->Customer
* Toyota Production Systems - [http://en.wikipedia.org/wiki/Toyota_Production_System]

Lean Software Development

2010-04-17T20:58:57Z

Paul.duvall:

* Reengineering the Corporation - [http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]
* About Systems Thinking - How the whole thing works together, not isolated - http://en.wikipedia.org/wiki/Systems_thinking
* Build Quality In, rather than by inspection
* The Toyota Way [http://www.amazon.com/Toyota-Way-Jeffrey-Liker/dp/0071392319]
* http://en.wikipedia.org/wiki/W._Edwards_Deming
* http://www.poppendieck.com/
** Lean Software Development: An Agile Toolkit - [http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/]
** Leading Lean Software Development: Results Are not the Point - [http://www.amazon.com/Leading-Lean-Software-Development-Results/dp/0321620704/]
** Implementing Lean Software Development: From Concept to Cash [http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/]
* 7 principles
** Eliminate Waste
** Create Knowledge
** Build Quality In
** Defer Commitment
** Deliver Fast
** Respect People
** Improve the System
* Value Stream Mapping - [http://en.wikipedia.org/wiki/Value_stream_mapping] (lean manufacturing technique used to analyze the flow of materials and information currently required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as "material and information flow mapping)
* The 5th Discipline - [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization/dp/0385260954]
* "Because we have the demand, now we put in the effort to implement it
* Specified->Coded->Tested->Deployed->Customer
* Toyota Production Systems - [http://en.wikipedia.org/wiki/Toyota_Production_System]

Lean Software Development

2010-04-17T20:57:51Z

Paul.duvall:

Lean Software Development

2010-04-17T20:55:48Z

Paul.duvall:

Lean Software Development

2010-04-17T20:52:11Z

Paul.duvall:

Lean Software Development

2010-04-17T20:50:31Z

Paul.duvall:

Lean Software Development

2010-04-17T20:49:43Z

Paul.duvall:

Lean Software Development

2010-04-17T20:48:48Z

Paul.duvall:

Lean Software Development

2010-04-17T20:44:55Z

Paul.duvall:

Lean Software Development

2010-04-17T20:42:17Z

Paul.duvall:

* [Reengineering the Corporation http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]
* About Systems Thinking - How the whole thing works together, not isoloated
* Build Quality In, rather than by inspection
* The Toyota Way
* http://en.wikipedia.org/wiki/W._Edwards_Deming
* http://www.poppendieck.com/

Lean Software Development

2010-04-17T20:39:14Z

Paul.duvall: New page: [Reengineering the Corporation http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]

[Reengineering the Corporation http://www.amazon.com/Reengineering-Corporation-Manifesto-Revolution-Essentials/dp/0060559535/]

CITCONUS2010Sessions

2010-04-17T20:38:07Z

Paul.duvall:

The notes from sessions go here. Please create one page per session.<br>

[[Value of Automated Acceptance testing]]

[[Is Scrum Evil]]

[[Continuous Deployment]]

[[Backyard Beekeeping]]

[[Fear and Rage in CI and TDD]]

[[Automated Workspace Setup]]

[[Metrics on and generated by CI]]

[[How to do without a CI Server]]

[[Lean Software Development]]