Home → Questions →

How to create both a Test and Production artifact

• Edit

kirk.miller

16 Mar, 2017 05:37 PM

Hello..

Newbie here ..

Situation is I have an AppVeyor project that I deploy my project bits to, and this is using a Powershell build script that uses a test environment/publish of our solution build. That's been working fine. Now I want to have both a test version, as well as a production artifact that gets deployed to AppVeyor. My question is this .. should I create a second AppVeyor project to contain the production version, or should the production artifact live with my existing AppVeyor project (i.e. there would be two artifacts, one for test, and one for prod)?

Ideally, we would like to have just one AppVeyor project that contains both the test and production artifacts .. if that's doable.
Thank you,

1. 1 Posted by Ilya Finkelshte... on 17 Mar, 2017 02:52 AM

   

   Hi Kirk,

   I hope I understand your question correctly. I believe it can be the same project. Test and production is usually in different branches in GitHub or other source control, so you can alter build/publish behavior based on branch. Artifacts are tied to specific build, so you will not mix production and test artifacts.
   Please feel free to ask any additional question. YAML configuration (use Export YAML if you use UI) and build logs are usually very helpful for us to understand the problem.

   Thanks!
   Ilya.

   • Edit

2. 2 Posted by kirk.miller on 17 Mar, 2017 05:53 AM

   

   Thanks for the response, Ilya. Let me clarify ..

   Yes, we have feature branches, as well as a develop, master, and release branches (following Git-flow). Our AppVeyor build comes into play only when we push a tag.

   When I say "test and production" I'm not referring to a branch. I'm referring to the Visual Studio configuration environment ("debug", "release", etc) that is set when a solution is built. On any of our branches we can choose one of these configurations and build the solution, and it will compile the solution output files (assuming no compile errors). These different environments compile slightly different sets of bits, and my goal is to have a test and production version. This allows a clean deploy to test and production servers, and no need to manually update anything. I could do this by kicking off my build (twice) and setting which configuration to use, but I want this automated, and to only use what gets pushed up to AppVeyor, hence my need to have multiple artifacts on my AppVeyor project.

   The need that I have is this .. when my build executes I want to compile both a test and a production output and create two AppVeyor artifacts. I want both of these artifacts contained under the same AppVeyor project, instead of having two projects (i.e. one for the test and one for the production). I think I have this problem solved, but I'm interested to see if there's a best practice that I've missed.

   Thanks. Hope that helps.

   Cap

   • Edit

3. 3 Posted by Ilya Finkelshte... on 17 Mar, 2017 06:01 AM

   

   Ah, I see now! Configuration is first-class dimension for build matrix, I believe it should fit your needs.

   • Edit

4. 4 Posted by kirk.miller on 17 Mar, 2017 06:50 AM

   

   Yes, I saw the build matrix documentation. However, my .yml file is pretty bare bones and lets my powershell script do most of the work. Because I have the actual build process in the PS script, I assumed (perhaps incorrectly) that the .configuration setting would not affect my build.

   My solution turned out be be as easy as simply calling the powershell script twice and passing the appropriate config/publish settings, like this:

   build_script:
     - ps: .\build.ps1 TestDev TestDev
     - ps: .\build.ps1 Release Production
   

   This creates two separate build artifacts under my one AppVeyor project, and I think the problem is solved.

   • Edit

5. 5 Posted by Ilya Finkelshte... on 17 Mar, 2017 07:49 AM

   

   Yes, configuration would not affect your build. You still can do matrix with something like this (did not test this specific script but you got the idea).

   - ps: if ($env:Configuration -eq "Release ") {$Deploy_environment = "Production" } else {$Deploy_environment = $env:Configuration}
   - ps: .\build.ps1 $env:Configuration $Deploy_environment
   

   But maybe you do not need it because you what for build to throw if test is not happy.

   Just FYI, another option is to have separate projects and call release build with API from testDev build if needed. API call sample.

   --ilya.

   • Edit

6. kirk.miller closed this discussion on 17 Mar, 2017 09:24 PM.

7. kirk.miller re-opened this discussion on 17 Mar, 2017 09:24 PM

8. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:15 AM.