3 ms·

This is an optimization. Production builds should be a full build. It is customary to have various optimizations in modify/save/rebuild/execute/verify loop.

This is an optimization. Production builds should be a full build. It is customary to have various optimizations in modify/save/rebuild/execute/verify loop. I, for one, don't even restart the app for most changes and use REPL to modify application at run time. I only rebuild it from scratch and restart from time to time to verify it all still works as intended.

ed25519FUUU 6y ago
Why not just rebuild and redeploy? That seems easier to me than an in-place hot fix.
- lmilcin 6y ago
  Because when you rebuild and redeploy you loose the state that you have in your application and then you need to put it in the correct state for you to test if your change worked correctly. Here is Shaun Mahood explaining this while building an application to do the presentation without even having to reload the page: https://www.youtube.com/watch?v=cDzjlx6otCU https://www.youtube.com/watch?v=cDzjlx6otCU
klodolph 6y ago
Production builds don't have to be a full build if you have high confidence that an incremental build is correct. You can achieve this in practice with Bazel and other similar build systems. I would have agreed with you five years ago. Depending on how long it takes to do a full build versus an incremental build, doing incremental builds for releases can make a massive improvement in developer experience. Just speaking from my own experiences here. Large C++ codebases in particular suffer from long build times.
- saagarjha 6y ago
  Production and development builds typically differ in optimization flags, though.
  - klodolph 6y ago
    Just make the build cache larger, so it can hold both versions.
- lmilcin 6y ago
  With the disclaimer that I don't know the Bazel and I have started over 20 years ago, I still think incremental builds are much more important for developer efficiency especially in environments and languages where they have to rebuild entire binary. Methods that can help you achieve that goal faster are more valuable than ones that are completely correct but require more time to execute. Most massive improvement in developer experience is if you can get feedback immediately without lapse in your concentration. Production build for me is something that happens in the background after I have pushed my code and moved to work on something else and so it has very little effect on my productivity. It is nice having it complete in seconds but it does not hurt my productivity significantly even if it takes a whole day, as long as I can continue getting feedback on my current coding task (ie. I have working local environment where I can fully test with little overhead0. At the most extreme example, I have worked on a credit card terminal where you needed a whole week to get the application built and deployed on a real device because it had to be built by a special compiler on another host and then once it builds it had to get approvals and get signed by external company. It of course did not affect my productivity in the long run as I found ways to quickly compile and run the functionality outside the real device.
  - paulddraper 6y ago
    Bazel, Buck, et al are for large monorepo code bases, where recompiling and retesting the entire code base for every changes is prohibitively expensive, even for CI.

ed25519FUUU 6y ago

Why not just rebuild and redeploy? That seems easier to me than an in-place hot fix.

lmilcin 6y ago
Because when you rebuild and redeploy you loose the state that you have in your application and then you need to put it in the correct state for you to test if your change worked correctly. Here is Shaun Mahood explaining this while building an application to do the presentation without even having to reload the page: https://www.youtube.com/watch?v=cDzjlx6otCU https://www.youtube.com/watch?v=cDzjlx6otCU

klodolph 6y ago

Production builds don't have to be a full build if you have high confidence that an incremental build is correct. You can achieve this in practice with Bazel and other similar build systems. I would have agreed with you five years ago. Depending on how long it takes to do a full build versus an incremental build, doing incremental builds for releases can make a massive improvement in developer experience. Just speaking from my own experiences here. Large C++ codebases in particular suffer from long build times.

saagarjha 6y ago
Production and development builds typically differ in optimization flags, though.
- klodolph 6y ago
  Just make the build cache larger, so it can hold both versions.
lmilcin 6y ago
With the disclaimer that I don't know the Bazel and I have started over 20 years ago, I still think incremental builds are much more important for developer efficiency especially in environments and languages where they have to rebuild entire binary. Methods that can help you achieve that goal faster are more valuable than ones that are completely correct but require more time to execute. Most massive improvement in developer experience is if you can get feedback immediately without lapse in your concentration. Production build for me is something that happens in the background after I have pushed my code and moved to work on something else and so it has very little effect on my productivity. It is nice having it complete in seconds but it does not hurt my productivity significantly even if it takes a whole day, as long as I can continue getting feedback on my current coding task (ie. I have working local environment where I can fully test with little overhead0. At the most extreme example, I have worked on a credit card terminal where you needed a whole week to get the application built and deployed on a real device because it had to be built by a special compiler on another host and then once it builds it had to get approvals and get signed by external company. It of course did not affect my productivity in the long run as I found ways to quickly compile and run the functionality outside the real device.
- paulddraper 6y ago
  Bazel, Buck, et al are for large monorepo code bases, where recompiling and retesting the entire code base for every changes is prohibitively expensive, even for CI.