Archive

Archive for the ‘DevOps’ Category

Why Git?

January 4, 2016 Leave a comment

Technical answer

Very often the answer to this question can be provided by highlighting multiple technical advantages of the distributed version control system, such as local repositories, differnt topologies,out of the box DR,efficient branching and merging and other.

Sceptic

An experienced developer could argue that modern centralized version control systems offer backup capability, personal branches in a form of shelves, change set management, labeling and other advanced features. Benefits of the DVCS might not overcome the simplicity and practicality of the centralized version control system. The transition to Git could result in the an increased process complexity and a temporary loss of productivity.

Social aspect of the Git

Developers, engaged into verity of the Open Source projects, have quickly realized that Git is not just a convenient geo accessible repository – it is also a powerful collaboration environment. De facto, Git has become very important social media channel and an idea exchange host for developers. Git mirrors the human thought process branching and provides mechanisms for individual or collaborative memories. “Why Git ?” – DevOps is a collaborative culture and Git fits it perfectly.

Git and Corporation

The transition to Git is very similar to a transition from COTS to DevOps – instead of multiple isolated teams working within closed boundaries, the focus is on the end product and the collaborative contribution to a platform evolution. The goal of adopting the Git culture is to bring Open Source style of development into the corporate environment.

Advertisements
Categories: DevOps

Latest trends in the application test practices

December 22, 2015 Leave a comment

Paradigm shift

New approach in the application testing is innovative and would require some time to digest. The biggest paradigm shift is to stop chasing bugs and focus on the identifying and changing processes and practices yielding high frequencies of production problems. According to Microsoft, it is possible to achieve practically acceptable threshold of bugs in production only by tuning up SDLC pipeline. The previous statement requires a clarification:

  • Limited number of bugs are allowed in the production
  • The major source of bugs is not implementation but processes and practices
  • If amount of bugs does not exceed the threshold there is no need for the QA organization. The rational is that Developers writing automated test, feedback from Insiders/Preview/Production users , green-blue deployment and the implementation of the feature toggle practices is enough framework to deliver quality at speed.

Functional testing

The message for functional testing is very clear:

  • Test has to be automated
  • Test has to be written and not recorded
  • Test has to be written only by a developer who introduces a change and is fully responsible for the application working in production
  • Test has to be written before or right after a change.

Non-Functional tests

The value of the non-functional tests has to be re-visited through a prism of new emerging concepts such as Continuous insight, elastic scaling and fabric deployment. Continuous Insight has three parts: Availability check, Telemetry and Usage. Availability check performs intelligent application pings and is a substitute for any type of connectivity tests. The application telemetry and usage in the new cloud-born architecture are connected to the stream analytics and integrated with elastic services in order to notify self-balanced , self-healing , resilient fabric cluster with provisioning or de-provisioning events. It seems to me that classic performance testing goals – identifying application breaking or throttling points in pre-production environment and resource planning are becoming obsolete. The recommendation is to identify resources consumption anomalies within telemetry stream that might be due to poor application design or implementation and convert them into technical debt backlog items.

What types of functional tests are necessary?” is not a correct question. The only type of automated test to start with is an isolated requisite based test . All other tests should be a result of an application evolution – found bugs, common inconsistencies, consumer’s feedback, etc..

In conclusion, I would suggest the elimination of the multiple obsolete test practices; along with documentation waste and expensive tooling makes application lifecycle management much chipper , much simple , much cleaner and much faster.

Categories: DevOps, Test

Microsoft Connect()-2015; feedback

December 15, 2015 Leave a comment

Microsoft

Microsoft continues to surprise the IT industry with bold efforts to re-brand its image. As of now, Microsoft is a Open Sourced, Cross-Platform, Cross-Cloud global player and is fully committed to the end-user experience and satisfaction. A few of the latest announcements that re-enforce and emphasize Microsoft’s message are the Docker, RedHat, Sonatype partnerships, and the CoreCLR, .NET libraries, Visual Studio open sources.

 

