At project > settings > versions you can create versions and apply Build and Release on a version. I totally understand what Release means here (it applies a release date and sets the state to released), but what does Build mean here?
This is an excerpt from official JIRA documentation:
Build the release.
The next step is to build the release. A release is essentially a snapshot of the artifact(s) and related metadata that will be deployed. A release is created from a single build.
If you have connected JIRA Software to Bamboo, you can automatically run a Bamboo build when you release a version. Otherwise, if you haven't connected JIRA Software to Bamboo, or you are using a different build tool, you will need to run your builds independently.
So, primary purpose of the build option is to automatically run Bamboo build if Bamboo and JIRA are connected.
Related
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
I'm new to version control systems and have been tasked with revamping our company's version control (small system right now). We have library files that will get updated, but we also need to support older versions of these libraries for different generations of our product. Part of my task is to set up an automated unit testing system that will do nightly checkouts, if newer code has been checked in since the last test run.
You will likely need to keep multiple branches of your libraries in source control, one for each version that will be supported/changed in the future. Each of these branches should have a build definition created to build the code and then run the unit tests against the code. The builds can be setup to run in
CI mode which will build on every checkin
Gated checkin mode (my personal favorite) which won't commit the checkin until the build and test run completes successfully.
Something has managed to break on my TFS build. Whenever my deployment build is selected to a specific build, it shows the possible configurations (in my case dev1, dev2, test1, test2 and prd). However when I select <Latest> it disables the possible configurations. My deployment relies on this so it fails.
Where does TFS get these configurations for <Latest>? I'd have thought from the latest successful build. But this does have configurations when I select that specific build.
Any tips?
According to your information, guess you are using release management for the deployment.
If you select <Latest>, release management will catch the latest successful build of the build definition. It will ignored the failed build. Just as you guessed.
If you select <specific build>, then it will list the all successful build result of the build definition.
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
I am trying to do a full CI-CD cycle using TFSonline.
when I go with 'AzureWebsite' along with Visual Studio Online, it provides me with a build definition using 'tfvccontinuousdeploymentTemplate.12.xaml'.
On check-in I get the output, the build triggers and deployment also happens to the azure website. The log contains build along with my deployment details, which is also reflected on the TFS portal
When I go the conventional iis route, I tried 2 steps
With Default build template and the good old ms build arguments /p:DeployOnBuild=true /p:VisualStudioVersion=12.0 /p:PublishProfile="dasd.pubxml" this does the build and deploy but I don't get the 'deployment summary', which is to be expected, because i did it via ms deploy...
I used the tfvccontinuousdeploymentTemplate and provided the build settings as the publish xml... well... build happens but the deployment does not
I'd like the build to contain the deployment summary for my deployment.
TFS Online has since been replaced by Visual Studio Online and since by Visual Studio Team Services. The XAML based build engine has been marked for deprecation and will be removed from Team Services in the near future.
The hosted build controller has since been upgraded with build templates for Visual Studio 14, upgrading to the latest tfvccontinuousdeploymentTemplate.14.xaml may also sole your issue until the XAML build engine is removed.
The new Build Engine ships with a "Deploy to IIS" task and there is a 3rd party MSDeployAllTheThings extension which makes it very easy to pick up packaged Web projects.
Your solution to switch to InRelease has since also been replaced by 2 different versions of Release Management and the latest release management feature uses the same tasks as the new build engine uses. So it's able to use the same Deploy to IIS and MSDeployAllTheThings task.
Due to the fact that this question is related to a SaaS solution, the old options are no longer available or will soon be removed.