Arsenij asked: > What's the difference between saros-build and saros-build2 ?
Well, about seven years of patchy maintenance work. Seriously: Both are virtual machines hosted by our in-department IT, with similar "hardware" characteristics. Saros-build2, however, is set up programmatically. This is done through Saltstack [1], which our IT uses routinely for several tasks (if you heard of Puppet: it's somewhat similar). The idea behind this is to make maintenance much easier: Instead of "sudo apt-get upgrade"-ing on the machine, you just edit a configuration file and let SaltStack reconfigure the machine. In addition, all custom configurations (usually in the form of config files) are stored along-side the system config in a Git repository. The deal with saros-build2 is the following: - Our IT provides the machine with the packages and services we want. So far, it's an up-to-date Debian machine with running instances of Jenkins, Gerrit and SonarQube. - Every update on these services themselves is done by the IT. If we something new (such as NodeJS), we write a ticket, they create a new Git commit in the server config repo, and update the server. - Everything inside is up to us: The Jenkins plugins installed, all jobs configuration, the SonarQube setup, etc. This is considered user data and therefore backuped regularly by the IT. As of now, saros-build2 is only reachable from within Freie Universität (or VPN or ZEDAT http proxy). Anyone in the right network, here you go: - http://saros-build2.imp.fu-berlin.de/gerrit - http://saros-build2.imp.fu-berlin.de/jenkins - http://saros-build2.imp.fu-berlin.de/sonarqube I'm currently in the process of moving more of our "user data", i.e. Jenkins jobs and everything around them, to the new machine. As soon as this is complete, we will shut down saros-build and make saros-build2 available under the standard domain. The machines saros-eclipse1 and 2 will also be replaced in this manner. Actually, moving the STF jobs to the new server is basically the only critical thing left. This means: In principle we could switch to saros-build2 already, make it publicly visible and deactivate everything but the STF jobs on old saros-build. Any thoughts? Franz PS: Just in case you thought moving some Jenkins jobs would be not a big deal ... I spent 16 hours during my weekend getting the three amigos (Gerrit, Jenkins, SonarQube) working together. This was because I did not just copy the old Jenkins jobs, but split them up, joined them, streamlined them. It actually was fun -- partly because the server did response in under a second to all my HTTP requests ... [1] https://docs.saltstack.com/en/latest/ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
