Development Process

Quote:

Original post by Michael Tanczos #1. We have a production server.. this production server should *not* be used for testing purposes and should only be used for production-level code.

Sounds good. I know I get nervous as hell even when doing an tiny little bug fix change to the current code base.

Quote:

One issue, however, is how these accounts get updated with the latest source from time to time without screwing up work in progress from a particular developer.

Hmmm. It seems that since we're treating development sandboxes as subversion working copies, then we can just do the normal svn update against the source files there. Since the update will mark any conflicts, we can just take it to a development forum whenever we get a file with C status on update.

Quote:

#3. We utilize subversion to store a production branch, staging and developmental branch (which can all change from time to time). When a developer is satisfied with their sandbox developments, they may commit code to the developmental branch. During times when we are nearing release, they may commit to the staging branch. The staging branch could represent pre-production code. This code will be bug-fixed until it meets quality requirements for production level code.

I think I understand what you mean, but the way this is phrased is kind of unhappy. Commits to the staging branch should probably be only bug fix changes, which means that working copies should be switched from that branch. (Given the assumption that the sandboxes are normally working from the development branch.)

Otherwise it sounds ok, but I don't envy the person in charge of handling merges between the two branches. On the plus side it sounds most likely that they'll be one way: from the staging branch to the development branch, and then after publishing the staging branch as the production branch, the development branch then gets copied as the new staging branch.

The major implemenation detail seems like it would be handling synchronizing the local working copies with the sandboxes. It seems like it would be easier to implement if subversion client access was performed on the local machines and then the developer just FTPs the files to the sandboxes. However, I think it might be less error prone if the sandbox was the primary working copy, and the devloper get/put files from there. Ok, that statement was about as clear as mud. Let me get some sleep and I'll try to rephrase it tommorrow.

Fleshing this out more..

Each sandbox is a svn branch. Developers do their work by checking in / out code as necessary. Is it possible to automatically publish updates to the sandbox as they are committed? This could allow us to not even need ftp.

When they finish a project they merge their code back into the development branch and resolve any conflicts as necessary (which most likely there will be few).

One thing to consider is that this may be overkill. The only thing we are trying to avoid is overwriting code improperly on the development end. For each staging release I think we don't really need to merge staging into production, but instead just create a new branch off of staging and call it production-1.01 or something and then continue to use the staging branch.

Man, so much to consider. All I need is suggestions for something that blends simplicity with getting the job done. I see no way around the sandbox approach at least so we'll need to have copies on a per-developer basis. Perhaps it really should be up to the developer to upload updates (from svn) there?

---
Michael Tanczos

What form of sandboxing will be done in regards to the database? I realize that running (~7) copies of the database would be well overkill, it would probably best to either have at least one full or mini copy of the database being shared by the development/gdnsrv01 copies (i.e. no development is accessing the live database)

Quote:

Original post by Michael Tanczos Fleshing this out more.. Each sandbox is a svn branch.

This sounds unhappy. A repository isn't stored in a form that the webserver would be able to read from directly, therefore the sandbox needs to be a working copy of one form or another, so why limit it to be branches? If someone is doing significant enough work on the developmental code to warrant an actual branch, let them manually do so through subversion. It seems like many cases just normal working copies of the development server would be sufficient. Too many branches swapping merges back and forth is even worse than trying to resolve C's from normal updates. True, you might have to deal with more conflicts that way, but in most cases, it seems better to deal with the conflict as early as possible rather than sit on it and suddenly find that you've no idea how the merge the branch. Not to mention that we'd start having two stage merges: let's say there's a bug fix committed to staging, that needs to get merged to development, which then needs to get merged to the sandbox branches. If someone wants to manage a branch on their own, let them, but forcing all the development on branches.... Ugh.

Quote:

Developers do their work by checking in / out code as necessary. Is it possible to automatically publish updates to the sandbox as they are committed? This could allow us to not even need ftp.

I've been thinking about this one, and come up with three options. One: presumably, you'd be able to wrap a svnclient in a webform with the necessary functionality to publish to the sandbox. Probably all you'd need is update and switch. The developer would commit the changes from his local copy, and the tell the sand box to update from the commit. However, this has the downside of requiring a commit for every change that needs to be tested on the sandbox, which, in turn, would mean needing a separate branch for each sandbox.

Two: If you wrapped more of svnclient's functionality in a web interface (either directly adding commands like add, delete, etc. or in a more automatic manner like TortoiseSVN) then you'd be able to modify the content on the sandbox and commit from the sandbox itself. This makes it easier to know that each commit is reasonable (has all the necessary files, etc.). On the other hand that seems like a good sized development project in and of itself.

The approach I'd probably recommend is each developer has normal subversion access to the repository on the gamedev server and manages the files in his sandbox by manual FTP. This should be easy to setup and doesn't lock us into the separate branch per sandbox thing.

I don't suppose there's a port of rsync that we could use on the server? :P

I don't think that it's a big deal any which way handling the staging and production branchs since presumably the changes would mostly all be one way, from staging to production. Just tagging a staging revision as production sounds like it'd be sufficient in most cases. You can mark my attitude on that point as carefully ambivalent; I don't believe any choice is really wrong for this case.

