| > But in my working reality, testing/building is a non-linear process that is iteratively run after some certain self-determined point-in-time. That’s not actually involved here. The actual process of coding can take place on a separate standalone project or even a whiteboard. But somehow all that code and everything associated with it needs to be packaged up for the team or it’s never making it to production. Further your process needs to minimally interrupt other team members or team efficiency tanks. How that’s done is up to the team but it needs to happen somehow and automation avoids headaches. I briefly worked on a project where we kept passing around updates to a VM, slow and bandwidth intensive but it did actually work. > "Production is, or should be deployable all the time," That’s a separate question. I am saying the code should be bundled with any needed environment configuration required to run that code. CI is a direct test of the process. > In no setup, do I think it's ever safe to take away the developer's agency and let some other process keep my local machine in "sync." There are so many variables to account for that some daemon/service can't be aware of, to allow for automatic updating (and again automatic updating != user running `git fetch`). Capacity is not a requirement. For developers it’s about being able to hit a big red button and get your local environment working rather than something you automatically do day to day. Onboarding, or coming back after 3 months on another project, etc shouldn’t involve someone trying to piece together all the little environment changes that people need to apply since the last time someone updated the onboarding document. In practice you might be reading a diff of some script and just apply that manually. But at least the sharing process is automated. |