Dev Test Deployment Process - Access Developers


	Back to Access Developers Comments List

Upload Images @Reply Bookmark Link Email Next Unseen

Dev Test Deployment Process

Kyle Rapp

2 years ago

Hello, I was wondering if anyone has best practices related to making dev changes and merging them into production.   (Richard...possibly a new tech help video idea?)

I do have a split DB but I kick users out to be safe, because I'm not exactly sure which types of changes would require a new front end file.    So, I guess this is a 2-part question.

1.Is there a list of which types of changes require a new FE file?
2.Is there a best practice that folks would recommend for the dev, test, release process?

Here is my current process:
1. For changes that will take lots of effort and testing, I make a copy of the DB files to a dev folder.  I make my changes in the dev copy, while the users continue to work in the prod DB.  This prevents me from kicking users out too long, but it means I have to do my dev work twice (once in the dev copy and then again in prod) or find a way to merge my changes into the prod DB instance.    When I am creating new tables, forms, reports, etc. it's easy because I just import them into the prod DB, but for changes to existing DB objects, I do the changes in the dev copy, test it to make sure my code works and then I kick the users out, take an up to date copy of the prod DB and do the same changes again in the up to date copy.

2. Before I take the up to date copy of prod, I ask users to close Access and once they confirm they're out, I make sure there are no locked DB files.

3. I move the 2 DB files to an 'Old' folder with the date.

4. I copy then copy the same files to a dev folder that users cannot get to

5. I then have to relink the tables because the BE file is now in the dev folder.

6. I make my changes in the copy in the dev folder.  (Could be anything from cosmetic changes to new tables, fields, forms, controls, VBA code, macros, queries, reports, etc.)

7. I do my testing, then run a compact & repair.

8. I have a table and form for version control, where I type in what's new in this version, including a date/time stamp.    (new record in the VersionControl table for each new version)

9. I copy the new DB files to the production folder on the server.

10. I generate a new FE file (ACCDE), and then for each user I delete their old FE file and place the new one on their desktop.  (I do this over the network and it's only a handful of users, so this part is not a big deal)

11. And of course, I backup the DB files before and after making changes, and the server get's backed up daily as well.

12. Then I let users know they can go back in.

I'm sure there's a better way and was thinking this could be a good tech help video if it doesn't already exist.

Thanks,
Kyle

Richard Rost @Reply

2 years ago

This is part of the reason why I developed the Access Updater because even for a small office, updating the front ends after making changes can be a pain. But, I usually keep an administrative ACCDB file, and that's the one that I'm working on making my changes. And then, when I'm done, I want to push the changes. Access Updater copies that to the server, and then the local workstations will pull that down, and it'll happen automatically. And yes if you're complicating things by linking to different tables while you're doing development then you have to relink tables too I don't personally do that but I keep some test tables on the server for making changes like that too.

Sami Shamma @Reply

2 years ago

I am a heavy user of Access Update. I use it on all my databases. I do have 45 users across the state. Before Access Update, I had a multitude of versions all over the place because updating the front end for everybody was a chore. Now, once I am happy with a version, and I am ready to send it out to my users, all it takes is a press of one button, and the next time any user logs in, the new front end will automatically install itself. It is an ingenious piece of software, 100% written in Access and nothing else. Before, it would take me weeks, sometimes months, before I sent out an update because I would dread having to do the upgrades. Now, I have been known to send out updates up to three times a week.

	Richard Rost @Reply 2 years ago
As far as "best practices" go, I really don't know. I should probably see what other people do. I just know what MY practices are having been doing this for 30 years. Is there a better way? Maybe. If you find one, let me know. :)

Kyle Rapp OP @Reply

2 years ago

Hey guys, Yes, I'm aware of the Access Updater and I thought about using it, but it only takes me like 1 minute to copy the new FE files over the network to the handful of users. (I totally get the value for lots of users.) The harder part for me is having to develop everything twice. (once in dev and then again in prod) I'm guessing some folks use the dev copy as the new prod and just do update and append queries to update any records that changed or append new records since the dev copy was taken, but that makes me nervous. So, I guess I'll just keep doing what I'm doing for now. :-)

	Richard Rost @Reply 2 years ago
If the trouble spot for you is just relinking your tables because you're using sample data you could very easily write some code that would relink all of your tables. I cover that in the Extended Cut for Relink Tables.

Richard Rost @Reply

2 years ago

Followup email from Kyle:

Hey Richard,  I hope you're well.  I wanted to follow up on a closed thread but didn't think it was appropriate to open a new thread for this.  I'm sure my question was confusing and I just wanted to let you know the light bulb finally lit LOL.

The biggest challenge I was having was doing lots of dev work and then having to do the same dev work again in the prod environment.    (mostly changing forms, VBA code, etc.)

This seems so obvious to me now, but it just occurred to me that because I have a split DB, I do not need to re-do the dev work in prod.  Instead, I just need to test my front end with a copy of the prod backend file.  If all goes well, I just copy my updated front end DB file to the prod folder and create/distribute new ACCDE files for the users.

My dev environment (an isolated NAS) has the same \\hostname\sharename\folder structure as the production environment so I don't need to worry about relinking tables either.

Obviously, if I had to make changes to the backend I would need to make those changes again in the prod copy of the backend DB file, but backend changes don't happen that often and tend to be very simple.   If I create a new table, I would likely just import said table into the prod environment instead of recreating it manually.

Thanks again,
Kyle

This thread is now CLOSED. If you wish to comment, start a NEW discussion in Access Developers.

Next Unseen

New Feature: Comment Live View