I want to skip certain steps on a Octopus project while doing automated deployment from Teamcity. I have read through the docs on how to set this up, and got it to do the deployment.
How do I go about skipping some Octopus deployment steps while using this ? Or should I create a seperate octopus project for automated deployments that only contain the basic steps, then another project containing all the steps ?
Please any help would be appreciated.
I achieved this (or something similar) with a fake environment.
We have an environment called "live - inactive" which only contains the octopus server machine. This step queries our load balancer and promotes the deployment to one of our real live environments. Our deployment process steps are not configured to run in this fake environment. So the iis config etc is skipped
As you can see in the following documentation http://docs.octopusdeploy.com/display/OD/Deploying+releases
--skip=step name as part of
Additional command line arguments for OctopusDeploy: Create release Step in Teamcity
Related
I am completely new to octopus. Basically i want to deploy a node application to an EC2 instance. I am using bitbucket for my sources and bamboo for CI. I wanted to know how exactly to proceed further. Or if i want to deploy my node application using octopus, should i package my node application in specific way? Or is there any tool which is actually feasible than octopus. As octopus is known for .net platform deployment. I am using mac. Do we have octopus server installer for mac?So that i can play around with it locally. Thanks in advance
Octopus needs a Windows machine to run the Server component. You can deploy to a target over SSH - so your EC2 machine doesn't need to be running Windows.
There's a guide to deploying a node.js app with Octopus that's probably the best place to start.
The deployment process should be fairly straightforward. Most likely a Package Step followed by a bash script to spin up or restart your node application.
To create a package to send to Octopus, create a zip or tarball containing all of the files you need for your node application to run. You can use octopackjs for this. It should be appropriately named with the version number as per that documentation page.
Adding a step at the end of your Bamboo build to tell Octopus to create a Release is relatively straightforward, as is deploying releases.
Recently, I started learning how to use Jenkins CI. So I am a little bit of a noob at jenkins. I am about to start to try and do the following:
I have setup a maven multi-module job on jenkins, which builds, tests, and finally creates 4 seperate war applications. I archive the war artifacts as part of this job. These war files will only ever be built once, they contain multiple environment properties, and the war file along with each environments server will manage the profile it runs in, eg dev, test, staging, prod, etc
I have another job on jenkins which will deal with the deployment to multiple environments.
This second job, uses the copy artifact plugin, and uses a post build action to deploy to a dev environment.
The job in step 2 will hopefully be able to have multiple promotions, allowing deployment to multiple environments: test/staging/performance/production etc.
I have searched stackoverflow and google, and all the posts I see, always use the parameterized plugin, specifying a parameter for the environment. This means there is a seperate build for each env which I don't like.
Can anyone tell me if this is the right way to go? Or direct me to some tutorial on how to do this properly.
Looks like what you need is a matrix-project build.
P.S.
A good introduction to Jenkins could be found in Jenkins: The Definitive Guide
After playing around with the jenkins configuration. I have this working very nicely now.
In the deployment job, I didn't see the "Add another promotion process" button, which allows me to promote the same build to multiple environments manually or automatically.
I'm using team City.
I have a build configuration that actually deploys my build artifacts on a remote machine (for the sake of this question I'll call it the "Deployment" build configuration). this works great.
I want to run the "Deployment" configuration in a loop that deploy the binaries on different machines (each iteration of the loop, deploys the binaries on a single machine). is there a way to achieve this with Team City?
thanks
I don't know about a configuration loop, but you could extract a template for your deployment configuration and then add configurations based on that template for each machine you want to deploy to. You'd just want a build parameter in the template to hold the path or connection details for each target machine.
I have set up a build step on TeamCity,as described here, to do automatic release deployments to our test server. But it is not using the latest nuget packages that was build in TeamCity.
Use Case :
Teamcity will create nuget package with version 1.0.0.9, all the dlls that is in the package is the correct version, and the Release in Octopus, that was deployed has got the same version number , but the packages that octopus uses is of an earlier package eg 1.0.0.5.
I have specified the --force parameter on the build step so it should use the latest packages but it is not.
If I manually create a release in Octopus, and select the latest packages it is working 100%
Please can someone tell me if I am missing something.
thanks in advance
I think what you need to do is create two build configurations in TeamCity, one to build and one to deploy with Octopus. Refer to this link that has a small blurb toward the end:
Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes.
So in my case I created 2 build configurations, then setup a snapshot dependency from the build to the deploy config and also a trigger to kick off the deploy after a successful build.
It looks like --force is just to force packages to the be re-installed if they have already been installed. Are you using the --packageversion parameter?
My organization uses Jenkins CI. We use the unique build number as our package version and then deploy that specific package version using the --packageversion paramater.
In the case where we have multiple services that need to be deployed. We have an upstream job / main job that provides the unique build number.
I'd imagine you can do the same thing with TeamCity
Master Job (unique build number) calls jobs A and jobs B with parameter (unique build). Jobs A and B build version (from Master Job). Jobs A and B complete then publish their respective versions.
It could be a few things.
Check out.
http://octopusdeploy.com/documentation/integration/teamcity
You haven't mentioned how your consuming the feeds from Octopus in Teamcity. I would start there.
Next I would use the teamcity action to do your deploy. You asked "Where should the --waitfordeployment flag be added" there is a check box to make sure the deploy has worked before the action can continue.
In TeamCity I use a Octo Push Packages step and in the Additional Parameters field I specify the --defaultpackgeversion {VERSION} parameter.
This will force Octo to use a specific version of packages instead of just choosing the 'Latest Version'.
There are more possible reasons for the problem.
To see the problems with Octopus go to Configuration -> Diagnostics
Another common problem is to use a Package Name #{variable} in a deploy step
Currently it is not possible and Package Name should be set manually, for example MyWebSite or MyWindowsService. See UserVoice for this feature.
We are considering TeamCity for continuous integration but have projects in both Rails (Rake tests) and PHP (PHPUnit tests).
I'm a bit new to CI - Has anyone setup TeamCity for PHP projects? If so, is it straight-forward?
Thanks,
Chad
To get the question answered:
Just use ant build scripts, and it'll work with TeamCity.
In the high demand market of web development, using CI is very beneficial and almost a requirement (now a days).
We use TeamCity, YouTrack, Perforce and PHP Maven to build, package and deploy our web applications. The setup is as follows:
Once developed, code is commited to the Perforce repository main folder for the app
TeamCity is configured to check this folder for changes and build each time changes are found (see configuring TeamCity)
Once development has reached a point where it's ready to be deployed, we integrate the main branch with the release branch
TeamCity is configured to check the release branch for changes and deploy via FTP to the server
Cron jobs are running on the app to deploy new releases to a QA branch
Once changes and functionality is verified, the status of the QA deployment is set to "deploy"
Another Cron job is running looking for new QA releases that are ready to be deployed. Once found, it extracts the package into the live folder
In this case, our PROD and QA folders are on the same server. Alternatively, you can have multiple TeamCity build configurations that push the app to different servers (or use a teamcity to define the environment variable).
Also, when we close tickets/issues in YouTrack, we can pull the build info from TeamCity as they interact with each other.
Links:
Configuring TeamCity, Maven for PHP for Joomla continuous build:
http://www.waltercedric.com/joomla-mainmenu-247/continuous-build/1552-configuring-teamcity-maven-for-php-for-joomla-continuous-build.html
We are using TeamCity to deploy a number of PHP sites -- static, Wordpress and Drupal shortly.
We use the Deployer plugin to sftp files to the appropriate server and then a script to rsync the files to the right place and to setup apache. Works very, very well.
Here is a fresh article from JetBrains on how to setup TeamCity with PHP:
http://blog.jetbrains.com/webide/2013/01/continuous-integration-for-php-using-teamcity/