Operations | Monitoring | ITSM | DevOps | Cloud

Continuous integration (CI) makes the cycle from design to code to building artifacts seamless and consistent. Continuous delivery (CD) makes delivery of that artifact to an environment the same every time. But, what about the actual environment the artifact is running in? Is it the same every time? That’s a hard thing to guarantee — unless you take advantage of an Infrastructure-as-Code (IaC) approach. This post explains how to use Infrastructure-as-Code to improve CI/CD.

Over the past few years, cloud computing has enabled agile, dynamic management of software and hardware components, on-demand. Nowadays, we can define our desired infrastructure in as little as a few lines of code, and we can provision real servers on cloud providers like AWS or Azure. Terraform is an open-source infrastructure-as-code (IaC) tool that has become the de facto solution for provisioning one aspect of those components.

CircleCI orbs are reusable packages of YAML configuration that condense repeated pieces of config into a single line of code. Since its launch in 2018, the CircleCI orbs registry has been used by developers, development teams, and by companies who want to help developers integrate their services seamlessly into continuous integration pipelines. In this tutorial, we will show how to use CircleCI orbs to continuously deploy a Node.js application to Heroku, one of the most popular hosting platforms.

Let’s face it: Creating the optimal CI/CD workflow is not always a simple task. In fact, writing effective and efficient configuration code is the biggest hurdle that many developers face in their DevOps journey. But you don’t need to be an expert to set up a fast, reliable testing and deployment infrastructure. With a few straightforward techniques, you can optimize your config.yml file and unleash the full potential of your CI/CD pipelines.

Deep in the woods, where trees are black and the air is thick, steam rises wistfully across the damp ground. A single dirt track, barely wide enough to pass, scars the terrain for what seems like an endless number of miles. It winds its way through the mountains and valleys, across a rickety bridge over a cavernous ravine, before plunging back into darkness, the trees bending over as if to grasp those passing through. Finally, in a small clearing, a lonely decrepit wooden cabin reveals itself.

A crucial part of effective package management is package distribution. Whether you are dealing with distributed development teams, deploying a distributed application or even if you are a software vendor, you need efficient, performant and reliable delivery of your software packages or artifacts. And for that, you need infrastructure. Lots of infrastructure. To deliver software globally, at low latencies, you’ll need infrastructure in many regions, preferably as many as possible.

The CircleCI Insights dashboard was designed to help you improve your delivery efficiency. We launched the dashboard a year ago to provide teams with actionable data for optimizing your pipelines. Since then, we’ve been listening to your feedback. By far, the most requested functionality is the ability to gain further visibility into test performance.

Retrospectives are a well-established resource in the software and systems engineering toolbox. From sprint retros through to post-incident reviews, we look back on our work to learn from it and to get better. We can apply the same ideas to our professional practice with a personal retrospective: writing an analysis of our experiences to learn as much as possible. We could look over a whole year of work, or focus more closely on a particular project.

Datadog CI Visibility provides a unified platform for monitoring your CI/CD pipelines. Now, we are partnering with CircleCI to extend that same critical visibility to your CircleCI environment. Datadog’s integration uses CircleCI webhooks to capture information about the status and performance of your workflows and associated jobs, such as a job’s duration and whether or not it failed or was canceled.

When you sign a contract, you expect both parties to hold their end of the bargain. The same can be true for testing applications. Contract testing is a way to make sure that services can communicate with each other and that the data shared between the services is consistent with a specified set of rules. In this post, I will guide you through using Joi as a library to create API contracts for services consuming an API.

When running a cloud service, it’s never good for customers to be the first people noticing an issue. It happened to our customers over the course of a few months, and we began to accumulate a series of reports of unpredictable start-up times for Docker jobs. At first the reports were rare, but the frequency began to increase. Jobs with high parallelism were disproportionately represented in the reports.

Companies across industries are under tremendous pressure to develop and deploy IT applications and services faster and with far greater efficiency. Traditional enterprise application development falls short since it is not efficient and speedy. IT and business leaders are keen to take advantage of cloud computing as it offers businesses cost savings, scalability at the touch of a button, and flexibility to respond quickly to change.

I’ve been leading software teams for more than 20 years and one thing I’ve learned about metrics is that leaders tend to put too much emphasis on engineering metrics alone, without considering the bigger picture. After speaking to a range of engineering industry leaders, and poring over millions of jobs processed from software teams worldwide, we found that the most insightful and relevant metrics fall into three categories: What metrics are meaningful for your team to measure?

For the past five years, CircleCI has hired third-party penetration testing firms that hammer our product releases or infrastructure at minimum every 90 days. To date, we’ve done more than 25 of these. Sometimes they cover new product features and other times they cover infrastructure.

Here’s a common situation that plagues many development teams. You run an application through your CI/CD pipeline and all of the tests pass, which is great. But when you deploy it to a live target environment the application just does not function as expected. You can’t always predict what will happen when your application is pushed live. The solution?

It’s often necessary to inject secrets into your build or deployment process so that the deployed service can interact with other services. This can be straightforward if you’re only deploying to a single environment. When deploying to multiple environments, though, you might need to dynamically inject different secrets depending on the environment to which you’re deploying.

Testing in isolation is known to be expensive. It’s time-consuming to execute thoroughly, and it typically requires a testing environment — sometimes multiple testing environments. That said, testing in isolation is undeniably effective.

If you work anywhere near the field of software development, you’ve likely already heard that you should always write code that is well-tested. Everyone wants to have well-tested code and for a good reason! Testing ensures our code is working as intended and protects against regression. Thoroughly testing code helps teams confidently ship software faster and with fewer issues.

Infrastructure as Code (IaC) is the practice of recording the desired state of your infrastructure using a declarative language. In this article, I’m going to assume that your team is starting from scratch. Maybe some of your build process has been scripted, and maybe there is some manual testing and quality assurance work happening. Many readers will find that they are midway through the IaC adoption journey I’ll describe, or that they have missed some steps.

In my interactions at industry events like AWS re:invent and KubeCon, I talk with a lot of developers. Devs often tell stories of things that prevent them from working quickly and efficiently. Many involve frustrating interactions with sys admins, SREs, or DevOps colleagues. One story I have heard several times involves a conversation like this: dev: Hey, SRE team. My build is failing and I don’t know what’s happening with the app in the build node.

Modern software development increasingly relies on distributed, service-based architectural patterns to achieve scalability, reliability, and rapid build, test, and release cycles. Two of the most popular service-based approaches are service-oriented architecture (SOA) and microservices. In this article, we will examine both approaches to identify their similarities and differences as well as some use cases for each.

Kotlin is one of the most versatile programming languages available, in large part because of the Kotlin team’s focus on bringing it to as many platforms as possible. It is the primary language for developing Android applications and is popular for JVM backends. Kotlin also features targets for native binary compilation with Kotlin/Native, and for web through Kotlin/JS. One of its most promising features is the ability to target multiple platforms it compiles to.