Review and Deployment

The Caliper SDK is a powerful tool for extending the capabilities of the Q2 platform, but we have also spent much time and energy creating a deployment process that is as useful and painless as possible. The Q2 SDK team will do most of the heavy lifting to get your work into our datacenter and into production, but the process can be greatly expedited by submitting clean and tested code that’s ready for customers.

Note

For internal Q2 employees, please check https://confluence.q2ebanking.com/display/SDK/How+to+Get+Your+Extension+Deployed for next steps on deployment.

Here are our recommended steps:

Check

We’ve spent a lot of time making Caliper SDK development as simple as possible while remaining flexible and full-featured.

However, as you finish your extension, there are some “gotchas” to check for before you are ready to submit your code for deployment.

We’ve made a tool to check for some of these common scenarios automatically. Run it by using the entrypoint q2 check.

It checks for issues like:

• Ensuring the version of q2-sdk you are developing on matches what it is in requirements.txt

• Ensuring all files are importing properly

• Ensuring all needed config files have been generated

And many more checks. Try it out. Everything should be green, and if not, the tool should tell you exactly what you need to do. This will be the first thing we check when code is submitted, so if it is not in a passing state, we will have to delay your deployment.

Git

For the next steps, you will need to share your code outside your Q2-provided cloud environment. This serves two purposes. The first is to allow the Q2 Caliper SDK team to have access to your code for testing. The second is to check that all the dependencies and setup scripts have been appropriately identified. This helps avoid “works on my machine” errors.

Your code should already be inside a GitLab repo, which was set up for you on your cloud dev machine.

Most setups will have two protected branches that correspond to environments in our data center.

Branch	Environment	Allowed to merge/push
master	Staging	Yes
production	Production	No

Note

New to Git? Check out our Git Quick Reference guide

Staging Deployment

Deployments to a staging environment (permanent test environment) should be automatic via the CI/CD pipeline when committing to your master branch. If you need additional database updates such as adding a new form, or updates to database configurations, open a support ticket at q2developer.com and choose type deployment.

See CI/CD Pipeline for additional details on the deployment pipeline steps.

Note

The introduction of custom SQL will trigger a security review. The SDK team must review all SQL before it is run in any environment.

Production Deployment

Deployments to a production environment have a more complex, secured workflow.

1. Create a merge request within GitLab to target branch production. Typically the source branch will be master, but may be any branch. If you have multiple developers or many features merging into master, you may want to create a branch off master and use it as the source. This allows your CI/CD branch to continue to take changes while we get your deployment ready. If you do not have a production branch yet, we will create it when we start your deployment. The production branch is used to determine what is deployed in the Q2 production data center.

2. In the description of the merge request, please describe code changes, additional steps or updates, and any other details.

3. Create a deployment request ticket on q2developer.com with a link to the GitLab merge request. This ticket allows us to easily track requests. Use the template below to guide you.

4. The SDK team will perform a code review on the merge request looking for potential security concerns.

5. When the deployment is complete, the Q2 team will merge the request to production branch and notify that the deployment is complete.

Note

Submitting Merge Request Branches for Production

To ensure a smooth and efficient deployment process, it is important that all merge request branches submitted for review meet the criteria for production readiness. Contributors are advised to follow these guidelines when preparing branches for review:

1. Production-Ready State: Only submit branches with extensions that are in a production-ready state. All code in the merge request should be complete and ready for deployment.

2. Avoid Work-in-Progress: Refrain from submitting branches that contain incomplete or work-in-progress code. Extensions should only be presented for a merge into the production branch once all necessary changes are finalized.

All code in merge requests to production will be reviewed with production standards. By adhering to these guidelines, we can maintain the stability of our production environments and facilitate a seamless transition from development to deployment.

Secure Code Review

Part of the production deployment process is a secure code review. This is done to ensure that the code that will be running is not a danger to our datacenter or the end users. There may be some discussion during code review as we confirm details and resolve issues– we intend code review to be a collaborative process. Our service level agreement requires us to complete the review within 3 days of submission, but depending on the size and complexity of the review, we aim for a faster turnaround.

When reviewing code, these are some of the things the team is looking for:

1. Is the code compliant with the OWASP top 10? These ten risks are the teams primary concern when reviewing code. Commonly found issues include:

   • Use of innerHTML when innerText could be used

   • Returning very specific error messages instead of a generic error

   • Use of broad try/except without logging the error

   • No input validation on end user form submissions

   • No request validation on an Ardent extension

   • Loading of external scripts or stylesheets without Subresource Integrity

2. Does the code keep end users’ data safe? If an account takeover event did happen, what amount of data could an attacker gather from this code?

   • What information is exposed in the network traffic of the browser?

   • Is there data being returned from the backend that is not necessary, or that needs to be encrypted prior like Social Security numbers or Credit Card numbers?

   • Is cross contamination possible with other users’ data?

3. Is the code respectful of Q2’s datacenter and resources?

   • Is caching implemented to prevent excessive network traffic for data that does not change that often?

   • Are there duplicate efforts to gather the same data? The typical example of this is making an account list call when an account list is already provided in the incoming request.

   • Are secrets being stored in code or in the repo that shouldn’t be stored in git history?

While code reviews can be a lengthy process, the SDK team is constantly evaluating our review process to make it as efficient and effective as possible. New tools are being built in order to expose more of this review process so blocking comments are not a surprise. All that being said, sometimes things are missed, but caught in later reviews. Depending on the severity, we may block on previously missed issues. The team is dedicated to keeping everyone safe and preventing major incidents, so extra caution is sometimes required.

Ticket template:

After the review is complete, we will transform your repository into a Docker container and run that container in our data center, which will allow your customers to access it.