All the software we write
Códice has been around since 2005, when we decided we wanted to create a better version control system. Since then, we have created Plastic SCM, a solid version control system that many teams of all sizes around the world pay to use. And it is important to note that they had many options to simply grab a version control system without having to pay a dime, but they opted to purchase our software, and keep us in business.
Well, today, I'm writing down the list of all the software components we develop, just to share with the team and users, the scope of the products we make here at Códice Software.
Plastic SCM
It is our main product. The one that makes us tick. The one generating the bulk of the revenue. And the biggest one too.
It has the following components:
Server
Runs on Windows, Linux and MacOS. Includes:
- Logic for version control operation: Includes merge logic, checkin, update/download, security, LDAP integration.
- SQL Datalayer: Storage in up to 7 different database backends: MySQL, SQL Server, Firebird, SQL Server Compact Edition, Postgres, SQLite and Oracle (although this last one is deprecated).
- Jet Datalayer: File-based storage for super-fast operation. It is the default right now.
As the following graphic shows, the server only accounts for an overall 8% of the total Plastic SCM codebase.
Cloud Server
It is a multi-tenant, horizontally scalable service to host Plastic repositories in the Cloud. It reuses most of the server code but with a different storage (SQL Azure + extensive use of blobs), different caches (to be accessed by multiple roles), and different synchronization mechanisms (again, to go from multi-thread to multi-role). It is hosted in Azure.
Command line client
Also runs on all platforms. We call it "cm" (which stands for configuration management and was inspired by the old days "ct" command which was short for Clear Tool in ClearCase).
JavaCM
Command line client built in Java using bytecode translation. Allows us to run on Solaris and HP-UX (rare cases).
GUIs
- Windows GUI: It is the first one we wrote and it keep evolving since the first version back in 2006. It is almost entirely written in WinForms except for the diffs that are WPF.
- Linux GUI: It is currently developed using GTK Sharp. Runs on Mono as all our software in Linux (at least until we migrate to .NET Core).
Before moving to native implementations on MacOS and Linux, we used to have a cross-platform GUI. See the following screenshot:
It is an old version of Plastic GUI running on Solaris (not that it was officially there, but I always like to show this photo). We used WinForms and Mono's implementation for the 3 platforms, which forced us to stay away from specific components (like editors) in each platform. It was good development-wise because it was a single code base, but it was totally alien on MacOS (Linux users are somehow more permissive about it). It wasn't free of glitches, anyway, and it never was as solid as we wanted due to Mono WinForms limitations. That's why we decided to go for GTK.
- MacOS GUI: Built using Xamarin.Mac, a wrapper on top of Cocoa for C# developers. As mentioned for Linux, once the MacOS GUI was WinForms, but we decided to go native years ago.
- Gluon for Windows: Entirely WinForms. We use a library for the white look and feel. It seemed like a good idea at the time, although now I believe we should give it the same aspect as the classic GUI in Windows.
- Gluon for Linux: GTK Sharp.
- Gluon for MacOS: Xamarin.Mac.
Mergetools and diff tools
Xmerge/Xdiff is what we call our diff/merge tool. Think of it as our own KDiff3. It can work as a standalone side-by-side diff tool or 3-way merge. It is packaged together with Plastic. It can do unique things like fragment move detection, which was our first step towards semantic version control, but without code parsing.
As all the GUIs, it runs on 3 platforms: Windows: WinForms + WPF, Linux: GTK Sharp and MacOS: Xamarin.Mac.
IDE integrations
- Visual Studio. Written in C#. Reuses part of the Windows GUI code.
- Eclipse. Entirely written in Java.
- IntelliJ. Written in Java.
SCC compatibility integration
Standard version control integration protocol for very old Microsoft Visual Studios. No longer in use in VStudio, but still around to ensure teams using things like MatLab, and other special software.
Windows Shell Extension
Written in C#. Like a Tortoise SVN Explorer integration but for Plastic.
Unity plugin
Integration with the famous game engine.
Unreal plugin
Developed by a third party. Just added in the list for completeness, but not really developed by us (fortunately).
WebAdmin
Web interface to administer the server. We replaced some old GUI-based tools with a web interface, and made it cross-platform at the same time. It was first released in late 2017. Uses ASP.NET Core (not exactly, but close). More about it here
WebUI
Web interface to list branches, repos, browse the contents of branches, diff code and even do code reviews. We completely rewrote it from scratch in 2018 using VueJS + ASP.NET Core. Now it is embedded in the server so no separate setup is required. The old one required separate setup + IIS/Apache and was hell (it was around for about 9 years, anyway).
More about the new one here.
This new version includes built-in semantic merge, which is very cool.
Plastic Drive
A way to mount a changeset tree as a virtual Windows drive :). It uses Dokan underneath.
Continuous Integration plugins
- Jenkins. Written in Java. Published on the Jenkins site.
- Bamboo. Written in Java.
- TeamCity. Written in Java.
Integration with issue tracking/project management systems
Polarion, Jira, Axosoft Ontime… up to 9 systems.
Network layer
For years we ran on top of .NET Remoting. While it is still supported, we implemented our own ad-hoc protocol based on top of plain sockets. The .NET Remoting implementation was heavily customized to support SSL, metadata compression and UDT transport on Windows, to mention a few.
SemanticMerge
Written in WPF. Version 1 was cross-platform. Version 2 (around for a couple of years) is Windows only. Future plans to have Linux and MacOS versions.
gmaster
Written in WPF. Windows-only. Reuses the entire SemanticMerge codebase and adds more features. Includes a more powerful license and upgrade systems.
www.plasticscm.com
Contains 2 parts, the "public side" that you can navigate without login, and the "private" part where customers need to login to access their data.
In September 2018, both public and private areas were ported to ASP.NET Core and hosted on Azure.
The private part includes license generation, billing, integration with SalesForce and email marketing automation. Billing is implemented with Stripe. (Deprecated PayPal is still supported).
www.semanticmerge.com
Composed of 2 parts. The public is in ASP.NET Core. The private is in old ASP. Private handles license generation and billing based on PayPal.
www.gmaster.io
Entirely developed in ASP.NET Core and hosted on Azure. Billing platform available but not yet operational.
TTS
Our own issue tracker system. We considered it many times about making it commercial, but the time hasn’t come yet. It is entirely written in PHP. It is older than Códice, since it was originally created back in 2002 long before Códice Software and Plastic ever existed.
We totally rewrote it in ASP.NET Core back in 2017 during a hack week. The reality is that we continue using the old version, because we didn't finish some of the features, although it is 90% there. We used the hack week to get up to speed with ASP.NET Core, which we later used for the WebAdmin.
HAL
Our own CI system. Includes orchestration software to run tests on virtual machines, including starting, stopping and monitoring VMs both on-premise and on Amazon (Azure support deprecated). It has its own DSL to define where tests run, define parallel blocks, serial ones, etc. Part of it was finally made a product as part of the DevOps "mergebots" product (part of the Plastic SCM server).
PNUnit
Parallel NUnit. Our decade-old contribution to the NUnit project to run tests in parallel.
We have a very old video (although recently published on YouTube, it dates back to 2007) where we show how we used PNUnit to run tests in parallel.
Test code
I wasn't going to add it as a category on its own, but really a lot of test code is present. We basically have 3 types of tests:
- Unit tests. We have thousands of them and they are super-fast and easy to debug. God bless unit tests :-)
- Smoke tests. It is the name we give to tests that automate the command line using PNUnit. For years they were our main test suite (we always had NUnits, but they were not as important as they are today). A typical smoke test starts a client and a server, and provides mechanism for the "client test" to wait for the server to be ready. The same test can be run on different machines and operating systems just modifying the configuration. I mean, you have a "test checkin with changes" test and you can run it with a Windows server and client, Linux server and client, and all the combinations in between. Very useful. We have a little bit more than 800 of these. Problem is that each one takes around 10 seconds to finish... and since we run the 800 tests in several combinations, this means a lot of time and we need to run them in parallel in about 40+ virtual machines, both on-premise and hosted on Amazon.
- Windows GUI tests. For years, we developed a suite of 100+ tests using TestComplete. We are still bound to a very old version. They are fragile and a pain to write, although the entire team got quite proficient in dealing with all the glitches in our tests.
- Cross platform GUI tests. We needed to write some tests for the Linux and MacOS GUIs. Since we didn't have a commercial product for that, we wrote our own suite. You can see them running on Linux and MacOS on YouTube. With GUI support coming to .NET Core, it is probably worth it to contribute our super small GUI testing platform. It is currently able to automate tests for Linux/GTK, MacOS/Xamarin.Mac, Windows/WinForms and Windows/WPF, and the tests themselves are written in C#/NUnit format.
0 comentarios: