Technical briefing on Software Release PlanningGuenther Ruhe
One of the most critical activities in software product development is the decisional process that assigns features to subsequent releases under technical, resource, risk, and budget constraints. This decision-centric process is referred to as software release planning (SRP).
This briefing will expose a state of the art on SRP. A survey of the most relevant approaches will be presented. Emphasis will be made on their applicability (concerning e.g. type of development process and type of system, tool support and degree of validation in industry. One of these approaches, EVOLVE, will be analysed in detail.
The briefing is addressed to a wide audience. For researchers, an updated state of the art will be exposed, a particular method will be explored in depth, and the presentation will rely on scientific grounds. For practitioners, the practical dimension of SRP will be present. For educators, the briefing will provide the basis for developing course material.
The document outlines an effective software release management strategy with multiple layers and branching models. It discusses establishing rigorous development, build, test, and deployment cycles with common environments. It also recommends moving to continuous integration and deployment with tools and processes to support rapid defect detection. Higher level branches have stricter quality criteria than lower ones, with mainline and release branches intended for stable, tested code. The strategy aims to speed delivery, increase quality, reduce costs, and support scalable, efficient development.
Taking Release Management to the Next LevelXebiaLabs
The document discusses how release management needs to evolve to enable development and operations teams to deliver features and functions faster. It notes that while development and operations teams are adapting practices like DevOps and continuous delivery, release management practices have not kept up. The missing step is application release automation, which can help achieve both speed and quality by automating manual release processes and enabling controlled continuous value delivery. A demonstration of these capabilities will be provided.
Software release management involves overseeing the integration and flow of software development, testing, deployment, and support. A typical software release cycle includes pre-alpha, alpha, beta, release candidate, general release, and end of life phases. Release management ensures reliable planning, scheduling, and deployment of software releases to end users. It is a growing discipline important for coordinating activities between development, testing, and release teams and addressing challenges like software defects, changes, new features, and deployment risks across different platforms and environments. An effective release manager acts as a coordinator, gatekeeper, diplomat, and point of contact to balance requirements from various stakeholders and customers.
Here is the FMEA analysis for the LTE Release Management process:
1. Execute Patch Release Testing
- Incomplete testing due to time constraints
- Defects passed through to next stage
8
- Lack of test resources/capacity
- Complexity of software
- Timeboxed testing
7
- Test automation
- Peer review of test cases
6
336
2. Patch under Pilot
- Defects identified in Pilot phase
- Delays resolution and rollout
7
- Insufficient Pilot scope/scale
- Quality of testing prior to Pilot
6
- Staged Pilot rollout
-
General description of Release Management within an ITIL-based IT (Infra) Services organization. Find me at https://nl.linkedin.com/in/tijsvanvelthoven for more information
Release management is a software engineering process to oversee development, testing, deployment and support of software releases. The purpose is to ensure a consistent deployment method across projects. Key aspects include planning releases, testing, developing distribution procedures, and coordinating communication about releases. The Digité application provides a project-level release management module for robust planning and execution of releases with capabilities like adding, viewing, copying and tagging releases to items like defects.
Releases are risky. Often homegrown scripts, manual steps, and runbook orchestrations contribute to the risks involved with application releases.Having a controlled release process can strengthen release management by ensuring quality, reducing manual tasks, deploying applications consistently across environments, and more.Development teams, making the changes to meet customers’ needs, realized that they could not keep up with the increased demand. Many of those teams turned to Agile methodologies. Agile methodologies would help developers create a steady stream of features and solve customer’s problems as they arose. Agile solutions allowed developers to make rapid changes. However, organizations were unable to achieve the full benefit of Agile. Legacy deployment processes delayed the release of the applications because they were built for infrequent releases.
Technical briefing on Software Release PlanningGuenther Ruhe
One of the most critical activities in software product development is the decisional process that assigns features to subsequent releases under technical, resource, risk, and budget constraints. This decision-centric process is referred to as software release planning (SRP).
This briefing will expose a state of the art on SRP. A survey of the most relevant approaches will be presented. Emphasis will be made on their applicability (concerning e.g. type of development process and type of system, tool support and degree of validation in industry. One of these approaches, EVOLVE, will be analysed in detail.
The briefing is addressed to a wide audience. For researchers, an updated state of the art will be exposed, a particular method will be explored in depth, and the presentation will rely on scientific grounds. For practitioners, the practical dimension of SRP will be present. For educators, the briefing will provide the basis for developing course material.
The document outlines an effective software release management strategy with multiple layers and branching models. It discusses establishing rigorous development, build, test, and deployment cycles with common environments. It also recommends moving to continuous integration and deployment with tools and processes to support rapid defect detection. Higher level branches have stricter quality criteria than lower ones, with mainline and release branches intended for stable, tested code. The strategy aims to speed delivery, increase quality, reduce costs, and support scalable, efficient development.
Taking Release Management to the Next LevelXebiaLabs
The document discusses how release management needs to evolve to enable development and operations teams to deliver features and functions faster. It notes that while development and operations teams are adapting practices like DevOps and continuous delivery, release management practices have not kept up. The missing step is application release automation, which can help achieve both speed and quality by automating manual release processes and enabling controlled continuous value delivery. A demonstration of these capabilities will be provided.
Software release management involves overseeing the integration and flow of software development, testing, deployment, and support. A typical software release cycle includes pre-alpha, alpha, beta, release candidate, general release, and end of life phases. Release management ensures reliable planning, scheduling, and deployment of software releases to end users. It is a growing discipline important for coordinating activities between development, testing, and release teams and addressing challenges like software defects, changes, new features, and deployment risks across different platforms and environments. An effective release manager acts as a coordinator, gatekeeper, diplomat, and point of contact to balance requirements from various stakeholders and customers.
Here is the FMEA analysis for the LTE Release Management process:
1. Execute Patch Release Testing
- Incomplete testing due to time constraints
- Defects passed through to next stage
8
- Lack of test resources/capacity
- Complexity of software
- Timeboxed testing
7
- Test automation
- Peer review of test cases
6
336
2. Patch under Pilot
- Defects identified in Pilot phase
- Delays resolution and rollout
7
- Insufficient Pilot scope/scale
- Quality of testing prior to Pilot
6
- Staged Pilot rollout
-
General description of Release Management within an ITIL-based IT (Infra) Services organization. Find me at https://nl.linkedin.com/in/tijsvanvelthoven for more information
Release management is a software engineering process to oversee development, testing, deployment and support of software releases. The purpose is to ensure a consistent deployment method across projects. Key aspects include planning releases, testing, developing distribution procedures, and coordinating communication about releases. The Digité application provides a project-level release management module for robust planning and execution of releases with capabilities like adding, viewing, copying and tagging releases to items like defects.
Releases are risky. Often homegrown scripts, manual steps, and runbook orchestrations contribute to the risks involved with application releases.Having a controlled release process can strengthen release management by ensuring quality, reducing manual tasks, deploying applications consistently across environments, and more.Development teams, making the changes to meet customers’ needs, realized that they could not keep up with the increased demand. Many of those teams turned to Agile methodologies. Agile methodologies would help developers create a steady stream of features and solve customer’s problems as they arose. Agile solutions allowed developers to make rapid changes. However, organizations were unable to achieve the full benefit of Agile. Legacy deployment processes delayed the release of the applications because they were built for infrequent releases.
Release Management: Successful Software Releases Start with a Planconnielharper
This document discusses the importance of release planning for successful software releases. It notes that even with agile development, a release plan is needed to coordinate releasing software to users. The document outlines different types of release cycles including time-based, feature-based, and market demand-based. It also discusses factors to consider when deciding on a release cycle. Additionally, it provides details on what should be included in a release plan such as goals, features, milestones, responsibilities, dependencies, and risks. The document stresses the importance of communication and ensuring product readiness to have successful software releases.
The document discusses release management in BMC Remedy ITSM 7.6. It describes the release request lifecycle including stages like initiate, plan, build, test, deployment, and close down. It outlines roles like release coordinator, change manager, and activity assignee. It provides details on how to create release requests, add related change requests and activities, and move through the approval phases. The webinar aims to help users understand release management functionality in BMC Remedy.
Watch the recorded version of this Webinar here:
Curious about Continuous Integration? Tune in!
Continuous Integration (CI), which is a big part of continuous delivery, is the concept of continuously building and testing software using an automated process. We have learned that utilizing CI could help us catch bugs earlier, enable better visibility, reduce repetitive processes, enable the development team to produce deployable products at a moment's notice, and reduce risk overall.
These slides will identify the various levels of continuous integration and delivery with regards to a release maturity of the development team or parent organization.
1. Release automation is the missing step in release management that can significantly improve speed and reliability of deploying software changes.
2. Most organizations currently manage releases manually using complex scripts, which is time-consuming and error-prone.
3. Release automation tools eliminate the need for custom scripts and provide consistency, speed, and visibility to the deployment process.
Agile Release Management Best PracticesAnmol Oberoi
This document discusses best practices for agile release management for Salesforce admins. It recommends setting up a sandbox structure for different stages of development and testing. Key benefits of agile release management include more frequent releases with shorter response times to changes. Best practices include using version control, having rollback strategies, collaborating with others on reviews, and communicating schedules. It suggests adopting agile frameworks to release iteratively in time-boxed sprints. Overall, the document provides guidance on implementing agile processes and tools to streamline releases of Salesforce configurations and applications.
The document discusses software deployment principles and practices, outlining four key principles: repeatable builds, consistent environments, autonomous packages, and ease of doing/undoing releases. It provides details on each principle and how they can be achieved, such as through versioning of artifacts, baselining components together, and developing automated and documented processes.
The document provides an overview of various software development life cycle (SDLC) models including Waterfall, V-Shaped, Prototyping, Rapid Application Development (RAD), Incremental, Spiral, Agile approaches like Extreme Programming (XP) and Feature Driven Development (FDD). It describes the key phases, strengths, weaknesses and scenarios where each model is best suited. The SDLC models range from traditional plan-driven to more adaptive approaches and the choice of model depends on project factors like requirements, risks, schedules and team preferences.
The document discusses automation testing and provides guidelines for different types of testing including unit testing, API testing, end to end testing, load testing, and security testing. It outlines the automation testing process, including writing test cases, developing automated tests, integrating tests into the development pipeline, and continuously monitoring tests. Developers focus on happy path scenarios while testers cover all scenarios.
Automation of Release and Deployment Management - MavericMaveric Systems
This presentation highlights why automation platforms for application release and deployment are becoming increasingly vital for global enterprises and explores the specific requirements of such a platform in order for it to prove beneficial, effective and offer a substantial return on investment.
This document discusses release cycles and delivery roadmaps. It provides guidance on designing well-balanced release cycles that consider constraints. Key points include defining a catalog of release cycles for different user story families, qualifying development steps as value-added or non-value added, assessing current cycles based on workload and lead time, and leveraging techniques like parallelization, continuous integration, and continuous improvement to reduce lead times. The goal is to balance steps for an acceptable ROI and define SLAs for each user story family's release cycle.
Release engineering involves managing the delivery of high quality software releases through processes like release planning, branch management, building, testing, and source code control. It aims to make releases predictable and of high quality by facilitating activities such as compiling code, verifying functionality, controlling branching/merging of codelines, and following best practices.
Software Development Process Models (SCRUM Methodology)Muhammad Ahmed
This document provides an overview of software process models and Scrum methodology. It defines a software process model as a description of the sequence of activities carried out in a software engineering project. The key activities include specification, design & implementation, validation, and evolution. Scrum is introduced as an agile software development framework. It utilizes short development cycles called sprints, daily stand-up meetings, product backlogs to track requirements, and emphasizes self-organizing teams and adaptive planning. The benefits of Scrum are discussed as improved productivity, quality, and ability to manage changing requirements.
Agile and DevOps, when integrated into business process, can empower organizations to drive CI In support of market demands, in a significantly efficient and cost effective manner.
The waterfall model is a sequential software development model where progress flows in one direction like a waterfall from conception to maintenance. It involves 6 phases - definition/analysis, basic design, technical design, construction, testing, and integration/maintenance. The waterfall model is easy to use but inflexible to changes in requirements, which is a common occurrence. It assumes requirements will not change once the process begins.
The document discusses various software production process models, including traditional waterfall models, iterative models like the spiral model, and agile methodologies. Waterfall models involve sequential phases from requirements to maintenance but lack flexibility. Iterative models divide the process into increments with feedback between phases. Agile methods like Scrum, Extreme Programming, and Smart emphasize rapid, incremental delivery, automating processes, and customer involvement. The choice of model depends on factors like requirements volatility, team experience, and project priorities.
This document provides an overview of Azure DevOps and how it can benefit developers. It discusses key features such as source control, work item tracking, continuous integration and delivery pipelines, and how SQL Server Data Tools can be used. The presenter has over 20 years of experience in technology and is a Microsoft MVP. They provide a demonstration of using Azure DevOps and SSDT for a database project. Resources for learning more are also included.
Building Scalable Development EnvironmentsShahar Evron
The document provides guidelines for building scalable development environments in 3 main areas:
1. Establish standard programming styles and coding practices to reduce bugs and improve readability. This includes using source control, peer review, and coding standards.
2. Implement a multi-tier environment with separate development, staging, and production servers to allow for testing at each stage.
3. Employ practices like unit testing, functional testing, and benchmarking to ensure quality and performance as the system grows.
Release Management: Successful Software Releases Start with a Planconnielharper
This document discusses the importance of release planning for successful software releases. It notes that even with agile development, a release plan is needed to coordinate releasing software to users. The document outlines different types of release cycles including time-based, feature-based, and market demand-based. It also discusses factors to consider when deciding on a release cycle. Additionally, it provides details on what should be included in a release plan such as goals, features, milestones, responsibilities, dependencies, and risks. The document stresses the importance of communication and ensuring product readiness to have successful software releases.
The document discusses release management in BMC Remedy ITSM 7.6. It describes the release request lifecycle including stages like initiate, plan, build, test, deployment, and close down. It outlines roles like release coordinator, change manager, and activity assignee. It provides details on how to create release requests, add related change requests and activities, and move through the approval phases. The webinar aims to help users understand release management functionality in BMC Remedy.
Watch the recorded version of this Webinar here:
Curious about Continuous Integration? Tune in!
Continuous Integration (CI), which is a big part of continuous delivery, is the concept of continuously building and testing software using an automated process. We have learned that utilizing CI could help us catch bugs earlier, enable better visibility, reduce repetitive processes, enable the development team to produce deployable products at a moment's notice, and reduce risk overall.
These slides will identify the various levels of continuous integration and delivery with regards to a release maturity of the development team or parent organization.
1. Release automation is the missing step in release management that can significantly improve speed and reliability of deploying software changes.
2. Most organizations currently manage releases manually using complex scripts, which is time-consuming and error-prone.
3. Release automation tools eliminate the need for custom scripts and provide consistency, speed, and visibility to the deployment process.
Agile Release Management Best PracticesAnmol Oberoi
This document discusses best practices for agile release management for Salesforce admins. It recommends setting up a sandbox structure for different stages of development and testing. Key benefits of agile release management include more frequent releases with shorter response times to changes. Best practices include using version control, having rollback strategies, collaborating with others on reviews, and communicating schedules. It suggests adopting agile frameworks to release iteratively in time-boxed sprints. Overall, the document provides guidance on implementing agile processes and tools to streamline releases of Salesforce configurations and applications.
The document discusses software deployment principles and practices, outlining four key principles: repeatable builds, consistent environments, autonomous packages, and ease of doing/undoing releases. It provides details on each principle and how they can be achieved, such as through versioning of artifacts, baselining components together, and developing automated and documented processes.
The document provides an overview of various software development life cycle (SDLC) models including Waterfall, V-Shaped, Prototyping, Rapid Application Development (RAD), Incremental, Spiral, Agile approaches like Extreme Programming (XP) and Feature Driven Development (FDD). It describes the key phases, strengths, weaknesses and scenarios where each model is best suited. The SDLC models range from traditional plan-driven to more adaptive approaches and the choice of model depends on project factors like requirements, risks, schedules and team preferences.
The document discusses automation testing and provides guidelines for different types of testing including unit testing, API testing, end to end testing, load testing, and security testing. It outlines the automation testing process, including writing test cases, developing automated tests, integrating tests into the development pipeline, and continuously monitoring tests. Developers focus on happy path scenarios while testers cover all scenarios.
Automation of Release and Deployment Management - MavericMaveric Systems
This presentation highlights why automation platforms for application release and deployment are becoming increasingly vital for global enterprises and explores the specific requirements of such a platform in order for it to prove beneficial, effective and offer a substantial return on investment.
This document discusses release cycles and delivery roadmaps. It provides guidance on designing well-balanced release cycles that consider constraints. Key points include defining a catalog of release cycles for different user story families, qualifying development steps as value-added or non-value added, assessing current cycles based on workload and lead time, and leveraging techniques like parallelization, continuous integration, and continuous improvement to reduce lead times. The goal is to balance steps for an acceptable ROI and define SLAs for each user story family's release cycle.
Release engineering involves managing the delivery of high quality software releases through processes like release planning, branch management, building, testing, and source code control. It aims to make releases predictable and of high quality by facilitating activities such as compiling code, verifying functionality, controlling branching/merging of codelines, and following best practices.
Software Development Process Models (SCRUM Methodology)Muhammad Ahmed
This document provides an overview of software process models and Scrum methodology. It defines a software process model as a description of the sequence of activities carried out in a software engineering project. The key activities include specification, design & implementation, validation, and evolution. Scrum is introduced as an agile software development framework. It utilizes short development cycles called sprints, daily stand-up meetings, product backlogs to track requirements, and emphasizes self-organizing teams and adaptive planning. The benefits of Scrum are discussed as improved productivity, quality, and ability to manage changing requirements.
Agile and DevOps, when integrated into business process, can empower organizations to drive CI In support of market demands, in a significantly efficient and cost effective manner.
The waterfall model is a sequential software development model where progress flows in one direction like a waterfall from conception to maintenance. It involves 6 phases - definition/analysis, basic design, technical design, construction, testing, and integration/maintenance. The waterfall model is easy to use but inflexible to changes in requirements, which is a common occurrence. It assumes requirements will not change once the process begins.
The document discusses various software production process models, including traditional waterfall models, iterative models like the spiral model, and agile methodologies. Waterfall models involve sequential phases from requirements to maintenance but lack flexibility. Iterative models divide the process into increments with feedback between phases. Agile methods like Scrum, Extreme Programming, and Smart emphasize rapid, incremental delivery, automating processes, and customer involvement. The choice of model depends on factors like requirements volatility, team experience, and project priorities.
This document provides an overview of Azure DevOps and how it can benefit developers. It discusses key features such as source control, work item tracking, continuous integration and delivery pipelines, and how SQL Server Data Tools can be used. The presenter has over 20 years of experience in technology and is a Microsoft MVP. They provide a demonstration of using Azure DevOps and SSDT for a database project. Resources for learning more are also included.
Building Scalable Development EnvironmentsShahar Evron
The document provides guidelines for building scalable development environments in 3 main areas:
1. Establish standard programming styles and coding practices to reduce bugs and improve readability. This includes using source control, peer review, and coding standards.
2. Implement a multi-tier environment with separate development, staging, and production servers to allow for testing at each stage.
3. Employ practices like unit testing, functional testing, and benchmarking to ensure quality and performance as the system grows.
SynapseIndia Drupal development
SynapseIndia Ecommerce development
SynapseIndia Sharepoint development
SynapseIndia PHP development
SynapseIndia Dotnet development
SynapseIndia Magento development
SynapseIndia MS Dynamic CRM
SynapseIndia Complaints
SynapseIndia Reviews
This document provides an overview of Visual Studio .NET 2005, including its various editions, new features, and system requirements. It discusses the Express, Standard, and Professional editions. Key new features include code snippets, refactoring tools, and improved debugging capabilities. The document also announces upcoming .NET events and links to additional information resources.
The document discusses best practices for database development and deployment. It recommends having identical environments for development, testing, and production to enable easy comparisons. This allows issues to be detected and fixed before production deployment. It also suggests using tools that track database changes and compare schemas to simplify environments and ensure consistency across stages. Regular practice deployments in non-production environments are advised to work out any issues before changes reach production.
The document discusses software project failures and the benefits of using an integrated platform like Visual Studio Team System (VSTS) for software development. It notes that on average in 2000-2004, software projects were 45% over budget, 63% over schedule, and only delivered 67% of planned functionality. VSTS provides features like version control, work item tracking, build automation, and reporting that help improve collaboration, accountability, visibility and quality of software projects. It discusses how one company saw a 225% ROI and 6 month payback by deploying VSTS across their development teams.
The document provides an overview of Azure DevOps and why JavaScript developers should use it. It discusses features like source control, boards for tracking work items, pipelines for continuous integration and delivery, and testing. It also includes a demo of setting up a sample Create React App project in Azure DevOps, including configuring a pipeline to build and deploy the app to an Azure App Service. Resources for learning more about Azure DevOps, using it with JavaScript projects, and understanding Git are also provided.
Automated Builds And UI Testing in SharePoint 2010 DevelopmentChris O'Brien
Shows how to introduce automated builds and UI testing to SharePoint 2010 development projects. Team Foundation Server 2010 is used as the build platform. Includes coverage of VS2010 features such as code profiling, IntelliTrace etc.
Best practices for share point solution deploymentSalaudeen Rajack
This document provides best practices for deploying SharePoint solution packages. It discusses what solution packages are and how they can be used to package and deploy custom features, site definitions, master pages and other components. It also covers the solution development lifecycle and tools for creating solutions, as well as how to deploy, retract, upgrade and manage solutions. Checklists are provided to help ensure solutions are properly tested, documented and deployed.
Upgrade to SharePoint 2010, Shai Petel SharePoint Conference Las Vegas Sep 2009KWizCom Team
KWizCom's Shai Petel discusses upgrading to SharePoint 2010, using his experience of upgrading KWizCom's SharePoint List Forms Extension Feature to SharePoint 2010 as an example
This document summarizes an upcoming tour by Kevin Schroeder of Zend Technologies to discuss various topics including:
- An introduction to Kevin and what he does at Zend
- An overview of Zend products like Zend Framework and Zend Server
- A discussion of performance, scalability, and queuing in PHP applications
- A demonstration of using the Zend Server job queue to asynchronously process tasks
- Considerations for deploying PHP applications in different environments like development, testing, staging, and production
Continuous Integration and the Data Warehouse - PASS SQL Saturday SloveniaDr. John Tunnicliffe
Continuous integration is not normally associate with data warehouse projects due to the perceived complexity of implementation. John shows how modern tools make it simple to apply CI to the data warehouse. The session covers:
* The benefits of the SQL Server Data Tools declarative model
* Using PowerShell and psake to automate your build and deployments
* Implementing the TeamCity build server
* Integration and regression testing
* Auto-code generation within SSDT using T4 templates and DacFx
Continuous Integration and the Data Warehouse - PASS SQL Saturday SloveniaDr. John Tunnicliffe
Continuous integration is not normally associate with data warehouse projects due to the perceived complexity of implementation. John shows how modern tools make it simple to apply CI to the data warehouse. The session covers:
* The benefits of the SQL Server Data Tools declarative model
* Using PowerShell and psake to automate your build and deployments
* Implementing the TeamCity build server
* Integration and regression testing
* Auto-code generation within SSDT using T4 templates and DacFx
APEX Application Lifecycle and Deployment 20220714.pdfRichard Martens
APEX application deployment is mostly done by exporting the application and importing it into the target environment.
But what if your team continuously develops (as they should), where do you stop developing to start preparing your release-deployment? You should be able to deploy based on features; without your developers having to halt their development.
Using the deployment-method explained in this presentation you will be able to do just that.
The method includes things like Code versioning (GIT), Feature-tickets (Jira), Code Review (Quality), Automated Deployment using Jenkins and Flyway. When implemented you will be able to successfully and predictively deploy your APEX applications (including underlying database objects) to the different deployment-environments.
With a few modifications you can even upgrade the methodology to be a "continuous delivery" methodology.
Feature Based Web Development with Bazaaryogomozilla
We take a look at feature based development using Bazaar. We cover version control evolution, what a feature is, how to develop features rathr than file changes and finally providing those features for provisioning of your web app!
Alm Specialist Toolkit Team System Roadmap 2008 And Beyond ExternalChristian Thilmany
This document summarizes new and upcoming features across multiple versions of Visual Studio Team System/TFS, including 2008, SP1, and the "Rosario" release. Key areas discussed include testing, continuous integration, code analysis, database tools, and administration improvements around scale and performance. The document provides an overview of the timeline and focus for each release.
DevOps aims to bring development and operations teams closer together through automation, shared tools and processes. Automating builds improves consistency, reduces errors and improves productivity. Common issues with builds include them being too long, handling a large volume, or being too complex. Solutions include improving build speed, addressing long/complex builds through techniques like distributed builds, and using build acceleration tools. Automation is a key part of DevOps and enables continuous integration, testing and deployment.
2. “ Release Management can be a complex topic, so any attempt to cover it in a single article would be a mistake.”, by Mike Drupeau and Sudesh Oudi ( “Release Management: Where to Start” , article)
ESTA APRESENTAÇÃO TEM COMO OBJECTIVO FALAR DA MINHA EXPERIÊNCIA EM TERMOS DE RELEASE MANAGEMENT . SITUAÇÕES QUE CORRERAM BEM . SITUAÇÕES QUE CORRERAM MENOS BEM PERCEBER TAMBÉM COM VOCÊS QUAL A VOSSA ABORDAGEM EM TERMOS DE RELEASE MANAGEMENT
Release Management é um tema bastante complexo, pelo que um documento/apresentação é insuficiente para o cobrir na totalidade
RM é todo o processo de planeamento, build, teste e deploy de software
Garantir que existe um método consistente de deployment a ser seguido (criar linhas de orientação) Manter os vários ambientes estáveis, i.e., não introduzir erros sempre que há releases
Durante o suporte poderão surgir novos requisitos ou bug fixes, pelo que o ciclo irá iniciar-se!!!
O sistema apenas pode seguir o rasto de um ambiente de trabalho que esteja a ser gerido pela ferramenta de gestão de versões CASO ESTEJA A TRABALHAR FORA NÃO EXISTE QUALQUER VISIBILIDADE SOBRE O TRABALHO QUE O PROGRAMADOR SE ENCONTRA A EFECTUAR!!! 2. O AMBIENTE DE TRABALHO DEVERÁ MANTER-SE SEMPRE ACTUALIZADO EM RELAÇÃO ÀS VERSÕES QUE SE ENCONTRAM CHECKED IN (PRETENDE-SE TER SEMPRE A ÚLTIMA VERSÃO DOS MÓDULOS A ALTERAR, PARA NÃO EFECTUAR ALTERÇÕES SOBRE VERSÕES ERRADAS) PARECE UMA REGRA SIMPLES … MAS ACREDITEM QUE NEM SEMPRE É SEGUIDA!!! 3. NO CASO DE TERMOS A FERRAMENTA DE VC CONFIGURADA PARA EXCLUSIVE CHECK OUT => EVITA QUE OUTROS PROGRAMADORES FIQUEM BLOQUEADOS À ESPERA DO VOSSO CHECK IN CASO CONTRÁRIO => EVITA OS MERGES (ALGUM CUSTO)
SER ESCLARECEDOR QUANTO A REGRAS DESENVOLVIMENTO => APÓS CADA CHECK IN INTRODUZIR NO DOCUMENTO DE RELEASE A VERSÃO E O BUG FIZ ASSOCIADO BRANCHING => APENAS SE EFECTUA BRANCH SE FOR UMA NOVA “FEATURE” MAINLINE É O “TRONCO” PRINCIPAL DE CÓDIGO QUE EVOULUI “ETERNAMENTE”, I.E., É SOBRE A MAINLINE QUE SE EFECTUAM OS BRANCHES QUANDO UM BRANCH É TERMINADO E DEPLOYED É PROPAGADO NOVAMENTE PARA A MAINLINE, DE FORMA AO PRÓXIMO BRANCH SER SOBRE A “NOVA” MAINLINE O RELEASE MANAGER TEM COMO FUNÇÃO GARANTIR A CORRECTA EXECUÇÃO DO PROCESSO DE BUILD POR EXEMPLO, NOVOS MÓDULOS IMPLICAM ACTUALIZAÇÃO DO PROCESSO PARA INCLUSÃO DO MESMO GARANTIR QUE OS PROGRAMADORES PERCEBEM A IMPORTÂNCIA DO BUILD … PASSAR RESPONSABILIDADE (E.G., PAGAR SE O BUILD FALHAR)
. + branches => + builds, + propagação alterações, + merges . Vantagem: incluir no branch o máximo das alterações já presentes na mainline . E.g., se é criado 1 branch e depois é identificado 1 bug fix, esse branch não terá incluído esse bug fix na passagem, pelo que é inevitável 1 merge! . “branch late” mas não muito tarde, i.e., da criação desse branch não deverá estar outro desenvolvimento pendente … NESSE CASO DEVERÁ FAZER-SE O BRANCH!
. PRETENDE-SE GARANTIR QUE OS BUILDS SÃO IGUAIS … IMPORTANTE AQUANDO DE IDENTIFICAÇÃO DE ERROS . IDEALMENTE: 1 CHECK IN => 1 BUILD || IDEAL EM PROJECTOS: 1 VEZ POR NOIT . IMPORTANTE PARA DETECÇÃO ATENCIPADA DE ERROS . PARA SE IDENTIFICAREM OS MÓDULOS QUE FALHARAM … O ÚLTIMO BUILD COM SUCESSO … QUAIS OS FICHEIROS QUE PROVOCARAM O(S) ERRO(S) …
guarantee that there are no 2 developers working in the same file . NÃO TEMOS QUALQUER RESTRIÇÃO ADICIONAL
ATENÇÃO QUE ESTA É A NOSSA SOLUÇÃO ACTUAL, NÃO NECESSÁRIAMENTE A QUE GOSTARÍAMOS DE TER . EXEMPLO, GOSTARÍAMOS DE TER UM BUILD DA BD MAS POR QUESTÕES HISTÓRICAS DO PROJECTO ISSO NUNCA CHEGOU A SER IMPLEMENTADO . ESTAS REGRAS FORAM IMPLEMENTADAS DESDE O INÍCIO DO PROJECTO
. IDENTIFICAR SEMPRE OS SPs E TABELAS NOVOS COM O BUG FIX OU NOVA FEATURE ASSOCIADA . TABELA CRIADA/MODIFICADA => CÓDIGO GERADO AUTOMATICAMENTE PELO SQL SERVER
. IDENTIFICAR SEMPRE OS SPs E TABELAS NOVOS COM O BUG FIX OU NOVA FEATURE ASSOCIADA . TABELA CRIADA/MODIFICADA => CÓDIGO GERADO AUTOMATICAMENTE PELO SQL SERVER
ESTAS SÃO AS NOSSAS PRINCIPAIS REGRAS DE DESENVOLVIMENTO WEB
QUANDO O CICLO DE DEPLOYMENT SE PROCESSA ASSIM, COM AS REGRAS ATRÁS REFERIDAS, NÃO HÁ QUALQUER TIPO DE PROBLEMA NAS RELEASES . N PACOTES QUA -> 1 PACOTE PRD
HÁ DIFERENÇAS EM RELAÇÃO AO CICLO ANTERIOR, QUE VÃO IMPLICAR NÃO LINEARIDADE NO PROCESSO DE CRIAÇÃO DA RELEASE … ..
OS PONTOS INDICADOS A VERMELHO SÃO OS PONTOS CRÍTICOS DO PROCESSO . RAZÃO: VAI PASSAR PARA PRD APENAS O QUE FOI ACEITE PELO SPONSOR, NO ENTANTO NÃO É TUDO O QUE SE ENCONTRA EM QUA (VAI APENAS PASSAR UMA PARTE DO QUE SE ENCONTRA EM QUA)
. New features and bug fixes were included in the patch file if the release was in the same day . 1 RELEASE => 1 SQL PATCH Headache to decide and test what to deploy
Headache to decide and test what to deploy
NOVOS BRANCHES SÃO SEMPRE SOBRE A MAINLINE QUE TERÁ O ÚLTIMO BRANCH DEPLOYED INCLUÍDO
CRIAR BRANCH APENAS SE NÃO SOUBERMOS QUANDO IRÁ SER DEPLOYED PARA PRD Existem AINDA ALTERAÇÕES QUE APENAS SE ENCONTRAM EM QUA E AINDA NÃO FORAM APROVADAS PELO SPONSOR PARA PASSAR PARA PRD … PARA PODERMOS LIMPAR O CÓDIGO DAS PASSAGENS EXISTENTE
CRIAR BRANCH APENAS SE NÃO SOUBERMOS QUANDO IRÁ SER DEPLOYED PARA PRD Existem AINDA ALTERAÇÕES QUE APENAS SE ENCONTRAM EM QUA E AINDA NÃO FORAM APROVADAS PELO SPONSOR PARA PASSAR PARA PRD … PARA PODERMOS LIMPAR O CÓDIGO DAS PASSAGENS EXISTENTE