Deployment prep

This is a collation of the best practices steps you should take to prepare your new API or Service for deployment by the SRE team.

We are not writing anything new here just structuring what already exists.

What's the value of following this process?

• Makes it easier and faster to be deployment ready, the intent is that you won't run into gotchas
• Makes us compliant with Security and Legal

When should you follow this process?

• Once your new API/Service is ready to be served via our production systems

Get your repo on gerrit

In order to get the benefits of automated CI/CD already setup on Gerrit, Request new gerrit repo You have to already have a gerrit account that the repo creator will assign permissions to inorder to push to the repo Consult on repo naming conventions. Wrong naming will result in archiving of the repo and you will have to create a new rightly named one

Update gerrit repo with latest code

Once you have the new empty gerrit repo, in order to be able to push other people’s code commits you will require special powers on Gerrit by joining the Trusted Administrators Group

Ping someone already in the Trusted Administrators Group to add you there

Push the code commits

Security and Legal Compliance Use Security Review - Standard Operating Procedure to find our if your new API/Service requires a security review. Not all Services/APIs will require this Security review

Security reviews all new review requests on a quarterly basis. It will be most nice to get your request in before the tasks of the quarter are finalized.

If Security team decide you require a Legal review they will be the ones to forward you to Legal for review, there is no need to ping Legal directly

Can we own our own security checking?

To some extent yes it is possible check for security vulnerabilities in your codebase by yourself to minimize on the back and forth feedback from Security team. For this you can consult | Security Review - Some tools to help

Security team will still have to do the checks from their end.

Handle tech debt

There’s a certain threshold that all Wikimedia systems must meet in order to be deployable by SRE. Currently no example deployable Wikimedia service exists

It may not be possible to exhaust the list here so budget some time to fix stuff on the fly as you receive feedback from SRE

Some confirmed components that must definitely be there

1. Service name
   • No underscores, use hyphens
   • Consistency in the naming of the service within the codebase itself and all docs.
2. Unit tests
   • Your service must have true unit tests that don’t have external dependencies.
   • These should be runnable from a basic `make test` build step
3. Metrics dashboards
   • Accessible via /metrics endpoint
   • A /healthz endpoint
   • Provide metrics gathered via Prometheus and dashboards to monitor and assess
   • For AQS 1.0 for example, | Example Grafana dashboard

• Documentation updated
  • Revise all endpoint and overview docs for completeness and consistency
  • Add make docs command to update the docs
    • Uses `swag` —-- swag init --markdownFiles