1
0
-1

Having seen the question about WAS, I checked what the OP was talking about and found the "Work Area Support" utility. 

We've been using uniface for 15 years now, and since the demise of the UVS version control, we've had no formal version control in place. So I have zero experience of using the various text-based VC systems this allows us to interface with. (I'm assuming, GIT and others.)

So, it'd be a steep learning curve to start using this in our environment, I was wondering if there was any exemplar documentation as to "best practices" for setting up a system for development by a small number of users either on a shared repository or on how to integrate separate developments into a seamless whole. 

We have a couple of developers, working in a development repository, with a testing repository maintained by export/import and occasional copy of the entire database to catch anything missed, and then two (max three?) 'production' repositories covering the live systems with patches. 

I'd appreciate feedback on what (if any) VC systems are good for use with the WAS and give some documentation of changes (in which we could add a ticket number for example). And what is possible in terms of separating and integrating specific changes across versions (new functions stay in development/testing, but fixes may need to be rolled to previous versions for patching.... 

    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      Hi Iain,

      It's too big a topic to give a very detailed answer here, but i'll try to give some initial pointers based on my personal experience (none of which constitutes endorsement of any kind!):

      • Using WAS, you will need to have standalone sandbox environments (e.g. local environments using sqlite) 
      • The most commonly used open source version control systems are git and subversion, both of which use the version control equivalent of optimistic locking by default (i.e. get latest version, change code, check for other changes and push, dealing with any conflicts).
      • There are other alternatives such as mercurial, and of course commercial offerings.
      • There are some conceptual & terminology differences between tools, e.g. in Subversion you push (commit) files, but in Git you push the changeset.
      • If you prefer to lock files to prevent other users from modifying them, later versions of subversion can do that, but you still need to handle it with a process to some degree.
      • In my personal experience, git is good for distributed working (tracking sets of changes) but has a steeper learning curve than subversion. You need to spend some time understanding how it works and choose a workflow that suits your needs (google is your friend).
      • I use Atlassian SourceTree as a gui client tool for Github and BitBucket repositories, which gives me a nice way to "stash" changes for comparison and re-application when there are merge conflicts due to two users editing the same code.
      • Subversion is simpler and I find the merge functionality easier to use, but you need to have access to a central repository.
      • In either case, I would recommend playing with them performing an end-to-end process using text files and a server first to understand the basics. That could be a hosted service or you could install your own server. Both have plenty of free online documentation and learning resources, and I recommend reading those first, e.g. search for tutorials and look at documentation such as the git pro book and/or the subversion (red-bean) book. 
      • Re: development and release tracking, you would typically use branches in the aforementioned tools to track versions of your software (or labels in some other tools). You might, for example, decide that the "trunk" latest changeset is work in progress and have branches for different releases and bespoke versions, but you might prefer to make the trunk the master release and branch changes, merging them in for release. What works best depends upon your needs. If you plan to do a lot of branching, then I would probably choose git, as it is designed for that kind of workflow. and arguably has better tracking of changesets. With git, you typically create a branch to for each feature you develop, then push your changes and issue a "pull request" to request a merge of your branched changes into the master repository.
      • Tracking of changes and association with issues is typically done via commit comments - you can typically add hooks to the version control server that check them and associate them with issues in tracking systems such as JIRA. This is probably one of the last things you'll implement, but you might consider it if evaluating hosting services, which can come with these features pre-configured.

      Kind Regards,

      David Akerman


        CommentAdd your comment...