aswinfrancis
❔ Is there a way to set environment name in dotnet core without publishing for each environment?
From what I understand I need to pass environment name to dotnet task in yaml for each environment I need. Sample below. Which means build the same source code multiple times just to set the environment name. So if I have dev, qa, train and prod, I publish it 4 times and the artifacts are then extracted and deployed.
Is there a way I build ones and set environment name in azure yaml based on where its being deployed to
- task: DotNetCoreCLI@2
displayName: 'Build/Publish WebApi.${{ parameters.projectName }} ${{ parameters.framework }}${{ parameters.environmentName }}'
inputs:
command: publish
...
...
arguments: '-c ${{ parameters.configuration }} -o $(Build.ArtifactStagingDirectory)/WebApi -f ${{ parameters.framework }} **-p:EnvironmentName=${{ parameters.environmentName }} **--no-restore --verbosity minimal'
...2 replies
How to version multiple self maintained dependent SDK packages pushed via azure pipeline?
We have multiple components that have SDKs generated and pushed a private package repository during build process. Right now we have all of them in the same version. For example, lets say we have order, payment and shipment component currently on v1.0 and now we make a major change only to shipment component, then we make sure all of them are set as v2.0 even though change is only to one component. All of these packages are in individual repos too. When ever a PR is raised to dev branch, it adds patch version with alpha tag to it. dev to master will have beta tag and only patch version is updated. If need to make major version like in the example all of them need to be on the same major version because package references in our csproj are like '1.0-alpha-*'
1) Is there a better way to handle versioning?
2)Looking at a way to minimize manual intervention?
1 replies
What is the best practice for versioning multiple API based components?
Our team is working on different API based components that are all packaged as separate client SDKs. They SDKs are referenced by a hub component that acts as a mediator for all communication between these components. Right now all changes are pushed to release branch at the same time and same versioning is maintained. So if component A and B has change but C didn't have we would still bump up all 3 components version to lets a 2.0 and we would also ensure that hub refers to 2.0 SDK version of all components. I am suggesting that we should have API versioning and the SDK package versioning shouldn't matter? i.e.., each component SDK package can be in its own version and we can set hub to always pick the latest version of the packages available. Any thoughts?
2 replies
