Driving Digital Tutorial: Branching and Release Management in GitHub

DevOps Git Branching
What's the number one software development practice needed by organizations committed to agile delivery of application releases that delight customers? My answer is version control with branching capabilities and tagging releases.

Is it number one? No need to debate whether version control is number one, top five etc. Most developers, testers, managers, and CTO will agree that version control practices are important to enable collaboration between developers, foster reliable application releases, establish process for different types of development tasks, and key to scaling the development practice. 

Branching enables Agile Development

I've worked with several development teams the last few months that are using GitHub but hadn't defined a practice for branching or tagging releases. How do you create a handoff from developers to QA? How do you facilitate a hotfix in production? How should you support larger feature development in parallel to small enhancements? How do you track releases and enable rollbacks?

While some of these procedures are straightforward, CTO and development managers often lack documentation to help large teams practice these steps in uniform ways. What results is a mess of branches, some developers branching while others not, formal releases but informal hotfixes etc. 

Then there are some strategic questions:

  • When should you implement a hotfix and what is the impact of taking on this emergency release
  • When developing a large feature, should you branch once for main feature or create multiple branches for each components? 
  • How should QA teams handle feature and hotfix branches?

Tutorial: Branching with Github

I've taken steps to answer some of these questions in a new Driving Digital tutorial, Branching with GitHub. It lays out steps to do many of the basic steps. It outlines roles and responsibilities showing who should branch, who generates pull requests, who merges and who tags releases. Lastly, it illustrates some of the tradeoffs when considering hotfixes and feature branching.

Sign up - Free Tutorial

I've put this in a simple free tutorial that you can receive. Just start by signing up, authenticate your email, and you'll receive a copy of tutorial.
continue reading "Driving Digital Tutorial: Branching and Release Management in GitHub"

Leveraging Data to Improve Customer Experience

Driving Digital with Data
Let’s consider a very typical digital opportunity. A company has a website enabling customers to log in, view recent activity, execute new transactions, and learn about new opportunities. The CMO wants to upgrade the site to improve the mobile experience and to introduce new analytics that she believes will drive increased usage and larger transactions. She comes to the CIO to partner on the implementation.

What first step should the CIO do when considering this opportunity? Should the CIO seek a business case on how much new revenue this investment will enable? Should IT leaders review existing platforms and consider the best technologies to rebuild? How about establishing requirements or designing the new customer experience?

My answer is none of the above.

What Does the Data Say?

The first thing the transformational CIO should do is to partner with the CMO and go on a data gathering exercise. Pull web analytics data to get sessions, pages, events, devices, and customer journeys. Merge in data from the commerce engine to capture transactions and data from the CRM on customer demographics. Lastly integrate the CMO’s market research on customer satisfaction and qualitative feedback on new capabilities and improvements mentioned by customers. Analyze this data by customer persona, spending behavior, and other dimensions to provide a data-driven story on the gaps and opportunities in a digital transformation of this website. This can then guide the business plan, customer experience, technology choices, and development priorities in the implementation.

Digital transformation affects every industry. It’s how banks must review online retail banking experiences, manufacturers their B2B ecommerce portals, insurance companies their tools for tracking claims, charities their websites for capturing donations, and hospitals their kiosks for providing patient information. Reviewing existing data, merging in new sources, and leveraging customer research is at the heart of delivering transformational digital experiences.

A Recipe for Becoming Data Driven

I cover many of the steps on becoming data driven in my book, Driving Digital: The Leader’s Guide to Business Transformation Through Technology. CIO can start with citizen data science programs that enable analysts in and out of IT to blend data sources, perform ad hoc analysis, and develop dashboards to share analytics and insights. The CIO should also be leading efforts to integrate enterprise data sources, so in my example above, data from the CRM, web analytics, and commerce engines should already be integrated and available as a data service to the analyst.

What happens next? With easy to use tools and access to data, analysts begin to ask questions and seek insights. As they analyze and expose more data, they are likely to hit data quality speed bumps such as duplicate records that need to be merged, inconsistent address formats, or records that are difficult to join because of inconsistent company names. CIOs can take the next leadership step by defining data governance, establishing master data sources, and providing tools to improve data quality.

