MIGRATING YOUR PROGRESS APP TO A MODERN VCS
Gabriel Lucaciu Delivery Manager YONDER THE PAST
Driving with the handbrake ON… GOALS
Am I using the proper VCS ?
How do I choose the VCS that ensures my future ? What do I need to do to get my Progress app to the next level of CI/CD ? FIRST, LET US KNOW EACH OTHER
13 yrs+ MY COMPANY 25 yrs+ EXPERIENCE SERVICES S O NEW INITIATIVES L U MODERNISATIONS T I APPLICATION DEVELOPMENT O N GO MOBILE & IOT S
& Automation
Agile coaching https://www.tss-yonder.com Version control system… INTRO
Migration STEPS
Agenda Choosing the Version Control REPOSITORY
Continuous Integration
Q&A VERSION CONTROL SYSTEM… INTRO MODERN VERSION CONTROL SYSTEMS
● A Version Control System is a software that helps tracking changes made in code over time
● Benefits of a modern Version Control System
● Creating workflows
● Working with versions
● Coding & collaborating together
● Keeping a history of the changes
● Automating tasks
● Steps to decide which VSC to use
● Determine why a new version control is necessary
● Define what it is needed from the version control
● The evaluation process TYPES OF VERSION CONTROL SYSTEMS CENTRALIZED VS DISTRIBUTED
Centralized Distributed
Typically easier to understand There is no locking of elements
Easier access control, The complete code base is everything controlled from server already on your local system
You don’t have to merge, only if Branching and merging is you want much easier, that’s how it’s built
Don’t need to be connected on network all time VERSION CONTROL SYSTEMS FOR OPENEDGE
Roundtable Git SVN Mercurial •Centralized version control •Distributed Version Control •Centralized version control •Distributed revision control •Enforces auditing procedures •Increase in operation speed •Newer system based on CVS •Easy to learn •Safeguards systems assets •Cheap branch operations •Includes atomic operations •Easy to set up •Accelerates productivity •Full history tree available •Cheaper branch operations •Not as flexible as Git •Decreases time-to-market offline •Does not use peer-to-peer •Designed for Eclipse model
● Other systems: CVS, Bazaar, home-made VCS etc. VERSION CONTROL SYSTEMS POPULARITY MIGRATION STEPS • Current tools and processes
• Branching strategy
• Migrating commits history
• Old version control system
• Source control structure
• Performing the migration EVALUATE THE CURRENT TOOLS AND PROCESSES
Source version control
● How is this managed? What VCS is used?
Build and Test
● Performing builds? Running tests?
Code reviews
● Performing regular code reviews? Any tools in place?
Release Management
● How does the deployment process look like? SELECTING A BRANCHING STRATEGY
● Branch strategies
Two common topic branch strategies are GitFlow and a simpler variation, GitHub Flow, which can be adopted or look to for inspiration. SELECTING A BRANCHING STRATEGY
● Feature flags
If you’re currently using a long-lived feature branch strategy, it may be easiest to begin adopting “feature flags” before migrating, so that you need to migrate as few branches as possible.
● Document
Be sure to document the mapping between legacy branches and the new branches so that team understands where they should commit their new work. MIGRATING COMMIT HISTORY
● History migration limitation
A commit appears to map relatively well to the changeset or check-in model that your previous version control tool used, but there are some serious limitations with this translation.
● Risks of misleading
These differences mean that a full history migration will be lossy, at best, and possibly even misleading.
● “Tip migration”
Therefore we suggest to avoid importing history and instead perform a “tip migration”, bringing only a snapshot of the most recent version of a branch. MAINTAINING THE OLD VERSION CONTROL SYSTEM
● Keep old VCS
During and after a migration, it will still be needed to access to the history in the old version control system, so this can’t simply shut down after migration.
● “Breadcrumbs”
For large development teams and regulated environments, it is recommended placing “breadcrumbs” that point users back to the old version control system.
A simple example is a text file at the root of a repository, added as the first commit, before the tip migration, pointing to the URL of the old version control server. ORGANIZING THE SOURCE CONTROL STRUCTURE
● Large or dynamic binary files
Due to the way VSC stores history, you should avoid adding binary files to a repository, especially binaries that are very large or that change regularly.
● Manage dependencies
It is recommended removing checked-in libraries, tools and build output from your repository and instead using a package management system like NuGet to manage dependencies.
● Example: Git LFS
Small, infrequently-changed assets like icons can be included directly in a repository; since they do not change often, they will not bloat the history. But large or frequently changing assets should be stored using the Git LFS (Large File Storage) extension. PREPARING FOR THE MIGRATION
● Checks before migration
Before doing the real migration, it is needed to make sure that:
● All code files have migrated and there are no stray binaries in the repository
● Users have the appropriate permissions to fetch and push
● All branches are available
● Builds are successful, and all tests are passing
● Migration time
It is recommended to do the final migration at a time when few people are working, ideally between milestones when there is some natural “downtime”. Usually this is done over the weekend, when nobody is “checking in”. PERFORMING THE MIGRATION
In general, the steps of the migration process are:
● Create and clone repository
● Populate repository
● Remove binary dependencies and assets Current Modern ● Exclude tools and libraries version version ● Manage asset files (eg. Git-LFS) control control system system ● Convert version control-specific configuration
● Add a breadcrumbs file (optional)
● Add and commit the files
● Migrate branches VERSION CONTROL REPOSITORY • Choosing the Version Control Repository to use
• Using the repository CHOOSING THE VERSION CONTROL REPOSITORY
BitBucket GitLab GitHub Roundtable • Free private repos • Familiar interface • Great for (remote) team • The Roundtable Team • Simple setup • Easy setup collaboration server is built on Progress • Nice ui and tools • Includes many features, • Open source friendly OpenEdge • Unlimited private including CI • Easy source control • Easy version control repositories • Nice UI • Great community solution • Affordable git hosting USING THE REPOSITORY
● Example: Create a new repository on GitHub
● Use GitHub to collaboratively modify the project's code
● Log in and go to the GitHub home page and create a new repo
● Push an existing repository from the command line
● Push a branch to GitHub
● To push changes onto a new branch on GitHub,
run git push origin
● Extra(s)
● Create a Pull Request (PR)
● Merge a PR
● Get changes on GitHub back to the computer BUILD AUTOMATION • Build tool
• OpenEdge compilation tool
• Build syntax BUILD TOOL
● Using a build tool
● Most modern compilers feature the ability to compile and link code to executable binaries via command line, thus enabling automated builds.
● Choosing a build tool
● Common build tools are:
● Apache Ant, GNU make, Shell scripts, Maven, Gradle, MSBuild etc.
● Recommendation
● Apache Ant (https://ant.apache.org/)
● Open-source Java library
● Command-line tool
● XML based syntax OPENEDGE COMPILATION TOOL
● Progress Compilation Tools
● PCT (Progress Compilation Tools) is a set of Ant tasks, designed to automate work in OpenEdge environment.
● PCT is distributed under the Apache License.
● Working with OpenEdge
● PCT can also be used to work with OpenEdge databases, provides different tasks for various database operations and can generate class documentation using ABLDoc
● Using it with ANT
● Documentation: https://github.com/Riverside-Software/pct/wiki
● Download PCT jar from Maven repository https://mvnrepository.com/artifact/eu.rssw.pct/pct
● Copy the downloaded PCT jar to ANT_HOME\lib {P} pct ANT task for OpenEdge BUILD SYNTAX
● makebuild.xml
● Adding the databases (
● Handling with the Propath (
• Setting up the CI server CHOOSING THE CI SERVER
● Main criteria:
● Support for Build Automation Tool – PCT Ant
● Version Control Software Support
● Monitoring Support – memory, disk space, builds
● Easy Integration with Third Party Software – JIRA etc.
Jenkins TeamCity Bamboo •Most popular & easy to use •Mostly used for Java & .NET •Integrates with Atlassian Suite •Free •Integrates with InteliJ and •Rich documentation •More than 1000 plugins Pycharm •Commercial pricePoor plugin •Portable to all major platforms •Used only for Windows server support •Most used with OpenEdge •Commercial price •Poor plugin support SETTING UP THE CI SERVER
1. Manage Plugins – download and install repository (Github) plugins
2. Restart Jenkins
3. Create a new Freestyle project
4. Configure VCS (Git) in the Source Code Management section
5. Invoke PCT Ant build step by clicking on Add build step
6. Execute the build
7. Click on Console Output to see the progress of the build
8. Verify Workspace in the build job TAKEAWAYS
Continuous Migration to a Create a new Build Integration Documentation modern VSC repository Automation server setup
• Evaluate the current • Performing the • OpenEdge compilation • Setting up the • Create a VCS manual for tools and processes migration tool (PCT Ant) continuous integration daily use • Selecting a branching • Using the repository server strategy • Migrating commit • Migrate history branches • Organizing the source control structure THE FUTURE
Stop driving with the handbrake ON… GET INTO THE 6TH GEAR ! ANY QUESTIONS ? Thank you.
CONTACT: [email protected]
E [email protected] l M +40 743232464 l W www.tss-yonder.com A 77, 21 Decembrie 1989 St., Building A, 1st floor | 400604 Cluj Napoca | Romania