Go Live Steps
- Rushikumar (Rush) Bhatt
Note:
Certain steps are skippable; as such, they are not mentioned in the Tl;dr version. Reference the detailed steps to see them.
Tl;dr
Jira
- For New or Existing Projects
- Create a ticket for the project / requested changes for a project
- Move ticket from "Backlog" to "In Progress" workflow stage
- When done, notify customer / Move ticket to "Under Review"
- Log work & add a closing comment with pertinent details (e.g. go-live approved by name/date/time etc.)
Stash
- For New Projects:
- Create a new repository in FNF project
- Clone repository to local (using Sourcetree)
- Add the nitro file from Leap TEST environment
- Commit and push to master branch,
- Create a tag and notify Jason Card for it to be released to PROD
- For Existing Projects:
- Do Steps 3 - 5, above
Confluence
- For New Projects:
- Add a project requirements page
- Add all the pertinent information related to this project
- When ready to go live, update the Document Properties box and and any other sections as necessary
- For Existing Projects:
- Update the project's requirements page
- Update the "Post Production Enhancement List" section
- After the changes have gone live:
- Add release date to the "Post Production Enhancement List" section
- Update the project's requirements page
Customer Notification
- For New or Existing Projects:
- Copy links for Form(s) and View Responses page from Leap PROD environment
- Notify customer/team that the latest changes have gone live and provide the links
Note:
Skippable steps are indicated by "(Optional)". You may choose to skip these steps, depending on your work-style — Use your best judgement!
- The steps outlined for Jira, Stash, and Confluence SDLC tools are not in a strict order
- Example: Do Jira Step 4 after Step 6 etc.
- Even the SDLC tools can be done in an order that suits your work style
- Example: Doing confluence steps first documenting the customer request, and then Stash, and finally Jira, etc.
Jira
Tip
It is prudent to do these steps throughout the life-cycle of the ticket (vs. doing them when closing the ticket), as it helps with accurately logging the work / time spent / updates from the customer with respect to changes in the scope of (intial) requested changes etc,
For New or Existing Projects
| Step # | Description | ||||
|---|---|---|---|---|---|
| 1 | If new project:
If existing project:
| ||||
| 2 | (Optional) Log the estimated effort | ||||
| 3 | If the ticket is in the "Backlog", move it to "In Progress" when you start working on the changes | ||||
| 4 | (Optional) If existing project:
FYI I usually do a "relates to" linking between Parent and post go-live enhancements
| ||||
| 5 | (Optional) As you progress, through the requested change(s)— a. Add comments as necessary b. Log work / time spent
| ||||
| 6 | (Optional) If scope change occurs (i.e. additional changes are requested by the customer), you may create a Smart Checklist. Markdown syntax is used for adding items and it is pretty simple and straight-forward. Note Normally, the proper way to handle scope change would be to create sub-tasks — i.e. child tickets. However, for FEB tickets it has been recommended to not do sub-tasks (as it "messes-up" (or was it "fudges"
| ||||
| 7 | When all requested changes are complete, notify customer and move the ticket into "Under Review" workflow stage
| ||||
| 8 | Upon receiving confirmation from the customer that all changes have been tested, verified, and confirmed, provide the following details in comments: a. Who approved the go-live and when. i. (Optional) Attach the confirmation email from customer to the comments b. Log work / time spent | ||||
Stash
Brand New Project
| Step # | Description | ||||
|---|---|---|---|---|---|
| 1 | Login to stash: https://stash.uconn.edu/ | ||||
| 2 | Navigate to FEB Nitro Files (FNF) project | ||||
| 3 | Provided you have the necessary privileges, click on the "Create repository" button, top-right | ||||
| 4 | Provide an appropriate name and then click on the "Create repository" button | ||||
| 5 | Clone repository to local — this is your local repository Tip Establish clean directory structure for all your Leap apps; directory within this structure is where you will create a local repository a. Create a project directory for this Leap application b. Use git/bash command: Clone Remote Repository git clone REPOSITORY_URL
| ||||
| 6 | Open up Sourcetree software | ||||
| 7 | Add a new repository, by clicking on the "+" at the top:  a. Click on Add at the top: b. Click on "Browse" c. Navigate to where you cloned locally (Step 5.a., above) d. And click on "Select Folder" — DO NOT click on the .git folder... merely ensure that the folder you select has a .git folder (this is a hidden folder — so you might not see it, based on your settings), as shown below e. Finally, click "Add" | ||||
| 8 | Go to Leap TEST environment and export the project (if you have not done it already) and save it locally Heads-up! Unless you have been told otherwise: Make sure that the "Include submission data?" checkbox is not checked! | ||||
| 9 | Locate the *.nitro_s file that you downloaded from Leap TEST environment and move it to the directory of your project's local repository (same folder as 5.a., above) | ||||
| 10 | Sourcetree automatically detects a change in your local repository; it's time to stage your project's nitro file — Reference the screenshot below for steps 10.a & 10.b: a. Your project's nitro file will be listed under "Unstaged files" section b. Click on
Note: You should only see your project's nitro file... if you see more than one file, reach out to our Leap group and troubleshoot as to why that is the case | ||||
| 11 |
| ||||
| 12 | Committing to remote repository — Reference the screenshot below for steps 12.a — 12.c: a. Under comments, use the following format — the first comment line & its format is mandatory! JIRA XXX-### YOUR COMMENTS (where XXX-### is the Jira ticket; you can provide your comments after that) Tip If you have a prior commit, you may click on the b. Click on c. Click on the | ||||
| 13 | Create a tag a. Click on "master" under "BRANCHES" on the left; notice that middle pane  b. Right-click on the commit that you did in (Step 12, above) and select "Tag..." c. In the resulting dialog box, under "Add Tag" tab i. Provide a name for the tag (this convention should work: "NAME_OF_REPO_v#.#", where #.# is your version number e.g. 1.0, 1.1, etc.) ii. Select/check the iii. Click the | ||||
| 14 | Notify Jason Card that the tag "TAG_NAME" (from #13.c.i) has been created and it's ready to go live. Here's my notification template... feel free to use it, if it helps! Note: Change the [PLACEHOLDERS] and in order to ensure the accuracy: the verbiage, as necessary!
|
Existing Project
| Step # | Description |
|---|---|
| 1 | On local machine, navigate to the project's directory where you have established your local repository Note: You should only see the .git folder and the previously exported nitro file:
|
| 2 | Delete the nitro_s file from this directory |
| 3 | Continue from Step 8 of "Brand New Project" |
Confluence
For a Project's Initial Release
| Step # | Description | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | If the project requirements page does not have a Pre Go-Live Log section, add it: Pre Go-Live Log
| ||||||||||||||||||||||||
| 2 | Follow/go through the developer's checklist, as listed within the Pre Go-Live Log | ||||||||||||||||||||||||
| 3 | Update the Document Properties box
| ||||||||||||||||||||||||
| 4 | If you have done detailed documentation for your project, add a link to it right after the Document Properties box by: a. Adding an Info macro, with the following verbiage
b. Format the text as: Heading 2 c. Add a link back to the high-level requirements document on your detailed documentation page, with the following verbiage
d. Optional: if you have Table of Contents (ToC) macro on either the Detailed Documentation page or the High-Level Requirements Document page, edit the ToC macro and add the following RegEx so that it is excluded from it: This is a detailed.*
| ||||||||||||||||||||||||
| 5 | Update any other details as necessary | ||||||||||||||||||||||||
| 6 | Verify & confirm the accuracy of:
|
For a Project's Subsequent Releases
| Step # | Description |
|---|---|
| 1 | Update the "Post Production Enhancement List" section— a. List the enhancements made at a high level i. (Optional) Provide a link to detailed documentation page where these enhancements are captured in detail b. Add customer name with Day/Date/Time of when it was approved to go live i. (Optional) Include the confirmation email c. Link the Jira issue d. Provide information for the other columns, which are self-explanatory Tip You may start adding information to the Post Production Enhancement List log, from the day you receive a request for changes from the customer, and then update the log over time... I do this myself and shown below are several screenshots of this log over time... |
Customer Notification
| Step # | Description | ||||
|---|---|---|---|---|---|
| 1 | Login into Leap PROD environment: https://hclleap-prod2.its.uconn.edu/apps/login/org/index.html | ||||
| 2 | Search for your project
| ||||
| 3 | Copy PROD links: a. Click on "Launch" and copy the link from the resulting page b. Click on "View Responses" and copy the link from the resulting page
Note: Click on the down arrow for "Launch", if your project has multiple forms, in order to copy each form's links | ||||
| 4 | Notify customer/team that the latest changes have gone live and provide the links Here's my notification template... feel free to use it, if it helps! Note: Change the [PLACEHOLDERS] and in order to ensure the accuracy: the verbiage, as necessary!
|
