4 ms·

It's not as stupid as you make it sound. It is after all how normal manufacturing works. What you build is constrained by your assembly line. If you want to bui

by kitd 5y ago

It's not as stupid as you make it sound. It is after all how normal manufacturing works. What you build is constrained by your assembly line. If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on.

bob1029 5y ago
> If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on. We applied this ideology to our software project. Our build/deploy toolchain is 100% in-house code. Turns out, there's actually not a lot of it required because you can build a monster .net project into a single exe distribution with 1 simple command line operation. This applies to most other ecosystems as well. Everything else is basic file operations and moving shit between computers. No reason to vendor either of these problems out. The benefits of having bespoke CI tooling are difficult to overstate. We've got automated processes where a project manager can multiselect 20 different customers, select a commit hash, and schedule an email containing a link to a zip of the resulting build that will be delivered to each customer's configured IT contact upon completion - all with a single button press. This process also entails injection of customer-specific configuration that is pulled at runtime from another system into each customer's distribution. The email templates are configured on a per customer basis and email delivery is delayed based upon project parameters. I can't imagine wiring something like this up in Jenkins or GH Actions.
- jayd16 5y ago
  Sounds like the only hard part is a nice interface to select the customer IDs. You can just pass along that data to select build configs or what have you. How is the rest of the process not applicable to GH or Jenkins?

by kitd 5y ago

bob1029 5y ago

> If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on. We applied this ideology to our software project. Our build/deploy toolchain is 100% in-house code. Turns out, there's actually not a lot of it required because you can build a monster .net project into a single exe distribution with 1 simple command line operation. This applies to most other ecosystems as well. Everything else is basic file operations and moving shit between computers. No reason to vendor either of these problems out. The benefits of having bespoke CI tooling are difficult to overstate. We've got automated processes where a project manager can multiselect 20 different customers, select a commit hash, and schedule an email containing a link to a zip of the resulting build that will be delivered to each customer's configured IT contact upon completion - all with a single button press. This process also entails injection of customer-specific configuration that is pulled at runtime from another system into each customer's distribution. The email templates are configured on a per customer basis and email delivery is delayed based upon project parameters. I can't imagine wiring something like this up in Jenkins or GH Actions.

jayd16 5y ago
Sounds like the only hard part is a nice interface to select the customer IDs. You can just pass along that data to select build configs or what have you. How is the rest of the process not applicable to GH or Jenkins?