Automation builds the key to consistency

Android Studio uses Gradle to build Android apps, and in the Eclipse era, ant is the default, and Java programs are actually ant. I am not a trained, even in the training course, also did not involve ant (perhaps I did not understand anything at that time, did not notice?) When you look back at the video, note that in case it's really used, it's up here, let alone gradle.

What does not mean to know, the above is to mention Gradle,ant, even maven, more ridiculous. Foreigners are also really interesting, like to take a dictionary can not be found in the word as a tool for the name. We too, for example, the city will play. In fact, Gradle,ant, and MAVEN, are automated building tools. That what is the automated build tool, I Baidu a bit, do not despise me to use Baidu, in Google left these years, China's Internet, especially the rapid development of mobile Internet, the domestic Internet resources is very rich, can say, Baidu also can give me the answer that I want. But the quality of resources is not much, or need Google. Baidu Encyclopedia, said and textbooks in the approximate, let me feel difficult to understand, but Baidu know that there is a good answer, very image, although still not very clear, still need to study carefully later, but it is enough for me to uncover her veil:

Source: Http://zhidao.baidu.com/link?url=hCN2ZiHewINctxVUkQPmneueSu9aiCN5y23BdRHzAs3fE5pWXxKdxfoqeDMwM-CLgD7NawLdeLQiuJBsNqC1Bq

Cut a picture, for those who are too lazy to open the link.

But this sentence alone is not enough to make me fully understand what she can do for us in practice. And then I went to the following article, let me understand that the existence of automated construction, but also let me understand the gradle deepened some. This article is also an English translation.

Original link: Automated build: The key to consistency

English original link: http://www.infoq.com/articles/Automated-Builds

Here, I'll do some excerpts:

Introduced

If there's one thing a software developer is good at (not quoting the movie "hacker"), it must be automating tasks that normally need to be done manually. Getting computers to handle repetitive tedious tasks will make life easier for everyone, and here we talk about how to focus on what they care about. However, the research and development team often ignores the most helpful audience-themselves.

In a large number of small and medium-sized software workshops, there is no automated build and publish tool. Building, staging, and code publishing are all done by hand, as well as running tests, backing up older versions, tagging new versions, and many other repetitive things. After all, you might think that this is all very simple work, the integrated development environment can be built by buttons or shortcut keys, you open two windows to drag and drop a few files or folders to complete the site publishing. But when you're maintaining the code base and the app, all of these things add up, and here a few minutes, there are a few minutes, and eventually a few hours of wasting.

Fortunately, it is easy to solve the problem. Basic automated building solutions are easy to deploy, highly customizable and inexpensive. This article describes some of the motivations for building an automated process, and some of the concepts you will need to touch. The second part of this series will describe the target. NET solutions, but these technologies are applicable in any environment.

What problems are we trying to solve?

Before we get into it, let's look at some of the problems we're trying to solve. Not all of these issues exist in your organization, but if you look closely at your team, you'll see that there may be some problems, and it's likely that the rest of your build process might be a bit of a job.

Inconsistent builds: Writing code in an integrated development environment is a wonderful thing. However, this is a cost that is typically handled by the integrated development environment or the operating system, such as the framework/runtime version, the output structure, the compile/debug version, configuration settings, environment variables, and compilation options. It seems like a good thing, but unless you're using exactly the same development machine, if the developer doesn't pay attention to these details, the same code base, different developers will get different output.

Incomplete builds: Most of us have felt guilty about bad source control practices. We may have forgotten to submit a bug fix, or forgot to update the latest code before compiling to get other people's changes. When this occurs in a human-built environment, the code that is about to be released is not up-to-date. We need a solution that guarantees that you are releasing the source control system that is always present.

Failed unit tests: unit testing is an integral part of any good application, and if used properly, it helps to avoid introducing new bugs while fixing bugs. However, writing tests is far from enough. You have to perform all the tests on a regular basis, and it's easy to forget when something needs to be done yourself. No one actually performs these tests, so some unit tests may not pass and you never know.

Human error: Even well-orchestrated simple processes are prone to human error. We've all had fingers hovering on the keyboard but accidentally hitting the wrong button, or accidentally removing the OS kernel (which happens more often than you think). Or at 1 o'clock in the morning, when we were sleepy, we accidentally turned on the official server as a test machine. This is unavoidable because no one is perfect, so anything that requires human interaction can go wrong.

Security: Server and network security is always handled by a separate software team. There are usually two extremes, or there is a limit to the server connection, to which no one can access the red tape of training new employees for one months, or if the server is open to everyone, the malicious clicks of any member of your team can ruin the system. As a developer, I usually prefer the second scenario because I can actually do things well, but I see the danger of doing this. No matter where your organization is in this area, automation will only improve your process.

What do we need to do first?

Once you have identified the main pain points for your team, you can design a solution for your needs. There is no universal scheme. As long as you have an automated build, it can reduce the human operation and make things consistent, you go the direction is right.

However, you really need a lot of things.

You have to start contacting good source control practices. Whether you're using SVN, Mercurial, Git, or TFS (don't use SourceSafe), you need to define such branching strategies, how to handle third-party and internal libraries, and how to organize projects in a warehouse. Of course, your team has set sail. When someone does something in a small project and does not follow the rules, they can screw up the whole process.

You must have a developer as an automated build engineer. This person will be responsible for writing build scripts, building a continuous integrated development environment, and most likely also responsible for the building and deployment of source control systems. Unless you have a large and complex environment, these jobs should only take up a fraction of his time, so he spends most of the week doing regular development work.

