The version control module

The version control module is linked to the templates module, you cannot use the version control module without also using the templates module. When changes are made in the templates module, they will show up in the version control module. The version control module can then be used to commit these changes and deploy them to specific environments (dev, test, acceptance, live).

The version control module has the following tabs:

Uncommitted changes

The first tab in this module contains all uncommitted changes from the template module. You see two lists here; one for templates and one for components. You can select multiple items in each list by holding CTRL or SHIFT while clicking on rows in the lists. Above those lists you can select the environment you want to publish your commit too. The commit will be committed to the selected environment and all environments below that. So if you, for example, select acceptance, then the commit will be pushed to dev, test and acceptance, but not live. Then you can also enter a description for your commit, to describe your changes.

When making a commit, you can select any number of templates and/or components that haven't been committed yet. We recommend making small commits of only one change per commit. One change could contain multiple templates and components, but should only affect one functionality. For example, if you add something to a product detail page, you might have to change an HTML template, an CSS template and one or more components, but that's all part of the same change. But if you also need to change something on the news page, that would be a different change and therefor a different commit. This makes it easier to deploy specific changes to production later, or to undo changes that have been made.

When committing, you can also select one or more users to request a code review. More about this functionality later.

Deploy

The deploy tab contains a list of all commits that haven't been fully deployed yet. We consider something fully deployed if it has been deployed to live/production (and therefor also all earlier environments). Via here, you can deploy commits to any environment that is hasn't been deployed to yet. For example, it can happen that a change first only gets deployed to test, then after testing it gets deployed to acceptance. Once it has been approved on acceptance, it can then be deployed to production. This can all be done through the Deploy tab.

To deploy one or more commits, you have to first select them in the grid. You can select multiple rows by holding CTRL or SHIFT while selecting rows. Once you have one or more rows selected, you'll see extra options in the footer of the grid. With these options you can deploy the selected commits to the branch (information about branches will be added to the wiki later) or environments you want.

History

This tab contains an overview of all commits that have made in the past. At each commit it will show which templates and/or components were part of that commit and when and by whom the commit has been deployed to each environment.

Reviews

In this tab you can find all commits for which a code review has been requested and that hasn't been approved yet.

The code review functionality is still very basic, you can consider it to be early access with limited functionality.

Requesting a review

Requesting a review can be done via de first tab of the version control module. When making a commit, you can select one or more Wiser users and request a review from them:

This list is divided into two categories:

1. Admin: These are the admin users for Wiser. These are the users that can log in to any tenant without needing a personal account in each tenant.
2. Klant (customer): These are the local users of the tenant you are currently working in.

You can select multiple of these users in any combination. Once you make your commit, your commit will be added to the reviews tab. The selected users will not receive an e-mail or any other kind of notification (this functionality will be added in the future), you have to manually ask them to review your changes.

If you do request a review, then you cannot deploy your commit to live until your changes have been approved. When the person/people have done the code review, they will notify you with the status. If your changes have been approved, you can deploy your commit to live. If your changes have been denied, you need to fix the issues they found and then request a new review. Your commit will then also stay visible in the reviews tab, with the status RequestChanges. If your review has the RequestChanges status, you should check the details to see if the reviewer left any comments, so you know what you need to change. You can see the these comments by expanding the review by clicking on the little arrow on the left:

Doing a code review

Once you have been asked to do a code review, you can see that review in the reviews tab of the version control module. There you will see the list of all pending reviews. Each pending review has a status. If the status is Pending, it means that nobody has done the review yet. If the status is RequestChanges, it means that someone has already done the review and did not approve it. The developer who requested the review then needs to make some changes and request a new review. If one person approves the changes, then the commit will be accepted and no longer be shown in the list of the Reviews tab. Even if multiple people were requested to review a single commit, only one person has to approve it for the commit to be accepted.

To see the details of a commit, you can click the little arrow on the left to expand the review request:

Once expanded, you will see any comments that you or anyone else left on that review. You can also see all templates and/or components that have been changed in this commit. If a template or component has been deleted, a text will be shown to indicate that, otherwise a button will be shown that can be clicked to see the history of that template or component. There you can take a look at what has been changed to review that. This is still limited because that button will show all changes that have ever been done in that template/component, so you need to search for the correct changes manually by checking which version has been committed by the developer and then looking at the history for that version. This functionality will be improved in the future.

Once you are done reviewing the changes, you can use the buttons next to the commit to approve the commit, to request changes or to place a comment. If you request changes, you should always add a comment to say what the developer should change, even if you also tell them that via other ways. If you approve the commit, then the commit will disappear from this list, if you request changes, it will stay in the list, but the status will be updated. Users/developers will not be notified about the status automatically, you have to do this yourself. (This functionality will be added in the future.)

If you request changes, that developer will need to make a new commit and request a new review. These will not be combined and the developer cannot make any changes in their original commit. So you will then have two pending reviews for the same changes from the same user. If you approve of the new changes that the developer made, then you should accept both the new and the old review, so that the list will stay clean.

A commit cannot be deployed to live/production if it has a pending review that hasn't been approved.