Setting up Your Project

Setting Up The Project for Development

CloudVanti is a platform that facilitates an environment to customize development codes and database changes. Subscribers gain full access to their project source code and database, deployment source code and database, backup and restoring of database, as well as CI/CD integrated setup with Repository to enable it to be deployed with custom codes.

CloudVanti Sitefinity manages the code and database development separately. The 2 separate repositories provided are for the Source Code and Database connected to the CI/CD pipeline.

Source Code Repository

The Code Repository is provided a branch called the Master Branch. When a code is committed in the Master Branch, it will automatically trigger the pipeline CI.

Database Repository

The Database Repository has two branches:

• Staging Branch: used to deploy from the Staging Database
• Production Branch: used to deploy from the Production Database

Understanding that the SQL Scripts deployed between Staging and Production may differ, the Database Repository is separated into 2 branches, with each of them automatically triggering their respective pipeline CI.

Cloning the Repository

The CloudVanti Sitefinity environment comes with a Git repository for you to place your projects in. It can be accessed through the Management Portal.

Here is how you can clone your projects into the repository:

1. From the Management Portal select Repos, then select CloneRepository.
   <subscription-name>-DB, for database repository
   <subscription-name>, for source code repository
   
   
2. Click the Clone button.
3. A prompt displaying the repository URL and credentials will appear.

Source Code File Structure

Once your files have been cloned into the Git repository, they will be sorted in accordance to the default file structure of Sitefinity known as Default File CloudVanti (DFC).

THINGS TO NOTE ABOUT FILES AND FOLDERS IN THE DFC

CloudVanti CI/CD processes will use files from the DFC. This structure is also applied for existing Sitefinity Projects.

1. All default folders and files in the DFC are of the same level as the .git. These files should not be moved to any another folders.
2. You may however add folders and files into the DFC but it has to remain the same structure as the default.
3. Provided by default in the DFC, the .sln and .csproj files should be found together in your project at all time as the CI/CD process will be running based on them.
4. Be sure to have your dependencies and library referenced from nuget.org.
5. Be sure to register all files within the .sln and .csproj folders.

Database File Structure

The .git folder will be the first thing you see after cloning into the Database Git repository.

To deploy new scripts, a new folder will be created which will contain the new scripts.




The folder and files should also be according to the naming convention as follow:

• Things to note when creating folders
  yyyy-MM-dd-zzz
• yyyy-MM-dd: DateTime format
  This helps to track and log the history of your Deployment database.
• zzz: Commit number of the folder, starts at 001
• the number should be unique for files of the same day.
• Scripts are executed by folders. To deploy the database of multiple commits within the same day, you would have to create different folders per commit. Adding new script to the old commit folder would cause them to repeat other scripts in addition to the newly added one.
  For example:
  Within the commit pipeline, 2 scripts are being deployed - the create user and tenant tables within folder 2020-08-14-001. A new script is created for a dashboard table to be deployed within the same day. A new folder by the name of 2020-08-14-002 is created that contains the new script for it to be committed in its own instance.
  
  
  
• Things to note when creating script files
  x_<filename>.sql
• x: Single digit number (1 - 9) to indicate the execution order of the script. The Pipeline executes scripts listed in ascending order.
• The script file's extension should be *.sql.
• Avoid using unsupported Azure SQL Database statements (e.g. USE statement). For more information please refer to SQL Documentation.