Keeping track of every app in development, testing, and production is a challenge that many businesses face. With so much manual work, as well as the risk of errors, it’s no wonder that companies are finding new ways to manage their version control.
Version control is a critical process and is often the difference between end users being able to get on with what they need to do and the support ticket system filling up with angry requests to get things working. For businesses that try to manually handle version control, a lot of problems crop up very quickly. So what’s the solution?
If you’ve got a single developer working in 3 week sprints, the chances of your business being overwhelmed by managing changes to apps is pretty low. However, as soon as you start introducing larger teams of developers – particularly if they’re working across multiple time zones – keeping on top of version control quickly becomes a real hassle. Add deadlines to lots of separate people working on the same projects and you have a recipe for disaster.
Part of what makes PlatformManager so effective for DevOps teams is that it clearly shows the history of every app, along with a full list of changes, and which version is currently in development, test, or production. For someone managing a team of developers, this greatly improves their ability to manage the work that individual developers are doing.
Compared with other change tracking software, we have built an extraction module that takes metadata from all the files you are able to track in PlatformManager. Metadata contains the script, expressions, fields, visuals – everything. The software then carries out comparisons between the metadata and it can show things like what files you are using, what data you are storing, where it is stored, and where else it is used – so you have access to a complete data lineage.
One of our customers in Healthcare has been using PlatformManager for more than a year. One example they cite of how good the platform is was when they found an issue they wanted to solve within one of their apps. They looked at the metadata using global search and found a specific SQL query that was causing an issue, they discovered the app was last reloaded months earlier, and it turned out the app was running on old data. The speed at which they located the issue meant they fixed it in 5 minutes rather than 5 hours.
For testing, changes are the most important thing to be aware of. A tester will never have the time to run tests on absolutely every part of an app. In fact, they’re usually so pressed for time that they only want to test the changes made. Knowing exactly what those changes are makes that much quicker, speeding up deployment and eventually ROI.
In our solution, we don’t override the app a business user is already looking at, but we put a new version in a temporary location, complete the reload which might take 30 to 60 minutes, and once that’s complete we replace what is currently being used. This means the end-user is never sat with an empty app, in fact, they can get on with their own work without even realizing they’re receiving updates. Even better is that if there are issues with updates, you can restore the previous version to production, so there is no downtime for the business user.
Dit artikel is oorspronkelijk gepubliceerd door PlatformManager.Terug