With CICD done, On every commit VSTS creates the build and deploys it to the target environment successfully.
I want to understand how the build is done, is it incremental OR full build every time I commit the change in the .net project.
If anytime I want to rollback, to the previous working build does VSTS does it or I need to configure or follow some procedures to do it hassle free ?
If you are using Hosted agent, it is full build every time. (Need to download source, build whole projects)
If you are using private build agent and do not clear anything (e.g. In Get sources, clean is false; Visual Studio Build task, clean option unchecked), part of build will be up to date if source not be changed. (can just download the updated files and skip some build targets if build results are up to date)
The VSTS can’t rollback the build, you can roll back changes, then rebuild and redeploy. There is a blog about rollback: Implement Rollback with Release Management.
Related
I am new to using Azure DevOps builds/pipelines, as the source code for the solutions I need to build are in TFVC I am limited to using the Classic (i.e. UI) builds rather than YAML.
When I want to test changes to a build definition I sometimes want to run a clean build, i.e. ensure that sources and artifacts from earlier builds are removed before the new build run, yet leave normal builds (i.e. ones triggered by changes in TFVC) to be incremental so to make builds faster.
I am used to TeamCity which has a plethora of options with regards to managing source and artifacts retention between builds, including a simple "clean" check box when triggering a manual build.
ADO Builds seems very limited in this regards and if I want to have a clean build it seems the only option is to change the build definition, select clean, run the build, then change the build definition again to remove the clean option.
Are there better ways to manage "ad-hoc" clean sources and artifacts in ADO Builds?
Those settings are either on/off. They wouldn't accept conditional run-time variables.
That being said, you might try leveraging the "Save as draft" option. It seems to create a DRAFT pipeline definition you could execute for your changes.
You could probably just flip it back to no clean before publishing. I don't really use that feature, but I am going to guess on the back-end it is using a different temporary definition id. That will probably mean on the build agent a new folder gets created under _work. If that is the case, you probably wouldn't even need to flip the clean sources since it will not exist the first run. It also probably means if this a self-hosted agent you will have doubled the work folder size and you might have to manage that clean-up after you are done.
If it does create the second work folder, this is probably preferable as it means you won't break the incremental build on the build directly following your test with clean. Whether you did that ad-hoc or through editing the build definition.
Build.Clean variable is deprecated, you can only use Clean option to clean local repo on the agent currently.
I'd like suggest you submit a user voice at website below, product team will evaluate it carefully:
https://developercommunity.visualstudio.com/content/idea/post.html?space=21
One workaround is adding a Post Build Cleanup task in the end of your pipeline, when you want to run builds incrementally, you can disable this task.
I have a single .NET solution with multiple class library projects, each one is published as a nuget feed using azure-devops.
Then I have an azure-devops build pipeline, with steps to Restore, Build, Publish, Pack and Push.
The first 4 steps are setup for **/.csproj and the last is a $(Build.ArtifactStagingDirectory)/.nupkg with the target feed.
I have everything set up and working, except if you make a change to just one project, it builds ALL projects because of the **/*.csproj.
This is no good for nuget packages, as it increments every project's version number and they all appear as having an update available in the nuget package manager.
My Question: Is there a way to do this so that only the project(s) with changes go through the process?
Is there a way to do this so that only the project(s) with changes go through the process?
The answer is yes.
The solution is use the private agent to build your solution instead of the hosted agent.
That because every time the hosted agent assigned to us is a clean machine, VS/MSbuild will build all the projects for the setting **/* csproj. So, to resolve this issue, we must save the results of the last build to achieve incremental builds.
So, to resolve this issue, we need to set up a private agent to build those projects and do not clean the working directory of your private agent before the build is run:
Set the Clean option to false on the Get sources:
Note: Since you also set the **/*.csproj for the task nuget push, if the project not modified, this command will push the same version to the feed, it will throw the conflict error, you need enable Allow duplicates to be skipped on the nuget push task:
Hope this helps.
I have successfully created a Build definition in VSTS for some SharePoint client side projects that I'm working on. I tried creating a Release definition but I can't seem to find any way for me to copy/download the artifacts created from my build definition locally. I may be missing something since I'm still quite new with VSTS but I can't seem to figure it out.
To downbload build artifacts from release when build successful, you can specify the release definition as below:
Add the build artifacts with latest version in release definition.
Enable Continuous deployment trigger for the artifacts.
Select the private agent which you want to download on the local machine.
Now when a build succeed, a new release will be triggered to download the latest build artifacts.
We are running TeamCity Enterprise 7.0.4 (build 21474)
We have teamcity CI/incremental builds running every 15 minutes or so.
The incremental builds identify the VCS activity, checkout the new/modified code, and run a build.
We need this CI build to trigger another teamcity project. The triggered project needs information about the VCS changes that were checked out and built by the CI project.
To be specific we need VCS author(s) user id(s), their email id(s), and the file(s) modified
Seems this info can be obtained via Change Log/Pending Changes from teamcity
Any pointers, how to pass this info to the triggered project
Thanks
You can try using snapshot dependencies. What is the VCS you are using ?
Solution depends on what you want:
* Show changes from first project in changes log of second project (TeamCity UI only)
Set snapshot dependency.
* Changes list inside build step as data for some process (writing into changelog.txt or something similar)
Use TeamCity Rest API to obtain such information.
Use query "/app/rest/changes?locator=build:(id:BUILD_NUMER_HERE)" to get build changes.
Build number could be obtained by empty artifact dependency or snapshot dependency.
If there a dependency, you can address parameters of first build as %dep.btxxx.build.number%
More documentation:
About dependencies
About Rest Api
About parameters from dependencies
I was hoping for some guidance on the best way to promote a build through its environments.
We have 3 environments, DEV, STAGING, PROD.
The DEV Jenkins build is running in a continuous integration set-up, as code is checked in to subversion, Jenkins will run a new build (clean, compile, test, deploy).
The tricky bit is when it comes to STAGING and PROD.
The idea was to be able to manually promote a successful DEV build to STAGING.
STAGING build would check out the DEV's SVN Revision number, build, test, deploy to staging and finally create a branch in SVN.
Lastly the release manager could manually promote the STAGING build to PROD.
PROD build would check out the branch from the previous STAGING build, deploy to PROD and tag the branch as a release.
I have tried to use a combination of the Promotion Builds Plugin and the Paramterized Trigger Plugin but with no luck. The Subversion Revision number doesn't seem to get passed between DEV build to STAGING build.
Does anyone have any guidance on their process to promote a build through multiple environments?
Another approach is to make use of the Artifact storage Jenkins provides coupled with the Copy Artifact Plugin.
When a build is completed, you could instruct Jenkins to persist your application, either as a compressed zip/tar.gz or as an application bundle (jar/war)
Trigger a downstream job and use the Copy Artifact to retrieve the recorded artifact from the upstream job (or use parameterised builds)
Deploy/Unzip artifact as necessary - Build shell script/maven deploy?
Retest application using the same sources/binaries as was created in step 1
Repeat for PROD as necessary
This approach would allow you to fingerprint the artifacts, and thus Jenkins would link builds together in the UI, as well as allow more formal sign off.
In this scenario, why do you need to go back and label the branch in svn? We don't use svn, but w/ TFS, when Hudson/Jenkins gets the code, the changeset number it has retrieved is in the build log. So we know what code the build came from, and could get back to it at any time.
Then we promote the build from environment to environment using Hudson, the source control system doesn't need to know where the code is deployed.
If it's absolutely necessary to store the SVN Revision ID, then add a build step to your DEV job that copies it to a file. Something like this:
echo %SVN_REVISION%>revision.ini
or something like this:
echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini
Then artifact revision.ini. When doing a STAGING build, use the Copy Artifact plugin (as mentioned by a previous user) to retrieve the revision.ini file specific to the build and load it into a variable. Then use that variable in a command line call to "svn" to build the tag.