Local Development
Development is much easier if done locally. We provide each developer with their own environment (folder) on the test server, which is easily accessible using your own personal URL; for example: https://jdoe-dev.test-cloudsuite.cloudsuite.com.
In a nutshell, you start by cloning the client theme to your computer in a folder of your choosing. This is where you will work from. You can make any changes you need here. You then upload it to your development environment by means of an sFTP connection. Now you can see the changes on your personal development URL.
To work in this way, you as a developer must be added by DevOps to the CloudSuite servers and you need access to the VPN.
Add the following lines to your hosts-file.
10.5.109.149 test02.internal.cloudsuite.com test02
10.5.109.139 test03.internal.cloudsuite.com test03
10.5.109.147 test04.internal.cloudsuite.com test04
10.5.109.161 test05.internal.cloudsuite.com test05
10.5.109.162 test06.internal.cloudsuite.com test06
10.5.109.130 test07.internal.cloudsuite.com test07
10.5.109.170 test08.internal.cloudsuite.com test08
10.5.109.195 test09.internal.cloudsuite.com test09
Start Development
If the theme is a monorepo, please read our documentation about monorepos.
Clone Project
We start by cloning the project from GitLab. Then we create a new branch to work on or select the branch we have to work on.
Prepare to Start
We use npm packages for all our projects and WebPack to build our static folder. Before we install the packages, we have to confirm the node version the project is using. This can be found in the file named .nvmrc.
Execute the following command(s) to use the same version.
| Already installed | Not installed |
|---|---|
nvm use {version from .nvmrc file} | nvm install {version from .nvmrc file} |
nvm i is also possible. This will install the version if not available and will activate it.
Now, when we are on the same version, you can start installing the packages and build the static folder using the following command.
$ npm install && npm run build
Make Changes
You can now start making changes to your files. Be sure to run npm run build or npm run watch before you can see any changes.
This command will watch the files and build immediately when something has been changed and saved. So you don't have to run the build command after every change.
Commit & Push
All done with your changes? Make sure you check if all acceptance criteria have been met. It's time to push your code so your teammates can review & test your work.
Write a commit message with a brief description of your changes. Try to add your ticket reference number as part of the commit message in order to better differentiate between the multiple commits in case they aren't being squashed when merging.
Update the Ticket
After you push your changes to GitLab, a pipeline will run to create a new URL where you can find your changes. This URL is necessary for your teammates to review/test your work.
Update your ticket with the URL and place a comment with a summary of what you have done. Change the status of the ticket to Testing and assign the consultant to review your work.
Review
In order to guarantee high quality, we have different phases in the process where design, functionality, and written code are checked.
Testing
Testing a ticket is done by the following people:
- QA Tester
- The Consultant (optional)
- The Client
These people will check whether it functions properly, also look at the design, but will also check the functionality from the CloudSuite Admin and the CloudSuite App.
Design Review
A designer will examine your work with a critical eye to see whether everything from the design has been neatly copied. He/she will also check if everything works as intended.
Code Review
When the designer, consultant, and client have approved everything, the ticket will be returned to you to have it checked by a Front-end colleague.
For this, you first have to create a merge request. This can be shared in the Slack channel #Front-end-code-reviews. Your colleague will check your code.
When everything is fine, you can merge it with the develop branch. Then, update the ticket with the status Ready for Release.
Ready for Release
All criteria are met and your ticket is ready for release. Now it's time to follow the steps to do a front-end release