Creating and testing packages ID: PM-BP-CT
A little extra planning, organization, and testing can make your life easier and less stressful. This lesson contains tips on how to create and test packages to avoid those sinking “oops” moments.
- Simple packages are better.
- If your package must be complex, consider writing documentation for your package on a publicly-accessible URL.
- Break different components into separate packages with interdependencies. Each package should have a single purpose or function.
- Consider which assets should be mapped vs included directly in the package.
- The fewer dependencies (required or optional) that your assets have, the simpler your packages will be.
- Short and helpful descriptions make mapping assets much easier while installing packages.
- Do not put anything in a public package if you do not have the right to share it with everyone.
- Do not copy anything from another source without first obtaining written permission.
- To use someone else's code you should include their package as a dependency. If their code is in a private package then yours should be, too.
- Test all packages in public packages for high code quality and value. If it does not provide sufficient value or meet minimum quality standards consider either waiting to release it or keep it private instead.
- When sharing private packages, the most specifically you can share your code the less likely it is to get abused. But the more generally you can share your code the less work you will have to put into managing access.
- Grouping similar private packages into private collections will reduce the work required to managing sharing.