TOOL: Git Sparse Checkout

Git repos are cloned fully. And your disk space goes down the drain in this process (if you're working in a lot of complex projects). What if you need only a set of files from a repo? You can use a client (like the web-based bitbucket) to locate and download (one by one). Or enter Git Sparse Checkout:

Using Git Sparse Checkout

SW Development: Single source of truth?

Recommendations on building the SSoT (alongside with DevOps and Agile approaches) for businesses like Financial Services (FS):
https://www.finextra.com/blogposting/15068/how-and-why-software-development-must-be-included-in-fs-compliance-risk-and-security-processes

Quoting:
"The problem is that traditionally, the way software development teams have worked has typically been siloed from the rest of the business.  So, the transparency that banks and other financial institutions need is not inherent in software development.

Plus, visibility and traceability of digital assets is being made more difficult because of the escalating complexity of applications and systems, multiple operating platforms and end points, plus a wider variety of file types -  often larger whether individually or in total volume – and incorporation of emerging technologies.     

This makes it difficult to comply with regulatory demands, because the audit trail – for example, when a piece of code was created or changed, by whom, when, where and how – is difficult to unearth, if challenged.  This is exacerbated by the fact that many financial products have to be maintained for years, if not decades, because of legacy customers.  Plus, should a problem become apparent later, a bank might have to devote extensive time and resource to find the source.  Finally, there is the risk that vulnerabilities can creep into the software development process, leading to breaches that are not detected until it is too late. 

Clearly, the scale of the potential risk and associated costs is too high to ignore and we are seeing more and more FS firms face this challenge head-on, adopting what has been coined ‘a single source of truth’.  Breaking down those traditional software development siloes, the idea of a ‘single source of truth’ is one place for all the digital assets involved in a project or product’s development and on-going lifecycle, from idea, design and development, through to test, deployment, release and maintenance.  The ‘single source of truth’ must be extremely collaborative and transparent, with item-level tracking and visibility of what changed, by who, why and when, across every single digital asset and contributor, technology, internally and externally. "

Recommendations on how FS (and other institutions) could build the SSoT in the link provided above. 

Configuration Management: NASA finds lost mission (IMAGE satellite)...

NASA finds lost IMAGE satellite thanks to an amateur astronomer and is not sure that communications will be possible (configuration management issue?):

• https://www.theregister.co.uk/2018/01/30/zombie_satellite_is_image/

Quoting:

"NASA finds satellite, realises it has lost the software and kit that talk to it. Vanished IMAGE now found. Don't suppose anyone kept a copy of its comms code?" 

(...)

"The Goddard boffins next need to undertake what the agency called “significant reverse-engineering” to capture and analyse data from the signal.

“The challenge to decoding the signal is primarily technical,” the announcement said. “The types of hardware and operating systems used in the IMAGE Mission Operations Centre no longer exist, and other systems have been updated several versions beyond what they were at the time”.

If NASA can decode data from the satellite, it will then try to turn on the science payload “to understand the status of the various science instruments”, and make a decision about IMAGE's future."

Update (2018-01-31) - Additional source for the same news:

• https://www.engadget.com/2018/01/31/nasa-makes-contact-with-satellite-lost-in-space-13-years-ago

TOOL: Come on, be a Git!

(no offense intended, and if you're offended, talk to Linus, who thinks he's a funny guy)
So, in order to interact with a Version Control System that someone called Git you have many options. Here are the 3 most common ones:

• Git command line client: https://git-scm.com/ - for command line lovers
• TortoiseGit: https://tortoisegit.org/ - for Project Managers and other "higher level" users

As a 3rd option: Sourcetree is a good client for developers with branching and merging needs (there are setups that require user Atlassian accounts, and others that will not require it): 
Go to the Atlassian web site for the most up to date versions (Atlassian is the company behind JIRA).

Configuration Management: Version Control System (VCS) and standardized folder structs

To support the CM activities, your company will make available a tool that can be called generically Version Control System (VCS).

Examples of such systems are Git, CVS and SVN (Wikipedia article here and comparison here).

Your QMS could have a Version Control System GBK (INTERNAL) to speed you up.

This guidebook also could be indicating common standard repository structures (per project type) so that when you move from project to project you'll know right away that you'll find meeting minutes in the same (relative) path, e.g. "quality-management\meeting-minutes", code under the "implementation" folder, requirements documentation under the "requirements" folder, and so on.

Folder structures could be different per project type, i.e. software development projects could have a different template used for initial folder strucutre creation than other of another project type (e.g. Services, R&D, etc.)


PS. BTW, are you a git (in VCS terms)? If so, do not complain to me, complain to Linus, Maybe because "He's such a stupid get" - John Lennon (quote from the "I'm so tired" Beatles song).