Integrations Onboarding Doc

IntegrationOnboarding.md

Team Integrations Onboarding

Integrations Repos

NOTE: This assumes you already cloned Hosted and Ember while following the Localdev guide

1. Run the following command:

cd ~/dev && \
git clone git@github.com:ActiveCampaign/data-collection.git deepdata && \
git clone git@github.com:ActiveCampaign/webhook-service.git webhooks-service && \
git clone git@github.com:ActiveCampaign/zapier.git zapier && \
git clone git@github.com:ActiveCampaign/activecampaign-for-woocommerce.git activecampaign-for-woocommerce && \
git clone git@github.com:ActiveCampaign/app-wordpress.git app-wordpress

2. Follow along with the DeepData readme

3. Follow along with the ActiveCampaign for WooCommerce documentation

PhpStorm

PhpStorm is a JetBrains (as in IntelliJ) IDE for PHP. It will make your life easier.

1. Open a ticket with IT support
   • https://activecampaign.typeform.com/to/FEMWX6

SourceTree SSH Key Setup

NOTE: PhpStorm has a built-in Git client that you can also optionally use

1. Configure SourceTree to use your generated SSH key
   • https://apple.stackexchange.com/a/250572

QA/UAT Process (Hosted and Ember)

The integrations team has developed an internal process for QA-ing/UAT-ing our work to help ensure quality. The first step is to install darc (detached-arc). This should've been done automatically during the localdev setup; to confirm that, type the command which darc into your command line. If there's a result returned, then you have it. If you don't, follow the installation guide here.

IMPORTANT: This flow is only made possible by using feature flags for all new features. You must feature flag all new feature work so that it can be released darkly into production.

1. Create a branch in both the Hosted and ember-app repositories named feature/qa/{your username}. If you have your own fork of either repo, make sure to not create this branch on your fork of that repo.
2. Using darc, create a staging account with a name of your choice. Often we end up choosing the name qa-{your username}, but any name will do. Always set the password to 1q2w3e4r so that Product can access the account consistently for UAT.

darc account new qa-{your username}.staging.listfly.com 1q2w3e4r

3. Again using darc, put that account on the version feature-qa-{your username}. The version will directly map to the branch you've created in Hosted/ember-app and from now on any push/merge to your branch will be autodeployed to your staging account.

darc account version qa-{your username}.staging.listfly.com feature-qa-{your username}

QA for PRs

Once you've completed the above steps to create a staging account, you should use your staging account to QA every PR you open/review.

# 1. Fetch the hidden PR branch from GitHub
git fetch ActiveCampaign pull/<PR_NUMBER>/head

# 2. Check it out in a detached state
git checkout FETCH_HEAD

# 3. Make an empty commit with message containing the branch to be merged in (for posterity)
git commit --allow-empty -m "<branch name>"

# 4. Force push to your QA branch
git push origin $(git rev-parse HEAD):feature/qa/<your username> --force

You should complete these steps prior to approving a PR you are reviewing and prior to requesting a review of a PR you are opening.

UAT for Features

Once all the PRs for a story have been merged, it's time for Product to perform UAT on the story as a whole. Follow the above steps to get your QA account ready for Product to use and then move the JIRA story into the Ready for QA column. Update the story to include all steps necessary to confirm the acceptance criteria.

PR/MR Etiquette

NOTE: This is not true of Hosted and Ember which have highly codified PR rules that you should follow

Some of our repositories have PR templates - they're optional. We trust that you're capable of writing a well-informed PR message.

When merging a standard PR, make sure to select the Squash and Merge option to reduce the volume of commits.

When doing a develop -> master merge (or the opposite direction), first branch of off the target branch, merge the merge branch in, and then open a PR of your new branch into the target branch. For a develop -> master merge, this would look like:

git checkout develop
git pull remote develop

git checkout master
git pull remote master

git checkout -b develop-into-master-merge
git merge develop

git push --set-upstream remote develop-into-master-merge

For merges such as these, do not squash and merge.

Logs

To view logs for our team, use Kibana. Note, you must be on the VPN/in the Chicago office to access Kibana. By default you will be viewing logs for Hosted. To view DeepData logs, in the top left corner under the search box, click the dropdown that says hosted-v1* and select deepdata-*. You will now be searching through DeepData's logs. You can also repeat this process for viewing Zapier logs (zapier-*).

The darc notes look really good. Thanks for adding them. What do you think about the following changes?

Under step 2 "Using darc, create a staging account with a name of..." -> Add:

darc account new qa-{your username}.staging.listfly.com 1q2w3e4r

Under step 3 "Again using darc, put that account on the version" -> Add:

darc account version qa-{your username}.staging.listfly.com feature-qa-{your username}