Release types

From All n One's bxp software Wixi

Jump to: navigation, search

1 Overview

Different companies have different terminology for the definition of how advanced or experimental their developments are.


This article is dedicated to understanding how the bxp development grade their releases.


2 Types

2.1 Concept

A known solution to an issue. Will be mapped to a module. The module may or may not exist. The item will be a job in our ticket queue and be documented until either a patron is found or is required as a bug fix. The learning department of All n One are custodians of concepts.


2.2 Planned

When the idea funding has been identified a solution on paper and whiteboard is worked through. This process involves the key elements and key challenges that will be faced in the implementation. This process usually requires experienced developers to facilitate the discussions. More detailed notes will be made. Comparison with existing tools and solutions from competitors solutions will be researched. A notational version will be discussed internally with the developers. At this point initial wixis as placeholders are created to allow the collection of notes and potential sharing with clients.


2.3 Alpha Development

A new branch in GIT is created. Development of the code begins. The three areas of materials are code, sql and documentation. All development is done in a local to the developer testing environment in isolation from all systems. As development continues it is logged in the Time Tracker module of the All n One instance to provide a double audit trail. Code changed in GIT and who was working on what and when.


Local instances with the All n One development office can be interacted with by other developers as required. Demonstrations and desk "side by side" sessions allow developers to demonstrate concepts and discuss progression. When the developer is happy that they have a package to release it is moved to beta release.


Notification to clients as to impending releases is made at this point. If there is going to be a direct impact on a client system or it's interface then at this point client's are notified.


2.4 Beta Development

To allow testing in an "as close to live" scenario as is possible, the code is released to the ww5 testing infrastructure. Here the code can be checked against live client scenarios, against prepared test data and also tested by other developers and clients as required.


As the code is refined and iteratively improved, the documentation will be made and release into the live Wixi. Whilst this does cause a time issue, documentation is ahead of the live code, it allows clients to read, research and better understand what is coming.


A marketing email is created and notification of the changes are communicated from the Business Development team to existing clients as to the level of impact.


2.5 General Release

A GIT push to the live severs is performed. This process transfers the code from the ww5 to the ww3 environment and has immediate application to all clients and all systems.


As with any development bugs and issues and refinements are identified when in a live environment. These changes are treated in an "Agile" way and the process here is reiterated, with the patron for Green Hamsters being instantly approved as an internal cost.


3 Departments and their roles

The departments of All n One All_n_One_Departments


3.1 Contact, Marketing and Business Development

These departments are responsible for the communication of change to the clients in a timely and accurate manner.


3.2 Frameworks and Projects

These departments are the primary teams responsible for backend / server side change. Server side is referred to by All n One as Framework development in bxp parlance.


Projects are responsible for documentation and project planning and delivery. Frameworks are responsible for Green hamsters. Both departments can develop server side code.


3.3 Content

This department is responsible for JavaScript and client side development. Whilst their work is also software development the changes tend to be more immediate and done in a far more "real time" way. The ww5 environment is also available to Content to use but sometimes for data security and speed of roll out the testing environment is not suitable. Content development processes mirror all the steps above with less emphasis on alpha and beta development.


Content changes are limited to a specific client. If a change affects all clients it is treated as a Project or Framework job.


3.4 Security

Security ensures that all systems remain secure and deals with the operational practices and use of the tools. Their input is pervasive through all departments and is a key factor in all aspects of development by all departments.


3.5 Infrastructure

It is rare that infrastructure will change in the live environment. If it does, the change will be treated and managed as a Project will all appropriate steps applied as above.


3.6 Coordination

The coordination department ensures that all the departments communicate change and updates.


3.7 Learning

Learning ensures the Wixis are understandable and usable. It then folds any change into the Driver's licence programs and existing training course materials available through the Wixi.