Developing in-house!

[Orlando]

Hi there.

I have been working as a custom developer for the past year and have just taken a position as an in-house developer for a small top medium sized company.

I just wanted to get some views and advice from anyone else out there that has or is working in-house on the best practise for developing an in-house system. Is it best to have a testing system running parallel to the live system? Or is working on the live system the best option?

Any other words of wisdom would be much appreciated.

Thanks in advance.

Orlando

[IdealData]

I have been an in-house developer for 7 years.

There are pros and cons on working on live systems, so you need to balance your decisions to suit the needs at the time. I have mixed live a parallel developmenmt during my time, more parallel in the early days as the changes I made were pretty significant, but more often now I do live development.

I am slighlty hampered by being on FMP 6/FMS 5.5 as this precludes making field definitions whilst others are using the files, although I test these on a parallel first then implement when uses are at lunch, or sometimes on my VPN link during evening.

Most of my system is SCRIPTED and I do not use FIELD LEVEL VALIDATION which permits me to make functional changes without interruption to services.

I'm sure many would call me foolish for doing live developments, however that is what is needed, but always with a backup before doing something major.

For the record my DBs now total over 60 with 700MB+ of data (no pictures!), 30+ users, mixed platform and 5 years historical records.

Good luck.

[Ender]

Live upgrades are less problematic with FM7/8, but whether they are allowed may depend on how stringent the internal IT procedures are for your company. Certainly there are concerns about not thouroughly testing a change, or making a change to a module that users are active in, and getting the users stuck in an incomplete process or layout.

In general, I do layout, script, value list, and privilege changes while users are in the system, being careful about what's being changed. Field and relationship changes, I try to save for when users are not in the file. I do major revision changes in an offline copy and substitute the new revision at night when I can close down the server and import the data. There are always the scheduled backups and older archives that can be used if there's a problem.

Developing testing procedures and documenting changes is a good practice to make sure that changes work as expected and that they can be undone or rebuilt if necessary.

[Orlando]

Thanks IdealData and Ender for your replies. This gives me allot to think about.

The main issue is there are no IT procedures as such at the moment and I want to, if I need to that is, specify them to everyone who developers the system and make development run smoothly and with as little fuss as possible.

I guess I need to look at the way I work, and the way the other developers work and come up with a structure on how to log and test development.

Thanks again.

[Ted S]

Like the others I've been doing in-house development for many years and I generally agree with what has been said so far.

It's kinda like working on your house. You can certainly paint, install new carpeting, build out the basement. etc while the family is at home but I wouldn't try to convert my 2 story into a rambler while mom, dad, and the kids watched on.

You always need to be thinking about what would happen if a user tried to use the feature that you are updating while you are updating it. I frequently will unbind buttons from their usual scripts and instead have the just display a "Under Construction" type message if there is real danger involved.

This ability to work on the live system and deploy changes worldwide immediately really puts FM in a good light in the eyes of management. Our core information system (non-FM) is updated semi-annually but with FM many changes can be deployed worldwide in just a few minutes.

Most business sell themselves as being quick to respond to changing conditions and customer requests but most software doesn't really support this notion. Filemaker truly does.

[Orlando]

Thanks Ted S

That is a very good point about considering users that are using the system as scripts are being amended and tested.

There are so many things to consider before making any changes and I suppose the user should always be in the forefront of your mind, as they are the people who will be affected by any changes.

To keep the discussion going, how do you manage your backups, do you keep copies of databases for weeks, months, years etc. Are DDR’s helpful when evaluating change requests and do you have any other words of wisdom you would like to share?

Thanks again guys, this has been really helpful.