• Jenkins serving Cake: our recipe for Windows


    https://novemberfive.co/blog/windows-jenkins-cake-tutorial/

    Where we started, or: why Cake took the cake

    Before we started using Cake to build our Windows 10 applications, we used a similar setup, but instead of Cake we used an MSBuild script.

    What went wrong? Well, nothing! We could do everything what we wanted with the MSBuild script. In fact, the Cake build script does exactly the same thing our old MSBuild file took care of.

    So why did we replace the MSBuild script with Cake?

    The answer is pretty simple: MSBuild uses xml to configure the build task. Cake build scripts are written in C#. As C# developers we write C# code on a daily basis, which means Cake, unlike MSBuild, feels instantly familiar (and doesn’t have us researching syntax on a regular basis). This means writing and changing the build scripts is easier, quicker, and fewer mistakes are made. It also means that any developer can make these changes, without having to go through a learning curve first.

    Some more advantages for us were the fact that we can make identical builds wherever we want with Cake (on our local machine, Jenkins, …) and the fact that it offers a Visual Studio Code plugin with syntax highlighting.

    Our recipe: application lifecycle management via Git, Jenkins and Cake for UWP

    So how does our solution work?

    Jenkins fetches the changes from Git via polling; gets and commits any new translations from Phraseapp; and starts the default Cake task.

    Cake can then:

    • clean the solution
    • take care of the semantic versioning, based on git branches
    • restore the nuget package
    • perform the actual build of the applications
    • run unit tests
    • create an app package bundle
    • sign the app package bundle

    At this point, Jenkins kicks back into action. It archives the packages, in our case to Dropbox and to a dedicated server, and uploads the beta builds to Hockey app. It then notifies the developers and/or project manager via Slack when new builds are available or have failed.

    Now, let’s get down to the details to help you get the same workflow!

    Preparing your Cake

    Step 1: Preparing Git

    Only files necessary for building the application are checked in with Git. All other files, like binaries and helper files, are ignored. We do this via a gitignore. We have to ignore following folders: tools and build (a custom folder we created to temporarily store the build artifacts).

    To do this, simply add the following lines to the gitignore file; you can place them anywhere in the file.

    #Cake
    build
    tools
    

    Step 2: Acquiring Cake

    You can download Cake from the website, install via Powershell or use the Visual Code plugin to acquire it. You only need two files to start working with Cake. You can place these files anywhere in the repository, but we prefer to place them at the root.

    • build.ps1: The bootstrapper powershell script. This file downloads Cake and its dependencies when needed. It contains a basic configuration and will start Cake.
    • build.cake: This file contains our buildscript. It will have some basic configuration by default.

    With these files in place, we can run Cake for the first time. To do so, start powershell with administrator rights. Go to the root of your repository, for example:

    cd c:projectsExampleApp
    

    Execute the bootstrapper script:

    .uild.ps1
    

    That’s it! You should now see something like this:

    Step 3: Customizing the bootstrapper

    In our company, we use three build types (build configurations in Visual Studio), which are aligned on all platforms:

    • Debug: For development only
    • Beta: For beta distribution and testing
    • Release: The actual store build

    The bootstrapper file (build.ps1) supports only Debug and Release by default. To better suit our needs, we replaced [ValidateSet("Release", "Debug")] with [ValidateSet("Release", "Beta")].

    Step 4: Making our Cake file

    First, we clean up the solution and remove the old build artifacts, to make sure we start with a clean slate:

    Task("Clean")
        .Does(() =>
    {
        // Remove old build artifacts from the build output folder
        CleanDirectories(projectPath + "/AppPackages");
    
        // Clean the solution, uwp supports multiple platforms
        foreach(var platform in supportedPlatforms)
        {
            MSBuild(solutionFile, configurator =>
                configurator.SetConfiguration(buildConfiguration)
                    .SetVerbosity(Verbosity.Quiet)
                    .SetMSBuildPlatform(MSBuildPlatform.x86)
                    .SetPlatformTarget(platform)
                    .WithTarget("Clean"));
        }
    });
    

    Next, we set up the semantic version of the app, using the GitVersion Tool. This version will be added in AssemblyInfo.cs. The GitVersion Tool is not part of the default Cake installation, so we have to add an import on top of the Cake.file:

    #tool "nuget:?package=GitVersion.CommandLine"
    
    Task("Versioning")
        .IsDependentOn("Clean")
        .Does(() =>
    {
        GitVersion(new GitVersionSettings {
            UpdateAssemblyInfo = true
        });
    });
    

    The next step is using a default command to restore the packages.

    Task("NugetPackageRestore")
        .IsDependentOn("Versioning")
        .Does(() =>
    {
        NuGetRestore(solutionFile);
    });
    

    After this, we define the actual build. We do this multiple times, once for each platform.

    Task("Build")
        .IsDependentOn("NugetPackageRestore")
        .Does(()=>{
        foreach(var platform in supportedPlatforms)
        {
            MSBuild(solutionFile, configurator =>
                configurator.SetConfiguration(buildConfiguration)
                    .SetVerbosity(Verbosity.Quiet)
                    .SetMSBuildPlatform(MSBuildPlatform.x86)
                    .SetPlatformTarget(platform)
                    .WithTarget("Build"));
        }
    });
    

    After the build of the application, we run all our tests. In this example we run only unit tests. All the names of our unit test projects are ending with “.UnitTests”. We can use a wildcard to find all our test projects.

    Task("Test")
        .IsDependentOn("Build")
        .Does(()=>{
        MSTest("./Tests/**/*.UnitTests.dll");
    });
    

    As final step we sign the generated appxbundle. This is needed to install the app on Windows 10 mobile. If you want to install the app on a PC, just zip all files, because HockeyApp supports only one file for each app.

    Task("Sign")
        .IsDependentOn("Test")
        .Does(()=>{
    
        if (!buildConfiguration.Equals("Release"))
        {
            var appxBundles = GetFiles(projectPath + "/AppPackages/**/*.appxbundle");
    
            Sign(appxBundles, new SignToolSignSettings {
                    TimeStampUri = new Uri("http://timestamp.digicert.com"),
                    CertPath = "certificate.pfx",
                    Password = "Password"
            });
        }
    });
    

    The full file should look like this:

  • 相关阅读:
    [linux]无法加载so文件错误
    linux找不到.so文件的解决方法
    [Linux]core文件调试方法
    LINUX下cp f无效问题
    解决IE无法查看源文件问题
    批处理获取exe返回结果
    不得不知 云计算入门必备的60条术语
    NMS
    开启和关闭(禁用)IE8加速器功能的办法
    钩子函数
  • 原文地址:https://www.cnblogs.com/chucklu/p/10668762.html
Copyright © 2020-2023  润新知