Is there a way that I could do CI using TeamCity and Docker? What I have so far is a Dockerfile that would install TeamCity and configure build agent on a base ubuntu image.
What I want is to have TeamCity call a DockerFile on every commit to SVN or GIT. This DockerFile would actually fetch the latest sources from SVN or GIT and run my integration Tests.
Additionally, how could I manage integration tests against trunk and branch? For example, I have a branch 1.0 and trunk. When I release a branch, I want to run the branch against all the integration tests. Now the integration tests might contain additional tests that actually require a trunk version. How do I handle this? Is there a way using Docker to acheive this?
You didn't mention what build tool you're using, but there are plugins for Gradle and maven that let you build images, start containers, and so on. They'll at least give you the tools to build what you want.
Related
We are planning to implement continuous integration with Jenkins software, so we successfully installed Jenkins in our server (windows platform)
My question was
How can I manage (keep) my source code?
How can we configure if the source code located in some other machine / server / cloud
Our current process
Jenkins, source code is available in same machine, so we created a project in Jenkins and map the pom.xml (like D:\pom.xml) file under build section.
Choose a Version control tool, consider that SVN and GIT are quite different (Git--> Distributed system, SVN-> Centralized system) so read a bit about them before choose, then check for the availability of GIT/SVN plugin in Jenkins unless it already contained in your Jenkins installation.
Put the code under SVN/GIT, follow the standards, configure Jenkins in order to access to SVN/GIT server.
Check how to configure maven with Jenkins, it has a great integration with Maven.
Maven Jenkins:
https://www.tutorialspoint.com/jenkins/jenkins_maven_setup.htm
Jenkins Git:
Jenkins and Git sparse checkouts
The flow of the single build job is:
Checkout The code,
Specify the folder with the pom.xml file
Run the maven goal you need (e.g. mvn install)
You put your source code into Subversion or Git. Then you give your Jenkins access to the Subversion/Git and point it to the URL which you want to checkout.
Answer to first question : Host your code in a SVN or GIT repository. Git has higher market share than SVN because of large feature set and higher efficiency. SVN is simple and easy to use for new comers in the version control territory. Explore the options and host the corresponding server in your infrastructure.
Answer to second question : There are multiple plugins available in Jenkins to fetch code from remote repositories. For git , there is git client, gitlab and gitHub plugin . For SVN there is Polarion webClient for SVN plugin.
Is there a way to configure a single Jenkins job to perform the release of each newer version of my application?
i.e, I would like to know in detail if it's possible to do the following tasks without any human intervention. I'm using SVN as well as Artifactory.
Branch from the tag to be released
Change the snapshot versions in pom files to release versions (for each dependency defined in pom)
Take release build (EAR)
Deploy it in Weblogic instance.
Prepare release note
Tag the release
Thanks in advance.
It can be fully automated using Multijob plugin (Also with a regular single job, but using Multijob it will be easier and you can use Maven targets instead of some manual shell scripting ).
The workflow starts with:
commit and push to git
hook in git should trigger a job by http POST, so u need to configure your job to accept remote triggering. You can pass the branch name as parameter
job started, cloning the branch (git plugin)
start Maven project to mvn clean install and check unit tests (optional)
start Maven project to mvn release:prepare and mvn release:perform to omit the SNAPSHOT from pom.xml
tag the branch (using shell block and simple git commands)
merge to master branch (optionally)
start Maven project to mvn deploy to deploy to weblogic (weblogic should be configured in ~/.m2/settings.xml as the repository for deploying the artifacts
NOTE: all tasks can be also in 1 job with some shell scripting. the best practices is to use plugins but sometimes you will find it easier to use shell scripting for some tasks.
I have a project being built with maven using TFS for source control and Octopus for deployment.
At the moment, I can perform a TFS CI build, create an octopus deploy package as a zip file from the output, and use octopus to deploy to my deployment target, extract the package and install the app.
What I would like to do is increment the version of the application projects when a new build is performed (perhaps nightly).
Is the correct way to do this, to get my build server to set the new version on the project, using mvn versions:set -DnewVersion=x.y.z then to run mvn deploy to push the updated packages to the networked repository. Then to finally create my maven package from this?
I'm a bit unsure the best way to allow my build server to up issue the versions and then use those updated versions of the packages in the build.
It seems like I may have the wrong end of the stick here. Any pointers greatly appreciated.
If you had already at Maven 3.2 or better Maven 3.3+ you could have done that in a more convenient way, but if you are at Maven 3.1. you need to go
via build-helper-maven-plugin and versions-maven-plugin you can do simply via:
mvn build-helper:parse-version versions:set \
-DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}\${parsedVersion.nextIncrementalVersion} \
versions:commit
But as far as I know the versions:commit will probably not work based on support of TFS for Maven SCM....(I never tested it with TFS). But the commit step be done by something different.
Say my mvn Project has had a major version release.
So trunk is version 2, and I have a branch with Version 1. I want to allow developers to freely edit tests on trunk, But I would also like to maintain backwards compatibility from version 2 to 1. Is there an easy way to run version 1 branch integration tests against version 2 source code. I was thinking of compiling and moving the test jar (not sure if this would work), but that seems ugly.... Just to clarify, unit test classes are denoted with Test.java where as integration tests are denoted with IT.java. I only want to run the integration-tests
I would preferably be able to run something like
mvn integration-tests -Dfailsafe.plugin.src="branch/version1".
Alternatively, a Jenkins or Atlassian bamboo plugin would work.
Simply switch branch before executing mvn failsafe:integration-test. This is common pattern.
Maven Failsafe Plugin has no support for switching branches and no support for Version control systems (VCS) - and this is good, because this other plugin responsiblity.
This is easy to switch branch in tools like Jenkins. Create one job per branch, changes to code in branch should trigger jenkins build. Jenkis has support for private maven repositories, this will help with artifact collision. Also is possible to share workspace (results) from first job with second job.
In your case build job pipeline in jenkins, after first job from master execute job from branch to verify integration tests.
The best idea I've seen so far is to do a switch on the version control system and then just to run the integration tests.
Steps
svn co trunk
mvn clean install
svn switch branch
mvn failsafe:integration-test
If you run mvn integration-test in this stage you will rebuild the project and you will thus be testing your branch/the older version
I have coded this up and tested it against svn/mvn/jenkins stack
I'm trying to setup a complete CI server, but I struggle on some points.
Currently, my system work as follow :
I commit local changes on my local GIT repository, then push to the GIT repository on the CI server
I then have a jenkins job triggered by the SCM change, who run a clean install and by doing so executes all my Junit and Jstestdriver test (via a local jstd server). This job deploy the snapshot artifact to a repository on my nexus repository
I installed M2-release-plugin for jenkins, and setup my pom.xml accordingly using maven-release-plugin. When i click on "Perform maven release" in jenkins job page, jenkins run mvn release:prepare release:perform, thus creating a tag in my git repo (say v000001) and deploying a versionned artifact on my nexus repository.
I don't really know if this process is fine, but i guess so...
My problem is that I want to deliver the versionned artifact in my nexus repo (say "artifact-v0000001.war") in my production tomcat. But I can't figure out how to do it.
When I do "mvn release:prepare release:perform tomcat:deploy" it deploys the new SNAPSHOT artifact built ... I don't want to do this, I want to reuse the artifact from the nexus repository.
Is there a way to doing this using a tool (maven/jenkins plugin, or external)?
Basically, I want to fetch the last release artifact on the repository, and send it to the tomcat manager for dereploying the webapp.
Do I need to setup a delivery job separated from the release job?
Jenkins, especially when combined with a tool like ANT, can do just about anything. It has a lot of plug-ins, and you can always write a script and incorporate it into a Jenkins build. Currently, I use Jenkins to deploy web applications to Windows IIS servers. What you could do here is have a Jenkins build that has your SVN path set in the source control section so that it fetches the latest version when you trigger the build. From there it should be fairly trivial to write an ANT script that copies it over the existing JAR in Tomcat, which will automatically restart it.
Your problem is that you are probably using the Jenkins release plugin, not the "m2 release plugin". The problem with the standard plugin is that it performs the regular build, saves the artifacts, then performs the release. It will then try to deploy the wrong artifacts that it created from the regular build.
The m2 release plugin solves this particular problem. There are some tricky workaround for this problem, but that's how it stands at the moment until this feature is implemented: https://issues.jenkins-ci.org/browse/JENKINS-11120 (log in and vote for it!)