Which is the Best Source Control Manager!

In the software development industry, there are a lot of tools available to help manage code changes. But which one is the best? In this article, we'll take a look at three of the most popular source control management systems - Git, Mercurial, and Subversion - and see how they stack up against each other.

Source Control Managers

There are many different source control managers (SCMs) available, each with its own advantages and disadvantages. It can be difficult to decide which SCM is right for your project, but in this blog post we'll compare some of the most popular SCMs and help you make a decision.

Git is a very popular SCM, especially among developers who work on open source projects. Git is distributed, meaning that every developer has a complete copy of the project history, and it's easy to create and merge branches. Git also has good support for non-linear development, so it's perfect for projects that require frequent branching and merging. However, Git can be difficult to learn and use, and it doesn't have as many features as some of the other SCMs.

Subversion (SVN) is another popular SCM. It's centralised, so there is only one copy of the project history, but it's easy to check out and check in changes. SVN also has good branch management features, so it's a good choice for projects that need to manage multiple branches. However, SVN can be slow when working with large projects, and it doesn't have as many features as Git.

Git

There are many different source control managers out there, but which one is the best? That really depends on your needs and preferences. However, one popular option is Git.

Git is a free and open source distributed version control system. It is designed to handle everything from small to very large projects with speed and efficiency.

One of the great things about Git is that it has a huge community behind it. This means that there are many resources available if you need help, and you can also find plugins and extensions to customize Git to your needs.

If you're looking for a powerful and flexible source control manager, Git is a great option to consider.

hg

There are a lot of different source control managers out there, and it can be hard to decide which one is the best for your project. If you're looking for a powerful and flexible tool, then hg is definitely worth checking out. Here are some of the reasons why hg is a great choice:

- You can easily create and manage multiple repositories with hg. This is handy if you want to keep different parts of your project separate, or if you need to work with other people on different parts of the codebase.

- hg has excellent support for branches, so you can easily experiment with new features without affecting the main development line. This makes it ideal for managing complex projects.

- The built-in merge tool is very effective, so you shouldn't have any problems reconciling differences between various versions of your code.

Overall, hg is a great choice for a source control manager. It's easy to use and very flexible, making it a good fit for both small and large projects.

svn

svn is a great source control manager because it is very easy to use and it has a lot of features that makes it very powerful. It is also very stable and it is used by a lot of large companies.

CI/CD Integration

There are a lot of options out there for source control manager (SCM) software. So, which one is the best? It really depends on your needs and preferences. However, some SCMs are better than others when it comes to integrating with continuous integration/continuous delivery (CI/CD) pipelines.

If you're looking for an SCM that will integrate well with your CI/CD pipeline, here are a few of the best options:

• GitLab
• GitHub Actions
• Jenkins - It plugs into EVERYTHING!

Each of these SCMs has its own strengths and weaknesses, so be sure to do your research before making a decision. Ultimately, the best SCM for you is the one that meets your specific needs and integrates seamlessly with your CI/CD pipeline.

Azure DevOps

Azure DevOps is a cloud-based source control manager that helps organisations manage their software development process. It includes features such as Git repositories, work item tracking, and build pipelines. Azure DevOps is a great tool for managing source code, especially for larger projects or where the enterprise is plugged into the Microsoft toolkit.

Jenkins

If you’re looking for a feature-rich source CI/CD system to plug into anything, Jenkins is a great option. It has a lot of bells and whistles that other source control managers don’t have, such as modular support for all Source Control Managers.

On the other hand, if you need something simpler, another option might be better for you. But if you want the most features and flexibility, Jenkins is hard to beat.

GitLab/GitHub Actions

GitHub Actions or GitLab pipelines are powerful tools for automating your development workflow. It can be used to build, test, and deploy your code. With GitHub Actions, you can easily create workflows that are triggered by events such as pushing code to your repository. This makes it easy to automate your development process and save time.

Round Up!

If it wasn't obvious from the subliminal images posted throughout this blog, it is a pretty clear choice that git is the future and we are not going to see many cases of the other SCMs coming back into play anytime soon. I do admit I will boot up a mercurial repository once in a while for old time sake. However, git even as a native package has everyone you would need to run a project from small scale to enterprise!

Coupled with the above, the way that cloud providers and CI/CD systems are integrating together to make a more DevOpsy and friendly environment is just building the cadence for developers to build bigger and better things without having to worry about the low level intricacies of their source code - I for example (and despite M$ now owning it...) will use GitHub while it is a free service. But then I also have small private projects on GitLab and BitBucket... not much to see there! 

At the root of all the above services, we have Git which has clearly won the SCM race, Well Done Linus! You did it again! 

Jenkins and PHPUnit

Starting from the Beginning

This blog post is another rehashing from the past, bringing some of the older knowledge forward, a lot of it is still relevant today to see behind the scene of the automation technology we are using and in that, gain understanding on how to improve it for the custom functionality we need in today society with modern enterprise. 

The following Blog was co-authored with my senior developer at the time (Zdenek M - Happy to link out, give me a shout, Buddy!) and has helped a number developers and sysadmins integrate Jenkins into their workflow with a variety of different plugins.

This isn't JenkinsX or Pipelines

No, that is correct! This is a very old school method of dealing with things. However, it does show off how the old Hudson (original fork of Jenkins and core code) can handle its plugin architecture.

The Article:

Continuous Integration is the process where code from a developer's repository is called by an automated system, built and tested against a set of standards that the developer has created in their tests. In this post we look at the steps to create a server that will automate your testing suite - and hopefully make you more productive... I have even tried to emulate the links going to website of that time via the Internet Archieve: Wayback Machine!

While working for a PHP Developer shop, we used to have a number of different tools for continuous integration:

