4 Steps to Get Started with Boomi CI/CD
Boomi is an incredible tool; it has a lot of different components used to meet different needs. However, as with many IPaaS solutions, it does not necessarily lend itself to a large-scale CI/CD environment. That said, CI/CD is a core practice in many businesses large and small, so going out of your way to add a bit of that functionality can be advantageous from both a cost and time perspective for your organization.
What is CI/CD?
As mentioned, CI/CD refers to continuous integration and continuous deployment (although some use the “d” to stand for delivery). The critical part, as we’ll see, is the word “continuous.” To understand the whole, let’s look at the pieces.
Continuous Integration (CI) - this is the process that allows developers to integrate and check-in new code frequently, at least once a day but more often for some groups or organizations.
Continuous Deployment (CD) - the regular and frequent deployment of the integrated code.
The comparison to the traditional SDLC is striking. In a conventional SDLC, developers would write a lot of code, integrate it into the existing solution, and promote it across the environments in large chunks, passing through QA, UAT, and so forth. When issues are found - sometimes not until the entire solution is already in production - troubleshooting the source of issues can take considerable time because there may be weeks or months of code and components to comb through.
With CI/CD, though, changes and deployments are small and frequent, from weekly or bi-weekly down to daily. There isn’t a single Big Bang release that pulls together independently developed components at the last minute. Instead, code is constantly tested as it’s integrated into the solution. Problems are easier to spot with the micro-changes, and risk is massively reduced.
This can be incredibly impactful for APIs because there are so many touchpoints across your solutions. Scope is reduced, so tracking down an issue is quick and less painful than with large deployments, stabilizing your solutions and minimizing tickets and rollbacks.
The Stages of CI/CD
If CI/CD doesn’t look like a traditional SDLC process, what are the stages of CI/CD?
Stage 1: Development - new features and functionality are created
Stage 2: Code Check-in - Code is checked in frequently, at most daily, but for some dev groups or solutions, check-ins could occur multiple times a day.
Stage 3: Code Validation - not testing, validation. This stage ensures your environments’ best practices, naming standards, and conventions are being followed.
Stage 4: Deployment to QA - The keyword again is continuous; deployment to QA happens all the time, no waiting, no delays. This allows for the earlier detection of errors or conflicts.
Stage 5: Deployments to Higher Environments - Deployments to pre-prod, Prod, UAT, and Performance environments happen frequently, as well, although the frequency of these deployments is driven by the maturity of and trust in your process.
Some organizations only use their CI/CD pipeline to get them to a near prod environment, preferring a more manual process to get it the rest of the way to production. Others use CI/CD to push deployments all the way through.
How Do I Know My Shop is Ready for CI/CD?
If this is sounding better and better, there is more good news - the requirements for entry to CI/CD on Boomi are pretty light, and you may already have a few of them under your belt.
Your shop is ready for CI/CD if:
- You’ve had at least a year with Boomi to have learned the platform
- You have multiple teams and multiple projects
- You have one team or project, and you’re ready to scale up to more.
4 Steps to Get Started with Boomi CI/CD
The first step is to define and identify a build engineer. The build engineer is the person that will be responsible for the definition and success of your process.
Next, start to define the lifecycle stages and gates. What are the rules you’ll need to enforce to pass a gate? What are the standards that will be enforced? What are the code validation steps?
Next, you’ll define the roles beyond the build engineer. Who is the development community? Who are the testers, and who are the approvers?
Choosing tools will be your last step. Your tools should meet your process, not the other way around.
Code Validation: Sonarqube, custom build code validation, etc.
The best advice we can offer is to start small. Define the most straightforward path to deployment first, and then implement that. For instance, start by automating the first part of your process - checking in code. Once that is in good shape, iteratively add more use cases. If you’re moving through the stages, add automation for post-check-in code validation next.
However, it will be challenging to be successful without good communication and training. Ensure your teams are aligned on using the new automated process and provide training resources, video, documentation, and tutorials to help get everyone on the same page.
What Are We Solving, and When?
Implementing the processes sequentially will gain you the benefits around improved code quality and versioning first. Then, as you progress through the stages, your challenges with each of those stages will get resolved as a matter of course, earning you a host of benefits:
- Increased code coverage
- Better test quality
- Shorter test duration
- Removed risk of deploying the wrong version
- Reduced deployment times
- Elimination of deploying untested code.
Your Boomi platform has moved the business forward, unlocked siloed data, creating operational improvements, and increasing revenue opportunities. The next phase in maturing your integration development process is adding CI/CD. The end-to-end benefits of continuous integration and deployment of new features and functionality are worth the upfront planning costs to get it in place.
Stay tuned to our blog to learn more about how this process works with Boomi. In the meantime, if you have questions about improving your code quality or streamlining organizational needs, contact Big Compass to discuss how we can help.