Real competitive differentiation is when the CIO can leverage the CMO’s market research to provide insights into future needs. Market research may come in the form of survey responses, customer feedback, insights extracted from social media feeds, aggregated news, economic forecasts, and government data. In other words, a lot of unstructured data and forecasting data that can be challenging to integrate with existing enterprise data sources. The data wrangling can be complex, and new tools such as Claire are driving boosts in productivity by leveraging AI and machine learning to automate data management tasks and identify patterns in unstructured data.

Transformation by Leveraging Data

To enable digital transformation and growth, leaders today must look beyond their current capabilities and develop competitive customer experiences. Leveraging data, analytics, and research allows leaders to make well informed decisions on strategy, priorities, design, and implementation. CIO’s need to lead this charge by merging existing and new data sources and developing a customer-centric view exposing their values, needs, and opportunities.

This post is brought to you by Informatica and IDG.

The views and opinions expressed herein are those of the author and do not necessarily represent the views and opinions of Informatica.

continue reading "Leveraging Data to Improve Customer Experience"

Understanding the Basics of Deep Learning and Neural Networks

Last week I had the opportunity to visit my graduate school alma mater, The University of Arizona where I studied artificial intelligence and image processing many years ago. I remember signing up for my first semester classes and electing to challenge myself with Professor Neifeld's neural network class. It already had the reputation of being one of the toughest classes requiring students to understand both the mathematical theory and real-world application of neural networks to solve classification and other problems.

Neural Networks Before Cloud Computing

Of course back then there wasn't cloud computing or easy access to parallel computing methods or deep learning Python libraries. As students, we had to program the algorithms by hand starting with the mathematics of a single neuron, the iterations to loop through all the neurons in each layer, and the algorithms to implement the backpropagation learning algorithms. You were more likely to screw up programming the mathematics before even having had the chance to tune the network properly to solve the challenge.

Needless to say, I learned how to program many neural networks. I assumed when one failed, it was because I had selected the wrong algorithm rather than a flawed implementation.

The reason we have deep learning today is because cloud computing enables us to program multiple layers of thousands of neurons. And instead of programming the intricacies of the algorithms, AI developers are more focussed on how to present  datasets to AI algorithms, selecting algorithms, tuning the learning algorithms, and evaluating the behaviors.

A Simple Explanation of Neural Networks

But as an "old dog" of neural networks, it gives me the opportunity to explain what they are in semi-layman's terms.

Remember linear regression? You applied an algorithm to optimize the linear equation y = mx + b given a dataset of x and y values. Neural networks operate on a similar principle but are nonlinear and approximate a complex curve to fit multidimensional data. In other words, the main differences is that the simple linear regression model is working with one dependent and one independent variable (x and y) to determine slope and intercept (m and b) while neural networks can have many thousands of inputs (like an image), usually a few outputs (is the image a cat?) and can approximate highly complex, multi-dimensional surfaces depending on the number neurons and topology (number of layers) of the network.

How does the network work? Each neuron operates like a transistor with an activation function that dictates its output given a set of inputs. When the network is presented with an input, the first layer of neurons compute their output and feedforward them to the next layer. This is repeated until all layers of the network are computed and the final layer shares its result.

Of course the initial result is likely to be wrong and the network has to be tuned. Given a dataset of known inputs and outputs, backpropagation is one of the many "learning" algorithms used to tune the neurons (adjust their activation functions) so that the network outputs the correct values for the inputs.

If you programmed the network by hand, you'd have to sequence through all the layers of the network and all the neurons in each later to compute their activation functions, capture outputs, and arrive at the network's output. You'd then have to compute the backpropagation algorithm and apply iteratively for every datapoint in your training set. So while the code was relatively straightforward, the computation was very slow and inefficient. Cloud computing and parallel computing models solves this issue.

Neural Networks Today

Of course today, it's unlikely that a programmer or data scientist would be programming the model by hand as there are many libraries and APIs that have these services available. The researcher still has to pick the topology of the network, activation functions, learning algorithm, and other parameters. More importantly, the trainer has to select a way to present the problem set to the network (the inputs and outputs) and identify appropriate training and test datasets.

And that's just one example of "supervised" learning where there is a training set that can be used to teach the network, There is a whole class of unsupervised learning where the network is trained based on the quality of its response.

So while cloud computing and the availability of deep learning APIs has made neural networks available to the masses, it's still not a straightforward undertaking. AI still requires significant investment in agile experimentation to test approaches, validate conclusions, and configure the next set of experiments.

