-
Notifications
You must be signed in to change notification settings - Fork 1
Specifications
After having developed a software product, the developer needs to deploy it on a customer’s machine. Because products are usually highly customized, its installation and updating is dependent on a technician, who often needs to either visit the customer in person or use a remote desktop or some other support software, which might be an easier solution, yet the technician still needs to be familiar with customer’s environment. The situation gets even more complicated as the number of customers and/or products being developed rises.
The purpose of DEF is to ease up and partially automatize the process of installing products by introducing a centralized system of customers, products and installations. The system allows automatic installations of arbitrary products versions to various environments (which typically are for instance testing, development or production) using customized scripts.
Advantages are also evident even in the case where a software company/developer is maintaining only a single product. It is easier to manage more versions of a single product thanks to the ability to set up various environments and push the versions along development pipeline. Thus, DEF helps during the whole development process, no matter how many products or customers you might have.
Deployment Framework.
User Acceptance Testing. Product testing by a user, typically a customer.
A method of checking server availability. Typically done by the client sending a short message and expecting a predefined answer from the server.
A software solution ordered by a customer.
A subsystem, part of a specific product. A good example would be Word, Excel and Powerpoint applications as parts of the Office product.
Environments define various usages of a product. For instance Development -> UAT -> Production.
A specific deployment of an application on an environment.
An archive containing a specific application version and optional scripts to be run during the installation.
A physical machine on which applications are deployed.
There can be more products deployed on a single machine. Sites are disjoint locations for each one of them.
Usually means a status of a specific person. Positions can be assigned roles. Thus, when adding a new user, there is no need to assign them rights manually, assigning them a position is enough.
A group of rights.
A DEF user.
Deploy at development and testing environments.
Deploy at UAT and production environments.
Set up servers and configurations.
Manage users and rights in DEF.
Manage products and applications.
Have an overview of currently installed applications for a specific product.
Dashboard is designed to provide an overview of all products and their applications, environments and installations. Entities attached to products are displayed in the form of tables, where rows represent applications, columns represent environments and cells (tiles) represent installations. There is an option to choose an arbitrary application version and deploy it at an installation. Installation can also be postponed to a selected date and time and also set whether the installation should be periodically repeated. Users can also see on each installation if and when the last deploy was successful, what is the currently installed version, on which server it is located and an URL, if there is one.
The packages section allows to display all available packages and information associated with them. Specifically, name, description, available versions, date of release, dependencies on other packages and information about where the package is currently deployed at. Last, but not least, the section contains information about where and how to publish new packages.
The products section allows to manage products and associated entities. Management in this particular case means adding, editing and deleting of products as well as applications, environments and installations. Products show their name, description priority, possible notes and associated entities as described below.
Users have the ability to read and edit name, description and priority.
Users have the ability to read and edit name, description and priority and an associated package.
Users have the ability to read and edit associated application, environment and server as well as site, URL and possible notes.
The servers section allows to manage servers, i.e. Users have the ability to add, edit and delete servers. They also can do a health check of a selected server. Information of use include name, URL, API key, date and time of the last synchronization, currently installed scripts version, an indicator whether the version is up-to-date and entities described below.
Users have the ability to read logs, in which there are information about deployments done at the selected server. These information are specifically date and time of various actions, brief information about the deployment process and the result of the deployment.
Users have the ability to see the list of sites available on a server.
Users have the ability to read, add and delete server configurations in a key – value format. There is no option to edit configuration key after the configuration pair has been saved. The section if filterable by sites – attachment to a site is determined by a prefix ended by a dot. For instance, Test1.ConnectionString key is attached to the Test1 site.
The security section is divided to three linked parts. The purpose of each of these parts is described below.
The users subsection is meant to provide user management. It allows to add and edit users, not delete them, however. Displayed information are an indicator whether an user is active, their login, given name, surname, email, positions, date and time since and until when the user is active and possible notes. All items except the indicator are editable. The indicator is calculated from the dates.
The positions subsection is meant to provide position management. It allows to add and edit position, not delete them, however. Displayed information are an indicator whether a position is active, its name and associated users, roles and environments. Unlike in the users subsection, the indicator is manually editable.
The roles subsection is meant to provide role management. It allows to add and edit roles, not delete them, however. Displayed information are an indicator whether a role is active, its name and associated positions and rights. Unlike in the users subsection, the indicator is manually editable.
There is a set of rights defined in DEF, to which one can assign roles. Then, roles can be assigned to positions and positions can be assigned to users. Positions can also have environments assigned, which effectively limits which environments a user can see. Environment assignment can be overridden, though, by checking the “see all environments” right (which includes even those to be added in future).
To access DEF, one must be saved as a user and set as active, i.e. current date and time must be within limits set for the user.
If a user does not have any rights for a section, they will not see a link to it anywhere.
Rights are divided to three categories – create, edit, read. To add (create) new products, servers, users, roles and position, one needs to have create rights for the specific section. To edit these entities and create subentities (such as a new application in a product), one needs to have edit rights. Last, read rights are sufficient to see details.