Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Production: https://aeon.emory.edu

Github Production Fork: https://github.com/AtlasSystems/hosting-aeon-emory "main fork"

Github Test/sandbox Fork: https://github.com/AtlasSystems/hosting-aeon-emorysb "sandbox fork"

Github Test/Sandbox: https://github.com/AtlasSystems-Prod/hosting-aeon-emorysb "prod sandbox"

Github Production LIVE : https://github.com/AtlasSystems-Prod/hosting-aeon-emory "production system"

Changes to either production or test/sandbox require approval by the Atlas team for accessibility and security concerns through a pull request. Known issues for rejection include old javascript/jquery and links to external CSS files (all CSS must be in the Emory Aeon github repository and not refer to another repository).  Pull requests generally take 24-48 hours for approval.  Emergency changes that need a quicker turnaround should be made in the Github repository and then a ticket should be sent to Atlas support (support@atlas-sys.com) notifying them of the urgent change that is needed.

For development work, clone the fork https://github.com/AtlasSystems/hosting-aeon-emorysb , and then the PR will automatically compare to the AtlasSystems-Prod sandbox repo. 

Changes to Aeon webpages can be tested prior to submitting a pull request by making changes within the testweb directory.  These changes take effect immediately and are designed for developers to test webpage changes.  Viewing testweb pages requires being logged into VPNproxy.  To see testweb changes, add /testweb to the beginning of the link address. For example the page https://emorytest.aeon.atlas-sys.com/aeon/aeon.dll?Action=10&Form=10 would be https://emorytest.aeon.atlas-sys.com/aeon/testweb/aeon.dll?Action=10&Form=10 in testweb.

Documentation of the full process is on the Atlas support website. Emory is an Atlas-hosted PCI environment.


Workflow:

  1. Work from the FORKED repo, AtlasSystems/hosting-aeon-emorysb. Clone this repo to make code updates.
  2. Within each Repo, there are FOUR copies of the fileset. Each of these need to be changed within the folders:
    1. Aeon
    2. Aeon_Testweb
    3. nonshib
    4. nonshib_Testweb

...

  1. However, they only want PRs FROM AtlasSystems/hosting-aeon-emorysb<main> TO AtlasSystems-Prod/hosting-aeon-emorysb<main>. No PRing from feature branch to main repo. Merge feature branch into the

...

  1. forked repo, AtlasSystems/hosting-aeon-emorysb, then do PR. The forks are the only ones we have write access to. 
  2. Then do PR from FORKED <main> to original <main>. 
  3. When PR is submitted, there are some automatic tests that run. A comment will appear in the PR with the results of the tests. Check those out to see if there are any necessary changes. It seems like

...

  1. the reviewers will kick the PR back if there are critical issues, but not necessarily for warnings or suggestions (even though the suggestions can be things you would want fixed before it goes live, so definitely check them out). 
  2. When everything is live on

...

  1. prod sandbox, let Elizabeth know so she can do UAT.
  2. Copy updated files from sb-fork to branch main-fork,  in theory it should be ok to do a bulk copy of everything, but in practice sometimes they are not exactly the same, so proceed with caution, compare carefully. ← hopefully will be updating this to push to additional remote prod fork as of 01312023 conversation w/ Collin
  3. Merge feature branch with copied files to main-fork main branch. 
  4. Then, do a PR from

...

  1. prod-fork AS/h-a-e<main> to production system AS-P/h-a-e<main>.

Any questions, feel free to ask Clare Barton.