Note: During Day 2 of the group meeting, I had a chance to speak with the Product Manager of the iOS mobile platform for one of the communications company… The team he manages has decided to use Azure Mobile Services for push notifications, and Azure Active Directory and Microsoft Intune in order to implement security policies. He was asked “Why choose the Microsoft cloud platform instead of AWS?” and his response was “capabilities, simplicity, and it’s relatively inexpensive”. In my opinion it’s quite meaningful and promising to hear such a response from a representative of the once “alien” culture.

  

Microsoft DevOps practices

Microsoft is a huge supporter and practitioner of the Agile Project Management, Continuous Provisioning, Continuous Integration, Continuous Delivery, and Continuous Insight paradigms. They also mentioned the VSTS ( Visual System Team Services) and the Mobile Tools units that are very close to switching to Continuous Deployment (vs Continuous Delivery), and also that Bing is already a Continuously Delivered product.
 

Public Cloud adoption

Companies that went through the initial, and usually painful, cultural transition have gained trust for cloud security and the ability to support governments’ regulations and privacy requirements. They are now in position to benefit from the global cloud presence, have the ability to offload infrastructure concerns, and enjoy the quick rate of the innovation that cloud provides. Cost-wise – many suggest that initial cost saving is insignificant and is around 10% or less. However, with understanding how to tweak cloud transactions accompanied with cloud elastic services would bring savings up to 25-30%. The transition to a PaaS architecture might decrease spending in half.
 

SAFe

Microsoft definitely provides a set of tools to manage Scaled Agile practices. However, the feeling I got is that Microsoft internally does not use the approach. Instead, they completely rely on the consumer’s feedback. Microsoft speakers actually made a point of working on a feature only if it made to the top of the stack by end users or communities vote. Community-driven features such as Docker support are considered strategic. Recently acquired HockeyApp platform and feedback channel in every new Microsoft product provide an ability to collect user experience and react on it. The role of the business in this consumer oriented model is to adjust highly voted features with financial and market impact analytics and advertise them as soon they are entered into the preview mode. Microsoft intensively uses Power BI and Azure Machine Learning Services for the market and financial mining.
 

Test practices

Microsoft perspective on the application testing is innovative and would require some time to digest. In short – the recommendation is to stop chasing bugs and focus on the identifying and changing processes and practices yielding high frequencies of production problems. According to Microsoft, it is possible to achieve practically acceptable threshold of bugs in production only by tuning up SDLC pipeline. The previous statement requires a clarification:
  • Limited number of bugs are allowed in the production
  • The major source of bugs is not implementation but processes and practices
  • If amount of bugs does not exceed the threshold there is no need for the QA. The rational is that Developers writing automated test, feedback from Insiders/Preview/Production users , green-blue deployment and the implementation of the feature toggle practices is enough framework to deliver quality at speed.
Functional testing

The message for functional testing is very clear:

  • Test has to be automated
  • Test has to be written and not recorded
  • Test has to be written only by a developer who introduces a change and is fully responsible for the application working in production
  • Test has to be written before or right after a change.

 
Non-Functional tests

The value of the non-functional tests has to be re-visited through a prism of new emerging concepts such as Continuous insight, elastic scaling and fabric deployment. Continuous Insight has three parts: Availability check, Telemetry and Usage. Availability check performs intelligent application pings and is a substitute for any type of connectivity tests. The application telemetry and usage in the new cloud-born architecture are connected to the stream analytics and integrated with elastic services in order to notify self-balanced , self-healing , resilient fabric cluster with provisioning or de-provisioning events. It seems to me that classic performance testing goals – identifying application breaking or throttling points in pre-production environment and resource planning are becoming obsolete. The recommendation is to identify resources consumption anomalies within telemetry stream that might be due to poor application design or implementation and convert them into technical debt backlog items.

“What types of functional tests are necessary?” is not a correct question. The only type of automated test to start with is an isolated requisite based test . All other tests should be a result of an application evolution – found bugs, common inconsistencies, consumer’s feedback, etc..

In conclusion, I would suggest the elimination of the multiple obsolete test practices; along with documentation waste and expensive tooling makes application lifecycle management much chipper , much simple , much cleaner and much faster.

Categories: Cloud, DevOps