But the results are impressive and many companies with strategic datasets are exploring the science and business value of deep learning. Just in the news the last few weeks - measuring store visits, sports analytics, healthcare research including diagnosing cancer, and even beekeeping. With a forecast to grow to $10.2B by 2025, I suspect we'll see a lot more investment and experimentation over the next several years.  

continue reading "Understanding the Basics of Deep Learning and Neural Networks"

Five DevOps Lessons from a CIO Getting in the Weeds on AWS

DevOps - Get in the weeds
I always advise CIOs and technologists to get into the weeds to figure out what's going on. So last week I spent some time getting a number of AWS services up and running. Nothing too crazy, but successful.

My first project was to set up a new domain, Driving-Digital.com on AWS Route 53 to enable landing pages and vanity URLs for my upcoming book, Driving-Digital: The Leader's Guide to Business Transformation Through Technology. While it's been a few years since I last set up DNS, the basics are fairly straightforward. What I had to learn was how to properly set up S3 to act as a web server and use the redirection rules to enable a set of vanity urls. Again, not too complicated especially if you configured an Apache web server.

My second project involved setting up an Amazon RDS Postgresql database with a VPC to enable selective inbound traffic. My goal was to enable an ETL service to automate moving data from my Google Analytics account into a database and then use Tableau to join data and build visualizations. This setup took a bit longer as I had to figure out how to setup a VPC properly and then grant appropriate permissions in the database.

My third experience was working with a client looking to setup a Node.js application on Elastic Beanstalk using Travis to automate deployments.

DevOps Lessons Learned in Cloud Configurations

So here are some of the lessons learned from my short and simple exercises -

  1. You can teach an old dog new tricks - If you've configured infrastructure in a data center, then enabling similar basic capabilities in AWS largely requires learning a new vernacular and tools. Again, I was only doing very basic DNS, VPC, web server and database configurations but was able to accomplish these tasks without training classes or reading extensive manuals. When I got stuck, I Googled for answers. For CIO, if you have system administrators and engineers that largely operate tech in the data center, getting them to operate similar technologies in the cloud only requires some basic training and time to experiment.  

  2. Planning required for more complex tasks - Setting up S3 to run a barebones web server is straightforward, but it doesn't have anywhere near all the capabilities of an Apache web server. Like all infrastructure needs, it's important to know your basic configuration requirements before selecting a technology and its implementation.

  3. Debugging is still hard - When I couldn't connect my ETL service to the database, I had to go through basic debugging steps to determine what network layer was blocking the traffic and how to configure it properly.  This took several trial/errors and the tools to debug weren't immediately obvious.

  4. Online documentation is very good, but not ready for DevOps - The documentation I poured over was very good explaining how to do basic and more advanced configurations. I  was also able to find reasonable documentation on solving problems once I had already recognized the source of the issue. It was poor in describing tools or steps to debug, or providing links to best practices. For DevOps, I was hoping to see some separation of duties to determine what steps should be automated as infrastructure configuration versus what should be setup as part of deployments.

  5. Move to Infrastructure as Software quickly - Tracing through a manually configured cloud environment is only slightly easier than doing the same task in your data center infrastructure. At least the cloud is web based and most of the tools are centralized, but navigating different configurations, naming conventions, and pipelines can become very complex if you're tracing through someone else's configuration. As CIO, we all thought setting configuration standards and moving to more homogeneous architectures would address the complexity, but I suspect only a small percentage of IT organizations are successful with this approach. On the other hand, if the configuration is automated in well structured and documented code, then there are fewer places and artifacts required to learn and maintain a computing architecture.
So today's post comes to you from my time in the weeds!

continue reading "Five DevOps Lessons from a CIO Getting in the Weeds on AWS"

Driving Digital: The CIO's Playbook

Thanks to Landmark Ventures and Anthony Juliano for a great CIO Summit last week and for giving me a speaking spot for Driving Digital: The CIO's Playbook.

If you weren't there - here's what I covered

How are you executing your Digital Transformation Program

These practices and many others are described in my upcoming book, Driving Digital: The Leader's Guide to Business Transformation Through Technology that will be available August/2017. In addition to agile transformation and data science programs, I cover product management, the IT organization of the future, ideation and portfolio management, data platform architecture and DevOps. Most importantly, I cover how to align the executive team on digital transformation and on changing to a digital mindset.

