Explain four ways of looking at ALM

Four Ways of Looking at ALM

We’ve chosen these four because we’ve seen this separation in many of the organizations we’ve worked with or spoken to:

• Software development lifecycle (SDLC) view: This is perhaps the most common way of looking at ALM, because development has “owned” management of the application lifecycle for a long time. This could be an effect of the gap between the business side and the IT side in most organizations, and IT has taken the lead.

• Service management or operations view: Operations have also been (in our experience) unfortunately separated from IT development. This has resulted in Operations having its ownview of ALM and the problems in this area.

• Application Portfolio Management (APM) view: Again, perhaps because of the gap between business and IT, we’ve seen many organizations with a portfolio ALM strategy in which IT development is only one small part. From a business view, the focus has been on how to handle the portfolio and not on the entire ALM process.

• Unified view: Fortunately, some organizations focus on the entire ALM process by including all three of the preceding views. This is the only way to take control over, and optimize,

ALM. For a CIO, it’s essential to have this view all the time; otherwise, things can easily get out of hand.

8. What is VCS? Explain features of TFS VCS.

A version control system (also known as a Revision Control System) is a repository of files, often the files for the source code of computer programs, with monitored access. Every change made to the source is tracked, along with who made the change, why they made it, and references to problems fixed, or enhancements introduced, by the change. Version control systems are essential for any form of distributed, collaborative development. Whether it is the history of a wiki page or large software development project, the ability to track each change as it was made, and to reverse changes when necessary can make all the difference between a well managed and controlled process and an uncontrolled ‘first come, first served’ system. It can also serve as a mechanism for due diligence for software projects.

Team Foundation Server (commonly abbreviated to TFS) is a Microsoft product which provides source code management (either via Team Foundation Version Control or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, lab management, testing and release management capabilities. It covers the entire application lifecycle. TFS can be used as a back end to numerous integrated development environments but is tailored for Microsoft Visual Studio and Eclipse (on Windows and non-Windows platforms).

TFVC is a centralized version control system allowing teams to store any type of artifact within its repository. TFVC supports two different types of workspaces when working with client tools - Server Workspaces and Local Workspaces.[13] Server workspaces allow developers to lock files for check-out and provide notification to other developers that files are being edited. A frequent complaint for this model is that files on the development machine are marked as read-only. It also requires developers to "go offline" when the server can't be contacted. Local workspaces were designed to avoid these problems. In a local workspace scenario files are not read-only and they do not have to be checked out before working on them. As long as the files are on the developer's local machine, it doesn't matter if the server is connected or not. Conflicts are dealt with at check-in time.

To improve performance for remote clients, TFS includes the ability to install Proxy Servers.[14] Proxy servers allow source control contents to be cached at a site closer to the developers to avoid long network trips and the associated latency. Check-ins are still performed directly against the TFS application tier so the Proxy Server is most beneficial in read scenarios.

As part of the source control engine, TFS supports a number of features to help developers ensure the code that is checked in follows configurable rules. This rule engine is called a Check-in Policy. There are several out of the box policies such as the Changeset Comments Policy which will not allow a check-in unless the developer enters a check-in comment. These policies are extensible and can be used to examine all aspects of the code being checked in, the comments and the related work items. TFS also supports a Code Analysis feature that when used independently is known as FxCop. The inclusion in TFS means that the analysis can run against code checked into the server and during automated builds.

9. How build automation is handled with TFS?

After version control, automating the build is the second most important thing you can do to improve the quality of your software.

Build automation is the process of streamlining your build process so that it is possible to assemble your application into a usable product with a simple, single action. This entails not just the part of code a particular developer is working on but other typical activities such as the following:

· Compiling source code into binaries

· Packaging binaries into installable modules

· Running tests

· Creating documentation

· Deploying results ready for use

Figure shows several of the logical components that are critical in the Team Foundation Build architecture. A build is defined by a build definition, which describes the build in detail, including what should be built, how, and when.

The build definition belongs to a team project in Team Foundation Server. When the application tier determines that a build for the build definition should be performed, it sends a build request message to the queue for that build controller. The build controller then downloads the Windows Workflow-based build process template defined for the build definition and executes it. By default, this causes a build to be run on the next available build agent in the controller’s pool of agents. A build agent is the actual machine that performs the build. Each build agent has a build controller as a parent, but one build controller can have multiple build agents that it can use for the build. Each build controller must be assigned to a single project collection. The build agent executes the main part of the build process as described in the build definition’s process template—including calling MSBuild to perform the actual compilation and test steps. Once the build agent has successfully executed the build, the default build process template then archives the build results (such as the website, executable files, assemblies, and so on) to the Windows-based file share provided as the drop location. It will also publish any symbols to the symbol server (if configured). All the information about the resulting build (including the build number, status, and information on the individual build’s progress for a particular build definition) are called the build details. These details are displayed in a build report. Note that the build controller and build agent processes are hosted by the build service. The build controller and build agent may live on the same machine. However, it is recommended that they do not reside on the same machine as the Team Foundation Server application tier in a production configuration. Executing a build is very CPU- and disk I/O-intensive. Therefore, the operation of builds could affect the performance of your application tier if running on the same machine, which could reduce the productivity of your entire development group.

Дата добавления: 2015-10-24