10 Replies Latest reply on Apr 23, 2012 10:16 AM by philmodjunk

    How to do rollout and integration from development to production?

    JasonPierce

      Title

      How to do rollout and integration from development to production?

      Post

      We have completed the basic function and design of our database and have given it to the data-entry workers to begin keying in records.

       

      We intend to keep developing features for the database (in a seperate development environment). Once we are happy with a group of features, how should we do a rollout and put it into production?

       

      Right now we have a single data-entry worker and might have 2 soon. We have a license for Filemaker server but have not yet set it up and configured it.

       

      Are there any good tutorials or guides on development cycle and transitioning from development to production environments?

       

      Thank you for your assistance,

      Jason Pierce

        • 1. Re: How to do rollout and integration from development to production?
          philmodjunk

          First, make frequent, sequential backups whenever you are doing development work on your file. This can be an automated process: Saving Sequential Back Ups During Development

          Next, consider using the data separation method to minimize the work needed to deploy updated copies of your database: Convert to Seperation Model

          Finally, write some scripts that import data from every table in the original file into the new, updated copy you are ready to deploy. Include script steps that update any auto-entered serial number fields to be at least 1 larger than the largest value in your imported data so that deploying an updated copy doesn't result in getting duplicate serial numbers.

          Get server deployed and working. Its automated backups can be a major source of added protection. (but you can also host up to 9 Filemaker users with a normal copy of Filemaker pro, so, for those "reading along" that haven't yet acquired a copy, you might want evaluate the cost benefit analysis involved before purchasing server.)

          • 2. Re: How to do rollout and integration from development to production?
            JasonPierce

            Thanks for the fast response Phil!

             

            Sounds like data-seperation is exactly what I'm looking for.

             

            How do I determine the appropriate location(Interface/Data) for my scripts? 

            • 3. Re: How to do rollout and integration from development to production?
              philmodjunk

              Almost all scripts would be defined in the Interface file. The only exception to that are any scripts that modify data and which must be performed with the "run with full access privileges" option. "run with full access privileges" only affects the current file so such a script can't modify data in a different file (such as the data file if access privileges would prevent it from happening.

              • 4. Re: How to do rollout and integration from development to production?
                JasonPierce

                When using data seperation model, where should table relationships be defined? I just realized that I have some relations defined in both my Interface and Data files... I think I would like to consolidate these to a single file if possible. It seems like it could get confusing to maintain with relationships setup in multiple files.

                 

                 

                 

                ======== EDIT =========

                I might have found the answer to this part of the question. I deleted all the relations in my Data file and things in my Interface file seem to be working fine still. Not 100% tested but leads me to believe that relations can be consolidated to just my Interface file.

                • 5. Re: How to do rollout and integration from development to production?

                  If you are using Filemaker Server or sharing files with Filemaker Pro you can modify your file while someone is working on it. Filemaker will lock out the changes that cannot be made while someone is editing a record and users cannot modify a record if you are making changes to the table.

                  If you are sharing the file using Filemaker Pro, use a standalone computer and do not use that copy of Filemaker Pro for anything but sharing the files.

                  Advising your user(s) that you are about to make a change and they should stay out of xxx tables or layouts is a useful technique.

                  Be sure to use Accounts and passwords so your data entry people don't have full access accounts. Limite Full access accounts to selected, well trained developers.

                  If you just have one person, one computer using the Filemaker file don't try the above. 

                  You can make a change to the file in use if you switch from data entry to full access and then back when finished. Make these changes when your clerk is on a break or out to lunch or assign a temporary task elsewhere. I've used this sit in their chair while they watch technique a thousand times. They tell me how to rearrange the tab order, move fields about the layout, change colors, etc. This makes them happier and more productive.

                  If you are using the GUI and DATA technique, then all you have to do is ask the user to quit and replace the GUI file when it is debugged or bugged, depending upon your point of view. Murphy says, "Delete One bug by adding Two Bugs."

                  • 6. Re: How to do rollout and integration from development to production?
                    philmodjunk

                    If you are using Filemaker Server or sharing files with Filemaker Pro you can modify your file while someone is working on it. Filemaker will lock out the changes that cannot be made while someone is editing a record and users cannot modify a record if you are making changes to the table.

                    Do that at your own risk. There are several issues you have to keep in mind:

                    a) Just opening the wrong dialog in Manage | Database will lock a table until you close it--even if you make no changes.

                    b) Scripts that modify data, if set error capture is enabled, can silently fail to modify data because you locked a table making your changes. Even if you do get a warning that data could not be modified, your data in multiple records could be left unmodified and figuring out which ones they are and how to correct the problem thus created may not be a simple process.

                    c) A network glitch coinciding with commiting changes to the hosted file can corrupt that file. File corruption is not always immediately obvious and significant time can go by (with lots of sequential back ups backing up the file along with the damage), before the problem is discovered.

                    d) Even if all things go perfectly, making changes to the design of your database can change the behavior of your system when your users interact with the file. Making such changes can literally catch them by suprise in in mid workflow--creating confusion and even errors in how they use the database. This can be especially nasty if you make a mistake updating a part of the design and your users blunder into it before you have a chance to test, detect and correct the mistake.

                    e) all told this is a lot like trying to repair your car without stopping the engine. Wink

                    Does that mean I don't make changes to the design of a file while it's hosted on a server? No.

                    But I weigh the risks, analyze the consequences and only proceed if it makes sense to do so. I never, ever attempt changes or examine field options while others are using the system. Locking an entire table just has too many potential problems. I wait until all users are out of the system (we have an 8 to 5 schedule for our work place--which makes this an easier option than a 24-7 user base) and make the change only when I am sure no one is actively attempting to modify data in the system. On the other hand, making small changes to a layout, value list or script I usually have no concerns over making them while others are using the system. But if there is any complexity to the change that I'm making, I'll first make the changes to a back up copy, test it to be sure I made workable, error free changes, and then I'll go forward with the updating the hosted copy to minimize the risk of adversely affecting the users.

                    I also have numerous back up copies being made (Hourly and nightly) and I archive selected copies on a monthly basis--allowing me to literally go back over years of copies of both data and interface to help reduce the risks of having problems with a damaged file.

                    Ultiimately, the more significant the change, the more likely I am to take down the file and replace it with an updated copy--with all data imported if it's a data file.

                    • 7. Re: How to do rollout and integration from development to production?

                      One other thing to avoid: trying to modify a currently hosted file over a cellular connection. Inevitably this will break and corrupt the file. Did it twice. The second time was just to verify...  :)

                      The only other problem I encountered other than agry data entry people who needed their speed fix, was the first time I modified an update script while someone was running it. I learned to ask first and insist that no one use that table for 5 minutes...  The script was modified in the middle of the update and naturaly it was the one where I corrected a bug by adding +1 to a date calculation or something like that. Half the file was updated correctly and half wasn't. But those were the days before Filemaker certification and I considered myself an explorer in uncharted waters...

                      One item not mentioned is that you don't need an 'official' two file solution to create GUI files. You can create a new file to access the data in the mother file just as if it were a Data only file. Filemaker doesn't care.

                      The easiest way is to clone your mother file. Then replace all of the TOs with pointers to the Mother File. If you do it right they will be in italics. After this is done and you can delete all of the tables as they aren't needed since the file will be accessing the tables in the Mother File. All of your scripts and layouts continue to work. This is the simplest conversion of all.

                      • 8. Re: How to do rollout and integration from development to production?
                        philmodjunk

                        The easiest way is to clone your mother file. Then replace all of the TOs with pointers to the Mother File...

                        But of course, that's why I posted a link that describes a step by step for doing exactly that in the very first reposnse to this post. Wink

                         

                        Convert to Seperation Model

                        • 9. Re: How to do rollout and integration from development to production?
                          JasonPierce

                          When using data seperation model, where should table relationships be defined? I just realized that I have some relations defined in both my Interface and Data files... I think I would like to consolidate these to a single file if possible. It seems like it could get confusing to maintain with relationships setup in multiple files.

                          ======== EDIT =========

                          I might have found the answer to this part of the question. I deleted all the relations in my Data file and things in my Interface file seem to be working fine still. Not 100% tested but leads me to believe that relations can be consolidated to just my Interface file

                          After some further testing I found some problems with deleting the old relationships from my Data file. I can delete almost all the releationships from the Data file, with the exception of any tables that use calculation field types relying on another table. In these, the relationship must stay present in the Data file inorder for the calculations to find the external fields they need.

                          • 10. Re: How to do rollout and integration from development to production?
                            philmodjunk

                            That is correct. And this can be a useful way to simplify your relationship graphs as the one in the data file will show those needed at the data level and the one in the interface file can be simplified to just those needed at the interface level.