This post is a part of automated deployment story

One of the blockers to widespread adoption of automated deployment tools is the fear that they cause greater security risk than humans executing a written deployment procedure. The greatest of fears is that an attacker would be able to push a malicious version of binaries to the production environment.

If you want to succeed implementing an automated deployment solution you must ensure at least same level of security as when humans manually copy binaries.

Who can deploy?

When there is no automation, the deployment is performed by designated humans. For testing environment it can be the QA manager, for production it is usually an operations team. They (and only they) are in possession of credentials required to log on to the target environment machines to copy the binaries and perform other deployment-related tasks.

People who have just begun automating the deployment tend to think that, since everything can be automated, the deployment process can be started straight from the build agent without any human action. This was also true in my case. Fortunately some wiser people reminded me about how important is to be able to name the person (not a machine) who was responsible for particular deployment.

The rule of thumb is, you can (and should) automate everything, but two things. First is starting the whole procedure. There should be a person that has to hit ENTER key in order to start deployment. We’ll be the one to blame if something goes wrong (for example upgrading the production site during peak usage hours). The second thing not to be automated is authentication. You should never store production (or even testing) environment credentials in order to be automatically used by the script. Whenever credentials are required, the script should ask the user to provide them. Sometimes it is possible to store them temporarily in memory so that user does not get prompted for same credentials twice.

What can be deployed?

Usually the more layers of security, the better. Should one get compromised, the other can prevent the disaster. Beside controlling who can deploy, it is also worth controlling what can be deployed. The easiest thing (and this is what we have actually implemented) is digital signature-based verification. A binary package is signed using a certificate stored on the build agent. The corresponding public key along with a gateway script is securely installed on all machines of the environment.

The only remotely accessible endpoint that is exposed by target environment machines is the aforementioned gateway script. This ensures that an attacker can’t bypass the security measures put in place. One can only trigger the deployment on the machine via this script and the script ensures that deployment package signature is verified against stored public key of the build agent.

Tools

Unfortunately there is no command-line tool to sign and verify signature built into Windows. That’s why PackMan was born. I mentioned this tool before in context of building a package. When building a package, PackMan also calculates the hash of the data and encrypts it using private key from provided certificate. It can be done with a command like this (MSBuild variable syntax)

PackMan.exe -i d:$(PackageDir) -o $(OutDir)\Package-$(BuildVersion).zip --cn DeployerCert -a create

When asked to unpack, PackMan first verifies the signature using a provided public key (PowerShell variable syntax)

PackMan.exe -p ${package_store}\${package_file} --vcn DeployerCert -a unpack -d ${tmp_package_dir}

This ensures that package is authentic and not corrupted.

This post is a part of automated deployment story

On of the problems with many simple deployment solutions is, the structure of the target environment is embedded into the deployment scripts. This was also the case with the previous, batch based, version of my deployment process. With the advent of PowerShell, everything changed.

Commas

CSV is one of the simplest formats for representing tabular data. It’s easy to read, easy to edit (also in Notepad) and it behaves nicely when stored in VCS. All these properties make it an ideal candidate to be used to describe the deployment environment. Last but not least, PowerShell has very nice built-in features for handling CSV files: Import-Csv, Export-Csv, ConvertTo-Csv and ConvertFrom-Csv. The most interesting one is Import-Csv as it allows to load data stored in file into an object form with one object per row and one property per column. It makes loading entire environment description file as easy as

$machines = Import-Csv environments.txt

The structure of the file is also quite simple. Because I deploy to DEV environment quite frequently (10+ times a day) and that it is done by an automated process, I’ve chosen to store credentials straight in the config file.

IP, Environment, Roles, User, Password
192.168.0.1, DEV, Web|App, devUser, p@ssw0rd
192.168.1.1, TEST, Web,,
192.168.1.2, TEST, App,,

Given these, you can imagine that getting the list of machines in particular environment (you need it to know where to deploy) can be done in another one-liner

$target_machines = $machines | Where-Object { $_.Environment = $target_environment }

Roles

You have probably noticed a column called ‘Roles’ in the description file. A concept of role is key to my deployment strategy. I borrowed the name from cloud computing lingo but the meaning is slightly different. My role is a named set of things that are deployed together and form a logical whole. The current list of roles in my application include web, tools (which is an odd name for application server stuff), tests (this role is installed only on DEV) and db.

