Subscriber Website (SWS) Development
For existing SWS sites:
For Database Requests: Complete the SWS Database
Request e-mail form and state the nature of your request (e.g. Restore, Back Up, or Run a
For Content Only File Changes: Check-in your content changes to GitLab and then submit
a GitLab Merge Request
For Code Changes or Structural Database Changes: Check-in your changes to the DEV branch on
GitLab, validate, merge your changes to TEST, validate once more, and then submit a software testing submittal package to SQA.
For new SWS sites:
To develop a new SWS:
SWS Kick-off Meeting
- IT Intake Process
Before you can start the Subscriber Website (SWS) process, you need to contact Jon Charles for an IT Intake Management consultation. The consultation will help determine if the SWS process is the correct process for your web deliverable.
- Obtain SWS URL and Design Approvals
EPRI project manager must obtain approvals from:
Email the completed SWS/Mobile App Kick-off Meeting
Checklist (201 KB) to SQA
SQA will schedule a kickoff meeting with relevant IT team member, Project Manager(s), and
Development team to review the SWS development and support plans (e.g., Operating Systems,
Platforms, etc.), Process Requirements (e.g., Pre-Production and Production distribution),
usability testing, and security testing requirements.
Subscriber Website must be compatible on the following stack:
- Microsoft Windows Server 2016
- Microsoft Internet Information Server 10
- Microsoft SQL Server 2016
Supported programming languages/frameworks:
- All .NET programming languages (C#, VB.NET, etc.)
* Note 1 Environment for Python-driven SWS must be discussed with SQA prior to starting
development. Pre-requisites and other dependencies may require approval from IT Management.
Note 2: Your application must be hostable on an IIS web-server. For example: python applications must be compatible with WFastCGI
Upon a successful kick-off meeting, approval to start development of the SWS will be given and a
GitLab repository will be created for checking in and automatically compiling/deploying code to
EPRI IT Servers.
SWS Customer Experience (CX) Meeting
Contact SQA to schedule a customer experience (CX) meeting with
SQA, Digital Marketing, and Web & Mobile Solutions.
The meeting will serve to:
- Align the SWS development with the overarching EPRI web strategy
- Review the SWS customer/user experience
- Prepare a demo or mockup of the site to share via WebEx if possible
- Review branding requirements:
- Determine next steps for the project
- Download the EPRIMobileFrameworkv1.0.pdf
for more information on the EPRI Mobile
- All SWS must be hosted on EPRI.com
- Refer to the branding guide 4.1 for web browser requirements
Once the CX Meeting and Kick-off Meeting have completed and all outstanding design issues have
been addressed, development of the SWS may begin.
The source-code for your SWS must be regularly checked in to EPRI's GitLab version control
system. This system will serve as an IT managed backup for the code as well as a continuous
integration (CI) system that will compile and deploy your code to EPRI IT managed web servers.
When checking in source code to GitLab there a few things to be aware of:
- The source code must be checked into the repository created and managed by SQA - this is the
- You may create your own, but it must be under a different name and you will still have
to check in your source code to the official repository.
- Repositories are for plaintext source code - checking in build artifacts and/or large binary
files (e.g. DLL, EXE, etc.) is highly discouraged unless it is absolutely needed.
- If your application requires third-party dependencies those will be restored via your
- Storing large non-plaintext files in these repositories will increase the time it takes
to clone and pull from them and is generally bad for version control best practices.
- When it's absolutely necessary to store large binary files (anything above 10 MB) Git
LFS should be used.
If your application requires a database, please contact the DBA
team with a backup file of your database so that they can restore it into an IT managed
You may request preliminary security scans in preparation for Step 6 to get ahead on
security vulnerabilities. Please note that findings in one scan could change in the next scan
due to the nature of the automated scanner - i.e. it is entirely possible that a subsequent
report could find vulnerabilities that the previous didn't. Multiple scans could mitigate this
risk, but there is no guarantee.
The SWS must meet all applicable EPRI product requirements before:
SWS Security Scan and InfoSec Approval
All SWS are scanned for security vulnerabilities using the Qualys scanner. For more
information on application security requirements please see the
Security Requirements page.
A remediation plan must be provided for any high or medium risk vulnerabilities found during the
scan. InfoSec may also require that certain low risk vulnerabilities be fixed at their
discretion. Developers must use the Remediation Plan
Template and submit the plan to InfoSec.
If only low and information vulnerabilities are found the report will be submitted by SQA to
InfoSec for their approval.
Approval from InfoSec must be received in order to proceed to Step 8.
SQA Usability Testing and SQA Approval
When the SWS is developed and ready for testing, request an SQA test (e.g., Pre-Production (Beta)
or Production (Final Acceptance)) by submitting the
Testing Submittal Package,
which must include the
SWS Promotion Checklist
Approval from SQA must be received in order to proceed to Step 8.
SWS Production Distribution
- SWS Developers must submit their code by checking it in to their official GitLab
repository created by SQA at the end of step 4 and having it checked in to the
TEST branch before usability testing begins.
- It is also highly recommended that the developer validates the SWS in TEST (e.g.
<sws-name>test.epri.com) before submitting to SQA.
- For more information regarding GitLab, send a message to SQA.
Once the SWS has received approvals for SQA Usability Testing and Security Scanning the SQA team
will schedule a promotion date (usually the week following the approvals barring any conflicts)
at which time the site will be promoted to Production and made externally available to members
and/or the public.
Note: The promotion checklist received in step 7 will determine how SQA promotes the
software. By default, we will promote the code and database from TEST to PROD as is, with the
only exception being necessary database connection config changes, unless otherwise specified.