Best Practices

Before personalizing your BigFix implementation, scan this list of known best practices and, when feasible, apply them:

Create a small test lab

Create a test environment, as similar as possible to your production environment. Use it to test and tune your custom content before rolling it out to production. You can use a virtual environment.

When feasible copy and edit existing content

Before creating custom content from scratch, consider making a copy of existing content and editing it to make it suit your needs. You can also download and personalize existing custom content available on bigfix.me.

Take one step at a time

Test each change that you do to ensure that it works as expected. Do not wait for the whole solution. To do this you can use proprietary tools such as the Fixlet Debugger or the Linux CentOS interactive sandbox.

Define success criteria and rollback procedures

Fixlets have no out-of-the-box rollback procedures, unless specified in the Post Action tab. Tasks do not re-evaluate applicability relevance; they succeed if all the actions they contain succeed. Be aware of these default behaviors when you create your custom content.

Broaden your point of view

If your real environment spans different geographies, take into account different localizations and languages. The relevance language can help you to inspect local settings or to implement variables.

Roll out to production in subsets of targets

Do this to easily manage unpreventable deviations and to fix them on a subset of targets, and also avoid potential overloading on the database.