CircleCI Blog

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.

Docker gives developers the ability to streamline packaging, storage, and deployment of applications at great scale. With increased use of container technologies across software development teams, securing these images can become challenging. Due to container images becoming a regular part of the development lifecycle, security checks for these artifacts need to be woven into an automated pipeline and become a standardized best practice for testing.

Running builds in continuous integration/continuous deployment (CI/CD) pipelines is a great way to automate your repetitive deployment and testing tasks. However, if you have tons of tests, build steps, or other slow setup tasks, it can heavily bog down your build and drive the feedback duration through the roof! Long feedback cycles are friends to no one and slow down development lifecycle, so the next logical step is to find ways to reduce the duration wherever possible. Some of us may run tests within our build steps in parallel or perhaps take unnecessary shortcuts in pursuit of shaving some time, though these solutions may not always work optimally in the end. Let’s take a look at how we can harness the power of CircleCI 2.0’s workflows and how running jobs in parallel can unlock a whole new world of speed for our teams and us.