Benchmark Client Build Instructions

• Clone or Get Latest from Court/Dev/Dev for 2.10 or Court/Release/Release 2.9 for 2.9 or depending on where it is needed to pull. 

• Check to make sure all necessary check-ins are done.

• Update AssemblyInfo for all projects under solution 

  • Court.InCourt  

  • Replace all 2.10.8 (current version) with  2.10.9.0 (latest New Version)  

  • 22 files with 44 different locations that should get updated (2.10)

  • 18 files with 36 different locations that should get updated (2.9)

• Update WhatsNew.txt with New Version and Date 

• Update 1_UpdateClientTableSchema_v(current version).sql file  

  • Make sure any new fields are added to the 1_UpdateClientTableSchema_v(current version).sql file. Check for any CourtDataLayer base class changes since last build.

  • There should also be version numbers in this file.  

  • Open

    

  • Copy script for version and update to latest new version number

    • Looks at the extended properties of tblVersion 

    • This part prevents the nag box about version mismatch when you launch Benchmark  

• Rename 1_UpdateClientTableSchema_v(current version).sql, changing the version number to the new version number.

• Copy the renamed 1_UpdateClientTableSchema_v(new version).sql to the SchemaUpdates\Versions folder.

• Check in, make sure the 22 (2.10) or 18 (2.9) AssemblyInfo files, the WhatsNew.txt file, the SchemaUpdates\1_UpdateClientTableSchema_v(new version).sql file, the SchemaUpdates\Versions\1_UpdateClientTableSchema_v(new version).sql, and the CourtWin.vbproj file are the only ones included in the check in. Add a comment then check in the changes.  

  • Open

    

     

• Team Explorer > Choose Builds > Filter for Benchmark Related Builds > Client Dev release 

  • Open

    
    Open

    

     

• Click Run pipeline 

  • The build process can take anywhere from 20-30 minutes.  It will get the latest, Todo a check for suspicious code etc.  

  • Open

    

     

    Open

    
• Open

  
  Open

  

   

Notes: 

• Defects that need to be added to multiple versions will each have a different defect ticket number.  

• When the package is done, it will send an email to QA to let them know the build is ready 

• The process will also update the defect tickets to Testing at PTG.  It gets the numbers from the What’s New files 

• Builds are on a physical build server because there are licenses required that are installed on that machine. Our IT is working to switch to Azure DevOps server eventually. 

• If the build takes longer than 60 minutes, it will fail.

  • If it has not completed the Copy to Downloads step, run the pipeline again.

  • If it has completed the Copy to Downloads step, the pipeline does not have to be rerun; the remaining steps can be completed manually.

Testing release: 

• Run the sql update scripts against a local database to make sure there are no issues.  

• The first one will update the schema, the 2^nd one will go through and add any field defaults needed or new rights to existing customers.  

SonarQube report will give you an overview of any potential bugs etc. 

• Open

  

   

 These may or may not be an issue for us with the specific use case of your methods.  

Open