Solum/Environments
Environments 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 it's own credentials for one or more cloud accounts. Such credentials will be persisted securely in Barbican. Following are some of the personas and use cases.
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
