Hello IPP developers, my name is Jarred Keneally and I am a developer support engineer for the Intuit Partner Platform. After receiving quite a few inquiries as to the best way to setup a co-development IPP project, I though I would blog about the way to do that.
You should know we are working on exciting new developer tools to manage your IPP Projects in release 1.4. Until that release arrives, here is what you can do in the meantime. Please keep in mind this process is only temporary.
These are the steps that are typical of a new IPP project in Flex Builder:
1. Someone creates a “build” account on workplace (hereafter referred to as “build engineer”)
2. Build engineer creates a database using the native workplace UI
3. Build engineer creates a new Flex project in Flex Builder
4. Build engineer converts said Flex application to an IPP Application by Adding the IPP framework to the new project
5. Build engineer configures the IPP Project using the wizard
a. Calls the Project 1.0
b. Creates and/or Assigns an AppToken
c. Points to, the dbid from Step #2 to create the Development Master (normally, they’ll always just use Find DBID here)
d. Saves the IPP Project
6. Build engineer runs the DTO generator.
7. Build engineer adds all of the files to CVS/P4, excepting binaries and the DevEnvironment.xml (shouldn’t be one at this point if my memory is correct)
8. Build engineer invites his team, DevA, DevB and DevC to be admins to the Development Master (same dbid as is found in the IPP Project editor wizard)
9. STOP: Combine all logins under Build Engineers Account: All workplace logins that want to deploy this app need to be added to the build engineers account. This process is only temporary.
a. Please submit a support incident with build engineers email and the emails of the other Workplace logins to be added to the account. Click Here to Submit an Incident
10. DevA, DevB, DevC check out source code from CVS/P4
11. DevA, DevB, DevC build code and deploy to their dev environments… This will create their development sandboxes. It will also create the DevEnvironment.xml file
12. DevA, DevB, DevC make enhancements that they check back into CVS/P4, etc, but they never check in the DevEnvironment.xml file
13. When a Q/A build is desired (or any other deployment or publishing operation) then Build Engineer comes back into the picture
14. Build Engineer checks out all code and deploys to Q/A, Stage, or publish.
*When someone changes the schema, it will be the schema of the dev master. That person must regen the DTOs and check them in. The other devs must then refresh their project with those new DTO files. The Dev Instance DBs will get updated automatically.
**The schemaVersion is what triggers the whole thing. Until there is a difference between the compiled version (SchemaVersion.as) and the sandbox’s schemaVersion dbVar, no schemaUpdate command will be executed. This is exactly the desired behavior because a developer may be in the middle of a task and not want his sandbox to be updated. So long as he doesn’t sync code his wishes will be law.
***In Dev the QAR is deployed to the sandbox and never to the master. In the other environments the exact opposite is true—you deploy the QAR to the master and when running the application the executable is automagically pulled from the master. It is this difference that allows multiple developers to have different code bases
****Technically any of the developers can deploy to Q/A (etc) but this is probably poor practice. Future versions of the tools will have role assignments to enforce the concept of an “authorized” deployment manager. Every developer, however, can deploy to his/her development sandbox as that is limited to their own development area. If they want, they can also start over this away simply by deleting the DevEnvironment.xml file and doing a Synch operation, or by running the IPP Project wizard and re-cloning the Development Master.
Happy Coding
Jarred
Leave a Reply