Marfeel Docs

# How to shuttle MarfeelXP

This document explains the process for generating a new release of MarfeelXP and landing it in production.

# Considerations

  • Code introducing or removing chunks should be merged first thing in the morning.
  • When removing a JSP, two shuttles have to be made. The first one should remove all uses of the JSP and the second one the JSP itself. This is to avoid cache issues where a compiled JSP tries to use the removed JSP.

# Before shuttling

  • A Shuttle must be done after every merge. Code cannot be merged if you're not planning to shuttle the code when the build is green.
  • Make sure that the production environment is stable by checking the Deployment Dashboard (opens new window) in Kibana.

TIP

Pull requests that do not contain production code, such as:

  • Markdown changes only
  • Jinks changes only

Do not require a shuttle. However, you must still follow steps 1 and 2 of this guide.

# Shuttle

  1. When it's your turn to shuttle, notify the other people in the #shuttle-stakeholders channel of which feature you are going to merge with a link to your PR.
  2. Merge your code in master and wait for the build.
    • Build is successful, jump to point 3.
    • Build is red. Check the output of the build. If the error doesn't seem related to your code, you can retry the build from MarfeelXP job page in Jenkins. If the build keeps failing, revert your code, and notify of the issue.
  3. Go to MarfeelXPShuttleGit (opens new window) job and shuttle your build. It should be preselected already in the dropdown. MarfeelXPShuttleGIT Jenkins Configuration
  4. As soon as the job finishes, check that publish-core (opens new window) job has been triggered. It would generate a new version of @marfeel/core package.
  5. Check that DependencyUpdater-run (opens new window) jobs are starting after publish-core (opens new window) has finished and monitor the rollout of the new package with the Renovate Status Dashboard (opens new window)

TIP

Here is a Quick Guide to understand the Renovate Status Dashboard (opens new window)

# After shuttle

Go to MarfeelXP stability dashboard (opens new window).

  • Check that all the KPIs shown in the board are stable.
  • Check that no new error has been introduced.
  • Check that your new build is receiving traffic. Wait until at least 70% of the traffic has moved to the new build.
  • Check that Renovate has no Pending or Failed updates left, and fix or notify if there were any.
  • Check that no new alarms have been fired. You can find them in the stability dashboard or in the alarms board (opens new window).

If the 5 previous points are satisfied, notify the channel that the shuttle has been successful. On the other hand, if the production environment doesn't look stable with the new build, jump to the revert protocol.

# Revert protocol

  1. Notify to the channel that the shuttle has introduced some errors and you're going to proceed with the revert process.
  2. Go to MarfeelXPShuttleShuttleGit (opens new window) job and find the build number in the parameters of the previous shuttle. Then do a new shuttle using this build number. Process is explained in the shuttle section. No need to lineup this time, you're already the first one!
  3. Revert your code and merge it in master. Master branch should be stable for next one in the queue.
  4. Notify pem@marfeel.com of the issue introduced in production and the impact it had.
  5. Handle the alarms triggered in alarms board (opens new window) because of your commit.

← Monitor Dependency Upgrades →