Even if you want to never use it, there should be a contingency plan in the process, like any other mission-critical program in your organization. The compile server is likely to become a single point of failure, it is likely not to have the ability to load balance, and there will be no hot backup to prevent server downtime. In this case, you want to make sure that you can quickly build a new server, complete configuration and permissions settings, and have a plan B that does not use the build server. Although the goal of the implementation is to never do anything manually, it is always possible to ensure that it is feasible.

Build Scripts

The automation of the build process relies on simple repetitive tasks. The first step is to write the build script. A build script can be any form: A batch file/shell script, an XML-based task set, a configurable program written by itself, or any combination of them. In the. NET world, MSBuild is a command-line feature provided by Microsoft that uses XML-based project files to build a Visual Studio solution. Nant is another common. NET build script tool, similar to the popular Java tools Ant. Others include rake in Make,ruby, which is common in the open source community.

No matter how you choose to write your build script, you should look for ways that are right for you and keep going. For example, once you find the best way to build a Web program project, creating a build script for a new Web application should be simple, as long as you copy the script from another project, modify the partial name, and the path.

The implementation between the operating system and the programming framework is obviously very different, but the idea is basically the same. The script should complete everything you normally do in the build/compile/delivery readiness environment. Typically, this means compiling the code, using specific compilation options, saving the output file and the original code base separately, and preparing for deployment. Even in projects that do not need to be compiled, such as static Web sites, there may be content that is not dynamically updated in the project, such as test pages or debug scripts, and you want to manage the content uniformly in the source control system, but when you do want to deploy, the build script will not publish the files when they are delivered to the staging environment. So you don't need to think about these things every time.

In addition to the basic build/compile/delivery readiness environment steps, you can actually do whatever you want. Want to compress JavaScript files? Create a task for it. Need a unique timestamp in the code before compiling? Create a task. Do you need a data encryption algorithm in order to keep the Web site from falling into your opponent's pocket? Add a task (ask someone for help). In the build process, what you can do on the command line can be executed before and after the code is compiled.

Most software projects have more than one module. For example, you might have a Web application, but you also have a separate database, which is part of the overall solution. For this scenario, a single control script is the workaround. The script is a controller that invokes a separate script each time. There are scripts in each Visual Studio project, in a Java package, or in a custom code structure. Each individual script has a task specific to that project, and the control script contains all the shared features.

Make scripts as common and reusable as possible. Use relative paths, do not use absolute paths, specific project information is defined in one place, reusable information is defined in the control script. This is easy to maintain and helps to build new projects in the future.

Continuous integration

Once the script is written, the project can complete the compilation and delivery readiness environment with a single command. It was a good start, but someone had to execute the order. Our goal is to remove human intervention, so continuous integration will consider these for us.

As for building scripts, there are many different techniques to choose from, and the way projects are organized is varied. But again, you'll want to find a solution that's right for you and stick with it to keep it consistent in your project.

Some popular options are teamcity, Jenkins, CruiseControl (or cruisecontrol.net), and if you prefer a multipurpose application, Microsoft Team Foundation Server can also complete continuous integration in addition to source control and build. Each product has its own target audience, but they are all designed to monitor the source code and run the build scripts automatically, so there's no need to do this manually. The traditional strategy of continuous integration Server is to monitor the changes of the source control repository, automatically download the latest code when there is a change, and then execute the script, which compiles the application in turn and prepares the publication. However, in the build script, you can add any tasks or behaviors that you need.

You can set up unit tests or any other automated tests that you write as part of the process. Once someone commits the code, the test runs immediately. As for the test does not pass, even if the compilation does not pass, you will be told the error, so these problems can be quickly processed. As far as I am concerned, I suggest shooting the responsible person with darts (dunce is another good choice), but it is up to you to decide how to achieve it.

Release

So far everything has been for this moment. At the moment we just submit the code, compile it automatically, run the test, deliver to the prep environment and prepare for the release. The final step is to publish the code that delivers the readiness environment to wherever it is needed.

Publishing your own hosted Web applications is typically a copy of the files from the preparation environment to the Web server. This may mean copying files manually, or organizing them into a simple batch/shell script. Because we're still trying to make life simple and automated, you'll be looking for better solutions. Depending on your organization's security policies, you may be able to organize the tasks in the continuous integration process to copy files through the file system or FTP. As for a pure HTTP solution, you can look at products such as Dubdubdeploy, which are not restricted by domain security or file system access, and can copy files between servers.

If you have a packaged product, the final step is simply to package the product. The build script might have handled the creation of the installation package, organized the documentation, and other things related to publishing the file. Now that you have a deployable product, the rest is to copy the product to a 3.5-inch floppy disk, package, release.

Summarize

Building an automated build environment may take some time to make it work the way you want it to take at least a few days, maybe a few weeks, and perhaps adjust as you wish. Finally, you need to weigh the time that you will save on a daily basis, and the pitfalls that people can easily fall into and avoid in a consistent process.

When everyone is doing what they do best, your organization will be the most efficient. Developers write code, build engineers handle build and deploy configurations, build servers to do all of the repetitive tasks, and it does a great job. Smooth software processes often directly improve product quality and shorten the release cycle, both of which will greatly affect your company's financial situation.

About the original author

Joe Enos is a software engineer and an entrepreneur with nearly a decade of experience working in the. NET software field. He focuses on automation and process improvement, covering all aspects of the software sector. He has lectured on automated builds for small software teams at various software conferences across the United States, including topics such as build scripts and continuous integration.

His company's first software PRODUCT, Dubdubdeploy, has been released in the near future and is the number one product that helps improve the software team's management of the build and deployment process. His team is currently committed to. NET build process is fully automated.

Automation builds the key to consistency