How to survive without source control on web projects

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.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.