When we want to structure Application Lifecycle Management we need not only thinking in procedures but as well, or may be even more important, we need investing in the complete environment that can support us in this process, including all hard and software tools.
To support the process of Application Lifecycle Management, in this document we will look at implementation possibilities of the so called DTAP environment, i.e. (software) Development, Testing, Acceptance and Production.
Let's have a look at the functional requirements for a DTAP environment.
In this environment, the components (program modules) are programmed and the component tests and component integration tests are carried out. Part of the software development process is as well specifying what to develop. Functional, Detailed, Technical and Release Documentation are all part of this process. All (version-ed) information, including the source code, must be well organised, easily searchable and accessible. Developers need a modern Integrated Development Environment (IDE). “Integrated” should include (but not be limited to):
- Writing and debugging software
- Unit testing
- Source Control
- Build Server
- Version-ed documentation
- Collaboration with other stakeholders
- All related information easily searchable and accessible.
Testers are key members of the development team and test activities should be completely integrated into the software development process. Ideally the same IDE is used by testers, just using other views and tools.
The testers IDE should include (but not be limited to):
- Create test plans and perform tests.
- Create “test labs” in order to test applications in multiple environments. Each lab contains its own databases (automatically) filled with all relevant configuration and functional data. A lab may also include relevant hardware. Configuration or even firmware may be different for each lab.
- Create virtual test environments quickly, deploy the application, and then complete automatic tests.
- Reporting bugs.
- Recording of steps that cause unexpected behavior.
- Generate test cases based on the steps that caused the bugs to appear.
For system integration testing, the test environment is linked with all interacting test environments of systems involved. This includes all hardware and software.
Ideally, the acceptance test environment should be a copy of the production environment. All systems that operate in the production environment are installed and, if necessary, active. The databases contain actual data, anonymously transferred from the production environment (if possible).
In the Acceptance environment, Support & Operations personnel may validate all information in order to establish whether the system can be put into use. Customers may even play a role in this.
For the Support & Operations department the Acceptance Environment is the first step towards the Production Environment, towards going live.
Within the Acceptance Environment Support & Operations must be able (but not be limited) to:
- Create and document release procedures
- Setup an Acceptance Environment resembling a particular Production Environment
- Different Acceptance Environments can be used to test one release based on different Production Environments.
- Test the installation and release of software before installation on a production side.
This is the environment in which all programs are eventually installed. No tests are performed in this environment. Normally, customers take care of the Production environment.
This said, it is of the utmost importance to be accurately informed about erroneous situations in a live system. Support & Operations is the first contact for customers with operational problems. To help Support & Operations with their tasks the Production Environment should support (but not be limited to):
- Exception reports
- Performance reports
- Recording and capturing the sequence of events that caused a bug and to store trace information, together with the appropriate environmental data.
Furthermore, Support & Operations must be able to:
- Have access to all relevant documentation
- Report bugs, including all relevant information gathered
- Report other observations to the development team for analysis and triage.
Ideally the software tools for Support & Operations are integrated with all other tools for software development, testing and acceptance.
For all but the most trivial of solutions, application development is a multidisciplinary exercise that encompasses a wide variety of tasks and participants. The principal aim of any software development effort is to deliver a quality application that meets the customers’ requirements in a timely and cost-effective manner. However, there are many obstacles that can get in the way of any development team. Many of the problems are caused by a lack of clear and effective communication among developers, project managers, and customers. Other problems may result from a lack of discipline that occurs when developers and project managers misuse or misunderstand the development process. Consequently, adaptable and easy-to-use tooling is critical to help overcome the issues that can arise when producing a potentially complex system.
Visual Studio 2012 and Team Foundation Server help to address these concerns by supplying a collection of tightly integrated tools to support and manage the entire Application Lifecycle.
The primary aims of Visual Studio 2012 and Visual Studio Team Foundation Server 2012 are to:
- Prioritize collaboration among everyone involved in developing an application, incorporating customers as equal members of the development team.
- Deliver timely and actionable feedback to reduce wasted effort and its associated costs.
- Provide natural and appropriate tools for the tasks involved in designing, developing, testing, delivering, and maintaining quality software.
- Support best practices for application development, while remaining independent of any specific methodology.
For more information look at