R
Richard.thompson
Guest
Jeff, While we do have a custom deployment tool this is more related to our custom build process. Here is problem and the solution we are using: The application is nearly 40,000 objects; just over 20,000 compile as .w, .p, and .cls files. A single threaded compile takes hours. Because of this time investment the team tends to avoid a full build. This results in code changes breaking the application. Our build process is now mult-threaded; we use as many cores as we have available on the servers. I hand off the job to what we call compile agents for them to compile their little slice of the application. For a file system stored on the serve we have the full compile down to 8 min, network drive file systems take about 2.5 times as long. What we have designed now is an incremental build that only considers for the build any changes to the application since the last full build (nightly). The candidates for incremental build are all modified .w, .p, and .cls named objects and any compile object affected by a change to an include file. Our goal is to have the incremental build take just a few seconds (okay maybe a minute) to encourage the developers and gatekeepers to build more frequently. My concern with this plan is that while I have verified confidence that I can find all .p, .w, and .cls affected by an include file change or a schema change I am not confident I can find all the object affected by a change to a .cls. Thus my question to the group is offered.
Continue reading...
Continue reading...