SQA Intake Process
Before you start the development of your Subscriber Website (SWS) contact SQA to request an SQA Intake consultation. The consultation will help determine if your SWS will follow one of the processes below. If SWS is not the correct process, SQA will work with the Project Manager to select the best alternate option.
- Standard Website - See steps 1-8 below.
- Apps (e.g., Python) - Follow the Standard Website process with the exception of step 2.1.
- MediaWiki - Follow the Standard Website process with the exception of the step 2.2, step 3, and step 4. Preproduction submittals are not required for MediaWiki sites, however is available upon request. Prior to development, review the Wiki Development Guide (Internal to EPRI).
- Microsites - To request a Microsite complete the Web & Mobile Request Form in ServiceNow (Internal to EPRI).
For new SWS sites:
1. SQA Intake Process
Before you start the development of your Subscriber Website (SWS) contact SQA to request an SQA Intake consultation to determine if the SWS process is the correct process for your web deliverable.
2. Obtain SWS URL and Design Approvals
EPRI project manager must obtain approvals from:
2.1 Digital Marketing: SWS URL
2.2 Web & Mobile Solutions: SWS Design
3. SWS Kick-off Meeting
Project Manager emails the completed SWS/Mobile App Kick-off Meeting Checklist (201 KB) to SQA . If your source code and build instructions (Example provided) are ready by the kickoff meeting be prepared to share them.
SQA will schedule a kickoff meeting with relevant IT team members, Project Manager(s), and Development team to review the checklist and approve moving forward with the development process.
3.1 Standard Subscriber Websites must be compatible on the following stacks:
- Microsoft Windows Server 2016
- Microsoft Internet Information Server 10
- Microsoft SQL Server 2019
Supported programming languages/frameworks:
- Server-side languages/frameworks: .NET Core (C#, VB.NET, etc.), Python, and PHP
- Client-side languages: HTML, CSS, JavaScript
3.2 Apps (e.g., Python) Subscriber Websites must be compatible with the standard development stack (3.1) with the exception:
- Cannot utilize database, must be self contained. Utilization of independently-published endpoints is allowed (e.g., external API
or database that is maintained separately from the application). - Cannot utilize PHP
Upon a successful kick-off meeting, approval to start development of the SWS will be given and an On-Prem ADO repository will be created by SQA for the project team to check in source code, request pipeline development, run the Checkmarx Source Code Security Scanner, and compile/deploy code to EPRI IT Servers.
4. SWS Customer Experience (CX) Meeting
Contact Web & Mobile to schedule a customer experience (CX) meeting. Forward the approval to the SQA team for record keeping.
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 development requirements BrandEPRI (Internal use only), Web & Mobile UX v5.0, and EPRIMobileFrameworkv1.0.pdf
- Determine next steps for the project
5. SWS Development
Once the CX Meeting and Kick-off Meeting have completed and all outstanding design issues have been addressed, development of the SWS may begin. During this process you must upload your source code to the On-Prem ADO repository and request pipeline development.
To Request Pipeline Development: Email SQA the source code build instructions (Download example) to develop your pipeline. The pipeline configuration is crucial to the standing up of your site in the DEV, TEST, and PROD environments. SQA submittal cannot take place prior to the accessibility of your site in the TEST environment. Once the request is received an estimated completion date will be provided.
The source-code for your SWS must be regularly checked in to EPRI's On-Prem ADO version control system. On-Prem ADO 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, along with the capability of running a Checkmarx source code scan in the build pipeline. When checking in source code to ADO 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 Qualys Web Application security scans in preparation for Step 6 to get ahead on remediating security vulnerabilities.
The SWS must meet all applicable EPRI product requirements before:
- Nuclear sector SWS must include the Nuclear QMP Database Agreement Splash Screen
- Corporate
- Documentation
- Test Cases
- GUI
- Security
6. SWS Security Scan and InfoSec Approval
All SWS must meet certain Security Requirements, currently SWS submittals are scanned for security vulnerabilities using the Qualys and Checkmarx scanner. The Qualys scan will generate a report detailing the vulnerabilities found ranging from Level 1 to Level 5.
Action must be taken by the Project Manager and Developer for any Level 3+ vulnerabilities found during the scan. InfoSec may also require that certain lower level vulnerabilities be fixed at their discretion. To address the vulnerabilities you must take the following steps:
- Remediate the vulnerabilities and request and SQA rescan.
- Submit evidence that the vulnerability is a false positive for review by InfoSec. This can be screenshots, code snippets, other elements, or a combination. InfoSec will be looking for this for each represented vulnerability type that is in question. Please use the same input values that the scanner used, where applicable.
- Send a remediation plan (see Remediation Plan Template) to Information Security for approval. Please note this should only be completed after exhausting steps 1 and 2. The risks identified & plan within the document will need to be approved by project owner (accepting the risk) and IT stakeholders (TBD on case-by-case basis).
If no Level 3+ 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.
7. SQA Usability Testing and SQA Approval
When the SWS is ready for testing and changes are completed in the TEST environment, navigate to SQA Submittal and follow the instructions provided to submit your deliverable for testing.
It is required the Project Manager (PM) and/or Developer validates the SWS in TEST (e.g. <sws-name>test.epri.com) before submitting to SQA.
Approval from SQA must be received in order to proceed to Step 8.
8. SWS Production Distribution
Once the SWS has received approvals from SQA (Testing) and InfoSec (Qualys and Checkmarx Security Scanning) the SQA team will schedule a promotion date at which time the site will be promoted to Production and made externally available to members and/or the public.
The SWS 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.
For existing SWS sites:
For Database Requests: Complete the Subscriber Website Database Request e-mail form and state the nature of your request (e.g. Restore, Back Up, or Run a Script)
For Content-Only Changes: You must have already completed a deliverable pertaining to the SWS for the current year. Check-in your content changes to On-Prem ADO and then submit a ADO Merge Request
For Code Changes or Structural Database Changes: Check-in your changes to the DEV branch on On-Prem ADO, validate, merge your changes to TEST, validate once more, and then submit a software testing submittal package to SQA.