CI/CD as a Service

Abstract

Continuous Deployment has transformed how developers introduce changes, placing emphasis on automation, reliability, and speed. As applications grow, the pipelines that transition code from development to production must also evolve. The objective is to offer quicker feedback through shortened deployment cycles. These pipelines should be adaptable, reflecting the needs of the software they handle. It's vital to incorporate rigorous quality gates at key intervals, making certain that agility doesn't sacrifice quality.

This article dives deep into the synergy of AWS and its Cloud Development Kit (CDK), illustrating how these tools can help DevOps engineers craft CI/CD pipelines that are not only efficient but also agile and responsive to the ever-evolving demands of the software.

About Us

At Studyportals, we started using serverless automation to create environments and CI/CD pipelines from AWS Lambda’s early stages. As we started transitioning towards a microservice architecture, the complexity of a deployment also increased and, without constant maintenance, the deployment tools that we were using proved to be increasingly difficult to extend and maintain. Our engineering teams relied mostly on pipelines that were manually created for each service. This approach, while initially serving our needs, started to manifest some challenges. One notable struggle was devising a robust and uniform notification system to centralize all the deployment notifications in the same place and use a similar format. Additionally, pushing updates to the pipelines and to the resources backing up the pipelines across multiple accounts and regions posed another hurdle.

Our architecture is distinctly categorized into three primary types of services:

• Docker (Monoliths): These are our traditional monolithic applications that encapsulate various functionalities within a single service boundary, containerized using Docker for consistent deployment and scaling.




• Frontend Microservices: These microservices focus on the user interface and experience. Recently, we've standardized them by , a fully managed application deployment service, coming out with a similar approach after we'd adopted this strategy. While we’ve set a solid course with our current setup months before AWS Proton was released, exploring an integration with AWS Proton is something we’re keeping an eye on for the road ahead.

  
  
  

  This is how it would look like in big lines:

  
  
  

  . There are strategies to get past these cross stack references, usually requiring manual steps. However, we aimed for full automation. Our workaround? We leaned on sharing data between stacks using the SSM Parameter Store. This approach was particularly helpful for those situations where we foresaw potential issues, enabling us to update a resource in the parent stack without disturbing its relationship in the child stack.

  
  
  

  Another struggle was with specific account limits, such as the number of CloudFront Custom Policies or the number IAM roles, which meant that we had to introduce account level support stacks in addition to our environment and service stacks. These account-level stacks housed resources that could be utilized by multiple services in the same account, and were designed to be long-lasting stacks.

  
  
  

  With the groundwork laid out, let's pull the curtain on our service blueprint:

  
  
  
  
  

  The environments from the descriptor extend an out of the box feature of CDK, also called Environments. It gave us a ton of flexibility: we could deploy our setup to any AWS account or region we wanted, making sure our deployment was as flexible and scalable as the services we were working on.

  
  
  

  With every GitHub event, our system responds promptly. Based on the configurations we've established with the CDK's Environments feature, our entire setup – including the environment and its associated pipelines – either undergoes creation or receives updates. This ensures we're always in sync with the latest code changes. After these changes are completed, the AWS CodePipeline springs into action. It retrieves the updated code from git, then builds, tests, and deploys it to the intended environment, likely followed by additional testing. By doing so, we ensure a high standard of quality while maintaining the adaptability and efficiency of our deployment method.

  
  
  

  
  
  
  The road ahead
  

  
  
  

  Continuous Deployment, with its emphasis on speed, reliability, and automation, has revolutionized the way developers operate today. While setting up our infrastructure and improving our CI/CD pipeline, we realized the benefits of the AWS ecosystem and the versatility of the Cloud Development Kit (CDK). The journey with Studyportals, adapting serverless automation, refining branching strategies, and accommodating the dynamic nature of microservice architecture, shed light on the complexities and challenges inherent in the transition process. Yet, it was this very journey that equipped us with the tools and strategies to overcome these challenges and streamline our operations.

  
  
  

  AWS CDK stood out as an invaluable tool in this process, offering modularity, reusability, and agility, which ultimately enabled us to keep our infrastructure and applications seamlessly aligned. However, it's crucial to remember that, like any tool, CDK has its own set of challenges, necessitating innovation and strategic workarounds to fully harness its potential.

  
  
  

  Going forward, we remain committed to evolving and adapting. Technologies will continue to change, and new challenges will emerge. But with a robust framework in place, a commitment to continuous learning, and an emphasis on adaptability, we are confident in our ability to navigate the future landscape of CI/CD.

  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen