Snapcraft, the package management system fighting for its spot at the Linux table, re-imagines how you can deliver your software. A new set of cross-distro tools are available to help you build and publish “Snaps”. We’ll cover how to use CircleCI 2.0 to power this process and some potential gotchas along the way.
“Developers are drawn to complexity like moths to flame, frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn’t like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.” Neal Ford
I have been coding in Clojure for almost 4 years now. I have been fighting with logging in Clojure for almost 4 years now. This is not something for which Clojure is solely to blame, but it is something that seems to often suffer the Lisp Curse.
This past year, while working in a field of green (ie, building Contexts), I was once again confronted with a “simple” problem in the realm of logging…namely we were spitting out all of our secrets. Figuring this was probably enough to block launching it publicly, my team took some time to dig deeper and hunt down the errant class writing all of our requests to
This post was originally published on Intuit Quickbooks’ engineering blog.
Docker on CI is powerful
CircleCI has an amazing set of features in a simple package that allows our developers to move faster than ever before. Coming from our old build system, we wanted to push Circle to the limits such that we could squeeze as much speed out of it as possible.
- Be as small as possible
- Be reliable/reproducible
- Be fault tolerant
From the outset, we wanted to make sure that we could build at scale with the least amount of friction possible. That meant embracing open source, and interweaving it our internal solutions. At each step of our build process, we focused on these things.
TL;DR: After August 31, 2018, CircleCI 1.0 will no longer be available for Linux and macOS users. You can find guides for transitioning from 1.0 to 2.0 and a full timeline on planned changes here.
We launched CircleCI 2.0 for general availability in July 2017, providing users with increased flexibility, power, and control. Since then, build times on both our Linux and macOS fleets have been dramatically reduced. We’ve been able to handle increasing numbers of users and jobs, while simultaneously decreasing average job time across every language we serve. The addition of Workflows in 2.0 has also made it possible to match your pipeline to your team’s needs.
This is it, folks: the final chapter in our epic trek through the history of DevOps! Last time, we talked about how the Agile movement gave rise to the more defensive practices of automated testing and continuous integration. This time, we’ll be discussing the progression of that theme with continuous delivery and continuous deployment.
Admittedly, the introduction of two more “continuous” terms is a bit confusing, especially because the lines between one term and the next are so blurry; it doesn’t help that they are recent developments and could be renamed at any moment.
But fear not! We’re well-equipped to deal with this kind of volatility and will tread carefully. At this point in our saga, “history” is hardly even the right word for what we’re discussing. What we’re really talking are current events, which is very exciting but also much squishier than more concrete subjects like waterfall development or Agile methodology.
Why are Deterministic Builds Important?
Reproducibility and reliability.
The most common thing a customer will say in a support ticket is that their builds are suddenly failing even though “nothing has changed” on their end. This is almost never true.
In this post, I want to talk about deterministic builds. The idea here is to reduce as many changing parts as possible within a build. This means fewer mysterious failing builds, fewer support tickets (for you and us), and perhaps identically reproducing that accidentally deleted binary by simply re-running the build.
Chrome and Punishment: Browser Tests and You
Browser testing is a popular strategy for web application developers to verify their programs from the user’s perspective.
With the release of Headless Chrome, there is hope.
Let’s explore why this is a problem and how Chrome helps to solve it.
The following is a guest post by the team at Open Listings: Kevin Miller, Director of Growth, and Alex Farrill, CTO.
I. The Challenge Prior To CircleCI
At Open Listings, we’re a scrappy and passionate team focused on an ambitious mission: making homebuying simple and affordable. Our product is fairly complex, as it has to address homebuyers’ different needs through each distinct step of the homebuying process. There’s no practical way to support all these use cases without thorough automated testing.
Welcome back, dear reader, to our ongoing journey through the rich history of DevOps! In the last chapter, we discussed the many movements that led to Agile methodology. Towards the end, we foreshadowed how constant validation would play a role in this chapter.
Now that foreshadowing is coming to light! This time, we’ll be discussing two processes near and dear to our hearts: automated testing and continuous integration.
Welcome to another chapter in the feature-rich story of DevOps!
Last time, we discussed why the history of software development is important and how waterfall development fit into that narrative. Remember that waterfall development was ironically rather rigid. It lacked the flexibility to adapt to change, a noticeable weakness in a world that is increasingly volatile.
In this chapter, we’re going to explore how (and to what extent) engineers iterated on the waterfall model through Agile Software Development. Instead of trying to control change by locking down phases of development, Agile methodology is about embracing change. Risk is lessened not by devising the perfect plan, but by cutting projects into small chunks and adapting on the fly.
But enough spoilers! Let’s dig around in the roots of Agile philosophy.