I've developed a page to sign up for announcements on Driving Digital and to get access to related services that I make available.

The talk is only ten minutes. Watch below!

continue reading "Driving Digital: The CIO's Playbook"

Aligning product owners and business stakeholders to a release management strategy

Aligning to a release management strategy
I have found that the hardest part of getting a release management practice instituted is in getting the business alignment. Development teams often recognize the need to develop a release management strategy. If they are strong technically, they may look to mature their DevOps practices to support continuous deployment if it makes sense for their business. If not, they may build continuous integration and delivery capabilities, then look to implement a more traditional release and deployment strategy.

Even when product owners and stakeholders are involved in formulating the strategy, they often struggle adhering to this in practice.

It's not always their fault. Product owners have their customers to satisfy. Some customers can be very demanding, or the product owner may just be feeling the pressure for high customer satisfaction. So for the purpose of this post, I'm going to assume that there are rational business reasons for a product owner's need for flexibility in the release practice and this isn't just a product owner behaving badly. If it is, here are my suggestions on handling difficult product owners.

Release Management Anti-Patterns

What are some of the issues that misalign business need with a development team's release management practices?

  • There's a problem and I need a hotfix
  • Users are complaining and we need an improvement fast
  • There's a new marketing event scheduled and the app needs
  • We're driving a price increase and need a big feature release 
  • How can we make a big workflow change easier for users 

Let's look at these one by one and consider mitigation strategies

There's a problem and I need a hotfix

