In this post, we look at Continuous Integration/Continuous Delivery (CI/CD), what it is, some best practices, and why it is important.
What is the meaning of CI/CD?
It’s a tech process, it’s a mindset, it’s a series of steps… CI/CD is all of those things. To put it simply, CI enables DevOps teams to streamline code development using automation. CI simplifies software builds and source code integration, enables version control, and promotes greater collaboration via automation. Where CI leaves off, continuous delivery kicks in with automated testing and deployment. Not only does CD reduce the amount of “hands on” time ops pros need to spend on delivery and deployment, it also enables teams to drastically reduce the number of tools required to manage the lifecycle.
What is continuous integration (CI)?
Continuous integration is the practice of integrating all your code changes into a branch of a shared source code repository early and often, automatically testing each change when you commit or merge them, and automatically kicking off a build. With continuous integration, errors and security issues can be identified and fixed more easily, and much earlier in the development process.
By merging changes frequently and triggering automatic testing and validation processes, you minimize the possibility of code conflict, even with multiple developers working on the same application. A secondary advantage is that you don't have to wait long for answers and can, if necessary, fix bugs and security issues while the topic is still fresh in your mind.
What is continuous delivery (CD)?
Continuous delivery is a software development practice that, when used in conjunction with CI, automates the infrastructure provisioning and application release process.
Once code has been tested and built as part of the CI process, CD takes over during the final stages to ensure it's packaged with everything it needs to deploy to any environment. CD can cover everything from provisioning the infrastructure to deploying the application to the testing or production environment.
CI/CD fundamentals
There are some fundamental elements of CI/CD that help ensure maximum efficiency for your development lifecycle. They span development and deployment. Include these fundamentals in your pipeline to improve your DevOps workflow and software delivery:
- A single source repository
Source code management (SCM), which houses all necessary files and scripts to create builds, is critical. The repository should contain everything needed for the build, including source code, database structure, libraries, properties files, and version control. It should also contain test scripts and scripts to build applications. - Frequent check-ins to the main branch
Integrate code in your develop, stage or main branch — i.e., trunk-based development or feature-branch workflow — early and often. Use small code segments and push them into the branch frequently. Don't merge more than one change at a time. - Automated builds
Scripts should include everything you need to build from a single command. This includes web server files, database scripts, and application software. The CI processes should automatically package and compile the code into a usable application. - Self-testing builds
CI/CD requires continuous testing. Testing scripts should ensure that the failure of a test results in a failed build. Use static pre-build testing scripts to check code for integrity, quality, and security compliance. Only allow code that passes static tests into the build. - Frequent iterations
Multiple commits to the repository result in fewer places for conflicts to hide. Make small, frequent iterations rather than major changes. Doing this makes it possible to roll changes back easily if there's a problem or conflict. - Stable testing environments
Code should be tested in a cloned version of the production environment. You can't test new code in the live production version. Create a cloned environment that's as close as possible to the real environment. Use rigorous testing scripts to detect and identify bugs that slipped through the initial pre-build testing process. I call this pre-production - or fancier "dry-run environment" - Maximum visibility
Every developer should be able to access the latest executables and see any changes made to the repository. Information in the repository should be visible to all. Use version control to manage handoffs so developers know which is the latest version. Maximum visibility means everyone can monitor progress and identify potential concerns. - Predictable deployments anytime
Deployments should be routine and low-risk, so the team is comfortable doing them anytime. CI/CD testing and verification processes should be rigorous and reliable, giving the team confidence to deploy updates at any time. Frequent deployments incorporating limited changes also pose lower risks and can be easily rolled back.
CI/CD at Appsmith
Often, low-code platforms are treated as separate entities, as SaaS products that can’t be integrated inside a development lifecycle, a CI/CD pipeline, and it makes sense; most of these platforms out there can’t be added to a repository and have automated tests or code verification, are not containerized, are not opensource, leading to disjointed processes and potential bottlenecks.
The beauty of Appsmith is that, yes, is a Low-Code platform to make life easier for developers, but it does not sacrifice control; since it is open source, each Appsmith environment can be containerized, can be isolated, tested, built, and each Appsmith app inside an environment can be put in source code, and be part of any software development lifecycle. That's powerful.
All the fundamentals and best practices we've mentioned in your Appsmith workflow, and this series of articles and videos you'll find next go over these examples so you can implement Appsmith inside your CI/CD workflow!
