We just installed QMetry on our Atlassian JIRA, and our bug management is done with Mantis for a long time.
My question would be if it is possible to connect somehow QMetry with Mantis so that eventual tickets in Mantis can be followed in the test cases in QMetry?
Or, if this is not possible, is there a possibility to bring the tickets from Mantis into JIRA?
Thank you
Related
My question is about API automation execution from CI/CD Platforms like Jenkins/Bamboo/Azure etc.
For API automation, it is important to have control on the machine from which the API’s are triggered as we may need to open Firewall for some API’s or add Certificates to java of that machine.
But if I run my API test from the CI/CD agent machines, I can not have that control as those agent machines are maintained by organizational level team who will not entertain any such modifications for the agent machines as they are used by all other teams.
How to overcome this issue? How is actually done?
If anyone out there, faced the same situation in their own company, I want to hear from them.
Thanks a lot for your support.
We want to start working with liferay. But the server is too heavy and the developpers computer don't have enought RAM. We want to centralize the server instance.
In other words, we want to build a development server where all developpers can connect and directly develop in their web browser, compile, view the result and push the code to git repository.
I found some good cloud IDE like eclipse CHE and a good maven archetype for liferay projet. So i can build the projet with maven. But now i want to know if it is possible to configure Liferay like every developpers can work without troubling another. And if possible, How ?
The developpers can share the same database and can use different port. Maybe, the server can generate tempory URL like some online cloud editor.
I found this post Liferay With Multiple Server Instances, but i don't think is the best way because he create one server per project. I think is too heavy.
If necessary, We have kubernetes in our IS.
Liferay's tomcat bundle, by default, is configured to take a maximum of 2.5G for the process, but it can run with far less - the default only recently was bumped up, because many people never change the default and then wonder why production systems run out of memory. For 1 concurrent user (the sole developer) on a machine, I guess that the previous default of 1G heap space is enough. Are you saying that that's too much for your developers' machines?
Having many developers on a shared server poses one problem: Yes, you may deploy different code from different machines, but: How about setting a breakpoint? Can you connect with multiple debuggers? If something fails, how do you know whos recent deployment caused the failure?
Sharing a server is an integration technique, not a development technique. If your developers don't have enough memory available for running their own Liferay server next to their IDE, it's a lot cheaper to upgrade their machines than to slow them down when everybody is accessing the same server and they can't properly debug. You pay the memory once, but your waiting developers by the hour.
Is it possible to share one server? Sure it is.
Is it possible to share one server without troubling each other? I doubt.
When you say: You think it's too heavy: What are you basing that assumption on? What does the actual developer machine look like and what keeps you from investing in the extra memory?
It's trivial to share some infrastructure - i.e. have all of them connect to the same database server (and give everyone their own schema). But just the extra effort and setup might require you to pay the developers by the hour as much as you'd otherwise pay for a couple of memory chips.
And yet another option is: Run Liferay on a remote server, but keep 1 instance per developer. This way you don't need the local memory, but can have the memory in the cloud. Calculate if you pay more for remote cloud machines than for local memory - that decision is up to you.
Apologies if similar has been asked before, I couldn't seem to find anything, just link me in the right direction if so.
I'm brand new to test automation, I will be writing selenium tests against a third party website hosted on an internal network. Our source control is provided by Visual Studio Team Services, although it is possible I can install TFS on premise.
Eventually I need to schedule test runs, I believe all this can be done with team services, seen some demo's, all good.
I will be using a URL to access the system under test which is on our internal network, if team services tries to run a selenium test and connect to the URL it will fail I imagine as it's running from wherever Microsoft are holding the code and building.
I don't think there would be a chance that we would allow Team services any access to our internal network if that was even possible.
So the question is, what are my options? can the build be moved from VS Team Services onto a local machine to run the tests with the internal URL? Is this a good idea if it can? Am i relying too much on the internet for testing on our internal network and is this a risk?
I have spent a bit of time on "the google" but struggling to find a great deal of information, it's possible I am asking the wrong questions.
Any help is greatly appreciated, links to articles are fine, don't mind doing the leg work, just need some pointers.
Many thanks for your help, apologies if any of that makes no sense.
You have a few options:
Install a VSTS Build agent on-premise and connect it to VSTS. The agent connects to VSTS using an outbound connection and it will be able to execute Builds and Release pipelines and from there orchestrate the execution of tests. You can either put this agent in a specific Agent Pool or Agent Queue, or you can add a Capability to it (e.g. "onprem"). By setting the Build Definition to use the specified Pool/Queue the agent will be selected. Or by adding the Demand "onprem" to your Build Definition it will ensure that it always requires that capability of any agent.
Use TFS 2015u3 or TFS2017 with the same agent, but that would mean you loose all the goodness that VSTS has to bring with regards to licenses, "free upgrades" and all.
With regards to security.
Adding a agent to your network that executes commands queued on a cloud service adds a risk. You can minimize that risk by configuring the build agent with a limited account, use Active Directory to limit the machines this user can run processes on/logon to and you can limit the access to this agent through permissions on the Queue and Pool as well. You can ensure that the users who have access to this pool and all your VSTS administrators have configured 2-factor-authentication on their AAD account and if needed add IP access control to these accounts as well. It's recommended that users that administer such agent pools/queues do not have alternate credentials configured and that the Personal Access Token used to register the agent is scoped to the permissions required to do just that.
With these extra measures in place you'll have a pretty secure setup. And it beats the hassle of having to install, backup, maintain a couple of TFS servers on-premise.
I am gathering information on what it takes to migrate from BMC Remedy and AccuRev to JIRA and AccuRev; and I would like to hear experiences from anyone who has done it and opinions from anyone who knows how to do it.
I found out that Borland has a bidirectional plugin for AccuRev and JIRA - http://www.borland.com/en-GB/Products/Change-Management/AccuSync/Integration .
How can I best migrate from BMC Remedy to JIRA?
Considering you are comparing a development environment to a project management system I am going to assume that you have a project management application developed in Remedy.
As such the process of migrating would be consistent regardless of what you are migrating.
You have to identify the fields in the new application that need to be filled in and then what fields in the current system are going to be used to populate them.
Once that document is made then you just have to export the information from your source and import it into your destination.
Personally, if you are able to do Remedy development, I would consume Jira webservices and build the migration steps in Remedy so that you don't have to perform the extra steps.
I hope this helps.
I'm searching for a main difference between OpenShift Origin and OpenShift Enterprise. I know that the first is open source and the latter is the commercial version. Have OpenShift Enterprise got other features compared to the open source version?
Thanks in advance.
Update 3/21/2018: If you find this old answer of mine in the future, Enterprise is called "OpenShift Container Platform" now.
The community version goes faster, but with change comes some risk. If you would like to be an early adopter Origin could be your choice. Note: support is best effort by the community, but I have found very helpful people on IRC and on the project's github page.
Link: https://github.com/openshift/origin
The enterprise version has the advantage of professional support for your money. While you won't get features as early, in exchange there is focus on stability and streamlining. This may be important for enterprises. Some solutions / examples may not work exactly the same way. For example application templates, utilities come as part of packages for RHEL users. It also comes with some entitlements for things like RHEL and CloudForms integration.
I tried installing a one master, one node small cluster with both, and found them just as good.
In short, stability or early adoption. Oh, and bugfixes.
Personally I prefer to go with Origin, as you can monitor the state of the project yourself and you are not forced to jump on every coming train. Update when suitable.
OpenShift Origin is the open source community version of OpenShift Enterprise. In order to understand what this means, you need to understand what open source software is - computer software developed via a competitive collaborative model from many individual sources. Origin updates as often as open source developers contribute via git, a version control system, sometimes as often as several times per week.
OpenShift Enterprise 3integrates with Red Hat Enterprise Linux and is tested via Red Hat's QA process in order to offer a stable, supportable product for customers who want to have their own private or onsite cloud. Enterprise might update around every six months, maintaining stabilization across minor updates. Providing timely professional support for each query they have from installation/POC to the production.