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

<ul>
<li><p><strong>A</strong>: You can and should use <code>BuildInParalell</code> however sometimes this causes a race condition, for example, it could be that a developer omits the <code>$(Configuration)</code> in an output path meaning that both the <code>Debug</code> and the <code>Release</code> 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.</p></li>
<li><p><strong>B</strong>: If a developer was referencing binaries in the <code>Debug</code> folder <strong>and it was a clean checkout</strong> then those assemblies wouldn't exist, although if they are being built in parallel on the same machine they, in fact, might exist.</p></li>
<li><p><strong>C</strong>: If a developer sets their configuration to Debug (or anything else for that matter) it will impact builds on <strong>their</strong> machine assuming you use the <code>/p:Configuration=Release</code> option on the <code>msbuild</code> command line on the CI/CD environment.</p></li>
</ul>

<p>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.</p>

<p>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 <strong>least wrong</strong> answer in which case I would select B.</p>

CC BY-SA 4.0
2019-10-31T14:47:21.167Z
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
CC BY-SA 4.0
2019-11-04T09:13:00.023Z
Wow full explanation! Yes it is B, thank you very much!
Rafael Gramoschi
CC BY-SA 4.0
2019-10-31T13:30:12.070Z
2019-10-31T13:30:12.070Z
Richard Slater
<p><strong>The problem:</strong></p>

<p>An organization is developing a solution that contains</p>

<pre><code>a web application project
class library projectS
</code></pre>

<p>You manage a continuous integration pipeline for the application.</p>

<p>Each time code is checked in, you must</p>

<pre><code>build both debug and release configurations in parallel
</code></pre>

<p><em>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.</em></p>

<p><strong>QUESTION: What is the reasons for the build issues? (SELECT ONLY ONE)</strong></p>

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

<p><strong>o</strong> The parallel builds caused contention issues for shared solution files.</p>

<p><strong>o</strong> The web application references assemblies from the debug folder of the class libraries debug.</p>

<p><strong>o</strong> A developer set their configuration to debug in Visual Studio.</p>

<hr>

<p>For me is B.</p>

<p>NOT A, because you can use MSBuild Task's BuildInParallel option.</p>

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

<hr>

<p>Can you help me, please?</p>

<continuous-integration><azure-devops><configuration><builds>
Last Question on CI-CD edx.org Final Exam
Rafael Gramoschi
# Last Question on CI-CD edx.org Final Exam

(Asked by: username_0 on 2019-10-30)

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?

**Tags:** continuous-integration, azure-devops, configuration, builds


---

## 1 answers

### Answer by username_1 on 2019-10-31. Score: 0 | Accepted answer

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.

> **Comments:**
> **username_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.  
> **username_0**: Wow full explanation! Yes it is B, thank you very much!  

---

