Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Low-Code/No-Code Application Development – Putting Users in Control

    Low-Code/No-Code Application Development – Putting Users in Control

    Not long ago, it wasn’t uncommon for a new application deployment to take a year or more. Today, that timeframe is measured in weeks. What has changed?

    For many enterprises, traditional, full-code waterfall application development, with its focus on a sequential define-develop-test-deploy-maintain approach, has given way to low-code/no-code development, a faster, more accessible method for developing and modifying applications using intuitive tools without extensive coding. Low-code and no-code development systems fulfill ever-increasing demands for fast application delivery and highly customized automation workflows.

    In addition to putting control back in the hands of users who know their needs best, low-code and no-code systems are also credited with improving developer productivity by enabling professional developers to streamline aspects of the development process.

    According to Gartner, the no-code/low-code platform market is forecast to grow almost 20% in 2023 to $10 billion and reach $12.3 billion in 2024. This growth is not surprising when you consider the following:

    • Tech Talent Shortage. The market for low-code/no-code platforms is driven in large part by a global shortage of skilled software developers, a situation that is expected to continue throughout this decade. Low-code/no-code platforms enable companies to quickly get development projects off the ground without the need for professional developers.
    • Focus on Cost. As companies become ever more mindful of their tech spend, low-code/no-code solutions can offer an accelerated, less expensive alternative to custom software development, which involves professional developers, longer development cycles and more comprehensive support programs.
    • Need to Reduce IT Backlogs. Low-code/no-code is also having a significant impact by reducing application enhancement backlogs in IT departments and application requests from end users that haven’t yet been addressed. In many companies, this backlog is years long. With no-code/low-code, users can actually create and/or modify applications themselves rather than waiting in a queue for their needs to be addressed.
    • Agile Development. Many companies today follow the Agile methodology of software development, where teams work together in incremental cycles to continuously improve. Key drivers of Agile development are flexibility and speed. Low-code/no-code application development can empower those teams with a faster approach to continuous software development based upon pre-defined elements and templates and drag-and-drop interfaces.
    • Growth in Cloud-Native Applications. Growth in low-code/no-code is driven in part by the increased adoption of cloud-native technologies as organizations rapidly embrace the benefits and availability of the cloud. The advantages of cloud-native software development include increased agility, lower hosting costs, faster time to market and improvements to user experience.

    Understand the Landscape and the Limitations

    While low-code/no-code development is on the rise, helping companies roll out almost-ready-made solutions quickly, cost-effectively and with less risk, it is essential to understand that it can come with sacrifices to scalability, flexibility and integration with existing tools.

    Solutions won’t always have a customized front end, they may not have industry-first capabilities, and they’re often viewed as software commodities. Yet, maybe it isn’t always about the technology that drives the outcome but the user experience it delivers.

    One of the hallmarks of a successful organization is striking the right cost/benefit balance. For today’s organizations, faced with labor shortages, tight profit margins and a need for speed, knowing when heavy-lifting custom software development is required and when low-code/no-code offers a better, more cost-effective approach can mean the difference between success and failure.

  • 5 Effective Git Workflows to Streamline Your Development Process

    5 Effective Git Workflows to Streamline Your Development Process

    In the fast-paced world of software development, efficient collaboration and version control are vital for successful project management. Git, a distributed version control system, offers various workflows to facilitate seamless collaboration among team members. Each workflow is designed to address specific development needs and enhance productivity. In this blog post, we will explore five popular Git workflows and discuss their significance in the software development process. 

    Centralized Workflow

    The centralized workflow is a simple and straightforward approach commonly used in small teams or projects. In this workflow, a central repository acts as a single source of truth for the project. Developers clone the repository, make changes in their local branches and push their changes to the central repository for integration. This workflow is easy to understand and implement, making it ideal for beginners. It promotes a linear development process, making it easier to track changes and maintain code consistency. 

    Feature Branch Workflow

    The feature branch workflow is widely adopted in larger development teams. It enables parallel development and promotes the isolation of work. Each feature or task in this workflow is given a specific branch. Developers work on their features, branch off from the main branch, and submit updates to the remote repository. Once the feature is complete, it undergoes code review and is merged back into the main branch. This workflow allows for better collaboration as developers can work independently on separate branches without interfering with each other’s progress. 

    Gitflow Workflow

    The gitflow workflow is a robust and well-defined branching model that is particularly useful for projects with multiple release cycles and long-term maintenance. It incorporates two main branches: The “master” branch for stable releases and the “develop” branch for ongoing development. Developers create feature branches from the “develop” branch, work on their features, and merge them back into “develop” for integration testing. Once the code in “develop” is ready, it is merged into the “master” branch for a new release. This workflow ensures a structured and controlled release process, making it easier to manage versioning and hotfixes. 

    Forking Workflow

    The forking workflow is commonly used in open source projects and promotes collaboration among multiple contributors. In this workflow, each developer creates a personal fork of the main repository. They make changes in their forked repository, create a pull request to propose changes and undergo a review process. The changes can then be merged into the main repository by the project maintainers. This workflow allows for a clear separation of duties and provides a controlled mechanism for accepting contributions from external developers. 

    Release Flow Workflow

    The release flow workflow is well-suited for projects that require frequent releases and hotfixes. It combines the concepts of the feature branch and gitflow workflows. The main difference lies in the way releases are managed. In this workflow, a dedicated release branch is created for each release. Once the release is ready, it is merged into both the “master” and “develop” branches. This workflow allows for efficient bug fixes and maintenance, ensuring that critical updates are quickly propagated to the main development branch. 

    Why Are These Workflows Needed? 

    Efficient Collaboration: Git workflows provide structure and guidelines for collaboration, enabling developers to work in parallel without conflicts. They facilitate seamless communication and code integration, fostering teamwork and productivity. 

    Code Consistency and Quality: By following established workflows, developers can ensure code consistency and maintain high-quality standards. Workflows enable code review processes, catching potential issues early and reducing the risk of introducing bugs into the main codebase. 

    Traceability and Version Control: Git workflows provide a clear history of changes, allowing developers to trace back and understand the evolution of the codebase. They enable easy rollbacks and provide a reliable version control system, safeguarding against accidental data loss. 

    Streamlined Releases and Hotfixes: Workflows like gitflow and release flow are specifically designed to streamline the release process, making it easier to manage versioning, hotfixes, and long-term maintenance. These workflows ensure that stable releases are delivered promptly and critical updates are quickly deployed. 

    Conclusion 

    Git workflows are powerful tools that help streamline the software development process. Whether you’re a small team or a large enterprise, adopting the right workflow can significantly improve collaboration, code quality, and overall productivity. From the centralized simplicity to the structured gitflow model, each workflow serves a specific purpose and caters to different project requirements. By leveraging the appropriate workflow, developers can navigate the complexities of version control and empower their teams to deliver exceptional software. 

  • Microsoft kills Python 3.7 ¦ … and VBScript ¦ Exascaling ARM on Jupiter

    Microsoft kills Python 3.7 ¦ … and VBScript ¦ Exascaling ARM on Jupiter

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: VS Code drops support for Python 3.7, Windows drops VBScript, and Europe plans the fastest ARM supercomputer. (more…)

  • The Ultimate Measure of Software Development Effectiveness

    The Ultimate Measure of Software Development Effectiveness

    There is a famous quote by Peter Drucker that states, “You can’t manage what you can’t measure.” In our industry, measuring how quickly we can get working software into the hands of our customers has become a mantra for agile development teams, and it’s even being talked about in the boardrooms.

    Customers measure the value of software by how quickly it can solve their problems. Customer needs change constantly. Just like us, they are responding to the needs of their own customers. Reacting quickly to customer feedback and turning that feedback into working features is key to customer satisfaction and retention.

    Having these directives in mind, it’s no wonder our teams are being asked to deliver working software sooner. Often, the main roadblock in achieving this goal lies not in developing the features but in getting them deployed.

    Let’s focus on three areas that determine your team’s deployment performance, which, in turn, directly impacts your software development effectiveness.

    1. Frequency of Deployments

    When I meet developers, I ask them a simple question: How often do you typically commit your code? A typical answer is a few times a day or even a few times per hour. However, if you ask the same person a question about how often their application is deployed to production, the answer varies widely.

    Some will say weekly or daily or still – very rarely – even a few times a day, which is software development nirvana. However, a more common answer is monthly or quarterly. I’m also not surprised if someone says that they release annually. They say it with an honest level of pride and accomplishment.

    Let’s put these two things – code commit and deployment frequency – into a broader perspective. If the goal of measuring software development effectiveness is getting working software into the hands of the users, it doesn’t matter how often you commit your code but how often you can give your users new value.

    Delivering small improvements to your customers has more impact on client satisfaction than giving them a big gift (new release) once a year.

    2. The Control of the ‘Launch’ Button

    Triggering a deployment includes someone instructing a deployment, pushing a “deploy” button, or committing triggered deployments. How many people in your organization can promote the application to a production environment? If this privilege is limited to a single person or just a handful of people – we have a problem.

    There are many reasons you might want to limit access to production. It could be because you don’t have safety measures built into your deployment process, such as role-based access control. You may believe in the delusion that you can protect your organization just by having fewer people with access to the production environment.

    The reality is that artificially limiting user access to production significantly reduces your chances of deploying frequently. Imagine if the “person in charge” must take a sick day or is traveling. Remember that access to the production environment is also required for bug fixes when your organization applies a fix-forward versus rollback strategy.

    3. The Level of Deployment Automation

    Measuring software development performance is directly correlated to the level of process automation. You can’t manually deploy to hundreds or thousands of customers in a reasonable amount of time. The manual process does not scale, as time is the one thing we can stretch.

    Ask yourself: Is your deployment process manual, partly automated (where parts of the process are automated, such as scripts that can be triggered to perform application deployment tasks), or can you claim that you fully automated your deployment process where there is no manual intervention, apart from push-button approvals.

    The more you automate your deployment process, the more productive your development team can be. For complex deployments, you may need to target many customers, sets of infrastructure or even physical locations. You might need to apply different configurations or hit agreed maintenance windows for customers or regions. One way to accelerate software delivery for these scenarios is tenanted deployments.

    Tenanted deployments capture these differences and apply them to a shared deployment process, allowing the complexity to be automated. You can manage tenanted deployments with tags, variables and customizations while reducing the cognitive load for team members.

    There are many ways deployment frequency impacts software development effectiveness. When you deploy more often, you reduce deployment risk, increase quality and get feedback sooner. One action you can take to reduce batch sizes is to increase deployment frequency. Smaller batch sizes will also allow you to recover faster when a problem arises.

    Remember that the longer the time between deployments, the more changes and points of failure build up.

    As you think about ways to increase software development effectiveness, think about the deployment process as a way to get close to the ultimate measure of developer success–getting the working software into the hands of customers sooner!


    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

  • Using DORA Metrics to Measure DevOps Success

    Using DORA Metrics to Measure DevOps Success

    The DevOps Research and Assessment (DORA) metrics have fundamentally changed how leaders interact with developers—and, in turn, how developers interact with their code. Although these metrics have changed significantly since their introduction in 2014, their intent remains to provide a numbers-based approach to improving the developer experience.

    DORA metrics play a critical role in many development workflows. These metrics posit that four focus areas—deployment frequency, lead time for changes, change failure rate, time to restore service and reliability—can differentiate high-performing software engineering teams (elites) from lower-performing teams (non-elites).

    Why is this a meaningful difference? High-performing teams reliably achieve faster time-to-market by removing menial tasks from their workload and expediting the development and deployment processes. Elite teams provide a better customer experience, deploy robust code faster and maintain better availability. And engineering teams that codify their procedures and track using DORA metrics are more likely to achieve these results in a shorter time frame.

    Why are DORA Metrics the Baseline for Many Developers?

    Most departments have tangible objectives and key results (OKRs) to present to executives. For example, the finance department typically looks to achieve a certain revenue threshold, while the marketing department may report on social media traffic or engagement.

    Software engineers have spent years grappling with how to demonstrate success to non-engineering departments. Although it’s relatively easy to identify when a deployment goes wrong, many developers have difficulty translating how these breakdowns occur. Engineering teams cannot generate buy-in for necessary process improvements or tool adoptions without the vernacular to discuss success benchmarks.

    DORA metrics provide a language for developers to use when speaking with executives and other teams. Moreover, DORA metrics enable developers to understand their process’ weak points and identify areas for improvement internally.

    Making the Most of DORA in 2023

    It’s incredibly frustrating to fall short of development goals or hit roadblocks like post-deployment errors and bugs. DORA metrics are the secret to circumventing these challenges. Here’s how DORA can go beyond codification to help your team achieve quicker, more reliable development and deployment:

    Accelerate Time to Market

    Tracking DORA metrics can significantly curb a team’s time to market—a key competitive advantage in the fast-paced world of software development. Enterprises that deploy more quickly and frequently accrue greater revenue over time than less efficient enterprises.

    A streamlined deployment process looks different from organization to organization. That is why DORA metrics are essential; they pinpoint each organization’s specific areas of improvement, enabling DevOps leaders to make informed decisions about remediation. Common indicators for lagging time to market include non-orchestrated deployment processes and manual testing procedures, which distract developers from what they do best: coding.

    Leaders looking to isolate issues with time to market should scrutinize their organization’s deployment frequency, as this metric can indicate process inefficiencies. Deploying irregularly? Your team may be batching too many updates, leading to overloaded, riskier deployments. Alternatively, infrequent updates may mean your organization has outgrown manual deployments. If that’s the case, consider adopting continuous integration and deployment (CI/CD) processes—these offerings improve time-to-market through immediate feedback and automated testing. Successful CI/CD implementations are proven to increase daily deployments by over 1000%.

    Improve Development Processes

    Although highly interconnected, deployment and development delays stem from different issues. Think of it this way: Low-performing engineering teams might deploy frequently—several times a day, even—but without quality assurance, those deployments are likely erroneous and may lead to extended system downtime.

    DORA metrics are a powerful way to isolate deployment issues from gaps in the development process. For example, an engineering team that tracks DORA may find their deployment frequency optimal, but their time to restore service and change failure rate lagging. This discrepancy indicates the team needs to improve its testing practices by rigorously reviewing code and managing application dependencies better. Additionally, the team should consider implementing more advantageous deployment and rollback processes, including but not limited to progressive deployments and automated rollbacks.

    Remove Menial Tasks From the Workload

    Some organizations approach DORA metrics and other OKRs as productivity benchmarks that can be wielded against individual engineers. This perspective has even tinged how many developers view DORA metrics. Yet Google research demonstrates DORA metrics are most successful when adopted by high-trust, low-blame cultures. In these enterprises, DORA metrics reveal organizational opportunities for improvement—never should they reveal lagging individual performers or provide reasons for unnecessary busy work.

    In fact, DORA metrics often eradicate rote tasks from developers’ workloads. Teams that use these metrics to identify and implement better incident management processes spend less time fighting fires (e.g., reworking code after a costly manual rollback) and more time doing higher-value work, like building new experiences. Automated processes like automated rollbacks and CI/CD empower developers to improve the quality of individual deployments while also reducing stress

    Make DORA Work for Your Engineering Team

    DORA metrics aren’t going anywhere soon. While they continue to evolve, like the recent removal of the elite category, they remain the industry standard for engineering OKRs, they provide a robust framework for success and a common language for developers and non-engineering stakeholders to communicate about performance, challenges and improvements in the software development process. DORA eases the collaboration and decision-making processes, creating an environment where leaders can consistently and effectively make data-driven improvements.

    But these improvements are only possible when engineers are empowered by beneficial processes and tools. I encourage leaders who implement DORA metrics into their benchmarking to take results seriously. Is your organization’s time to market lagging? Interrogate your current developer workflow—and actively take steps to address issues through developer-first solutions. Doing so will not only improve your organization’s software delivery capabilities but also foster a culture of continuous learning and improvement.