Ask HN: How are you doing CI/CD at your company? - xstartup
======
drakonka
I started at my company as a build engineer and could talk about this for
_hours_, but here is a general overview with no project-specific details:

At the time I started we had a proprietary CI system. I have since moved to
doing tools and am not as up to date with the CI side of things, but we've
moved over to using Jenkins for our build system. The setup currently seems
much more complex than with our previous system with more potential points of
failure, but also more flexible and powerful (something we have grown to need
more than the more tailored but rigid proprietary system of before).

The general gist is: user (coder or content creator) makes local changes; user
submits their local changes to a pre-submission step that tests their work on
the CI (different tests depending on type of change); CL is submitted and
built/autotested; various kinds of builds are pushed out as a result
(development builds that people then sync to work with, different kinds of
package builds, cert builds, tool builds, etc etc).

I am not 100% sure how I feel about Jenkins. But I am no longer the person
dealing with it, so it is nice to not have to care :)

~~~
mslate
Why'd you move off the proprietary CI system? What was it?

~~~
drakonka
It was a build system written in C# and configured via XML-style job files. We
moved because we felt that there were open source alternatives that were
powerful, flexible, and would allow us to focus on more important things (ie
the actual builds vs fiddling with features we may or may not have or fixing
bugs in our proprietary system). There wasn't much point continuing to
maintain this in-house anymore when existing tools could do everything we
needed.

------
matt_s
Jenkins will run test suites after merges. Once a pull request has progressed
through dev & testing, and you have approvals, you can deploy whenever.
Occasionally there are PR's/tickets that relate to each other but most of the
time the work is broken up into testable, small chunks of functionality that
can be deployed any time they are ready.

Sometimes you have to build extra things to follow this process if your
changes are shipping ahead of other related changes. Like a feature flag to
turn things on/off. In previous jobs this would be seen as waste but with
CI/CD it is necessary to allow a continuous flow in the process, which is
awesome.

------
eb0la
Jenkins, triggered from a Slack bot.

To trigger a deployment to production, you need someone from QA, Backend, and
Product management, to approve the deploy.

The easiest way to do this is to "vote" inside Slack. Three votes, and the bot
starts the deploy.

