search

microsoft / AL-Go

The plug-and-play DevOps solution for Business Central app development on GitHub
MIT License
277 stars 114 forks source link

Split build from publish and test #812

Open freddydk opened 10 months ago

freddydk commented 10 months ago

Summary

Today, the build step in AL-Go is done using Run-AlPipeline from BcContainerHelper. Run-AlPipeline will build, sign, publish and run tests. for Performance reasons and due to new code signing requirements, this process needs to change.

  1. Building the apps should be done first
  2. Then Signing
  3. Then publishing and running tests.

Only step 3 requires an actual BC instance (Container or like). Building and signing can be much faster using this approach.

Additionally refactor the build part of workflows to use an composite action, to capture the build parts in one area.

Current structure:

Image

New structure (single project):

Image

New Structure (multi-project):

Image

It should also be possible run the p1 tests together with the p2 tests to validate that p2 didn't break p1 tests.

Success Criteria

TBD

Implementation

TBD

Try it out

Not yet available

fvet commented 6 months ago

@freddydk I see this is labelled '2024 w1' (although draft PR pending). Can we expect this as part of the April release? Not having to spin up a container for building apps would certainly decrease our build time.

freddydk commented 6 months ago

Nope - not going to make it - will have to go through the plan and adjust, sorry

mazhelez commented 2 months ago

Splitting the build and test jobs is possible even today by splitting the apps into different AL-Go projects.

Of course, that way apps and test apps will be in different artifacts for delivery/deployment. So, I believe we'll try another approach: having the ability to bundle apps from different AL-Go projects together.

fvet commented 2 months ago

I'm not quite sure if I follow the suggested solution, but our goal is to keep to one repository, containing all apps, so we can deploy / release them all together as one solution, similar to how the MS multi-app repo's are structured.

image