First of all I want to notice that DCVS (Disctributed Concurent Version System) is only a tool, which may be useful in some tasks related to storing different versions of the programm. So we need to determine use cases of a DCVS and needed information to store before integrate it into a workflow. Let’s try to define some requirements from different roles involved in developing process: client, manager (superviser), programmer and release engineer.
Client never sees DCVS history but he always has access to the two portal versions:
- Fully tested production portal with actual content;
- Sandbox (preview), where client may test new functionality, see new design and e.t.c.
Portals, which are accessable by clients, should be always up: all portal functionality (production and preview) functionality should be accessable 24/7.
Preview portal is used to prepare some materials for production site. So we should be able copy any desired information easily.
Preview portal mainly used not to show some functionality to clients, but to give possibility to check the solution by theyself. In most cases it’s enough to produce use cases (illustrated in difficult cases) for client to describe incomprehensible functionality (It’s preferably to send this information to the client and developer before development started). Also I want to notice, that the client may look not only at concrete function, but at whole portal, so primary goal of preview portal is to give the client a chance to look at his future production portal. So production portal will be a copy of approved preview one.
Manager is some kind of a proxy between a developer and a client. So he should be able to inform client with actual information about client’s portal, such as list of available functions on preview portal and production one.
As far as manager has information about clients’ whishes and priorities, he determines all functionality that should be released to the portal. It’s important to understand that adding some functionality now will affect all portal, not a small its part (maybe in future we’ll introduce modules and module testing but not now). So it’ll preferably to assign tickets to make possible to do cumulative tickets updates.
On the other side manager’s connection manager should be able to reproduce any client use case with the identical environment without access to clients’ portals (production and preview). It’s needed for testing. This ability is very actual for clients that run their portals in separate networks, such as Deere or USAA.
Developing new functionality won’t affect any other work.
Developer has access to the following portal states at any moment:
- Any his work;
- Copy of production;
- Copy of preview;
Regular, developer shouldn’t merge his work more than once. Exceptions may be done to production hot fixes.
Any code modification should be presented in DCVS. Developer should be able to answer following question at any time:
- What has been changes?
- Who has changed it?
- When has been code changed?
- What version have been affected?