Page History

...

• cmr-graphql
• edsc-echoforms
• edsc-timeline
• edsc-smart-handoffs
• edsc-geo
• earthdata-download

Initial setup

The README at https://github.com/nasa/earthdata-search contains documentation detailing configuration, setup, and running Earthdata Search. After following the installation guidelines in the README, follow the rest of the guide for the commands needed to run an initial setup.

...

Git Stash site: https://git.earthdata.nasa.gov/projects/EDSC

Bamboo Build: https://ci.earthdata.nasa.gov/browse/EDSC-EDSCDB/DBN2

Communication

• Stand-ups occur daily at 9:45 AM EST. (EOSDIS Slack Huddle)
• Sprint planning meetings occur as part of the EED-2 SAFe efforts. Typically on the first day of each sprint.
• Retrospectives typically take place on the last Thursday of the sprint.
• Developers should use EOSDIS Slack accounts for chat and join the #edsc-dev channel for team communication. See your team lead for an invitation to the channel.

...

Earthdata Search uses an agile development process with two-week sprints. At all times, our master main branch maintains a potentially releasable product increment. Once a commit is merged into mastermain, it will immediately trigger a build and deployment to our SIT environment.

...

Development

No change may go into master main until it has undergone peer review in Github and is successfully building in TravisCIGitHub Actions. Master Main is to remain deployable at all times, so ensure it contains production-ready code with green builds.

Occasionally, due to intermittent problems with test timing or execution order, our master main build will fail. Fixing the issue and ensuring it does not happen again becomes the highest priority when this happens.

...

1. The developer chooses a JIRA issue from among those in the active sprint, assigns it to himself, and moves it to the "In Progress" column of the agile board
2. The developer implements the change in a new git branch named after the issue number, e.g. EDSC-123. Commits are also prefixed with the issue number, e.g. "EDSC-123: Add user accounts page".
3. (Optional) When in need of collaboration or input, the developer pushes the branch and opens a new pull request without assigning a reviewer. Collaborators may pull the branch or view and comment on the diff in Github.
4. When the change is complete, the developer pushes the branch and opens a pull request (without assigning a reviewer), triggering a TravisCI build GitHub Actions build for that branch, and ensures the build is green.
5. Once the build is green, the developer assigns the pull request for the branch to each member of the development team and moves the issue into the "Pending Review" column in JIRA.
6. The reviewer looks at the code, ensuring passing tests, adequate test coverage, code quality, and correct/complete implementation. He also runs the code and manually tests it, paying close attention to usability and consistency of like-features or interactions throughout the rest of the application.
7. The original developer fixes items brought up during review until the reviewer is satisfied and has approved the pull request. In most cases, we like to have 2 approvals. In some cases that is not needed. The team lead will have a good idea as to what needs additional review. Use your best judgement.
8. Once sufficient approvals have been granted via Github, the original developer merges the branch. At this point the remote branch can be deleted.
9. Once master main has built and deployed to SIT, the original developer verifies the new functionality/fix is working, moves the JIRA issue to the "Ready for SIT Testing" column, and creates a JIRA issue test session for QA and verification.
10. If the QA process reveals updates need to be made, the QA team member works with the original developer directly to resolve any issues, following the process outlined above, until QA approves the changes.
11. The QA team member moves the JIRA issue into the "Done" column, typically with a resolution of "Verified Internal".
12. Once deployed to the UAT environment, the QA team member executes a regression testing protocol ensuring new features work correctly and that the build/release is stable. They also reach out to a primary stakeholder for the issue (for instance, the person requesting the change) so that they may test the implementation. If satisfied, the Product Owner adds "Verified in UAT" as a comment in the issue or the issue is moved to "Verified External" (in the case of an external reviewer).

...

Deployment

There are 4 3 shared deployment environments for Earthdata projects, including Earthdata Search:

...

Changes to shared environments must be deployed through Bamboo via the Earthdata Search deployment project. Any successful build of the master main branch in Travis CI GitHub Actions will result in the code being send to the deploy the main branch of the ECC Git repo (BitBucket). Once that branch receives the code, the branch is built and deployed to the EDSC SIT environment (https://search.sit.earthdata.nasa.gov).

...

When building the interface, use the History API to ensure that history entries are pushed to the stack appropriately. Push entries to the stack when the user reaches points they would reasonably expect to bookmark. Avoid pushing entries so frequently that backing out of a state using the back button becomes tedious or impossible.

Deployments

...

Main

Merging to master main will kick off a build on Travis CIGitHub Actions. Travis Bamboo will automatically kick off a deployment to SIT, on a successful build.

If the build on master main fails and requires intervention a manual deployment to SIT will be required.

End-to-end Services

Once your code merged into the e2e-services branch on GitHub you'll need to push that branch to the e2e-services branch on Bitbucket. Before you can push to Bitbucket you'll need to add it as a remote:

git remote add bitbucket https://USERNAME@git.earthdata.nasa.gov/scm/edsc/earthdata-search-client_repo.git

Once the remote is establish, ensure that you're on the e2e-services branch, and push it to the Bitbucket remote:

git push bitbucket e2e-services

This will kick off an e2e-services build on Bamboo.

• deploy Builds on Bamboo
• e2e-services Builds on Bamboo

Manual Deployments

Prerequisites

Manual Deployments

Prerequisites

• Must have NASA VPN Token
• Must have code 700 VPN Token to login to Bamboo
• Must have NASA VPN Token
• Must have code 700 VPN Token to login to Bamboo
• Permissions to deploy to the desired environment (may need to contact OPS)

Once on the NASA VPN, visit https://ci.earthdata.nasa.gov/browse/EDSC-EDSCDBDBN2 which will prompt you for your code 700 token, further instruction for each environment are below.

Deploying to SIT, UAT or OPS

From

...

main on GitHub

This is the most common deployment method. After working a ticket, you've issued a Pull Request, that has been reviewed and merged into master main on GitHub. When Travis CI completes GitHub Actions completes a build on master main it runs runs bin/ecc-sync which syncs mastermain from GitHub to deploy on Bitbucket. Bamboo has a deployment trigger configured to deploy automatically on a successful build to SIT.

...

At any time you can push your code to Bitbucket and create a release from that branch. Note that you should not push these branches to any environment except SIT, and that you should check with all necessary stakeholders before doing so. Once you are done testing that branch on SIT, return SIT back to the normal master main branch deployment.

Backports

...