Skip to main content

More Agile and Iterative Hardware Development for Azure


Hardware is essentially a vehicle for Software. 
With many projects requiring very specific hardware requirements, such as printing without start-up time, artificial intelligence, and more controversial projects like Bitcoin Mining, the route to market could be significantly improved with a more agile and iterative approach.  

  
open-source hardware Project Olympus 
One of the goals behind Project Olympus is to close the gap of the average 1.5 years of development cycle for hardware and get closer to the typical increments being achieved for software development.  
  
the incompleteness theorem  
Microsoft's rationale for sharing an incomplete design is that "open source hardware development is currently not as agile and iterative as open-source software. ... By sharing designs that are actively in development, Project Olympus will allow the community to contribute to the ecosystem by downloading, modifying, and forking the hardware design just like open-source software." 
  
Background 
  • Open Hardware 
  • Open Software 
  • Open Future? 

Project Olympus is Microsoft’s blueprint for future hardware development and collaboration and forms a part of  its hyperscale cloud hardware design and a new model for open source hardware development  

Microsoft's latest contribution to Facebook's Open Compute Project introduces a new server design, it also changes the way the designs are conceived and submitted, as well as their collaboration process. Microsoft plans to share designs with the OCP as early as possible in the design process. 


  
  
Physical example 
 


  
Conclusion 
With a large array of names, such as Intel, AMD, NVIDIAactively collaborating, and designing the latest hardware around this open-source hardware framework it will be interesting to see the branches which form as dedicated projects have a vehicle to thrive and continuously develop at speed. 

  
 Links 
Project Olympus 

Popular posts from this blog

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request. With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally. Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below: Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps

Simple Git branching strategy for release cycles

Coming up with a branching strategy that works well can be challenging when working with multiple developers and managing release cycles. A simple approach is presented here to manage release cycles, with a small to medium sized team of developers while still being able to react to production issues and fix bugs. The primary goal being to isolate work streams without impacting development progress. Background Git does not enforce any particular strategy when it comes to branching which is partly what makes it such a great and flexible repository. The problems start to arise though as you move into different stages of your development process. As an example, you have a release almost complete but don’t want to impede progress on the upcoming release cycle which is where the majority of effort is required. The Basic Approach The focus is around producing a release while still being able to react to hotfixes or production issues without impacting on going development of featu

Azure DevOps Authorisation

Managing whether an identity has access to a given  service, feature, function, object, or method in Azure DevOps comes down to authorisation. Fortunately, by default, the DevOps permissions are set in such a way to enable you to focus on the job at hand, DevOps. Loosely translated this means 'don't get in my way'. My experience is that the Azure DevOps team have done a good job at this, enabling you to crack on developing, building, testing and releasing without much hindrance. Working with relaxed permissions is great when you are the owner and possibly either a one man band or small team but as soon as we need to consider larger teams, varying roles with approvals and degrees of access, authorisation becomes a real concern. I was recently involved in a project utilising offshore developers where trust was a concern and a number of specific teams handling specific roles needed to come together to approve a set of pipelines.  This article is a pick of findings a