thanks for taking the time to read this.
I’m a graduate DevOps engineer at my organisation and I have been tasked with trying to automate a Jenkins upgrade for all our instances (RHEL 7 servers) across the estate. I have written a role in ansible which automates the update using .rpm files and have tested that the role does correctly update the application.
I otherwise have very little to no experience at all using Jenkins and don’t know a whole lot about the application itself.
In my research I have seen conflicting information about which is the best method to upgrade Jenkins, but an incremental upgrade path seems to be the best approach, or most widely advised. Some of the oldest instances of Jenkins on our estate are sitting at version 2.121.x so are quite out of date.
I have read the upgrade path guide and I’m considering upgrading to the first release of each major version of Jenkins but I really don't understand all the specific pieces of information given about the changes made to the Jenkins application and what things I should DEFINITELY be doing before installing the next major version. Should I also be updating the plugins manually from the GUI after every single upgrade step or should I update the plugins after updating to the latest version of Jenkins first?
Any advice on this is really appreciated as I really don’t know what I’m doing. Thanks a lot.
Related
I'm about to migrate Jenkins from version 2.190.3 to 2.204.6. As I know, I need to update installed plugins manually after updating Jenkins. I've got two questions here.
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
How can I find the expected side effects when I proceed with the update? Are there any tips?
Does the Jenkins update affect current plug-in? or does it work the same as before updating the plug-in?
Ans: Jenkins only update jenkin-core, it doesn't update current plugin. However, some plugin may be broken after update Jenkins-core due to incompatibility to new Jenkins-core
How can I find the expected side effects when I proceed with the update? Are there any tips?
Ans: we can not to be sure any expected side effect. So, when you proceed with the update, just go to "Manage Jenkins", it will shows you broken plugins that need to be upgraded to new version.
The recommended approach is to update all your plugins to "latest (compatible)" as possible, then upgrade Jenkins, the upgrade your plugins again.
Read the Upgrade Guide ans Change log. 2.204.6 is still very old. Recommend to 2.263.4 first as 2.277.x will break many plugins as a result of tables to divs migration.
Plugins are/must be upgraded separately from the app. Existing plugins may no longer be compatible, typically for security issues or a core plugins being decoupled. Some plugins may only work with newer core versions.
You should take a copy of your instance & config, update that and validate, then move to your real system.
My company is considering upgrading our on prem TFS 2017 update 3 to the latest Azure DevOps Server (notably, the on prem variety).
During discussions about that possibility, one key stakeholder claimed that if you upgrade, all of your build and release pipelines would have to be rebuilt from scratch. We have a healthy number of build and release definitions in TFS 2017.
I have looked for the answer in the Microsoft documentation about what exactly gets upgraded, but unfortunately I can't get the level of granularity which would prove or disprove the above claim. On the surface it would seem like a horrible upgrade story if it were true. But I also understand that designs and architectures change and upgrades aren't always possible.
Could somebody let me know whether the build and release pipelines can survive the upgrade more or less unscathed? Knowing this would be a valuable data point as we work toward a decision.
Thanks in advance!
The vNext build definitions and the release pipeline I would expect would be pretty lift and shift. Depending on the tasks that you have defined, they might no longer be supported or there might be new versions. The UI will let you know that new versions are available.
A lot of the new focus is building out the features for the YAML build definitions. If you want to leverage those, you'd have to do a lot more rework of converting those vNext tasks into YAML. But converting is not really a hard requirement.
You mentioned that you aren't using the XAML build definitions, but if you happened to be using them, I would image that is where a lot of the rework comes in. Having done that in the past, I can say it is a pain if you have to do it.
all of your build and release pipelines would have to be rebuilt from scratch.
I've tested it and it won't lose any data after upgrading. We should use scheduled backups to ensure that we always have backups in place in case something goes wrong.
we can use that new hardware to do a dry run first, and then we will wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account which does not have any permissions in our production environment. See Protecting production in the dry run in pre-production document for more information.
Optionally configure new features which require changes to our existing projects.
The production upgrade steps will be quite similar. There the steps will be:
Take the production server offline using TFSServiceControl's quiesce command. The goal here is to ensure that the backups we use to move to our new hardware are complete and we don't lose any user data.
Take new backups of each database.
Copy the backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use the scheduled backups wizard to restore the database backups.
Run through the upgrade wizard, using our desired production service account.
Optionally configure new features which require changes to our existing projects.
You can refer to this doc for more details.
I am working for a company now for a couple of weeks. The build process is done mostly manually and takes several hours spread over several days. The languages in use are C#, COBOL, Delphi, Visual Basic 6, and of course the database with T-SQL. For the version control, we use Apache Subversion (SVN), except for COBOL code and the documentation, which is kept in Microsoft Visual SourceSafe (VSS). I have the idea to improve the process using a continuous delivery tool. Do you think that Jenkins would do the job?
Thank you for your reply.
Jenkins is undoubtedly a tool that can help with CI/CD.
Whether it is the right tool for your particular needs you should be able to determine by doing your own research into the capabilities of Jenkins and the tooling that it supports. You may find that you struggle with finding adequate support for the older technologies that you mention and you will likely find that you need to uplift some of that legacy to make it usefully available to any viable, modern CI/CD tool.
e.g. get your code out of SourceSafe. You should do that anyway because .. SourceSafe. :)
Don't get bogged down in how to migrate your history. Just shutter SourceSafe (make it read-only) to retain as a reference to your history and move tip/head into a new repo. (SVN if you have to, though I'd highly recommend Git).
More generally, I would be surprised if you could not find some immediate quick-win improvements that can be made, without needing to invest time/effort/money into a "Silver Bullet" tool, just by putting some scripting in place to automate current manual processes.
Jenkins is definitely the right tool. We use Jenkins as a CI tool for building our Delphi (+Dunit+Innosetup), C# and Cordova/PhoneGap applications (all code in SVN).
I have no idea of the dependencies between the code in SVN of VSS, but if it depends on each other, I would advise to put all the code in a SVN or GIT repository.
There are some simple examples to integrate Delphi in Jenkins, see the following links:
https://community.embarcadero.com/blogs/entry/continuous-integration-with-svn-jenkins-and-dunit-delphi-with-craig-chapman
http://www.ictexpertise.com/blog/2016/02/10/continuous-integration-of-delphi-project-with-jenkins/
http://chapmanworld.com/2015/01/18/use-radstudio-with-jenkins-no-plugin/
I'm going to upgrade our jenkins-ci to the latest version. I'm following this wiki page (Going for the upgrade button in the "Manage jenkins page"): How to upgrade jenkins
My question is this, we have a lot of jobs that constantly run (some timed jobs, some triggered jobs). When upgrading, should (or even need) I disable all jobs before hand? If there are jobs currently running, should (or even need) i terminate them?
It depends a lot how you deployed you CI. If you installed by default (no custom settings i assume you can follow the auto procedure that you already provided in link).
When upgrading, should (or even need) I disable all jobs before hand?
When upgrading you should put your Jenkins instance in the quiet mode Configure > Manage > Quiet down, this will prevent further builds to be executed, also it will let all running builds to finish, i hope this answer to your both questions.
Speaking more about jobs, you should make a backup first in case something goes wrong.
Also you should think a lot about plugins and review them all since some of them might not work as you expect since you are upgrading to the new fresh Jenkins core. There is one plugin called plugin usage which might help you to understand your current status
My company currently uses lunt build as CI server. Hudson now forked to Jenkins, seems pretty powerful to me. I quickly installed it on tomcat, and the GUI seems to be quite powerful for setting up jobs, plus there is over 400 developer plugins and counting!
I was going to ask is it possible to do a POC with Jenkins.
Do any of you guys have experience with both or know the pros and cons i can use when i submit my proposal?
Thanks,
Shane.
Our small company's software team switched from Luntbuild to Jenkins (née Hudson) back in January, 2010, after using Luntbuild for three years. Every developer, including one manager, agrees that Jenkins is cleaner, simpler, and easier to use.
I found jobs (builds) much easier to set up and configure, in Jenkins, especially for projects built from different repository URLs. Documentation is neither project's strong-suit, but Luntbuild's seems more voluminous while being less useful. Jenkins' community is vibrant.
Beyond my personal experience, you may wish to consider the Wikipedia article titled Comparison of Continuous Integration Software.
Your best bet is to poke around on the actual Jenkins CI site. Here's a few links that might help your case.
https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins
There's a spot to "test drive" Jenkins on that page. It sounds like you already set up a Jenkins instance, you could possibly add a couple "dummy" builds to that as well.
Also, everything else you might have questions about could be found in the Jenkins wiki:
https://wiki.jenkins-ci.org/display/JENKINS/Home
Hope this helps.