Kanji
・ Cloud engineer / freelance ・ Born in 1993 ・ Born in Ehime Prefecture / Lives in Shibuya-ku, Tokyo ・ AWS history 5 years Profile details
Table of Contents
According to the official user guide, AWS CodePipeline is defined as follows:
AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your software. You can quickly model and configure the different stages of a software release process. CodePipeline automates the steps required to release your software changes continuously. Source: What is AWS CodePipeline? - AWS CodePipeline
AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your software. You can quickly model and configure the different stages of a software release process. CodePipeline automates the steps required to release your software changes continuously.
Source: What is AWS CodePipeline? - AWS CodePipeline
According to the official user guide, AWS CodeCommit is defined as follows:
AWS CodeCommit is a version control service hosted by Amazon Web Services that you can use to privately store and manage assets (such as documents, source code, and binary files) in the cloud. Source: What is AWS CodeCommit? - AWS CodeCommit
AWS CodeCommit is a version control service hosted by Amazon Web Services that you can use to privately store and manage assets (such as documents, source code, and binary files) in the cloud.
Source: What is AWS CodeCommit? - AWS CodeCommit
According to the official user guide, AWS CodeBuild is defined as follows:
AWS CodeBuild is a fully managed build service in the cloud. CodeBuild compiles your source code, runs unit tests, and produces artifacts that are ready to deploy. CodeBuild eliminates the need to provision, manage, and scale your own build servers. It provides prepackaged build environments for popular programming languages and build tools such as Apache Maven, Gradle, and more. You can also customize build environments in CodeBuild to use your own build tools. CodeBuild scales automatically to meet peak build requests. Source: What is AWS CodeBuild? - AWS CodeBuild
AWS CodeBuild is a fully managed build service in the cloud. CodeBuild compiles your source code, runs unit tests, and produces artifacts that are ready to deploy. CodeBuild eliminates the need to provision, manage, and scale your own build servers. It provides prepackaged build environments for popular programming languages and build tools such as Apache Maven, Gradle, and more. You can also customize build environments in CodeBuild to use your own build tools. CodeBuild scales automatically to meet peak build requests.
Source: What is AWS CodeBuild? - AWS CodeBuild
According to the official user guide, AWS CodeDeploy is defined as follows:
CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, serverless Lambda functions, or Amazon ECS services. You can deploy a nearly unlimited variety of application content, including: Code Serverless AWS Lambda functions Web and configuration files Executables Packages Scripts Multimedia files Source: What is CodeDeploy? - AWS CodeDeploy
CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, serverless Lambda functions, or Amazon ECS services.
You can deploy a nearly unlimited variety of application content, including:
Source: What is CodeDeploy? - AWS CodeDeploy
According to the official website, GitHub is defined as follows:
GitHub is a development platform inspired by the ideas of its users. By hosting source code on GitHub, from open source projects to business use, you can review code with millions of other developers, manage projects, and develop software together. Source: GitHub Japan | GitHub
GitHub is a development platform inspired by the ideas of its users. By hosting source code on GitHub, from open source projects to business use, you can review code with millions of other developers, manage projects, and develop software together.
Source: GitHub Japan | GitHub
Candidates for resources managed by the CI/CD pipeline include application source code, infrastructure as code (IaC), and configuration files required for building and deploying applications. Applications and infrastructure deployed using these resources must be managed as code through the CI/CD pipeline not only during development but also during operations. Consider whether the resources managed by the CI/CD pipeline can be managed as code, taking into account the skills and operations of developers and operators. For example, consider excluding the following cases from CI/CD pipeline management:
Code resources managed by the CI/CD pipeline are managed in repository services such as AWS CodeCommit or GitHub. AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy are services provided by AWS, and if there is no existing repository service for managing code resources, AWS CodeCommit will be the first candidate. However, as shown below, AWS CodeCommit will stop accepting new customers as of July 25, 2024.
After careful consideration, we have decided to stop accepting new customers for AWS CodeCommit as of July 25, 2024. Existing customers using AWS CodeCommit can continue to use the service as usual. AWS will continue to invest in the security, availability, and performance of AWS CodeCommit, but there are no plans to introduce new features. Source (Japanese translation): How to migrate your AWS CodeCommit repository to another Git provider | AWS DevOps & Developer Productivity Blog
After careful consideration, we have decided to stop accepting new customers for AWS CodeCommit as of July 25, 2024. Existing customers using AWS CodeCommit can continue to use the service as usual. AWS will continue to invest in the security, availability, and performance of AWS CodeCommit, but there are no plans to introduce new features.
Source (Japanese translation): How to migrate your AWS CodeCommit repository to another Git provider | AWS DevOps & Developer Productivity Blog
It is unclear when AWS CodeCommit will become unavailable in the future, so if you are not already using AWS CodeCommit, it is recommended to manage your code resources with another repository service. Compared to databases, the migration difficulty is not that high, but once you start using a service, it can be difficult to migrate to another. Carefully select a service considering internal rules, available features, security requirements, and future prospects.
There are cases where the same code is deployed to multiple environments or resources using the CI/CD pipeline, such as:
To address these, the following methods are available:
Each method is explained below.
If you adopt a branch strategy such as GitHub Flow or git-flow, you can use different branches for multiple environments such as development, staging, and production. For example, you can use the main branch for production, the develop branch for staging, and feature branches for development. In this case, you can run the CI/CD pipeline triggered by updates to each branch and deploy to each environment. Since feature branches can be freely named and used by developers, dynamic execution of the CI/CD pipeline is required. For example, AWS Prescriptive Guidance introduces the following pattern:
Automate dynamic pipeline management for deploying hotfix solutions to a Gitflow environment using AWS Service Catalog and AWS CodePipeline - AWS Prescriptive Guidance
The advantage is that by checking the contents of a branch, you can easily see which code is deployed to which environment.
The disadvantage is that as the number of branches increases, the number of CI/CD pipelines also increases, making management more complex. Also, since branch flows tend to become complicated, branch management can be difficult for developers with low Git proficiency.
This method uses a single branch to deploy to multiple environments or resources. For example, when the main branch is updated, the same code can be deployed all at once to the development, staging, and production environments.
The advantage is that the number of branches is reduced, making CI/CD pipeline management easier.
The disadvantage is that since the same code is deployed to all environments at once, it is difficult to perform staged deployments, such as deploying to the development environment for testing before deploying to staging and production.
It is recommended to use this method when deploying infrastructure resources such as security or monitoring services, rather than application resources.
This method uses manual jobs to reuse build/deployment artifacts and deploy to multiple environments or resources. For example, you can reuse the build artifacts of an application deployed to the development environment and deploy them to the staging or production environments. In this method, you can deploy to the required environments or resources by manually running jobs after the CI/CD pipeline has been executed.
The advantage is that you can deploy the same code to multiple environments or resources by reusing build/deployment artifacts. Also, you only need to prepare as many CI/CD pipelines as you need to run jobs simultaneously, so you can reduce the number of CI/CD pipelines.
The disadvantage is that after running the CI/CD pipeline and generating build/deployment artifacts, you need to manually run jobs, which may increase the amount of work required for staged deployments.
Depending on how much you build out the CI/CD pipeline mechanism, you can construct a highly versatile CI/CD pipeline.
The main tools used to manage resources in the CI/CD pipeline are as follows:
Using these deployment and build/static analysis tools, you can deploy, build, and perform static analysis on resources managed by the CI/CD pipeline.
Note: Just because these tools automate build/deployment processes does not mean you do not need to learn the tools. By establishing procedures for changing parameter files during operations, you can reduce the learning cost of the tools, but during development, you will need to learn the tools because you may need to build/deploy in your own environment for troubleshooting, not just through the CI/CD pipeline. Select the tools to use in the CI/CD pipeline, taking into account the skill sets of developers and operational requirements.
Once the tools are decided, consider the steps of the CI/CD pipeline.
How to consider the steps is under preparation.
Once the tools to be used in the CI/CD pipeline are decided, determine the resources managed by those tools, their administrators, and deployment destinations. For example, if you use AWS CLI (CloudFormation) to deploy AWS resources, organize as follows:
When organizing, it is important to clarify which team manages which resources and where they are deployed. For each managed resource, consider which repository will manage it in the next section, “4. Repository Segmentation Units.”
Consider how to segment the resources managed by the CI/CD pipeline into code repositories. Segmentation perspectives include the following:
Basically, by segmenting by “1. Function,” you can also segment by “2. Administrator” and “4. Lifecycle” at the same time. If necessary, consider further subdividing “4. Lifecycle” within “1. Function.” For example, when segmenting Network Firewall, by dividing resources into those deployed only during initial construction and those deployed during operations, you can avoid the risk of the firewall itself being deleted. Here, organize the “managed resources” in more detail.
For “3. Deployment destination,” consider how to segment based on the results of “1. How to deploy to multiple environments/resources” discussed earlier. For example, for GuardDuty, you can segment by shared account and each environment account as follows:
When building a CI/CD pipeline for each segmented code repository, set permissions for each CI/CD pipeline. First, organize which permissions cannot be granted for each administrator, and then consider further restricting permissions. For example, if there are three teams: platform team, development team, and operations team, you can set permissions as follows:
It is important not to restrict CI/CD pipeline permissions too finely. If you restrict permissions too much, the CI/CD pipeline may lack the permissions necessary to run, causing deployments to fail. Also, since you can restrict the execution of the CI/CD pipeline itself using pull requests or approval phases, it is not recommended to strictly restrict permissions as a countermeasure against internal fraud. If you do restrict, it is recommended to use the following AWS managed policies to grant the necessary permissions.
AWS Managed Policies - AWS Managed Policies