It’s not shocking that a lot of organizations struggle when it comes to DevOps execution. DevOps is a new conception which IT organizations use to enhance collaboration between two functions into one. In today’s cutthroat business environment, DevOps comes as an important resolution that helps organizations meet ever-growing business demands.
The meaning of DevOps is different for different peoples. Some says it’s a “collaboration of operations and developers” or it’s using automation or it is a toolchain approach or culture or a job title or it’s just a Dev. and Ops. or variety of related things. But if we look onto it, it’s not just a set of tools or not just a culture or job title. We can say It is a way of doing work where people of both operations and developer skill sets work together on projects to create quality products without wasting resources and infrastructure in a short span of time by using best practices of tools.
There are many organizations in the world who are adopting DevOps to enhance their employee Performances and revenues and profitability of their business. There are many studies done till date where it is clearly shown that where companies implement the DevOps approach get more done, plain & simple. The greatest change in approach in a DevOps environment is that there is a single group made out of cross functional members including operations architects, business expert, DBA’s, QA, developers and so forth. There are many advantages of collaboration among these different roles delivers.
If we look on to benefits there are:-
1. Continuous software delivery
2. Less complex problems to fix
3. Faster resolution of problems
4. Faster delivery of features
5. More stable operating environments
6. More time available to add value (rather than fix/maintain)
To accomplish this, Dev and Ops must break the silos and work together with each other, share liability for keeping up the framework that runs the product, and set up the product to keep running on the framework with continuous quality input and delivery automation.
In this process there are so many tools and practices used to achieve the results. Source Code Repository, Build Server, Configuration Management, Virtual Infrastructure, Test Automation and Pipeline Orchestration any many more in the process.
DevOps is certainly a group activity, however it’s still vital to clearly define once roles and liabilities for accomplishment inside the group. Means to say it is really important for organizations to make sure dev and ops teams are collaborating and sharing responsibilities throughout the software delivery lifecycle from planning all the way to managing the production environment.
Now the real problem is that there are various challenges an organization and their employee’s face when they trying to execute DevOps skills because they do not able to overcome the Developers and Operations mentality and unable to do continuous balance and change of work process, they lack of understanding the security and access management, unable to do continuous monitoring, Toochain cashes of Developers and operations and various others problems they face when they try to implement it on their projects. To overcome these challenges organization’s must provide their employees DevOps skills from industry experts. Now to make your job easy I did some research on it and found one portal “DevOps Consulting” where you can get best industry trainers and consultants for corporate and individual training.
Hi, I am prabhakar, i have read an article about Team Building and i would like to share it with you.All successful businesses and organizations know that teamwork and team synergy is the key to success. A lot of effort and resources are dedicated towards team building exercises and activities. A good team forms the foundation of any company, organization or community. Team building is not an easy task. This is because a team consists of various individuals with distinct personalities, schools of thought and disposition. But effective team building steps can slowly help these individuals to rise above petty differences, working together and complimenting each other to ensure the overall success of the team as well as personal growth of each individual. A discordant and inharmonious team will continue to experience failure even if it comprises of brilliant individuals. Sports are a very good example of this, in team sports like Football, Hockey or Basketball the co-ordination, communication and synergy of the team is what sets the best teams apart rather than individual superstars.
Team building requires dedication and effective skills. Each member of the team must be made to feel an integral and indispensible part of the team so that team strategy and goals can be placed above individual goals.There are various team building games and exercises available but it is only with perfect execution and participation of all members can these be effective. It is also important to resolve any conflicts as soon as possible. Conflicts can be very harmful for team building. Negative feedback, especially in public should be avoided at all cost as it may hamper the team’s performance.
Software engineers usually find coding to be the most satisfying aspect of their job. This is easy to understand because programming is a challenging, creative activity requiring extensive technical skills. It can mean getting to “play” with state-of-the-art tools, and it provides almost instant gratification in the form of immediate feedback. Programming is the development task that most readily comes to mind when the profession of software engineering is mentioned.
That said, seasoned engineers and project managers realize that programmers are part of a larger team. All of the integral tasks, such as quality assurance and verification and validation, are behind-the-scenes activities necessary to turn standalone software into a useful and usable commodity. Software configuration management (SCM) falls into this category—it can’t achieve star status, like the latest “killer app,” but it is essential to project success. The smart software project manager highly values the individuals and tools that provide this service.
This chapter will answer the following questions about software configuration management.
What Is Software Configuration Management?
Software configuration management (SCM) is the organization of the components of a software system so that they fit together in a working order, never out of synch with each other. Those who have studied the best way to manage the configuration of software parts have more elegant responses.
Roger Pressman says that SCM is a “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”>
We think that Pressman’s description is a better description because we often view SCM as meaning software change management.
Wayne Babich describes SCM as “the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes.”>
The Software Engineering Institute says that it is necessary to establish and maintain the integrity of the products of the software project throughout the software life cycle. Activities necessary to accomplish this include identifying configuration items/units, systematically controlling changes, and maintaining the integrity and the traceability of the configuration throughout the software life cycle.
Military standards view configuration as the functional and/or physical characteristics of hardware/software as set forth in technical documentation and archives in a product. In identifying the items that need to be configured, we must remember that all project artifacts are candidates—documents, graphical models, prototypes, code, and any internal or external deliverable that can undergo change. In SW PM terminology, a configuration item might be a proposal/estimate or bid, project plan, risk management plan, quality assurance plan, CM plan itself, test plan, system requirements specification, system design document, review metric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objects and aggregate objects to be configured. The number of relationships among them reflects the complexity of the configuration task.
Why Is SCM Important?
Software project managers pay attention to the planning and execution of configuration management, an integral task, because it facilitates the ability to communicate status of documents and code as well as changes that have been made to them. High-quality released software has been tested and used, making it a reusable asset and saving development costs. Reused components aren’t free, though—they require integration into new products, a difficult task without knowing exactly what they are and where they are.
CM enhances the ability to provide maintenance support necessary once the software is deployed. If software didn’t change, maintenance wouldn’t exist. Of course, changes do occur. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision.
CM works for the project and the organization in other ways as well. It helps to eliminate confusion, chaos, double maintenance, the shared data problem, and the simultaneous update problem, to name but a few issues to be discussed in this chapter.
Who Is Involved in SCM?
Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation.
How Can Software Configuration Be Implemented in Your Organization?
We used to say, “Make a plan and stick with it—never waffle,” and “Requirements must be frozen—how else will we know what to code?” Now, we say, “Plans are living documents—they will be in a continual state of change as project knowledge increases.” We now know that requirements are never frozen—they merge, morph, and evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change.
Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. This chapter will review SCM plan templates and provide you with a composite SCM plan template for use in any of your projects. We will cover the issues and basics for a sound software project CM system, including these:
- SCM principles
- The four basic requirements for an SCM system
- Planning and organizing for SCM
- SCM tools
- Benefits of SCM
- Path to SCM implementation
SCM benefits an organization in four areas: control, management, cost savings, and quality. These four benefits are mapped to an organization’s overall goals and objectives when the decisions are made to bring a SCM tool in-house. The features of a SCM tool further support these benefits.
SCM Benefits the Organization in Four Major Ways
Control in SCM provides the ability to review, approve, and incorporate changes into a configuration item. There must be one controlling SCM tool so that there is only one set of training, license management, installation, and user procedures. All project personnel use the tool. Inherent in the tool is a standardized, measurable process for change. Integrity maintenance of CIs is enforced throughout the product life cycle. The tool permits only controlled change to the baseline CIs, and all changes are tracked.
Management in SCM is concerned with the automation of identifying and guiding configuration items through their life cycle to final assembly as part of product and delivery. Identification of CIs through a unique naming convention allows version, release, update, and full change tracking. Baselining of CIs with the ability to produce product deltas from the baseline satisfies requirement and schedule changes along with product family support. Rapid reviews and audits of CIs are accomplished through the analysis of historic information collected. Project status reporting is accomplished in a clear and consistent format based on SCM collected information on all CIs under configuration management.
Cost savings are realized across the entire product development life cycle with SCM. Maintaining product integrity through defined, tracked, and audited CIs provides a managed bill of materials for the product released to customers. Cost savings scale with SCM use and application across applications. This scaling is dependent on the depth of control needed for each application product release tree. Deep combinations for product families can be analyzed for risk exposure and cost savings directly impacted by the amount of configuration management applied. Side effects are reduced through controlled change by understanding the impact on all versions and releases. Accurate and repeatable release control is produced in a repeatable fashion over entire product families for all customers and users.
Software development is a people-intensive activity, and quality must be considered at every person-to-tool interface. Ensuring a high-quality work environment must address the process of building software products in an automated fashion. This must include tracking CIs to the tools that produced them and the clients that ultimately receive the product. Measuring the end product to ensure high quality is done through tracking the changes made to a product throughout its life cycle. Repeatable management and change control in a documented and measured fashion allows accurate estimation of future efforts. Quality is an ongoing process. The lessons learned in one product must be transferred to new, related products and entire product families.
When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified.
Potential SCM Problem Classes
- Multiple developer syndrome—When you have a project that requires more than one developer, there is the problem with multiple people working on one product base. This could be a test plan, requirements specification, or code. Effort is wasted when two or more people work on the same file and then save it. Without SCM control, the last person to save the file has those changes saved. All the other changes are lost. The simplistic method of locking a file while one person reads it prevents others from simultaneously working on the file.
- Multiple releases—Enhancements to the base product should result in additional releases of the product containing the latest changes. Once the second release is available, some users are on an earlier release. Having an SCM makes managing those releases possible. When bugs are reported, changes must be made across all impacted releases. As new features become available in the product, they must be made available to all current users, no matter what the release date.
- Product family—As products are built that offer the same capabilities across a heterogeneous set of hardware platforms, both the common and the platform-specific software bases must be managed. If a product operates on four versions of Windows, three versions of Unix, Red Hat Linux, and FreeBSD the user manual may be significantly the same. But there is a different installation process for all nine platforms. Without SCM, nine individual manuals must be written and maintained. With SCM, one documentation configuration item with nine versions will suffice, with the differences being only the installation procedure.
- Requirements change—The first law of systems engineering is that no matter where we are in the system life cycle, the system/software will change, and the desire to change it will persist throughout the life cycle. Dealing with this change represents a major management challenge. Having an SCM in place will ease the management of these changes to the requirements of the products that will occur. An SCM allows the easy identification of feature sets that group the requirements satisfied by a release or version of the product. These feature sets are tracked through development to delivery.
- Schedule change—As requirements change, so must the schedule. Mapping the feature sets for release to the schedule allows project managers to more accurately estimate the effort required for generating that next release. Having the SCM in place allows the project manager to look at historic effort levels in getting out releases. This is an enormous aid in estimating the “what if” scenarios that result from taking on new product users or providing customized solutions to other clients.
- Software changes—No product developer has the luxury to write code once and forget about it. Along with requirements and schedules, the software being developed changes in response to those other changes. Software is not static. That is its inherent power. It can be changed, so it will be changed. SCM systems track those changes so that, if the wrong change is made, a previous working version is available. This capability alone has saved enormous amounts of time as developers have tried out specific solutions that did not work in the product environment and were able to rapidly back up to a working version.
- Staff changes—In the best of organizations, people get promoted, take other jobs, and leave. When that happens in the midst of a development project, not just the technology knowledge goes out the door. The long-learned knowledge of how things are done is also gone. So when a replacement person is brought on board, they may know the technology, but without a documented SCM process, they will have no real idea how to do product development. SCM provides the framework and knowledge base of what has gone on before in the project. A new staff member has one place to go to understand the “how” of the organization’s development process and the “what” of the project to date.
- System/user documentation change—No product developer has the luxury to produce in a technology or tool vacuum. All product developers use hardware microcode, operating systems, tools, and documentation that are not under their control. When a major operating system change occurs (e.g., the next “best” release of Windows), an SCM will allow tracing all the CIs, components, and subcomponents that are impacted by that change. The change is isolated, and the amount of effort required to respond to the change can be estimated. This provides a responsible schedule for an upgrade based on situations beyond the organization’s control.
A template that may be used in the creation of a software configuration management plan (SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues (organization, responsibility, etc.), SCM activities (configuration item identification, change control, status accounting, audit, and reviews), tools, techniques and methods, supplier control, and standards collection and retention.
On any given project, a few engineers or developers specialize in and become your SCM experts. While they are the gurus, everyone on your project will be a user of the product that they select, develop, and maintain. It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product.
We can group the characteristics and abilities needed by the four SCM functions: identification, control, auditing, and status accounting.
- Ability to see partitions
- Ability to see relationships
- Some technical ability
- System engineering orientation
- Ability to evaluate benefits versus cost
- System viewpoint (balance of technical/managerial, user/buyer/seller)
- An appreciation of what is involved in engineering a software change
- Extreme attention to detail
- Ability to see congruence
- Ability to perceive what is missing
- Extensive experience with technical aspects of system engineering or software engineering
- Ability to take notes and record data
- Ability to organize data
- Some technical familiarity
- System engineering orientation
Once the staffing of the SCM function is complete and the overall organization’s SCM policy is established, the configuration control board (CCB) is identified. The CCB is the heart of the control function. It infuses sustained visibility into the process of change throughout the system life cycle and traceability into the process of change. The membership in the CCB is not limited to the developers or product line management. All stakeholders in the product must be represented. This includes the end-user usually represented by marketing, subcontractors used in the product development, product development funders, and the product developers. The CCB is the final decision maker as to what bug fixes, enhancements, and feature sets get included in the next product release.
The CCB has periodic meetings, with the results documented. These meetings can be done in a rapid fashion, and doing them online or via email is an adequate way to gain consensus and come to a decision. Important to status accounting is the documentation of CCB meeting minutes. The basic purpose of the minutes is to provide the CCB decision makers with the information needed to make intelligent, informed decisions. The amount of detail varies with the meeting frequency and technical content.