57 lines
3.2 KiB
Plaintext
57 lines
3.2 KiB
Plaintext
TODO related to Release
|
|
|
|
|
|
These are items that should be handled before release, a checklist of last minute stuff
|
|
|
|
ROCKFISH License key route stuff, make sure it's ready to make requests adn handle customers in real world scenario
|
|
RAVEN LICENSE KEY TRIAL
|
|
- make sure the various workarounds to enable trial key fetching are disabled / removed, see License.RequestTrialKey and various others
|
|
- Basically, if you remove the special CONST guid trial dbid value the rest of the code that needs to be changed should jump out due to compiler errors
|
|
|
|
DbUtil::DBIsEmpty()
|
|
- Check that shit was updated to ensure all relevant tables are involved
|
|
|
|
|
|
All dependencies in AyaNova.csproj project file should be locked down to a version release
|
|
- for example "Npgsql.EntityFrameworkCore.PostgreSQL" package should be set to a determined last change version
|
|
- Then test everything, confirm all ok, and no more changes to that file until determined after release it's safe to do so
|
|
- It should be a snapshot in time.
|
|
|
|
figure out the tiniest possible distribution and which docker container from Microsoft it will work with
|
|
- right now using sdk version on DO server because of fuckery, but ultimately it needs to be the minimal possible
|
|
|
|
Branch / tags / repository
|
|
- Need to figure out how to branch and tag properly so can start on next version without affecting release version
|
|
- In other words snapshot the release in the repo.
|
|
- Currently it's not an issue, but maybe it should be done properly
|
|
|
|
Remove widget route from release (or hide it) but keep in debug
|
|
(But...would it be handy for diagnosing things??)
|
|
|
|
DB INDEXES / PERFORMANCE
|
|
- Absolutely have to fine tune the indexes before release.
|
|
- Found a lot of useful info on examining index usage with postgres, there are some built in stats in PostgreSQL that show how indexes are being used and or not used properly or usefully
|
|
- A quick search should show many ways to query for used tables etc
|
|
- Monitor unussed indexes: https://jmorano.moretrix.com/2014/02/postgresql-monitor-unused-indexes/
|
|
- Many queries to do with tuning: https://gist.github.com/ruckus/5718112
|
|
- Useful for learning: https://www.datadoghq.com/blog/postgresql-monitoring/
|
|
-
|
|
|
|
DB CONNECTIONS:
|
|
https://news.ycombinator.com/item?id=18425923
|
|
wild_preference 2 hours ago [-]
|
|
The other half of this is correctly using the connection pool in the application layer to begin with.
|
|
One of the most common performance errors I see in random http applications is grabbing db connections for too long, like in middleware, or too aggressively in parallel queries.
|
|
reply
|
|
sb8244 2 hours ago [-]
|
|
This is so true and easy to overlook until a post mortem. A great exercise is to audit how connections are maintained in your application, before it's too late.
|
|
reply
|
|
macintux 1 hour ago [-]
|
|
I'm reminded of a systems failure described in, IIRC, the O'Reilly book "Release It!". Java ODBC exception swallowed resulted in eventually running out of connections.
|
|
Very tough problem to troubleshoot without extensive monitoring.
|
|
|
|
|
|
DOCUMENTATION TODO's
|
|
|
|
Do a search for "TODO" all caps in the docs, there are things that are on hold and need to be fleshed out.
|
|
Do not release with the todo tag in there still!!!! |