Some companies, when they take sites for maintenance, require them to move to their servers and their infrastructure. More often they charge money for this work. At Initlab, we support Drupal websites on our clients' servers, we don't require them to move, and therefore we don't charge money for this move. Instead, we have mandatory onboarding. In this article we'll explain what it's for and what the benefits are.
Many customers are frightened when we have barely started working together and the tasks already have 4 hours of work. The word "onboarding" is also not quite clear, what is it and what is it for? When you have a website, you'll start counting hours!
It's all very easy to explain with a simple analogy. The client is the owner of the ship on which he hires an Initlab team. And a good team makes sure to check the ship before it sails. You have to fix bugs, tidy up, bring your own equipment, etc. You can scoop water out of the hold with a mug in the middle of the voyage, but wouldn't it be easier to patch the hole and sail on in peace?
This is what mandatory onboarding is all about - checking, debugging all systems, making future work easier. Four hours spent now will save a lot of working hours, and therefore the client's money.
We will describe all the steps our managers, system administrators and developers take before the site is fully operational.
Managers' tasks
Our managers are not only responsible for future communication with the client, but they also have to oversee the overall order of the project and control all processes. Their tasks during onboarding:
- Obtain SSH access from the client and into the site's admin area, add logins and passwords to PassPack. Our employees need secure access to the server/hosting - SSH - to work in peace of mind. We try to work through SSH and through the console for security reasons and to save time. Managers then check that passwords are correct and enter them into PassPack. This is an encrypted vault of passwords - we never send such data via email or correspondence. Only PassPack. It guarantees complete security and confidentiality of access to the site.
- Design a project in RedMine. RedMine is a project management system, where all the website tasks are located. An account is created for the client. He or she can keep track of the time spent, send in tasks, view their priorities and the staff working on them.
- Set a task and monitor its completion. Our managers train clients on how to use RedMine and check that everything is working correctly - notifications are received, tasks are set, the developers receive them and complete them. Further coordinated work with the client is our priority.
- Offer additional services: backups, administration, SEO audits. No, we don't mean to impose services. Our managers will find out what your site needs and whether you need it. They will first consult with those who will work with your site, find out the additional needs of the site and suggest only what you need.
Tasks of DevOps, system administrators
These guys will set up and maintain your web server, keep your site running, and help developers do their work quickly and efficiently. All onboarding tasks usually take them up to two hours - time well worth it.
- Install Drush on a prod. Drush is a command that can be used to quickly perform actions on the site: reset the cache, connect to the database, enable/disable modules. You don't have to go into the admin panel every time you use it. This will simplify basic tasks and save hours and therefore money for the client.
- Set up a demo copy, save access to PassPack. We always make a working copy of the site, usually on our own servers. This is necessary to demonstrate the intermediate results of the work - to hand over a complex task in parts, to coordinate changes so as not to break the main site. We lock the copy with a separate password in PassPack to protect against leaks and to ensure that the developers have access at all times.
- Set up Git. Git is a system for controlling and storing file versions. It's a must-have service for all developers. All changes from the site are recorded here - who, when, and what was changed. So that if anything happens, you can roll back to an old version or find the time when changes were made.
- Set up CI. CI helps you quickly transfer changes from copies of the website to the working version. Manual migration takes much more time and labour. We are used to keeping things simple and fast, making it easier for everyone, including the client. In addition, CI setup allows to implement automatic code review for Drupal standards and automate testing of the site when changes are transferred, as well as to update the copy of the site at the click of a button. Code validation and automatic testing are necessary on complex projects in large development teams and aren't mandatory for everyone. But on large-scale projects, we highly recommend them - so there will be fewer bugs and glitches. They are implemented in consultation with the client.
- Archiving a copy of the website database before work commences. The site consists of files and a database - the files contain images and code for the site, scripts, and the database contains content, users and shop orders. Before starting the work we back up the database copy and place it on the archive server so that in case of force majeure we can restore everything or compare it with the initial version. Any errors detected on the copy of the site DevOps indicates in a ticket for further analysis by the developers. Our developers get involved and help deploy a fully working copy of the site for development.
- Putting the website up for monitoring. This service is agreed upon with the client. We monitor the availability of the site and the availability of security updates. This is necessary so that we can fix problems on the site more quickly.
Developers' tasks
These guys will design your website. Their job is to make sure that the site was originally designed to the highest Drupal standards. If this is not the case, the developers will make recommendations on how to improve the site in the future, and determine which tools can be used at the moment. Developers are responsible for one of the most critical parts of the job, which means their 2 hours of preparation and testing now will save dozens of hours in the future.
1. general assessment of site quality to facilitate further evaluation (custom + Hacked + Schema + Watchdog). This is something akin to a doctor's check-up. Developers look at the "history" of your site - what happened to it before, how it was created and maintained before. At this stage there are 4 mandatory points of check:
- Has anyone made custom modules? Drupal is a system where you can use pre-made modules or you can write your own. As a rule, 99% of functionality can be implemented on off-the-shelf solutions. But many developers don't know about it, so they "reinvent the wheel". We check the site for 'self-written' parts, so that we can take control of them and, if possible, fix them in the future.
- Have developers changed the Drupal core before us? Sometimes developers for various reasons (don't know how, don't want to, believe it's faster) make changes to the Drupal core at once. It's like breaking your arm and instead of putting a cast on it you just cut it off. That's why our developers check the core for such unauthorized changes in Drupal core. It's all the same site operability and time saved in the future.
- Whether the database structure has been changed. In this case, Drupal updates may not apply. We, therefore, adjust the database structure description so that there are no problems with security updates. Or document the changes found so that they can be taken into account in the future.
- We review Watchdog. This is a built-in Drupal module that logs errors. If there are a lot of them, the site will work slowly and further maintenance will be complicated - you'll have to spend time figuring out the causes later. We check the pages of the site for errors in Watchdog. If everything is done by Drupal standards, there won't be anything unnecessary there. But if a non-professional or inexperienced developer was working on the site then the Watchdog will contain some entries for errors. Sometimes there are too many of them, which is why they need to be dealt with immediately.
2. explore the state of Composer and configurations for Drupal 8+ sites and Features for Drupal 7:
- not conflict with the way the site has worked before us, otherwise, there is a risk of breaking a lot of things;
- quickly update or install the required module on the website;
- record the history of changes to the website settings;
- quickly transfer changes from copies of the site to the main site;
- reduce errors (a robot does this, not a human, which is not perfect).
- If the condition is far from satisfactory, in consultation with the client, we will tidy up the necessary parts of the site.
3. Find out if there is nothing wrong with the site's display. In addition to its internal processes, the site also has an appearance - how it is displayed to your customers. The design theme is responsible for the appearance of the site. Typically, its development utilizes preprocessor - a special programming language and tools. And if at the beginning of the creation there was used the preprocessor, and then they worked without it, in the code of the site will be difficult to navigate. There is a risk of losing all the changes made, if they were introduced in the wrong place or the preprocessor is not running correctly. There are many preprocessors, so we find out which one was used and how to continue working with it.
We hope we have managed to explain clearly why onboarding is so important. In essence, it's the same as a changeover, just like in any production facility. We value comfort and speed, because both we and the customer need it. Four hours of time to work in the "field" in peace of mind. Believe us, it's worth it.
Add new comment