Spike: Integrate the Customers Portal with GitLab.com
Background
As a group, we discussed some of the pressing issues for the Fulfillment team and Growth Section. We identified some architectural changes are likely needed to address some of the core issues in the Customers Portal. These larger issues cover both the customers experience using the Portal and the engineers experience developing features in the portal.
One of the biggest topics to come out of that discussion issue was the idea of integrating the Customers Portal directly into GL.com. This means moving the portal code into gitlab.
This is not the first time this idea has been discussed. Here are some of the previous issues/epics/discussions related to this idea:
- Move SaaS billing and account management into GitLab.com
- Make the Transactions Portal Invisible
- Mentioned by @chris_baus as part of the discussion issue
-
Growth Engineering Weekly discussion
- Discussion starts at 5:35 and concludes at 31:30.
Purpose
The purpose of this issue is to continue the conversation started regarding integrating the Portal into GL.com:
- Document the benefits and drawbacks
- Propose options of integrating the portal into GL.com.
- How can we iterate towards these options?
- Determine rough levels of efforts related to options.
This is intended to be a living document where everyone can contribute.
Pros / Cons
List the benefits and drawbacks to integrating the apps at a high-level, without regard to the question of "How".
Pros:
- Reduce/eliminate the need to synchronize data between the Portal and Gitlab.com
- Simplified user experience for purchases
- No confusing context switching between applications.
- Unified database between Portal and GL.com
- Single-Sign On for Customers
- No need for user accounts in each application
- Much easier for the Support Team
- Share resources (infrastructure, etc) with Gitlab.com
- Reviewer roulette
- Rubocop settings
- Helpers like MigrationHelpers
- Improved sales flow for sales-assisted GitLab.com subscription purchases
Cons
- Potentially increases the size of GitLab (this may depend on how we implement)
- Follow the GitLab release cycle (currently we can deploy things quickly)
- PCI compliance concerns
- Rate of background jobs killed in GitLab vs the Portal is much higher
How should we integration the Portal?
Here are some of the ideas I've heard discussed, but we should elaborate on these ideas and add others.
- Port the Customers Portal code into gitlab as GL.com? only.
- Create a new division/offering of within GL, similar to EE, where the Portal specific code would live.
- Port the Customers Portal code as a Rails Engine that would hook into the main GL application.