Mockery for beginners

First of all.  You shouldn't have to.  Your management should help you get source control.  It's not always possible.  You might be under funded, you might be overworked, you might just have too much to do.  What you do now might work for you.  I work for a company that is only now after five years adopting source control.  That sounds crazy but it has worked in the main.  We have lost six or seven files in my five years there and we got them straight back, albeit without the new changes, from the live servers.

The biggest problem with not having source control believe it or not is not the actual the source code, you can keep that safe with backups, it's the developers.  Why should a developer work in such a precious environment where he/she can't make fundamental changes without worrying about restoring a good state.  Why should a developer work for a company that doesn't at least try to hit some of the twelve goals that Joel sets out as important for software development.  Source control being the first on the list.

Let's assume you'll get to implement source control at some point, you can't just install it and start.  It doesn't work like that.  The biggest thing you need to think about it process.  Should you sandbox, should you directly check out from the trunk to the live servers, should you make releases.  How do you do it now?

We currently have a shared development environment which is crucial if you have no source control, once again I am not abdicating having none, this should help you figure out how to work without it and how to move forward.

Anyway, we have a shared dev environment that people either use mapped drives, FTP, rds e.t.c to connect to.  Let your developers choose how they connect, let them choose how to work, it's more productive to give control out.  You as the manager or work coordinator will need to be aware of how work pieces affect each other and you should figure out a system of giving out work such that you won't get people over writing each others code.  It won't work perfectly but we have generally had people who work on parts of front end and people who work on core system code as our split.  The only overwrites we have had were on the front end stuff so we didn't lose business logic. 

Set up

You basically need three environments to run code, be it database, be it web code, be it server components.  At it's cheapest they can be on the same server, but they can't be literally the same files that run, perhaps you virtualize, perhaps your application runs on different ports from different locations.  Whatever your set-up, that's up to you, but you need to be able to completely separate a development, test and live environment.

The three environments

Development should be the box where everything happens to move the product(s) forward.

Test, this is essentially where you gain approval for your changes and projects before you make them live.  Your customers should not approve changes on the live or development servers.  You need sign off for everything you ever do.  Everything you ever do is for a customer, even if the customer is another programmer, IT manager, you e.t.c.  Even changes you make for yourself.  When doing this you'll still need someone else to approve your actual code but it's too early to talk about code approvals.  If you don't currently have a test server, you need to somehow provision one, in it's smallest form, it can be another instance on your development server, but ideally it will be a new box.  When you initially build it, you need to basically follow your instructions for building your live servers, as the test server should mimic as much as possible the live sites.  Never copy your development server to create a test server, if you do you will increase your problem/bug count over time.

The live environment

The live environment should be set-up as best you can set it up, everything you do to build it should be as scriptable as possible.  If the build is automated it will be repeatable, if not you need a process.  Just getting it running is not an option if you want your servers to respond in a predictable fashion.  You should never directly edit on the live servers, you should release via some sort of package, the most simple a zip file of the changed files in your package from test.  It will be tricky to try to get your DBA's to only do scripted releases to a database but you need to aim for it.  If all your releases are dated you should be able to get back to a particular date where you know the code/database structure is good.

Distinguishing between changes

You should go get a bug tracking system, but I'm assuming absolute minimum sign off from management/budget.  So go start a spreadsheet, each line having a unique number which becomes your change number and package number for releasing.  This should detail the change requested, the priority (1-5), the files modified, the action completed, the original estimate, the actual time taken and a column that figures out the difference between the two so your developers can get better at estimates, which in turn will make you better at telling customers when they'll get something.

Moving from Dev to a test server then live server

When you're done developing you will need to be able to package your individual changes/projects into file lists and db changes, these need to be moved from the dev server to the test server upon which they are to be tested.  I won't cover how to test them here, that's separate.  This same list should be the list you use to upload from test to the live servers.  It can't change, it shouldn't change unless you change it on dev and re promote to test.  If it does change testing needs to start again.  Try to package the files up in a zip or something similar in it's most basic form, this could also be used later to roll out to live.

Roundup

This is no real replacement for the gains that source control and release management can give you.  In reality you need to move to source control and release management so you can focus on developing systems.  When you get there you won't lose your dev environment or test environment, they'll just change function.  Dev will be come system integration and unit testing, and test becomes user acceptance and further unit testing, but we don't need to detail those yet.  For now just realise that your current throughput might slowdown when you get source control, people don't tell you that, but it's worth it.  You need it.  Generally you can get away without it but when you have a failure the time to get back to a working system can be massive.  With so many companies adopting disaster recovery, business continuity plans perhaps you can tell them source control is DR in a box.

\  # Sunday, August 20, 2006