{"id":3649,"date":"2019-01-08T00:59:56","date_gmt":"2019-01-08T06:59:56","guid":{"rendered":"https:\/\/www.supportpro.com\/blog\/?p=3649"},"modified":"2019-10-30T02:21:32","modified_gmt":"2019-10-30T08:21:32","slug":"ci-cd","status":"publish","type":"post","link":"https:\/\/www.supportpro.com\/blog\/ci-cd\/","title":{"rendered":"CI\/CD (Continuous Integration \/ Continuous Deployment)"},"content":{"rendered":"

\"DevOps<\/a><\/p>\n

Continuous Integration (CI) and Continuous Deployment (CD) defines\u00a0a culture, a set of operating\/manipulating principles, and collection of practices that allow application development teams to deliver code changes more regularly and in an accurate way.<\/span><\/p>\n

<\/p>\n

Execution is also known as the CI\/CD pipeline and is one of the best practices for DevOps teams to implement.<\/span><\/p>\n

CI is a concept, which has been taken as a standard or a parameter nowadays, within our IT services and development.<\/span><\/p>\n

The concept of continuous integration means automating the overall deployment process for an application after a code has been committed so as to identify and address the pain points before they become serious issues. So each time a product code is developed, it goes through an automatic CI process.<\/span><\/p>\n

There are several tools for Continuous Integration to help trigger these builds and tests.<\/span><\/p>\n

\"Continuous<\/a><\/p>\n

Continuous Integration is a software development practice where members of a team integrate their work frequently.\u00a0 Usually, each person integrates at least daily – leading to multiple integrations per day.<\/span><\/p>\n

Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.<\/span><\/p>\n

CI is a coding process and set of practices that operate development teams to implement small changes and check in code to version control repositories regularly. Since most new applications require developing code in different platforms and tools, the team needs a mechanism to integrate and check its changes.<\/span><\/p>\n

Developers practicing CI merge their changes back to the main branch as often as achieved. Developer’s changes are checked by creating a build and running automated tests against the build. So we avoid the integration hell that usually happens when people wait for release day to combine their changes into the release branch.<\/span><\/p>\n

CI is a widely established development practice in the software development industry, in which members of a team integrate and merge development work (e.g., code) frequently, for example, multiple times per day.<\/span><\/p>\n

CI enables software companies to have shorter and frequent release cycle, improve software quality, and increase their team’s productivity. This practice includes automated software building and testing.<\/span><\/p>\n

\"CI<\/a><\/p>\n

Continuous DElivery (CDE) is aimed at ensuring an application is always at production – ready state after successfully passing automated tests and quality checks.<\/span><\/p>\n

CDE employs a set of practices e.g., CI, and deployment automation to deliver software automatically to a production-like environment.
\nAccording to, this practice offers several benefits such as reduced deployment risk, lower costs and getting user feedback faster.<\/span><\/p>\n

\"CDE<\/a><\/p>\n

The figure indicates that having continuous delivery practice requires continuous integration practice.<\/span><\/p>\n

Continuous Deployment (CD) practice goes a step further and automatically and continuously deploys the application to production or customer environments.<\/span><\/p>\n

There is a robust debate in academic and industrial circles about defining and distinguishing between continuous deployment and continuous delivery. What differentiates continuous deployment from continuous delivery is a production environment (i.e., actual customers): the goal of continuous deployment practice is to automatically and steadily deploy every change into the production environment. It is important to note that CD practice implies CDE practice but the converse is not true.<\/span><\/p>\n

While the final deployment in CDE is a manual step, there should be no manual steps in CD, in which as soon as developers commit a change, the change is deployed to production through a deployment pipeline.<\/span><\/p>\n

CDE practice is a pull-based approach for which a business decides what and when to deploy; CD practice is a push-based approach.
\nIn other words, the scope of CDE does not include frequent and automated release, and CD is consequently a continuation of CDE. But CDE practice can be applied to all types of systems and organizations, CD practice may only be suitable for certain types of organizations or systems.<\/span><\/p>\n

Continuous Integration Practices<\/strong><\/p>\n

We have to have some standard practices to be followed by the starting of the project:<\/span><\/p>\n