EPRI: Electric Power Research Institute

Software Development


Subscriber Website (SWS) Development Requirements

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 Script)

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:

  1. IT Intake Process
  2. 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.



  3. Obtain SWS URL and Design Approvals
  4. EPRI project manager must obtain approvals from:


  5. SWS Kick-off Meeting
  6. 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.)
    • JavaScript
    • PHP
    • Python*

    * 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.



  7. SWS Customer Experience (CX) Meeting
  8. Contact SQA to schedule a customer experience (CX) meeting with SQA, Digital Marketing, and Web & Mobile Solutions.

    The meeting will serve to:

    Note:

    • Download the EPRIMobileFrameworkv1.0.pdf for more information on the EPRI Mobile Development Framework
    • All SWS must be hosted on EPRI.com
    • Refer to the branding guide 4.1 for web browser requirements

  9. SWS Development
  10. 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 official repository.
      • 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 package manager (e.g. Nuget for .NET, NPM for JavaScript frameworks, Pip for Python, etc.).
      • 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 DB.

    You may request preliminary security scans in preparation for Step 6 to get ahead on remediating 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:



  11. SWS Security Scan and InfoSec Approval
  12. 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.



  13. SQA Usability Testing and SQA Approval
  14. 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 (81 KB).

    Approval from SQA must be received in order to proceed to Step 8.

    Notes:

    • 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.


  15. SWS Production Distribution
  16. 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.