We use it to migrate our software from the different environments of development and QA, and then QA to production.
It performs pretty well. I like it.
We use it to migrate our software from the different environments of development and QA, and then QA to production.
It performs pretty well. I like it.
It's good because a lot of time you can keep the history tracking, so I can go back and I can see what the software looked like before and after, what was changed and what was moved.
It's the audit-level tracking. If something has gone wrong I can go back and figure out what happened, who did it.
Being able to go back through and see the history of changes that were migrated, who got migrated. And being able to see data migration has occurred.
Some of the things that we have talked about are trying to move towards Agile, and trying to map back. If I'm migrating once in a code that maybe solves multiple projects, or multiple user stories, or features. Being able to try and do that one-to-many; because right now we're just doing one-to-one.
If it were able to help us map back that code to basically what initially was running, that would help, because sometimes it can be multiples, I can install one release of a product that may have multiple originating.
It seems to be pretty stable.
It seems to be scalable. I don't know that we've tested any limits on it, but it appears to be.
It's been so long that I don't know what the previous solution was, but the switch was because we were trying to get it all consolidated, because we were in multiple places.
It was complex just from a matter of getting everything set up initially and making sure all our parameters were set properly. So it was about us getting everything there the first time. Because when you've got code everywhere, and you're trying to get it in one place, it can sometimes be a challenge just to find it all and get it there.
The most important criteria in selecting a vendor are
We like to hear from other customers that have used it. What were your experiences with it? The software, the vendor not being responsive.
I would rate it a solid eight out of 10, because it is stable, it serves the need that we have now. However, I don't know if it's serving where we are going with the Agile.
It seems to be a solid company, they're good and responsive. It's just a matter of making sure you know where all your software resides today, to get it all there.
For any organization to succeed in implementing this software is dependent upon the resilience of staff in the face of frequent organizational changes of the information system and in their work. It can manage the continuous-flow deliveries or cascade deliveries.
Globally this product manages back end process powered by z/OS. The interface could be improved in terms of the MMI/HMI. For example, with monitoring, the graphic view of the evolution of the IS.
Conceptually this system is based on a centralized vision. An improvement axis should exist to help you open your system and to decentralizing it. Converge a unified HMI for, and propose, more analyses and opportunities for the graphical analysis of the content of data included in repositories.
We've had issues with the stability of the genotype, the repository integrity.
It's OK, but it could be better with an incremental approach.
They are serious and display empathy.
It's complex because it depends upon your development architecture. Also, it's reached the limits of automation and freedom given to end users.
You need to think why you want to use an application configuration management system and if it matches with your development objectives.
Source control management.
It performs well.
It's very controlled. I can't say that it improves, the way our company functions.
It's not so much that it, by itself, isn't beneficial, but that maybe the way we use it is not necessarily great.
There are lots of restrictions and it's difficult to move things through the process and to get things elevated. And then we'd have to do some crazy process to get a CCID created and you've got to submit a request here, and then you've got to have this and that.
We've got this other process, if you generate a package and then you forgot an item, then you have to add to it. We have to get someone else to reset your package and you've got to submit a different request and get someone to reset the package. It's just painful, instead of having the users have the control over what they're doing, and over that process.
Learning the tool for the first time was extremely difficult, and it could be because of all the other processes we had around it. But knowing you can do these things in batch, you can do things in the foreground or online mode, and then these, you have to have a package for. There are these rules, and some of the concepts inside the tool are not clear, like what is the CCID? Why do I have to have one? What is that? And how is it used? As a developer, it's not important to me - I don't know what a CCID is, and I don't care - but apparently it's important to someone.
It seems extremely stable.
It seems scalable. I've never encountered any slowness. It seems that many, many users could use it without a problem.
The most important criteria when selecting a vendor are
CA Endevor is better than not having any source control management, some kind of source control tools.
Source code management. It works well.
I do not think our organization could go without it.
Source code management.
It is very stable. We had issues early on (twenty-something years ago), but not now.
We can make it do pretty much whatever we want, depending on just how complicated we want it to be. It will do a lot of things if we tell it to.
It is not built that way. It has to be told. It is pretty flexible.
Technical support is always good, and they are getting better.
I was not part of the initial setup. I have gone through several releases of the software, though. Those were pretty straightforward.
I would definitely tell anyone looking for this type of solution to pursue Endevor.
We use it to manage our source, make sure everything is clean, and nobody puts anything in the production that does not belong.
Flexibility.
It performs fine. We have not had any real glitches for the product.
It is already there. We have not really implemented it. We just have to get it to Managed API source.
It is stable. We do not have any issues with it. It is just complex because it is a tool set. It is not a plug and play kind of product at all.
No issues with it. It covers our base; no problem.
Good. They provide answers and solutions. The team member will really get more detailed on the technical end of it and he has not had any issues with getting support.
I was involved in the initial setup. It was complex. It is a toolbox, so you have got to design it to do what you want to get done, so it was complex.
I was not part of the decision-making process.
I don't know if there are competitors. I can't comment on how it compares.
This solution works. You can definitely make it work.
I set up the security configurations for Endevor as well as everything in the mainframe. I am the security architect, so I determine what has to be done in order to secure the product going into production.
Endevor allows us to map a change made to the production environment through various stages of delivery.
More of the following:
Therefore, we can report on our delivery quicker to management.
The product is very stable. It has been around for a long time. It all depends on how you to deploy it. If they deploy it correctly, then it provides a tremendous benefit. But if you lay it out wrong, it can be a nightmare to work with.
It is very scalable. You can go to just the libraries, but we use it more for than that. Not just libraries, but all of the elements that are associated to an application moving from one phase of delivery to another.
They are very good, but we use the user community as well instead of their support. This is because the help desk, or the help areas, within the product can't necessarily understand, in many cases, how we have deployed something. Whereas, a user group president of Endevor might have a lot of different sources in which to ask the same question.
I was involved in the initial setup. While it was simple and straightforward, we took simple and straightforward, then made a disaster out of it. Back then, we did not have the knowledge base. Now, we do have the knowledge base.
We implemented in-house. We just put it in ourselves. We probably would not have done that in hindsight. There is always a better solution if it is designed correctly. We just went strictly from the book.
We use CA Endevor Software Change Manager in order to control the lifecycle of the applications for mainframes.
The management and information CA Endevor Software Change Manager provides is very useful
There should be better integration between CA Endevor Software Change Manager and Zowe.
I have been using CA Endevor Software Change Manager for approximately 20 years.
CA Endevor Software Change Manager is stable.
The technical support from CA Endevor Software Change Manager is helpful.
I would recommend this solution to others.
I rate CA Endevor Software Change Manager a ten out of ten.
This software is made to keep the components' and change history. There is no concept of application and version management of these applications. It is in this area that it could be improved.
I have used this solution since 1997 in several companies with mainframes (banking, insurance, and pension funds).
There were malfunctions in earlier versions. The software has been stable in recent years.
Technical support is correct.
We did not previously use a different solution.
Implementation requires a good level of knowledge and expertise.
The license price is high, so big companies with a large information system can have this software.
I only know of three types of software that meet our needs. Endevor is the most widespread in France. LCM is not available in France.
It is a very good choice, but it requires a good level of knowledge to implement. Call on experienced people to implement it.