We are planning to migrate Teamcity to Jenkins due to cost reasons. However we found that conceptually both tools are same but the technical functionality is different. Hence if somebody has experience or has done this migration before, please share the steps (high level) which can help us to plan the migration effectively.
Additionally, Is there a automated or faster way to do the migration?
Thanks
Related
This is not a programming question, but I don't know any more active forum and besides programmers are the best people to be able to answer my question.
I am trying to understand the rationale behind continuous integration. On one hand, I understand that it is a good practice to daily commit your code before heading to home whether or not the coding and testing is complete or not and then there is continuous integration concept where the minute something is committed, it triggers a build and all the test cases are run. Aren't the two things contradictory?. If we commit daily whatever coding is done, it will cause daily failed builds..Why don't we manually trigger builds once the coding and testing is complete?.
Usually when you save your code daily is to be sure that your work will not be lost.
On the counterpart the CI or Continuous Integration is to test if what you produced is ok, in the majority of projects the CI isn't applied to individual branches ie: feature, bugfix, it's applied on major branches ie: master, develop, releases, etc. And these branches aren't updated daily as they need a pull request to be update and someone to approval that pull request.
The use case for having CI implemented on individual branches (feature, bugfix) is to check before merging a pull request into a major branch when it will check the tests and if the code builds.
So resuming, yes you need to commit your code daily, but you don't need to apply CI to it daily.
I suggest to you check the Gitflow workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
The answer is obvious.
1. Committing Code: In general the code is committed only after testing with the environment locally.
Consider Developer_A working on Component_A hence one has to commit with minimum verification as the scope is to develop Component_A.
No imagine complex system with 50 developer developing Component_B...Component_Z++
If someone is committing the code without minimum test it is most probably going to give you failed result.
Or else developer might have it committed on development branch that all together depends on SCM strategy adapted in project.
2. Continues Integration test scope:
On the other hand integrator principally collects and synergies different codes (Software Components) together into 1 container and perform different tests.
Most importantly, integrator need to ensure that all the Components Developed from different developers is fitting good and at the end Software is working as expected. To ensure that, Integrator have acceptance criteria and to proactively prevent something which can go wrong, it is important to have these criteria automated with the help of Continues integration.
But among all factors, it is important to give feedback on the quality of software to the developers. It is best in favor of project (economically), to know about the bug earlier hence Continues Integration and DevOps.
In Complex System it is worth to have automated watcher to catch the sneaked mistakes from developers.
3 Tools and Automation:
To create human independent system, automation tools like Jenkins are helpful.
Based on the testing strategy different testing levels can be performed with the help of Automation tools.
Is Continuous Integration feasible for iOS.
Again my Jenkins build fails with “Your session has expired. Please log in.” and I begin to ask myself if Continuous Integration is at all feasible for iOS development.
How can you set up a reliable unattended build system that demands a user logged into some web service which might expire your login at any moment? As far as I see it the answer is: You can't.
It's just not possible. It will always be an unreliable system which will stop building for no apparent reason.
Or am I missing something?
As an answer to the discussion in the comments, it is feasible. There is no simple way to explain everything that you need but in a short summary.
If you using Jenkins,
You need access to MacOS, Jenkins running on MacOs or Jenkins Slave which is with MacOS.
Xcode on the machine from point 1. with xcode(xcode comand tool) xcbuild.
Fastlane integrations (check here)
The last thing is fine-tuning with your process, haw and when to increase builds and etc.
At some providers like Azure DevOps, it was easy to add all these BIG steps with build in components of the system.
In general, I never found a good tutorial about this how to be done end to end. But with a lot of reading and trying it was done from me, without to have big experience in the dev-ops world.
P.S. It will be nice if you do a good tutorial for how this can be done when you made it(I didn't have time to do it :( ).
We are looking to incorporate continuous integration/nightly builds into the development process of two of our products. One is to be written in Java using JavaFX for interface, the other is to be written in ASP .Net MVC using C# as our coding language.
The question is pretty straightforward: considering the fact that we have those two products and we want to use the same CI server for both of them, which one would be the best pick? Are there any known issues regarding either language that we should be aware of? Considering we're a very small team, is either one considerably easier to maintain and configure than the other? Any insight will be helpful!
Please read this : How to choose between Hudson and Jenkins?
Generally use Jenkins, it is Hudson fork with better support and have much more plugins.
Hudson died the day the entire developer community followed Kohsuke over to Jenkins.
Jenkins power is in its plugins of which Jenkins has over 1000. Hudson has virtually no more than the day the community stopped developing Hudson and started moving Jenkins forward.
Jenkins has a rich developer community, Hudson (owned / killed by Oracle) has one guy: no contest!
We are on TFS 2012 currently and planning to upgrade to TFS 2013 soon. I'm trying to better understand what is the best setup for TFS. We currently have multiple teams in the company using it and it is critical as a source control and ALM tool. Nope Visual Studio Online is not an option for us.
Let me know what you guys think specially if someone else has a similar setup.
1) Whether we should have a DR environment for TFS so that if something goes wrong with the Main TFS we can failover? I know we can restore it from the DB backups but that is time consuming specially if the TFS application tier goes down and has to be rebuilt.
2) Should we have a QA/Dev environment so that it can be used to try the upgrade first and if it looks good then done in Prod? It can be used in future to try out features etc. as well.
In a recent environment I was working in, we had a "QA" TFS server that we could test updates\template changes\plugins, etc. That worked out great for the whole team and I would definitely recommend having a test server if that's an option for you.
I can't recommend what you do for disaster recovery as there are many factors involved that your team needs to decide on. My last team didn't maintain a completely separate rollover environment, but there were nightly snapshots of our TFS servers that were virtualized. We could restore from those snapshots fairly easily. That recovery plan was sufficient for this team based on risk\resources\potential downtime.
I hope that helps.
The ALM Rangers publish a TFS Planning Guide which has a section on how to approach DR with TFS: http://vsarplanningguide.codeplex.com/
You probably should also consider designing a High Availability (HA) TFS deployment. Details of how to do this are in the TFS Installation Guide: http://www.microsoft.com/en-us/download/details.aspx?id=29035
In general though, at the core of TFS is a SQL Server, and all the best practices around HA SQL and DR for SQL apply here. Reconstructing an AT is relatively straightforward, and if you design a HA TFS deployment you will have multiple load-balanced AT's so if one fails the traffic just routes to the healthy AT(s).
My company are imposing Jira and Zephyr on us for defect tracking and test management. We're quite happily using TFS 2008 for both these jobs at the moment, but management have never let the fact that something isn't broken stop them from trying to fix it.
Are there any tools/plug-ins that will allow us to synchronise between the remotely hosted repositories and our in-house TFS server?
Probably too late, but the company might want to look at the new features for bug tracking and manual tests coming in the 2010 release. Nice as Jira is, I doubt it will integrate well with the historical debugger and the ability to include a video of the test, as well as information on the test environment, and have it all be part of the work item.