What is Continuous Integration or CI?
Continuous integration (CI) is a workflow to integrate code changes by developers into the main branch. This Includes automated testing and artifact creation.
What are the various steps involved in a typical CI process?
- Start with the source code
- Run some checks
- Build the artifacts and store in some registries
- Run some tests on artifacts
- Merge the code in the main branch
What is Continuous Delivery or CD?
Continuous delivery (CD) is, Continuous integration (CI) + automatic deployment of artifacts to testing and staging environments and manual deployment to production environment.
What are the various steps involved in a typical CD process?
- Start with artifacts
- Automatic deployment to testing and staging environments
- Manual deployment to production environments
What is an environment?
A cloud native environment is a standalone version of an application + infrastructure. Environment details are usually captured in a template that completely describes all the application and infrastructure resources. These templates are used to quickly create working replica application environments running in an isolation for specific purposes, and they can also be quickly destroyed automatically - which allows for quicker iterations on the latest code.
Environments can be permanent or short-lived “on demand” (ephemeral) environments. These ephemeral environments represent a version of the application that is still under development, and has not been released to customers. Setting up custom environments on demand is extremely valuable to many personas:
- developers for iterating on code fixes or features
- devops for configuring new infrastructure to support the application
- qa for ensuring correct behavior of new code before it is released
- enablement for onboarding new team members quickly with the latest feature code
- sales for demonstrating the product features to customers in an isolated way
- etc.
What is the main challenge managing environments?
If the environments are not production-like or if they are partial, simplified versions of the production environment; meaning not all the components, services, and cloud resources (this is true for modern cloud-native or cloud-first applications) are configured - issues arise.This leads to configuration and code drift, test failures, code rework, and ultimately increasing the release time and reduced developer productivity.
What is an environment as a service?
Environment as a service is a new engineering approach that allows you to create on-demand production-like environments in the cloud for the full software development life cycle. EaaS allows you to shift left and test before merge, connect to the environment using remote development, as opposed to running a local docker, give developers realistic environments to develop and test their code so that pushing the code to dev and staging become a breeze.
What is the difference between CI/CD and environments?
- CI/CD tools are not responsible for creating or managing environments.
- Environment management includes ingres ruling, mapping between database instances, infrastructure and microservices, exposing endpoints and maintaining persistency between infrastructure and code, all of which are outside of the scope of CI/CD tools
- Environments are created and maintained outside the CI/CD tool.
- CI/CD tools rely on existing environments to test the code changes.
- Usually CI/CD make use of testing, staging, and production environments.
- CI/CD tools such as Jenkins, GitHub Actions, Gitlab Pipelines are great for defining the steps and workflows code should go through from commit to production (including testing, building, and code reviews)
In summary, environment management and Environment-as-a-Service (EaaS) is complimentary to CI/CD and can make your release process significantly shorter.
Enter Bunnyshell
Bunnyshell is an environment as a service platform which focuses on provisioning and managing environments. Environments are first class citizens of Bunnyshell.
With Bunnyshell developers can define production-like environment blueprints, and then Bunnyshell provisions and manages the environments as needed. On-demand environments can be created with just a few clicks, or automatically using API calls or webhooks.
Bunnyshell environments may be as complex as needed, can include cloud infrastructure created with Terraform, can include codebases from multiple repos, and even Helm charts resources.
![[object Object]](https://images.prismic.io/bunnyshell-blog/598b54cd-f317-4b70-a6f5-5bfa0e84eddd_Icon%20White%20on%20Blue.png?ixlib=gatsbyFP&auto=compress%2Cformat&fit=max)
CI/CD + Bunnyshell
Automate Your CI/CD Testing Pipeline with Bunnyshell
On-demand environments with just a few clicks, or automatically using API calls or webhooks
Pipelines and Trees
CI/CD Pipelines
The workflows defined by CI/CD tools look like a pipeline. All code changes wait for their turn to go through a series of environments, from testing to production. Here are typical steps in this pipeline
- Build & Unit Test Build Binaries
- Pre-Bake Staging Environment
- Test:Integration & Quality
- Test:functional
- Test:Load & Security
- Approval
- Deploy:Prod
Each environment can host only one version of the code at any point in time. So environments are a bottleneck for CI/CD pipelines. And the bigger the team, the bigger the bottleneck.
Environment as a service
On the other hand, in an environment as a service (EaaS) the workflow looks like a tree. That means environments can be dynamically added/removed. Like nodes / leaves on a tree. Like commits on a git tree.
Each code change can have its own environment and there is no need to wait for one to become available. So no bottleneck.
CI/CD + Environment as a service = Match Made in Heaven
It is clear that CI/CD tools are great for standardizing workflows but they are dependent on environments. On the other hand, creating environments and letting them “hang around” is a waste of time, resources, and money.
Put CI/CD and environment as a service together and you have very powerful workflows without any bottlenecks.
Now the question arises, how to use this combination in practice?
CI/CD and Environment as a service use cases
The obvious use case here is automated testing.
Environment as a service handles creation of new environments for every code change and CI/CD pipeline runs tests on these environments. There are 2 ways to achieve this.
- The CI/CD pipeline uses API for an environment as a service (Bunnyshell API) to trigger the creation of a new environment, waits for the environment to be available, and runs the tests
- Make use of the automatic "ephemeral environments' feature in environment as a service (Bunnyshell). On every pull request environment as a service (Bunnyshell) (triggered by git webhooks) automatically creates a new environment, builds and deploys to it. The CI/CD waits for the env to be ready and then runs tests against it, rejects or accepts the pull request.
‘Ephemeral environments’, sometimes also called dynamic environments, temporary environments, short-lived or on-demand environments spin up for the purpose of testing and spin down after a successful test. You can learn more about ephemeral environments here.
In addition to above use case, CI/CD and environment as a service (Bunnyshell) makes a few new ideas possible
- Preview environments: Use the ephemeral environment created for each pull request to share & demo changes or accelerate manual QA
- Hybrid local/remote development: Run most of the apps and infrastructure in your environment in the cloud, but run some locally, to develop and debug.
Benefits of CI/CD and environment as a service
- Speed: As all of the testing stages can be run in parallel, a lot of valuable time is saved which increases the overall speed.
- Consistency: All the environments are consistent and production-like as they are created from a predefined blueprint and as such; there are no false positives or negatives, testing is always done with exact same artifacts, testing is done with installation/deployment scripts of the application.
- Automation: All manual work is avoided which eliminates the errors, additional time and resources.
Conclusion
- CI/CD tools are great at defining automated pipelines, but can have environment related bottlenecks.
- Bunnyshell creates and manages a tree of consistent production-like on-demand environments.
- Put them together and you get great automated pipelines that can run in parallel, with no environment related bottlenecks.
- You also get preview environments and hybrid local/remote development..