Experiment: "Build iOS app guide" email campaign

What does this MR do and why?

This MR implements a campaign email experiment.

In !80361 (merged) we introduced a service running in the background to detect if a project is an iOS project. This detection happens every time changes are pushed to the project's main branch (much like repository language detection).

In this MR, when a project is determined to be an iOS project we send an email to the project's members with access_level >= DEVELOPER that contains a guide on how to build iOS projects within GitLab.

Database changes

Users::InProductMarketingEmail is updated so it can be re-used to record sending of campaign emails. Previously, this model was only used to record sending of marketing emails (Users::InProductMarketingEmail records with track and series attribute values) when users accomplish specific tasks during onboarding–e.g. user invites a teammate to a project.

This update comprises the following changes to in_product_marketing_emails DB table:

1. Remove NOT NULL constraints on track and series columns
2. Add campaign (text) column (for now it can only contain 'build_ios_app_guide'
3. Add unique multicolumn index on user_id and campaign to ensure that a user is sent a campaign email at most once
4. Add a check constraint to ensure that track and series are NOT NULL when campaign IS NULL OR track and series are NULL when campaign IS NOT NULL

Migrations

Rollback

AddTextLimitToInProductMarketingEmailCampaign

$ rails db:rollback
== 20220420034519 AddTextLimitToInProductMarketingEmailCampaign: reverting ====
-- transaction_open?()
   -> 0.0000s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE in_product_marketing_emails\nDROP CONSTRAINT IF EXISTS check_9d8b29f74f\n")
   -> 0.0062s
== 20220420034519 AddTextLimitToInProductMarketingEmailCampaign: reverted (0.0217s)

AddCampaignToInProductMarketingEmail

$ rails db:rollback
== 20220401071609 AddCampaignToInProductMarketingEmail: reverting =============
-- transaction_open?()
   -> 0.0000s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE in_product_marketing_emails\nDROP CONSTRAINT IF EXISTS in_product_marketing_emails_track_and_series_or_campaign\n")
   -> 0.0012s
-- transaction_open?()
   -> 0.0000s
-- index_exists?(:in_product_marketing_emails, [:user_id, :campaign], {:name=>:index_in_product_marketing_emails_on_user_campaign, :algorithm=>:concurrently})
   -> 0.0039s
-- execute("SET statement_timeout TO 0")
   -> 0.0005s
-- remove_index(:in_product_marketing_emails, {:name=>:index_in_product_marketing_emails_on_user_campaign, :algorithm=>:concurrently, :column=>[:user_id, :campaign]})
   -> 0.0046s
-- execute("RESET statement_timeout")
   -> 0.0005s
-- remove_column(:in_product_marketing_emails, :campaign, {:if_exists=>true})
   -> 0.0022s
== 20220401071609 AddCampaignToInProductMarketingEmail: reverted (0.0305s) ====

Migrate

AddCampaignToInProductMarketingEmail

$ rails db:migrate
== 20220401071609 AddCampaignToInProductMarketingEmail: migrating =============
-- change_column_null(:in_product_marketing_emails, :track, true)
   -> 0.0014s
-- change_column_null(:in_product_marketing_emails, :series, true)
   -> 0.0008s
-- add_column(:in_product_marketing_emails, :campaign, :text)
   -> 0.0037s
-- transaction_open?()
   -> 0.0000s
-- index_exists?(:in_product_marketing_emails, [:user_id, :campaign], {:unique=>true, :name=>:index_in_product_marketing_emails_on_user_campaign, :algorithm=>:concurrently})
   -> 0.0041s
-- execute("SET statement_timeout TO 0")
   -> 0.0005s
-- add_index(:in_product_marketing_emails, [:user_id, :campaign], {:unique=>true, :name=>:index_in_product_marketing_emails_on_user_campaign, :algorithm=>:concurrently})
   -> 0.0067s
-- execute("RESET statement_timeout")
   -> 0.0005s
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0003s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE in_product_marketing_emails\nADD CONSTRAINT in_product_marketing_emails_track_and_series_or_campaign\nCHECK ( (track IS NOT NULL AND series IS NOT NULL AND campaign IS NULL) OR (track IS NULL AND series IS NULL AND campaign IS NOT NULL) )\nNOT VALID;\n")
   -> 0.0018s
-- current_schema()
   -> 0.0002s
-- execute("ALTER TABLE in_product_marketing_emails VALIDATE CONSTRAINT in_product_marketing_emails_track_and_series_or_campaign;")
   -> 0.0010s
== 20220401071609 AddCampaignToInProductMarketingEmail: migrated (0.0444s) ====

AddTextLimitToInProductMarketingEmailCampaign

$ rails db:migrate
== 20220420034519 AddTextLimitToInProductMarketingEmailCampaign: migrating ====
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0019s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE in_product_marketing_emails\nADD CONSTRAINT check_9d8b29f74f\nCHECK ( char_length(campaign) <= 255 )\nNOT VALID;\n")
   -> 0.0011s
-- current_schema()
   -> 0.0003s
-- execute("ALTER TABLE in_product_marketing_emails VALIDATE CONSTRAINT check_9d8b29f74f;")
   -> 0.0008s
== 20220420034519 AddTextLimitToInProductMarketingEmailCampaign: migrated (0.0131s)

Screenshots or screen recordings

How to set up and validate locally

To test just the email itself, expand this to see instructions:

1. Start up your local GDK instance
2. In Rails console

   Notify.build_ios_app_guide_email('test_recipient@example.com').deliver_now

3. Visit http://localhost:3000/rails/letter_opener to see the sent email

---

To test the whole flow:

1. Ensure GDK instance is set up to simulate gitlab.com. In your terminal, run:

   export GITLAB_SIMULATE_SAAS=1 gdk start

2. Enable the experiment. In Rails console:

   Feature.enable(:build_ios_app_guide_email)

3. Create a project using iOS (Swift) template
4. Add a developer and a guest (members) to the project
   • Ensure that all users (owner, developer and guest) during testing are opted in to receive marketing emails and can receive notifications. You can check this in Rails console:

     user = User.find_by_username('username_of_user')
     user.email_opted_in? # should be true. If it's not then just do user.update({email_opted_in: true})
     user.can?(:receive_notifications) # should be true

5. Push a commit to the main branch (master) of the project. You can do this by just editing the README.md file using Web IDE and committing the change to master branch
6. Visit http://localhost:3000/rails/letter_opener and verify that:
   • the email is sent to the owner and the invited developer member of the project
   • the email is NOT sent to the invited guest member of the project

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.