sdk-features

Commands

• npm run start - launches the local instance at http://localhost/pf/admin
• npm run build - creates a zip file that is appropriate for upload into the fusion deployment system. This is not using fusion CLI because of issues when running it within our jenkins instance.
• npx fusion nuke - clears the fusion cache
• npx fusion down - stops fusion
• docker ps - checks if all docker services have stopped running

Deployment

Due to some environment limitations, we will be using an environment set up in "staging" (under the arcsubs environment). The goal is to have a qa PageBuilder Fusion instance where we can host our sdk-features package, which in turn loads the "subs core components".

There are few caveats which you must keep mind when working on this in that environment:

• Since there is no CDN set up in staging, we will be using demo's CDN: https://api-demo-demo-sandbox.cdn.arcpublishing.com/ for QA.
• We will auto-deploy when QA is built.
• When develop is built, if you want to see the develop bundle in action, you will have to deploy it manually (unless we get 2 environments?)
• The final product (i.e. the product of building sandbox & production) will be a copy of our files being pushed to ArcSubs-Fusion-Features and tagged appropriately. This repo is meant to be shared with clients.

Development & QA

Our development & qa environment will be the pagebuilder fusion instance running in arcsubs.staging environmnent.

When building the develop branch, the bundle will be uploaded but not deployed, since (for now) this will be a shared dev & qa environment. To test things in the develop branch you will need to manually deploy the bundle and promote it (or preview it) from PB's Deployer screen.

When building the qa branch, the bundle will be uploaded and deployed, but not promoted automatically (because it takes a while for a bundle to fully deployed). To test things in the qa branch you should preview the deployed bundle called arc_subs_features_qa and promote it when you have verified that it will work. The goal is to have QA be the number 1 environment where manual testing happens.

The pages in arcsubs.staging are the following:

• https://arcsubs.staging.arcpublishing.com/pf/paywall/
• https://arcsubs.staging.arcpublishing.com/pf/retail/#/campaign
• https://arcsubs.staging.arcpublishing.com/pf/identity#/

Sandbox & Production

As with all our other products, sandbox & production needs to be adapted by our clients. Since the goal of sandbox and production deployments will be to provide a bundle that others can deploy along with relevant documentation the code will need to be pushed to a repository in the WPMedia organization so that others can clone it. The repository lives here: ArcSubs-Fusion-Features.

The repository should be seen as a feature pack that needs to be adapted to the needs of the client.

API Keys

To deploy to arcsubs.staging an API key has been created. This key is stored in our AWS Params store under /arc-subs/secrets/arcsubs-staging-deployer-token. It is also stored in Jenkins as a secret which can be used by invoking credentials('arcsubs.staging.token') in the jenkins file. You shouldn't need these unless you are setting up something up for deployment.

Documentation

The other part of the deliverable is documentation. This documentation will be found in the GETTING_STARTED.md file in this same package which will show a developer how to add the features to their own PB Fusion instance, configure it (set up pages, resolvers and templates as required) and also how to stay up to date w/ our latest releases.

It is critical that this documentation is kept up to date. Eventually we may need to consider moving this documentation to ALC rather than have it live in the file mentioned above, however for now, since it's a new document, it's more convenient for it to live here.