Here’s when and why we will update build images on CircleCI 2.0 and CircleCI 1.0.
A Step-by-Step Guide to Updating Legacy Processes in Your Org
Changing the way teams work is hard. Just think how hard it is to change just yourself. Then sprinkle in the difficulty of getting a group of people using various applications moving in the same direction.
We’ve talked to a lot of teams, and we’ve heard many variations on the same theme in terms of obstacles they foresee in implementing continuous integration:
“My company is a 20 year old company with established processes. Bringing in Continuous Integration would be a huge change to our culture, there are security implications, and it requires a major retooling. I’m going to have to sell this to my boss.”
So, where do you start when embarking on selling a new idea to your boss, to your team, and to everyone else you need to convince to invest?
Continuously deploying Clojure apps to Google App Engine
At CircleCI we write lots of Clojure. The main backend app is > 100,000 lines of Clojure code, and the frontend is > 30,000 lines of ClojureScript.
I love Clojure as a language, so much so that I decided to do my side projects in Clojure, too.
I was quite surprised when I realized that deploying to AWS requires a set of elaborate hacks to just get continuous delivery (push to master on GH -> production) working. Although I use AWS at work every day, I just can’t justify building my own implementation of things like secrets and blue / green deployments for my side projects.
Originally posted on Stackshare.
CircleCI is a platform for continuous integration and delivery. Thousands of engineers trust us to run tests and deploy their code, so they can focus on building great software. That trust rests on a solid stack of software that we use to keep people shipping and delivering value to their users.
As CTO at CircleCI, I help make the big technical decisions and keep our teams happy and out of trouble. Before this, I was CTO of Copious, where I learned a lot of important lessons about tech in service of building a consumer marketplace. I like snowboarding, Funkadelic, and viscous cappuccino.
A couple weeks ago, we released CircleCI 2.0. This was a tremendous effort, involving every person at CircleCI by the time it reached General Availability. Exactly the kind of effort that we try to avoid as a CI/CD company.
We fundamentally changed the guts of our product, and there’s no way for that to not be terrifying. It took six months to get this in front of the first customer, and another nine to get to GA. It’s impossible to tell you how relieved we are to have reached this milestone because it means we can actually start delivering code in small chunks again.
So why would we, as a company that literally has ‘CI’ in its name, spend so much time crafting an actual release? Doesn’t that go against everything we believe?
Docker introduced multi-stage builds in May of 2017. In simplest terms, these are Dockerfiles with more than one
FROMstatement. With a small tweak, you can build multi-stage Dockerfiles on CircleCI 2.0.
Our mission is to enable teams to do their best work. Today’s release of CircleCI 2.0 represents a huge step forward on that path. Over 5+ years and 65M+ builds, we’ve learned a lot about how the most effective engineering teams work. They commit early and often, and get validation on new ideas immediately. They can spot problems quickly and fix them even faster. Implementing CI/CD frees teams to ship better software faster and individual devs to push code and innovate without fear.
CircleCI has roughly 100 employees and at least 10 of us are here as a result of attending a coding bootcamp. Love them or hate them, bootcamps are here to stay and they’re becoming more entrenched in the hiring pipeline. Course Report counted 30 technology-focused bootcamps in 2013. Today, they list more than 300.
Test, test again
Here at CircleCI, we care a LOT about testing. And after running more than 65 million builds, we have learned a thing or two. Empowering teams to test often and better is a driving force in what we do. Running tests makes your code more reliable.
But are you getting the most out of your tests? Beyond simply implementing them, are you adequately testing your tests? After all, the tests themselves are only as good as they are reliable.
Some Docker containers are perfect for CircleCI 2.0. Postgresql, for instance, spins up everything you need just by passing in a few variables:
version: 2.0 jobs: build: docker: - image: clojure:alpine - image: postgres:9.6 environment: POSTGRES_USER: username POSTGRES_DB: db ...
But sometimes you’ll come across a third party container which doesn’t play so nice. You’ll need access to some resources which are present inside the container and nowhere else. The issue you’ll run into is that CircleCI makes your execution environment your primary image. So above, while I have access to the ports which are exposed by Postgres,
psqlisn’t in my
$PATH. Only the contents of Clojure’s Alpine container are.