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.

SaaS companies operating at the scale we are have a lot of moving parts. Combine that with the fact that we fully embrace Continuous Deployment and our eagerness to bring you great development tools means that a lot of changes are happening that you may want to know about.

Here are several ways to stay informed on what’s changing at CircleCI.

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.

CircleCI workflows are powerful features 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.

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.

Continuous integration (CI) tools have been evolving towards flexible, general-purpose computing environments. They aren’t just used for running tests and reporting results anymore. They often run full builds and send artifacts to external systems now. If you’re already relying on a CI system for these other needs, it can be convenient to build and deploy your documentation using the same platform rather than pulling in an additional tool or service.

This post gives an overview of some popular options currently available for building and deploying documentation before diving into the details of using CircleCI to deploy documentation to GitHub Pages. This is a workflow that will be convenient for teams already using those tools for hosting code and running automated tests.

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.

React has taken the frontend world by storm, and for a good reason. It provides an intuitive model for building data-driven user interfaces. React enables us to write declarative components describing the user interface and provide the data needed to render these interfaces. It then efficiently updates the DOM when this data changes. Redux, on the other hand, enables managing the data that React needs to render interfaces. It offers a predictable way to structure and update the data in frontend applications and pairs quite nicely with React.