The technical solution is to make sure your branching and testing strategy supports hotfix branches. See one example. But the bigger problem is the cost to implement the hotfix especially if the product owner is prone to request many of them. First, it disrupts the development team to branch, fix, and deploy the hotfix. Second, it requires at least two rounds of testing; one when the hotfix is deployed and a second it is merged into the main development branch. Here's what I suggest
  • Make sure the product owner understands the tradeoff by reducing the commit in the current sprint to support the hotfix.
  • Illustrate and build awareness around the added testing costs
  • Measure and benchmark the behavior (# hotfixes / time-period), communicate the impact to the roadmap, and single out product owners that have higher hotfix requests.

Users are complaining. We need an improvement fast

This is more likely to happen with internal applications deployed rapidly and where users may have different workflow needs. It may also happen if release cycles are too long and users prefer seeing more incremental changes. Suggestions
  • Make sure to capture and reflect if the needs of a specific user group were missed.
  • If this happens infrequently, consider scheduling minor releases before going onto your next major release. See more specifics on major/minor releases.
  • If this happens frequently, consider shortening your release cycle.

There's a new marketing event and the app needs

This is more specific to products or customer facing applications. Ideally, marketing events should be considered when developing the overall product and release roadmap. That being said, it's fairly common for an agile marketing team to find new opportunities requiring changes to the release schedule and feature prioritization. Suggestions:
  • Make sure the marketing team is engaged when developing roadmaps and release schedules.
  • Develop a communication/collaboration process so that you are informed as early as possible when a new marketing opportunity may impact the roadmap.
  • Make it easy for product owners to update priorities in the agile backlog.
  • Develop a branching strategy that can accommodate these opportunities.

We need a big feature release

This shouldn't really be an ad hoc business decision and this business strategy needs to be reflected in the product roadmap and the release strategy. If it comes out of nowhere, it probably means that there is a shift in business strategy, or this may be a onetime event. Suggestions:
  • Make sure the team understands whether this a shift in business strategy that should require a review of the roadmap and the release strategy, or if this is a onetime event.
  • Consider having shorter and incremental "alpha" releases for internal users and longer "go-to-market" releases that are customer facing.

Can we make a big workflow change easier for users

This suggests that you have the capability to roll out incremental improvements to a subset of the user community, or, have the ability to do A/B tests when rolling out new capabilities. Suggestions:
  • If you need to roll out changes to different customers or user communities incrementally, then this capabilities has to be developed within the application. Add it to the backlog and develop a rollout strategy based on the application's authentication groups and roles.
  • There are many third party tools to support A/B testing or you could build the capability in house. If A/B testing is needed, just make sure it's developed as a horizontal capability so that it can be leveraged across multiple applications.
If you send me any other anti-patterns, I'll look to update in a future post.

continue reading "Aligning product owners and business stakeholders to a release management strategy"

Defining Your Agile Release Management Strategy

Release Management
In my last post, I asked whether continuous deployment is right for all businesses and suggested a number of business criteria and technology capabilities to help determine whether organizations should go beyond continuous integration and continuous delivery to a full continuous deployment operation. I recommended in an earlier post that release management strategies are important to agile practices, however, maturing to continuous deployment is just one, rather advanced approach, Organizations can still achieve high quality software releases and develop product delivery roadmaps with more traditional release management practices.

The Problems with Ad Hoc Release Management Practices

Many organizations start with ad hoc release practices and leave it to individual product owners with or without the agreement of their development teams to decide when applications are ready to be released, when to schedule release dates, and how frequent to schedule them. Leaving it to individuals or teams to make these decisions leads to several potential issues. First, these teams usually don't act in isolation and their schedule may create conflicts when they require participation from shared service teams. Second, the ad hoc nature makes it more difficult to forecast roadmaps since the amount of overhead tied to different release schedules may not be consistent from release to release. Third, these teams can create quality issues if there isn't some guidance set on what types of application changes are appropriate for shorter versus longer release cycles. Lastly, these teams tend to want to make "quick fixes", "patches", "support changes", or "emergency changes" frequently and without realizing that this makes it difficult to focus on more strategic application improvements.

Over the years, I've been brought into several organizations stuck in this cycle of frequent patch releases. The team makes one release, the product owner reports user complaints or production issues and demands fixes, the team complies with a patch release that only partially fixes the issues, the product owner reports additional customer feedback as defects, the team chases it with another patch release and this cycle repeats. If this continues, users get frustrated with the quality of the application, teams get the reputation of having poor practices, and product owners fail to deliver on their strategic roadmap.

Getting out of this cycle is critical and many teams can't do it easily on their own. They need someone to lead them through steps that (i) recognize the issues created by ad hoc release practices, (ii) define release principles that make sense for the business strategy and for users, (iii) take active steps to normalize their release management practices.

Defining Release Management

Here is a summary of the steps I specify with organization that want to go from ad hoc release schedules to a normalized release management practice

  1. Define a frequency of change that makes sense for the business strategy and for users. A B2C company that targets small experimental changes may want more frequent releases than a B2B company that's producing analytics for their customers. Keep in mind that any release that contains new capabilities, functional changes, workflow changes, or substantial UI changes often requires some form of testing and user training, so the release cadence should align with how easy it is to engage the user community on new capabilities.

  2. Define release types that correspond to the impact to users and technical risks. Presented below are three typical release types.

    Release TypeScopeTypical Duration
    MajorNew features and capabilities. Workflow changes. No changes to underlying systems, app infrastructure, and libraries3-6 sprints
    MinorSmall changes and fixes. No new capabilities or system changes2 sprints or less
    System UpgradeChanges to systems, app infrastructure and libraries with no or minimal functional changes1+ sprints to test, then validate impact

    You'll notice a couple of things. First, I instill testing disciplines by having releases focus on application changes (major and minor releases) versus system changes (system upgrades) which provides scope to the testing required. Second, minor releases are characterized by shorter durations that have less time to engage users on changes, so the scope of minor releases is tied to improvements that have less impact and technical risk. Third, major releases don't have undefined durations and the duration should be normalized to the business strategy and technical capabilities of the organization. Lastly, it's hard to determine the duration of a system upgrade, so I advise teams to plan at least one sprint to test the upgrade and add to the backlog the issues that need remediation. Once these are identified, the team can then project the duration for this type of upgrade.

  3. Your release starts when planning the release, not when you're ready to deploy. This is a change  the team needs to recognize. Deployment planning which goes into defining the technical steps to push an application into production is not the same thing as release planning. Release planning should start before any development starts. It should start by defining the business goals, selecting the release type, and defining at least part of the backlog for what needs to be developed. It should include defining what business activities are required pre and post the release. Once this scope is understood, then a target date can be selected for the release.

  4. Look to establish a schedule of releases. Once a team has been through at least one successful release of every type, it can then explore developing a release strategy. This strategy should factor in how many major releases the business team requires, how many system upgrades are needed to keep technologies up to date, and how best to schedule minor releases. 
Once these practices and governance are in place, then optimization leads to shorter release cycles and the capability of performing more frequent releases. I'll leave that to another post.

Further reading 

continue reading "Defining Your Agile Release Management Strategy"