SHA256
moved
This commit is contained in:
1 parent
1e15c5b1af
commit
cae543e146
3 files changed
No files matched your search
@@ -1,37 +0,0 @@
|
||||
# CodeBuild
|
||||
- A fully managed build service in the cloud.
|
||||
- Compiles your code, runs unit tests, and produces artifacts that are ready to deploy.
|
||||
- Eliminates the need to provision, manage, and scale your own build server
|
||||
- Provides prepackaged build environments for popular programming languages and build tools such as Apache, Maven, Gradle, and more.
|
||||
- You can also customise environments to use your own build tools
|
||||
- Scaled automatically to meet peak build requests.
|
||||
|
||||
## Workflow
|
||||
1. Trigger a build
|
||||
* You can trigger a build with AWS Console, CLI, SDK or [[_CodePipeline|CodePipeline]] trigger (like pushing to `main`).
|
||||
2. Passes the code onto CodeBuild
|
||||
3. You give it a `buildspec.yaml` file, which is generally part of your code base.
|
||||
* You can override it with other build commands.
|
||||
4. Push into a bucket, or any other AWS SDK action (I think?)
|
||||
|
||||
## Build Environments
|
||||
The Docker images that run the CodeBuild, can be managed by AWS or you. If you need specific software, you need to make an image and upload it to ECR and reference it in the pipeline.
|
||||
|
||||
## `buildspec.yml`
|
||||
- Provides the build instructions.
|
||||
- Needs to be in the root of your project folder (`/buildspec.yml`, relative to the project root) (by default).
|
||||
|
||||
### Phases
|
||||
1. `install`: only for installing packages in the build environment. (Code gets pulled before this step.)
|
||||
2. `pre_build`: commands that run before building.
|
||||
3. `build`: commands that you run during the build.
|
||||
4. `post_build`: commands you run after the build.
|
||||
|
||||
### Artifacts
|
||||
Where we can find the build output
|
||||
How it prepares it for uploading to S3 output bucket.
|
||||
Basically Zips that go to S3, or ECR images, anything else that SDK can touch.
|
||||
|
||||
## Use Cases
|
||||
- Generating static pages to host on S3.
|
||||
- Run test code & report test coverage. For example, a developer needs to ensure their code passes all tests before being allowed to make/merge a PR.
|
||||
@@ -1,11 +0,0 @@
|
||||
# CodeCommit
|
||||
A fully-managed source control service that hosts secure Git-based repositories. (GitHub for AWS)
|
||||
|
||||
## Special features
|
||||
- In scope with many compliance programs (HIPPA)
|
||||
- Repositories encrypted at rest & in transit
|
||||
- Can handle repositories with large numbers of files or branches, large file sizes and lengthy revision histories.
|
||||
- No limit on the size of your repositories or on the file types you can store.
|
||||
- Keeps your repositories close to your production resources in AWS Cloud, which helps to increase the speed and frequency of your development life-cycle.
|
||||
- Uses IAM to control which AWS users have access to which repositories.
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
# CodeDeploy
|
||||
- A fully managed deploy service in the cloud.
|
||||
- Can deploy EC2, On-Prem, Lambda, or ECS.
|
||||
- Rapidly release new features.
|
||||
- Update AWS Lambda function versions.
|
||||
- Avoid downtime during application deployments.
|
||||
- Integrates with existing CI/CD tools eg. Jenkins, [[_CodePipeline|CodePipeline]].
|
||||
- Integrates with existing management tools eg. Puppet, Chef, Ansible.
|
||||
|
||||
## Core Components
|
||||
### Application
|
||||
The unique identifier for the application being deployed. Ensures the correct combination of revision deployment configuration, and group are referenced during deployment.
|
||||
|
||||
### Deployment Groups
|
||||
A set of EC2 instances or Lambda Functions where the new revision is deployed to
|
||||
|
||||
### Deployment
|
||||
This is the process and components used to apply a new application revision.
|
||||
|
||||
### Deployment Configuration
|
||||
A set of deployment rules used during deployment - with success/failure conditions included
|
||||
|
||||
### AppSpec File
|
||||
Contains the deployment actions that CodeDeploy should execute during deployment.
|
||||
|
||||
### Revision
|
||||
This is everything required to deploy a new version: AppSpec file, application files, configuration files, executables.
|
||||
|
||||
## Deployments
|
||||
### In-Place
|
||||
- The app on each instance in the deployment group is **stopped**.
|
||||
- The latest app revision is installed, and the new version of the application is started and validated.
|
||||
- You can use a **load balancer** so that each instance is unregistered during its deployment and then restored to service after the deployment is complete.
|
||||
- ==Only deployments that use the EC2/On-Premises compute platform can use in-place deployments.==
|
||||
|
||||
### Blue/Green
|
||||
- Instances are provisioned for the replacement environment.
|
||||
- The latest application version is installed on the replacement instances
|
||||
- An optional wait time occurs for activities such as application testing and system verification.
|
||||
- Instances in the replacement environment are registered with an ELB, causing traffic to be rerouted to them.
|
||||
- Instances in the original environment are unregistered and can be terminated or kept running for other uses.
|
||||
|
||||
Reference in new issue
Block a user