• Xinc – to run PHP unit tests and integration tests
• PhpUnderControl (CruiseControl) – to run functional tests
• PHP Unit Testing framework
• Selenium RC Server – standalone server for launching functional tests in web browser

Using all these different tools made things very confusing, and our sysadmin had to learn all these different technologies to try and keep a CI single system together. Some of the main issues with this configuration were:

• Xinc – could be tricky to configure, it looks like a PHP application but doesn't behave like one, it has poor documentation, and to have Git support you have to migrate to the latest version
  
• PhpUnderControl – did a really good job for us over the years, but the project looks half dead and project XML configuration can be quite tricky
• Selenium Server – to be able to run tests in a web browser (Linux) we installed full X Server, which is not the best solution from resources point of view: it needs at least 2GB of RAM
  

To consolidate these systems and their configuration we opted for Jenkins CI which is a continuation of the old Hudson project, available under Creative Commons License, aimed at making CI as easy as possible to implement. The beauty of Jenkins (apart from its single tool structure that contains all CI elements) is that it is a single tool with a pretty, easy GUI that enables easy configuration of a project so that it can be tested.

Another massive benefit is that Jenkins is one of those brilliant tools (like Git) that is so customisable that you can bend it to work in whatever way you need. In this post we shall be looking at how Loft implemented Jenkins into our workflow practices.

So, let's get started...

While planning the server, we listed what services we would need from it:

• Git and SVN abilities - for getting the projects out of our repositories
• PHPUnit
• Xdebug
• Selenium Server
• JUnit - for reports
  

(Not part of the plan but added for fun:)

• Clover reports - code coverage

Once we had the plan the next step was the build...

Jenkins installation

First, we needed a server to set up as our Continuous Integration server (henceforth referred to as CI server). This was to be a Linux Box as it is far easier to work with than a Windows box, as well as  more secure and cheaper. A disadvantage is that you can't run tests in Internet Explorer on this box.

Luckily for us, Jenkins has it's own repo which can be installed on almost any distribution of Linux that has it's own package manager (Such as Yum or Apt). For RHEL and similar you can install the repository with:

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
         

And for Debian/Ubuntu:

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins
         

This will do all the hard work of installing Jenkins to the server that we are working on, so all we have to do (as root) is start the service:

/etc/init.d/jenkins start

This will start Jenkins and the Jetty (Java-based webserver) that it runs on. Like us, you may decide that the Jetty is not fit for your purpose and might look for something like NginX or Apache to handle a proxy pass to the Jetty which will give you some extra security to hide your Jenkins Interface behind.

Most of Jenkins is very configurable from the management GUI. From this web page you can download and install new modules to the server which will allow you to use different tools to work out more information about your code and project. These plugins.... do just that: they plug into the project configuration area, which enables the user to add more build stages to the project and extra tests.

Selenium Server requirements

For functional testing we use Selenium Tests with the Selenium RC server to control requests to a web server which acts as a real user going through the site, clicking on links and filling in forms, all the while taking pictures of problems and assessing that all the correct information is displayed on the page. One problem with these tests is that they require a GUI or some form of desktop to use the web browser. In previous set ups of CI, Loft tended to use a Full Blown Desktop (Gnome or KDE) which made our sysadmin's life trickier.

In this case we decided to install a different type of GUI on to the server: one that could still be viewed over an encrypted VNC connection and give access to the web browser that Selenium is running, but would also be light enough that it would not impact on the CI potential of the server.

To remedy this we used a combination of:

• xvfb - as the X server
• x11vnc - acting as the vnc server with the -shared -forever -localhost options set
• Firefox - the web browser
  

The installation of the above allowed us to configure a display on xvfb which acted as a blank x server. On top of this platform we could call our web browser to run the selenium tests.

Configuring the PHP project

To run tests, you need a few extra plugins, which are easy to install through Jenkins plugin manager:

• Jenkins Mailer Plugin – to be able to send emails
• Git Plugin – to update tests / code
• SeleniumRC plugin – if you want to run Selenium tests
• Clover PHP Plugin – to be able to publish code coverage
• xUnit Plugin – for publishing test results

The project has a few sections which enable you to configure what to run, when to run it, and what to do with results.

1) Update code / Tests

Jenkins has excellent support for VCS – SVN, GIT – you can choose or even combine different repositories to update tested code or tests.

2) Build trigger

You can choose when the build is started. We use the option to Trigger builds remotely for builds triggered by post-commit (receive) hooks from Git.

Here is a sample post-receive hook used in a Git repo:

  #!/bin/sh 
   PROJECT="/var/www/vhosts/project"
   cd $PROJECT || exit
   unset GIT_DIR
   git pull
   #start jenkins
   wget http://jenkins:8080/job/project/build?token=sdsdjsdjksdjds787jk -O /dev/null

Or for functional tests we use the Build periodically option – for example to run tests every 4 hours.

3) Build

In our case, just a simple command to run all unit tests:

phpunit --log-junit results/phpunit/phpunit.xml -c tests/phpunit.xml  

4) Publishing results

Because we export test results to junit format, we can use JUnit (Java Unit test) Publish to publish results:

5) Notify developers

By publishing results, Jenkins knows if the build was successful or not. If not, you can notify developers - or even point a finger at the person who broke the build!

6) Selenium

If you need to start the Selenium server, you can start it for every build or check that server is running:

7) Code coverage

Code coverage is optional, but it can give you very interesting information:

Round Up!

So as you can see - it's an absolute breeze, far easier than in the past. I recommend you give it a try or expand to get in to the practice of CI/CD, it's not just for big businesses these days with most SCMs now offering a CI/CD testing facility dictated by a YAML file in your repository.

With the above you can even see how the beginnings of Jenkins Pipelines began to form with similar requests being handled with the above console, just now in a "Groovy" (Not so groovy!) Jenkinsfile!