Ask HN: Simplest CI/CD practices for startups? | Hacker News Reader

Ask HN: Simplest CI/CD practices for startups?

2 pointscamjw3 comments

First-time founder looking for some advice on the lowest friction way to set up CI. In the past I used Jenkins and a combination of Teamcity and Github actions, is there a consensus on what's the simplest/most boring technology to use for this? The rest of the techstack is a monorepo of django and a couple of (typescript) next.js apps, a variety of AWS services and I want to avoid pushing the boat out on stuff that isn't a value add but also want to make sure there isn't some great alternative that I'm not aware of.

At the moment CD is just me running "eb deploy" every so often which isn't great.

View on HN

Jenkins is good enough, any tool that you or your team already "knows" is good enough.

First, try to move any scripts that you might have and any dependency on yours or your team members workstation to a dedicated CI/CD tool (like Jenkins).

Second, from the beginning, make sure to follow the "best practices" on how to handle credentials and secrets. Don't add in plain text any credentials or SSH keys.

Third. from that point on, you can start looking at more complex tooling and/or deployment strategies (canary deployments, blue-green deployments, etc) to make sure updates on your applications won't break production.

CI/CD pipelines don't have to be fancy in order to work properly.

Makes sense! Thanks!

Opinions may vary, but I think it's nice to keep the developer experience concise and simple, and for continuous intregration to perform exactly the same steps.

That could distill down to as simple as the single-word command 'pytest' or 'tox' for a Python project, or 'jest' for Javascript (with all configuration bundled in the repo).

Then a platform that provides a straightforward transition from a command-line step to a pipeline job; both GitLab and GitHub offer that through their respective YAML configuration languages.

The nice thing about this - if you're careful - is that it avoids too much vendor lock-in. If needed in future, you can migrate to another service that allows running simple command-line scripts.

Some of this applies to continuous deployment too, but in practice that depends a lot on your infrastructure and service/process management (kubernetes, systemd, etc). It's possible to design that to make command-line CI/CD straightforward too, but a lot easier if you plan for it up-front, and more challenging to migrate to from another architecture.

Reply on news.ycombinator.com