Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Fortunately for us, we don't have to worry about a hotfix/service pack; we're still on Delphi 5. :D</p> <blockquote> <p>Sigh, there was a time when an entire application (settings and all) would exist within a single directory - making this a non-issue. But, the world has moved on, and we have various parts of an application scattered all over the place: </p> <ul> <li>registry</li> <li>Windows\System</li> <li>Program Files</li> <li>Sometimes even User folders in "Application Data" or "Local Settings"</li> </ul> </blockquote> <p>You are quite right to consider the impact of hotfixes/service packs. It's not only RTL/VCL that could be affected, but the compiler itself could have been slightly changed. Note also that running on the same line of thought, even when you upgrade Delphi versions, you need to build using the correct version. Admittedly this is a little easier because you can run different Delphi versions alongside each other.</p> <p>However, I'm going to advise that it's probably not worth going to too much effort. <em>Remember, working on old versions is <strong>always</strong> more expensive than working on the current version.</em></p> <ul> <li>Ideally you want all your dev to be be on main branch code, you want to minimise patch-work on older versions.</li> <li>So strive to keep the majority of your users on the latest version as much as possible.</li> <li>Admittedly this isn't always possible.</li> <li>You wouldn't want to jump over to the 'new version' without some testing first in any case.</li> <li>Certain agile processes do tend to make this easier.</li> <li>By using a separate build machine or VM, you already have a measure of control.</li> <li><code>TIP: I would also suggest that the build process automtically copy build output to a different machine, or at least a different hard-drive.</code></li> <li>Once you're satisfied with the service pack, you can plan when you want to roll it to your build machine.</li> <li>It is extremely important to keep record of the label at which the build configuration changed. (Just in case.)</li> <li><code>If your build scripts are also kept in source control, this happens implicitly.</code></li> <li>When you've rolled out the hotfix/service pack, fixes to older versions should be actively discouraged.</li> <li>Of course, they probably can't be eliminated, but if it's rare enough, then even manual reconfiguration could be feasible.</li> <li><code>Instead of a VM option to keep your old configuration, you can also consider drive-imaging.</code></li> <li>To save on the $$$ of VMWare LabManager, look for a command-line driven VM Player.</li> <li>You might have to keep 2 "live" machines/VMs, but should never need more than that.</li> <li><code>It's okay for an automatic build script to fail because the desired configuration isn't available. This will remind you to set it up manually.</code></li> <li><em>Remember, working on old versions is <strong>always</strong> more expensive than working on the current version.</em></li> </ul> <h3>Third Party Packages</h3> <p>We went to a little bit more effort here. One of our main motivations though was the fact that we use about 8 third party packages. So doing something to standardise this in itslef made sense. We also decided running 8 installation programs was a PITA, so we devised an easy way to manually install all required packages from source-control.</p> <p>Key Considerations</p> <ul> <li>The build environment doesn't need any packages <em>installed</em>, provided the object and/or source files are accessible.</li> <li>It would help if developers could fairly easily ensure they're building with the same version of third party libraries when necessary.</li> <li>However, dev environments usually must install packages into the IDE. <ul> <li>This can sometimes cause problems with source compatibility.</li> <li>For example new properties that get written to IDE maintained files.</li> <li>Which of course brings us back to the second point.</li> </ul></li> <li>Since Third Party packages are infrequently updated, they are placed within a slightly different area of source-control.</li> <li>But, <strong>NB</strong> must still be referenced via relative paths.</li> </ul> <p>We created the following folder structure:</p> <pre><code>...\ThirdParty\_DesignTimePackages //The actual package files only are copied here ...\ThirdParty\_RunTimePackages //As above, for any packages "required" by those above ...\ThirdParty\Suite1 ...\ThirdParty\Suite2 ...\ThirdParty\Suite3 </code></pre> <p>As a result of this it's quite easy to configure a new environment:</p> <ul> <li>Get latest version of all ThirdParty files.</li> <li>Add _DesignTimePackages and _RunTimePackages to Windows Path</li> <li>Open Delphi</li> <li>Select Install Components</li> <li>Select all packages from _DesignTimePackages.</li> <li>Done!</li> </ul> <hr> <p><strong>Edit</strong>: Darian was concerned about the possibility of errors when switching switching versions of Design Packages. However, this approach avoids those kinds of problems.</p> <ul> <li>By adding _DesignTimePackages and _RunTimePackages to the Windows Path, Delphi will always find required packages in the same place.</li> <li>As a result, you're less likely to encounter the 'package nightmare' of incompatible versions.</li> <li>Of course, if you do something silly like rebuild some of your packages and check-in the new version, you can expect problems - no matter what approach you follow.</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload