How to Automate with CI/CD Pipelines for Connected Microservices

What is CI/CD, and how it boosts software development

CI/CD stands for “Continuous Integration and Continuous Delivery (or Deployment).” This method allows a team to automate building, testing, and deployment to deliver apps to customers frequently and seamlessly. 

• By leveraging continuous integration, you can introduce code changes from multiple developers into one project automatically. It’s the “build-and-test” piece of a puzzle from where you add on both continuous delivery and deployment.
  
  
• In continuous delivery, teams release software in short cycles, adding new features, changing configurations, fixing bugs, and experimenting. The process is automated, repeatable, and thus speedy.
  
  
• Continuous deployment is similar to continuous delivery. However, if the latter still needs a developer to press the button to start the process, the former is completely automated.

In many cases, CI and CD are implemented together as a single CI/CD pipeline. This combined approach helps teams to automate the entire software development and delivery process, from code commit to production deployment.

CI/CD in FinTech: Use cases, pros and cons. 

In the ever-racing world of FinTech, the expectations for new services or updates to existing ones are pressing, with release cycles spinning faster every year. That’s where CI/CD comes into play to help you keep up without sacrificing software quality. Actually, it helps your team achieve so much more.

• In general, CI/CD helps teams accomplish more and do it faster, saving time and reducing the amount of manual work.
  
  
• CI/CD can help implement automated testing and real-time monitoring to detect and fix vulnerabilities early in the development process. This way, you reduce the risk of security breaches and leaks of precious financial data.
  
  
• Use the method to ensure that FinTech software adheres to strict regulatory requirements. Automated compliance checks and reporting can help maintain transparency and minimize the risk of regulatory penalties.
  
  
• Continuous delivery ensures a seamless customer experience with minimal service interruptions.
  
  
• As a FinTech player, your company may encounter surges in user traffic, especially during market volatility. CI/CD allows for automated scaling of resources to meet high demand, securing system reliability.

There are many more applications of CI/CD in FinTech. From cloud migration to mobile app development, through financial algorithms testing and data analysis, CI/CD proves indispensable. 

However, there are a few cons that can make you think twice before switching to CI/CD.

• Implementing this approach requires effort, time, and money. To benefit from automation, first, you need to set it up, with one or several pipelines. The good news is that below, I explain how to do it. The bad news is that small companies with tight budgets may have a hard time and extra resources spent doing it alone.
  
  
• CI/CD requires constant support. If you’re a large company with a wide range of services, that might be a problem. Multiple pipelines, some even for particular delivery stages, can streamline processes and drain resources simultaneously.

Why implement CI/CD in microservices

Microservices architecture divides complex applications into smaller, independent, and collaborative services. Each team of developers has its own code to create and install independently. The team also owns every change a team member makes. That’s why, for companies that use this architecture, CI/CD is crucial. CI/CD pipelines automate the integration and testing of these services, reducing manual intervention and accelerating development cycles. 

Below, I explain how to build pipelines for CI/CD on microservices.

Planning your CI/CD pipeline

Start by asking yourself and your team questions:

• How many microservices do you have, and how are they interconnected? (Understanding architecture)
  
  
• How do your developers currently work with the code base? (Understanding development workflow)
  
  
• How often does your team want to release new features and bug fixes? (Understanding release cycles)
  
  
• Are there any security checks you need to perform on your microservices before deployment? (Understanding security requirements)

Next, you can start planning your CI/CD:

1. Define your pipeline stages; here are some typical steps for microservices:
    
   • Build: compile your code into container images or other artifacts (JAR, WAR, etc.)
   • Test: run unit, integration, and end-to-end (e2e) tests on your microservices.
   • Deploy: deploy your microservices to a preconfigured staging or production environment.
     
     
