Ask HN: How to find team with mature testing+CI/CD processes? | Hacker News Reader

Ask HN: How to find team with mature testing+CI/CD processes?

10 pointsarwhatever6 comments

After 13 years in the industry, my days of checking out the main branch to find that Billy Bob unknowingly broke the build yesterday are over.

As are my days of being excessively reliant on the Tribe Elders for application knowledge, and being afraid to update existing software to meet changing business needs.

These factors in my question are the best proxy for team skill level and conscientiousness that I can think of.

I aim to limit my job search to jobs with a high (quantifiable) level of automated testing and CI/CD maturity, but the only strategy that comes to mind is filtering for this during initial phone screens. And perhaps setting an Indeed email alert for just the right key words.

I have to think that the best and brightest minds on HN can come up with some much better strategies.

View on HN

We’re hiring our initial team at Splitgraph [0] and are looking for senior backend engineers. We’ve put a ton of effort into optimizing our CI system and are always improving it. We’ve got automated build, test and deploys along with tools for rapid onboarding and cached rebuilds when switching branches locally. We can spin up a new cluster on AWS, GCP or Azure and deploy the code from any commit hash without any manual input except for pressing a button in the GitLab UI. We use a combination of Docker, Terraform, and Nomad for prod deploys. In dev we’ve got a Makefile based system that’s smart about when to rebuild images and makes it easy to switch branches without destroying your environment.

Developer productivity is our priority and the CI system is the foundation of that. (In fact I just spent the entire weekend optimizing the frontend toolchain and development workflow after the lessons learned from onboarding our first hires.)

If you like Python, databases, DevOps, etc. and don’t mind working at an all-remote early startup, please apply! Leave a note in the cover letter section of the form that you saw this comment. :)

[0] https://www.notion.so/splitgraph/Splitgraph-is-Hiring-25b421...

(Job posting also includes more details about the stack.)

I've been on such teams. Usually it was championed by some devops who just cared a lot about it and was willing to put in a lot of work to make it happen.

It's not all that great though. I'd say that, since it's usually maintained by devops guys, it's not fully designed with developers in mind. For example, the deployment to a CI is usually unacceptably slow for at least one seeminlgy unfixable reason (or perhaps the devops don't care enough, because the slowness doesn't hurt them as much). So, in practice, the CI is only used to run the automated test suite before the final OK on the merge and before that, you're better off running and testing things manually.

I’d argue you’re going to be more valuable if you bring your mindset and experience to a team that is small enough to influence and that doesn’t yet have good CI in place. But if you want to find engineering teams that brag on good equipment and processes, I’d suggest sifting through StackOverflow careers.

Based on experience, I’m of the opinion that teams don’t change - there is so much guidance on how to implement these practices available already that any team with the will has already done so.

This opinion might be excessively negative, but I’m coming off an experience where both the manager AND half of the devs on the team were on board, and we almost didn’t manage the needle in 2 years.

And I’ve read of others having to threaten to fire or actually fire team members to get the rest on board.

I will definitely check out SO Careers.

Totally understand. I just see someone who went through an experience like that, and think, he's learned a bunch of lessons that would make him great at moving to another slightly dysfunctional organization to help them do the same thing, and they'll pay to have someone who can help! But I get wanting to spend some time producing at a place that has its act together--and that you'd want to keep multiple kinds of engineering skills sharp and that requires working in a variety of roles.

I frequently don't see the organizational support for a proper CICD process. The people that hold the purse strings just don't understand the value.

There's an obvious set of prerequisite here:

1. what's your code coverage?

2. what's the branching strategy like (this is a long winded way of asking: are PR branches built automatically?)

3. how frequently do you release?

I guess this could be your "smoke test", without a reasonable code coverage you cannot have the PRs build automatically or a frequent release schedule.

If you ask an HR person about the frequency and get anything less than "frequently" you're likely dealing with an org that doesn't have 1/2/3. It seems unlikely that something like this would make it into a job posting though.

Reply on news.ycombinator.com