As you can see in the sample environment description, a DEV machine serves both roles while in test environment there’s dedicated machine for each role. You can imagine, that production would probably have 3 or 4 machines serving web role and maybe 2 for application role. Having a simple file that has all this information really helps organize things.

Orchestration

Looking from 10.000 ft, the process of deploying one role to one machine is following

• stop the role
• update the binaries for this role
• start the role
• (optional) verify health of the role

Given that we have multiple machines, each of which potentially serving multiple roles, the question arises how do we orchestrate the whole process so we minimize the down time. The answer, as for all difficult questions, is, it depends. Because it depends, we want to abstract away the concrete orchestration and be able to pick the actual implementation based on requirements at hand. In my project I’ve identified two distinct cases.

If I don’t have to change the structure of transaction database, I can upgrade the machines one by one. To achieve zero downtime I need to fake the response for balancer’s health enquiry telling it that the machine is down before is actually is. This way clients will be served normally before load balancer picks up the faked ‘down’ response and actually removes the machine from the cluster. Then I can safely upgrade this one machine. Last but not least, I have to wait some time before load balancer figures out the machine is up. Voilà! A super-simple zero-downtime deployment.

In case I don’t need to change the structure (and assuming I can’t write code that can work with both structures) I want to upgrade all machines in the environment as quickly as possible. This is where PowerShell v2 jobs come in handy. You can use Start-Job to virtually deploy to each machine in a separate thread of execution. Because the bulk of work is done not on the coordinating machine but on the target machine, this literally cuts the deployment time to the amount it takes to deploy to one machine. Cool, isn’t it?

This post is a part of automated deployment story

I am sorry you have to wait so long for a new episode of the story. The truth is, this episode was written a week ago and saved as a draft. Just before publishing I got an e-mail from the IT department that the solution I proposed (using SharePoint site) is not acceptable from the security point of view. They are not going to allow any access to the site from an automated process accounts. Period. So the blog post went to trash but not the idea. Here it is, reborn, better than ever!

Release candidate repository

I’ve taken the idea of release candidate repository from the Continuous Delivery book. The idea is, release candidate is not a term describing a binary package generate just before releasing, waiting for final tests and go-live flag. Instead, a Release candidate is every binary that passes unit tests (or commit stage tests how book authors tend to call them). The candidate then goes through various stages of the deployment pipeline, passing (or failing) integration tests, automated user acceptance tests, load tests, usability tests etc. During this journey, a candidate is deployed to various environments. Finally, a successful candidate ends up being deployed to production. As you probably expect, I was in desperate need of a tool that could track my RCs from the very beginning to the end of their lifetime. Buying an expensive and have-it-all tool was, of course, not an option.

Release Candidate Tracker

It took me one afternoon to hack a quick and dirty solution. As always, you can download it from github. Please don’t complain about the code quality. I know it’s not the cleanest code on the planet, but it works (or sort-of). RCT uses an embedded RavenDB database to store information. The database files are stored in the App_Data folder. If I understand Raven’s license correctly, you can use RCT anywhere you want, also in commercial environment.

Workflow

Here’s the workflow describing the typical usage scenario of RCT. First, the build script (MSBuild in my case) creates a release candidate after successfully running unit (commit stage) tests. To achieve this, it uses curl tool to call RCT API.

$id = .\curl -s --data "State=${state}&VersionNumber=${version}&ProductName=${product}" "${server}/ReleaseCandidate/Create"
if ($id -ne $null) {
    .\curl -s --upload-file $scipt_file "${server}/ReleaseCandidate/AttachScript/${id}"
}

The first call creates a RC entity while the second one attaches a generated deployment bootstrap script. At this point, a candidate is in initial UnitTestsPassed state. You can see it on the release candidate list

The subsequent stages exercise the candidate using various test suites: integration, user acceptance and so on. However, before the candidate can be tested, it has to be deployed to a suitable test environment. Here comes another feature of RCT — the deployment bootstrap script. You can download it simply by clicking a ‘Deploy’ link on the candidate list. If you want, you can even associate the .ps1 extension with PowerShell so that it will be automatically executed. The script (which will be covered in detail in later episodes) starts the deployment process. Eventually, a deployment script completes the deployment and updates the state of the candidate.  There’s another API call and another script that does this

.\curl -s --data "Environment=${environment}&VersionNumber=${version}" "${server}/ReleaseCandidate/MarkAsDeployed"

After executing the tests, the state of the candidate needs to be updated to reflect the result. Here’s a script for this task

