We use Maven, Jenkins and Nexus to build and deploy our software. The problem is that it's difficult for support and all of our people to know if a version is still in the QA staging repository, Beta or Release.
What tools are people using to make visibility of this possible? One option is to create a custom webapp that uses the nexus REST api to make it visible but I would imagine this is a solved problem and I shouldn't have to do that.
Any help or pointers in the right direction would be appreciated.
Related
I have an external Nexus Open Source version repository, that is connected to an internal one trough proxy repository.
I want to automatically sync the repo with the latest releases and latest snapshots without the need to request them trough a build.
I know there is a capability "Smart Proxy feature" but I can't enable it as we are not using the professional version.
Can you suggest other "smart" and "clean" ways to achieve this?
I was thinking I can create a Jenkins job running every 5 minutes that requests the dependencies thorugh a build using placeholders such as latest release and latest snaphost but i want to know if there is any easier and cleaner way to achieve this.
If my question is not clear please let me know.
Same question asked here but no useful replies.
I've just installed the latest SonarQube 5.0.1 locally to try it out. The project I'm working with at the moment is hosted in Bazaar (bzr) source control. I looked at the SonarQube list of SCM plugins here:
http://docs.sonarqube.org/display/SONAR/Plugin+Library
Bazaar is not listed. Are there any workarounds or independent projects that I could use to get the scm history information from Bazaar into SonarQube? At this point I am just trying to get a sense of the value of the information to our project, rather than worry about a scalable production-ready solution.
There is currently (2015-04-09) no SCM plugin for Bazaar. If you wish to contribute one, feel free to take inspiration from e.g the SonarQube SCM integration plugin for Git.
Last year I got virtual server for my server needs, configuration is not great, but things work without problem... Few months ago I installed Nexus Repository manager and after that I have daily problem with tomcat... I now restart machine every night, but still it seems that nexus is unavailable most of time.
I am working on OS project and we need to have repository manager (RM) available to host all our stuff and also all libraries our project needs...
I have currently 3 options (how to solve this problem):
Downgrading maven version to 1.6 (or at least some that is stable and doesn't need so much resources)
Using artifactory (their package seems to be the same size as nexus, but I don't know if it will be better - resource wise)
Using archiva (no idea how stable this is and how good it is)
I am thinking about going with option 3, I just don't know if this is right solution. I am sure some of you have your own RM running, what would you recommend? Do you have perhaps any other options? If I use option 1, which version would you recomend...
Thanks in advance,
Andy
By "downgrading Maven version to 1.6" I assume you're referring to the Java version, as if you're using such an old Nexus, then it doesn't shock me that you're having problems. Upgrade your Java to 1.7.x, as well as your Nexus to the latest one.
Archiva and Artifactory are always options, but I don't think the problem is in Nexus itself, but rather your setup (and you haven't mentioned anything about it).
What version of Java, Nexus, Tomcat are you using?
Also, by "OS project", I assume you mean "OSS" (open source) project. If so, you can use Sonatype's OSS hosting. I've described how to set up an OSS project (using Github, BuildHive and Maven Central) here. You can also just skip to using Maven Central directly, checking here. I think this would be a better option for you, if you're not familiar enough with managing your own repository manager.
I would suggest to run Nexus with the native jetty as supplied by the default download bundle instead of on tomcat. This will give you better performance and also better support.
Of course if you can get all libraries into the Central Repository via OSSRH it would be even easier since you could get by without maintaining a repository manager altogether.
I am referred to Hudson today.
I have heard about continuous integration before, but I have no idea what the heck is a ci-server.
Hudson is really easy to install in Ubuntu and in several minutes I managed to set up an instance of it.
But I don't quite understand the workflow of a ci-server, or how am I supposed to use it?
Please tell me if you have experience about ci, thanks in advance.
Edit:
I am currently using Mercurial as my SCM, and I wonder what is the right way to use it with Hudson.
I have installed the Mercurial Plugin of Hudson, and I create a new job with a local repository. When I commit in the repository the Hudson job is built with the latest version of my source code.
If what I used is a remote repository, what's the workflow like?
Is it something like the following?
Set up a Hudson job with the repository
Developer makes a local clone of the repository
Developer commit and push changes
The remote repository update with the incoming changeset
Run a Hudson build
There may be something I misunderstanded at all, please help me point it out.
Continuous Integration is the process of "integrating software" continuously i.e. as frequently as possible (ultimately after each set of changes) to avoid any big-bang integration and all subsequent problems by getting immediate feedback.
To implement Continuous Integration, you first need to automate the build of your software (where build means of course compiling sources, packaging them, but also compiling tests, running the tests, running quality checks, etc, anything that will help to get feedback on the health of your code). Then you need to trigger the build on the latest version of the sources on a particular event (a change in the repository, a temporal event), to generate reports and to send notifications upon failure (by mail, twitter, etc).
And this is precisely the responsibility of a CI engine: offering trigger mechanisms, being able to get the latest version of the sources, running the build, generating and publishing reports, sending notifications. CI engines do implement this.
And because running a build is CPU and Disk intensive, CI engines usually run on a dedicated machine (or even a farm of machines if you want to build lots of projects).
Back to your question now. Once you've got Hudson running, configure it (Manage Hudson > Configure System): setup the JDK, build tools, etc. Then setup an Hudson Job and follow the steps: configure the location of the source repository, the build tool, the trigger, a notification channel and you're done (you can do more complex things but that's a start).
For more details on the setup, check:
The official Use Hudson guide for more details. << START HERE
Continuous Integration with Hudson - Tutorial.
Spot defects early with Continuous Integration.
Martin Fowler's overview of continuous integration is one of the canonical references. In my opinion, using automation to make sure your code base is healthy is one of the most useful things that you can set up.
Update Sorry that I didn't have much time earlier to expand on my reply. #Pascal_Thivent is right that in order to effectively use CI, you need to be able to automate your builds, tests, etc. CI is actually a good forcing function for this. For me, it's one of those little warning flags if I start to think that it would be too painful to put a build into Hudson. It means that something is not quite right.
What I like about Hudson is that it's flexible enough to accommodate different workflows. We use it for both builds / unit tests and releases. And it eliminates a lot of the worry about certain release procedures only working in one person's environment.
What I don't like about Hudson is that it is occasionally unstable when new builds break plugins. I've had a couple of upgrades (2 out of 10 or so) go bad because of incompatibilities. I do two things now:
I never upgrade my team's Hudson server to the latest and greatest right away. I generally only upgrade when there are significant new features, or bug fixes.
I now have a basic Hudson instance set up with all my plugins on a virtual machine with some dummy builds that I fire up to test out any new upgrades before doing it on the public server.
We're currently using CruiseControl.NET as a continuous integration server for a number of ASP.NET web projects, but we're also evaluating TeamCity.
This is working great for our build server.
What we'd like to setup is a customer facing test server. I'm thinking that when we are happy for our latest development version to be released to the client for test, we could label it in SVN.
I'd then like a second build server to build this version ready for the client to see.
The question is this - is there any way to get either CruiseControl.NET or TeamCity to build only the latest labelled version of the code in a repository?
If anyone has any alternative suggestions, that'd also be greatly appreciated!
You could have a designated location or branch in your subversion repository e.g. \release then point the second TeamCity build server at that.
When your are happy with trunk then overwrite the existing location. The second build server will pick this up, build it, and even deploy it to a test server.
I don't think there's a way to do this directly in TeamCity. You can however configure your build trigger to filter on files and/or users. So, if you touch a given file to indicate release status in addition to or rather than labelling, you can use that.
The trigger filter could be, for example (untested):
+:/ReleaseVersion.cs