Go to dropdown in menu for more.

Environments

• Production: https://access.boston.gov

• Test: https://access-boston-test.digital-staging.boston.gov/

• Development: https://access-boston-dev.digital-staging.boston.gov/

General Documentation

• Active tickets can be found at Digital Maintenance Project Board;

  • Historical tickets for the product can be found online here.

• All content on the website

  • Folder of icons

• IdentityIQ workflow examples

• PingID sample code

Flowcharts

• Forgot password

• Change password

• First time signup

Browser Support

• Support for industry standard latest supported browsers

• It is okay to require JavaScript

Brainstorm/Plan ways the security team can take owner ship of the deployment of new icons and updating Access-Boston’s config file. 2 Step Deploy Plan: The Security will update the config files in S3 via SFTP and the Digital team will restart the Applications.

1. The first is giving them access to the S3 bucket directory containing the App config `.yml` file via SFTP. Once they make the changes they will create create an ‘Issue’ ticket in our Github project for the Digital team to schedule a deploy to the service.

2. The second part is triggering a deployment of their applications on AWS's ECS. Depending on the details of the change, we would go corresponding instance in either "AppsProdDeploy" or “AppStagingDeploy” and 'force a new deploy’ by using the ‘Update” the instance button.

Dedicated Git Repository Deploy Plan: The Security team commits a “Pull Request” to a private repository, whose build process will trigger a build/deploy request through Travis-CI and restart the corresponding App containers.

1. Setup a private repository the Security team can update.

2. Replicate part of the deploy process (travis, slack, etc) the mono-repo uses update the Apps in AWS

SFTP/S3 and LAMBDA Deploy

1. Give the Security team's SFTP Access to the S3 bucket path containing the App config files.

2. Create a Lambda function that gets triggered when the contents of the S3 bucket are updated

3. 1. Connect the corresponding Access-Boston environment using ECS CLI and ‘force new deploy’ that application.

Resources:

• ECS Task Runner with Lambda

• Better Together: Amazon ECS and AWS Lambda

Process: Adding New Icon to Access Boston Website

Process: Non-icon Access Boston Feature or Bug Requests

Andreea will create a ticket for the icon including all of the above in the 'Digital' github repository and assign Phil and Reilly.

Reilly will add this github ticket into the 'Needs triage' column of the main digital project board. Issues will remain in this 'Needs triage' column until they can be discussed during a digital team sync that typically happens on Monday mornings, but periodically moves to Tuesdays due to days off.

When the ticket has been discussed it will be moved into the 'Low priority' column until the week it is set to go live. Tickets will be organized top to bottom with closest launch date at the top and further away date at the bottom. Tickets will be moved to the 'High priority' column the week they are set to go live. Then, once the tickets are in progress they will move through the ques as described on the project board.

When there is more than more environment (i.e. dev and/or test) both Access Boston and Digital Teams will test on the different, available environments. Digital will move the icon to production when Access Boston has confirmed good to go on any applicable test environments. If there is only a production environment, then Digital will make the change straight to production. Approvals from testing should be recorded in the github ticket.

Tickets ready for testing should be assigned to Andreea as well as flagged for her in-person for her to assign to the accurate Access Boston staff member. If she is unavailable, then the ticket can be assigned to Dinesh; be sure to add the label 'validation'.

Digital will confirm via the github ticket and verbally to Andreea when the icon is in production.

For any system outages or emergency errors, find Reilly, Matt, or Jeanethe and Carissa. Prioritize in person communication first. If need be, Reilly will enter an incident management 'ticket' and collectively Access Boston and Digital teams will discuss a plan on how to resolve following the incident management process. If this outage has happened outside of Monday-Friday, 9 a.m.-5 p.m., then Greg should contact Jeanethe, and Jeanethe will pull in the accurate resources.

If this is a non-emergency feature requests or bug, then the first step should be a meeting (or at least an in-person conversation), so that both Access Boston and Digital teams are aware of this non-emergency item and can discuss whether the work can/will be supported by Digital developers.

If applicable (i.e. if the work will be completed), during or right after this meeting, Reilly will create a ticket in the 'Digital' github repository and send an email to the Access Boston email with a link to the ticket. This ticket will include known details. If there are open questions on the ticket, then Reilly will work with Andreea to resolve these questions. Access Boston team should review the ticket to see if additional details are needed; and add these details into the github ticket.

Simultaneously, Reilly will add this github ticket into the 'Needs triage' column of the main digital project board. Issues will remain in this 'Needs triage' column until they can be discussed during a digital team sync that typically happens on Monday mornings, but periodically moves to Tuesdays due to days off.

As a general rule these non-emergency items will be completed during Digital bash weeks. These weeks typically happen every two months. Bash week dates and priorities can be tracked in github here.

We created this repository in Github to manage changes to the Access-Boston dashboard by editing the config files for each of the environments runs on. The following are the are steps needed to commit changes, this repository will then automatically notify the digital team that a new deploy to AWS is ready to be kicked off.

Edit Process

1. From the repository landing page, edit the config file for the environment (dev/test/prod) you want to change, by going from the 'src' and the 'config' folder; the click on the folder for the environment you want to edit.

   

2. Click on the 'apps.yaml' file, from the details view click the 'Edit this File' icon.

   

   

   Adding new links require 3 of the following fields:

   • title

   • url

   • *groups: Groups is a list of groups of people with access that application. The formatting should follow this style: groups

   • *icon: Icon is require for links in the 'Apps' section, at the top of the file

3. When you're done making changes, go to the bottom of the page where it says 'Commit Changes' and provide a name and description for the changes made.

   

4. Leave the "Commit directly to the 'master' branch" radio button checked

5. When you're done, hit the "Commit Changes" button
6. No you can go back to either the homepage or commits page to view this commits progress.

Homepage:

Commits Page:

If you see a yellow dot next to the commit, its still being processed, once its done the dot will check to a green check mark if it passed or a red x if it failed.

Passed:

Failed:

Once the build for the commit passes, our build integration with Travis notifies Digital Team will be notified via Slack that we can restart the application on AWS.