archive-gh-me/serverless
1
0
Fork 0
mirror of https://github.com/serverless/serverless.git synced 2026-01-25 15:07:39 +00:00
Code Issues Projects Releases Wiki Activity

Update documentation

Browse Source
This commit is contained in:
Philipp Muens 2016-08-20 20:39:43 +02:00
parent b72cd2f882
commit bcc74df4dd
2 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/developing-plugins/building-provider-integrations.md
View File

@ -19,6 +19,7 @@ Let's take a look at the [core `deploy` plugin](/lib/plugins/deploy) and the dif
The following lifecycle events are run in order once the user types `serverless deploy` and hits enter:
- `deploy:cleanup`
- `deploy:initialize`
- `deploy:setupProviderConfiguration`
- `deploy:compileFunctions`
@ -31,6 +32,11 @@ infrastructure.
Let's take a closer look at each lifecycle event to understand what its purpose is and what it should be used for.
#### `deploy:cleanup`
Remove the `.serverless` directory which stores all the artifacts which were previously deployed to make sure that the
new artifacts can be stored in the `.serverless` directory and won't conflict with the old ones.
#### `deploy:initialize`
This lifecycle should be used to load the basic resources the provider needs into memory (e.g. parse a basic resource
@ -86,10 +92,12 @@ Here are the steps the AWS plugins take to compile and deploy the service on the
3. The functions of the [`serverless.yml`](../understanding-serverless/serverless-yml.md) file are compiled to lambda
resources and stored into memory (`deploy:compileFunctions`)
4. Each functions events are compiled into CloudFormation resources and stored into memory (`deploy:compileEvents`)
5. Old functions (if available) are removed from the S3 bucket (`deploy:deploy`)
6. The service gets zipped up and is uploaded to S3 (`deploy:createDeploymentArtifacts` and `deploy:deploy`)
5. Old artifacts (if available) are removed from the S3 bucket (`deploy:deploy`)
6. The service gets zipped up (`deploy:createDeploymentArtifacts` and `deploy:deploy`)
7. The compiled functions, event resources and custom provider resources are attached to the core CloudFormation template
and the updated CloudFormation template gets redeployed (`deploy:deploy`)
(`deploy:deploy`)
8. The zipped service and CloudFormation template are uploaded to S3 (`deploy:deploy`)
9. The stack will be updated with the help of the recently uploaded artifacts (`deploy:deploy`)
#### The code

6
lib/plugins/aws/deploy/README.md
View File

@ -17,9 +17,9 @@ This makes sure that custom resources the user has defined inside the `serverles
**Note:** Empty, but defined `Resources` or `Outputs` sections are set to an empty object before being merged.
Next up it removes old service .zip files in the services S3 bucket. After that it uploads the services
.zip file (which is available via `serverless.service.package.artifact`) to the S3 bucket (which is defined in the core
CloudFormation template). Furthermore it updates the stack with all the Resources which are defined in
Next up it removes old service directories (with its files) in the services S3 bucket. After that it creates a new directory
with the current time as the directory name in S3 and uploads the services artifacts (e.g. the .zip file and the CloudFormation
file) in this directory. Furthermore it updates the stack with all the Resources which are defined in
`serverless.service.resources.Resources` (this also includes the custom provider resources).
The stack status is checked every 5 seconds with the help of the CloudFormation API. It will return a success message if