Jump to: navigation, search

Difference between revisions of "Solum/Environments"

(Environments)
 
(Environments)
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Environments is a logical grouping of resources. Following are some of the use cases.
+
= Environments =
 +
An Environment is a logical grouping of resources. App actions (deploy, view stats, etc) can be targeted per environment. Certain constraints (permissions, resource quotas, etc) can also be applied per environment. An environment may carry its own credentials for one or more cloud accounts. Such credentials will be persisted securely in [[Barbican]].  
  
=== Use cases ===
+
Example:
1. As an application developer deploying my app onto Solum, I should be able to specifiy the environment where my app gets deployed i.e. Dev, Test, Staging, Prod
+
{
 +
  "id": "a7033084-5efef-4812-90a4-e4d24ffb6e31",
 +
  "name": "staging",
 +
  "type": "environment",
 +
  "acl": "fcd84e29-c169-47b1-aaf0-f5dcbded1b39",
 +
  "credentials": "3f95316c-acce-476c-a96b-8b75039a37d5",
 +
  "keystone_endpoint": "https://12.34.56.78:5000",
 +
  "change_policy": "c299c08c-213f-4b88-8da4-e5bb90640db3"
 +
}
  
2. As a release manager manager defining the app release lifecycle for our PaaS apps, I should be able to define my "custom" environments in addition to the predefined ones such as Dev/Test/Staging/Prod. An example of a custom environment could be "Performance Test Environment".
+
The above example shown a staging environment containing two assemblies (running applications), a reference to an ACL policy, and a reference to a credentials set (a secret in [[Barbican]]) to use to authenticate with the configured keystone and heat endpoint. Note that additional keys may be added, and each service consuming the Environment resource may implement functionality based on the presence of the keys in the Environment. The referenced change_policy (implemented with [[Congress]]) will be used to determine if the assembly_list can be altered by adding an assembly or removing one.
  
3. As a release manager for a team deploying apps via Solum, I should be able to specify resource quota's (amount of compute/storage) per environment. Once the resource quota is hit, I should be able to specify a soft threshold (email notification), or a hard threshold (i.e. prevent further resource use on the environment)
+
Following are some use cases and the related personas:
  
4. As a release manager for a team deploying apps on Solum, I should be able to specify which user can perform what actions on each environment. For example, a developer might have more access to a dev environment [deploy app, start/stop app, delete app, view app status+statistics], and less access to a production environment [view access only]
+
=== Personas ===
 +
==== Solum User ====
 +
A user of the [[Solum]] software and an OpenStack Cloud to facilitate ease-of-use and automated integration with software development for applications that run on OpenStack. A <code>Solum User</code> is a software developer (canonically: Application Developer).
 +
==== Release Manager ====
 +
An individual member of a software development team responsible for coordinating software releases, and initiating deployments of tested/approved software.
  
5. As a release manager, I should be able to specify the "entry gates" for app deployment by environment. For example
+
=== Use Cases ===
* unit tests must pass for dev environment
+
1. As a <code>Solum User</code> deploying my app with Solum, I want to specify the environment where my app gets deployed i.e. Dev, Test, Staging, Prod, as long as I have "deploy" privileges on the Environment [see 2 below].
* functional tests must pass for test environment
 
* performance tests must pass for staging environment
 
  
6. Promotion of apps from one environment to the next: as a release manager, I should be able to "promote" an app from one environment to the next. For example, once test signoff is received from the QA team, I should be able to promote the app from the Test environment to the Staging environment. When an app is promoted, the DU/image is not rebuilt from code, rather the same DU from the Test environment is deployed to the Staging environment.
+
 
 +
2. As a <code>Release Manager</code> for a team deploying apps on Solum, I want to specify which user can perform what actions on each environment. For example, a developer may have more access to a dev environment [deploy app, start/stop app, delete app, view app status+statistics], and less access to a production environment [view access only]
 +
 
 +
 
 +
3. As a <code>Release Manager</code>defining the app release lifecycle for our apps, I want to define my "custom" environments in addition to selecting from predefined ones such as Dev/Test/Staging/Prod. An example of a custom environment could be "Performance Test Environment".
 +
 
 +
 
 +
4. As a <code>Release Manager</code> for a team deploying apps via Solum, I should be able to specify resource quota's (amount of compute/storage) per environment. Once the resource quota is hit, I should be able to specify a soft threshold (email notification), or a hard threshold (i.e. prevent further resource use on the environment).
 +
 
 +
 
 +
5. As a <code>Release Manager</code>, I want to specify conditional "entry gates" for app deployment by environment. For example
 +
* Unit tests must pass for dev environment
 +
* Functional tests must pass for test environment
 +
* Performance tests must pass for staging environment
 +
 
 +
 
 +
6. Promotion of apps from one environment to the next: as a <code>Release Manager</code>, I want to "promote" an app from one environment to the next. For example, once test sign-off is received from the QA team, I should be able to promote the app from the Test environment to the Staging environment. When an app is promoted, the application binary/WAR file is not rebuilt from code, rather the same binary from the Test environment is used to compose the DU to be deployed to the Staging environment.
 +
 
 +
=== See Also ===
 +
Proposed API for: [[Solum/ApiModel|Pipelines]]

Latest revision as of 20:02, 14 May 2014

Environments

An Environment is a logical grouping of resources. App actions (deploy, view stats, etc) can be targeted per environment. Certain constraints (permissions, resource quotas, etc) can also be applied per environment. An environment may carry its own credentials for one or more cloud accounts. Such credentials will be persisted securely in Barbican.

Example:

{
  "id": "a7033084-5efef-4812-90a4-e4d24ffb6e31",
  "name": "staging",
  "type": "environment",
  "acl": "fcd84e29-c169-47b1-aaf0-f5dcbded1b39",
  "credentials": "3f95316c-acce-476c-a96b-8b75039a37d5",
  "keystone_endpoint": "https://12.34.56.78:5000",
  "change_policy": "c299c08c-213f-4b88-8da4-e5bb90640db3"
}

The above example shown a staging environment containing two assemblies (running applications), a reference to an ACL policy, and a reference to a credentials set (a secret in Barbican) to use to authenticate with the configured keystone and heat endpoint. Note that additional keys may be added, and each service consuming the Environment resource may implement functionality based on the presence of the keys in the Environment. The referenced change_policy (implemented with Congress) will be used to determine if the assembly_list can be altered by adding an assembly or removing one.

Following are some use cases and the related personas:

Personas

Solum User

A user of the Solum software and an OpenStack Cloud to facilitate ease-of-use and automated integration with software development for applications that run on OpenStack. A Solum User is a software developer (canonically: Application Developer).

Release Manager

An individual member of a software development team responsible for coordinating software releases, and initiating deployments of tested/approved software.

Use Cases

1. As a Solum User deploying my app with Solum, I want to specify the environment where my app gets deployed i.e. Dev, Test, Staging, Prod, as long as I have "deploy" privileges on the Environment [see 2 below].


2. As a Release Manager for a team deploying apps on Solum, I want to specify which user can perform what actions on each environment. For example, a developer may have more access to a dev environment [deploy app, start/stop app, delete app, view app status+statistics], and less access to a production environment [view access only]


3. As a Release Managerdefining the app release lifecycle for our apps, I want to define my "custom" environments in addition to selecting from predefined ones such as Dev/Test/Staging/Prod. An example of a custom environment could be "Performance Test Environment".


4. As a Release Manager for a team deploying apps via Solum, I should be able to specify resource quota's (amount of compute/storage) per environment. Once the resource quota is hit, I should be able to specify a soft threshold (email notification), or a hard threshold (i.e. prevent further resource use on the environment).


5. As a Release Manager, I want to specify conditional "entry gates" for app deployment by environment. For example

  • Unit tests must pass for dev environment
  • Functional tests must pass for test environment
  • Performance tests must pass for staging environment


6. Promotion of apps from one environment to the next: as a Release Manager, I want to "promote" an app from one environment to the next. For example, once test sign-off is received from the QA team, I should be able to promote the app from the Test environment to the Staging environment. When an app is promoted, the application binary/WAR file is not rebuilt from code, rather the same binary from the Test environment is used to compose the DU to be deployed to the Staging environment.

See Also

Proposed API for: Pipelines