Catálogo de publicaciones - libros

As we end this chapter, we have taken important steps toward improvement of delivery processes. We have looked at the inside of our fictitious development company, Etomic, and we have seen some of the issues they have faced and are facing. We have reviewed a list of aims Etomic has for delivery processes, and discussed the surrounding context for delivery, looking at the problems posed and hinting at potential solutions or methods for the mitigation of risk.

We have also proposed an initiative known as Design to Deliver, which we will use as the basis for delivering improved delivery processes.

Finally, we have taken the first step in this initiative by defining a very broad build and deployment process and have briefly discussed automating these processes.

In the next chapter, we are going to start practical work on the Design to Deliver initiative with a look at NAnt—the tool we will use for build automation. This tool offers a lot of power, and so we will spend some time thinking about how it works but, just as importantly, what we can do with it.

Without even delving into the tasks of NAnt to any great degree, we can see already that there is significant power and flexibility afforded to the erstwhile developer through the configuration and organization possibilities of the build scripts for NAnt.

We can run NAnt scripts with our desired command-line options. We have looked at the core features of a build script and feel confident in meddling with these and applying their various attributes. Additionally, we have looked at two specific tasks that provide significant additional flexibility in script structure. We understand how dependencies between targets work, and how inheritance between build scripts works.

On a practical level, we have considered how we might structure our own build script for our solutions. We have considered the core activities that need to occur as part of our build process and we at least have a “v1” skeleton of the build and deploy files.

It has taken a little time to examine the features and specifics of NAnt, but you should now be feeling confident with the tool. At this point, you should be capable of producing effective scripts. More important, we hope we have whetted your appetite to tackle the issues our process presents even if you are not quite sure of the exact implementation details.

As far as implementation details, this chapter has explored specific tasks and the basis for simple solutions.

We will now move forward and apply our process to an actual system using NAnt. This approach is aligned with the Design to Deliver initiative that we introduced in Chapter 2; we will identify a suitable simple candidate and implement the process with only this candidate in mind initially.

We have walked through the creation of a build and deployment script in some depth. Although we have concentrated on a simple application, the same issues that arise for complex applications have appeared here in one form or another.

We have refactored the original script to a small extent and considered where other gains through refactoring may be obtained as we progress.

In addition, we have linked groups of tasks together to achieve our ends, and we discovered some of the limitations that we may need to tackle.

In the next chapter we will complicate the scenario further, which will lead to refactoring of the code itself and a refactoring of the build files to gain further efficiencies.

We now have several applications of different types running from a few build and deploy scripts. We have made the script files more efficient and spotted a few problems that we need to address going forward.

Broadly, we have a functioning process across several applications, and the knowledge to carry us forward into more complex scenarios. We have a list of useful standards for the development teams to work with to ensure that the integration of their projects into the process is as smooth as possible.

In the next chapter we will look at providing improved processes through the use of continuous integration with CruiseControl.NET and explore the effects that this has on the current process.

Subsequent chapters will help us to address some of the remaining issues as we extend NAnt to create new tasks and handle more complex interactions such as configuration and database issues.

In this chapter we have come to the end of the basic configuration for automated delivery of .NET solutions. We have built successively upon a set of initially simple scripts, and maintained that simplicity as we have increased the number of applications using the process. This has been possible through the implementation of a set of standards that are not too intrusive, but are effective to provide the necessary hooks for build automation as we have defined them.

Specifically in this chapter we have used CruiseControl.NET to provide a harness to encapsulate the build process we have developed, but also to implement continuous integration for our applications.

In subsequent chapters we will focus on the development of more advanced features to the system we have in place to squeeze some more functionality out of NAnt and CCNet while also using some other tools.

We have taken a closer look at the behavior and structure of NAnt. As we have discovered, it is easy to extend, and a variety of features are available to assist in the construction of tasks with minimum integration effort, including specific support of command-line type tasks and specific tasks to aid the use of any custom assemblies.

Extending NAnt is a pleasure rather than a pain. The framework for the application provides utility rather than forces increased thought on the part of the developer.

We will make further extensions to NAnt in the next chapter, where things start to get a little complex as we look at the integration of databases into the build process.

There has been a lot to learn in this chapter, but I hope you will agree that the results in terms of describing the beginnings of a database integration framework are satisfactory. The work highlights the fragility and lack of utility for such processes at this time, but with a toolset like SQL Bundle and NAnt and a little thought and creativity, these processes can work. Discipline is required to actually carry through these concepts to a production scenario, and if you review the processes, you will identify risks that cannot easily be covered-such as “How do I roll back in the event of a failure?” The scripts provide an easy means to handle such issues, but they do not avoid the original problem. On the other hand, we suffer these problems daily in any case. In the next chapter, we will look at generating further efficiency to the delivery process and the scripts through the use of code-generation techniques.

We have investigated what code generation or transformation can offer to the overall process. We have seen that there are a couple of possibilities for generation, and we have implemented a solution using CodeSmith and XSLT as the code-generation tools. We followed the same littleby- little process to complete a simple scenario to provide a basis for more extensive and involved work. Finally, we automated the code generation itself using a new instance of CruiseControl.NET.

I hope you agree that code generation is a technique that offers several benefits to the standardization and operational processes of delivery. We have only started to scratch the surface of the flexibility of a tool like CodeSmith and a framework like XSLT, and once again we have come close to an overwhelming set of options for decision making and script preparation and execution.

In the final chapter, we recap the efforts made throughout this book, and I offer a few final thoughts on the delivery processes that we have defined.

Working with NAnt and CruiseControl.NET is a great pleasure. The flexibility and power of these frameworks and the possibilities they introduce for defining the process in a formal way should not be underestimated. Their ability to remove the tedium of certain processes from the developer and to ensure compliance is also excellent.

At the same time, these tools highlight flaws and immaturity in the delivery phase of a software solution. This makes me a little sad but hopeful for the future.

Things will improve, particularly as Microsoft gets its act together and begins to deliver tools in this area, which has the tendency to push the world in a specific direction.

Delivery processes are a huge consideration. You can achieve efficient, consistent processes now with planning, effort, and the correct tools by your side.