help.axcms.netAxinom Logo
Save Save Chapter Send Feedback

AxCMS.net Project

 

Roles 

In the majority of cases, AxCMS.net projects involve the following stakeholders:

 

Fig. 1 Roles in AxCMS.net Development

Fig. 1 Roles in AxCMS.net Development

Axinom provides the framework: AxCMS.net. On top of AxCMS.net an ISV (independend software vendors) builds an individual project according to specific customer's requirements ("customer solution" as described in the picture above).

This application (website) is delivered to Web Editors who add and manage content. After a successful publishing process, end-users have access to the live web enviroment.

Depending on the project, additional roles can be defined:

  • Graphic Designer - creates the visual appearance of the web site. His work ends with delivering the visuals (e.g. as Adobe PhotoShop files) to the Developer
  • Frontend Developer - implements the graphic design in AxCMS.net Project as HTML / CSS. From the AxCMS.net process point of view he is a Developer - working within Visual Studio and releasing and deploying his work together with the code of the Developer.
  • Network Administrator - deploys and maintains the web site. See "Installation and Configuration Guide" for a more detailed description. The Administrator's work starts when the Developer provides the release package.
  • Translator - translates the content and/or the GUI to other languages. As long as the Translator works in the AxCMS.net Management System he is treated as a special kind of editor. The main tools for translating the GUI can be found under "Edit / Translations". If the Translations API is used, the Translator can work with 3rd party translation software and the results of his work are automatically integrated back into AxCMS.net.

Environments

We define 3 main environments for a typical AxCMS.net project:

  • The Development Environment
  • The Test Environment
  • The Production Environment

Each environment contains a fully functional AxCMS.net installation, including the Management System, Live System, AxCMS.Service, etc. (see Components).

Fig. 2 Development-, Testing- and Production Environments

Fig. 2 Development, Testing and Production Environments

The Development environment is used to develop the project functionality and layout. The Development environment is installed locally on every Developer's workstation including all components (IIS, Database, etc.). If multiple Developers work on the same project they should use source control software to ensure they all work with the most up-to-date version of the project. In the Development environment only sample content or generated content is used. When the development (or one iteration of it) is finished, the project is released and deployed into the test environment.

The Test environment is similar to the production environment and is used for testing the functionality and layout. Not only Testers, but also other project stakeholders / end users should check the application in the test environment to ensure that it performs as expected and presents the intended image/look. The Test environment usually works with sample content. However, a snapshot from the production system can also be made periodically and installed back into the test environment. If the tests are acceptable, the deployment step of moving it into production can take place. If tests are not acceptable, the project goes back into development where the issues are resolved and a new deployment to the test system takes place.

The Production environment is the environment in which the application is ultimately installed into the LS and where the end users can use it. It can be installed at the company's data center or at an external hosting provider. In this environment, the real content is managed. Please note, that production deployment does not deploy any content (the deployment of the test environment into the production environment does not deploy any content). It is only the software version that is deployed. This is why you should not assign resources to add actual content into the test environment as it will not transfer to the production environment. If it does happen, you will have to find a way to transfer the content later from the test environment into the production environment.

In a simple project you might try to take a shortcut and avoid using the test environment by deploying directly from the development environment to the production environment. Although it can be done, it is not recommended. The main reason for this is that any small bug that may have been overlooked in development could cause damage in the production system, ultimately affecting the end users.

In a more complex project, more environments may be needed. For example, a staging environment  can be inserted after test but before production. This environment can simulate the configuration of the production system and can be connected to actual external interfaces. You might also consider having one test environment at the ISV and another one at the customer site.

Activites

A typical AxCMS.net project - as with any other web development project - involves many activities / processes. Here is a list of activities that are most often associated with a project. Your own project might consist of a subset of these or may require additional activities depending on company or customer requirements:

  • Requirements Analysis
  • Graphic Design
  • Usability Concept / Testing
  • Information Architecture
  • SEO
  • Software Architecture
  • Software Design
  • Development
  • Testing
  • Configuration Management
  • Deployment
  • Data Migration
  • Integration
  • Acceptance
  • Project Management
  • Support
  • Training
  • Documentation