While under development, a few times a week (every time a new feature is ready to be rolled out), and I do it manually (publish in visual studio -> Remote Desktop to the server, replace files)
Thanks! I'm curious about your use case and specifics about how you're looking at start date and how often you'd expect to update it (i.e. is this a one-time cleanup or a regular thing?). I'd welcome an email with some details!
Yes. My point is doing this all the time is, generally, a waste of time. I recommend turning off automatic updates, do it on a schedule. Weekly is too frequent. I have some servers I update yearly. That may be too long. At a previous startup, we had boxes that hadn't seen an update in 3+ years.
It's a balance between keeping your machine up to date, and not inconveniencing the user.
That said, I do struggle to understand why MS can't rework the deployment mechanisms to just stop/start services etc to allow for on-the-fly upgrades in the background, instead of doing it all at a reboot.
This is very different at the moment, not only you could have patch updates for the modified properties but you could also perform rollback in case something is rejected by the server and so on and on.
Incrementally, every time I make a small but significant change. I treat it like a super-save, so I can get that latest slice of work back if the disk on my dev machine dies. (The dev machine is currently a Linode.)
30 seconds is too often. Once a day isn't often enough.
This right here. Most of the time you just need to rebuild your image. If the project is being actively developed and built, nothing to worry about. (Unless you pin to a very specific OS version of course).
If it's not, you just need to trigger a build every so often. Maybe this could be a feature PaaS offers in the future.
Isn't that the wrong approach? That's not something to do hourly, that's something you do once when deploying the site, and then again when you update the libraries. Which you host locally. If the code on your site happens to change every hour there is no way you have a chance to assure security.
Actually using dynamic versions (i.e. 1.3.+) are cached for 24 hours (unless you override the default). So you typically just pay the penalty for looking for new versions once a day.
Luckily we have "update nights" at most once every other month. But the workflow you describe is what I would want in the end. I work in a small startup tough so change is happening rapidly to make these processes better. It's far from institutionalized!
We do however have a staging environment already that is frequently updated and updates available within an hour from starting the update.
Disagree, you have to continuously update production servers (not daily, but ~weekly/monthly). The more often you do it, the more automated and risk-free it is, and the smaller the version gap for when that critical security vulnerability hits that needs to be patched ASAP.
It's not the frequency of updates, it's the control. I can easily ignore an application update until any arbitrary standards I require are satisfied; whether those standards are "ok, 48 hours have passed with no security alerts" or "my company's professional auditors have reviewed all code changes" is up to me.
(Unless there's a breaking change on the server side, but precisely because app updates are not guaranteed, app backends are much more conservative than web backends).
Controlling the updates for a web client might not be totally impossible but it's far, far more difficult and clumsy. Best case is it's a full SPA so you can just save the resources locally, but it's using classic server-side rendering with just a single chunk of client-side JS used for encryption... And of course there are no clearly announced and numbered releases, you need to keep refreshing the page to know when an update is deployed.
We have a productized SaaS, where the product UIs are sometimes updated several times a day each (we have a couple dozen products now and growing). The backend driving the products is updated usually on a weekend after a 2-week sprint. It works out pretty well for us, and we rarely feel rushed to get something out. There is the odd hotfix for a critical bug - that happens maybe once every two months or so.
reply