Handling different environments - staging vs production

Many applications have a staging environment and a production environment. What’s the best way to implement Product Fruits when your application is developed in this manner? 

With Product Fruit’s workspaces and the ability to copy content between them, this is easy to tackle. In fact, it’s just a matter of figuring out which approach you’d prefer.

One workspace approach

Initial content building

When you install Product Fruits into your application, you probably don't have much content created. If you want to deploy the code to your production environment but you still need to create content, you can go to Workspace settings and limit Product Fruits to be visible only for selected usernames.

These usernames are usernames you are passing via the JS snippet into Product Fruits.

Ongoing updates

To test content before deploying it to your users, you can utilize segmentation, creating a segment just for a specific username or email address. Once the content testing process is completed, the segment can be removed or changed.

An example of a segment for internal users:

Don't forget to check the Tracked Users section if the needed data are passed to Product Fruits.

Two workspace approach

Another option is to create one workspace for your staging environment, and then a second for your production environment. This allows you to create the content on your staging environment and then copy it to your production workspace when it’s ready to be shared with the masses.

Note that only tours and hint groups can be copied but other types of content should be easy to transfer manually.