Dev, QA, Release, Live


The new factories of the modern world are software companies. There are popular methodologies such as Agile and DEVOPS that have been adopted in recent years to produce quality software in digital factories. Using these universally accepted methodologies, Workcube operates a software factory targeting the LEAN approach.


As illustrated in the diagram below, the rules applied in code development are as follows.

  1. Workcube development process is carried out on Git.
  2. Coders pull updated code from the master branch in the public repository in the Atlassian Bitbucket cloud to their computers.
  3. They code the tasks assigned to the coders and send them to the DEV branch with a "Pull Request" after performing the first test.
  4. A temporary Task-Branch is opened for each task to follow the code manufacturing flow. Each task must have a "Pull Request".
  5. The "Pull Request" code is reviewed and merged into the DEV branch by the chief developers.
  6. The QA team monitors the code merged into the dev branch through task registrations on the networg.workcube.com portal.
  7. IQA team tests each task and its associated merged code on dev.workcube.com.
  8. The QA team member reports the test result as feedback to the coder.
  9. If the test result is unsuccessful, "Revision" is requested.
  10. If the test result is successful, "Add to version" approval is given.
  11. The task with the status "Add to version" and the associated code is pulled into the "Master" branch.
  12. After checking, the chief developer merges the code to the Master branch and deletes the branches of the finished tasks by closing the task branch.
  13. The QA team monitors the code merged into the master branch through task registerations on the networg.workcube.com portal.
  14. QA team member tests the same task and related code on the qa.workcube.com portal.
  15. The QA team member reports the test result as feedback to the coder.
  16. If the test result is unsuccessful, "Revision" is requested.
  17. If the test result is successful, a "Release Note" is added to the task details.
  18. The Release Note is grouped as Hotfix and Feature and published under "Release Notes".
  19. Users and System Administrators can access "Release Notes" from Workcube, read the notes and upgrade the system.
  20. Two types of upgrades are available as Version Upgrade or Patch.

How to apply to Workcube for suggestions and hotfixes?

  1. If you want to make an application about a page in Workcube, when you are on that page, click "?".  When you click the icon, the dropdown menu opens under it.
  2. Click the "Report a Problem" link in this menu to go to the wiki.workcube.com/addhelp screen.
  3. On the Add Help screen, the technical information of the page associated with the error or suggestion is sent to Workcube in the background.
  4. Additional screenshots and a loom video are requested from the user.
  5. The tickets are grouped and defined by the QA Welcoming Team and feedback is given to the applicant
  6. The version of the customer Workcube where the ticket opened from is compared with the current version and patches.
  7. In the current version, the case is tested.
  8. If the user (customer system) is in the current version but the error is not found in release.workcube.com, the applicant is replied by saying "Get the Patch".
  9. If the error exists in release.workcube.com, the QA version is also checked.
  10. If the error is not found on qa.workcube.com, the user is notified as "Hotfix will come with the next version".
  11. If the error also exists on qa.workcube.com, the user will be notified as "In Review".
  12. The error is investigated by the QA team and the findings are revealed, and a task is assigned to the DEV team.
  13. The DEV team manages the development process on Workcube Project Management and the integrated Bitbucket cloud.

Why should we always have the current version?

  1. Developers should always work by getting the Master branch. In this way, they will be working on the most current version.
  2. Customers should always be on the Current Version. This way, they always get new features and hotfixes.

How do we get to the Current Version?

  1. If you do not see the Workcube 19.12 and higher version number when you scroll over the Workcube Logo in the upper left corner, you may be using a clone from the Master and worse, from the DEV branch.
  2. The DEV branch is the development, the QA branch is the test environment. You probably do not upgrade after the first installation or try to do it manually.
  3. This is a very risky situation for production environments. A Workcube Developer Edition that has not passed quality control and remains old is definitely not suitable for use as production site.
  4. Live (Production) environments that remain in the dev and master branches and installed from the developer edition must be upgraded.
  5. Check out the wiki article which explains the steps to be taken to upgrade the developer edition installations in Dev and Master branches. >> Link