.\curl -s --data "State=${state}&VersionNumber=${version}" "${server}/ReleaseCandidate/UpdateState"

Eventually, is the candidate manages to successfully pass all the tests, it can be potentially deployed to production. Of course not every successful candidate ends up on production. Each change of candidate state is reflected on its detail view page

Any contributions to RCT are, of course, more than welcome. Happy deploying!

This post is a part of the automated deployment story.

The first custom step of my build process is building the deployment package. Starting from two applications in the solution it is impractical to just copy over a bunch of DLLs. Much better idea is to package them somehow so they can be easily handled as a whole. There is a number of packaging technologies available for .NET applications, including:

• NuGet
• OpenWrap
• Web Deploy

None of them is a complete and perfect solution. First two are biased towards packaging and managing reusable libraries so they put emphasis on versioning and enabling usage of packages in IDE and in the build process. Web Deploy is focused on, well, web deployment and it is lacking good support for any other application type.

Web Deploy

In my solution I’ve chosen Web Deploy because it few reasons. First, it was already there since it was the foundation of old deployment scripts. Second, it has a very nice feature of so-called publishing a web application. You may know this feature from VisualStudio as it is available from context menu on web projects. Basically, it removes all the files that are not necessary to run the application (like .cs, .csproj).

There are two central concepts in Web Deploy: operation and provider. Operation describes what to do. There are three (only!) possible operations:

• dump – displays information about an object
• delete – deletes an object
• sync – synchronizes two objects

Web Deploy comes with a great variety of providers. Providers implement specific deployment steps like changing the machine.config file or putting an assembly to GAC. The most important one for me is the package provider. It allows to pack a specified web site in IIS into a zip file and clone it somewhere else. What you can’t read on the documentation page (but can find on the Internet, of course) is, you can build similar package via MSBuild. Do do so, just call

MSBuild "ProjectName.csproj" /T:Package

After your main build process completes. The output is a nice zip file containing all the information necessary to deploy the web application.

DRYing the build script

For each application I deploy I need to call some packaging routing in the build script. This can quickly become a copy-pasted spaghetti. Fortunately I found out that MSBuild supports iteration. Here’s how you define the collection of elemenents

<ItemGroup Label="WebPackages">
  <WebPackages Include="ProjectA\ProjectA.csproj" />
  <WebPackages Include="ProjectB\ProjectB.csproj" />
  <WebPackages Include="ProjectC\ProjectC.csproj" />
</ItemGroup>

And here is how you call a specific routine on all of them

<Target Name="web-package-build" Inputs="@WebPackages" Outputs="%(WebPackages.Identity)">
  <Exec Command="$(MSBuild4) &quot;$(SolutionRoot)\%(WebPackages.Identity)&quot; /p:Configuration=$(BuildConfig) /p:DeployOnBuild=true /p:DeployTarget=Package /tv:4.0" />
</Target>

Nice, isn’t it?

One to rule them all

Bare Web Deploy would probably be enough for three or four web applications. As you remember, in my case there is about a dozen of them and another dozen of console tools. That’s why I decided I need another layer. Later on it turned out to be a good idea also for another reason — security. During the audit process one of the auditors pointed out that we don’t have any mechanism to guarantee that the binaries deployed to production are not forged.

I thought it will be a trivial task to implement — just use a command-line tool to zip all the packages (and console applications, each in it’s own folder) and another command-line tool to sign the zip file digitally. Unfortunately it turned out that there are no built-in tools on the Windows platform for these simple tasks. I didn’t like the idea of installing applications like 7zip or similar on production servers so I decided to create a custom tool for the task. This is exactly how PackMan was born.

PackMan is a quick and dirty tool for packaging a bunch of files together in a digitally signed zip file. Of course it also allows you to verify the signature and unpack the contents. PackMan is stream-based so it has no problem supporting quite large packages (mine has about 120 MB). It uses Windows PKI to retrieve the keys for signing and verifying.

Here’s the story of an automated .NET deployment. Story is strongly based on my current project. To give you some context, here are few facts about the project:

• dozen web applications (half of which to be installed only on test environments)
• more than dozen console applications doing various things (reporting, mailing, etc.)
• four environments (DEV, TEST, DR and PROD), up to 4 machines each

While it certainly is not the biggest .NET project, it for sure calls for automated deployment procedures. The previous tedious manual process was taking up to 8 hours to complete and, needless to say, was failing quite often due to deployment notes not being up to date.

