Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
First of all there's a BIG difference between build and deploy stages.
I'm not convinved that using build times to measure "successful engineering teams" is a fair metric.
Having a build that lasts a subjective big amount of time is not necessarily bad.
i.e. you simply can't build and deploy a business production ready Next JS App in less than 4/5minutes. But even it lasts 1h it's not an issue. You can build and deploy when it's ready, which will last <2min more or less.
Things you can do to optimize the whole release process:
Cache dependencies.
Split build and deploy stages.
As the project grows and you need more dependencies, there's more code to evaluate, minify, bundle.... the more time it will take to build. It's ok, nothing wrong here.
On the other hand, having a pipeline that lasts more than 2 minutes to deploy is something you need to look at carefully and optimize it to reduce the downtime.
Optimizing Build and Deploy stages are a different world.
Apart from caching dependencies to speed up the build stage the only actions you can
Check the dependencies and reduce it to the minimum necessary (that's one of the reasons to not begin a project with `npx create-react-app` or similar).
And on the deployment side you can:
Check your deployment method. Can you use a lighter docker image? Are you using a private server and deploying through FTP protocol or sFTP? Won't be better to use RSYNC instead?
Check the steps and log the amount of time spent on each. (Usually most of the time is spent in copying files).
Disclaimer: I'm not much into infrastructure and this comment is propelled by my observations as lead dev and conversations with the Infra and DevOps guys. So If I miss something or I'm wrong on anything please tell me so I can learn more. 😊
Passionate full stack web developer, course author for Educative, book author for Packt, he/him.
Find my work and get to know me on my Linktree: https://linktr.ee/thormeier
I'm not convinved that using build times to measure "successful engineering teams" is a fair metric.
This. I've seen enough insanely large Drupal projects with several gigs of database init dump import, cache warming, config and default content imports, XML imports and whatnot, that took up to 45 minutes until it they were considered built. The choice of framework and all code is actually sound, it just takes ages because they do a ton.
That's a great distinction to point out between the build and deploy stages. They can be optimized in different ways + have different expectations for how they'll run.
I used to work on a decently sized Gatsby site. Cutting out some dependencies and adding better caching took the final build from ~30 minutes to less than 10. They also added incremental builds to speed things up on smaller changes. The deploy step was always pretty fast -- unless it failed for some unknown reason...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
First of all there's a BIG difference between build and deploy stages.
I'm not convinved that using build times to measure "successful engineering teams" is a fair metric.
Having a build that lasts a subjective big amount of time is not necessarily bad.
i.e. you simply can't build and deploy a business production ready Next JS App in less than 4/5minutes. But even it lasts 1h it's not an issue. You can build and deploy when it's ready, which will last <2min more or less.
Things you can do to optimize the whole release process:
As the project grows and you need more dependencies, there's more code to evaluate, minify, bundle.... the more time it will take to build. It's ok, nothing wrong here.
On the other hand, having a pipeline that lasts more than 2 minutes to deploy is something you need to look at carefully and optimize it to reduce the downtime.
Optimizing Build and Deploy stages are a different world.
Apart from caching dependencies to speed up the build stage the only actions you can
And on the deployment side you can:
Disclaimer: I'm not much into infrastructure and this comment is propelled by my observations as lead dev and conversations with the Infra and DevOps guys. So If I miss something or I'm wrong on anything please tell me so I can learn more. 😊
This. I've seen enough insanely large Drupal projects with several gigs of database init dump import, cache warming, config and default content imports, XML imports and whatnot, that took up to 45 minutes until it they were considered built. The choice of framework and all code is actually sound, it just takes ages because they do a ton.
That's a great distinction to point out between the build and deploy stages. They can be optimized in different ways + have different expectations for how they'll run.
I used to work on a decently sized Gatsby site. Cutting out some dependencies and adding better caching took the final build from ~30 minutes to less than 10. They also added incremental builds to speed things up on smaller changes. The deploy step was always pretty fast -- unless it failed for some unknown reason...
ROLLBACK, ROLLBACK!
😂