CircleCI Blog

CircleCI workflows is a powerful feature that can be used to make your deployment process simple and intuitive. In this article, we will learn how to use them to automatically push images to the Docker registry, just like Docker Hub’s own automated build process, but with all of the customization that your own build process offers.

I regularly speak at conferences and tech meetups, and lately I’ve been fielding a lot of questions regarding the continuous delivery of applications to cloud platforms, such as Google Cloud, using HashiCorp Terraform. In this post, I will demonstrate how to deploy an application using CI/CD pipelines, Docker, and Terraform into a Google Cloud instance. In this example, you will create a new Google Cloud instance using a Google Container-Optimized OS host image. Google’s Container-Optimized OS is an operating system image for Compute Engine VMs that is optimized for running Docker containers. With Container-Optimized OS, you can bring your Docker containers up on Google Cloud Platform quickly, efficiently, and securely.

This tutorial also demonstrates how to use Terraform to create a new Google Cloud instance and deploy the application using this CI/CD tutorial Docker image. The image will be pulled from Docker Hub and run on the instance created from Terraform.

Note from the author: this post was written in collaboration with Justin Cowperthwaite, engineering manager, with additional input from Jeff Palmer, VP Engineering.

We want CircleCI to be a place that all engineers can learn and grow, and be supported no matter what level they join us at, or how they want to shape their careers. To support this, we use an engineering competency matrix, a framework that outlines expectations and growth paths for engineers. This matrix is a tremendously useful tool for us: it informs the structure of our job descriptions and our interview processes. It helps us set expectations together with our engineers, is a basis for goal setting as well as conversations about learning and development. It helps us have more objective performance conversations which are less susceptible to the biases and skills of an engineer’s manager. Overall, it clarifies the vision of our organization and helps us maintain consistency throughout all stages of hiring and professional development.

Our goal at Percy is to help teams deploy with the confidence that their applications look exactly like they should.

Instead of manually checking your UI across browsers and screens, our visual testing and review solution automates it for you. Integrate Percy with your tests and our custom-built rendering infrastructure generates snapshots of your UI every time you push a change.

That workflow fits seamlessly into your existing CI/CD suite, helping you eliminate the risk of visual regressions on every single commit. With Percy, you can also run visual tests in tandem with parallelized CI builds–and our CircleCI orb makes it easier than ever.

Surprisingly, many open source projects don’t implement a continuous integration (CI) solution. Perhaps your project is one of these. You might be thinking, “We don’t need it, we know what we’re doing,” or even, “We’re too small, we’ll implement it later.”

When maintainers do use CI, it’s often an insufficient implementation, such as using it for deployment without any testing.

I should know; I’ve been guilty of this myself.

But I want to show you that the decision to implement CI for an open source project is not about you. It’s about providing the right tools for contributions. It’s about enabling your project growing steadily with healthy code.

Using CI in your open source projects will help empower your contributors to make better PRs more easily and help your project grow and thrive.

Read on for four ways that CI can empower your open source contributors:

Bringing a new tool into an organization is no small task. Adopting a CI/CD tool, or any other tool should follow a period of research, analysis and alignment within your organization.

In my last post, I explained how the precursor to any successful tool adoption is about people: alignment on purpose, getting some “before” metrics to support your assessment, and setting expectations appropriately. I recommend you revisit that post to best prepare your team before you enact any tool change.

The next step is about analysis: deducing exactly what pipeline problem you most need to solve. By examining your development process (which I’ll refer to as your “path to production”) you can pinpoint where your biggest problems are coming from. Only when you know what problem you’re trying to focus on solving can you make a well-reasoned tooling decision.

Mobile apps are different than web apps and require tooling specifically designed to meet the needs of development, security and DevOps teams. Organizations can speed mobile appdev by optimizing flow and baking in security, which can be achieved by using CircleCI and NowSecure. A long-term collaborator with CircleCI, NowSecure is pleased to be a CircleCI Technology Partner with our own orb in the registry.

This post, written by CircleCI Developer Advocate Ron Powell, originally appeared on The New Stack here.

Have you ever found yourself in a situation where you have discovered a new tool that may be able to solve a problem for your team? Did you bring it excitedly to your manager only to be shut down by a conversation about cost/benefit analysis and return on investment? It can be difficult to introduce these tools when you are not the person that makes those decisions.

What I want to offer is a method for applying a DevOps mindset to tool adoption. With DevOps, we are always working to be more iterative, as well as think bigger about the way our choices are affecting others on our team, as well as end users. We can approach adopting a new tool in the same way: when trying to make a change, go in stages, test and prove, and consider all involved. In this article, I will show you how, and include specific language you can use with your manager and others on your team that will help you along the way.

Our company Cypress.io has made an open source, MIT-licensed, free end-to-end test runner that can test anything that runs in a browser. The test runner makes it easy to effectively test complex modern web applications, yet it is simple to install, easy to learn, and it just works.

This is a guest post written by Karel Rochelt. It originally appeared on the Amio blog, and has been republished here with his permission. We hope you enjoy!

Providing an error-free API for a heavily developed project is not an easy task. Likely, the first things that come to mind are tests. For a mid-sized API, you may write hundreds or even thousands of end-to-end tests. These tests significantly prolong build times. In this post, we will explain how we solved long build times with CircleCI test parallelism and Gradle/Grails for Amio’s main service.