Timeline for Build once or twice: how to synthesize advice from PHP's Composer package manger manual and Continuous Delivery
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 18, 2021 at 11:05 | history | bounty awarded | bdsl | ||
| May 12, 2021 at 12:04 | comment | added | bdsl | I just meant it doesn't feel ideal to me - surely you can't disagree with that? 🙂 | |
| May 12, 2021 at 11:19 | comment | added | Duroth | @bdsl In that case, I'd suggest interpreting "build only once" as "build only as many times as absolutely required". Yes, your Testing environment might require those Dev dependencies (PhpUnit or whatever testing framework you prefer), but you can (and should) reuse the single 'release' build on Acceptance, Staging, and whatever other environments you have set up in your specific CD pipeline. But Composer was pretty much created so you don't have to store build binaries indefinitely, so I'd have to disagree on it not feeling ideal. ;) | |
| May 12, 2021 at 8:48 | comment | added | bdsl | Great answer - will wait for other possible answers and see if I can think of ways you might not get enough consistency simply by committing composer.lock before potentially accepting. Committing the composer.lock file is another thing that almost everyone does, including me, but doesn't feel ideal. They say it's so that "in six months when reinstalling the project you can feel confident the dependencies installed are still working", which makes sense but I'd like to try handling that by keeping the composer.lock with the build in an artifact store for six months or more, not in git. | |
| May 12, 2021 at 7:58 | history | edited | Duroth | CC BY-SA 4.0 | added 1 character in body |
| May 12, 2021 at 7:28 | history | answered | Duroth | CC BY-SA 4.0 |