4 ms·

Out of curiosity, how long do people think it takes to setup e2e testing infra and ci/cd? Because for my startup I'm building as a solo founder, it took me 2 we

Out of curiosity, how long do people think it takes to setup e2e testing infra and ci/cd? Because for my startup I'm building as a solo founder, it took me 2 weeks and I really just can't imagine working any other way.

MaxwellKahn 3y ago
I read the article as a general philosophy to spend more time on the product instead of premature scaling optimization. If e2e testing + ci/cd is cheap/easy and helps in your situation, then that's what you should do. I feel the author is more criticizing the CTO who prematurely decides to rewrite the infra to handle scaling to millions of concurrent customers before they have those customers.
AlotOfReading 3y ago
For my space, it takes months and hundreds of thousands of dollars minimum to build new testing infra from scratch. You get to choose how many of those dollars are spent on developer salaries vs vendor solutions [0]. [0] https://www.dspace.com/en/inc/home/news/engineers-insights/blog-vehicle-in-the-loop-sim.cfm https://www.dspace.com/en/inc/home/news/engineers-insights/b...
- brigadier132 3y ago
  Hardware is a different game.
deleted 3y ago
[deleted]
quickthrower2 3y ago
Yeah this startup stuff can feel like “don’t waste time buying a dishwasher for your cafe you just need to get coffee in people’s hands!”. Just buy the dishwasher you know you will need it. Unless the date is 1960 or something. The trick is: learn CI/CD at your job. When you work on your startup it will be a trivial thing. I mean you probably will be using Vercel or similar where it takes 120s to setup and deploy from nothing. Most of that time is npm install on your machine. What about other things? k8s for instance? Simple: if it is second nature to you then you can use it. If you can’t fix 99% of the issues on the spot then don’t. Pick something else.
vbezhenar 3y ago
For my projects I use containers. My rule is `docker build .` in the project directory must build the project and run all the necessary tests. It works for all technologies I had to use so far. Making `docker build .` run on push is not a hard task and probably could be done in a few hours with cloud services. I spent a day to write a custom github workflow to run it on our runner, but that's probably not needed for most people. After your OCI image is built, you can push it into the registry. I guess that counts as CI. Now E2E tests: I don't know anything simple yet. I guess I can hack together some script which will run docker compose and invoke that script with github push webhook. Probably would do it that way. Should work for not-so-complex projects.
theptip 3y ago
I view it more as a “% of resources” and “required number of nines uptime” kind of thing. If you’re a solo founder pre-PMF or even pre-customers, pausing feature work to build infra for 2 weeks is IMO often going to be excessive. If you have a couple engineers and you spend one engineer for one sprint to get things running automated for the next quarters push, that could be a good spend. The MVP of CI/CD is a few hours wiring up Gitlab/GH Actions. The MVP of e2e tests is more variable but a moving skeleton can be hours if no UI, days if including browser testing. However what makes sense for a first pass is very context-dependent.
opportune 3y ago
I imagine it would take me that long the first time having not set it up before, but that even if you started over from scratch it’d take you much less time. I made another comment to this effect, but I think testing and CI (not necessarily CD though) have such quick payoff times in terms of productivity that you almost always want to set them up ASAP.
andrewaylett 3y ago
Maybe an hour for something complex? Five minutes for a web project? Because I'm going to use GitHub Actions and Vercel and not spend time building something. This was a hard-learned lesson for me, because I enjoy toying with build systems. If I can get a project into production from the start, I'm much more likely to come back to it and keep working on it.

MaxwellKahn 3y ago

I read the article as a general philosophy to spend more time on the product instead of premature scaling optimization. If e2e testing + ci/cd is cheap/easy and helps in your situation, then that's what you should do. I feel the author is more criticizing the CTO who prematurely decides to rewrite the infra to handle scaling to millions of concurrent customers before they have those customers.

AlotOfReading 3y ago

For my space, it takes months and hundreds of thousands of dollars minimum to build new testing infra from scratch. You get to choose how many of those dollars are spent on developer salaries vs vendor solutions [0]. [0] https://www.dspace.com/en/inc/home/news/engineers-insights/blog-vehicle-in-the-loop-sim.cfm https://www.dspace.com/en/inc/home/news/engineers-insights/b...

brigadier132 3y ago
Hardware is a different game.

deleted 3y ago

[deleted]

quickthrower2 3y ago

Yeah this startup stuff can feel like “don’t waste time buying a dishwasher for your cafe you just need to get coffee in people’s hands!”. Just buy the dishwasher you know you will need it. Unless the date is 1960 or something. The trick is: learn CI/CD at your job. When you work on your startup it will be a trivial thing. I mean you probably will be using Vercel or similar where it takes 120s to setup and deploy from nothing. Most of that time is npm install on your machine. What about other things? k8s for instance? Simple: if it is second nature to you then you can use it. If you can’t fix 99% of the issues on the spot then don’t. Pick something else.

vbezhenar 3y ago

For my projects I use containers. My rule is `docker build .` in the project directory must build the project and run all the necessary tests. It works for all technologies I had to use so far. Making `docker build .` run on push is not a hard task and probably could be done in a few hours with cloud services. I spent a day to write a custom github workflow to run it on our runner, but that's probably not needed for most people. After your OCI image is built, you can push it into the registry. I guess that counts as CI. Now E2E tests: I don't know anything simple yet. I guess I can hack together some script which will run docker compose and invoke that script with github push webhook. Probably would do it that way. Should work for not-so-complex projects.

theptip 3y ago

I view it more as a “% of resources” and “required number of nines uptime” kind of thing. If you’re a solo founder pre-PMF or even pre-customers, pausing feature work to build infra for 2 weeks is IMO often going to be excessive. If you have a couple engineers and you spend one engineer for one sprint to get things running automated for the next quarters push, that could be a good spend. The MVP of CI/CD is a few hours wiring up Gitlab/GH Actions. The MVP of e2e tests is more variable but a moving skeleton can be hours if no UI, days if including browser testing. However what makes sense for a first pass is very context-dependent.

opportune 3y ago

I imagine it would take me that long the first time having not set it up before, but that even if you started over from scratch it’d take you much less time. I made another comment to this effect, but I think testing and CI (not necessarily CD though) have such quick payoff times in terms of productivity that you almost always want to set them up ASAP.

andrewaylett 3y ago

Maybe an hour for something complex? Five minutes for a web project? Because I'm going to use GitHub Actions and Vercel and not spend time building something. This was a hard-learned lesson for me, because I enjoy toying with build systems. If I can get a project into production from the start, I'm much more likely to come back to it and keep working on it.