Continuous Integration
-
MCET-SEC 6: Schedule / Essential tools
Since I’m running behind the schedule here with what I wanted to have by now, I thought, I share… this schedule. What I have in my pipeline while creating MCET-SEC – modern cost-efficient toolchain for a small but savvy software engineering company. 1. Modern repository (system that not only holds the source code but enables collaboration – pull-requests, commenting and so on). -> This is done. With one false start with Gogs, resolved with Gitea. 2. Test Management Software. -> Done and working fine with TestLink. 3. Build server. -> Done with Jenkins. 4. Continuous deployment/delivery. 5. Static code analysis with central reporting. 6. Test automation. 7. Ticketing/issue tracking/time tracking.…
-
MCET-SEC 4: Build server
All right, all right! I will look into at the Docker while building my cost-efficient toolchain for a small Windows minded software engineering organization. Docker was the immediate feedback I’ve got from my developer at CODEFUSION. “Are we building our toolchain using containers?” – they’ve asked. “Nee!” – I’ve replied. Not because I have something against. It’s actually the other way around. It is because I do not have any experience with containers. I’m a Windows person. I know that Microsoft is all about Docker, but I have no time to learn I thought. Then I’ve started to set everything up on Windows. Repository with pull-request functionality based on Gogs…
-
MCET-SEC 2: Repo
This is the second part of the series MCET-SEC where we create a modern cost-efficient toolchain for a small but savvy software engineering company. I run a small development company of 10+ developers. We specialize in Microsoft .NET development (desktop, web, services) but we are doing a lot of in modern web (like Angular/TS) and mobile (Xamarin, native Android and iOS). It was a while since I’ve written “Continuous Integration in .NET” and build the toolchain for my company. It is time to renew it. Lets start with the repo. Repo it is a common name given by software developers to the most important tool in our toolset: a source…
-
MCET-SEC
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…
-
Machine Learning 4 Continuous Defect Prediction
Defect prediction is a set of techniques used to identify a likely buggy software change (eg. a commit). Various measurements from previous changes are taken into consideration to predict weather a new change is likely to contain a bug or not. Commit messages or bug tracking system entries are usually examined to gather the measurements. Machine learning is often used to classify the buggy/clean changes. We are working now on adding a continuous notion to defect prediction. On one side by building on top the idea of continuous defect prediction in the IDE (Integrated Development Environment). On the other side by perfecting the prediction by using the unambiguous results of…
-
Scaling CI–switching poll to push
Scaling CI has many flavors. For example: When: Code base / test no. increases -> build time increases, Teams grow, No. of projects grows. Then: Create targeted builds (dev build, qa build), Write fast unit tests, Smaller teams with local integration servers, Modularize the code base: Scale hardware, Add more build agents, Parallelize. and last but not least: Ease the source control system. Let me show you how to make Subversion and (TFS) Git pro actively inform Jenkins CI about changes in source control. The most straight forward way to let the CI server know that something changed in the repository is to configure polling. What it means is that…
-
Vanilla build server and a little NuGet gem
Vanilla build server is a concept that says that the build server should have as few dependencies as possible. It should be like vanilla ice cream without any raisins (I have raisins in ice cream). Let me cite the classic (from: Continuous Integration in .NET): “It’s strongly suggested that you dedicate a separate machine to act as the CI server. Why? Because a correctly created CI process should have as few dependencies as possible. This means your machine should be as vanilla as possible. For a .NET setup, it’s best to have only the operating system, the .NET framework, and probably the source control client. Some CI servers also need…
-
.NET Developer Days 2014 Conference
I will be speaking at .NET Developer Days 2014 in Wrocław, Poland. The conference will be held between 14th and 16th October 2014 at the City Stadium in Wrocław. The topic is “Continuous integration and deployment in .NET with Jenkins CI and Octopus Deploy”. Here is the conference website: http://developerdays.pl/.
-
Waiting for the first .NET wrist watch
Almost a year ago there was a Kickstarter campaign to found a first .NET Micro Framework watch: Agent smartwatch. Nice thing about it is that you will be able to program it using C# and Visual Studio. While we are still waiting for the product there is a SDK with an emulator. It is from the same guys that gave us Netduino! I decided to check it out. Think about it: you have a Continuous Integration server running your builds and you want to monitor it on the fly. Is there a better device to do it than a wrist watch? So I thought and decided to check it out.…
-
Eventful week
Last week was quite eventful. I’ve talked about Continuous Integration in .NET and about how do we use it at my company CODEFUSION at the IT Academic Day 2013 at the Opole University of Technology (OUTech). It was an event organized by the .NET Group from the OUTech and Microsoft Poland. The auditorium nearly full! Of course I’ve showed my funny CI gadget "Great Integrator Helmet". It connects wirelessly to the CI server and transfers a feedback about failing build by blinking and hauling. As usual it was very well noticed by the auditorium And since we are at the topic of tinkering with electronics: I’ve described how to build…