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.
After a bracing conversation with Alek Sharma, our developer advocate, I decided to write an equally bracing call-to-arms describing our hiring process.
So, you’re a software engineer. You’re adept at creating value from abstract concepts, weaving functions together in the loom of your mind. You know that Real Problems™ involve Real Work™ – a potent blend of success and failure, mixed thoroughly and served with a little umbrella.
TL;DR: CircleCI 2.0 now recognizes your build, test, and deploy stages as individual jobs with the release of Workflows. Teams using Workflows will now be able to control each stage of their development process to match their ideal process from start to finish.
Sometimes you’re backed into a dark corner, and a creeping thought comes into your head: “Rewrite this dark corner that everyone’s afraid to touch.”
WWDC 2017 has been a source of many great improvements for iOS and Mac developers, from new hardware to brand new APIs for drag and drop, wireless debugging, and exciting frameworks for machine learning and augmented reality. However, there are a few features that we’re most excited about.
The ability to share project environment variables has been one of our top-requested features, and is now available to all CircleCI users.
Previously, each new project required manually adding environment variables such as API keys. Now, organization admin users can do a one-time import of environment variables from other projects within an organization. This should reduce pain when setting up new projects.
Here’s how to find and import project environment variables from your build dashboard:
This guide was originally posted in Japanese here.
Interested in contributing a post to this blog? Reach out to our team at blog at circleci.com
Recently, CircleCI 2.0 went into open beta. Since CircleCI 1.0 adopted LXC as its base container, it hasn’t yet been possible to use Docker versions 1.11 or above. Luckily, there’s no such restriction in CircleCI 2.0 since it supports Docker natively.
This is a guest post by Divya Sasidharan, a web developer at the Knight Lab.
Interested in telling your story here? Reach out to our team at blog at circleci.com
In agile development methodology, test-driven development is seen as the embodiment of good coding practice. The “test first, code later” approach to writing software not only blends well with the short sprints intrinsic to agile development, it also enables developers to focus on the requirements and design of a system without getting sidetracked. However, given that a project undergoes different stages of development with varying requirements and specifications, a test-driven approach is not always conducive to development.
In a fairly new codebase, or in a prototype application, where code is being added and refactored at a rapid pace, tests can add friction that slows down development. Conversely in a more stable codebase, tests protect the integrity of an application. Considering this, how can we more productively think about testing as a whole and adapt to the ebbs and flows of a project lifecycle?
I was recently part of a panel at #SRECon, where I shared my thoughts on how to onboard Site Reliability Engineers (SREs). For those who missed it, I’m sharing what I discussed for those who are either considering joining an SRE team or are actively onboarding/managing SREs.
Earlier this year, I wrote a post about Why Developers Are Moving To Yarn. This struck a chord with many people who were frustrated with