Skip to content

Instantly share code, notes, and snippets.

@turhn

turhn/DevOps Manifesto.md

Forked from anonymous/gist:161265
Last active August 29, 2015 14:19
Show Gist options
  • Save turhn/423d5af5f9a6a23f9ccc to your computer and use it in GitHub Desktop.
Save turhn/423d5af5f9a6a23f9ccc to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. turhn revised this gist Apr 13, 2015. 1 changed file with 26 additions and 26 deletions.
    52 changes: 26 additions & 26 deletions DevOps Manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,38 +2,38 @@

    On Infrastructure
    -----------------
    *There is one system, not a collection of systems.
    *The desired state of the system should be a known quantity.
    *The "known quantity" must be machine parseable.
    *The actual state of the system must self-correct to the desired state.
    *The only authoritative source for the actual state of the system is the system.
    *The entire system must be deployable using source media and text files.
    * There is one system, not a collection of systems.
    * The desired state of the system should be a known quantity.
    * The "known quantity" must be machine parseable.
    * The actual state of the system must self-correct to the desired state.
    * The only authoritative source for the actual state of the system is the system.
    * The entire system must be deployable using source media and text files.

    On Buying Software
    -------------------
    *Keep the components in the infrastructure simple so it will be better understood.
    *All products must authenticate and authorize from external, configurable sources.
    *Use small tools that interoperate well, not one "do everything poorly" product.
    *Do not implement any product that no one in your organization has administered.
    *"Administered" does not mean saw it in a rigged demo, online or otherwise.
    *If you must deploy the product, hire someone who has implemented it before to do so.
    * Keep the components in the infrastructure simple so it will be better understood.
    * All products must authenticate and authorize from external, configurable sources.
    * Use small tools that interoperate well, not one "do everything poorly" product.
    * Do not implement any product that no one in your organization has administered.
    * "Administered" does not mean saw it in a rigged demo, online or otherwise.
    * If you must deploy the product, hire someone who has implemented it before to do so.

    On Automation
    -------------
    *Do not author any code you would not buy.
    *Do not implement any product that does not provide an API.
    *The provided API must have all functionality that the application provides.
    *The provided API must be tailored to more than one language and platform.
    *Source code counts as an API, and may be restricted to one language or platform.
    *The API must include functional examples and not requre someone to be an expert on the product to use.
    *Do not use any product with configurations that are not machine parseable and machine writeable.
    *All data stored in the product must be machine readable and writeable by applications other than the product itself.
    *Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.
    * Do not author any code you would not buy.
    * Do not implement any product that does not provide an API.
    * The provided API must have all functionality that the application provides.
    * The provided API must be tailored to more than one language and platform.
    * Source code counts as an API, and may be restricted to one language or platform.
    * The API must include functional examples and not requre someone to be an expert on the product to use.
    * Do not use any product with configurations that are not machine parseable and machine writeable.
    * All data stored in the product must be machine readable and writeable by applications other than the product itself.
    * Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.

    In general
    ----------
    *Keep the disparity in your architecture to an absolute minimum.
    *Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    *Do not improve manual processes if you can automate them instead.
    *Do not buy software that requires bare-metal.
    *Manual data transfers and datastores maintained manually are to be avoided.
    * Keep the disparity in your architecture to an absolute minimum.
    * Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    * Do not improve manual processes if you can automate them instead.
    * Do not buy software that requires bare-metal.
    * Manual data transfers and datastores maintained manually are to be avoided.
  2. turhn revised this gist Apr 13, 2015. 1 changed file with 26 additions and 27 deletions.
    53 changes: 26 additions & 27 deletions DevOps Manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,39 +2,38 @@

    On Infrastructure
    -----------------
    There is one system, not a collection of systems.
    The desired state of the system should be a known quantity.
    The "known quantity" must be machine parseable.
    The actual state of the system must self-correct to the desired state.
    The only authoritative source for the actual state of the system is the system.
    The entire system must be deployable using source media and text files.
    *There is one system, not a collection of systems.
    *The desired state of the system should be a known quantity.
    *The "known quantity" must be machine parseable.
    *The actual state of the system must self-correct to the desired state.
    *The only authoritative source for the actual state of the system is the system.
    *The entire system must be deployable using source media and text files.

    On Buying Software
    -------------------
    Keep the components in the infrastructure simple so it will be better understood.
    All products must authenticate and authorize from external, configurable sources.
    Use small tools that interoperate well, not one "do everything poorly" product.
    Do not implement any product that no one in your organization has administered.
    "Administered" does not mean saw it in a rigged demo, online or otherwise.
    If you must deploy the product, hire someone who has implemented it before to do so.
    *Keep the components in the infrastructure simple so it will be better understood.
    *All products must authenticate and authorize from external, configurable sources.
    *Use small tools that interoperate well, not one "do everything poorly" product.
    *Do not implement any product that no one in your organization has administered.
    *"Administered" does not mean saw it in a rigged demo, online or otherwise.
    *If you must deploy the product, hire someone who has implemented it before to do so.

    On Automation
    -------------
    Do not author any code you would not buy.
    Do not implement any product that does not provide an API.
    The provided API must have all functionality that the application provides.
    The provided API must be tailored to more than one language and platform.
    Source code counts as an API, and may be restricted to one language or platform.
    The API must include functional examples and not requre someone to be an expert on the product to use.
    Do not use any product with configurations that are not machine parseable and machine writeable.
    All data stored in the product must be machine readable and writeable by applications other than the product itself.
    Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.
    *Do not author any code you would not buy.
    *Do not implement any product that does not provide an API.
    *The provided API must have all functionality that the application provides.
    *The provided API must be tailored to more than one language and platform.
    *Source code counts as an API, and may be restricted to one language or platform.
    *The API must include functional examples and not requre someone to be an expert on the product to use.
    *Do not use any product with configurations that are not machine parseable and machine writeable.
    *All data stored in the product must be machine readable and writeable by applications other than the product itself.
    *Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.

    In general
    ----------
    Keep the disparity in your architecture to an absolute minimum.
    Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    Do not improve manual processes if you can automate them instead.
    Do not buy software that requires bare-metal.
    Manual data transfers and datastores maintained manually are to be avoided.

    *Keep the disparity in your architecture to an absolute minimum.
    *Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    *Do not improve manual processes if you can automate them instead.
    *Do not buy software that requires bare-metal.
    *Manual data transfers and datastores maintained manually are to be avoided.
  3. turhn revised this gist Apr 13, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion DevOps Manifesto.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    == Rules ==
    #Rules

    On Infrastructure
    -----------------
  4. turhn renamed this gist Apr 13, 2015. 1 changed file with 0 additions and 0 deletions.
    0 DevOps Manifesto → DevOps Manifesto.md
    View file
    File renamed without changes.
  5. turhn revised this gist Apr 13, 2015. 1 changed file with 35 additions and 34 deletions.
    69 changes: 35 additions & 34 deletions DevOps Manifesto
    View file
    Original file line number Diff line number Diff line change
    @@ -1,39 +1,40 @@
    == Rules ==
    On Infrastructure
    -----------------
    There is one system, not a collection of systems.
    The desired state of the system should be a known quantity.
    The "known quantity" must be machine parseable.
    The actual state of the system must self-correct to the desired state.
    The only authoritative source for the actual state of the system is the system.
    The entire system must be deployable using source media and text files.

    On Buying Software
    -------------------
    Keep the components in the infrastructure simple so it will be better understood.
    All products must authenticate and authorize from external, configurable sources.
    Use small tools that interoperate well, not one "do everything poorly" product.
    Do not implement any product that no one in your organization has administered.
    "Administered" does not mean saw it in a rigged demo, online or otherwise.
    If you must deploy the product, hire someone who has implemented it before to do so.
    On Infrastructure
    -----------------
    There is one system, not a collection of systems.
    The desired state of the system should be a known quantity.
    The "known quantity" must be machine parseable.
    The actual state of the system must self-correct to the desired state.
    The only authoritative source for the actual state of the system is the system.
    The entire system must be deployable using source media and text files.

    On Automation
    -------------
    Do not author any code you would not buy.
    Do not implement any product that does not provide an API.
    The provided API must have all functionality that the application provides.
    The provided API must be tailored to more than one language and platform.
    Source code counts as an API, and may be restricted to one language or platform.
    The API must include functional examples and not requre someone to be an expert on the product to use.
    Do not use any product with configurations that are not machine parseable and machine writeable.
    All data stored in the product must be machine readable and writeable by applications other than the product itself.
    Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.
    On Buying Software
    -------------------
    Keep the components in the infrastructure simple so it will be better understood.
    All products must authenticate and authorize from external, configurable sources.
    Use small tools that interoperate well, not one "do everything poorly" product.
    Do not implement any product that no one in your organization has administered.
    "Administered" does not mean saw it in a rigged demo, online or otherwise.
    If you must deploy the product, hire someone who has implemented it before to do so.

    In general
    ----------
    Keep the disparity in your architecture to an absolute minimum.
    Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    Do not improve manual processes if you can automate them instead.
    Do not buy software that requires bare-metal.
    Manual data transfers and datastores maintained manually are to be avoided.
    On Automation
    -------------
    Do not author any code you would not buy.
    Do not implement any product that does not provide an API.
    The provided API must have all functionality that the application provides.
    The provided API must be tailored to more than one language and platform.
    Source code counts as an API, and may be restricted to one language or platform.
    The API must include functional examples and not requre someone to be an expert on the product to use.
    Do not use any product with configurations that are not machine parseable and machine writeable.
    All data stored in the product must be machine readable and writeable by applications other than the product itself.
    Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.

    In general
    ----------
    Keep the disparity in your architecture to an absolute minimum.
    Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    Do not improve manual processes if you can automate them instead.
    Do not buy software that requires bare-metal.
    Manual data transfers and datastores maintained manually are to be avoided.

  6. turhn renamed this gist Apr 13, 2015. 1 changed file with 0 additions and 0 deletions.
    0 gistfile1 → DevOps Manifesto
    View file
    File renamed without changes.
  7. @invalid-email-address Anonymous created this gist Aug 4, 2009.
    39 changes: 39 additions & 0 deletions gistfile1
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,39 @@
    == Rules ==
    On Infrastructure
    -----------------
    There is one system, not a collection of systems.
    The desired state of the system should be a known quantity.
    The "known quantity" must be machine parseable.
    The actual state of the system must self-correct to the desired state.
    The only authoritative source for the actual state of the system is the system.
    The entire system must be deployable using source media and text files.

    On Buying Software
    -------------------
    Keep the components in the infrastructure simple so it will be better understood.
    All products must authenticate and authorize from external, configurable sources.
    Use small tools that interoperate well, not one "do everything poorly" product.
    Do not implement any product that no one in your organization has administered.
    "Administered" does not mean saw it in a rigged demo, online or otherwise.
    If you must deploy the product, hire someone who has implemented it before to do so.

    On Automation
    -------------
    Do not author any code you would not buy.
    Do not implement any product that does not provide an API.
    The provided API must have all functionality that the application provides.
    The provided API must be tailored to more than one language and platform.
    Source code counts as an API, and may be restricted to one language or platform.
    The API must include functional examples and not requre someone to be an expert on the product to use.
    Do not use any product with configurations that are not machine parseable and machine writeable.
    All data stored in the product must be machine readable and writeable by applications other than the product itself.
    Writing hacks around the deficiencies in a product should be less work than writing the product's functionality.

    In general
    ----------
    Keep the disparity in your architecture to an absolute minimum.
    Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
    Do not improve manual processes if you can automate them instead.
    Do not buy software that requires bare-metal.
    Manual data transfers and datastores maintained manually are to be avoided.