LINCS Technical Partner Roles & Responsibilities

The LINCS System is maintained under contract with CivicActions with funding from the U.S. Department of Education (ED), Office of Career, Technical, and Adult Education (OCTAE), under Contract No. ED-EVP-O-16-F-0001. CivicActions is responsible for maintaining the LINCS Systems websites and related hosting.

Please coordinate with your COR to schedule a meeting to discuss support options for your specific contract.

LINCS Technical Support Services:

Based on the requirements of your contract, CivicActions under the LINCS project can provide:

  1. Landing Pages within the LINCS Drupal site

    1. Access to the LINCS Content Management System for project landing pages, project personnel must work within the Drupal platform and take LINCS Security Training.

  2. Access to the LINCS Learning Portal (Learning Management System) for course development

  3. A production server (if appropriate)

    1. A functioning Drupal environment running off the production branch of the project's git repository.
    2. Security
      1. As a deployment best practice, separation of duties in IT helps to minimize risk. Meaning, permissions should be limited in the production environment and not easily accessible. Limiting access to the production environment protects the security of the environment.  Direct access to the production environment is available to only a few select developers and system administrators at CivicActions.
      2. User data security - Exact copies of the production database put the security of the user data at risk.  For this reason, only sanitized copies of the production database will be available to all developers involved.  The database entries for user passwords, email addresses, physical addresses and phone numbers are either altered or removed to minimize the risk to user data (PII).
      3. Project personnel will be able to access the admin sections of the website as well as Drupal generated status reports and watchdog error logs.
  4. A development / staging server (if appropriate)
    The shared development server offers the following access ( the following applies only if the partner has their own team of developers, otherwise the level of access indicated here would not be provided):
    1. A functioning Drupal environment running off the master branch of the git repository.
    2. SSH access to the server so the code can be browsed and files examined
    3. Drush access
    4. Error log access
    5. Rsync access to move files that are not managed by the Git repository
    6. Sanitized database copies
      1. Nightly from the production server (2AM ET
      2. Every 2 hours from the development server
  5. Services
    Under the LINCS Technical Contract, the specified amount of hours allocated per month for support will be determined and prioritized by the LINCS Contract Officer’s Representative (COR) and the project COR, this includes the following:
    1. Server maintenance on the Production and Development servers.
    2. server and support infrastructure (ssh access, developer user permissions)
      1. Ensure security and compliance - maintain security of the STAR servers
      2. Monitor STAR servers to ensure availability (notify of network outages or system failures)
      3. Diagnose and troubleshoot network, server, or system issues (not including website code issues)
    3. Hosting support, increasing memory limits, server outages.

    4. Git repository

    5. Code Review
      1. Code review through merge requests to the master branch of the repository will be performed with a focus on:
        1. Security - anything that may put the site or its users at risk
        2. Stability - anything that may cause the site to go down or cause the server to be less than performant (excessive errors, warnings, or notices).
        3. Deployability - code deployments need to be repeatable and testable. Deployments must contain code that can deploy itself upon update.
      2. If issues are found during code review,  the partner will need to resolve the issue prior to it being accepted to the master branch of the repository.
      3. Once code is merged to branch master, it will be the responsibility of the partner developers to follow the process to pull that to the development server and make it operational (methods described in the repository wiki)
    6. Code Releases to Production
      1. Types
        1. Scheduled Code releases to the production server should be scheduled a minimum of 3 business days in advance and should not fall on Fridays or a day preceding a holiday.
        2. Hotfixes are code releases that are more urgent in nature and are used to resolve a site instability, error, or security update.  The partner should notify CivicActions as soon as it is determined that a Hotfix is needed, to give them the opportunity to handle the hotfix release with minimal disruption to CivicActions' other LINCS related duties. The LINCS COR will assess the priority level of the request with input from the technical lead to determine scheduling of the hotfix.
      2. Scheduling - Any code release should be initiated by submitting a request to support@lincs.ed.gov and CC the distribution list for the specific project. ( an email distribution group will be created for the applicable partner )

 

The Partner project will be responsible for:

  1. Tracking and timely implementation of security updates for Drupal, other utilized libraries.
  2. 508 compliance on the website and its files in use on the site including pdf, doc, swf, images, etc.
  3. Maintaining the site (site development, content updates)
  4. User management & support.
  5. Development
    1. Create code changes that are self deploying though the use of hook_update_N so that code deployments are repeatable, testable, and simplify releases to production.
    2. Submit merge requests for all changes being made to code.
    3. Code should meet Drupal Code Style requirements by running them through PHPCS prior to commit. https://www.drupal.org/docs/develop/standards
    4. Code should follow Drupal standards for security and best practices. https://www.drupal.org/docs/7/security/writing-secure-code/
    5. Make changes to any issues raised during code review.
    6. Once  code has been merged, follow the process defined in the repository wiki to make it operational.
  6. Schedule code releases to production
    1. Must be scheduled with at least 3 business days notice and not on Friday or the day preceding a holiday.
    2. Hotfix releases must be given as much notice as possible.
  7. Providing technical details or documentation related to the project as needed by the Department of Education (SORN, Privacy Impact Assessment,etc.)