
Launching Today: CircleCI 2.0 Reaches General Availability - ssemmaprise
https://circleci.com/blog/launching-today-circleci-2-0-reaches-general-availability/
======
dankohn1
Do you recommend using the same Docker image that passes tests on CircleCI in
production?

I have an open source Rails app <[https://github.com/coreinfrastructure/best-
practices-badge>](https://github.com/coreinfrastructure/best-practices-badge>)
that self-certifies that open source projects are following best practices. It
currently uses CircleCI 1.0 and then deploys to Heroku
<[https://circleci.com/gh/coreinfrastructure/best-practices-
ba...](https://circleci.com/gh/coreinfrastructure/best-practices-badge>).

If I configure it for development and test, it will contain all the test and
development gems in addition to the production ones
<[https://github.com/coreinfrastructure/best-practices-
badge/b...](https://github.com/coreinfrastructure/best-practices-
badge/blob/master/Gemfile>). I would also need to include gcc and other build
tools. But I would have immutability in that my dev, test and production
images would be identical.

Or, should I use one image for dev and test, and then build a different image
for production, in order to have the smallest possible size? CircleCI supports
building <[https://circleci.com/docs/2.0/building-docker-
images/>](https://circleci.com/docs/2.0/building-docker-images/>) further
Docker images, but then there's a chance of losing dev/prod parity if, for
example, a software dependency gets updated in the meantime.

~~~
147
I'm not sure if Circle supports it yet but you should definitely look into
docker multistage builds as that should solve this problem for you.

[https://docs.docker.com/engine/userguide/eng-
image/multistag...](https://docs.docker.com/engine/userguide/eng-
image/multistage-build/)

~~~
dankohn1
I've been experimenting with multi-stage builds, and they do let me build a
leaner image with clearer syntax by using one the first image to build my
gems, and then copying the gems to the final image.
<[https://github.com/coreinfrastructure/best-practices-
badge/b...](https://github.com/coreinfrastructure/best-practices-
badge/blob/dan-docker-updated/Dockerfile#L48>)

However, that doesn't fix the problem of having lots of development and test
gems installed in test that I don't want for production. I don't know of a way
of copying just my production gems to a production image.

~~~
lstamour
Well, you could load only the gems required for the environment:
[http://bundler.io/groups.html](http://bundler.io/groups.html)

Or maybe have more than one path for gems and change load paths between
environments?

Or keep tests in a separate image from the production image under test?
Similarly, build tools could live in a different image/layer.

~~~
dankohn1
It's not a crazy idea to first install production only gems, then copy them
(cache them), and then install the remaining gems. But I'm asking for info on
best practices.

~~~
lstamour
You can bundle into vendor folders, one for each env and one for the rest.

~~~
dankohn1
Do you have a URL demonstrating this, please?

~~~
lstamour
No URL right this second (maybe I should write a blog post–), but I would set
GEM_HOME or BUNDLE_PATH env variables as I ran bundler to have it install in a
different folder, and add the folders as necessary to GEM_PATH at runtime. I
would also consider using a local cache folders for the source of the gems
bundler uses. This is the purpose of
[http://bundler.io/v1.6/bundle_package.html](http://bundler.io/v1.6/bundle_package.html)
which assumes that gems are installed separately rather than loaded directly
by path because of platform differences (packaging on Mac to run on Linux, for
example). But you don’t need the overhead of bundler’s packaging and install
process if your binaries are built in the same environment they run in, as
could be the case with Docker or VMs.

You could also point BUNDLE_PATH at the last place bundler ran for that
environment (don’t delete the old gems) and that would speed up the install,
but a better approach might be to package to a shared folder and then install
to env specific bundle path folders in your docker image/build workspace, if
you want bundler to manage the shared caching while keeping gem output
separate and unique to each build.

It’s important to remember that gems are just folders of ruby files placed in
the load path, sometimes with compiled bits to load at runtime, that could in
turn be dynamically compiled to rely on system libraries or non-Ruby packages.
So you have similar constraints with Ruby that you would have with Node.js –
the potential for issues from the portability or lack thereof for native code
dependencies. That’s why there’s a distinction between “install” and “package”
– install will make sure the binary output can run on the current system
unless flagged not to.

------
nailer
Use Circle daily, signed up for the beta 2.0 release which has been fine in
production for the last few months.

When I've needed support (mainly around installing custom versions of various
apps) the staff have been very responsive.

Circle folk: for me it still displays 'Leave 2.0 beta' and 'Join 2.0 beta' \-
do I need to anything to get 2.0 final?

~~~
ssemmaprise
That label on your dashboard refers to a UI change, which, now that you bring
it up, does sound super confusing. You don't need to do anything to go from
beta 2.0 to GA 2.0 - if you're using 2.0 config in your yml file, you're in.

Thanks for pointing that out, let me see if we can make that less head-
scratchy.

~~~
nailer
Ha maybe I haven't been using 2.0 then - I thought Circle 2.0 meant Circle
2.0, UI and backend.

~~~
ssemmaprise
More on going from 1.0 to 2.0 here: [https://circleci.com/docs/2.0/migrating-
from-1-2/](https://circleci.com/docs/2.0/migrating-from-1-2/)

You should also see a little icon in your dashboard that says 1.0 or 2.0 to
the right of each of your builds - that will tell you what version you're on
:)

------
danielsamuels
Oh no, we tried switching over to it for a test project and it was basically a
disaster. Something as simple as running Python tests and node tests on the
same instance just didn't seem to be possible. We _really_ don't want to have
to maintain our own Docker images. Their support forums are running Discourse
too, so it's basically impossible to find anything you're looking for.

~~~
tlackemann
I always found Discourse sites to be quite easy to navigate. Do you suggest
anything better?

~~~
enzanki_ars
The problem with any community forum support is that without representatives
from the company constantly on there, a question might:

\- go unanswered

\- get answered by the community with "here is how you do it," without the
"here is why" part.

\- the question can't be answered by the community and all you see are
messages along the lines of "same issue here."

Rarely do I see the "here is how you do it and here is why" answer I am
looking for.

~~~
Dirlewanger
Those are all valid, but none of those are inherent with Discourse, so not
sure why the guy mentioned brought it up.

------
kevinburke
I wrote a binary for interacting with CircleCI from the command line that you
might like. Notably you can type "circle wait" and get friendly output showing
how long your test steps took to run and which (if any) containers of a multi-
container test failed.

We use it a ton and you might like it too.

[https://github.com/Shyp/go-circle](https://github.com/Shyp/go-circle)

------
nailer
Re: [https://circleci.com/docs/2.0/migrating-
from-1-2/](https://circleci.com/docs/2.0/migrating-from-1-2/)

Rather than have every customer repeat these steps to transform their file,
why don't you do it for them, and make a circle.yml to .circleci/config.yml
converter?

I'm currently trying to work out what

    
    
        dependencies:
          pre:
    

Turns into for 2.0. There's instructions for

    
    
        dependencies:
          override:
    

But I'm not sure if the same logic applies to pre, and the replacement shown
there is indented in such a way that it looks like there's some missing
information about what the parent container should be. All I can do is guess
what the replacement for

    
    
        dependencies:
          pre:
    

should be.

~~~
keybits
Thanks for the feedback, we have a tool in the works to translate the config.
Sorry it's not available right now.

For the 'dependencies: pre' step, you would replace that with a 'run' step,
the same as outlined for 'dependencies: override'. We'll update the docs -
thanks for pointing it out.

~~~
nailer
Is there something above 'steps:'? The indentation looks like there's a
missing parent key - eg, it starts with a bunch of spaces at the top level -
but it's hard to work out what it is.

Edit: looking at another doc, [https://circleci.com/docs/2.0/configuration-
reference/#deplo...](https://circleci.com/docs/2.0/configuration-
reference/#deploy), the missing parent key is 'jobs:'

Also shouldn't "Search and Replace Deprecated 2.0 Keys" be "Search and Replace
Deprecated 1.0 Keys" (or better "Search and Replace Deprecated Keys")?

~~~
nailer
Also

[https://circleci.com/docs/2.0/configuration-
reference/#table...](https://circleci.com/docs/2.0/configuration-
reference/#table-of-contents)

Implies 'steps' is directly under 'jobs', whereas:

[https://circleci.com/docs/2.0/configuration-
reference/#full-...](https://circleci.com/docs/2.0/configuration-
reference/#full-example)

shows that 'steps' is under 'jobs > build'

~~~
nailer
Some feedback:

\- Re:

    
    
        * missing executor type
        *  is not supported executor type
    

Include [https://circleci.com/docs/2.0/executor-
types](https://circleci.com/docs/2.0/executor-types) in the error.

\- This should be one error, not two.

\- Why is 'working_directory' mandatory now? It wasn't before. Why not provide
a default?

\- 'working_directory: ~' fails. But 'working_directory: ~/' works (but then
fails later). This is silly. Do path normalisation.

\- [https://circleci.com/docs/2.0/executor-
types](https://circleci.com/docs/2.0/executor-types) should include a node 8
image already. it's the current version of node and '@latest' won't be great
when 9.x comes out.

\- Re: [https://discuss.circleci.com/t/directory-tmp-you-are-
trying-...](https://discuss.circleci.com/t/directory-tmp-you-are-trying-to-
checkout-to-is-not-empty-and-not-git-repository/11370). The error is missing a
word. Also checking out to a directory with existing contents should be fine.

Edit: finally got it:

[https://gist.github.com/mikemaccana/b6a7be0351d769a9099f5fdb...](https://gist.github.com/mikemaccana/b6a7be0351d769a9099f5fdbdc726b0c)

~~~
gordonsyme
`~` is YAML for null -
[http://yaml.org/type/null.html](http://yaml.org/type/null.html)

~~~
OJFord
Wow. I've always thought I understood `$HOME` was generally considered
safer/more portable, but I've never _actually_ had a problem when
(interactively) using `~`.

Always use `$HOME`!

------
bdcravens
After years of using CircleCI 1.0 (loved that they let me install custom
packages) for pre-Docker apps, I found 2.0 required a ton of scripting to test
and deploy. Moved back over to Codeship - love the workflow. Setup used our
docker-compose.yml, and testing/deploy config using a simple yml file worked
great. Love the command line tool that lets us encrypt ENV files, as well as
run and deubg the build locally.

------
tfar
Is there a way to cache build results for follow up builds? So the next build
only needs to rebuild the files that changed?

~~~
ssemmaprise
This may be what you are looking for:
[https://circleci.com/docs/2.0/artifacts/](https://circleci.com/docs/2.0/artifacts/)

------
drinchev
CircleCI is great!

I use it almost everywhere.

Unfortunately here in Berlin mostly everyone switches to self-hosted version
of Jenkins at one point.

~~~
ssemmaprise
What do you think happens at that point to make them switch toJenkins?

(In case it's not super obvious, I work at CircleCI)

~~~
drinchev
I've heard some reasons like :

\- Privacy issues \- Owning critical service component

Unfortunately I've never heard the reason that I think is the right one ( at
least from what I can see is happening here ), which sounds like :

"Hey, we don't need this, because at Zalando / Nokia Maps, etc. we used
Jenkins, so I don't wanna spend time maintaining a new tool ( CircleCI )."

Same stuff happens with project management ( dominated by JIRA around Berlin
).

At one point a company trashed all my CD-setup ( which was with the free plan
anyway ) to run Jenkins with Docker ( I don't know how well supported docker
is with CircleCI, but I doubt that is so much different than Jenkins ).

EDIT: I'm freelancing in Berlin, so I usually do a hand-over when the team of
devs is hired.

~~~
scrollaway
Yeah, CircleCI really needs to allow self-hosting. Jenkins is basically the
only player in the space and Jenkins is _not good_.

~~~
ssemmaprise
We do -- but let me know if for some reason this isn't what you're
thinking/wouldn't meet your needs:
[https://circleci.com/enterprise/](https://circleci.com/enterprise/)

~~~
falsedan
> _$35 /user/month_

That's ~$40k/year for 100 devs, plus the infrastructure costs. A Jenkins
license is $0 (or $100k+ for enterprise support). If it was my budget, I'd
have a hard time fronting up a large fraction of a developer's salary to a
third party to provide a fuzzy level of support, versus spending zero money
and putting the support burden on an in-house team I can trust and directly
influence.

TeamCity has great support, I trust them from JetBrains's great work with
IDEs, and their top-shelf license is ~$22k (one-off with 1-year of support &
upgrade; iirc the yearly support fee is discounted 50% of original license).

~~~
gtirloni
If you have 100 devs, you need _at least_ 1 FTE supporting Jenkins and that's
$60-120k/year alone.

~~~
falsedan
We have more devs than that, and we spend way less than 1 FTE (or equivalent)
per year on keeping it in good working order. Our biggest issue is when we
want to do something that's not well-supported or hit bugs.

~~~
gtirloni
That's impressive. We run into not well supported features and bugs
frequently. It's probably a side effect of our workloads.

Right now we're evaluating GitLab CI and it looks like the way forward (for
us).

~~~
falsedan
Don’t get me wrong, we are owned daily by Jenkins bugs. We just push as much
as possible out of job config and into shared workflows & Makefiles, and treat
Jenkins as a glorified cron with a web UI.

------
k__
Half-OT: How do you do CI with iOS applications? Is there some good cloud
service? Or do you simply set up a local macOS server with Fastlane, for
example, and be done with it?

~~~
ssemmaprise
iOS/macOS also supported on CircleCI. Unfortunately not on 2.0 yet, but coming
soon! [https://circleci.com/mobile/](https://circleci.com/mobile/)

------
twinpride34
Is this fundamentally a more Enterprise version from 1.0?

We're looking for something with security, control, support etc that we didn't
see when we looked at 1.0.

~~~
manishas
Check out [http://docs.shippable.com/getting-started/byon-
overview/](http://docs.shippable.com/getting-started/byon-overview/)

All the security and control of an on-premises solution with all the benefits
of SaaS.