2. Choose your CI/CD tools: There are several different CI/CD tools available, both open source and commercial, free and paid. Some popular options include Jenkins, TeamCity, and GitLab CI/CD.
   
   
3. Implement your pipeline: Do it once you have chosen your CI/CD tools and defined stages. This means writing code to automate the steps in your pipeline and integrating your CI/CD tools with your development and deployment workflow.
   
   
4. Test and refine your pipeline: Once your pipeline is implemented, you need to test it thoroughly to make sure it works as expected. You should also refine your pipeline over time to improve its efficiency and effectiveness.

Version Control System (VCS)

Version control is essential for managing changes to your microservices and tracking their deployment history. I will go over the basic steps for creating microservices repositories:

1. 1. Create a separate Git repository for each microservice. This will help you to manage each microservice independently and to avoid conflicts between different microservices.
   
   
2. 2. Add the source code and configuration files (including your CI/CD configurations) for each microservice to its respective repository.
   
   
3. 3. Commit your changes to the repositories and push them to a remote Git hosting service.
4.  
5. Here is a short example of how to set up Git repositories for a microservice architecture with three microservices:

You can also use Git submodules to include one Git repository inside another. This can be useful for managing dependencies between microservices.

Automating CI/CD: Best practices

Here are some CI/CD best practices and strategies:

Commit early, commit often: this helps to ensure that code changes are integrated and tested early on, and that any problems are identified and fixed quickly.

Do not ignore tests: all tests should pass before any code is deployed to production. This sequence improves the overall quality of the code that will be deployed to your customers.

Use cache: optimizing your builds will improve the efficiency of the CI/CD pipeline.

Make your CI/CD pipeline the only way to deploy to production: it should be a strict policy that will help you to reduce the risk of human errors and ensure the code is tested and the deployment procedure is consistent between releases.

Monitor and measure your pipeline: collect metrics on your pipeline, such as build time, deployment time, and test failure rate. This data can help you to identify areas for refining your CI/CD pipeline.

Here is a generic code example of a GitLab CI/CD pipeline for a Java microservice:

This pipeline will check the source code, build the microservices, run unit tests, and deploy the microservices to a staging environment.

You can customize this pipeline to meet your specific needs. For example, you can add additional stages, such as a security scanning stage.

Security

As the FinTech world marches into uncharted territories, the compass of compliance becomes your trusted guide. When harnessed correctly, it's the cornerstone of trust, innovation, and a flourishing future. 

Security scanning in CI/CD integrates security testing into the CI/CD pipeline. This helps to identify and fix security vulnerabilities early on, before they reach production.

There are two main types of security scanning in CI/CD:

• Static application security testing (SAST): SAST tools analyze source code to identify security vulnerabilities.
  
  
• Dynamic application security testing (DAST): DAST tools scan running applications to identify vulnerabilities.

Both SAST and DAST tools can be used in CI/CD pipelines. SAST tools are typically used early in the pipeline, during the build stage. DAST tools can be used at any stage in the pipeline, but they are often used during the test stage.

To implement security scanning in CI/CD, you need to integrate a security scanner into your pipeline. There are several different security scanners available, both commercial and open source. Some popular security scanners include SonarQube, Coverity, Snyk, Semgrep

As an example, I will show you how to easily integrate Semgrep SAST check into our previously created pipeline:

Rolling back

Rollbacks and fallback strategies are essential parts of any CI/CD pipeline. They allow teams to recover from failed deployments and minimize the impact on users.

Rollbacks are the process of reverting a deployment to a previous state. This can be necessary if a deployment fails or if it causes problems for users.

Fallback strategies are plans that teams can put in place to minimize the impact of a failed deployment. Strategies may involve redirecting users to a previous version of the application or providing users with a degraded experience.

Here are some examples of strategies:

• Use blue/green deployments: this strategy involves running two production environments, one blue and one green environment, with new deployment. When a new deployment is ready, traffic is switched from the blue environment to the green environment. If issues are encountered, traffic can be switched back to the blue environment, which is a verified working version.
  
  
• Use canary deployments: this strategy involves deploying a new version of an application to a small subset of users. If the deployment is successful, it can be rolled out to more users. If the deployment fails, it can be stopped before it affects all users.
  Use feature flags: it will allow you to enable or disable features on the fly. This strategy can be useful for rolling out new features slowly or for disabling features that are causing problems.
  
  
• Use versioning: versioning allows you to roll back to a previous version of the application if a deployment fails.
  
  
• By implementing rollbacks and fallback strategies in CI/CD pipelines, teams can minimize the impact of failed deployments and ensure users have a good experience.

Auto-scaling your microservices

Microservices auto-scaling based on real-time metrics is a process of automatically scaling up or down microservices based on their real-time performance. This can help to improve the performance and reliability of microservices-based applications by ensuring that resources are allocated efficiently and that microservices can handle sudden changes in load.

There are different ways to implement microservices auto-scaling based on real-time metrics. One common approach is to use a dedicated auto-scaling service, such as Kubernetes Horizontal Pod Autoscaler (HPA). HPA can be configured to scale pods up or down based on various metrics, such as CPU usage, memory usage, and request latency.

You can set up auto-scaling using kubectl command:

Or create a manifest file to reuse it in your pipeline easily:

This configuration detects if CPU utilization of a ‘php-apache’ deployment surpasses average 50% and increases the number of pods up to 10 to split the load.

Documentation

• Identify the different stages of your pipeline. What are the steps that your pipeline takes to build, test, and deploy your code?
  
  
• Describe each stage in detail. What tools and technologies do you use in each stage? What are the inputs and outputs of each stage?
  
  
• Include diagrams and screenshots. Diagrams and screenshots help to illustrate the flow of your pipeline and make it easier to understand.
  
  
• Document your triggers. What events trigger your pipeline to run?
  
  
• Document your fallback strategies. What happens if a stage in your pipeline fails?
  Document your monitoring and alerting. How do you monitor the health of your pipeline and get alerted to any problems?
  
  
• Version your documentation. Your CI/CD pipeline is likely to change over time, so it is vital to version your documentation so that you can track changes and ensure that it is always up-to-date.

I prefer using Markdown inside my repositories to describe the CI/CD process. Markdown is a lightweight markup language that is easy to read and write, and you can throw in some diagrams using extensions like Mermaid.

For bigger teams, maintaining a corporate Wiki might be a better option; a collaborative documentation site allows you to have comprehensive documentation for all sorts of topics like SDLC, CI/CD, monitoring, issue remediation, recovery plans, etc.

Managing CI/CD for legacy systems

Managing CI/CD for legacy systems is essential to ensure they can seamlessly integrate with the more modern microservices architecture, enabling a smooth transition without disruptions and mitigating risks. This can be challenging, but it is crucial to do so to improve the quality and efficiency of the software development and delivery process. Here are some tips:

• Start by understanding your legacy system. What are its components? How do they interact with each other? What are the dependencies? What are the known issues?
  
  
• Identify the areas of your legacy system that can be automated. This may include building, testing, and deploying the system.
  
  
• Start small and scale up gradually. Don't try to automate everything at once. Start by automating a few key tasks and then gradually add more over time. For example, you can migrate the build of one of the microservices to the new CI/CD tools and verify the integration with the existing system, then step-by-step plan the migration of other services.

Final words on CI/CD in Microservices

Dealing with microservices, software development teams need to ensure rapid deployment, enhanced testing, and improved collaboration. 

CI/CD is an essential practice for microservices because it streamlines development, improves the reliability and scalability of services, enhances collaboration, and accelerates time-to-market. These benefits align with the core principles of microservices architecture, making CI/CD a natural fit for organizations adopting this approach.

To successfully develop and implement your CI/CD strategy, you’ll need a team of experienced professionals. Finding one at INSART, you get extensive expertise in the FinTech business domain, team management, and solution development. As a strategic partner, we support our clients throughout their industry journey to new achievements, expansion, and scaling. Contact us today and accelerate your FinTech journey with confidence.