Virtualization - VMware, VirtualBox
This was a natural step right from the beginning of our server solutions venture. The easiest way to deploy Easy Project is in our provided virtual machines preconfigured for optimal performance. VMware and VirtualBox compatible machines are provided without extra charge. For a minor fee, we can also provide a Hyper-V machine.
We also released a couple of free versions of VM for the Easy Project community.
Easy Project installer
Our most used tool to date. When you opt to install Easy Project directly to the server, this tool makes it a lot easier. You only run a single command and then follow a wizard. No longer do you need to manually run installations, migrations, rake tasks, gem updates, etc. Easy Project installer does it automatically, minimizing the chance of an error.
Easy Project installer is also an integral part of our VMs, where you can use it for regular updates.
Dockerization – Docker
Docker offers a flexible and efficient option for deploying Easy Redmine. By leveraging Docker's containerization technology, we can package our applications and their dependencies into standardized containers.
These containers can then be deployed on various environments, ensuring consistency across development, testing, and production stages.
Docker's portability, scalability, and isolation capabilities make it a reliable choice for streamlining the software deployment process.
Easy server requirements check
Easy Project is dependent on various systems, which is quite normal in this era of integrated technology. To keep the dependencies in order, we have devised a very simple tool that checks the important components on the server. The admin just runs a simple command to find the status of each requirement. This information is important for admin before installation or update, but also for our support staff, who will give you a more informed response to possible issues.
Manual and guidelines
The server environment is a diverse jungle of ridiculous proportions. To keep all parts in perfect sync requires tons of experience and continually refreshing your knowledge about new technologies. For the most crucial configurations and components related to our applications, we have published instruction manuals and guidelines that assist admins in regular server maintenance.
These include – installation manuals, ruby updating, server configurations, useful commands or common server errors, and more.
Limitations of server solution
While we always try our very best to provide customers with as much useful information and tools for the smooth running of their self-hosted application, we cannot directly control their environment. That means we have no ability to perform fixes directly on the server, or we cannot look for the cause of various errors occurring on the server which leaves us only guessing when providing support.
Remote server support performed by our administrators is available as a paid service. Furthermore, the resolution time is always longer when compared to a cloud solution – simply due to arrangements needed before access to the client-server can be provided. This leads to the next point:
Access restrictions and issues
In most instances when a customer asks for server support, they cannot provide direct access to the server, but rather a remote-controlling session via apps such as TeamViewer. It is better than having no access, but our experience shows a significant decrease in flexibility and resolution time when using remote-controlling tools in comparison to direct (SSH) access – connection issues with the hosting computer, lagging, and loss of control when the customer uses the computer. It all adds up to a 50% slower resolution time than with SSH access.
Demand for server admins is larger than supply which is a cold hard fact. Server support is no exception. For this simple reason, server support must be scheduled in advance, so that there is a sufficient time frame for the complete resolution of the issue.
This is especially true if the only access option is via remote-controlling where the customer’s admin must be present. If the customer provided us with SSH access, this problem is a bit smaller – our admin starts the repair immediately when available and doesn’t need to meet up with the customer’s admin.
Bug report verification
It is not far-fetched to say that every server environment is different. With so many configuration options, you would think it is impossible to have two identical servers. This is often the reason why we cannot simulate an in-house specific behaviour described by the customer which acts as a bug.
If a service required to run our application is configured differently as our recommendation, it is not necessarily wrong but may cause issues in the application that are hard to trace back to that configuration.