Page History

...

Our estimation may differ from typical agile projects in the following ways:

Bugs are tackled immediatelyas soon as possible. We cannot have a huge backlog of bugs. If we've marked something done and it is defective, we fix it. Quality is non-negotiable.

...

The production environment, running the canonical public-facing site.

SearchLab (Lab)

An environment for highly experimental features. This is typically where major prototyping efforts are deployed, demoed, and tested.

Deploying changes

Changes to shared environments must be deployed through Bamboo via the Earthdata Search deployment project. Any successful build of the master branch in Travis CI will result in the code being send to the deploy 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).

...

The base site contains HTML boilerplate libraries which add CSS classes to the html and body element that detect commonly misbehaving browsers (older IE versions) and browser capabilities. Use these classes to target browsers or capabilities rather than relying on CSS hacks.

Javascript

...

Build components and modules, not one-off elements

Try to build

Use Coffeescript

New project code should be written in Coffeescript. It eliminates much of the boilerplate and gotchas of Javascript, producing easier-to-read code that is more accessible to developers with all levels of front-end experience.

Follow polarmobile's Coffeescript style guide for code formatting

https://github.com/polarmobile/coffeescript-style-guide

Build components and modules, not one-off elements

Try to build Javascript components and widgets that could apply throughout the site, rather than on a single page or in a single situation. Good questions to ask when writing code is "Can I make this into a widget?" or "Can I apply this behavior to all elements with this class?". If the answer is no, perhaps the element could be described as a composition of multiple components (scrollable, zebra-striped, selectable list rather than one-off granule list)

...

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 branch deployment.

Deploying to SearchLab

Unlike SIT, UAT and OPS SearchLab has no automatic triggers.

When deploying to SearchLab be sure that your local branch was created off of e2e-services on GitHub. As with master, when you're code is complete, issue a PR against e2e-services and once it's approved and merged, it will build on Travis. When the build is successful on Travis nothing will happen, you will need to take manual action from here. 

Now that the PR is merged, you can checkout the e2e-services branch from GitHub

git checkout e2e-services

And then push this to the respective branch on Bitbucket

git push bitbucket e2e-services

At this point all you need to do is locate the build and once its successful, create a release and deploy it 

Backports

The following example creates a back port for version 1.69.2, meaning that is the version that is currently deployed and we need to create 1.69.3 to push out a bug fix.

...