Bala Shunmugam
Member
Can you list out the best practices om creating a release file?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Best practice on Release file
- Thread starter Bala Shunmugam
- Start date
1. Since it is not possible to create groups in the tree view on the Release tab, I recommend that you create a naming convention for the automations listed in that tree. All of the releases you generate will appear in the right-hand pane for each automatio. For example:
Tree View (left pane) Releases (right paneu)
Account Updates Account Updates_20201225_1111am.bprelease
Account Updates_20210105_0333pm.bprelease
Product Updates Product Updates_20210228_1023am.bprelease
Product Updates_20211617_0100pm.bprelease
In the examples above, Account Updates and Product Updates are your automation/project names, and each associated release for the automation is listed on the right. Date and timestamp the releases in the filenames in case you ever do more than 1 release for that automation on that day. Even if you think you will never do more than one release for a given automation on a given day, I promise you there will be times when you will need to do so. The date/timestamp will prevent your previous release file from being overwritten.
2. Create a folder structure for storing your release files on a network share that is accessible to your Developers and Release Managers (at minimum).
3. Organize your release file folder structure by organizational entity. Store the releases related to each org entity in the proper folders. For example, I work in a Bank and we have subfolders for Consumer, Commercial, Branch, Credit Card, etc.
4. When you create the Release Packages that your Releases are based on, you must include all components needed for the automation (refer to this link). Since BP does not include source control, I recommend that you always create a full release (from the Relese Package), and never use BP's ad hoc release functionality. This way, each release becomes sort of a restore point so that if you need to roll back for any reason, you can just import the previous release and overwrite everything to get back to the prior version.
Tree View (left pane) Releases (right paneu)
Account Updates Account Updates_20201225_1111am.bprelease
Account Updates_20210105_0333pm.bprelease
Product Updates Product Updates_20210228_1023am.bprelease
Product Updates_20211617_0100pm.bprelease
In the examples above, Account Updates and Product Updates are your automation/project names, and each associated release for the automation is listed on the right. Date and timestamp the releases in the filenames in case you ever do more than 1 release for that automation on that day. Even if you think you will never do more than one release for a given automation on a given day, I promise you there will be times when you will need to do so. The date/timestamp will prevent your previous release file from being overwritten.
2. Create a folder structure for storing your release files on a network share that is accessible to your Developers and Release Managers (at minimum).
3. Organize your release file folder structure by organizational entity. Store the releases related to each org entity in the proper folders. For example, I work in a Bank and we have subfolders for Consumer, Commercial, Branch, Credit Card, etc.
4. When you create the Release Packages that your Releases are based on, you must include all components needed for the automation (refer to this link). Since BP does not include source control, I recommend that you always create a full release (from the Relese Package), and never use BP's ad hoc release functionality. This way, each release becomes sort of a restore point so that if you need to roll back for any reason, you can just import the previous release and overwrite everything to get back to the prior version.