I started automating the process a few months ago, but at first I was struggling with each and every step. The breakthrough came with reading the awesome Continuous Delivery book by Jez Humble ad David Farley.

This is the first post in the (hopefully) long series. It is mean to give you an outline of the process we implemented. As time passes, it will fill with links to posts covering specific areas. So, here’s the sketch

1. Compile the source code (nothing fancy here)
2. Run the commit stage tests (mainly unit tests)
3. Build and digitally sign the deployment package
4. Put the package in the build drop folder (again, nothing fancy)
5. Create a new Release Candidate in the release repository
6. Get the latest Release Candidate which passed commit stage tests
7. Start the deployment based on description of the environment (what to install where)
8. Upload the deployment package to target machine(s)
9. Validate the authenticity of package with public key of the publisher
10. Stop all running applications (both web and console hosted by Windows Scheduler)
11. (Re)create the applications and application pools on IIS
12. Update the binaries to new version
13. Start the web applications and schedule console applications
14. Verify the correctness of deployment
15. Run the integration and automated user acceptance tests
16. Update the status of Release Candidate reflecting the outcome of the tests

December is traditionally a time of retrospective posts. Forgive me please but I simply can’t resist following this trend. I’d like to share with you my thought about books I read this year. Hope you’ll find it useful when deciding what to read next.

REST in practice

This was the first Kindle book I bought. After reading it I could say I love both the book and the device. I learnt quite a lot about the principles of REST. The hardest part was understanding why these hypermedia are so important but then came the moment of enlightenment. I can for sure recommend reading it.

CSS: The Missing Manual

I must admit I had quite high expectations that I will learn how HTML layouts work and how to efficiently position elements. It turned out to be a book about CSS syntax and very basic stuff I already knew.

Management 3.0

I wanted to learn a little bit about management for quite some time and suddenly this book came out. I simply love all the analogies (i.e. to bacteria) Jurgen uses in the book to explain how such complex systems as software developer teams work. Recommended to everybody, even if you don’t plan to become a manager.

Event Processing in Action

Another high expectation book and another disappointment. I expected a good book on event-driven architectures but actually EPiA is a book about taxonomy and nomenclature of event systems. Not much more than a bunch of definitions.

Dependency Injection in .NET

I bought it via Manning early access program and it was for sure not a waste of money. Although because I had some experience with DI before and have been up-to-date with blogs and tweets of Krzysztof Koźmic and Mark Seeman, there was not much new to me in the book. Still, I don’t regret the money and I can happily recommend the book, especially if you are new to DI.

The Pragmatic Programmer

A friend of mine recommended this book to me so I though I can give it a try. I had mixed feelings after reading it. I can’t recall a single thing that altered my thinking or opened my eyes to some new insight. For sure it is a solid book and at the time of writing it contained some cutting-edge stuff but after a few years these ideas have become mainstream and their understanding is expected even from novice developers.

JavaScript: The Good Parts

Another tentative one. I expected a lot more hardcore stuff in the book. It left me with a feeling that I know JavaScript (which is bullshit). If you happen to don’t know it at all (are there such people?) it may be a good book to start with.

Streamlined Object Modeling

After hearing so many good things about the book on Domain-Driven Design group I simply had to read it. To my surprise I dint’t like it. I could not get rid of a feeling that authors promote some catch-it-all model they developed and claim it solves all problems (even probably hunger in Africa). The only thing I really liked was the modeling heuristic that objects that are active in real world tend to work better if modeled as passive in the domain model and vice-versa.

Working Effectively with Legacy Code

I bought this one because we started to rewrite some legacy code in my current project. I wanted to learn from the expert how to deal with such code. It turned out to be a good, solid book. I don’t remember any particular moments of enlightenment but for sure I learnt a lot.

Continuous Delivery

This is the last one. I’ve been reading it since Saturday and already read about 70%. Continuous Delivery is probably the best book I’ve read this year. Together with REST in Practice and Management 3.0, it totally changed the way I see software development as a process. Thanks Jez and Dave!

Looking into the new year…

There are several themes that dominate my Amazon wishlist for the next year:

• C# (need to refresh my knowledge)
• Lean (having heard a lot about Kanban I finally need to read some ‘classic’ books)
• Architecture (Pattern Oriented series in particular)

I would also like to read some ‘true classics’ like Extreme Programming Explained by Kent Beck. Life will show if this is doable…

…Windows is. If you have been convinced by Microsoft that .NET is an application platform for the enterprise, here is a list of arguments proving that it is not (yet).

• IIS is not an application server. All it provides is serving dynamic web pages and hosting WCF web services.
• AppFabric have not delivered on its promise. Nobody is using workflows so the only widely usable part of it is the distributed cache (which, I must admit, is nice).
• IIS does not allow to host scheduled tasks. For these you have to use Windows Scheduler which operates on OS level.
• IIS does not work well with custom threading models so things like NServiceBus have to be hosted as Windows Services.
• IIS does not have a decent monitoring & management story. You have to use WMI which, again, is an OS level service that does not speak .NET language and is quite cumbersome do use.

Convinced? So here’s a list of things which you, as a developer, can do to fix this problem

• Extend IIS or create a complementary service that can use the same model as IIS (one core process per system + process per application) that would host scheduled tasks and could incorporate custom threading models thus allowing to run things like NServiceBus.  TopShelf would be a good starting point.
• Assembly is not longer a good deployment unit — it is too small. Provide a packaging system that would allow to package several assemblies (a functional module) together. Such a module could be easily deployed (and undeployed) from the application server as a whole.
• Create a decent scheduling library. The only one there is, Quartz.NET, is probably one of the oldest .NET open source projects still in use. It desperately needs a replacement that follows today’s design practices.
• Think about how you could contribute to NetMX or come up with a completely new, lightweight, monitoring & management framework.

Having all these things built, it would be quite easy to assemble an open source private cloud infrastructure. The goal would be to have a farm of servers running either Windows or Linux/Mono that can be treated as one logical machine to which I can easily deploy all kinds of components including (but not only)

• web applications (using various MVC frameworks)
• scheduled services
• message consumers (using various frameworks like NServiceBus or MassTransit)
• web services (using, again, variety of frameworks like WCF or OpenRasta)

delivered in easy to use packages.

Last Saturday I attended the second Kraków Code Retreat which was a part of the Global Day of Code Retreat. The event was organized by Kraków Software Craftsmanship society, [sckrk].

The organizers did a great job preparing the meeting. There was even a coffee machine for those who, like myself, can’t start a proper coding day without a cup of coffee (or two). Because the event started so early (between 8 and 9 AM), the organizers ensured that we have sandwiches for breakfast. It was a very nice surprise.

On the contrary, the form of the event was not a surprise for me. Partially because I attended the previous code retreat [sckrk] organized in April and partially because the form of these events is pretty much standardized. There are 5-7 sessions, each about 45 minutes long. During each session we try to solve exactly the same problem (the most popular one is Conway’s Game of Life) the best way we can. The assumption is that we work in pairs and we all employ TDD. The amount of time is calculated in such a way that it should be very difficult to finish the solution. The reason for this is, during a code retreat, you should not focus on getting things done but, instead, on writing the most beautiful code you can.

I was quite surprised by the fact that we (I paired with Piotr Leszczyński for this session) managed to solve the problem within the provided time frame. Especially given that I did not manage to solve it during the event in April. The key to our ’success’ (remember, it’s not the completeness of the solution what matters here) was probably the fact that we both have had some experience in both pair programming and TDD. What is more, we did practice these disciplines together in some point in time. I really enjoyed these 40 or so minutes. It would be worth attending the event even for this one session. On the solution side, it was not particularly clever or beautiful. It was not purely object oriented and some abstractions were missing. But my feeling was it was a good SOLID code. The downside of having a complete solution in first try was that I was under it’s influence for the rest of the day. It was hard to think in a completely different way.

The effect was, I spent two sessions refining this solution. One of the improvements was making the coordinates a class on its own. It encapsulated the way neighbourhood (the key concept in Game of Life) is defined. We didn’t have enough time to make the last step and make our game board generic of T where T is an implementation of some Coordinates. It would make changing the coordinate system (for example to spherical or 3D) a trivial task.

The other improvement was made in the method that returned neighbouring coordinates for a given coordinate. In the first solution we just hard-coded it like this:

yield return new Coordinates(x, y - 1);
yield return new Coordinates(x, y + 1);
...
yield return new Coordinates(x + 1, y);

The improved solution looked like this:

return (from x in Enumerable.Range(-1, 3)
from y in Enumerable.Range(-1, 3)
select new Coordinate(x, y))
.Except(this);

It puts grater emphasis on the intent. It would be even better if Enumerable.Range method has min and max parameters instead of min and count.

