 |
 |
 |
 |
Complete Guide and Reference Manual for UPS and UPD | |||
Chapter Contents¶
Chapter 20: Checklist for Building and Distributing Products
20.1 Pre-build Checklist
20.2 Build the Product
20.3 Test the Product
20.4 Distribute to fnkits as "test"
20.5 Distribute to fnkits as "current"
Chapter 20: Checklist for Building and Distributing Products¶
This chapter summarizes the steps for preparing to build a product, building it and distributing it.
20.1 Pre-build Checklist¶
- Create product root directory structure. Here is a comprehensive list of product elements and their suggested subdirectories (most products don't require all of them):
- README (top-level)files (top-level or ups )
- INSTALL_NOTE file ( ups )
- executables ( bin )
- table file and other installation-independent files/scripts ( ups )
- source code and build instructions ( src )
- test scripts ( test )
- examples ( examples )
- libraries ( lib )
- include files ( include )
- For shell scripts or pre-built binary products, put the executable file(s) in the ${UPS_PROD_DIR}/bin directory.
p<>. For products requiring build, create the file and include instructions for compiling, linking, testing and all other necessary operations, as well as for copying the final binaries into ${UPS_PROD_DIR}/bin . Insert the product source code into ${UPS_PROD_DIR}/src .
- Include documentation.
- Create/edit README (and INSTALL_NOTE as needed). See samples in sections 17.3.1 README , and 17.3.2 INSTALL_NOTE .
- Create/edit the table file (usually under ${UPS_PROD_DIR}/ups ). See section 36.7 Table File Examples .
- Create any extra scripts your product needs in ${UPS_PROD_DIR}/ups . See Chapter 37: Scripts You May Need to Provide with a Product for examples.
- (Optional) Declare the product to a local database (use the -d flag).
- Store the master source code and all the auxiliary files in a code repository according to your group's policies.
p<>.
20.2 Build the Product¶
- Verify that dependencies required for build are present.
- Build the product.
- Set permissions to a+x for scripts and other executables, and to a+r for readable files (if not already done).
20.3 Test the Product¶
- Run regression tests.
- Add it to fnkits (possibly as -d for development). If you're not registered to add products to fnkits . (Send email to compdiv@fnal to request authorization.)
# put it in kits, with no chain (or maybe with -d for development?) upd addproduct myprod v1_x -f Flavor -r /path/ -M ups -m myprod.table
- Make a scratch products area on another system, and install from KITS into that area.
# install on some test machine ssh other-machine setup upd mkprd /tmp/prodarea upd install -z /tmp/prodarea/db myprod v1_x -f Flavor
- Run regression tests on that machine.
# test it there setup myprod v1_x -f Flavor run-whatever-test # clean it back out rm -rf /tmp/prodarea
This ensures the product is installable and works elsewhere than where it was built, which is important.
20.4 Distribute to fnkits as "test"¶
- Since the product is already in fnkits, use the modproduct command.
# now chain it as test upd modproduct -t myprod v1_x -f Flavor
- Let people know about the product.
mail -s "myprod v1_x released as test" some_list@listserv.fnal.gov ...
- (Optional) Make a tar file of your product.
20.5 Distribute to fnkits as "current"¶
- Wait suitable time (amount of time depends on product).
- Fix problems found during test phase.
- Rebuild product.
- Commit changes to code repository.
- Put final release into fnkits as "current".
- Reinstall as "current" on fnalu , as appropriate.
- Check all the chains on fnkits (and fnalu ) to make sure that older versions, flavors, etc. are no longer chained to "current".
- Post news to fnal.announce.products , fnal.announce.unix (if it is a UNIX product), and fnal.sys.fnalu.announce (if installed on fnalu ).
- Send email to <product>-users@fnal.gov announcing current phase.
- Contact https://fermi.service-now.com/ to inform them about the new product or version. Include information on the kinds of questions to expect, if possible, and where to direct users for help.
| |
|
|
Last revised May 2014
| |
|
|
| |
Complete Guide and Reference Manual for UPS and UPD | |||
Chapter Contents¶
Chapter 20: Checklist for Building and Distributing Products
20.1 Pre-build Checklist
20.2 Build the Product
20.3 Test the Product
20.4 Distribute to fnkits as "test"
20.5 Distribute to fnkits as "current"
Chapter 20: Checklist for Building and Distributing Products¶
This chapter summarizes the steps for preparing to build a product, building it and distributing it.
20.1 Pre-build Checklist¶
- Create product root directory structure. Here is a comprehensive list of product elements and their suggested subdirectories (most products don't require all of them):
- README (top-level)files (top-level or ups )
- INSTALL_NOTE file ( ups )
- executables ( bin )
- table file and other installation-independent files/scripts ( ups )
- source code and build instructions ( src )
- test scripts ( test )
- examples ( examples )
- libraries ( lib )
- include files ( include )
- For shell scripts or pre-built binary products, put the executable file(s) in the ${UPS_PROD_DIR}/bin directory.
p<>. For products requiring build, create the file and include instructions for compiling, linking, testing and all other necessary operations, as well as for copying the final binaries into ${UPS_PROD_DIR}/bin . Insert the product source code into ${UPS_PROD_DIR}/src .
- Include documentation.
- Create/edit README (and INSTALL_NOTE as needed). See samples in sections 17.3.1 README , and 17.3.2 INSTALL_NOTE .
- Create/edit the table file (usually under ${UPS_PROD_DIR}/ups ). See section 36.7 Table File Examples .
- Create any extra scripts your product needs in ${UPS_PROD_DIR}/ups . See Chapter 37: Scripts You May Need to Provide with a Product for examples.
- (Optional) Declare the product to a local database (use the -d flag).
- Store the master source code and all the auxiliary files in a code repository according to your group's policies.
p<>.
20.2 Build the Product¶
- Verify that dependencies required for build are present.
- Build the product.
- Set permissions to a+x for scripts and other executables, and to a+r for readable files (if not already done).
20.3 Test the Product¶
- Run regression tests.
- Add it to fnkits (possibly as -d for development). If you're not registered to add products to fnkits . (Send email to compdiv@fnal to request authorization.)
# put it in kits, with no chain (or maybe with -d for development?) upd addproduct myprod v1_x -f Flavor -r /path/ -M ups -m myprod.table
- Make a scratch products area on another system, and install from KITS into that area.
# install on some test machine ssh other-machine setup upd mkprd /tmp/prodarea upd install -z /tmp/prodarea/db myprod v1_x -f Flavor
- Run regression tests on that machine.
# test it there setup myprod v1_x -f Flavor run-whatever-test # clean it back out rm -rf /tmp/prodarea
This ensures the product is installable and works elsewhere than where it was built, which is important.
20.4 Distribute to fnkits as "test"¶
- Since the product is already in fnkits, use the modproduct command.
# now chain it as test upd modproduct -t myprod v1_x -f Flavor
- Let people know about the product.
mail -s "myprod v1_x released as test" some_list@listserv.fnal.gov ...
- (Optional) Make a tar file of your product.
20.5 Distribute to fnkits as "current"¶
- Wait suitable time (amount of time depends on product).
- Fix problems found during test phase.
- Rebuild product.
- Commit changes to code repository.
- Put final release into fnkits as "current".
- Reinstall as "current" on fnalu , as appropriate.
- Check all the chains on fnkits (and fnalu ) to make sure that older versions, flavors, etc. are no longer chained to "current".
- Post news to fnal.announce.products , fnal.announce.unix (if it is a UNIX product), and fnal.sys.fnalu.announce (if installed on fnalu ).
- Send email to <product>-users@fnal.gov announcing current phase.
- Contact https://fermi.service-now.com/ to inform them about the new product or version. Include information on the kinds of questions to expect, if possible, and where to direct users for help.
| |
|
|
Last revised May 2014