undefined | Better HN

0 pointsnikanj7y ago0 comments

For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop.

I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature.

There are numerous things that increase velocity for a large team, but decrease it when the product is just getting started. Joel Spolsky wrote about something similar almost a decade ago, https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

0 comments

Aeolun7y ago

If your CI breaks every time you change the build you are doing something wrong.

solomatov7y ago

It usually happens when tests are not fixed.

nikanjOP7y ago

It usually happens when changing the build means something like "Let's package the installers with WiX instead of NSIS, so we can provide MSIs for enterprise clients".

Not everyone's app is a web page.

argyleaf7y ago

WiX is a nightmare from which I am feverishly trying to awake...

nradov7y ago

That doesn't make any sense. Setting up the CI pipeline should be the first step, before writing any product code. It doesn't cost you any time, it saves time and allows for building more features faster.

adamlett7y ago

That sounds completely unrealistic and utopian to me. Before I even consider how to deploy a product, I want to experiment locally to find out if I even have a potential product. Most of my experiments never amount to being anything more than an experiment. If I had to set up a CI pipeline before writing any code, most of them wouldn’t even amount to that!

Maybe, if I were executing on someone else’s vision, I could justify taking time up front to set up CI. But I still think it’s a little dogmatic to state that this has to be the first order of business, always.

raghava7y ago

Pardon me, but this reminds me of https://www.monkeyuser.com/2018/workaround/

>> numerous things that increase velocity for a large team, but decrease it when the product is just getting started.

Irrespective of the team size, if the speed of delivery has to grow, a decent CI/CD helps make it faster, IMO.

j / k navigate · click thread line to collapse