1–10 of 68 posts
We have a single sandbox environment currently, but different customers are asking for varying amounts of delay before feature release. How do you manage bug fix deploys in these cases as well?
Charge them extra for a "staging" environment setup only for them and then deploy all latest stuff there for them to test. Then get their approval to apply it to their production environment. Charge well for this.
How would this work at scale? say if there were say 10 customers wanting approval, you'd have to have separate code release branches/versions for each customer? I imagine this could get error prone.
I suppose to your point on charging additional fees for this you can afford any sort of workflow.
In my experience it’s because if you roll out a new feature (or non-trivial UX change), that can wreck someone’s day and cause internal support issues into the company that uses your product.
Consider your rollout of new features to be least impacting, don’t confuse someone who’s using your product to get work done by changing something that breaks a workflow that worked yesterday etc.
You can put new features in new sections, or need special users to activate them.
In some cases we would show screenshots of upcoming features to hear about any other feedback, but otherwise focused on new features not being disruptive.
Have you clarified why they want this notice? In my experience it’s because if you roll out a new feature (or non-trivial UX change), that can wreck someone’s day and cause internal support issues into the company that uses your product. Consider your rollout of new features to be least impacting, don’t confuse someone who’s using your product to get work done by changing something that breaks a workflow that worked…
Seems like putting as many things that might risk this under settings/configurable as possible? This does extend development to have to gate everything in this way though.
Have you clarified why they want this notice? In my experience it’s because if you roll out a new feature (or non-trivial UX change), that can wreck someone’s day and cause internal support issues into the company that uses your product. Consider your rollout of new features to be least impacting, don’t confuse someone who’s using your product to get work done by changing something that breaks a workflow that worked…
Thanks for the reply - yea these are great points to consider and raised a few of them. Ideally rollouts benefit all customers, and the concern is that there is some possibility that something might not jive with them and they want the ability to do testing ahead of time. Seems like putting as many things that might risk this under settings/configurable as possible? This does extend development to have to gate everyt…
I’d dig deeper into the why with your customers, after we understood moving buttons around causes people’s day to be hard we did it only when really justified etc.
I wouldn’t hold up releases for customers, but do dig into the why more with your customers about why they want this notice, you may find it’s just an assurance something like a workflow isn’t totally different next Monday morning.
Also, you might look at cPanel's notices that they send out where they explain upcoming feature updates well in advance of the rollout. They also have different release cycles, where the newest features are released to the EDGE cycle instead of the STABLE, and then the long term release cycle remains unchanged except or security updates.
We did once have a customer with their own environment with a different version deployed, as they were initially a major client with such demands but after a few years it became clear it wasn't worth the maintenence effort to special case this one client so we made it clear in contract renewal one year that this would be going away.
Charge them extra for a "staging" environment setup only for them and then deploy all latest stuff there for them to test. Then get their approval to apply it to their production environment. Charge well for this.
Would you have the staging environment share data with production or have its own infrastructure? or use feature gating? One customer may not care that it shares the same DB, but another might. How would this work at scale? say if there were say 10 customers wanting approval, you'd have to have separate code release branches/versions for each customer? I imagine this could get error prone. I suppose to your point on…
That would be used for acceptance testing.
Bonus points for having up-to-date data in the staging DB.
I assume this is a multi-tenant implementation.
The other option is to charge the customer to disable unwanted features, in addition to enhanced features.
If it is multi—tenant, having the ability to ‘feature-gate’ could be worth the effort, if you can charge for enabling AND disabling features.