Why should the QA environment be set up besides the live (production) environment on client servers?

  1. Two Workcubes, qa.domain and live.domain, are installed on the same server starting from the implementation phase for customers with customization or additional code.
  2. "qa.domain" and "live.domain" are two Workcube sites connected to the same database.
  3. "qa.domain" is always updated with the newest version.
  4. System administrators and users can examine new incoming or expected features in "qa. Domain" with the same data and perform actions on them.
  5. In order to prevent possible errors, data differences and usage practices in the new version affecting the production environment; "live.domain" works on the previous release or patch.
  6. Administrator and key users upgrade "live.domain" after performing basic tests in QA environment.
  7. In this way, while key users work in the new version of qa environment, standard users work in live in the previous version. Mission critical operations are not interrupted.
  8. It is also possible to keep the live.domain always up to date, creating an old.domain and leaving it in the previous version.
  9. Those who have the right to use open source code can also install dev.domain in addition to this.
  10. For customers who have the Open Source Code License, dev.domain can be installed in addition.
  11. The live database is isolated by establishing a development database for dev.domain.
  12. Customization and improvements made in the dev environment can be transferred to the customer qa or live environment. This obligation belongs to the customers and business partners.

How are sectoral solutions and add-ons upgraded?

  1. Sectoral solutions or add-ons are located in the Addons / Partner_Name / Solution_Package folder in the Workcube directory.
  2. This folder must be in exactly the same folder and file structure as the FactorySettings folder inside the WBP folder in the main directory.
  3. License control is done in installations with addon licenses.
  4. Addon developers continue to develop Files and WRO files in their own folder on Git.
  5. Add-ons are automatically upgraded for licensed installations.

How to localize?

  1. English and Turkish interface is included in the standard library. These are part of the standard installation.
  2. Developments are made in the dev and QA environment, and the QA team regularly develops a dictionary for the interface.
  3. German, French, Arabic, Russian, Italian and other dictionaries are regularly developed in dev and qa environment in collaboration with local business partners.
  4. Words, Definitions and Phrases in standard applications are regularly added to the dev and master branch by the local partner.
  5. Add-ons developed for compliance with local laws and regulations and files customized accordingly are placed under the Addons / Partner / Country folder and added to the DEV and Master branch on Git.
  6. To see the words coming from the dictionary on a page, click on the settings icon in the upper right corner. The "Development Mode" checkbox is checked under the "Other" heading in the Setting tab.
  7. When the page is refreshedd, the words from the dictionary appears as | Word |. Clicking to the word takes you to the dictionary.

How is customization done at the code level?

  1. It can be extented by adding 4 header files to a Workcube object (WO: fuseaction).
  2. In DevTools, there is WO-Fuseaction in the Workcube Objects list. Additional file paths are written to the extented inputs in the WO detail.
  3. Thus, when WO-Fuseaction is requested, "before extented" files run. With save or update, "after extented" files run.
  4. Addoptions is the work of a customized file instead of the standard file.
  5. When the path of the customized file under WO-Fuseaction is written in the Addoptions Control Path field; addoption file works instead of standard.
  6. Addoptions are not recommended as it separates the application from the standard version. Do not use this method unless it is really necessary. In 2022, the addoptions feature will be removed.
  7. Under the BPM application, display file or action file is added to the process-stage screens.
  8. Special reports are added by uploading files to special reports.
  9. Specially developed files are added to System Printer Documents and Templates under General settings.
  10. New words are added to the dictionary to change words in the interface. In order not to be affected by the upgrades, the "Do not allow to be affected by Upgrade" checkbox should be marked.

Where should I store the codes I have developed specifically for my customer?

  1. You should open and store a customer-specific branch in the Bitbucket repository of the Workcube Developer Community.
  2. Storing code on the client server is not a modern method for code continuity and backup.
  3. The service partner may change, developers may leave the project and servers may crash. For these reasons, you must keep your project in a branch in order not to be dependent on a person and to reduce the risks.
  4. The customer-specific branch is opened in the repository as Projects / ProjectName. In Networg.workcube.com, the Bitbucket address of the relevant project should be entered.
  5. If you want the code developed specifically for the customer to work with the version, you must put it in the Addons / Custom / ProjectName folder in the "Master" branch.
  6. Every editing that the developer makes in the Addons / Custom / ProjectName folder is automatically upgraded during version transitions.

How to share information in accordance with GDPR rules?

  1. Only authorized employees and authorized business partners of user companies with subscription registration in networg.workcube.com can create a ticket for support
  2. Authorized persons must be registered by filling the System-Access-GDPR-Communication Document.
  3. It is mandatory to fill in the all information on the General Settings> Application Information form for each Workcube installation.
  4. In accordance with the GDPR rules, no information is given from the support department to the notifications made without complying with these rules.

Feedback

Did you find this content helpful?
Related Contents