We have 4 "developers" that are using Dev Studio to build reports. For the past 3-4 months we have been doing all our development in the managed reporting environment on our development server and haven't been moving anything to production (all proof of concept development). We now are ready to start building out reports that will be moved into production. We have WF installed on a Development Box and also on a Production Box. I would like have the "developers" start doing their development locally using project folders in Dev Studio so we can use source control with subversion (and the push-OK plugin). I have a question regarding the setup for the Dev Studio IDE and I apologize in advance if I butcher the question.....I am not that familiar with IDE development and checking in and out objects (at least not in practice). While I want my "developers" to create their reports in project folders, I want them all using the same set of master files / synonyms and not having them all with separate master files / synonyms defined in their localhost environment. We will be employing some virtual columns in the synonyms and my concern is that the developers will not be consistent in setting these up if they were maintaining these in localhost. Is this feasible? Are there other options for doing local development and then checking in your work using source control. Any insights people could provide would be appreciated. I'd love to hear how other companies are using webfocus to promote procedures from one environment to the next.

Thanks.
Bob

Are you currently using Push-OK? We tried that and had a lot of problems just getting it to work with Developer Studio. DS always crashed. We are using Tortoise and that is not integrated, but we implemented manual procedures and the developers can see what has been checked out/in.

As far as the developers using all the same MFD’s, that can be done. I just ensured that only the MFD’s are created in a single App folder and there were not duplicates anywhere else. In our Dev environment, we have a standard folder where all the fex’s are stored for a particular project. Now each developer has their own folder to do any development in, but once they are ready for testing, they move their fex’s into the common folder. We only use MRE for launching and no real development happens in there. It was easier from our standpoint.

Once the developer is finished with their testing, they move their fex into a staging folder and leave it there. So now it’s in two places, the common folder and the staging folder. They also follow a procedure to check it back in to the SVN repository. Once a week we have a script that copies it (all .fex & .htm files) into our TEST and QA environments. It’s a scheduled time so our developers know when the cut of time is. We are lucky to have 4 environments.

Once our analysts have finished the QA testing, we have another script that will promote the entire common folder from our QA environment to Production.

They key to all of this is the SVN repository. Since a fex might be modified by different developers during different times, it’s important for a developer to keep their local copy of the trunk updated to the SVN repository. So they update their trunk first, then copy into DS, make their changes, copy back to their local trunk, commit changes into SVN and migrate into the common and staging folders.

For us, it’s been a success and it helps from the standpoint of the developers not stepping on each other, but the flip side since there are manual steps, we had to make sure everyone is following the correct procedures.

I hope this helps.