A Release is a stream of development effort focused on a particular purpose like development release, integration release or production release. A development release is used to develop features, integration release is where one or more development releases can be merged and tested, production release is where the integrated code is tested and prepared for delivery. Release has Change Management and Project Planning aspects. A Release can contain many release tags that denote intermediate versions or the final version of the software. A baseline is a group of configuration items (products, deliverables) developed during a specific phase of the development process that has been formally accepted.
Validata ABC can contain all type of baselines and releases. The decision how many development streams to use and what would be the relations between them can be taken based on the Release Management Strategy.
There are occasions when an individual developer is required to work without being disrupted by the changes made by the rest of the development team. Validata ABC enables that, by creating such a component of the source that combines the changed files that the ‘isolated’ developer is working on combined with all the other files in the same version as before he started working on it. When the developer finishes the task the system prompts them to merge the particular versions of the source files with the versions in the release.
Isolation can also be achieved on team level. Very often, software development teams are sub-divided in groups that are assigned work on different tasks and they work in parallel. In this case, isolation is needed on team level so that the changes done by one team do not affect the work of rest of the team. Validata ABC enables that by creating as many development streams are needed – called Releases. The changes made by a team in one release are not available to the rest of the teams. In order to merge their work one or more integration releases are required that can interact with the development releases.
The Development Manager or Team Leader must create a Task and associate it with Source Objects and Data Objects. Each task is then assigned to a developer in the team.
Based on these associations, Validata provides an Impact Report that highlights the connection between modules, tasks, and their associated source objects and data objects. The reports is available for each Baseline and can interactively display the impact of the changes in the source objects and data objects, depending on the tasks that the manager decides to include in the baseline.
Validata ABC supports both single and multiple server deployment. During login in Validata ABC the user selects the server he wants to use. In this scenario the servers will be working independently - each server will have its own data. Additionally, multiple Validata ABC servers can connect to the same database.
The UI of Validata ABC has a preview where users can view all files that are locally retrieved. The checked-out files (that he has permission to change and check-in) are marked in this preview. The user can select a checked-out file and has a context menu command to check it in. Exploring the source code is an available and very friendly feature that Validata ABC provides.
Any changes done locally after check-out but before check-in can be undone by simply getting the version again from the server. Changes that have already been checked in can be rejected by the Development Lead during the Work Pack Closing process. In this case all Tasks in the Work Pack will be rejected and the source will not be included in the build.
Even if a whole project has failed and needs to be scrapped it can be done neatly by reverting to another Validata ABC Baseline. This way all the changes done during the project will be effectively rejected.
Currently a developer can check in the source units that they have developed when their task is completed. However, there is at least one stage that checks what goes in the source database - the Development Lead has to complete the Task before the changes become visible to other participants. Additionally, the workflow can define other states of the task before it can be closed to allow for other people to check and review it.
The user gets the right version of the project source files that are assigned to him on his desktop, works on them locally, and checks in his work. During this process the communication to the Validata ABC Server is not intensive. Temporary loss of connectivity to the Validata server is not an issue. The user has available only the sources that concern him. He can have a test environment on his own machine and test on it without communicating with the Validata ABC Server. Licenses for the Validata ABC Server and the desktop application can be managed independently.
Validata ABC implements role-based security that assigns access right to users based on the role they used to log in. The access rights that a given role has are configurable. Users are assigned to role(s) by a Validata administrator.
In addition to the role-based security there is a configurable workflow available for several types of Validata ABC system objects that allows the users to create/update/view/delete the objects based on the states in which they are. This way you can define automatically enforceable procedures for moving requirements, change requests, defects, etc. through different states.
Validata ABC is fully compatible with Toolbox. Validata ABC can build full project configurations and output them as Toolbox project files ready to be deployed through Toolbox. Data records, source and objects can also be directly deployed to a given environment so DL.DEFINE is not needed. Validata ABC provides full change management and versioning capabilities so BUILD.CONTROL is not needed.
Yes, Validata ABC can deploy source files and compile them on target environment or deploy objects ($ files) directly and catalogue them.
Validata provides an Alert and Notifications functionality that allows Validata’s administrator to configure different alerts for different users. Users can be notified when system changes have occurred such as: changed defect statuses, changed change request, completed tasks, etc. These notifications can be sent through the Validata interface and/or by email.
Validata ABC has a functionality that compares the content of any table between two T24 environments. Validata ABC will produce a report indicating the packages missing either in the first or second environment. It will also compare the content of the packages and report the differences of what is deployed on the first and the second environment. The report can be exported as an Excel file.
Validata ABC can have different OFS Telnet Sets (that's Validata setting) with T24 users, which have different primary company. In that case we need to set a variable in BCON, which will define if the package will go only to the company, where the current user is assigned or to all companies, where he has access.
Validata ABC provides a suitable interface (for example, when import versions and enquiries) for the user to browse through the environment and select source files. When the source files are selected they are downloaded from the environment and added to the Validata ABC storage.
Yes Validata ABC can help you specify where the libraries have to be deployed through particular settings.
Validata ABC provides two scenarios:
a) Deploying BCON package as is; in that case the capability of any restriction is not available.
b) During Build and Deploy; in that case we have the capability of restricting users to certain typicals.
If there is a need to execute commands during deployment the recommended approach is to use Validata ABC custom actions. These actions support executing shell commands, jshell commands, send OFS messages and execute commands through Classic interface. Validata ABC can be setup to execute custom actions before and after the deployment of each package.
We also have two more options for fine-grained control in updating records. In BUILD.CONTROL deployment we're supporting update of only certain fields of existing records and preserving the other, For example you mark that the value of two fields in one record will be updated with what is coming from the package, while all other field values will be preserved to what is in T24.Before assembling the package, Validata ABC will merge the existing T24 record with the one in Validata repository so these two fields will have updated values and the others will be untouched.
One of the reasons would be to call a mainline program from Classic mode.
Validata ABC can integrate with SVN, version control system and use its repository. Validata ABC is an open platform and it is able to talk and sync (one-way or both ways) with other systems.