Tag: AWS CodeBuild

This post is co-written with Isaiah Grant, Cloud Consultant at 2nd Watch. Many organizations are building data lakes on AWS, which provides the most secure, scalable, comprehensive, and cost-effective portfolio of services. Like any application development project, a data lake must answer a fundamental question: “What is the DevOps strategy?” Defining a DevOps strategy for […]

Introduction More and more customers are using Infrastructure-as-Code (IaC) to design and implement their infrastructure on AWS. This is why it is essential to have pipelines with Continuous Integration/Continuous Deployment (CI/CD) for infrastructure deployment. HashiCorp Terraform is one of the popular IaC tools for customers on AWS. In this blog, I will guide you through […]

Learn how to scan Python packages for security vulnerabilities using AWS Developer tools and Snyk

AWS CodeBuild is a fully managed build service that offers curated Docker images. These managed images provide build environments for programming languages and runtimes such as Android, Go, Java, Node.js, PHP, Python, Ruby, Docker, and .Net Core. However, there are a lot of existing CPP-based applications, and developers may have difficulties integrating these applications with […]

In the first post of this series, we introduced a continuous compliance workflow in which an enterprise security and compliance team can release guardrails in a continuous integration, continuous deployment (CI/CD) fashion in your organization. In this post, we focus on the technical implementation of the continuous compliance workflow. We demonstrate how to use AWS […]

In a microservices world, it’s common to share as little as possible between services. This enables teams to work independently of each other, helps to reduce wait times and decreases coupling between services. However, it’s also a common scenario that libraries for cross-cutting-concerns (such as security or logging) are developed one time and offered to […]

AWS CloudFormation StackSets can extend the functionality of CloudFormation Stacks by enabling you to create, update, or delete one or more stack across multiple accounts. As a developer working in a large enterprise or for a group that supports multiple AWS accounts, you may often find yourself challenged with updating AWS CloudFormation StackSets. If you’re […]

Founded in 2019, BigHat Biosciences’ mission is to improve human health by reimagining antibody discovery and engineering to create better antibodies faster. Their integrated computational + experimental approach speeds up antibody design and discovery by combining high-speed molecular characterization with machine learning technologies to guide the search for better antibodies. They apply these design capabilities […]

Take a Well-Architected approach to make an informed decision when choosing to implement CI/CD using open-source tools on AWS services, using managed AWS services, or a combination of both.

We will look at key considerations for evaluating open-source software and AWS Services using the perspectives of a startup company, and a mature company, as examples. These will give you two very different points of view that you can use to compare to your own organization. To make this investigation easier we will use Continuous Integration (CI) and Continuous Delivery (CD) capabilities as the target of our investigation.

In our next two blog posts we will follow two AWS customers Iponweb and BigHat Biosciences as they share their CI/CD journeys, their perspective, the decisions they made, and why.

To end the series, we will explore an example reference architecture showing the benefits AWS provides regardless of your emphasis on open source tools or managed AWS services.

Understand how to automate trigger of project specific code pipeline for GitHub mono repos users. Currently, if a customer is using GitHub as a version control system and he has only one repository which contains multiple folders each for a different project, change in any file, triggers the code pipeline for the whole repository rather than for the appropriate project. With this blog, they would be able to automate trigger of appropriate pipeline based on the project folder where the file gets changed.