I am using TeamCity (version 9.1.5 if that matters) and I am trying to figure out how to create a trigger that deploys the project to a server. Or maybe there is a way to deploy a project to a server without using a trigger on TeamCity.
It's a very broad question, but I will share the approaches I have used in a couple of scenarios:
1) To deploy when a code checkin is performed, I have setup a build configuration that does the deployment, added the build configuration that does the compiling & packaging as a snapshot and artefact dependency which is then triggered with a Finish Build Trigger https://confluence.jetbrains.com/display/TCD9/Configuring+Finish+Build+Trigger
2) To deploy at a given time of the day but only when new code has been checked in, I have setup a build configuration as above but triggered with a Schedule Trigger https://confluence.jetbrains.com/display/TCD9/Configuring+Schedule+Triggers ensuring to select the dependent build in the Build Changes section.
With regards to how to perform the deployment there are many options, I have used WebDeploy for ASP.Net applications and MSI packages executed by Remote Powershell scripts for Windows Services, but other options are also available depending on the technology you have.
JetBrains provide an end to end example for ASP.Net in their on-line documentation, search for "Continuous Delivery to Windows Azure Web Sites (or IIS)"
Related
My company is developing a web application and have decided that a multi-tenant architecture would be most appropriate for isolating individual client installs. An install would represent an organization (a nonprofit, for example) and not an individual users account. Each install would be several Cloud Run applications bucketed to an individual GCP project.
We want to be able to take advantage of Cloud Build's GitHub support to deploy from our main branch in GitHub to each individual client install. So far, I've been able to get this setup working across two individual GCP projects, where Cloud Build runs in each project individually and deploys to the individual GCP project Cloud Runs at roughly the same time and with the same duration. (Cloud Build does some processing unique to each client install so the build processes in each install are not performing redundant work)
My specific question is can we scale this deployment technique up? Is there any constraint preventing using Cloud Build in multiple GCP projects to deploy to our client installs, or will we hit issues when we continue to add more GCP projects? I know that so far this technique works for 2 installs, but will it work for 20, 200 installs?
You are limited to 10 concurrent builds per project. But if you run one cloud build per project, there is no limitation or known issues.
Looking at some of the delivered SAPUI5 code on HANA I noticed that WebStorm and even RubyMine was used by some SAP developers. I have also heard that various other developers on customer sites use WebStorm for code checked into the ABAP repository.
Both the HANA and ABAP repositories technically look to be proprietary. The default method for syncing SAPUI5 code with HANA and ABAP repos seems to be using Eclipse or the Eclipsed based HANA Studio, via SAP delivered plugins installed.
I searched and couldn't find any plugins or help on how you could check in and out of HANA or ABAP repo easily not using Eclipse or Orion.
For HANA you can put Github in the middle using something like the SAP HANA Deployment Shell and on the ABAP stack you can /UI5/UI5_REPOSITORY_LOAD to manually upload, i have heard alternatives for both where developers have reverse engineered the services eclipse use by listening on the HTTP traffic or de-compiling the plugins.
My question how are others using Webstorm to develop SAPUI5 applications within a team and how do you sync your code with the SAP repository?
I use Webstorm for my UI5 development. We store the code in a GIT repository hosted through an internal Gitlab server (https://about.gitlab.com/) running on Ubuntu! You could just as easily use cloud solutions such as Gitlab or Bitbucket.
There are two ways to circumvent Eclipse and remove the need for the ABAP team repository:
(1) Use the abap program /UI5/UI5_REPOSITORY_LOAD in t-code SE38 on your Gateway ABAP stack. Just point it to your git directory and execute!
(2) Use the program /UI5/UI5_REPOSITORY_LOAD_HTTP to do the same thing from a webserver. You could imagine a scenario where you have a HTTP service that triggers the pull on SAP but we always use the first method!
Edit # 03-SEP-14
To clarify my thoughts on (2) the ideal scenario would be to implement a small post commit handler so that on a repository change it would:
Pull the changes from the repository
build the UI (i.e. perform minification/uglify on the JS & CSS) to a separate build folder (create preload files)
perform any unit tests on the code (if they exist)
if the tests pass, upload to Gateway by either:
zip the build folder and post it to a custom Gateway service (or)
call a custom gateway service to then trigger a pull of the build folder via HTTP
(Since master is always deployable :-)!)
You end up with a continuous integration platform that ensures the integrity of your code and ensures that you also deploy only the production code (always a little uncertain of deploying non-minified source code with comments etc. to a productive internet facing server..).
This method is agnostic of the IDE you use and if you do it right, also of the source code repository setup.
Hope this helps & happy developing!
Oli
I am trying to improve our general automation process. We use VS2012 and TFS2012.
Here is what I want to happen upon checkin to our CI branch:
BUILD
Build the selected projects / solutions as configured in the build definition settings.
Generate a deployment package that can be used to deploy the websites (without having to rebuild the entire project again)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL
Run all configured unit tests.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent breaking changes entering our development environment
Take deployment package from (1.2) and publish it to it's intended environment (hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS
Take nuget package from (1.3) and publish it to our private nuget gallery
I don't need a full tutorial (although that would be awesome) for the entire process, but more how to go about integrating it.
For instance:
Should I use msbuild on a wrapper project?
How do I deal with creating the packages upon build on the TFS build server?
How can I enforce the "IF AND ONLY IF ALL UNIT TESTS PASS" constraints?
What is the best / easiest way to perform the deployment /publishing after as part of the build.
This is the process we want to use and any help is realising this is very much appreciated.
And I'm sure many other people are interested in how to set about integrating this style of process.
Also if it's relevant most solutions have a mix of shared dll projects, websites / apis, and unit tests. One of the reasons I want this process is to be able to split them up and modularise our large dlls into smaller isolated units, which would be to unmanageable ATM without this auto publish mechanism.
Thanks,
Gary.
BUILD Build the selected projects / solutions as configured in the build definition settings. Generate a deployment package that can be
used to deploy the websites (without having to rebuild the entire
project again)
This is out of the box, add deployment profile to your projects, call them 'Release'
Add the following to your MSBuild Arguments
/p:DeployOnBuild=true;PublishProfile=Release
you don't have to use Release, as long as your Publish Profiles match what you put in the MSBuild arguments
This will generate the deployment files as part of your build (MSDEPLOY)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
See Nugetter on code plex http://nugetter.codeplex.com/
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL Run all configured unit
tests.
Should be out of the box, but you can change the build template to fail the build should compilation be unsucessful, if this suits your needs better.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent
breaking changes entering our development environment Take deployment
package from (1.2) and publish it to it's intended environment
(hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS Take nuget package from
(1.3) and publish it to our private nuget gallery
See Nugetter on codeplex as listed above
I've a question regarding Build Servers for .NET Projects. Currently I'm using TeamBuild in conjunction w/ TFS 2010 to do automated builds in the .NET world. Some older projects are built using plain old MSBuild scripts.
To get rid of the administrative effort I'm currently moving my sources to github. Github offers, as many other sites service hooks to trigger build servers for doing automated builds such as CI or nightly builds.
Sure I could use TeamCity OnPremise and dynamically create Build Agents in Windows Azure using VMRole and Virtual Disks, but I think this hybrid solution is a little bit moronic.
So what are your thoughts about the following architectural idea?
Let's say you're using github as source control platform. When commiting sources to your repository an Azure WebRole hosting a WCF Service will be triggered.
The WebRole itself will just use the Azure API to fire up a new instance of a custom Azure VMRole.
The Azure VMRole itself will use some kind of buildscript such as Rake or MSBuild to have as few developer tools installed on the build agent as needed. After building the entire project the artifacts will be published to Azure BlobStorage and the WebRole hosting the WCF service will be called again, but right now the Azure WebRole is going to terminate the BuildAgent.
While using such a setup you could minimize the costs for the build agent and build nearly any kind of project as far as you're able to install the required element for the build by using PowerShell.
So in bottom line: what are your thoughts on this architecture? Other Ideas? Is there an existing service offering such a solution?
Thorsten
have you looked at https://appharbor.com ? I know a number of people who are using it to do exactly what you are doing.
Check out Team Foundation Service as it can do the following:
Continuous Delivery to Azure
Deploy to production on Windows Azure with two clicks from Visual Studio, or automatically as part of your build process.
Just found this one http://www.appveyor.com/ AppVeyor is also free for OpenSource projects.
We have multiple groups running their own TeamCity setups inside the firm. My group provides a set of generic libraries that other project groups use in their projects. We use TeamCity to push versions of our libraries to production. What I need is a way to automatically trigger builds on other group's CI system that depend on our libraries once we push a new version to production? I already have have the scripts to upgrade to the latest version etc ready. Right now it is manual, i would like to automate it and have a new build of the dependent projects triggered once we release a version to production. I am looking for a way to push the trigger notification across Teamcity instances.
You can trigger TeamCity builds using an HTTP request so you could modify your build script to make the required requests at the end of the build. This does have the downside that you need to hardcode the list of builds that need to be triggered on the remote servers into your build script.
The syntax for the HTTP request is:
http://<user name>:<user password>#<server address>/httpAuth/action.html?add2Queue=<build type Id>
For full details take a look at this page of the TeamCity documentation:
Accessing Server by HTTP