Contact
Developing and releasing software can be a complex process, notably as applications, teams, and deployment infrastructure grow in complexity themselves. Challenges often become much more distinct as project expands. To develop, test, and release software in a quick and consistent way, developers and organisations have created three related but distinct strategies to manage and automate these processes. These strategies are referred to as CI/CD. It is hard to find terms getting more attention in the software world in the last few years than the closely related practices of Continuous Integration (CI) and Continuous Delivery or Continuous Deployment (CD), often referred to in tandem as CI/CD. Continuous Integration refers to integrating the work or tasks performed by individual developers into a main repository in order to catch multiple bugs daily and to improve collaboration effectively. Whereas Continuous Deployment is involved in minimising the traction in deployment or release process, automating the steps required to deploy a build so that code can be released safely at any time. Continuous deployment takes this one step further by automatically deploying each time when a change is made to the code.
CI/CD enable teams to develop, test, build and deploy code safely without any bugs. It also improves the code quality. The benefits of Continuous Integration and Continuous Deployment are numerous. However to build the pipeline to implement the whole process of CI/CD is a tedious and expert task. Some of the merits of CI/CD are listed below:
- Integrating CI/CD result in faster software builds and deliver quicker results
- Identification and resolving of bugs is simple and easier.
- Unit testing is performed by the developer while coding hence CI/ CD increases code coverage.
- CI/CD decreases time taken for code review since tools can be used for automated code review
- Back-to-back releases using CD are easy and less time-consuming
- Share visibility of the development process in real-time
Most of the organisations across the world are implementing CI/CD for their software products. Cabot had got a requirement from one of our clients to implement continuous build process in their software product. They have to do an extensive code review on their products. The Continuous build process forms a part of CI/CD.
As a certified AWS Partner, the team Cabot proposed to use the following AWS services to implement continuous build process with extensive code review. Using these services, we were able to implement CI/CD for their software products.
- AWS CodeCommit
- AWS CodeBuild
- AWS CodeDeploy
- AWS Codepipeline
AWS CodeCommit is similar to Git repository. It provides a console for the creation of repositories and branches. Through a few simple steps, developers can find information about a repository and clone it to their computer, creating a local repo where they can make changes and then push them to the CodeCommit repository.
The following steps illustrate how we use our development machine, the AWS CLI or CodeCommit Console and the CodeCommit Service to create and manage repositories:
1. AWS CLI or the CodeCommit console is used to create a CodeCommit repository.
2. We have used Git from our development machine to run git clone specifying the name of the CodeCommit repository. A local repository is created in the machine which is connected to the CodeCommit repository.
3. The local repo on the development machine is used to modify (add, edit, and delete) files, and then git add command is run to stage the modified files locally, then git commit command is run to commit the files locally, and finally git push is run to send the files to the CodeCommit repository.
4. In order to download changes from other users, git pull command is run to synchronize the files in the CodeCommit repository with our local repository. This ensures that developers are working with the latest version of the files.
We can use the AWS CLI or the CodeCommit console to track and manage our repositories.
After pushing the source code to the AWS CodeCommit, it is then built using AWS CodeBuild and the build artifacts are stored in S3 Bucket. To implement Continuous Integration, AWS CodeBuild fetches the latest changes of the source code from AWS CodeCommit or GitHub repository as configured and based on the build specification YAML file (created as buildspec.yml) the commands are run based on the four phases like Install, Pre-build, Build and Post-build. CodeBuild have the provision to provide custom OS images for building application. If we need custom run time, then CodeBuild has the provision to use our own custom Docker image and the output will be stored in S3 bucket. In case of static web pages, code building is not required. Once the build is completed the artifacts (WAR/ZIP/JAR/EAR) are stored in the AWS Storage which is an S3 bucket.
After the completion of build, the application is deployed using AWS Codedeploy. AWS Codedeploy is the deployment service which automates the deployment of the application (in this case WAR file) to the Amazon EC2 Linux or Windows instances, Lambda servers or on - premise instances.
The artifacts completed using AWS CodeBuild is stored in S3 bucket. The artifacts are then picked up from the S3 bucket and deployed appropriately to the app server Tomcat or JBoss etc. in the AWS EC2 instance provisioning.
AWS CodeDeploy depends on a YAML file called appspec.yml which has instructions on the deployment to the EC2 instances.
CI/CD can be implemented in a single step through CodePipeline. CodeCommit, CodeBuild and CodeDeployment can be managed in a centralized environment through AWS CodePipeline. AWS CodePipeline helps to have a visual view of the end to end delivery process. AWS CodePipeline is a continuous delivery service that can be used to model, visualize, and automate the steps required to release our software. We can quickly model and configure the different stages of a software release process. CodePipeline automates the steps required to release your software changes continuously.
Thus in a CodePipeline, we will typically configure the following
Source Code Repository – Source code would need to be either in AWS CodeCommit or GitHub repository.
Build Service – AWS CodeBuild details will be configured as part of the pipeline.
Deploy – AWS CodeDeploy will be configured into the pipeline.
During the deployment to different environments, if any approvals are needed, that could be configured as well
Hence, if there is a code change by the developer the visual representation of Build and Deploy can be automated using CodePipeline.
When developers commit changes to a source repository, CodePipeline automatically detects the changes. Those changes are built, and if any tests are configured, those tests are run. After the tests are complete, the built code is deployed to staging servers for testing. From the staging server, CodePipeline runs additional tests, such as integration or load tests. Upon the successful completion of those tests, and after a manual approval action that was added to the pipeline is approved, CodePipeline deploys the tested and approved code to production instances.
CodePipeline can deploy applications to Amazon EC2 instances by using CodeDeploy, AWS Elastic Beanstalk, or AWS OpsWorks Stacks. CodePipeline can also deploy container-based applications to services by using Amazon ECS. Developers can also use the integration points provided with CodePipeline to plug in other tools or services, including build services, test providers, or other deployment targets or systems.
Using AWS Services, the team Cabot was able to tackle the client requirement. Cabot’s team of dedicated engineers were able to implement continuous build process flow with extensive code review.
Interested in adopting Continuous Integration and Continuous Delivery in your organisation? Allow us to help you!
YOU WILL BE HEARING FROM US SOON!
We look forward to hearing from you!
YOU WILL BE HEARING FROM US SOON!
