Developing a software is a tedious task if you paint the big picture. Developers code and push the changes to the repository and pray that their codes work out. Let’s say it works in your local system and maybe from the repository too. What if the other developers push their code to the repo and this time it doesn’t work out due to conflict may it be inter-modular or so and so. Seems like the end of the world, ain’t it? But it actually isn’t. Utilizing a test driven development  and using a continuous integration server becomes a lifesaver for the whole project team.  Also, after the clean build one can deploy directly if they want to. So, to put in a nutshell the whole process is: All the developers commit the code on github or gitlab and Circle CI will pass or fail the test and then the app pushed is dockerized and then deployed.
THE FLOW!
I am not going to explain here about the contuinuous integration and deployment as it is already described in the previous post related to TeamCity and Octopus deployment, thanks to Prajjwal Maharjan for lifting me off of this burden. So, let’s talk about the flow.
The above picture displays the overall flow of the continuous integration and deployment. let me break it down describing each component and roles of each.
The project
First of all comes the project where we have code, folders, images and other resources. Â The project is pushed to the repo and committed after changes.
GitHub/GitLab
We have to link the repo to Circle CI and Docker for automated integration and deployment.
I myself prefer Git than svn as it’s already old and the linking between Circle CI and Docker, etc. has been dominant and svn is not. So, one can setup GitLab and assign multiple git accounts to the developers and push the code to the common repo and work. And, my friend Abhishek here at Javra has already utilized GitLab so we can work with Git and  utilize a CI/CD system.
Circle CI
Circler CI bills itself as an all-in-one build management, testing and deployment solution for mobile and web. CircleCI is intimately tied to Git. We create an account by logging in with Git, and builds are all tied to your Git commits. If our workflow is built around Git, then this is all incredibly simple and convenient. It also supports an array of secondary technology and service integrations, to hook into our toolchain and workflow, including chat and email, analytics, and deployment services. CircleCI automatically infers the settings from your code to get our team building faster. We can also setup a project manually or add a circle.yml file to customize our workflow.
Circle CI is based on the idea of containers, which are currently Docker containers. Builds can be parallelized across containers, allowing simultaneous builds, or a single build conducted in parallel. Each time we push code to one of the git repos we’ve added to your CircleCI account, a build is triggered. So if our team push multiple commits in quick succession, builds will be queued up when we run out of available containers. With the basic service, which allows us to have unlimited users and projects/repositories, we get a single container for free. Additional containers are $50 per month.
So, we have to link the repo to the circle CI account and after each commit the build will be triggered and we can get the status of success or failure, you are thinking green and red right? Yes, that’s correct! And, we can deploy if the green light’s on or what if we automate the build too so there comes continuous deployment.
For more information about Circle CI the link’s here
Docker
Docker allows us to package an application with all of its dependencies into a standardized unit for software development. Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything we can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
Containers isolate applications from each other and the underlying infrastructure while providing an added layer of protection for the application. Basically we create a Dockerfile that will package the source and create a container so that there is no need of VM or setup required for deployment machine. It’s so awesome that setup code are built into that dockerfile. The docker build will be triggered from the success status from the Circle CI and that particular repo will be linked and then the system for deployment will be ready. And, here we call the application as “a dockerized application”.
For more information about Docker; the link’s here and here.
Now after all this, one can deploy in cloud using Tutum or one can deploy as one wants. All the environment has been setup for automated integration and deployment. So, the magic here is; no headache from the words we hear “It worked locally, but not in the production; hmm…”
A shorter version of this article can be found here on Google Docs.