So what is CICD?
So first, CICD is about continuous integration, and that means that the developers are going to push the code very often into a central code repository.
And so that could be GitHub, which is a third party service from AWS, or CodeCommit which is Ed’s AWS service or Bitbucket which is also a third party service. So developers push the code to code repo and then there’s going to be a test or build server that will check if the code is correct and working as soon as it’s pushed into the code repository. So this could be CodeBuild, if it’s AWS or Jenkins if you want an open source tool, for example.
Continuous Integration (CI)
So the build server is going to fetch a code and test it and then as a developer, we’re going to get feedback as to whether or not the test or checks will have passed or failed. And so we get the build and test results, but we’ve saved time.
So with this, we find bug early and we fix them early, because we are testing the code as soon as it is pushed in a code repository. So the developer doesn’t need to test the code on their machine.
They can just push the code and wait for the build server to do it while they do some other tasks. Therefore, the code is going to be delivered faster, because it’s going to be tested.
Thanks for this we’re gonna be able to deploy often, because as soon as it’s tested and ready, we can deploy it. And then happier developers, because developers have a healthier cycle for development.
So we saw CI and now there is CD. it could be continuous delivery, for example. And so let’s give you this example.
So here we have application servers of version one, and we want our code as a developer to be pushed all the way to these application servers.
So the way we do it is that we use continued delivery. Anytime we push the code onto the code repo, it’s going to be deployed if it’s tested appropriately onto our application servers. So the developer pushes the code, the code is going to be tested by the build server. So this is the continuous integration part. And then after the build is passed, so it is green, so it’s fully tested, then there’s going to be a deployment server.
And this deployment server is going to deploy our application onto our application servers. So version one at first. But then if we push again a new version of our code into our code repo, then we’re going to have application server version two.
So with continuous delivery, we ensure that deployments happen often and then they’re very quick and we shift away from a mentality of let’s do one release every three months, which is very long to do, you know, error prone, because it doesn’t happen very often to let’s automate you know, up to five releases a day.
Because every time we push the code into the code repo, the code is going to be live onto some application servers. So to do continuous delivery, we need automated deployment tools such as CodeDeploy, which is an AWS service or Jenkins CD or Spinnaker or other tools.
So if you look at the tech stack for CICD on AWS, we have the code and the code can live in CodeCommit or GitHub or Bitbucket or any third party code repository. Then we have build phase, the build phase and the test phase could be done by CodeBuild on AWS, but there’s a competitor to CodeBuild, which is open source called Jenkins CI or any third party CI server will do as well.
Then we’ll go to the deploy phase, then we can use CodeDeploy, and CodeDeploy will seek and deploy to EC2 instances, on-premises servers Lambda functions, and ECS. Or if you wanted to also provision the infrastructure, we could use Elastic Beanstalk as an alternative to CodeDeploy to do the deployment and the provision of the infrastructure. And then to orchestrate all these things to define exactly what happens in our CICD process, then we can orchestrate everything using AWS CodePipeline. So that’s it for an overview of CICD.
