3 ms·

Ask HN: How are you doing CI/CD at your company?

5 points by xstartup 9y ago

drakonka 9y ago
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 9y ago
  Why'd you move off the proprietary CI system? What was it?
  - drakonka 9y ago
    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.
eb0la 9y ago
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.
matt_s 9y ago
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.

5 points by xstartup 9y ago

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 9y ago
Why'd you move off the proprietary CI system? What was it?
- drakonka 9y ago
  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.

eb0la 9y ago

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.

matt_s 9y ago

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.