-1

The problem:

An organization is developing a solution that contains

a web application project
class library projectS

You manage a continuous integration pipeline for the application.

Each time code is checked in, you must

build both debug and release configurations in parallel

The most recent build has compile errors for the release configuration but not for the debug configuration. Developers confirm they have tested the release configuration correctly works on their devices.

QUESTION: What is the reasons for the build issues? (SELECT ONLY ONE)

(i know "what IS the reasonS is just unfair, but it's as it is!!)

o The parallel builds caused contention issues for shared solution files.

o The web application references assemblies from the debug folder of the class libraries debug.

o A developer set their configuration to debug in Visual Studio.


For me is B.

NOT A, because you can use MSBuild Task's BuildInParallel option.

NOT C, because developerS confirm THEY have tested the RELEASE config (ON THEIR DEVICES)


Can you help me, please?

1 Answer 1

0

I would suggest that the answer is most likely to be B, although it may be A under some circumstances.

  • A: You can and should use BuildInParalell however sometimes this causes a race condition, for example, it could be that a developer omits the $(Configuration) in an output path meaning that both the Debug and the Release build output a file to the same location, then it just becomes a fight to see which build actually gets and locks that file first.

  • B: If a developer was referencing binaries in the Debug folder and it was a clean checkout then those assemblies wouldn't exist, although if they are being built in parallel on the same machine they, in fact, might exist.

  • C: If a developer sets their configuration to Debug (or anything else for that matter) it will impact builds on their machine assuming you use the /p:Configuration=Release option on the msbuild command line on the CI/CD environment.

It's entirely possible that Azure DevOps or any other CI/CD tool could be configured to rebuild each configuration in a clean container, thus meaning Release and Debug are actually being compiled in their own sandboxed filesystem thus can't possibly conflict with each other.

This isn't a great question for an exam because there is not quite enough information to differentiate between options A and B. Some exams do intentionally do this though, and often your best bet is to select the least wrong answer in which case I would select B.

2
  • I concur. The issue with B is most likely the cause. When referencing assemblies straight from bin/{debug|release}/** you have that race condition. For A, you should not have race condition if you're actually using 2 job agents b/c for each agents, you could have a clean copy of solution to work with.
    – Roman
    Oct 31, 2019 at 14:47
  • Wow full explanation! Yes it is B, thank you very much! Nov 4, 2019 at 9:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.