Build and Release Concept and Process Training | Build and Release Training | scmGalaxy

In this training, we will understand about the The Software Development Lifecycle and their imporance in Software development. There are following topics which includes

Planning and Specifcations: Every activity must start with a plan. Failing to plan is planning to fail. The degree of planning differs from one model to another, but it’s very important to have a clear understanding of what we are going to build by creating the system’s specifcations.

Analysis and Design: In this phase we analyze and defne the system’s structure. We defne the architecture, the components, and how these components ft together to produce a working system.

Implementation: This is the development phase. We start code generation based  on the system’s design using compilers, interpreters, debuggers to bring the system to life.

Testing: As different parts of the system are completed, they are put through a series of tests. Test plans and test cases are used to identify bugs and to ensure that the system is working according to the specifcations.

Releasing: After the test phase ends, the system is released and enters the  production environment.

Maintenance: Once in the production environment, the system will suffer modifcations as a result of undetected bugs or other unexpected events. The system is evaluated and the cycle is repeated.

SCM provides the way to control the software development lifecycle, allowing for a greater degree of software management being one of the core components in the software development process.

In order to control the software development lifecycle, SCM employs a series of concepts and techniques. We will take a look at some of these key concepts and techniques, what they are, and how they work. In this section you will learn about the following:

Resource Management: Managing source code fles, project fles, documents, images, etc., in a central area commonly called repository, database, or depot.

Workspaces: Providing a private work area for each project participant, separate from the other participants (architects, developers, testers, etc.).

Resource Versioning: Maintaining different resource versions as the project evolves using fle revisions stored as fle deltas.

Cooperation Support: Managing the interaction between the project participants using operations like check out, check in, and merge.

History Management: The ability to view, manage, and mark resource versions using labels.

Build and Release Management: The ability to manage project builds and releases in order to ensure that the confguration for the resources used in the

builds is marked, known, and reproducible.

Parallel Development: The ability to work in parallel on more than one project version by branching multiple codelines and later merging them.

And as part of the last section, Build and Release Management practices which can is the process of transforming the human-readable source code fles into binary machine-level executable fles by combining confguration items, using building scripts, make fles, compilers, linkers, and other tools, and creating a version of a software program.

Building can take from a few fles to several hundreds or thousands of fles making it a delicate process. While every developer performs test builds in the workspace to ensure that the changes made do not break the repository state, when it comes to building the entire confguration to release a project version, different policies have to be in place. We saw the ability of the repository to record specifc confgurations: how labels can be used to create repository snapshots. Having all source code fles in a managed central area, the repository, allows for greater control over the build process, controls specifc project confgurations ensuring they can be reproduced in the future, and adds the ability to automate the build process.

Automating the building process brings great benefts and boosts the productivity as possible problems are spotted earlier and on a regular basis. This can be achieved by using frequent integrity builds with regression testing (sanity builds), using automated building and testing environments.Release management is closely related to build management as a release is in fact a production build of the project. Release management is the process of releasing a built and tested system into the production environment with the scope of making the application available to the end users. When releasing a product version, the confguration used to generate the release build must be recorded and stored to ensure that at a later time the build can be reproduced identically. This allows us to see exactly what resource versions were used in the build and be able to release future improvements and bug fxes based on that confguration. Upon releasing the frst version of a product, things aren’t very complicated. The entire development team effort is focused on developing this frst version. But as the product comes together and the moment for it to be released is nearing, things change.

After the frst version is released the effort is divided into at least two paths, one to continue the development towards the next release and the second to maintain  the released version. These efforts must be conducted in parallel and SCM must

be able to cope with this situation. For these cases SCM provides support for  parallel development.

For more info of this training – please send an email to info@scmGalaxy.com