In most of the organisations, we get only workstataion installed in our remote machine and registry is running on some server where we don't have access. In below scnearios, we struggle alot to make our test cases or Virtual service working.
1. Connecting to DB: Jars to connect different DB may not be present in registry server already. We deploy jars in our local machine, making it work for the connection but when we stage it, we get to know this jar is not present on registry server. Now we need to ask them to DevTest admin team to provide that jar in the server which is really a time taking job. It will go for multiple approvals before providing that jar in the server.
2. Custom Jars: In case of custom filter/assertion or jar for dynamic java execution step, the struggle is huge. That custom jar must be having some dependent libraries. Convincing the admin to deploy that jar is very difficult. If that custom jar wil fail then debugging is trouble and correcting it will take huge amount of time.
3. Changes in properties file: For e.g, we need to modify local.properties file to make it enable for SSL services, Raising a request and showing that it won't impact other Devtest Users is huge.
DevTest is amaming tool with lots of option to customize but as an end user I struggle alot to deploy customized solutions it as per my need. There is a huge delay in providing deliverables.
P.S. May be this is me struggling for it. If somebody has already find out the solution, Please help.
I agree with you on all the points you have raised. Unfortunately, I do not have a solution to your pain points.
These are some of the the reasons, I prefer working at a client site, where they give me access to the registry server.
Thanks Kishore. I am also on client side but they have team doing all the DevTest admin activities. So if we need some changes they take thier own time by creating a story and then validating if it will impact other users or not and if everything goes well after 2 week or so it will be available for us to use.
Points noted Monica -especially #3.
Hi Monika, it seems that many of your challenges are a result of separation of concerns and organizational alignment.
Since the licensing model for DevTest has changed, is there any possibility of setting up your own Registry, VSE, Coordinator, etc. so that you can exhibit greater control over the environment?
Or, are there any continuous integration (i.e., automated deployment) processes that you can plug into to help with these types of changes? Many customers are moving to a continuous delivery models where application changes are deployed multiple times per day.
Hi J_NeSmith, I will check with the admin team if they can provide performance pack.
We are moving towards CI too using jenkins integration but again we have same concerns about providing the dependent libraries or any properties file changes to the devtest in same box where jenkins is installed.
I agree with Joel. Getting your own lower environment to test all the required changes is ideal. Then if needed, it can be promoted to controlled environment for consumption of everyone.
One solution can be if you have a lower environment where you have complete access, you can make the required changes, run a regression test suite to make sure none of the use cases of other users are getting impacted and then promote the changes to be deployed to the controlled environment. This will ensure that the concern of impacts to other users wont be there and the deployment process can be automated as much as possible making the work flow faster.
Property file changes etc, will require alignment from all other teams in a shared environment and they have to be notified. Hence, it is desirable to test the changes in some lower environment and move them to controlled environment once it has been tested.
I have faced same issues in previous projects. This is a pain point but if our admin team are able to help then can be resolved quickly. In my current project, we are doing continuous Delivery and admin team is providing full support for it. All our execution is from Jenkins and no problem at all. Also it will be good if you have someone from DevOps to help you in initial phase.