For the database, I'm liking Michalson's idea: make a copy of the current gamedev forum database and then running all the sandboxes and the staging server off that one database. With the addendum that we beat the crap out any developer who manages to corrupt the shared database, and deal with any problems then. Alternately, is the old gdnsrv01 database still compatible with current forum code? If so, we might be able to dig that guy out of mothballs and run with that.

I'm considering that we work with a full copy of the database like we did with development for all developers. I don't think we'll realistically be stepping on too many toes with database changes. At the same time, if we need to alter stored procedures I don't want to be causing the live site to stop functioning.

Also, I'm agreed on the branching idea. That looks like it's going to be very difficult.

So it looks like the easiest approach may just be to give developers the ability to checkout the repos. for at least obtaining source (as per sicrane's suggestion), and give them the responsibility of keeping their own sandbox up to date. They could create their own branches for experimental purposes and merge back if they choose.

I'm cool with that.. it seems to take all the headaches out. The one reason I could see for production, staging, and developmental branches is that in some cases you may uncover a production-level bug that you need to update. Though primarily bug fixing would be done in the staging branch as really it is created to prepare for a production release.

The general process is, anyway, to always have a production and developmental branch.. though not necessarily a staging branch. So I think at the time of release the staging branch gets tagged as production and any bug-fixes may continue if necessary. But the creation of the staging branch should basically be points in time where we feel that we've hit a critical mass that we want to focus on getting a release out. We can then fork a new developmental branch and use the existing developmental branch in preparation for a production-level release.

I'd rather not complicate matters by *always* having staging around during periods of development.

So another question..as we continue to experiment on a developmental version, what approach do we use to implement bug fixes made to the production version that aren't in the developmental version?

---
Michael Tanczos

I'm at ETCS right now, so I can't give much input at the moment, but please make sure Don gets in on these discussions. He's successfully implemented software processes for his own development companies, so I like to think he knows what he's talking about. If he doesn't know about this forum, then it would be wise to post a message to our mailing list about this. Thanks,

Kevin

Ok,

There is a lot going on in this thread, so I'll try to narrow it down. The primary problem is a coupling of branches to developers and sandboxes. Let's decouple and see if it gets simpler.

1) My preferred method for developers accessing the server would be through ssh. I tried setting up ssh earlier but it seem to have a problem with Server 2003. I just need to try that again so that it works with certificates. It worked with passwords, but that is annoying to have to type them in every time.

2) For the developer websites, I would prefer to add a private IP address (e.g. 192.168.200.100) for internal development and assign each developer a different port. When an ssh connection is made, you would forward local ports 80-8X to the remote IP address 192.168.200.100 (e.g. ssh dthorp@osiris.gamdev.net -L80:192.168.200.100:80 -L 81:....:81 etc) Then you would point your browser to http://localhost:80 or :81 and it would route to the server. This would prevent non-developers from accessing the sites. It would also allow you have another developer look at your site for testing and comments.

This is not as ideal as using PPTP, but I'm sure it would work. If I can get PPTP working with my firewall, then we could use it so that we don't have to do port forwarding.

Scripts could be written and maintained to make this transparent if we use ssh. It's really not as bad as it sounds.

3) With ssh access, more than 2 people can log in and run commands on the client so you could do an svn update to merge your changes to the server for testing...or if you like vim, you could make them directly on the server and not have to use subversion or ftp to transfer the files.

If I can get PPTP working, you could just map a drive letter and copy the files.

4) Subversion. In general, all development should occur on the trunk branch. Bug fixes, small changes, etc. can be committed as they are finished without causing problems. Development branches should in general only be used for massive changes or experiments.

Depending on the types of changes, we may decided to have the trunk and a bug fix branch if a major feature is going into the trunk. In that case, bug fixes would have to be put in the trunk and the bug fix branch.

The production site should be published from a versioned release branch. The trunk should have a site which we can test from before moving to production. It is effectively the staging area mentioned in the other posts.

Once bug fixes are commited developers should be able to update the trunk to make them live or we update the trunk periodically with a cron job.

Once we get far enough, I can produce a diagram that shows the subversion layout and workflow.

5) Developer workflow. A developer will have one sandbox on the server that we map an IIS site to. If that is too restrictive, then we can map 2 or more sites and just assign them different ports. That would allow each developer to have a trunk, bug fix branch, and personal branch live at any one time. We could use the following pattern Each developer is assigned a base port (e.g. 1100) then we would say personal 1100, trunk 1101, bug fix 1102, etc.

On each workstation, you will have one or more sandboxes checked out from subversion. You would edit your files there and copy them to your personal area on the server for testing. Once you are happy with the fix, you would commit it to the appropriate branch(es), update those sandboxes on the server and test them in context with the other fixes.

6) Database access. We should keep a copy that matches the current database + or - some period, say we do weekly or nightly replication. If someone does something destructive, we would just have to restore the copy. The next thing to do would be to create a small representative database that has enough data for testing, but is small enough to allow one copy for each developer. Ideally the database is created programatically so that a web interface could be exposed to allow each developer to restore their own database if they mess it up or want to restore it to its pristine state.

7) Project management. Coordinating bug fixes and features will require project management. Personally, I would like to purchase and use Jira ( http://www.atlassian.com/software/jira/ ). It would allow us to manage bugs and features and track our status. It would also help us decided what branches we have and how often we publish a release. This a large topic in and of itself that will take time to work all the issues out, but a good issue tracking system will help.