When you’re practicing continuous delivery, it’s essential that you monitor your application so you know that it’s performing well after deployments. You need to be notified immediately if something is wrong or if users are having a poor experience so you can resolve the issue quickly. When your monitoring solution can also tell you which code changes caused the error, you can save valuable time troubleshooting.
Today’s blog post is the first of a two-part series written by Jason Skowronski, who serves as the lead editor for technical content at Rollbar. Jason began his career as a software developer at Amazon and now enjoys being a developer advocate for the latest technologies.
Application errors can cause frustrating problems for customers that may ultimately lead to losing their trust and business. Experienced developers know what it’s like to have a critical production problem and spend minutes or perhaps even hours diagnosing a tricky problem. It’s even harder to diagnose when several developers are making changes and deployments in parallel.
Rollbar is an error monitoring solution that can tell you what errors occurred after a deployment and show you the deployment and code change that likely caused them. It integrates with your continuous integration and delivery (CI/CD) system to track when deployments are promoted to production. When an new error occurs, it looks up the deployed version in your source code repository like GitHub to identify what code was changed and who changed it. This will help you narrow down errors due to code bugs faster.
This is a guest post by Pavlos-Petros Tournaris. It originally appeared on his blog here. Pavlos-Petros works as an Android software engineer at Workable. We hope you enjoy!
Nearly a year and a half ago, Facebook released Litho as an open source project. Litho is an Android framework, which lets you define your UI in a declarative way. It immediately got my interest and I started getting my hands dirty with some examples and pet projects.
- via the SSG successfully building the site
- and HTMLProofer
What if we wanted to do more? Let’s walk through a new tool I made for testing markdown files and how it improved the accuracy of CircleCI docs examples.
Today we made a small change to the navigation inside CircleCI. Where you saw the word “builds” you will now generally see the word “jobs”. This change has zero impact on the functionality of CircleCI; all your projects should behave identically to yesterday.
That’s all you need to know to enable you to keep using CircleCI just as before. If you’re curious about why we’ve made this change, read on.
Today we’re proud to announce the formation of CircleCI G.K., a subsidiary of CircleCI. While we have worked with Japanese developers for some time, this is our first official international office, and a sign of our commitment to the Japanese market.
CircleCI in Japan
Japan has long been a focus for CircleCI: it’s one of our largest markets, and we work with some incredibly innovative companies there, like CyberAgent, Mercari, DMM, DeNA, CrowdWorks, and many others. Establishing a dedicated presence in Tokyo will help us better serve those customers and make the experience of using CircleCI better for all of our users in Japan.
Last week, we partnered with Code2040 to host their first PopUp event here at CircleCI HQ. The PopUp series is designed to engage the broader community, in particular rising Black and Latinx tech professionals. We were delighted to host the Code2040 team, an incredible panel of guest speakers (including our very own Jose Browne!) and an audience of 75 attendees.
Having security controls in place is no longer the only consideration when assessing one’s risk factors. Even when security controls are implemented, they’re often not appropriately permissioned. For example, it’s not uncommon for critical service-level accounts to be given excessive system privileges. This increases attack vectors within a system should that account be compromised. This compromised account could then execute malicious code or access very sensitive data that could present any number of issues for an organization. One way to prevent these types of security incidents is to implement the concept of Principle of Least Privilege.
This is a guest post written by Nick Janetakis. It originally appeared on his blog, and has been published here with his permission. Nick is a self-taught full-stack developer and teacher, and has created a course for Docker beginners called Dive into Docker.
Testing is a critical piece of any CI/CD pipeline. Most teams do pretty well with application level testing, and there are plenty of frameworks (JUnit, RSpec, etc.) to support it. But server-level testing–the validation of server configuration and services–is, too often, omitted. In this blog post, we’ll explore an approach to execute tests against our custom Docker images as part of a CircleCI pipeline using Goss.