I'd like to create a CruiseControl.NET task to mimic the publish functionality for web applications in Visual Studios. Any suggested approaches or examples? Thanks.
I implemented the RoboCopy task found in the Nightly Build of MSBuild Community Tasks http://msbuildtasks.tigris.org/ and excluded certain files in the copy to my release directory I created.
Related
We are still using an in-house TFS 2012 server but I'm now looking at moving to VSTS. I have a couple of questions though:
Years ago I customised our build process template to perform a number of additional tasks, and I was wondering if VSTS builds can be customised in a similar way, specifically to do what we currently do:
Run StyleCop
Change the version number in every AssemblyInfo.cs file in the solution prior to building (the major and minor numbers are specified in the build definition).
Run a batch file at the end of the build which runs an InnoSetup script to create a "setup.exe" file (the batch filename is againspecified in the build definition).
(The first two are (I think) DLLs that came from the now defunct tfsbuildextensions.codeplex.com site).
Second question: we currently have an in-house NuGet repository. Am I right in saying I could host this on VSTS instead? And will that be accessible both to VSTS builds and our dev team?
The newer build system is fully extensible. You can simply add "Command Line", "Batch File", or "PowerShell" tasks to run whatever commands you'd like during your build process. Any customizations you made to your XAML build process templates will have to be ported manually, but it's entirely possible that someone has created free extensions that are available to install from the VSTS marketplace that replicate the behavior you're seeking.
VSTS supports package management feeds. It's an extension and requires additional licensing, but the simple answer to your question is "yes".
How can I achieve CD (Continuous Delivery) for winform applications in VSTS (Visual Studio Team Services)? Currently this is what I have in my Visual Studio Solution file
1) A winform project
2) A Windows setup and Deployment project
So every time I build a winform project, I do the following steps (and I need CI / CD for exactly these)
1) Build Setup and Deployment project, which takes Build output of Winform project and creates and EXE / MSI
2) I take this MSI file and use NSIS to embed it inside EXE
3) I run SIGNTOOL from command prompt and digital sign the EXE
4) I upload this signed EXE to my website
Now how can I use CI / CD pipeline to automate the above or is it not possible for my case? I am confused. I can't find any material for winforms, all are for web apps.
Thanks
You will obviously need some sort of desktop deployment strategy. The easiest is to be using xcopy. Other alternatives include frameworks like ClickOnce, Windows Installer or Squirrel to name a few. I have a number of corporate apps that use Clickonce that I have deployed using vsts.
Now I am unable to understand how will VSTS help me with this?
Use VSTS to build the software first and include additional tasks to package your app. In my case, I use devenv.exe to generate ClickOnce packages, but you can include custom tasks by using powershell. The artifact of the build should now be the "packaged app".
Then use the VSTS deployment to copy the "package" to some kind of hosting server from where your users can download the package. That could be either a web server or a fileserver or any location appropriate for your deployment strategy.
In this context, VSTS is an orchestration tool. It helps to trigger actions for you.
See Deploy an agent on Windows to see how to setup an on-premise agent.
To build and deploy the way as you used in VSTS, you can use below steps:
Create a repository (Git or TFVC) and push your solution in the repository.
Add build/release definitions.
With CI build, enable the Continuous Integration in Triggers Tab. With CD deploy, enable Continuous deployment trigger in Pipeline Tab. The process for CI build and CD deploy, you can refer CI/CD.
Add related tasks in your build/release definition.
Build VS Installer task: build setup project with msi file.
Nsis Build Task: embedded msi file in exe.
Command Line task: to execute the signtool command. Since Hosted agent has not signtool.exe, so you should use private agent which has the signtool.exe on the machine.
Copy files task, Copy Files Over SSH task or Windows Machine File copy task: upload the file exe to your web server.
I have used the
/p:GenerateProjectSpecificOutputFolder=True for creating build for each and every project in my solution and now i wanted to customerize the folder structure on my needs. How can we achieve this?
enter image description here
If you are using XAML build, you can customize Binaries folder in TFS Team Build by modifying the build process template. Adding CreateDirectory Activity and FindMatchingFiles activity are necessary, following this blog for more details.
If you use the new build system, that will be much easier to manage artifacts. With task Publish Build Artifacts, you can specify contents in the task, also you can add as many Publish Build Artifacts task as you want to manage artifacts. More details, check http://www.codewrecks.com/blog/index.php/2015/06/30/manage-artifacts-with-tfs-build-vnext/
Alternatively you can extend your build definition with a PowerShell script at different points within the build:
Pre-build
Post-build
Pre-test
Post-test
Note I am using the TfvcTemplate.12.xaml template. This is the build template that comes with TFS 2013.
I'd like to check in assemblies to TFS source control after successful project build on TeamCity. Are there any elegant and easy way to do that?
I can create a command line step and run tf.exe with parameters, but then I need to provide credentials to connect to TFS, map the directories and finally do the check in.
The second option is to set up the powershell step, and use one of the cmdlets, but this requires installation of cmdlets on the build machine which I don't want to do.
Have you got any experience in such case? Maybe I can use the credentials used by TeamCity to get the sources, and do not map the directories but use the downloaded structure / sources?
This answers your question but it is not normally a good idea to commit binaries to your source control. You have a couple of choices.
Create a nuget package manually:Nuget Packages can be stored in a
shared folder. You can manually create a package in 5 minutes.
If your other projects are built using teamcity, check out artifact
dependencies in teamcity.
TF.exe commandline tool is the best feasible option for this scenario.
We got a TeamCity server which produces nightly deployable builds. We want our beta tester to have access these nightly builds.
What are the best practices to do this? TeamCity Server is not public, it is in our office, so I assume best approach would be pushing artifacts via FTP or something like that.
Also I have no clue how to trigger a script when an artifact created successfully. Does TeamCity provide a way to do that?
I don't know of a way to trigger a script, but I wouldn't worry about that. You can retrieve artifacts via a URL. Depending on what makes sense for your project, you could have a script set up on a scheduler (cron or Windows Scheduling) that pulls the artifact and sends it to the FTP site for the Beta testers. You can configure it to pull only the latest successful artifact. If you set up the naming right, if the build fails they beta testers won't notice because the new build number just won't be there, no bad builds would be pushed to them.
Read the following help page from the documentation. It shows how you send commands from your build script to tell teamCity to publish the artifacts to a given path.
In TeamCity 7.0+ you can use Deployer plugin. Installation steps can be found here. It also allows to upload artifacts via SMB and SSH.
I suggest you start looking at something like (n)Ant to handle your build process. That way you can handle the entire "build artifacts" -> "publish artifacts" chain in an automated manner. These tools are dependency based, so the artifacts would only be published if the build succeeded.