The latest News and Information on Continuous Integration and Development, and related technologies.
When you are the only dev building a software project, you can create and modify your code according to personal preference. When you contribute code to a team-run project, you need to follow a standardized set of guidelines and coordinate precisely with other team members. Standard guidelines and coordinated work effort are vital to the success of every team-based software development project.
At CircleCI, CI has a second meaning: Continuous Improvement. We continuously seek out feedback not only to improve our code but to improve our processes and get better at our jobs along the way. This Continuous Improvement starts with one important company value: a blameless culture. Our blameless culture extends into every part of how we operate.
Building software is hard. Building cloud software is even harder because things move much faster — and require mission-critical reliability and availability. To effectively build software in the cloud, engineering teams need observability, CI/CD, reporting, and lots of tooling. At every organization I’ve worked at, we’ve needed a system of tools that lets us: But all the tools available to engineering teams never quite fit together with our specific processes.
The DevOps field is engaged in a great, collective migration into the cloud. Businesses are decentralizing their applications and databases, hosting them in the cloud to make them available regardless of geography or user device. Some organizations choose to host their applications on private servers, but in periods of high demand take advantage of the public cloud by directing overflow traffic to cloud servers. This approach is called cloud bursting.
Ever since CircleCI introduced webhooks, I have been excited about the possibilities this new way of integration opens up to developers. I decided to try out one of the use cases described in the webhooks documentation. This use case involves transmitting information about build-pipeline workflows into an Airtable database. The data piped into Airtable forms a log for you to monitor your workflows and you can go as far as designing graphs and other visualizations to analyze the build data.
Breaking changes in production are inconvenient and can be costly to fix. Using commands like git clone < some GitHub repository >, executed on your terminal is a common practice, known as using the command line. This practice can be faster and more efficient than using a GUI. For this tutorial, I will walk you through the process of testing command-line applications git, explain why you need command-line applications, and describe in detail how they work.
