The latest News and Information on Continuous Integration and Development, and related technologies.
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.
Cloudsmith joins the CD Foundation as a new member, in helping to strengthen the growth and evolution of continuous delivery models.
Configuration files can take some time to set up, but after that initial push they are easy to forget about. “If it’s not broken, don’t fix it” is a common approach that many developers take with their configuration files. But when it comes to your continuous integration pipelines, small changes can have huge benefits.
