I am a user of hudson. I recently moved to jenkins. I know hudson does not support clustering of servers. Does jenkins provide that. Also elaborate things a little as I am new to this. Thanks in Advance.
If by clustering you mean having a single web interface and many workers behind, yes Jenkins (like Hudson from which Jenkins is forked) support it and it's called Distributed Builds. It allows you to run jobs on differents workers called slaves.
See the Distributed Builds page on the Jenkins Wiki.
OS Jenkins does not support clustering.
Cloudbees Jenkins Enterprise has HA support using active and stand-by Jenkins masters.
http://jenkins-enterprise.cloudbees.com/docs/user-guide-bundle/ha.html
Jenkins is fairly close to Hudson, feature-wise. Jenkins project forked off Hudson around 18 months ago and the basic architecture is still the same. So, even without knowing exactly what you mean by clustering, I am confident Jenkins does not support clustering if you say Hudson does not support it.
I have heard rumors there is work going on to make Jenkins have some high-availability features, but that is all I know. No idea what exactly that means or how is it implemented.
Related
It would appear that Sonarsource has discontinued development on the command line instance of the sonarlint tool. The link to the page on the sonarlint website now returns a 404 and there is no mention of the product on the sonarlint website.
Does this mean that there will no longer be a command line version of sonarlint?
The reason that I am asking this is that I would like to implement a build process that runs static analysis of the code for developers and also as part of the CI process on our Jenkins server. Whilst this can be achieved using various other plugins (checkstyle, etc.) the decision to start using Squid rules and deprecating older checkstyle, findbugs, etc. rules in Sonar makes alignment of the build process with the outcome reported by Sonar difficult; there are some rules in squid that are not readily matchable. For this reason I was looking for a way for developers to run a local Sonar analysis which is the same as that which is run by Jenkins during CI. (This is basic build and development best practice to align the local developer build with that executed by the CI server).
Either the sonar preview mode or the sonarlint command line tool would have allowed our build to do this, but it appears that Sonarsource does not understand the value of the practice and has decided to no longer support (by on going development) either method, which, in my opinion is a mistake. I hope that by raising this question they may consider again whether and how to support Sonar analysis for developers that does not require and IDE or editor plugin. My preference for this would to remove the deprecation of the preview mode analysis in the sonar runner so that we can confidently create processes that rely on it.
The SonarLint CLI version is not developed nor supported anymore.
It will be dropped completely soon, please find more info here (post by a SonarSource representative):
https://groups.google.com/d/msg/sonarqube/WlALjVzp-OE/Ev3QpnaOBAAJ
You might go with Sonar Scanner:
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
I want to install MySQL installer msi with my setup.(MySQL installer has to install silently. I am using batch file in custom action to do this.)
However, the problem is that MySQL's msi cannot be run from within main setup.msi it gives out 1618 error(Another installation needs to be completed.) I would like to know an easy way around this.
Background info: MySQL installer unpacks the manifest which contains MySQLInstallerConsole.exe it is then called through another cmd command to install MySQL.
So all I am looking to do is to execute MySQL installer so that it unpacks the manifest. Later I would call the MySQLInstallerConsole.exe to install MySQL through custom action.
Just to mention even more possibilities- some my colleagues mentioned (VS bootstrapper, burn):
Just start writing a batch or script for calling the two MSIs after each other.
Always a good starting point maybe, if you have no experience with MSI.
Write your own mini setup.exe bootstrapper with 5 lines of code to do the above.
(To be more concrete in "Third party tools":) Buy InstallShield or Advanced Installer or InstallAware, this are the tools with ready GUIs to do such easy bootstrapping.
I would recommend the second out of them. Starting another MSI are only two clicks. Similar with the other. But there are BIG differences between the three, especially InstallAware is special.
! Mentioned "mini bootstrappers" of those tools are not as powerful as Burn or the others followed:
Buy the ready setup suite SetupFactory which can be used as a bootstrapper for MSIs.
Use the InstallShield "Suite" project type, if you buy the Premium Edition of InstallShield. Costs big bucks, but has a friendly user interface. I was successful using it before some years, but I had to work around a handful of bugs as always with IS (but I guess you will discover bugs with most tools. Way it is.)
There (again) Burn would come in handy, you could fix potential bugs or behaviours on your own here ...
Only it could take you more time in the beginning.
... Of course there may be more.
There isn't an easy work around. Windows Installer enforces a 1 installation at a time rule through the use of a mutex. You need to create a bootstrapper / chainer to serialize the installation of your packages. Visual Studio Deployment Projects don't support this. I'd suggest looking at Windows Installer XML (WiX) and it's Burn boostrapper / chainer engine.
The documentation is a bit sparse, but in the Visual Studio world the customized bootstrap is the Bootstrap Manifest Generator. The docs start here:
https://msdn.microsoft.com/en-us/library/ms165429.aspx
and there is an old article here:
https://msdn.microsoft.com/en-us/magazine/cc163899.aspx
but it's not clear how much info and support is available since setup projects were removed from setup projects and then restored.
We have this issue.
We want to automate the deployment of our Continuous Delivery Build Server Tool chain using a Configuration Management tool such us Puppet, Chef or Ansible.
More precisely we have a bunch of tools (e.g. nuget, NUnit, MSBuild etc) that we use in our Continuous Delivery infrastructure. These tools are deployed to Several Build Servers. Maintaining the configuration of them is time consuming and error prone (i.e. different configuration in different Server resulting is error when building our solution using the Continuous Delivery tools).
We want to automate the maintenance of their configurations and we were thinking to use the Configuration Management tools such us Puppet, Chef or Ansible.
The question is: Are these the right tools for achieving the Configuration Management of our Build Server toolchain?
Anyone having experienced the same issue and how do you solve it?
Thanks in Advance
Alberto
Yes. All of these 3 can help you with that. Which one is better is highly opinion-based.
Yes, convergent configuration management tools such as the ones you listed are a widely used and powerful way to manage servers. The question is still very vague so that's about the best I can say.
A project with the following technologies and components has surfaced: to up a Web stack solution initially composed with Ubuntu, JDK, JBoss, Spring MVC 3.0+, and MySQL.
In planning this project, I have been struggling to find answers to the following questions for first steps, best practices, and sequence:
1) Does the JDK (and JBoss) need to be installed as ‘root’? (I have seen articles that mention it is not a good idea to operate in root unless absolutely necessary due to the fatal consequences.)
2) Does Ubuntu need to be installed as a Server in order to accomplish all this, or can it also be installed as a Desktop? I have not been able to determine if having a JBoss and MySQL need to be installed on top of Linux as a server.
3) Does Maven need to be used within Spring STS in order to get JBoss, and MySQL (and in the future Hibernate) to work successfully together?
4) My intent is to install in this order: a) Ubuntu -> b) Java -> c) JBoss -> d) Spring STS -> and e) MySQL. Are there any blatant conflicts in this sequence?
JBoss will require Java (recommend Java 7) before it will do anything. I don't think it really "installs" per-say, but rather just unpacks to some directory (even if you install from the package manager, it just really extracts itself). I question your need for Spring since JBoss and Java EE in general really does everything Spring does, and better now-a-days. Unless you have a specific requirement for Spring, I'd question this extra dependency.
For linux - in a high level, any OS can be a "server", all it needs is to be capable of serving things (web pages, ssh connections, etc). In M$ world, different "levels" of the OS have been specially designed based on anticipated task/workload. So for example, while Windows 7 can indeed run as a server, it was not designed for it and therefore may not be optimized or include helper utilities and tools to make life easier as a sys admin of the system. Windows Server on the other hand does include all the "normal" server tools and lots of goodies to make maintaining and setting the server up easier.
In linux land, this is no such thing. Linux is the kernel that talks back and forth with the bare metal, etc... and Distro makers will take that and build an OS around the kernel, basically just attaching any packages they feel their distro needs... such as wget, or cat, or any other standard userland apps, plus some non-standard such as mysql or java or whatever they want.
Now, some distributions of linux will tailor themselves at being "server" ready, while others will tailor themselves at being a desktop OS. The difference? It's really just whatever default packages the distribution maker decides to include or not. For example, the overwhelming majority of linux servers are run completely headless, and therefore there is absolutely no reason to have X11 and a huge bloated GUI environment installed and/or running on that system... it's pointless. Also, an "average joe" user does not need MySQL installed by default on his desktop system since it would only bloat his system and he likely won't ever use it.
So basically it comes down to default installed packages.
Some linux server distros take this further and exercise extreme caution when making updates, patches, or new releases in the name of stability and security, while on the other hand most desktop distros are more haphazard with their updates since if it breaks a home users web browser, it's probably not a huge deal... but if a server update breaks the webserver application stack, now that's a serious problem.
So you'll find server OS's like CentOS (based on upstream RHEL) are extremely slow to bring in the "latest and greatest" features that desktop OS's get early on. Their goal is high security and long term stability.
Now, for Ubuntu. While I certainty know a lot of folks run Ubuntu as their server OS choice (partly due to Amazon choosing Ubuntu as the default linux VM for their ECS cloud), but I'd really question this. Ubuntu is not focused on being a server. It's focused on being a great all-around desktop oriented OS. Yes the LTS version is meant for long term stability, but it's based out of a desktop OS, so it's still not the focus.
IMHO, I'd go with CentOS because it's free and completely binary compatible version of RHEL - and RHEL is the de-facto standard for enterprise-grade linux servers. Be aware though, the RHEL way of doing things is a bit different than the debian way -- so there is no apt-get, you must use yum install instead. Startup scripts are different and some ways of doing things are different, but really, once you know linux, you know linux.
EDIT: Also check into Jenkins - its a free opensource continuous integration system that runs on JBoss or Tomcat or any other container, and can automagically pull your code from a repo (github, git, svn, etc) and compile/package it then push it to live deployment. You setup your ANT or Maven build scripts, and it can kick off on a schedule or however you configure it.
EDIT EDIT: I'd also recommend using OpenJDK -- as it's likely included in your package manager (for just about every disto) and will be more updated than the oracle version if it's in your package manager too. I've found most "server" distros will have OpenJDK 7 while only having Oracle java 6 in their package managers. Also, installing it via the package manager will enable you to keep it updated a ton easier.
Installed as root, why not? Run as root, probably not a good idea.
If you want a desktop, install a desktop distrib. If you want a server, install a server distrib. This doesn't change what can and can't be run in the OS. It only changes what is installed by default.
Maven is a build tool. JBoss doesn't care how you build your app. All it cares about is if the application you deploy is a valid Java EE application.
No. You need an OS, so Ubuntu must come first. JBoss and (AFAIK) Spring STS need a JRE to run, as they're Java applications, so Java should be installed before them. MySQL is independent of JBoss, STS and Java, so you can install it whenever you want.
Note that if you're struggling just with this installation part, be prepared to suffer with the rest. Building a Java EE webapp is not a piece of cake, and you should probably find some experienced developer to help you, as it seems you're only beginning with Java.
I love Jenkins and appreciate that it is an active project. Still, I don't know what would be the correct approach for maintaining a Jenkins installation because I do see Jenkins+plugins updates daily and this takes too much time to update them.
Is there a way to automate this or a LTS version that I can use instead?
The Jenkins team do have a concept of LTS releases, so take a look at this Wiki: https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line
As for automating updates, you can do it if you've installed Jenkins using a package manager at the OS level. For instance, on ubuntu you could have a cron that calls apt-get update and apt-get install jenkins at midnight. I'm not sure about automating if you've installed it manually.
However, automatic updates have a bad side, as essential plugins could potentially stop working with new updates, or bugs that have slipped through the net could cause problems.
Having said that, the quality of Jenkins seems consistently good, so it might be worth the risk for you.
As far as I know there isn't a way to automate the update.
However, given the fact that an update could (in theory, Jenkins has been completely stable in my experience) break something in your build process, I don't think automating would be an appropriate solution.
What seems to work well for me is to periodically do the updates manually and then re-run all of the build jobs to verify that nothing has broken. I do this as part of our regular maintenance when we do VM backups and operating system updates on our CI environment. (The updates are done after the backups so that if something does go wrong, we have an up-to-date fall back point..)