Continuous Integration (CI) is a methodology for automating software build, packaging, and testing in a consistent way. CI helps development teams gain some degree of confidence that the changes they check into source code version control won’t break the build or introduce bugs into the software. The endpoint of a CI is usually a check-in to the main branch of a software repository.
Continuous Delivery (CD) automates the process of delivering tested software to an infrastructure environment. Of course, that doesn’t mean throwing it right into production and seeing if customers complain. Typically, an organization pushes a build to a development environment first. As developers themselves look at and release new builds, the next step is usually to the test environment. In a test environment, it is used by a wider group of users (which may consist of dedicated internal testers, possibly even a group of users enrolled in beta testing or dog-fooding) and closely monitored. If there are no problems, finally the testers approve the new version and send it to production.
Each step on the CD has the option to quickly revert to a previous build and generate a bug report ticket for developers to address in the new build. The goal is not to push a large number of builds into production, but to continuously improve and improve the software without regression. Another term for this approach is “devops.”
Why Host CI/CD in the CloudHosting a CI/CD platform in their own data center is an available option, especially for companies that mandate hosting applications and data inside firewalls. The disadvantage of this case is that a dedicated team to maintain the infrastructure is required and a certain amount of equipment investment for the server occurs.
If you can host in the cloud, that’s usually better. The cost of hosting in the cloud is modest, and operating costs are offset by the services provided (onboarding, infrastructure maintenance, security maintenance, support, CI/CD software maintenance). If the CI/CD software is hosted in the cloud and the source code repository is also hosted in the cloud, interacting with the source code repository in the pipeline is easier and faster. When developers and testers are geographically dispersed, hosting the repository in the cloud can provide a seamless experience for developers compared to hosting it on a remote server behind a firewall.
It is also possible to deploy CI/CD on a hybrid of on-premises and cloud servers. Many modern CI/CDs run in containers on Kubernetes clusters, and run equally seamlessly on-premises and in the cloud. In a hybrid deployment scenario, each component can be placed where it makes the most sense: the developer’s own physical location and the network location of other servers in the development infrastructure.
CI/CD and repository integrationAs previously emphasized, “The endpoint of a CI is usually a completed check-in to the main branch of a software repository,” repositories are essential for CIs and CDs. Software repositories are also the endpoints of the check-in and test processes, but they are also popular for storing CI and CD scripts and configuration files. Of course, many CI/CD platforms can store scripts and other files internally, but it’s usually better to put them in version control outside of the tool.
Almost all CI/CD tools are interoperable with Git. Some integrate directly with GitHub, GitHub Enterprise, GitLab or Bitbucket. There are also a handful of tools that support Subversion and Mercurial.
CI/CD tools must support current programming languages and toolsEach programming language or language group (JVM language, LLVM compiled language, .NET language, etc.) usually has its own build tools and test tools. For a CI/CD tool to be useful, it must support all languages belonging to the project. If not, you may need to create one or more plugins for your tool.
Docker images are becoming increasingly important in distributed modular and microservices software distribution. It is helpful for CI/CD tools to know how to handle Docker images, such as creating images from source code, binaries, prerequisites, and deploying images to specific environments. Similarly, without this feature, you may have to write your own plugins or scripts to implement the necessary docker features. It is better if your CI/CD tool supports Kubernetes and other container orchestration systems you are using in your environment.
Do developers understand the CI/CD and tools currently under consideration?The principles of CI and CD are clear, but the details are not. There are many different CI/CD tools, each with different levels of support and documentation. There are several books on Jenkins, which is not surprising given that Jenkins is the oldest tool. For other products, you should look through the documentation, support forums, and paid support options during the selection process.
Different CI/CD tools can be selected for each project
Although the topic of this guide is choosing a CI/CD platform, one should not expect that one platform will be optimal for all software development projects. Most enterprises use multiple programming languages and environments, and not all CI/CD platforms support all languages and environments in use.
Source: ITWorld Korea by www.itworld.co.kr.
*The article has been translated based on the content of ITWorld Korea by www.itworld.co.kr. If there is any problem regarding the content, copyright, please leave a report below the article. We will try to process as quickly as possible to protect the rights of the author. Thank you very much!
*We just want readers to access information more quickly and easily with other multilingual content, instead of information only available in a certain language.
*We always respect the copyright of the content of the author and always include the original link of the source article.If the author disagrees, just leave the report below the article, the article will be edited or deleted at the request of the author. Thanks very much! Best regards!