8 ms·

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 u

by nikanj 8y ago

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-programmer/ https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

Aeolun 8y ago
If your CI breaks every time you change the build you are doing something wrong.
- solomatov 8y ago
  It usually happens when tests are not fixed.
  - nikanj 8y 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.
    - argyleaf 8y ago
      WiX is a nightmare from which I am feverishly trying to awake...
nradov 8y 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.
- adamlett 8y 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.
raghava 8y ago
Pardon me, but this reminds me of https://www.monkeyuser.com/2018/workaround/ 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.

by nikanj 8y ago

Aeolun 8y ago

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

solomatov 8y ago
It usually happens when tests are not fixed.
- nikanj 8y 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.
  - argyleaf 8y ago
    WiX is a nightmare from which I am feverishly trying to awake...

nradov 8y 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.

adamlett 8y 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.

raghava 8y ago

Pardon me, but this reminds me of https://www.monkeyuser.com/2018/workaround/ 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.