Server Downtime Today for TLP's questioned

Since TLP's are not Live, how long will they be down?

All servers will be down for the same amount of time as they all use the exact same codebase.

All EverQuest servers, Test server, and services, will be taken offline for scheduled extended maintenance on Wednesday, July 12, 2023 at 5:30 a.m. PT*. This affects login, commerce, and authentication services. Read-only access on forums and websites will be possible. Please watch our socials or forums for updates! The estimated downtime is expected to last until approximately 12:00pm PT.

VS Today,

All EverQuest Live Servers will be brought offline on Wednesday, July 19, 2023 at 6:00 AM PT* for an update. Downtime is expected to last approximately 12 hours.

Patch notes for this update will be found in the Game Update Notes section of the forums once they are available.

I think you mean same database, they use feature branches for specifics like for the TLPs....

Same database is something many many folks have questioned as well but that was the previous reasoning.

You're both right, but a little off on the 'release branch' strategy.

The terms are company and strategy specific, but they are synonymous. A 'branch' (in this case the 'release' branch would be a fork of the repository (or codebase) with approved changes, but it would still be the exact same repo deployed to each of the servers. It would be gruesome trying to management multiple repos for a single product and that's an easy way to introduce more bugs between servers.

As for the SQL Server and their databases? We'd need to understand their architecture to speak on that. If I had to guess, it's probably safe to say they are using SQL Servers (clustered) with one primary and the others are replicated. Again the schema or relational blueprint is anyone's best guess.

No, a branch is different than a fork, branches are merged to produce a specific release, a fork is never merged back and honestly only used when a project is splitting and going in two different directions resulting in two different projects with the same ancestry.

Their codebase predates MS SQL Server getting any decent amount of capacity and scalability, I seriously doubt they would have spent time migrating to MS SQL Server without addressing their single database issue (google it or search the forums, this is the excuse used for a number of things like for instance, extended downtime for server merges....)

Branches or forks doesn't really matter as it would require multiple client programs if the TLP and live servers had different codebases.

No, only would require separate clients if they changed something on the client side. specific to a feature branch.... Yes, they all use the same master, you might stick with subjects you know something about.... not trying to be mean but you are not a developer, obviously.

Today is a patch day, which happens on a regular schedule once a month, virtually always the third Wednesday of the month. Code updates affecting gameplay take place on all servers with players, except for the Test server, which has its own schedule (because it is used to test patches before they go live). The wording of the notice has gotten sloppy, as all code patches are always applied to TLP servers as well as Live servers, since they will always contain things which bear on TLP play. It is one common codebase, with some branching logic as necessary for TLP and special server rulesets. It is rare for patch day downtime to be more tha six hours, despite what the notice says.

The first notice was for a backend update downtime, which happens irregularly, generally no more than once every few months. It will shutdown all DBG services for all games, because whatever they're doing is on the backend. They don't go into detail about what these downtimes accomplish, but it does not include any code updates for any game. Database software updates, server or network hardware updates or repairs, anti-cheat updates, account cleanups, or financial processing updates are all considered part of the backend.

All game code updates will (or are supposed to) have patch notes which get posted in the designated area of these forums.

While each change wouldn't always have a difference in clients what would be the point of having different code bases if there are no actual differences in the code? Not to mention that would double the work to make any changes as they would have to be made multiple times.

To support things like... FTE, Legacy Characters, Hierloom loot, DZ character based lockouts..... Randomized loot, Free-trade loot, etc....

It simplifies their work, each one of those is a branch off master with the changes that are needed to support said feature, when merged to create a release branch with master you get your actual codebase that you compile for said server set.

I think what you are trying top conceptualize is the master branch itself, which combined with any bugfix branches (each bugfix selected for a release gets merged with master to create a release branch) which results in the release for live as well as the starting point for feature branches for TLPs. This is a high level way it would be done using git as your cvs, no idea what Daybreak uses but most of not all use the same concepts.

It's a 25-year-old codebase, originated by rank amateurs with no previous enterprise-scale development experience. It's not structured the way you assume, not even close. If the game was rewritten from scratch using Unreal 4 or 5, then yes, the approach you suggest would be possible. That's not going to happen.

And all of those features can be used on live or TLP servers meaning they have to make the same code changes for both of them if they tried to keep the separate.

No, you do not get how git (or any cvs) works....

Things that affect the entire game are made only in master (well technically a branch of master that's merged with master), these are your bugfixes, mechanic changes, etc.

Things that affect a specific target release (for instance, a TLP ruleset) are made in feature branches that are merged with master for that specific release. They inherit all of the changes from the master branch they are merged with and only add or change things defined in the feature branch.

Ok so which is it?!?! LOL

Who did the math here. Is it 5:30am-12:00pm (which is 6.5 hours) or is it 12 hours which would be 5:30am-5:30pm?

Whether or not the engine is a COTs product like unreal or EQs homegrown engine that predates those is entirely irrelevant to code management and release management processes. I agree they probably did not structure their processes in this manner originally but I guarantee they do now. Any developer you hired in the last 20 years would push for this if it was not already in place. I myself have taken 30 year old code consisting of millions of lines and migrated to this process in under a week, and it pays off in spades in the long run.

And you would be 100% wrong, sorry. Therein lies the complete breakdown in understanding of so many posters here. A lot of EQ's codebase has literally not been touched since it was originally written 25 years ago.

One word: Cost. Before I retired I was making 10x what DPG pays now for a full-time developer. There are security guards making more than what DPG pays. Pretty soon McDonalds will be paying more than what DPG pays. It's sad, but we need to be realistic in how we analyze this.

What are you even talking about? If they have different releases for the different servers they are going to need a client for each of those releases as it is very unlikely that the same client would work for each of them.

What you are suggesting sounds like a lot more work to maintain then what they are currently doing.

That is not what I said at all..... as I said before, not trying to be mean, but you obviously know nothing about this.... here is some reading for you:

https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/
https://www.agilest.org/agile-proje...project managers,from writing over each other.
https://devops.com/source-code-management-best-practices/

well, I will just say, do a google search, tons of free source material for code management out there.