[noodles]

Reading this thread brings back a lot of memories about a variety of different ways in which I have edited source, and the environment and ways in which myself and my fellow coders have had to work.

Initially I worked on an LP MUD and the typical workflow was to edit files locally in whichever editor was available from wherever a coder was logged in, pasting in the file when the changes were complete. There was also an FTP server (which was pretty standard) and coders could upload files through that. This was cumbersome however as development had to be done communually on either the main game server, or the development server. The coder could easily make a typo which would introduce problems, requiring some way of reverting the changes (which hopefully they had manually backed up). Or the changes could clobber concurrently made changes by a fellow developer. Both of these situations occurred often.

This drove the MUD source code to be provided to coders, who could work on a local copy of the MUD. Development was now much more convenient. The problem of unreliable changes being put in place was lessened, but the clobbering problem remained.

Now I work on a MUD written in C. The code base is stored in a distributed version control system, where a central branch is used for the live version of the MUD. A process monitors the central branch and when a change is committed a new MUD server is automatically built.

The process runs a set of unit tests exercising the reliability and the stability of the compiled code. If there are failures, the changes are reverted and a notification email containing the relevant details (including the name of whomever checked it in) is sent to the developers mailing list. If the unit tests pass, it next runs the functional tests. These simulate use of the server by players, doing everything from creating new users, attempting different forms of movement through to staging combat and so forth. If this fails, the same thing happens as does for unit test failures. If it succeeds, then tentative server deployment starts.

The new version of the server is run, however it does not accept connections yet. What it does do is connect to the proxy server, notifying it that a new game server has been started and its version number. The proxy server then asks the existing game server to pause (notifying the players that a server upgrade is in progress), at which point the game server serializes the game state and hands it back to the proxy. The proxy then hands it to the new server, which attempts to fully recreate it. If the new server fails, it notifies the proxy and exits. The monitoring process detects the unexpected exit and processes the output, doing the unit/functional test failure activities, after which the proxy server resumes activity on the old game server.

If the new game server successfully recreates the state it was handed in a paused state, then it notifies the proxy which then proceeds to channel its connections to the new game server, and decommission the old server.

Anyway, back to editing. People can use the editor of their choice locally on their own game server running from their local branch. They can at any time engage the unit or functional testing locally. No more clobbering of changes made by others, except through sloppy merging. Coders are expected to have run the tests locally before checking into the central branch.