Single Packaging Job

When a single packaging job is triggered by a single commit, packaging tasks are performed in linear order. 

1. Check out from SCM
   • Project file
   • SQL scripts included in a commit
2. Package each script
3. Deploy changes to the REF database
4. Commit changes to SCM
   • Project file
   • SQL scripts included in a commit
5. Update sqlSCMLastChangeID

Packaging Jobs at Speed

Packaging scales correctly under load. As you scale up the number of developers who commit code on a project and the number of commits over time, packaging jobs do the right thing when multiple commits are performed. In a CI/CD setup, the SCM is set up so that a commit triggers a packaging job. in the following example, consider what happens when commits 2 and 3 are performed before packaging job 1 gets to the point of reading the SCM for commit 1. 

1. Commit triggers packaging job 1 
   • SQLfile_A.sql
   • SQLfile_B.sql
2. Commit triggers packaging job 2
   • SQLfile_A.sql
   • SQLfile_C.sql
3. Commit triggers packaging job 3
   • SQLfile_A.sql

Q: What happens when the commits for packaging jobs 2 and 3 come in so fast that packaging job 1 finds both later commits for SQLfile_A.sql? 

A: Packaging job 1 picks up commits made since the last sqlScmLastImportID. If other commits were made between the start of the packaging job and the time it reads the SCM, those commits are picked up too. 

Q: In the example what do packaging jobs 2 and 3 do in response to SQLfile_A.sql?

A: If a packaging job is run after a commit's changes have been packaged, it updates the pipeline label and then ends. In the example, if packaging job 1 picks up all the commits, then subsequent packaging jobs perform the following actions:

• Packaging job 2 packages SQLfile_C.sql but only updates the pipeline label for SQLfile_A.sql
• Packaging job 3 only updates  the pipeline label for SQLfile_A.sql