eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
OutSystems recently released version 7.0 of its Agile Platform product, which includes a new feature set called LifeTime. LifeTime is an application lifecycle manager that integrates with Agile Platform, giving you a visual interface into all the applications and servers. It includes the ability to deploy code to different servers through a drag-and-drop interface, while checking for errors that might occur with a deployment.
The problem LifeTime tackles is this: Your application continues to grow, you split it into different modules, and it becomes more and more complex. Then you’re ready to move the different parts to, for example, the test environment or even to the production environment. But this can be difficult without realizing the full impact of moving only certain parts. As a developer, I’ve been faced with this very problem: I’m managing a complex system, and I make a change to only part of it. Do I then publish the entire system over again, or do I just publish the part that I changed?
For small apps, just publishing the whole thing is usually the easiest approach. But for extremely large, complex systems, that’s often not realistic. You have multiple developers working on the project, each making changes to different parts of the system. Different parts get pushed to test or production at different times. And since I don’t have all the changes yet that the other developers are working on, the reality is that we all have slightly different code bases on our different machines.
The idea of LifeTime is to simplify this process. Does it? eWEEK put it to the test. And we were greatly impressed not only with LifeTime, but with the entire Agile Platform 7.0.
The first thing we tried out was the Infrastructure feature. (Each of the main features has a tab at the top of the screen.) This is where you put together graphical representations of your different environments that LifeTime will be working with, such as a Development environment and a Production environment. Through the point-and-click interface, it was a snap to put these together, and once you do, you can monitor the health of these individual environments and get reports on the performance.
Next up was the main feature of LifeTime, the Applications feature. When we tried this feature, we were presented with a list of all the components in our application that we’d put together with Agile Platform’s Service Studio, which is their primary integrated development environment (IDE) and not a new feature. There were columns for each of the environments, in our case Development and Production. Each column listed the source control version that the corresponding feature was currently running at in that environment. It also noted who made the most recent change. In the Agile Platform world, these high-level features are considered “applications” and they’re made up of smaller “modules.” In this list, however, the applications are shown, and you can click on an application and see a similar list of that application’s individual modules, again with each environment.
At this point, we could immediately see where the differences were. I know in my own work that’s never easy, knowing the exact differences between our test environment, for example, and our actual production environment, at least not visually like this. But here, it was all right there for us to immediately see.
However, LifeTime goes beyond just looking at it. You can click on the module, then click on the version, and “tag” a version by adding a description and advance it to the next version. This was just as easy as the rest of the features; just click and type in a description and you’re good to go. You can even go backward if needed. A good example is reverting back to an earlier version if a mistake is made.
You can also compare differences between the versions of the same module in different environments using an older feature in Service Studio, and then copy the changes back and forth between environments. This is important, for example, if you spot one little part of your system that didn’t get pushed to production. Now, you just click and copy it up and you’re good.
Detecting Mismatches
But what really impressed me was the way LifeTime can detect mismatches. For example, you might be pushing a new module from development to production, but you forgot that you have an older API for another module on the production server. Pushing the new module with the older API might result in an error. LifeTime will detect such dependency errors, and notify you of the problem before allowing the push to go through. The version number will be noted in red; then you can use the part I just mentioned about copying changes back and forth from within Service Studio.
So how does this help you as a developer?
Suppose you’re ready to push version 3.0 of your product to production. You can easily see that the Test environment has 3.0 of the applications and modules that have been revised, with earlier versions for those applications and modules that haven’t changed for the 3.0 release.
You can see side-by-side exactly which applications and modules in the production environment haven’t been upgraded to 3.0. You can pick the features you’re ready to push forward and click Deploy. But before it will actually accept the deployment, it will detect any errors and incompatibilities between the versions of your modules so you can fix those problems before deploying.
When we tried this, we saw an error message that an API in another module had changed, and the only way we can successfully deploy is to also deploy that API. In other words, we know what we need to do to deploy to production without breaking it. If we just deployed the first module, our system would have broken. As a developer with 25 years of experience, I can’t say how many times I’ve seen this problem, and now with LifeTime, I won’t have to worry about it.
I highly recommend this product.