We develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).
For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.
It could be better, but it works for us.
The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.
The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".
What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.
Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).
We already have a customer portal where you can display any information you want for your customers. We also provide container and deployment logs, as well as alerts in the platform, so you can immediately see if an update failed and what went wrong. Release notes are already on our roadmap, and a lightweight issue tracker has also been requested.
Scheduled updates are currently not on the roadmap, but we’d be happy to scope that feature together and add it.
Thats a great idea, and was my original plan. However, it just didn't make sense given the time and level of the response. The audit report is pretty straightforward, and has all of the details. I assume the technical folks who want to go deeper will read the full report.
The response to the feedback and to give some background was what was needed on our side, and we wanted that to be accessible to non-devs as well.
More like giving formula for free to new mothers to begin with, and when they wouldn't produce their own (as there was no "demand") they would later need to buy more formula.
There was a stackoverflow question (IIRC) long ago on how to disable a mobile phone's camera shutter sound, and the answer was to record the sound, inverse it and play it when the camera is activated so that the two sounds cancel each other out. Not sure if it worked though, or if it helps in your case, as precise timing is needed for this to work.
Ok so this looks like something I would use for an app we're deploying on-prem. I'm thinking it would make new deployments/releases a bit easier if we could "advertise" upcoming features/versions and allow users to leave feedback, express their interest, or at minimum just let them know what's coming.
My questions are, can I use this without embedding your js, does it support vanilla js frontends, and how easy it is for marketing folks to build and maintain your newspage (eg starting from release notes in markdown).
I think answering these kind of questions in an FAQ on your landing page would help. I could get the gist of your offering by scrolling but no real "aha!" moment. Too much text for not enough info. (For me at least).
Also, really glad your site works without js enabled, bonus points from me!:)
The newspage (https://updates.supanotice.com) will work without JavaScript but the in-app widget that you see in the lower right corner on my page require JavaScript. However, it is completely framework agnostic and is based on web components. It will require that you add a script-tag in head and a tag in the body and you're good to go.
A FAQ for the landing page is on it's way and I will be working on improving the landing page with screenshots and examples so you can get a better feel for it.
I didn't know it worked without JS myself :-) I guess it's a side effect you get when rendering on the server using Elixir / Phoenix
We develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).
For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.
It could be better, but it works for us.
The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.
The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".
What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.
Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).
Is distr for us?
reply