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/
Related
I'm looking for advice on the best approach to setup TeamCity/Octopus.
Currently I have multiple branches in TFS2015 - dev, main and release (currently we create a release branch for each release).
Our procedure is to develop in dev and deploy to dev environment. When we are ready for testing we merge from dev to main and deploy to test from main. When happy we create a release branch and deploy to live from the release branch. This is a manual process.
Hotfixes are done on the release branch and deployed to live. We then merge back to main/dev.
I'm totally new to this and so far in a VM playground I've setup TFS2015, TeamCity and Octopus and can check-in to TFS, build/create package on TeamCity and deploy this pack from Octopus. But...
I'm unsure how I should setup TeamCity and Octopus to work with multiple branches? Multiple projects for each branch and generate different artifacts?
When I do this for real I have a TFS VM, I plan on installing TeamCity and Octopus on this along with the build agent. Is this a bad idea? Should I create a new VM just for TM and Octopus?
Any advice or best practice would be appreciated.
Although your question is good in scope, but a good answer must cover many details to be complete.
Let me try to point out the main areas that you will need to further investigate and configure.
TeamCity
A VCS root can be configured to listen to multiple branches via a branch specification
A VCS root can contain multiple projects/solutions and these can be built in multiple steps within TeamCity.
Given that Team City does not support conditional build steps, you will need a different strategy to allow you to vary build steps (and parameters) per release channels / environments.
My recommend approach is to split up the builds into a build definition per release channel (target environment).
Dev and Feature branches could share a single build definition.
Master and Hotfix branches can share a single build definition since they both publish to staging/production environments.
Release branches will need a separate build definition and publish to QA/Testing environment.
This gives you fine grained control over parameter and configurations of each release channel. build a debug version of your app from Dev branch for example at major version 3, while build a release version from Master branch with major version 2.
Every build definition will have a step to publish its artefacts/packages to Octopus Deploy, and specify the channel of which the artifacts belong to.
Octopus Deploy
In Octopus Deploy, define the channels to reflect the release channels, that also reflect your branching model.
Develop, Test, Release are my standard goto channels
Each channel can enforce a different Lifecycle to limit the environments that a channel can deploy to and how an application progresses through your overall ALM cycle.
I know this is not a complete answer. but it is a good start that I hope can help you refine your question to more specific technical details.
We're having somewhat similar CI setup requirements except TFS. In our case workflow for most projects is: GitHub -> TeamCity -> Octopus Deploy.
So I'm not sure about multi-branch setup with TFS, but in case with GitHub repos it's pretty easy to configure in TeamCity. You just have to specify branch-related settings in your VCS root (see Branch configuration). When you have configured that, TeamCity will let you run build's for every specified branch separately and will display build statuses for every branch nicely.
In Octopus we use Channels feature to split workflows of releases coming from different branches. That means we have channel-per-branch convention for the projects, so that TeamCity is pushing packaged releases from particular branch (in our case it's develop and master) into it's respective channel in Octopus (see Channels in Octopus).
Probably you can setup all the services on single machine but imho it's not the best practice to do performance-wise and scalability-wise.
Off course I don't know you code etc but I think you should step away from merging from dev to test and then creating a version from test. That way you essentially are building a different application compared to the one you were having on dev. Once you merge from test to production and build your application from there, you are releasing a build you haven't been testing.
You should strive for a flow in which you build once and deploy multiple times. So, build one package which you promote from dev to test to production.
Off course you can have a production branch on which you could fix bugs etc. The Channels feature in Octopus works great for scenario's like that.
So answering my own question (sorry), the approach I ended up taking was to simplify my branches and configure TeamCity/Octopus like so...
Branching Strategy
I've moved from
--dev
--main
--release
----release1
----release2
to
--master
--release
----release1
----release2
Master is where most of the devs do their work, when we are ready for a release we have a cut-off point and merge master into a new release branch.
The release branch is deployed to test and any fixes from testing are made on the release branch.
When testing is complete we deploy to live/production from this branch.
This means that the binaries we have tested are exactly the same as the ones we deploy to live/production.
Teamcity
In TeamCity master is automatically built each time a check-in occurs. Then the package is pushed to Octopus. Octopus acts as a repository in this case. TeamCity also creates the release on Octopus. So it should be checkin->build->create release->deploy.
To do this, I have one VCS Root and have a build configuration called Build-Master. This uses the checkout rules to ensure I'm only using the master branch. I use the Ocotpus packaging to build the package then use the OctopusDeploy runner in TeamCity to create a release automatically and deploy to the dev servers.
Release is different. I want to deploy to the test servers manually rather than each time a check-in occurs. When happy promote this to the live production servers.
Any fixes from test will be made to the release branch and deployed to test.
When testing is complete we promote to live and any hotfixes are made on the release branch. Obviously all fixes/hotfixes are merged down to master.
So, in TeamCity to achieve this I have a build configuration called Build-Release. Again, I use the checkout rules to ensure I'm dealing with the correct release branch.
The build creates a package using OctoPack, however this time it's not pushed to Octopus.
Octopus
Octopus has a project specifically for deploying master to our dev servers, for example projectnamehere-dev.
In Octopus, I have a separate project for Test/Prod. I've setup an external feed which points at TeamCity so I can pickup the package created in TeamCity. This is setup in Library->External Feeds.
So, to deploy to test. I create the release branch in TFS and give it a version number, 1,2,3 etc. I then change the Build-Release build config to point at this new branch. Change the version number.
Then in Octopus, I create a release, select this package and deploy to test. Any fixes from testing are made on this release branch. I just build the package again and create a new release and choose the new package.
When testing is complete, in Octopus I just promote the last release to the live production servers.
Channels in Octopus are used on the two projects because they have different life cycles. I also created two new life cycles, the default is dev/test/prod. I created just a dev and then test/prod.
Hope this helps.
In the version control settings -> vcs -> Branch Specifications: "*" ("This will do all branch, filter as needs be" e.g. +:refs/heads/master +:refs/heads/develop)
enter image description here
Octopus doesn't handle branches, it only deploys, you can however use their rest api, so for example, if test pass in develop then call the octopus rest api to create a new release and deploy.
I have Jenkins version 2.7.1 running on a Windows 7 machine. It is successfully pulling code from a subversion repository and running tests. I have the test jobs set up for the development branch of each project only.
We periodically make stable releases of the projects in jar files with version numbers. I would like to have Jenkins be the repository manager for those stable releases. These are made by hand - There is no Jenkins job making or testing stable releases. The projects do use Maven.
Each stable build is tagged in the subversion repository, so it could be made again on demand if needed.
I downloaded the Maven repository server hoping to make this fit the purpose. I read the documentation that's provided, but it's pretty terse. As I understand it and have it configured now, this appears to have a couple of issues:
If I go to jenkins-ip/plugin/repository/project, it has made directories there that expose the names of all of my projects, which seems undesirable. (Here jenkins-ip is the IP where I access Jenkins on my local network.)
On the other hand, there's nothing but empty directories under these projects, so they're currently useless.
These projects all correspond to the continuous testing of the development branch. There's no apparent way to get the stable builds into the hierarchy. (It doesn't seem efficient to create a job for each stable release...)
Is there anyway to get Jenkins (with this plugin or through another method) to be the repository manager just for the stable builds? I know that I can start a different repository manager like archiva, but it would be ideal to use Jenkins since it's already running and it seems to claim capability for this function now.
To use Maven repository server you have to build the project on Jenkins.
Then the plugin will expose all archived artifacts as maven repo.
Note you need to use a "Maven project" type for it to work (freestyle is not supported)
There are several plugins that will help you manage building from multiple tags, however not all of them work with "Maven project" type.
You could also try Jenkins pipeline (previously "Workflow") or the Job-DSL plugin.
A simplest solution would be to have a build parameter specify the tag name (then checkout e.g. ^/tags/projectname/${tagParam}), but you have to figure out how to trigger the job then.
I am trying to setup TeamCity to build/deploy the site to DEV/UAT. I am not able to get or dont know how to set up TeamCity to build and deploy to remote servers after commit to a certain branch. So basically we have three branches in GIT DEV/Staging/Master and I want TeamCity to trigger build and deploy after commit to each branch separately. So if user commit/merge to dev branch then TeamCity should build and deploy to dev server and if user commit/merge to staging branch then it should build/deploy to UAT.
Is this even possible? If yes then please let me know how?
Thanks
Bruce
I believe your build server is separate from your deploy server. You can try 2 approaches
Have teamcity agents running on the deployed servers. Create artefacts in the build process and download these artefacts using the agents in the deploy steps
In case you want all your agents to run on the same server as Teamcity, Have a SSH (or similar ) functionality copy over your build artefats onto the deploy box.
I have a problem with proper maven profile configuration of a project that is deployed to a continuous integration server.
In my project, there are some resources that needs to be included only during tests at the daily building phase and others that needs to be included during nightly builds, and they can never be included both at the same time, because building process will fail, I can achive this locally by activating one profile at the same time.
Continuous integration server runs following maven commands:
-during daily builds:
mvn clean package -Pci -Dci
-during nightly builds
mvn clean install -Dmaven.test.failure.ignore -Pci,nightly -Dci -Dnightly
As you see, nightly build command include maven variables and profiles defined in daily build command, which makes some troubles for me, becouse I want to have only one profile activated at the same time.
Specifically, what I want is having 3 separate profiles:
-my-pforile (activated by default, not used on CI server)
-ci-profile (activated only on daily builds, used on CI server)
-nightly-profile (activated only on nightly builds, used on CI server)
How can I achieve that? I tried almost everything. Reconfiguring CI server is not an option.
When I have to configure the same build with different profiles, using Jenkins as a CI,
I usually create as much builds as profiles, so each build uses the correct configuration.
If adding a new build is not an option probably you can try to create a workaround
using something like the exec plugin (http://mojo.codehaus.org/exec-maven-plugin/) to download
the resources from a ftp (or something else).
You will have also to create a cron job (or equivalent) to replace the correct resources between the builds:
in the evening you put there the resources for the night, in the morning the ones for the day.
But considering how cumbersome this process will be, probably it is better to try to add
a new build.
I am trying to understand the automated deployment process in TFS 2010.
I have a DEV, QA, Stage, and Live environments. Using a basic (or standard branching strategy), when configuring automatic builds/deployments does deploying to DEV get code from the MAIN branch to the DEV Server. Then if I want code to go to QA, do the bits on the DEV Server go to QA Server? Then get bits from QA Server to Stage? And finally from Stage to Live? So once code goes from TFS to DEV it's just a matter of moving source code from each Server to the next?
Or is it typical to grab code from DEV branch (instead of MAIN branch) to go to DEV Server and then move code to each Server as described above?
Just trying to understand the automated deployment process and what is a standard configuration.
Thanks for any info given...
TFS does not have a single built-in automated deployment process. You need to specify how and where your code will be deployed, depending on the type of project.
Deployment is about deploying the results of a successful build. Deployment is about branches only to the extent that you have built a branch.
The goal of deployment is to send a branch's code to an environment.
So, if you are working in the MAIN branch and choose to deploy to DEV, the code from that MAIN branch would get deployed (copied, installed, et al) to whatever is configured as the DEV environment.
Most people do not have one branch per environment. You probably would have a DEV branch separate from the MAIN branch, but that's a source control management concern separate from automated deployment. You might want to retag this question along those lines.