Difference between revisions of "Solum/FeatureBlueprints/GitIntegration"
(→Code Flow) |
(→Flow Boundaries) |
||
| Line 69: | Line 69: | ||
=== Flow Boundaries === | === Flow Boundaries === | ||
Diagram for component areas and potential abstraction boundaries: | Diagram for component areas and potential abstraction boundaries: | ||
| + | |||
[[File:Solum r01 flow.jpeg|frameless]] | [[File:Solum r01 flow.jpeg|frameless]] | ||
=== Implementation === | === Implementation === | ||
Revision as of 21:40, 30 October 2013
Blueprint: https://blueprints.launchpad.net/solum/+spec/git-integration
Contents
Git Deployment
Functionality
A deployment unit (DU) is a unit of deployment for the application being deployed. For example, if Solum is configured to use containers for deploying application code, then a DU would refer to a container instance.
Story 1: generate new app (minimal implementation)
As an application developer, I want to push my code to the master branch of my git repository, and have the platform automatically detect the code push and generate a running application (i.e. an assembly) using the new code.
I would be able to specify the application characteristics (AppName, size and number of deployment units, auto scale policies, etc) while deploying my app.
Following are the application characteristics that can be specified (this is an indicative list, not intended to be a comprehensive list).
Application Characteristics
| Attribute name | Description | Required? |
|---|---|---|
| DU Count | Initial number of deployment units. | Optional (default = 1) |
| Flavor | Size of each DU (as determined by RAM, CPU, disk space, allocated to each DU). Small, medium, large, extra large, etc. the sizing characteristics of what is small and what is large is configurable by the platform service provider | Optional (if no flavor is provided, then a default flavor will be used. The default flavor is configurable by the service provider) |
| AutoScale | Should the application auto-scale (Y/N) | Optional (default = N) |
| MinInstances | Minimum number of DU's (lower threshold for the auto scale policy) | Optional (default = 1) |
| MaxInstances | Maximum number of DU's (upper threshold for the auto scale policy) | Optional (default = specified DU Count during app creation) |
| ShellEnvironment | Set application specific shell environment variables at app start up | Optional |
| LanguagePack | User could specify the language pack (say MyPythonPack) to be used during app creation. If no language pack is specified, then the platform would auto-detect the default language pack associated with the code being pushed. | Optional |
| Services | List of services that the application will bind to (e.g.Trove, NewRelic). The services list would also optionally contain any service initialization parameters if the service support it. An example of this will be an SQL script passed to a database service to create the custom application scheme. | Optional |
The general workflow for a git based deployment is as follows:
1. Precondition: the user is already registered as an OpenStack user, and has been associated with the Solum service (see the blueprint "user authentication" for details)
2. Register[noun]: registers the new application with Solum (generates a git repository in Solum and associates it with the new app).
- Inputs: Name (Optional) of the application, if no Name is provided, Solum will generate one
- Returns: URL of the remote git repository, and the URL associated with the app
3. Git push (deploys and generates a running app). Builds the app binary from source. Git push will use the default application characteristics (per the default values specified in the Application Characteristics table above). The default values can be overridden by specifying the values in an application meta-data file that is stored along with the application source.
While implementing this story, the build step and deploy step will be self-contained steps that can either be invoked together, or separately. This is needed to support "build once, deploy multiple" scenarios, for example when we implement environment support.
Side note: there will be multiple deployment paths supported by Solum. Deployments can happen via
- Git (this blueprint)
- CLI (where register and deploy will be combined to a single CLI operation exposed to the user, that packages code from a directory network accessible from the developer's workstation)
- IDE Plugins
- SDK (that calls into the REST API)
- REST API
All the deployment paths above will converge at the REST API: i.e. all the steps end up calling the REST API where all the business logic for build and deploy resides. All the other deployment mechanisms are "hooks" to do the necessarily pre-processing before calling the REST API. More details on the multiple deployment approaches will be documented in a separate blueprint (TBD).
Story 2: update app
I would be able to use git push for updating an existing application. The update can include changes to the application code, or changes to the application characteristics (refer table in Story 1 above). I would like the update to happen with zero downtime (or at least near zero time) for my running app.
Story 3: specify git branch
By default, what we implemented in Story 1 will always build from the master branch. As part of this story, I would like to be able to specify a specific branch to use for the build. I should be able to specify the branch in two ways -
- specify the branch as part of each deployment request - configure a default branch to be used for each subsequent deployment
Story 4: Auto deploy Yes/No
Auto deploy: I would be able to specify if a git push operation just performs a build, or performs a build+deploy to generate a running application (default behavior will be build+deploy)
Solum will implement Environments/Application Life Cycle management as part of the roadmap. However, implementation of environments is out of scope of this blueprint.
Flow Boundaries
Diagram for component areas and potential abstraction boundaries:
