Is there any way to use the "build from source" functionality from the command line?

[ragnarredbeerd]

Here is what we are trying to accomplish: an updater for our client projects that basically looks at the master branch of our repo on open, and if there's a new commit, we pull down those files and build.

The plan thus far:

1. On open of database (db1), run command line check to see if Git is installed. If not, install via command line execution in VBA.
2. Run git commands to check the date/time of last commit and compare that with the commit that created db1 - stored in front end table. Alternatively, I think we could use a commit # instead of date/time.
3. If there is a new version, pull the files down into the same directory as db1.
   -- Here, it would be ideal to be able to use the dll to build from source using the command line. Beyond creating another Access db, injecting the VBA I need it to run, and then opening it with arguments, I am not sure how to accomplish this.

This would give us some CI/CD capabilities for Access projects, which would be realllllllly cool.

Let me know if you have any ideas.

Thanks!

[hecon5]

So, I'm pretty sure that's the intent of the merge build tool (it's being worked in the dev and mergebuild branches).

There's a boilerplate version of Access CI/CD HERE: https://github.com/msaccess-vcs-integration/msaccess-devops

@joyfullservice: I see the development of merge has slowed down a bit (I know I've been ... swamped lately); am I getting this correct?

If I've misunderstood, and there's something else, make an issue for this, and perhaps we can figure it out. I think on the legacy version of VCS someone wrote a PowerShell Script to do something similar.

Edit:
From reading your plans, I'd suggest making the auto-merge manual. IMO, merging changes into Access should be deliberate, as it has some consequences, and because Access isn't always so nice, making it deliberate is the best case. Integrating with git and the merge tool will accomplish most of what you've got here, and tying in devops above, and I think you'll a pretty slick CI/CD.

For my users, I compile a new version, and their version will phone home to a server to check for updates and then download it without their needing to do anything, but IMO users should not be building versions from code, that's the dev's job, and it should be deliberate.

If you want some ideas and boilerplate code, I'd be happy to share some of the end user versioning control/update tools I use.

[hecon5]

I see a few things here, before I start giving "answers".

1. Updating your source code and development version.
2. Updating your user's main version (more later)
3. Updating your user's modules (IIRC, @joyfullservice uses a module based approach vice a "all in one" approach; this has some distinct advantages to updating one massive file, but some downsides in terms of ensuring cohesion).

In my opinion (there are many, this one is mine), the way you're updating your users (2) will work; it's similar to what we do.

For the development (1): using this module + a repository (GitHub is one of many, there's also GitLab, Atlassian Bitbucket, and there are many others) is darn tooting close to what you describe. I think you are describing 1 above.

The way our team does it is as follows. We use a 3 branch approach:

• stable: this contains released version code. Released versions are compiled from it.
• develop: this contains checked, approved development code that the beta team sees.
• features (name appropriate to fix/update): this contains whatever the developer wants, it tracks as closely as possible the file they're building, often times will have breaking bugs, may have errors, but the goal is to be able to build the version you're working on for backups, NOT to show others that you're bug free, cause that's a lie.

Our flow for releasing to users

1. Develop new feature/bug fix on a feature branch (we try to keep these small).
2. Test said update on our machines.
3. Make a PR to the dev
4. Build a beta version (from addin).
5. Release beta to our beta test group (a group of eager users who don't usually mind issues, and are more than happy to let us know any issues).
6. If any, fix any issues (go back to 1).
7. If no found issues, release to stable branch.
8. Compile and release version (semi-CI/CD approach).

Using the addin and some internally developed code, It's about a 5-10 minute process to compile the stable branch from the code, click "release to users", and users seeing a "update" notice next time they load it (at the moment, we do not periodically check the server for updates during operation as it had some unintended side effects, especially for network loss (we're geographically scattered)).

We automated as much as possible here, namely compile the code, build a accdr file (for a few reasons, we don't release the accdb file, a few of those reasons because we don't trust our users, mostly because had so many issues with users accidentally deleting code and creating undesired outcomes).

I'd love to get some time to incorporate the CI/CD mechanisms that I mentioned above, because with a VM, it'd be possible to have the VM build stable nightly, and develop. But I've got so much other stuff on my plate at the moment that's a far away dream, and as the release process is so quick, the amount of time to develop vs the time it saves is minuscule.

OK. Now I've bored you. Sorry.

The purpose of the merge tool (from my interpretation) is to enable two developers to work on the same feature branch simultaneously. Namely, if you have someone checking your code, and they find a bug, and propose it, they can simply commit that fix to the branch, you click "merge", the addin goes through the branch code "outside" the Access file and the code "inside" the Access file, compares it, and enables you to merge the two together, much like git conflict resolution.

• Fetch/Pull remote to your local repository.
• Click "Merge" on addin.
• Any changes are handled inside the addin on a comparison screen, that will export and use diff like comparison.
  • Only the changed components/forms/etc. are imported/exported/compiled. Items unchanged are skipped.
• Once any differences/issues are noted, the addin exports to your local repository.
• You commit/push these to the remote.
• Your file and the code on your machine and the remote repository all match.
• You continue developing for a while before your next meeting.

The current process to do this adds a bunch of steps, and because of how the files live and git works, it's sometimes byzantine and a delicate process. Different steps highlighted.

• Fetch/Pull remote changes to your local version
• Export your local file's code to the local repository, because if you import right now, you'll lose them.
• Tediously go through the code to determine what's noise (letter case changes, color issues though this has mostly been addressed, EOL additions, etc. For projects with hundreds or more forms (mine is one), this can take...a while.
• Commit the bits you actually want to be used.
• Refresh your local copy to remove noise files.
• Import/build
  • NOTE: This process builds the ENTIRE database from scratch. This can take significant time, especially for linked tables/queries.
• Export (to confirm they happened if you're paranoid).
• Commit any issues, consider rebuilding if they're different enough
• Push to remote.
• Your file and the code on your machine and the remote repository all match, probably.
• You go get some coffee and or need to attend another meeting, because you've run out of time.

In any regard, it seems a lot nicer to merge in the file than deal with it externally and have to completely rebuild. Obviously, for critical items (like stable builds, which hopefully won't be super common, and in a fully automated CI/CD environment, it happens at 01:00 and the 5 minutes doesn't matter to you) it might be better to do a full build, but for development iterations...merge will save a TON of time.

[ads-software]

@hecon5 Haha, I must be a geek cuz none of this is boring me in the slightest... it all sounds like the direction I was looking for. Let me see if I can wrap my brain around all of this new information.

Development: I think on the development side of things, we are on the same page. My branching and testing process may differ slightly, but the basic idea is the same. We want to build and deploy once we have a "usable" version for users.

Deployment: Like I said, we are currently using a batch file to check SQL Server for a new version. Instead of this process, you are using a ClickOnce installer. I am not entirely familiar with how that installer works, other than that it is an option when I publish projects in Visual Studio. Your ClickOnce installer is firing off some other processes that I am not implementing, such as adding the database to Trusted Locations, which would be super helpful to me.

Here's where I get lost: When you generate the ClickOnce installer package, where are you putting the package so that the user's existing system can look for the update and grab it? Some kind of cloud storage or?

Sorry for my lack of experience here, I'm in the middle of bringing our development practices into the new millenium :), and I'm still learning, ALWAYS learning. Again, any light you can shed on these processes is much appreciated.

[joyfullservice]

Here's where I get lost: When you generate the ClickOnce installer package, where are you putting the package so that the user's existing system can look for the update and grab it? Some kind of cloud storage or?

@ads-software - Great question! When I originally developed this, I used a UNC network share. This works fine, but you have to make sure you install it from the UNC path, not a mapped drive, or the updates won't work correctly. To do it over, I think I would put the package on an internal Web server so the updates could be copied by the script to a shared folder, but deployed and updated to the clients over the Intranet.

[ads-software]

What do you think of using our SQL Server to hold the package in BLOB storage?

[hecon5]

Personally, I wouldn't. Not because it wouldn't work, it would, but I'd rather not have my SQL Server dealing with my tool transfers, and leave that to better suited tools. This frees up my server to deal with the task I want it to do: handle our business data quickly.

We use OnPremise SharePoint, which works...ok, but it has some limitations. We're trying to migrate to a Teams based SharePoint, but some of our other development has taken over. It's on the route plan for later.

[ads-software]

FYI I am the OP, just using the business acct.