It has been a lot of time since I have written my book “Continuous Integration in .NET”. A lot of time at least in terms of modern software engineering. It has been almost 8 years. A lot changed in this time. I was starting to write the book still being a head developer in a middle-sized German software development company. Now I own myself a small-sized Polish software development company. These 8 years was a busy time. Building a stable company is a task that takes a lot of time. It was a time I neglected hobby. A hobby that made me write the book in the first place. How to make the work of a software developer easier by automation what is possible, making transparent everything that needs to be transparent, streamlining the software production and delivery process to a factory like state or at least abstracting the craftsmanship elements of software development in well-defined software engineering processes.

What we’ve build back then at my company was a solid set of tools that made outstanding job. In facts it makes outstanding job ever since. But it is a little bit rusty now. There are better approaches on the market now. For some customers we are using their toolchain, for some we are using our own. Some of our software engineering customers started to outpace us in their toolchains. Granted that they are putting a lot of money in their new shiny tools but nevertheless developers that tasted their toolsets were complaining about ours. And as usual among the developers no one really wanted to put-up with the mundane task of setting up a good toolchain. Ok, let it be that way. Let the developers be the developers and create software. I’m back in the game as a software engineering tinkerer. I’m back to set up a modern cost-efficient toolchain for a small but savvy software engineering company (MCET-SEC).

Where do we start:

  1. Code repository: SCMManager
  2. Build Server: Jenkins
  3. Issue Tracking/Time Tracking: Redmine

Simple and efficient setup. Back in the day it was like a modern truck. Now the truck is getting old. It still runs smoothly but you would like to have all the new features the new trucks have also.

  1. But we don’t have the means to do a peer code review in a formal way.
  2. Our continuous delivery landscape is limited to our local network and is based on local MSDeploy infrastructure.
  3. Our Issue Tracking/Time Tracking software lacks the release tracking/release notes functionality.
  4. As we’ve started having only software developers and no software testers, we virtually don’t have test management software. Now since we have both the developers and the testers the issue became apparent.
  5. With few people the licensing of the software we are using was no issue. With the number of people getting the teens it is starting to make trouble.

It is time to get it all right. I’m starting now (march 2019). Join me on the journey to build a MCET-SEC.

Leave a Reply

Your email address will not be published. Required fields are marked *