Like I said before, one of the assumptions of core retreat is to test drive the design. The problem with this approach is, it is hard to force a completely different solution only be means of writing proper tests. I wanted to try something different so I convinced Piotr to leave TDD aside for one session. We agreed to use test-first approach but implement the design I proposed. Piotr suggested that we should also refrain from writing any conditional statements (if, switch). This sounded like a fair deal.

What we tried was an actor-based approach. Every cell was an actor which was able to respond to various events. The environment was responsible for routing these events so that cells get events generated by their neighbours. The solution was turn-based so that in the beginning of each turn every cell got events from other cells and at the end — a clock event from the environment. The response for this event could be either ‘alive’ or ‘dead’.

The other interesting thing about this solution was, it allowed us to get rid of conditional statements in a quite elegant way. We used a state pattern to process the events:

public interface IState
{
   IState ConsumeAliveEvent();
   IEvent GetResponse();
}

There can be four possible states in the game: base (cell will die in next round), after consuming one alive event (will also die), after two (will survive), after three (will survive) and more than three (will die).

Unfortunately we didn’t have enough time to finish the code, but it was quite promising. Especially the tests which were in form of statements like this

given these (events) happened, the cell should generate these events

In quick summary I would like to encourage you to take part in every code retreat event that is organized in you neighbourhood. It is really worth it, event if you have some experience in TDD and/or pair programming.

When listening to many discussion about Domain-Driven Design and Event Sourcing, subjects which I am recently very into, sometimes I have a feeling that events are considered merely a way of persisting aggregates. People tend to discuss benefits events have with regards to storing historical data, having possibility to generate any read model out of events and so on. Reducing event sourcing to such ‘housekeeping’ duties is castrating your architecture.

This point of view is expressed in a way people model their event-based solutions: thinking first about the aggregates and then, within each aggregate, about events they generate. Sometimes the process is even more event-UNcentric when people first implement a command and then start thinking about what event types should be created.

Given the fact that most Event Sourcing practitioners have a background in DDD, we tend to bring our experience from working in data-centric environment to the event-centric world. There is, however, a fundamental difference between these two.

When building a behaviour-oriented DDD solution on top of a data-centric infrastructure (a database) you do your best to hide the database and its schema from the business layer. Over the years we learnt that it is better treated as implementation detail because it does not provide concepts useful to model behaviour. There concepts must be built on top of it. The underlying data layer must not be visible to the outside world because of it’s volatility — it has to change whenever the behaviour it supports needs to change.

On the other hand, when building a similar solution on top of event-centric infrastructure you can (and should) leverage events to model the behaviour. They (not aggregates or anything built on top of them) are the central concept here. Whenever business changes, new event types appear and some old are no longer generated but no event is ever lost. Whatever happened, happened.

Returning to my original thought, in an event-centric solution aggregates should not be treated as first-class citizens. Don’t get me wrong, they are very useful. In a healthy design probably a vast majority of events would be generated via aggregates, but some would not. Aggregates are priceless when it comes to modelling concurrency and to encapsulating business logic.

You may now want to ask a question when should you use aggregates and when not? The answer seems to be simple. Whenever your system needs to respond to some external activity, you just directly inject an event representing what have happened into your system. The idea is, again, whatever happened, happened. You can’t throw concurrency exception at The World saying it is wrong to raise this event right now. You have to humbly acknowledge the fact and record the information. On the other hand, when it is your system who conducted the activity to be communicated by an event, you should use an aggregate to have full control over how and when the event is published.

Have fun building event-centric solutions!

Chciałbym zaprosić wszystkich na 69. spotkanie Krakowskiej Grupy Developerów .NET. Spotkanie odbędzie się jak zwykle w siedzibie ABB, przy ulicy Starowiślnej 13. Będzie także dostępne on-line dzięki uprzejmości portalu VirtualStudy. Na spotkaniu, jak zwykle, dwie sesje. Tym razem będą to:

Kanban – Usprawnienia bez wysiłku, którą zaprezentuje Paweł Brodziński, oraz

Software as a Service – jedna baza danych, wielu użytkowników, którą przedstawi Maksymilian Majer

Po spotkaniu zapraszamy wszystkich na wspólne piwo. Będzie to okazja, aby podyskutować z prelegentami na temat ich prezentacji w bardziej nieformalnych warunkach. Pierwsze dwie kolejki tym razem (to nie reguła) stawiają prelegenci!

Zapraszam do rejestracji na spotkanie tutaj.