Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Related Jira Issues

FNSDKEXT-16 - Getting issue details... STATUS

FNSDKEXT-17 - Getting issue details... STATUS

FNSDKEXT-21 - Getting issue details... STATUS

FNSDKEXT-40 - Getting issue details... STATUS

FNSDKEXT-95 - Getting issue details... STATUS

Introduction

Unity will utilize FN’s Azure DevOps solution to manage the building and packaging of both the FN SDK and the Unity example project. The following defines how Unity will make use of Azure’s built in build and pipeline tools to conduct proper CI/CD methods.

Azure DevOps Git Repo Maintenance

Two repos will be created in support of the FN SDK:

  1. A repo for the the FN SDK library as its own standalone project will be created

  2. A repo for the Unity project utilizing the FN SDK library will be created

.YAML File

A .yaml file will be included at the root of each git repo to enable the automation of builds and packaging of artifacts

Stages

  • Each yaml file will contain a single stage to define the various tasks to run according to a pre-defined schedule

Jobs

FN SDK Library

  • A single job will be created to support testing, static code analysis, building and publishing of artifacts

Unity Project

  • A single job will be created to support testing, static code analysis, building and publishing of artifacts

Tasks

FN SDK Library

The following tasks will be defined in the yaml file:

  • A static code analysis task will be written to automate detection of any vulnerabilities or poorly written code

  • An automated testing task will be written to run any unit tests written for the SDK

  • A build task will be written to produce a dll artifact

  • A publish task will be written to copy the resulting library artifacts of the build task to a specified sharepoint location

Unity Project

The following tasks will be defined in the yaml file:

  • A static code analysis task will be written to automate detection of any vulnerabilities or poorly written code

  • A batch script task will be written to build the example Unity scene

    • A container using a Unity build license will be utilized throughout the course of the project to allow for remotely building the Unity project.
      NOTE: This container will only be valid during the course of development. FN will need to work with Unity to obtain their own Unity build license if they wish to continue building the Unity project post project delivery

  • A publish task will be written to copy the resulting appx file of the example Unity scene utilizing the FN SDK to a specified sharepoint location

    • Scripts will also be provided to assist with sideloading the UWP application

Schedules

General

  • A build will be generated on the development branch on a nightly basis to ensure integrity of core, working branch

  • A build will be generated on the master branch on a bi-weekly basis to ensure the integrity of the delivery branch and support the production of artifacts for delivery at the end of each sprint

  • An additional yaml file will be created to enable building feature branches on a more frequent basis.

Batch Files

  • A batch file will be written to build the example Unity scene utilizing the FN SDK

Artifacts

SDK Artifacts

The following artifacts will be generated upon a successful build of the FN SDK

  • Release builds of any libraries built by Unity in support of the FN SDK

  • Builds of any dependencies of any libraries built by Unity in support of the FN SDK

Unity Artifacts

The following artifacts will be generated upon a successful build of the Unity project

  • An built UWP app of the Example scene utilizing the FN SDK for the Windows 10 OS platform

    • Any required libraries will also be generated as artifacts for the Unity project

  • A built Android application of the Example scene utilizing the FN SDK for the Android 10 OS platform

    • Any required libraries will also be generated as artifacts for the Unity project

Naming Conventions

Artifacts will contain the following information within their name:

  1. A unique identifier to assist in differentiating builds from each other

  2. An indication of the branch the artifact was generated from

  3. An indication of the date the artifact was generated

  4. An indication of the release version/milestone tied to the artifact

Retention Policy

  • Artifacts from builds in the development branch will be retained for a minimum of 2 weeks before being deleted

  • Artifacts from the main branch will be retained for the length of the project

Internal Repo Maintenance [Resource]

  • An internal, Unity facing git vcs repo will be created to mirror the Azure repo

  • Unity developers will connect their local git repo to both the Azure DevOps repo and the internal git vcs repo

  • Any changes made to the root development branch will be reflected both in Azure and the internal git vcs repo

  • Any changes made to the main branch will be reflected both in Azure and the internal git vcs repo

  • No labels